Tracking Plan Tips
Check out a tracking plan example here. Feel free to use the spreadsheet as a template.
1. Casing is important.
If you use multiple different casings for the name of an event in your code (e.g: "Purchase Completed" vs. "purchase completed"), they’ll be tracked as different events. This is a very common issue when different developers are using the same tracking plan.
2. Stick to a naming framework.
My favorite is “Object + Action”, e.g: “Fundraiser Created”, “Donation Completed”. But the most important aspect is that you’re consistent with whatever framework you use. A good reference article by Segment can be found here.
3. Extra information goes in the event properties, not the event name.
Anything more than the general name of the object or action should not be in the event's name.
Example: Instead of having “Free Account Made” and “Premium Account Made” as separate events for the types of accounts a user can make, just make a single “Account Made” event with an “account_type” property that can be either "Free" or "Premium".
4. Don’t use punctuations in the event name.
They’re unnecessary and just lead to confusion. Your event should be named “Purchase Completed”, not “Purchased Completed.”
5. Events should describe user actions.
Try not to have events that are simply the names of different pages in your app. This isn’t applicable to 100% of cases - sometimes simply arriving at a page is what matters most - but is a good general guideline.
Example: avoid events like “Account Creation Page” and “Login Page”. Instead try “Account Creation Started”, and “Login Flow Started”
6. An event’s name should reflect its exact trigger.
If an event is called “Purchase Completed”, it should be triggered when the purchase is confirmed to be completed and not when the user presses the button to purchase. If it’s triggered on the button click, you won’t be able to catch cases where there’s an error resulting from the button click. Repeated clicking of the button can also lead to overcounting your number of purchases.
7. Give your properties context-specific names.
Instead of naming a property something like “price”, call it “item_price” when on used as a property on a "Purchase Completed" event. It makes things much easier when you’re looking for that property in Mixpanel.
8. Differentiate between server-side and client-side events.
Events can be captured both on your client (e.g: mobile app, web app) and your backend server. The former gives more detail into user actions, but the latter has more accurate numbers. Mixing and matching the different types of events in the same report can give you unexpected results, so make sure you indetify them clearly in your tracking plan or the event name itself, for example by adding a "(server)" suffix to the name.