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.
This post describes two different approaches to tagging: tag managers and JavaScript implementation.
Tag Managers
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.
JavaScript Implementation
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
A team will be most productive using the tools and processes they know and trust. Tag managers and JavaScript implementation represent very different approaches to define the tagging logic. So, a key question becomes, who are the individuals who are accountable for the tagging logic and what tools are they most productive with?
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.
Assigning the tagging logic to developers and including accurate usage reporting as a definition of done will avoid these coordination issues and potential blind spots. You can also employ strategies that implement the bulk of the instrumentation (tagging logic) in JavaScript and use "aftermarket" tools, for minor touch ups or when the developer team is no longer on the project because the app has stabilized.
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.
Of course, if the team members responsible for tagging are comfortable with the tag managers or other "aftermarket" approaches, these tools may be the best choice for your team. Plus, you may find it less expensive and easier to find people who can configure “aftermarket” tools compared to JavaScript developers.
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.
Now imagine a very complex website with many dozens of screens, sequential work flows and eCommerce. Additionally, there’s a major redesign of the web underway and a requirement to provide consistent analytics across the upgrade path. If the JavaScript developers are also responsible for producing accurate analytics, they can account for the analytics changes in one place. A tag manager would have its tagging rules tightly bound to the "old" presentation tier and would require compatible changes be implemented separately and rolled out simultaneously.
It should also be noted that some analytics tools do a great job making it as simple as possible to get analytics up and running. For example, inspectlet (http://www.inspectlet.com/) claims that "Setup is a breeze, just drop our two lines of javascript into your site and you'll start seeing data in your dashboard instantly."
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.
Lock-In Factor
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.
Conclusion
Tag managers and JavaScript implementation are both excellent choices for implementing tagging logic. Which one you choose depends on your team and your situation.
table[]
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.