How to Write More Analytics Friendly Code
Why Does Tracking Matter?
Software built for business should be useful to the consumer and valuable to the company that produces it. To optimize software towards these ends, you need a way to track results.
No analytics tool does this out of the box. You can install Google Analytics and see how many monthly visits you get without any additional work, but if you want actionable data, you need to lay some groundwork.
How difficult this task? It depends on the way the app or website is built in the first place. Understanding the need for analytics allows you to make a few small changes to your workflow, without affecting the user experience of your customer.
First, You Need to Decide What to Track
You can track anything and everything, but doing so means you risk creating a firehose of data, overwhelming to the point of uselessness.
Here’s my rule of thumb: If a person enters their credit card or email address anywhere, it’s worth tracking. The credit card points being 100x more valuable. Think subscription activations and checkout carts. For emails, be mindful of account creation and list opt-in.
1.Have Unique URLs for Goals, Even if they are fake
By default, Google Analytics, and other tracking systems use URLs for event tracking. Often times a “thank you” page exists only so the marketing team can measure performance, not for any benefit to the user. Thank you pages can be useful, but many aren’t.
If you don’t want to change the user experience, you can create “fake” landing pages with `GET` variables.
For example, let’s say you have a subscription activation process that takes the user straight to the dashboard, so they can get to work with all the new features they just bought. You have three subscriptions: bronze, silver, and gold. You want to know which subscription people pick.
In this scenario, you could update the subscription process to send them to one of three URLs:
* `/dashboard?subscription=
* `/dashboard?subscription=
* `/dashboard?subscription=gold`
Even though the variables don’t change behavior, they act as a signal to analytics software.
2. Add Unique IDs to Clickable Elements
The second easiest kind of event to track is a click, both links, and buttons. If you are building an application with several distinct but similar actions on a page, make those click elements easily distinguishable. The simplest way is with IDs.
Similar to the last example, what if you have a table with three options, each with an identical ‘select’ button? Tracking which selection people make requires JavaScript selector gymnastics. Instead, if they have unique IDs, tracking becomes a breeze.
3. Everything I Just Said About Buttons, But About Forms
Read 2, but mentally find/replace “click” with “submit” and “button” with “form.”
4. Put UTM Codes on Links From The Outside In
UTM codes, short for “Urchin Tracking Modules,” are a huge boon when it comes to tracking where traffic is coming from, and what they do once they get there. UTM codes allow you to see which traffic sources perform the best. You could be spending equal amounts of resources on SEO and social media, and getting the same number of opt-ins. But, who pays you more? Do they have the same lifetime value? Without tracking UTMs, it’s impossible to know from Google Analytics.
Buffer has a great write up on how to structure your UTMs, And Google has a tool to help you build the URLs.
5. Decouple Tracking From Your Codebase
While it’s good to make your code trackable, you don’t want your code to be responsible for tracking as little as possible. There are several benefits:
* A cleaner codebase.
* Your application that’s easier to test.
* The ability to update analytics & tracking without going through the deployment process.
* If your marketing and production departments are separate, they can both work without blocking one another.
The best tool for this is Google Tag Manager. With Google Tag Manager, you can have a developer embed one (two if you count the separate `<head>` and `<body>` components), and be done. New embeds can be added without any changes to the codebase, and events are tracked via a cloud-based GUI instead of a custom JavaScript.
6. Think Twice Before Building a Single Page Application
Deciding to build a single page application, i.e. structuring your app such that the UI is exclusively handled in JavaScript & HTML, and your backend exclusively delivers an API to said interface, is not a choice to be taken lightly.
Is it a good idea? It depends. “Should you build a single page application or not” is a deep topic that could be the subject of multiple articles. But as far as tracking goes, I’ll say this:
If you build a single page application, you’re going to have a bad time.
One downside is that you must take additional care to re-implement patterns already in place in browsers and HTTP. Hope that React component was worth it.
If you go this route, Google has a guide for integrating your SPA you can read here.
Also be mindful that SPAs don’t work with every tool. For example, Hot jars screen recording and heat mapping is pretty sick but doesn’t work on single page applications.
Wrapping Up
These are a few sticking points that I’ve had to write issue tickets concerning. I’m hoping that by taking the time to write this, I’ve reduced the total time spent writing issue tickets worldwide.