Marketing Pixels: How to Deploy Them With Tag Management

Alban Gérôme is the Senior Technical Web Analyst at Legal & General and former VP, Data & CX Technology Manager at Barclays Bank in London. 

He has 12 years' experience in web analytics, mostly as an implementation engineer, of which 9 years using the Adobe stack. He is also a regular speaker at MeasureCamp London, Paris, Berlin, and other European capitals. Featured in the book "Data-Driven Business Transformation" by CDOs Caroline Carruthers and Peter Jackson.

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.

Many business objectives are measured and supported by multiple data dimensions, that often are peripheral to the objective itself. Using machine learning models, we can distill these dimensions based on their importance to a KPI metric.

Why you need to involve your IT department

First of all, IT will need to implement your marketing tag management, 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.

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.

The unique selling point in CRMint is reusable “workers” and a graphical user interface to better design and understand the pipeline, steps and job functions. From a personal side, there’s an integrated worker for importing the created dimensions back into the Google Analytics interface, so you don’t have to develop a Measurement Protocol or API service. Amazing stuff.

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.