Adding Events and Properties
With a naming convention in place, you can begin mapping the information gathered so far into the different components of the Mixpanel data model in your spec. The interactions identified so far would be Mixpanel events and next to the event you can add the KPI or metric it is related to.
Properties are the details, so think about the interactions identified and ask “What are the details I want to know?”. It could be a detail that should be included with the event (event property) or something about the user (profile property). In some instances, it makes sense to track properties as both event and profile properties. If there is a property that should be tracked with all events once its set, you would want to use a super property.
Default Events and Properties
Mixpanels client-side libraries will track some properties by default for all events or profile updates coming from that SDK. The default tracked properties can be seen here. Additionally, our mobile libraries can track certain events automatically if enabled. These events can be seen here.
Certain properties also have special functions in Mixpanel. The reserved property values are particularly important for some user properties with regard to our messaging tools. We recommend checking out our reserved event and user properties when creating your tracking plan to check if information needs to be sent to Mixpanel in a specific format.
The Data Type and Sample Value fields in the spec should show the expected format for your properties. The different Mixpanel data types can be seen here. The incremental type is also used in some of the example specs. Incremental is simply a numeric property that will change by some value (e.g. Number of Songs Played).
Other important pieces of information to add are descriptions of your events and when these interactions should trigger. This is critical information for your end-users, your developers implementing, and for any data discrepancies. At times the behavior may seem obvious (built into the name - e.g. “Level Complete”) and others there may not be much of choice but regardless it is best practice to document the behavior.
Take a “Signup” event for example. This event could be implemented to trigger when the Signup button is clicked in your app or perhaps after receiving some confirmation an account has been successfully created from your backend. In the first case, if an error occurs after the user presses the signup button - maybe the password they entered was the wrong format - a “Signup” event would trigger in Mixpanel but an account for that user would not have actually been created for the app yet. In the latter case, this would not happen because the event triggering is dependent on a successful signup happening.
The remaining fields, Implemented?, Method Call, and Developers Notes, are best left to those implementing to fill out as they go. After the events and properties have been officially implemented these fields should be filled in to complete the tracking plan.
ACTION ITEM: Add events and properties you want to track for your key metric along with supporting information to the tracking plan.