How we migrated 130 media tags to the server - and how it all turned out
With the rise of server-side measurement, we are increasingly implementing server-side tracking for our clients not only for analytics, but also for advertising platforms. In this article, I want to share our experience with a server-side implementation of media tags for a larger client - what we learned along the way, which templates we used, and what to watch out for.
The client we worked with already has part of their infrastructure running on Google Cloud Platform. Their server-side GTM runs on Cloud Run, and hits from front-end GTM containers are routed to it (the client measures traffic across multiple domains).
The main migration of GA4 360 to server-side GTM had already been completed earlier. The next step was a server-side implementation for advertising platforms: Google Ads, Facebook, Sklik, and Bing.
There were several reasons for migrating the media tags:
• speeding up the website by moving media tags to the server (i.e. a better customer experience)
• security - having control over what data individual scripts send from the website
• preparing, for consented users, the setup for sending personal data and enriching it on the server
In theory, this sounded like a breeze. Google Ads, Facebook, and Bing all have server-side templates. GA4 data is already flowing to the server, so we can use those events to trigger media tags. It should be just a matter of clicking things together - simply mirroring the tags on the server. Except it wasn’t :)
A bit of context:
At the time of the migration, the two main GTM containers contained:
• 100 GA4 tags
• 250 media tags
• all of this was spread across 7 top-level products
• divided into 50 product groups
• which were further split into 95 individual products :)
All front-end GTM containers were sending data to a single shared server-side GTM container. This meant that the media tags didn’t just need to be moved - they needed to be properly collected from multiple sources, with their triggers and naming consolidated, and then mapped to the correct conversions in each advertising platform.
Facebook: Hybrid CAPI setup
There were originally 54 Facebook tags. Together with the marketing team, we agreed to consolidate them as much as possible into a smaller number of more generic events - this was fully sufficient for campaign setup. The goal was simplification. The catch is that Facebook thrives on data - and from multiple sources.
The client agreed to run the Facebook pixel both in the browser and on the server - a so-called hybrid setup. What does that mean, and why does it make sense?
• When the pixel runs in the browser, it loads the Facebook library on the front end and collects a large amount of user information, including data gathered automatically in the background.
• When you trigger it on the server, it depends entirely on what data you pass to it. This approach is more secure and less sensitive to ad blockers.
What this looks like in practice:
1. From the browser, an event (e.g. page_view) s sent directly to Facebook. It must contain an event_id – for example, a combination of a timestamp and a random number (we generate this in the front-end GTM using a STAPE template).
This variable has its place in the template under the More Settings section.
2. The same trigger simultaneously sends an event (e.g. a GA4 event) to the server - with the same event_id (passed as an event variable).
3. From the server, the same event is then sent to Facebook using the STAPE Facebook template. The Event ID is set in the Server Event Data Override section.
→ Facebook deduplicates events automatically. If the same event arrives from both sides with the same event_id, Facebook keeps the browser event. If the browser event is missing, the server event is used instead.
The migration looked simple on paper, but in reality it required a manual review of all 54 tags - deciding what to merge, what to keep, what to rename, and what to forward to the server.
In some cases, we had to:
• unify naming across the two main GTM containers,
• create dedicated triggers for the server, or
• send so-called transport tags (if you use a GA4 data stream to pass data to the server).
Imagine that you trigger media remarketing on gtm_consent_update. But this event is not sent to GA4, so you can’t access it on the server. Transport tags are GA4 events sent to the server purely to trigger media tags (they don’t contain the full set of parameters).
We labeled all of these with the same name, for example sgtm_transport_gtmConsentUpdate. On the server, we used them as triggers for media scripts, while at the same time excluding them from firing the GA4 Event Data tag.
🛑 But watch out: for an event like this is the first one in a session, it can carry session source / medium. And if you exclude it from GA, you can end up with “(not set)” in attribution.
Hard-earned lessons :) Practical tips:
• Be very strict about which parameters you forward.
• For example, you probably don’t want to store event_id in GA or BigQuery - exclude it using transformations.
• On the other hand, some parameters can cause a tag to fail (for example, lead_id, or Facebook’s contents parameter incorrectly sent as an object instead of an array).
• Always check the Outgoing request in debug mode to make sure nothing is throwing an error. Server-side debug isn’t as “talkative” as front-end debug, so issues can be much easier to miss.
If your hybrid FB CAPI setup is configured correctly, you’ll start seeing a light-blue line next to individual events in Facebook Events Manager, indicating data that came from the server. The image below shows an example of a perfect outcome that meets Facebook’s highest requirements - more events are being sent from the server than from the browser, deduplication works, and it’s a thing of beauty :)
Here we’re looking at a form submission event, where ad blockers are very commonly involved. This is where the server-side approach really shines. In addition, Facebook can use not only the event_id for deduplication, but also extra data such as hashed email or phone number (if sending personal data is allowed, we strongly recommend doing so - Facebook has an excellent match rate especially with phone numbers). I’ve seen cases where there were many times more browser events than server events, because the server tag in GTM was blocked due to consent (?), along with a few other quirks.
In the end, with this migration we landed at 33 events successfully deduplicated in a hybrid CAPI setup.
Google Ads
In parallel with the Facebook rollout, we also worked on implementing Google Ads and Sklik. Google Ads and Sklik had a completely different structure compared to Facebook tags - and there were significantly more of them. For Google Ads, there were 72 tags, and the same number for Sklik. Once again, we went through a review cycle with the marketing team: which events to keep, which to merge, and which ones to add after all. This time, we actually went in the opposite direction, and the final number of tags ended up being higher.
For Google Ads and Sklik, no deduplication is needed - the tags are fired either from the browser or from the server.
Sklik
At the time of the migration, Sklik did not have an official server-side template. The team at Optimics created one for the client and later made it publicly available. The template is easy to use, and its setup is no more complex than on the front end.
Bing
Compared to the front-end version, the Bing server-side template includes a wealth of information (including e-commerce data) that you can send to the advertising platform. However, the only required fields are the system ID (UET Tag ID) and the event name.
Consent
And what about consent? The STAPE Facebook template includes an option to specify whether you are sending only consented data to the server, or whether you want the template itself to respect the consent parameter.
Google Ads on the server inherit the Consent Mode parameters from the front end, meaning they pass information to Google about whether the data can or cannot be used.
The Sklik template by Optimics has Consent Mode integration built in.
In the Bing server-side template, there was initially no explicit indication of how consent was handled. We contacted the template author, who promised to add this information - and did. In practice, the tag is now sent together with an explicit consent or no-consent parameter.
Summary
This was not a technically complex migration, but it required a lot of testing and attention to detail.
For each tag, we had to verify that the server-side trigger fired the tag correctly - otherwise, marketing would have lost conversions.
At the time of the migration, Sklik did not have an official server-side template. The team at Optimics created one for the client and later made it publicly available (link).
Sklik, Bing, and the remaining tags were then taken over by the client’s lead analyst - a big thank-you to him and the entire marketing team for their great collaboration and support. After several months of testing and deep-diving into tag configurations, I was even dreaming about tags, and I was more than happy to hand the project over.
List of used templates + links
Facebook Conversion API by STAPE (server tag)
Unique Event ID (front-end variable)
Google Ads Conversion Linker + Conversion Tracking (server standard tags)
Sklik template by Optimics (server tag)
Bing template (server tag)
Server-side migration may feel like a routine task these days - but trust us, it can still be quite a ride :)
