Defining super properties and profile properties
Mixpanel defines super properties as follows:
“Super Properties are a type of Event Property that you can register once to automatically attach to every Event you’re tracking. They are Event Properties that apply to all Events without having to manually include them in each mixpanel.track() call.”
This means that as soon as a super property is defined the property gets added automatically to any events that follow afterwards.
Mixpanel defines profile properties as follows:
“Profile Properties give you details about a certain user overall. In other words, Profile Properties describe your users as they exist at this moment.”
Profile property values get stored in the user’s profile. They can be observed in the user section of Mixpanel’s interface. The most important element to point out here is that profile properties only capture the latest value of a property.
Use case - Buying sneakers
To elaborate on the implications of defining a property as a super or profile property we will be using a simple example.
In this example we’ll be looking at events triggered for an eCommerce selling sneakers.
For the sake of simplicity we’ll be looking at only two specific events:
product_added_to_wishlist - This event is triggered when a customer adds a product to her wishlist.
purchase - This event is triggered when a customer buys a pair of sneakers.
The rest of the events that would happen across the two sessions are omitted so we can clearly focus on the case this article is dealing with. We also assume that when a brand that was on the wishlist was bought, the brand gets removed from the wishlist.
In session 1 the user adds a pair of Nike sneakers to the wishlist after which she buys them. A couple of days later she returns to the website and adds a pair of Puma sneakers to her wishlist.
The case we’ll be exploring is what questions can be answered depending on the definition of product_wishlist_brand as either a super property or a profile property.
The super property setup
Defining product_wishlist_brand as a super property as soon as the event product_added_to_wishlist gets triggered results in the fact that the property product_wishlist_brand gets added automatically to any other event going forward. Super properties are meant for properties that are key to contextualise any other event.
The result of defining product_wishlist_brand as a super property when product_added_to_wishlist is triggered is that the event purchase now also contains the property product_wishlist_brand.
This setup allows you to answer the questions:
“Was the brand that a user bought on the wishlist of the user, prior to the purchase?”
“How often do customers buy sneakers of the brands that have been added to their wishlists?”
“Which brand was on the user’s wishlist prior to completing the purchase?”
The answers to these questions could be interesting to the product team as it could be an indication of how important wishlists are and how it contributes to sales.
Answering these questions is enabled through the use of super properties as the purchase event is always contextualised with the exact value of product_wishlist_brand at the moment of purchase.
The profile property setup
Profile properties only capture the latest value of that property. This means that, if we define product_wishlist_brand as a profile property, we will only be able to recall the latest value that is stored and that access to that value depends on when we conduct our analysis.
If we request the value for profile property product_wishlist_brand after session 1 but before session 2 the value will be “nike”. If we conduct the same analysis after session 2 the answer to that question will be “puma” as the value has been overwritten by that point in time.
More importantly, if we ask the question we asked ourselves in the previous paragraph “what was the brand that a user bought on the wishlist of the user, prior to the purchase?” using product_wishlist_brand as a profile property we would be unable to answer that question. Reason being that the value stored for the profile property product_wishlist_brand would be “puma”, while the value should have been “nike”.
This is expected behavior as the profile property only retains the latest value for a property. Depending on the point in time an analysis is made relative to the behavior of the user, some info might be lost when relying on profile properties.
However, answering the question “how many users do currently have a Puma product on their wishlist” can be answered most effectively by capturing product_wishlist_brand as a profile property as this will immediately show the exact count of users for who the latest value for product_wishlist_brand is mapped to “Puma”.
Other use cases where profile properties come in handy is when we would like to know the subscription model a user is on, or how a user is classified in sales segment.
Articulate your questions then pick the right property type.
As this article was focusing on explaining the explicit difference between super properties and profile properties the order of things was atypical. We first explained a specific setup in order to then address which (exemplary) questions could be answered. We hope this article has served its purpose in explaining the difference in that way.
However, when building a Mixpanel tracking plan the questions should always come first. A proper understanding of the implications of tracking properties as super properties and profile properties allows you to ensure the technical specifications of your tracking plan will meet the requirements needed to answer your questions. A good implementation starts with a good understanding of what you want to get out of your Mixpanel implement
ation which means you need to start by thinking about the last step, the analysis.
Need help defining your Mixpanel specifications? Don’t hesitate to reach out.
Comments