Tag Management is something we know and some people even love. Traditionally it’s been added to websites via a single line of JavaScript commonly being embedded in the header or body of the web page, but recent advancements show this isn’t the only way – but should you switch? Should the development staff get to make that call exclusively? To help answer that, let’s look at the three scenarios.
Possible Install Method 1: Client Side
In a client side (browser) configuration, the user’s machine loads the tag management JavaScript, and conditionally loads and fires off all the various tags inside of the container, in the hope of sparing the marketers from requiring the development staff for minor changes. This is the default configuration for Google Tag Manager, Adobe Launch and Tealium iQ.
There are tradeoffs of course – namely you have to serve a bunch of extra logic over the wire which inflates page size. This process can degrade page performance. On the measurement side of things, because everything is happening on the user’s browser, that means adblockers or built in privacy protections in browsers such as Safari, Brave and Firefox can halt or modify the request, skew or preventing data collection entirely.
None of the cons are desired of course, but what of the benefits?
This installation method can be leveraged on pages with high amounts of caching and can easily interaction with the Document Object Model (DOM) via CSS Selectors in order to track user interaction. Since the logic is loaded and executed on the user’s browser that means that there is less load on your server infrastructure – which may save costs.
Further, because it’s integrated at the page level, with proper ordering of logic, it can interface with the a consent management framework so that you can be in compliance with various regulations you may be subject to (such as Europes General Data Protection Regulation). These platforms are normally classified as Data Processors, however it’s important to see if that designation is correct for each of the regulations you may be subject to.
Lastly, these platforms are often positioned in a way that marketers may be able to make simple changes without development staff support (not that I recommend this).
Recommended
- When required to work with Consent Management prior to data collection
- When the website makes heavy use of Caching
- When technical resourcing is limited
- When needing to use tags which rely on 3rd party cookies (Remarketing)
Avoid
- When page performance is critical
- When concerned about data collection quality
Investigate
- Consent Requirements and how the platform may interact with them
- Regulatory requirements
Possible Install Method 2: Server Side
Over the past few years we’ve seen an increase in server-side tag management. In this configuration the website talks to a service (such as Tealium EventStream, Segment, Adobe Launch Server-Side Forwarding, or Google Tag Manager-Server Side) which then routes the inbound data to one or more multiple endpoints (tags). Each platform is different, some use JavaScript to power this data flow, and some work off the web or application server directly.
As far as advantages, typically such an install configuration means less JavaScript being executed on the client, which normally results in a page performance benefit. If you wish to track user interactions, you’ll still need some JavaScript to handle this use case, but it can dramatically less than loading everything on the browser.
Further, because the third party tags are not being called from the browser – that means built in browser behavior or extensions are less likely to affect data collection, potentially increasing the amount of data collected. A further advantage is that it can lessen the possibility of data leaking to vendors without knowledge as everything will require a direct mapping to the vendor tag, and the vendor tag lacks access to the user’s browser window.
Some of the trade offs here may require large scale changes to how you serve pages to users. For example, if you have the application server send the data, then the application server can’t benefit from caching as much, which likely means you need a more scalable architecture. If you have JavaScript call a web-service, you can still take advantage of caching, but still are effectively expanding the infrastructure of the website by at least one additional layer which will require ongoing configuration and support. In general depending on the exact configuration and install method used there can be a sizable increase in ongoing cost over a client side installation.
There are four conditions that need heavy consideration even after accounting for the above:
Infrastructure
Depending on platform you may end up responsible for infrastructure setup and maintenance. Google’s solution for example, requires some knowledge of Google Cloud Platform at minimum. While this may not be a heavy lift if your organization already leverages Google Cloud Platform, it can be a learning curve for organizations who haven’t already invested in training for the cloud.
It is critical to understand the mechanics here because running on the cloud means you may end managing the servers, the load balancer, the DNS (Domain Name Server) configuration and so on. If the configuration is incorrect the servers may be unable to keep up with demand, and thus data collection will cease entirely until demand drops or the situation is otherwise resolved. If this isn’t something that you’re comfortable with you’d either need to hire staff with the skills, train existing staff with the skills or select a platform where the majority of the architecture is managed (which often comes with a sizable increase in cost of operation).
If you choose to integrate at the application server you may run into issues with consent (see below). You additionally may incur issues with the tight coupling of the server calls to the tag manager with whatever existing deployment release timeline may already be in place. This can ultimately result in making it difficult to make changes / add new fields by having to work inside a preexisting development pipeline. Prior to picking this you should be very aware of the impact to staffing and development timelines such a choice may impose on the organizations development staff.
Debugging
As far as debugging goes with the client side solution above, it’s easy to see all the network traffic from the browsers developer tools. This isn’t the case in server side tag management. Depending on the architecture involved debugging may ultimately extend beyond the client side tools, into server logs on one or more layers of architecture in order to troubleshoot why the destination platform isn’t getting data properly. Due to this, this often means that whomever is doing the troubleshooting will need access to layers of your network they wouldn’t require with a client side setup. Depending on your vertical and regulatory requirements this may be a heavy lift as it may require clearance from the organizations security team.
Working with server configurations and logs is a different skill set from the JavaScript/CSS based client side implementation, and the skills may not be easily transferable. I would urge caution in assuming that existing web development staff can / will easily be able to adapt to a server side methodology.
Consent Requirements
It is worth noting that just because the logic occurs on a server does not excuse someone from consent requirements required by regulation. In such a scenario you may be forced to favor specific install mechanics such as calling a web service, in order to conditionally call them based on consent choices.
Depending on the endpoint of the tag manager, you may be subject to additional regulation due to data localization (or other) requirements. Phrased another way switching which layer you do data collection on, may subject you to additional regulation requirements. This should be investigated prior to a technical decision to refactor a tag management solution.
Vendor Support
It is worth mentioning that just because you decide to leverage server side tag management does not mean all the vendors you may be using support a server to server integration. In such a scenario the organization will be required to review each vendor and when determined they can’t move server side, determine if client side data collection is still viable, if it’s worth the effort to build out a server to server integration, or to cease use of the vendor entirely.
Recommended
- When page performance is a major concern
- When data security is a concern
- When you want to maximize data collection
Avoid
- When technical staff / support is limited
Investigate
- Consent Requirements and how the desired platform may interact with them (this may force specific installation methods)
- Regulatory requirements
- If a Hybrid install method is needed due to UX measurement or Remarketing efforts.
Possible Install Method 3: Edge Tagging
Edge tagging is the newest integration method you may hear about. In this scenario use of an edge layer (such as Content Delivery Network) is leveraged to send data to destination vendors, and set the correct cookie(s) required as part of the effort to deliver the page to the end user.
This combines some of the benefits of server side data collection while piggy backing on existing infrastructure for a process that already occurs naturally as part of rendering the page on the user’s device. So by design you get a performance boost due to less JavaScript being served, and increased data collection due to a wider array of supported traffic. You may ultimately still rely on smaller JavaScript files for tracking user interaction, but the overall weight should be lower than in a fully client side implementation.
You also get some of the negatives of both implementation methods. For example, such an implementation method may require learning specific Content Delivery Network logic or processing. Debugging the data flow may be more difficult and occur over multiple layers. You may end up needing to learn cloud mechanics like in the server side example, rather than rely on anything related to the client side implementation so a learning curve is likely going to apply to staff making the jump from a client side configuration.
Most of the considerations outlined above for server-side implementation are echoed here, but this next section is what I consider the most important with this implementation method.
Consent
Obtaining consent for data collection is important (and required by law in several regions). In my opinion edge style tagging is incompatible with Opt-In regulation, because the connection to the vendors occurs prior to the page being served to the user (thus before they can consent). Thus, by the time the user can consent, it is already too late and the relevant cookies may have already been placed. While I am not a lawyer, I can only take this to mean it is incompatible with regulations which require the user to consent prior to data collection.
Recommend
- When page performance is a major concern
- When data security is a concern
- When you want to maximize data collection
Avoid
- When technical staff / support is limited
- When not using a Edge platform
Investigate
- Consent Requirements (I believe it is not compatible with Opt-In regulation, consult your legal team).
- Regulatory requirements
- If a Hybrid install method is needed due to UX measurement or Remarketing efforts.
Bringing it all together
There are multiple ways to implement tagging as I have shown above, but as I’ve tried to call out in each, there are trade offs which can affect ongoing costs, infrastructure changes, staffing changes and legal liability in multiple areas of a organization. It is now critical that the technology staff no longer make these decisions in a vacuum. While it may seem like a technical only decision to move data collection from one layer to another, there are downstream impacts in certain configurations that may ultimately increase risk and legal liability for the organization as a whole.
You want to be aware of the total cost of ownership, and what a proposed design may mean from a regulatory compliance point of view prior to investing into the development of a specific platform implementation. I strongly suggest looking at tagging from multiple angles ahead of any effort, to ensure you make decisions with eyes open in order to avoid being blind sided by regulation infractions after the fact.
One can no longer simply change tagging without affecting other areas of the business in the majority of scenarios.