In the excitement of overhauling a site, analytics tracking requirements commonly get overlooked. It’s understandable that the focus is on the shinier, prettier aspects like the design and functionality rather than the less visible (but equally critical) aspects like tracking and measurement. This scenario happens more often than anyone would like to admit:
These are some analytics gotchas that every digital project manager should be aware of…
Analytics tracking is more complex than just enabling it or switching it on. It requires defining which data points will be captured on which pages, how they will be captured, what values get sent to the reports, and having a developer code it accordingly. There should be project phases for:
- Gathering analytics requirements from the business for what should be tracked.
- “We need a report with user IDs.”
- Designing the implementation based on those requirements.
- “Capture the user ID on each page in eVar12.”
- Implementing the analytics tracking code to collect the data.
- s.eVar12=”123456″
Involve the analytics team early in the process to allow sufficient time to design and implement the solution.
Analytics data can be captured on the page load, or on the click of some element. From a scalability and ease of implementation perspective, it is far easier to implement tracking on page load where a new URL is rendered. That’s not to say that onclick tracking should be avoided entirely, but be aware that onclick tracking lends itself to being more complex, more manual, and less scalable.
There are ways to make onclick tracking more scalable by adding CSS elements specifically related to data collection, but the front-end developers would have to be provided with a spec for what additional CSS definitions need to be added to which elements, what the values look like, etc.
Onclick tracking does not happen automatically. All tracking based on click or hover interactions must be custom-defined and custom-coded.
Excessive onclick tracking can have an effect on cost. Certain tools like Adobe Analytics have a pricing model based on server calls. Using Adobe as an example, each Adobe contract specifies a certain amount of allotted server calls per month. A server call happens each time a packet of data is sent to Adobe, which means one server call each time a visitor loads a page, and one server call each time a visitor clicks on a tracked element. By gratuitously adding onclick tracking, it can cause server call overages and additional costs.
Use a data layer and tag management tool. Industry best practice is to have a tool-agnostic data layer on all the pages of your site, and then a tag management tool like Tealium or Adobe Dynamic Tag Manager to map the data layer values to the appropriate variables in your reporting tool.
Resist the urge to track everything. Only track what is essential, and what will yield actionable information. It’s better to have 10 really solid reports with meaningful information, than 100 reports full of “maybe that will be interesting to look at someday” information.