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.
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.
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.
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.
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.