One of the clients we work for at Adwise uses Criteo for some of their advertising. And just like all the other advertising vendors, Criteo has a tracking script to measure and report campaign performance. Not all advertising vendors also have a Tag template for Google server-side GTM though. So I was happily surprised that Criteo does. Unfortunately, that Tag template has some dangerous flaws that prompted me to (heavily) modify it.
In this blog post, I’ll explain what’s wrong with Criteo’s template and I’ll share my updated version.
[2023-03-10] Update: After having a conversation with Criteo, I learned that my original template was using a timestamp in local time instead of UTC. Unfortunately, this was not made clear in the documentation. As a result, I have updated my code to use a UNIX timestamp in seconds that is based on UTC.
The official Criteo Tag Template
If you search in the Google Tag Template gallery, you’ll quickly find the official Criteo Tag template. The fact that it is in the official gallery gives it a bit of (false) credibility.
So you might be wondering what is wrong with the official Criteo template. Let me show you. The code in the screenshot below is from the official template:
On line 22 they use the method
getAllEventData() to get all the data from the Event Data Object and store it in the variable
Then on lines 32 to 39 they remove some data if the user has a specific cookie. This is the cookie ‘crto_is_user_optout’ (not visible in the screenshot). Note that this only works if you have a Criteo opt-out cookie. It does not work with your own Consent Management Platform, such as Cookiebot or OneTrust.
On line 41 the entire Event Data Object is stringified and eventually on line 44 the function is called that sends all the data to Criteo.
Because the official template uses
getAllEventData()they will likely collect more data than needed. It's almost as if they want you to accidentally breach the GDPR…
Of course, you could be very strict by making sure that the Event Data Object only contains data that Criteo needs when the tag is fired. So I reached out to Criteo about this and asked them if they have any documentation about what data is expected in the Event Data Object. After a quite lengthy email conversation, this is the most helpful response I got:
In the case the customer wants to use the GTM S2S template we get all the details of the events from the default function getAllEventData … Once an event is triggered we get all the information from GTM.
They’re just repeating my point. Not helpful at all. Time for plan B!
My unofficial Criteo Tag Template
Criteo does have documentation about their server-to-server endpoint. (https://guides.criteotilt.com/onetag/s2s/) One interesting distinction between this documentation and the official template above is that the endpoint differs. Criteo’s template sends data to
https://sslwidget.criteo.com/gtm/event?mappingId=..., while their documentation mentions
I heavily modded the official template to do three things:
- Send data to the endpoint as described in the documentation.
- Translate standard GA4 event names to Criteo event names.
- Only include the data that Criteo needs.
These standard GA4 event names are mapped to Criteo events:
|page_view when page_location is /||viewHome|
|page_view for all other pages||viewPage|
The new tag should be triggered on these events:
How to use this template
- Download the template.tpl from GitHub
- Create a new custom Tag template in your server-side Google Tag Manager container, and import the template.tpl file
- Add a new Tag using the template you just added and configure it correctly. You might need to reach out to your contact at Criteo to get all the necessary data, such as Application ID and caller ID.
Just as with the official template from Criteo, you’ll also need to add the “Criteo User Identification” Tag template to your web container. You can find this template in the Community Gallery for web containers.