First of all: I am a big fan of the Google Tag Manager (GTM). It’s a great and powerful tool that – with the right training – saves developers a lot of work and can outsource many tasks to marketing.
“Single Point of Failure”
As practical as tag managers (e.g. GTM) are, there is one problem: they represent a “single point of failure” for online attribution. If this fails, e.g. by being blocked, all tracking behind will also fail. Now one could argue that if GTM is blocked, all other trackers will be blocked anyway – this is also true for the most popular trackers like Google Analytics, Facebook, Pinterest, eTracker & Co. But it is not the case for less popular services and tracking solutions, like direct cooperations or custom events.
So there are some smaller affiliate networks or even private programs that are not on the blocking list of Easylist & Co. Also direct cooperations, e.g. our tracking pixel which is available for our partner shop in the course of order data processing (DSGVO), are not on the blocking list. However, if these tracking pixels are integrated via the GTM, they are – so to say – still indirectly blocked.
Unfortunately, it is not possible to determine the extent of the problem or the failure rate in general. It depends on which third-party services you use (whether they are blacklisted) and on the AdBlock rate of the respective site. But Tom Capper provides an interesting analysis with his article “How Much Data Is Missing from Analytics? And Other Analytics Black Holes“. According to his measurements, the tracking deviation when using GTM is about 5%.
Difference between tag-manager vs. tracking-switch
But the so-called “cookie- or tracking switches” have a much greater effect on the online attribution than tag managers.
“A tracking switch is a container that manages multiple code snippets (tracking pixels and scripts) and publishes them according to pre-defined rules. The code of the turnout must be integrated on all sub-pages and internally the possible transaction pixels (e.g. different affiliate pixels, Facebook and AdWords conversion pixels) must be stored. In addition, rules must be defined that determine the hierarchies between the individual pixels (attribution model).”
Source: Projecter-Blog (German)
Similar to the Tag Manager, a tracking switch is a kind of container. While a tag manager is typically integrated on the entire page and primarily controls individual (additional) functions, the tracking switch takes care of the attribution. Its use therefore usually begins BEFORE the website and ends when an action (for example, purchasing) is completed. A tag manager usually does not need a cookie or other functions to recognize a user – a tracking switch does. It is almost always based on some kind of identification feature (cookie, fingerprinting etc.).
The diagram shows that the tracking switch is usually called up before the shop – in other words, the merchant does not use direct links to his offers in his paid channels, but uses tracking links from the tracking provider he works with.
When the tracking switch is called, this is recorded and usually written to a cookie together with the source of the campaigns. If a goal is reached (e.g. purchase), the tracking container of the tracking provider checks whether and where the customer comes from – for this purpose it reads the set cookie. Based on the source, further tracking pixels are then triggered “on-the-fly”.
Admittedly – this representation is an extremely simplified model of reality and represents only the simplest variant based on a 3rd party cookie. In reality, there are several, much more complex solutions to either improve tracking or simply to bypass anti-tracking solutions (e.g. ITP/ETP). These include fingerprinting, local storage, 1st party cookie via JS include or CNAME or server side tracking, master tags etc.
But the basic procedure does not change much – the tracking switch identifies the source and the user and decides on the attribution at the destination based on this information.
What’s the trouble?
There is a variety of tracking solutions that are offered either as a standalone solution or as an additional feature of other products – be it eTracker, DoubleClick, Ingenious Technologies or multichannel providers such as Channelpilot, DataFeedWatch etc. Also, agencies and service providers sometimes provide their own developments. The problem does not even arise with the solutions themselves, but rather with the lack of maintenance or adaptation to new conditions – not by the providers, but by the customers themselves!
After all, a good tracking solution continuously adapts to market conditions and reacts to changes: ITP/ETP, SameSite cookie update, 3rd party cookie problems – just to name a few challenges of the last months. However, not all adjustments can be made exclusively on the part of the tracking service provider – in some cases the customer must also react and, if necessary, revise an already implemented solution. Master tag or CNAME tracking is a good example.
However, many customers shy away from the effort or delay the adjustments with the risk of getting into a “single-point-of-failure” situation – if the tracking switch fails – for example due to privacy blockers – the entire underlying attribution is lost.
What should I do?
As mentioned at the beginning I’m a fan of the Google Tag Manager – in my opinion tracking switches & containers are a good thing, too. BUT: You shouldn’t think that you have to include them only once and then let the tracking provider manage everything. You have to implement recommended updates – even if they are more extensive. Otherwise you risk a creeping loss of tracking quality, which then affects attribution and thus decision-making, especially in paid channels.