Expert Insights

Tag Management Architecture: Marketing Pixel Orchestration

Alban Gérôme, VP, Data & CX Technology Manager at Barclays Bank in London, shares his best practices for orchestrating marketing pixels and building a solid tag management architecture

Alban Gérôme
June 03 · 5 min read

A known struggle for marketers in 2019? Data orchestration. Here are Alban Gérôme's actionable insights on how to manage marketing pixels with an effective TMS architecture.

John Wanamaker, an American merchant from the last century, famously said that he is wasting half of his marketing budget, but he does not know which half! Marketing pixels help marketers lower the cost of acquisition of customers by targeting them better.

What are marketing pixels

Marketing pixels are small fragments of Javascript code. Marketers need a way to deploy and remove these pixels in a timely fashion without Javascript skills. The IT department cannot drop everything to accommodate such constraints. Content Management Systems (CMS) have allowed editorial teams to create articles without HTML skills. A Tag Management System (TMS) lets marketers struggling with code deploy these marketing pixels. Although it is possible to use a TMS without any involvement from IT, IT is not too happy with non-developers injecting code in their carefully crafted and tested code. GDPR has added another layer of requirements that require TMS content governance.

Code injection makes IT crowds shiver. Should a malicious hacker gain control of your TMS, they could capture login details or deface your website.

Why you need to involve your IT department

First of all, IT will need to implement your TMS, and they will need to understand that it will inject code, mostly marketing pixels code, into some of your webpages. IT will often be concerned that your code does not meet the same testing standards as what their code has to meet and cause the web pages to load more slowly or even break entirely. Code injection makes IT crowds shiver. Should a malicious hacker gain control of your TMS, they could capture login details or deface your website. You will need to work with IT and address their concerns, but the governance required here may not be as complicated as you imagine.

GDPR’s impact on your marketing pixels

A page with marketing pixels will also write cookies to your visitors' devices. The EU Cookie Directive of 2011 requires consent from your customers for these cookies. Since marketing pixels leverage cookies, you cannot use these pixels without the consent of your customers. These pixels collect no personally-identifiable data, but GDPR also requires you not to collect that data for longer than necessary. You should be able to explain what your marketing pixels do, why you need them, how long you will need them for, who owns them in your organization, which business or financial KPI each pixel is trying to improve, what is the baseline for that KPI, which cookies these pixels are dropping. I have all this documented in a spreadsheet and I archive all my IT sign-offs for future reference.

How to shrink your TMS footprint with a clear architecture

For a TMS to execute the code for a marketing pixel, you will need to create a rule in your TMS. A rule consists of a set of conditions that will ensure that the pixel fires only if we have the consent of the customer for the cookies the pixel depend upon. The rule will often have additional conditions to ensure that the pixel will only fire on specific web pages, on specific devices, if the customer came from a specific partner website etc. When the condition is met, the TMS will inject the code for one or more marketing pixels. This happens invisibly without the customers' knowledge, but again, the customers are free to withdraw their consent at any time, and the data we collect cannot contain any personally-identifiable data. Now although an organisation can have hundreds of marketing pixels in their TMS, these pixels come from a small number of companies. Typical examples of marketing pixels are DoubleClick Floodlight and AdWords, both from Google. Facebook, Microsoft, Amazon and Quantcast are also fairly common. As a TMS user, you would notice that the code for all pixels from a specific vendor is always the same except for a few parameters that contain different values. You should demonstrate to IT that if all DoubleClick Floodlight pixels code is the same except for a few parameters, providing sign-off for one should be sufficient until Google provides a new type of pixel code. The same goes for the cookies a pixel depends upon, you can document them once for each provider until their code changes. You will need to preview every pixel still before pushing them live, unfortunately.

Although an organization can have hundreds of marketing pixels in their TMS, these pixels come from a small number of companies

Looking at all TMS rules a pattern begins to emerge, metadata that changes very often, template code for your pixel providers that occasionally changes, a generic script that will combine both like a coffee machine blending your coffee powder and water, which rarely changes. The generic script would process all the metadata, execute the conditions, check the consent of the customer, and whenever a condition is met, it generates the full formed pixel URLs and fires the requests. Now, whenever your marketer needs a new pixel from a provider that IT has approved before, all you need is to add the relevant metadata for this new pixel. Should Google decide to change the code for their DoubleClick Floodlight pixel, which may happen because of ITP, you will need to submit this to your IT department for sign-off, but then you only need to modify the template code for the DoubleClick Floodlight pixels and the metadata for these pixels. Your generic code should rarely need to change.

Benefits of a solid TMS implementation

With a classic TMS implementation managing hundreds of rules, your TMS will generate almost as many asset files. This can cause page performance issues. The TMS architecture I presented above would help you shrink the number of TMS files from hundreds to only 4. One is the TMS generic library file; you will need this even without a single piece of content in your TMS. The second one is a JSON file containing all your TMS content metadata. The third one is a Javascript file containing the generic templates, one template for each type of pixel. The last part is the generic script, i.e. the coffee machine. A DMP and an A/B testing tool would load one more TMS file each; they would require proper IT sign-off. This architecture keeps IT happy because requests for new pixels only means adding metadata, not code, at least until an existing provider upgrades their tags or when we need to work with a new provider.

Similar Articles

Five ways ITP 2.1 is impacting your marketing

Diana Daia
May 06 · 3 min read

ITP 2.1 Web Analytics Health Check

Sebastian Mørch
June 04 · 3 min 30 sec read

The 2020 Digital Marketing Glossary

October 11 · 14 min read
Subscribe to newsletter

The latest insights and trends, sent to your inbox

Get informed with no-nonsense marketing and analytics tips and best practices from industry leaders worldwide.