So you have a new project and you want to setup your analytics. This post is to understand the minimum you should be doing.
Don’t fret! The companies with the most advanced data systems like Facebook and Amazon and Netflix didn’t start out with that system when they were young.
And the good news is that tools and services have grown substantially better in the last few years. This post will be opinionated but you can trust that you’re doing the right thing.
Oh, who the hell am I to have strong opinions? I ran growth at Dropbox and my startup YesGraph focuses on helping apps grow so I constantly talk to companies about their metrics, analytics, and growth. I’ve seen every stage, from startup to Facebook scale, so to reiterate, this is for young startups.
0. It’s event driven, obviously
If you’re looking at Google Analytics for pageviews, you’re missing what users are actually doing. Good analytics starts with the user experience, which means following a series of events the user went through.
Some would argue that this should go further, that you need to look at events and the state of the user at the time. I agree, but that’s starting to get complicated, like with advanced cohort analysis. The real point is that some people don’t even understand event based systems and are looking at vanity metrics. So let’s not make perfect the enemy of the good.
I’ve talked to some growth managers who have trouble explaining the idea of event based analytics to their management. That’s crazy. Your management might be incompetent, so email me if that’s you: ivan@yesgraph.com
1. Abstract calls to analytics events.
You want to make adding analytics events really easy. In your code, create an abstraction for logging an event that you can call from anywhere, (web front end, app server back end, mobile client). This helps avoid having vendor specific code peppered across your codebase. This will also make switching vendors much easier and your code easier to read.
On your app server or mobile app it might look really simple:
log_event(some context, the user, stats, etc)
This doesn’t need to be some huge library.
On the front end, you can make a similar call in javascript. Plus you can go further with connect triggered events. I’ve implemented an attribute system so that a click on an element like this:
<div click_event=”signup button”>...</div>
…would trigger a call like this:
log_event(event=”Button Click”,
click_target=”signup button”)
That makes adding front end instrumentation very easy. This whole effort is to make it easy to think about and add instrumentation. If instrumentation is painful, lazy engineers will leave holes. Fun fact: all good engineers are lazy; that’s why they are so fast.
2. Abstract your vendors with Segment or MParticle
Now that your whole codebase is insulated, what happens inside “log_event”?
You should log analytics events using Segment or MParticle. I prefer the former. These services aren’t like Mixpanel, where you feed data and then look at dashboards. They multiplex out the analytics events to different services like Mixpanel and Amplitude.
This lowers the switching costs of trying new tools. It doesn’t require a code change! If you can try a new tool easily, you can move faster and have more agility with your analytics. This also means you aren’t locked-in to a specific vendor.
3. Store you own analytics data
Segment makes this really easy, whether by using their webhooks to store events in your own DB or using their service to send the data to your database directly with “warehouses”.
Storing your data is essential because not every question can be answered with a tool. If Mixpanel can do it, awesome. If not, it’s better to code a solution on your own data than to not answer a question.
Sometimes it takes correlating events with other data you have, like subscription states or other objects in your DB. It could be that a Business Intelligence tool can help do this work for you, but if you’re just starting out, that is unlikely to be your best solution.
If you’re logging events from multiple platforms, syndicating out to Segment and getting everything back in one place with webhooks is technically less work than storing the data yourself first and then syndicating out to segment. For the latter, the biggest headache is working on APIs to ingest front end and mobile client events.
4. Instrument the User Experience
Now that you’ve established your analytics pipeline, you need to add your events. The way to do this is really easy: just pretend you’re a user. Walk through your onboarding and core product and write down what happens. Each event you notice matters.
If you have 10 or fewer, you should probably go into more detail. If you have 50 at the start, it will be hard making sense of them later. This is one reason I don’t like systems that automatically log events, because it’s hard to make sense of the deluge of events. Systems that do this, like Heap, might get better with time.
Note that it is really easy to add events, but this can cause headaches later. So you want to be conscientious about which events you have. The literal strings used as event names unfortunately matter here. So pick a format and decide on the degree of detail. You don’t want to have multiple events like: “User signed-up” and “SIGNUP”.
I like to put all the events in a single file in your code to the degree that is possible so that it’s clear what all the events are. Front end vs back end makes this painful to do 100%.
Sometimes having a high level event with a data attribute is better than lots of events. Let’s say you have a social signup experience using Twitter and Facebook, plus an email signup option. Sometimes you care about the channel but usually you just care about the signup.
So this is better:
{‘event’: ‘SIGNUP CLICKED’, ‘channel’:’Twitter’}{‘event’:‘SIGNUP CLICKED’, ‘channel’:’Facebook’}{‘event’:‘SIGNUP CLICKED’, ‘channel’:’Email’}
…than this:
{‘event’: ‘TWITTER SIGNUP CLICKED’} {‘event’: ‘FACEBOOK SIGNUP CLICKED’} {‘event’: ‘EMAIL SIGNUP CLICKED’}
Similar things are true for web page views, button clicks, and other kinds of events.
Eventually your data team is going to go crazy with the problems here and start versioning their analytics like your database, API, code base. I wouldn’t bother with that effort at the start.
What are some good events? Here are some that come to mind, as I imagine a user walking through some SAAS app:
- viewed blog post
- viewed landing page, with referrer tracking to the blog
- clicked learn-more
- viewed pricing page
- viewed create account page/modal
- entered email in create account form
- create account form submitted
- user signed up
- viewed onboarding step 1
- email sent, (welcome email)
- user created project
- user viewed integration page
- user sent invite
- invite landing page viewed
- invite accepted
- user sent message
- user signed out
- email sent, (subscribe email)
- user subscribed
I could go on. This app isn’t even real and I came up with over a dozen things to track.
5. Product questions compel analytics NOT vice versa
So now you have instrumented events that are getting logged into data systems meant to analyze it. Awesome! So the next step is to look through Mixpanel, right? Wrong!
Start with your product experience and ask questions. Those questions will rely upon your analytics to answer them. Sometimes you might need to add new events to answer the questions. Sometimes you need to write code if the tools aren’t up for it.
The big problem with starting with the tools is that you are immediately biased by what the tool shows you. You aren’t thinking about the truth, but of the buttons and graphs on their dashboard. These are general purpose tools not designed just for you.
Don’t get me wrong: if you can answer a question with a tool like Mixpanel, go for it. But don’t confuse the tool with the goal. Your goal is to make your product fucking awesome. You do that with relentless focus on your users and their experience.
This last one is recurring. You have a question, sometimes add events, find your answer, run an experiment, and measure the results. Do this again and again to make your product better, which is the point of your analytics systems.
I’d love to hear what you think! Try this out, check out YesGraph, and email me: ivan@yesgraph.com.