Easy, but easy to f*ck up. 3 Rules to Setup Analytics Tools correctly.
Feb 19, 2014 · 4 min read · 4,891 views
As a consultant for analytics i see a fair share of integrations of analytics tools. One of the most common mistakes is how people actually track events and conversion goals.
Very often a lot of data is rendered useless because it is confusing or contradicting to each other. If people use several tools. This problem even amplifies more.
The rules for good analytics actions/goals: #1 As few actions as possible #2 Same names in every tool #3 Triggered by the same logic in code
— Andreas Klinger (@andreasklinger)
I summarised my personal opinion in this tweet above. People asked me a few times to go into details - so here are some quick notes.
Btw if you look for a bird-eye view on the whole topic of metrics tools check out my ebook-as-a-mega-blog-post: A Primer on Startup Metrics.
Rule #1: As few actions as possible
You want to add as few events as possible.
“But we need to track so many things”
If you starting out, do yourself the favor and ignore everything that “might be interesting” (optimisation) and focus on the ones that define the core aspects of your product (accounting).
Things will break, the less moving parts you have the more certain you can be that they actually still work and provide meaning.
Protip: use a prefix for temporary events. I use “test_”
Rule #2: Triggered by the same logic in code
The most common mistake is to have analytics events triggered in different parts of the application.
Eg. Google Analytics might receive the event when the user presses the button or visits some page “that should come afterwards” and your custom dashboard pulls the data from the database.
This sound reasonable in the beginning but very soon your application will change a few times, new validations will require more complex forms, etc, etc. Very quickly you have a mess of interdependent logic that will lead to stuff breaking.
My recommendation: Create a analytics helper function that you trigger at the place the actual event happens. Eg in case of a user signup AFTER the user is saved. If you send your data to your analytics tool through javascript it’s the job of this helper to make sure the frontend receives the needed information. (eg in rails use gon or flashes - watch out for 301s)
Rule of thumb: If data change happens the event should be triggered at the place the data change happened.
Rule #3: Same names in every tool
One of the biggest mistakes people do is to use different names for kinda-the-same things when they use different tools.
Use the same name, make it the job of the helper to make sure every tool receives the information in the format they need.
Eg Google Analytics might expect “User”, “Signed Up” and Mixpanel might expect “User - Signed Up”
Btw Segment.io is a wrapper for your analytics calls and highly recommendable (they additionally offer features like history import to new tools, etc).
Rule #3.1 Event Names: Be understandable
I - as somebody who has not implemented your events - should be able to understand what each event represents AND in which context of your app it is most likely triggered.
Rule #3.2 Event Names: Be explicit
If a user has been created - this happened If a user just clicked a button - this happened
Eg Newsletter Submitted is not the same as Clicked Newsletter Submit Button
Nothing is more horrible than ambiguous event names.
Btw In almost all cases you will want to use past tense.
That’s it
New post, b/c it’s always the same mistakes “Easy, But Easy To F*ck Up. 3 Rules To Setup Analytics Tools Correctly” http://t.co/S3QerEbEuu
— Andreas Klinger (@andreasklinger)
I hope this primer helps you to set up your events correctly - if you have any questions please feel free to reach out to me via twitter If this post is useful for you please tweet and share it. Thanks
Until then, track on
Andreas