Two Good Approaches for Implementing Analytics Tags
Reading time: 6 minutes
Good analytics are no longer just a nice-to-have. Your digital analytics are one of your competitive imperatives. Companies that win, will succeed through data driven insights and increasingly through automated intelligent systems.
Front and center in this battle ground are web and mobile analytics. Modern websites and applications track user actions to drive insights and dynamic personalization in a constant game of conversion rate optimization.
To feed an analytics engine, the event stream and state of the app must be transformed into the data model required for analytics. For historical reasons, this is called tagging.
The most familiar Tag Manager is of course Google Tag Manager (GTM). GTM, and many other great analytics tools, give non-developers a means to decide which events to capture by building rules that examine the presentation tier. These rules inject the tagging logic into the web page when it loads. Tools like Optimizely take it one step further and let their users define alternative presentations and dynamically modify the page (via the DOM) before it is presented.
This is like a car dealership installing features into your car; think of tag managers as an aftermarket product.
All good analytics tools have APIs that make it easy to transfer data to them. And, if good practices are employed, sending data to the analytics server with these APIs can be an inexpensive and effective approach.
This is like a feature that is built into a car in the factory.
The Team Factor
Another key consideration is the configuration of multiple teams that are working on the product. It is not uncommon for the application development to be done by one team and the analytics to be siloed in a different team, or even a different company such as an advertising agency. In such a scenario, "after-market" tools have a huge advantage.
Coordinating changes can be problematic with a siloed analytics department. When a new version of the web page is deployed that changes the UI components that the tagging logic references, data may be lost until the tagging team makes the necessary corrections.
The team’s DevOps strategy is also a key consideration. In an environment where a team of developers and designers are developing, testing, deploying and monitoring small frequent updates, the team will likely prefer being in complete control of process. Having a third-party server inject changes into the page could complicate end to end testing, especially if accurate measurement is part of the acceptance criteria.
Also, in an analytically-driven Agile scrum team, the product owner should be one of the biggest consumers of KPIs generated by the app and use hard facts to prioritize the backlog. Stories and chores executed by the team can deliver the features, experiments and analytics in one tight loop.
The Complexity Factor
For the basics like logins and page views (route changes, now-a-days), tagging is a trivial exercise. Common situations that add complexity include:
The application’s features grow.
Multiple experiments can be running simultaneously in many different parts of the application.
Rich user experiences like complex forms, carousels, sliders, drag and drop, swipes and gestures are used.
The user experience spans multiple devices including native mobile.
The insights team demands finer grained behavioral data.
Continuity of analytic reports are required as the app is upgraded.
The analytics teams are siloed from the development team.
As this complexity grows, teams can find they have an expensive maintenance problem on their hands.
Software developers are constantly striving to manage complexity in an efficient and maintainable way. Yet, due to the popularity of "aftermarket" analytics tools, the tagging logic is often not well designed.
A tag manager provides a user interface to allow a user to define a set of rules that take your presentation tier as an input and transform it to a data model that will provide useful insights into users’ behavior, capturing key events like downloading a pdf, watching a video, leveling up on a game or buying a product.
Amount of Change Factor
Another consideration is how much innovation is expected. If the property is essentially stable, then tag managers and "aftermarket" tools are a natural choice. You don’t need developers to run the analytics, because experiments will be simple.
On the other hand, if the team is evolving the product with a build-measure-learn process, then a steady stream of updates can be anticipated. Product owners should be given the freedom to try big experiments and significant pivots could be made at any time. Having the analytics tightly integrated with the application delivery team can be a big win in this scenario.
The complexity of the change is also a factor. With classic A/B Testing, someone needs to develop the A and the B. If the test is as simple as changing the text, color or size of an element, "aftermarket" tools, like Optimizely, are a good fit. Having developer skills would open the experimentation to a wider range of experiments.
Finally, a well-designed interface to an analytics engine will allow you to change where your tags send the data to with a simple configuration change.
If you are taking the tag manager / "aftermarket" approach, then the tagging logic will need to be reimplemented if you change analytics tools. This may be no problem at all if your app is simple.
|Analytics team is separated from the development||Tag Manager|
|A simple app||Tag manager|
|A stable app||Tag manager|
|No changes expected or it’s a simple app||Tag manager|
Learn How Rangle Can Help With Your Analytics
Our built-in custom analytics solutions allow you to measure and then optimize for greater conversions and revenue. Contact us to learn more about our analytics consulting and how we can help you get the most out of your data.