Hey everyone. Today we’re looking at a common document needed to be able to implement analytics data, and that is a tracking plan. It doesn’t really matter if you’re doing it on Mixpanel or Amplitude, Google Analytics, or if you just build it on an actual, just raw data structure, or something like Amazon Redshift or BigQuery. You’re likely going to want to think through your event tracking, and what events you want to send, what properties you want to collect and so on. I find the best way to do this is just in a simple plain old Excel spreadsheet or Google Sheets, which would be my preference. Actually as you think through it, before you [inaudible 00:00:36] start writing code, we can do a quick planning out document.
I’ve got in front of me the template that I use for my clients. Also, I’ll show you the template that other companies provide you with. I will have the template from Segment.com and Mixpanel has a template, and I’ve seen a template from Amplitude as well. They’re all almost the same, and you’re going to see the same structure over and over again. But let’s walk you through it, let’s walk you through the most basic columns and rows that you should keep in mind.
When we open here, right away, when I create a document like this I’ll go through the app, whether it’s a web app or a mobile app. I tend to split the document into sections or I tend to split the app into sections. I might have the signup portion, and then I’ll have the onboarding portion, and then I’ll have maybe some of those core critical product things it can do, and then I’ll have maybe some of the revenue portion, or some of the revenue events like upgrading their plan and so on and so on and so on.
I’ll just event it into logical sections, and it really depends on the app, but you could probably get a sense of what those sections are. This is just for organization. It doesn’t matter if you have too many sections or too little sections, just some sections. Then we get into the bulk of it, right. Really, we want to look at first events. Events have two things usually, event names and event properties. The event name is what you’d be looking at when you look inside a tool like Mixpanel and you want to say hey, how many times a user did this. That usually means, how many times has this event been fired over that time period?
Event names should be logical. That’s the best description for it. I’ve seen very cryptic, obscure event names that no one knew what they were. They shouldn’t be, let’s say, development functions, right. Of course, in your code, you might have a function for signup, which might look something like signup, completed functions, something like that, right. It probably shouldn’t be that. It should just be signup completed, right, it’s the action the user has took.
When you write them, you tend to have the choice to write them in the past, in the present or in the future. Again, not a big preference either way. But what you can do is simply choose one. You might say hey, I’m going to use the past tense for this and I’m going to keep them like that. I think this is all past tense and I’ve completed it. The other thing you should consider here is using the same naming convention. This right now, this is all title case, right, but you could also do lower case, right. Or you could do camel case. Again, which one you choose doesn’t really matter, but you should stick with one. You choose one, you stick with it.
From my experience, lower case seems to be quite popular. It seems to be easier to maintain. For developers, they can sort of just force everything to be lower case. It makes it easier to keep in standard. That’s one option. Another thing I’ve also seen that’s also handy, it’s maybe a sort of prefix for category events. This is commonly seen in, say, onboarding, right. We might say hey, we have six or seven events during onboarding and we want to know they are in the onboarding, so we’re going to do onboarding first step. And then we’re going to do onboarding second step, right. Onboarding third step, right. So when you look at them in the interface or whatever you’re using to query these events, they’re sort of easier to find. You can say oh yeah, here’s the onboarding events because they have the prefix. Other common prefixes are things like checkout, where you have category events organized around that. That seems to be handy. Those are just general tips.
Then lastly we move into the properties. Properties is anything related to the event that we want to track. Usually we’re looking at relevant things. You know, here for the signup, maybe users can sign up by email, Facebook and, let’s say, Google Plus here. You know, we could add a property that we just call authentication type, Facebook, email, Google Plus, right, so they have one of those values. You’ll find that the properties is really where the magic happens. As you get deeper in your product and you kind of cover some of those core product events, you’ll find yourself doing five, ten, maybe 15 different properties, maybe even more, because you’re collecting all the signup information. What properties lets you do is it lets you create more condensed reusable global events.
A common example is maybe users can upload pictures to your server. You know, a video attachment. They might be able to upload a YouTube video, then they might be able to also upload from Vimeo, and they might be able to upload an MP4, something like that, right. Let’s do that. You know, upload an MP4, but instead of doing three kind of major events, or three different events, we can just sort of do one event. Do upload video, and now we have one event. We can have a property here that is called video type, right, and maybe here we’ll do something like YouTube or Vimeo or MP4, something like that. Now we condensed three events into one global event.
It’s always a good idea to condense events, one, because it’s easier. If you want to, let’s say, do a breakdown of the most popular types of videos being uploaded, it’s easier to have one event and then break it down by property than do [inaudible 00:06:10] three events together, just simply [inaudible 00:06:13] wise, even if you use something like Sequel. A lot of analytics tools, they tend to charge you by event, not by property, so it’s a cost incentive to do that too. That’s one thing.
The other thing about properties to keep in mind is to be consistent in how you use them. A common example here is we might have maybe an event when the user logs in, right. Then when they log in, they can also log in via Facebook, email or Google Plus. Instead of having a whole different property, something like authentication or account type, right, and you have Facebook, email and Google Plus. Instead of doing that, let’s just use the exact same thing, right. The benefit here is then, as people get familiar with the data, they’ll learn to recognize that. They’ll see oh yeah, it’s authentication type, I saw that at the signup event. It probably works in the same way here, right. This is something you’ll see across your product, where you’ll have properties that are very similar, almost identical, and they might mean the same thing. You can just rename then slightly maybe make them a little less specific, just so you can reuse them in different places. That’s the event.
A helpful column that you’ll want to skip is the logic, the one that fires. This column is helpful for developers. When they take the plan, and this plan is really meant to developers, right. It’s meant to help them implement the data quickly. You don’t want to assume that they know what you mean when you mean signup completed, or whatever event. Just be very specific in the logic. This event fires when the user clicks the download PDF button on the homepage. That’s very specific, right. There’s not a lot of room for ambiguity or confusion there. That’s really helpful.
Then lastly we have a column F, in this case we call it traits because this is for Segment, but this is really user attributes. Mixpanel calls it people properties. This is just the attributes of users you want to collect. A lot of cases, attributes here will be things like name, email, city, country. Then in every product, you have very product-specific attributes. Maybe the plan they’re in, like the membership plan. Maybe how much they’re paying. Is it per month, is it per year? Then we can look things [inaudible 00:08:26] authentication type, right, so we can store that. How do they authenticate? By Facebook, by email, Google Plus? Other types of traits here or user attributes might be how many times people did things. A lot of times we might say okay, they uploaded videos. How many videos have they uploaded in total, just so we have a running tally of that, and we can break it down by that.
You want to just set those here, and this is just sort of properties. You’ll see they have almost the same structure of a property. As you go through, you just want to think about okay, what user attributes am I interested in looking at? If I were to open the profile of a user of one of my best customers, what would I want to see at a glance, right? What things would be interesting to me? This would be things like oh, you’d be interested in seeing city they’re from, what country they’re from, how they authenticated. Maybe how many times they have done this, how many times they have done that, or what is their plan and so on. That’s where this comes from.
This is this plan. There’s a couple of tabs here. We’ll skip the super property tab since that’s very specific to Mixpanel. In the notes tab, I just tend to put a little guidance of what the plan is. I like to use pipes to denominate ORs. So email OR Facebook OR SMS. Commas to denominate lists. A lot of analytics tools support the idea of a list, so having multiple items. You could imagine something like you have an event called add to cart, and your cart has multiple items, so you might set a property with a list of values for those items in the cart. Numbers or integers are pretty straight forward. Everything else tend to be strings. For currency, most analytics tools do not want to see a currency symbol in there. Whether it’s a dollar sign or a euro sign, it doesn’t matter. You then just put the actual … You tend to put that as a number. Then I like to provide the documentation docs for whatever we’re implementing. You can see this plan is sort of geared towards Segment.com, but you might see a Mixpanel link here or a Google Analytics link or whatever we do it in.
Their events tab is similar to what we have. You know, here is our event name. The “Why?” this is more of a business column. Then we have properties, they sort of added properties, and then they separate that into columns. Properties and property values, pretty straight forward. Location’s kind of similar to probably the fire one, so you know, this fires to the signup page or this fires here. I find it helpful to have an actual description of when something should fire, just because it might be able to fire in multiple ways on that page. But that’s what this is doing here, and like before, we have a code here or the little tracking here for “Ready,” “Installed.”
But again, a developer will have to figure out is the server saying it’s supposed to happen once a day when they log in, when they log out? There’s still a little bit of logic that would need to be entered here to figure out when something should be done. Lastly, they have a group call, which is relevant for tools like Intercom that lets you organize users on their organizations or groups, so same idea. So that’s that, that’s Segment.
Now here’s the Mixpanel plan. This is geared towards SaaS companies, but the structure’s what we’re looking at here. We have a trigger. This is kind of like our fire one, right, user views a page, user views the blog, user requests a demo. Then they have the event name. Then they have properties. Here is the different properties, and here is a property type. They have a super properties, which is something specific to Mixpanel. Again, property type, and then people properties, which is their user attributes concept. Same thing. What they don’t have here is they don’t have values for the properties, which … I find the values do help provide a little context of what the property is. Business insights, this is cool, right. Again, we’re trying to tie it into some kind of business goals. And then to metric category and reference client. I’m actually not sure what reference client is. We’re going to keep it going down, we have a complete list of things. Again, another way to structure your tracking plan.
You have options. You can either build your own, you could do something else. I’ve seen people do diagrams of their analytics data. But the same idea is still there. We’re going to have events, we’re going to have event properties, we’re going have user attributes. We need a logic of when to fire them, and not to forget that these documents are usually for developers. They need to be as clear, as straightforward as possible, so I could just grab it, grab the documentation and implement. And that’s all for today. Let me know if you have any questions.
I find most companies are stuck with high-level metrics and they aren't able to properly understand what actually drives user growth for their web and mobile products. To do that, you need the right data and the right tools.
If this sounds like your situation, then you should download our free tracking plan (and tutorial video). This is the document that you should create before you ever implement tools like Mixpanel, Amplitude, Segment, and Intercom. Click the image below to download your own free tracking plan (and tutorial video).