17 March 2025

Floodlights to server-side or not to server-side, that is the question?

In summary

• Floodlight tags deployed via a server-side container can experience measurement challenges, when compared with client side only deployments.
• These measurement challenges can include view-through conversion (VTC) limitations, but also conversion undercounting issues due to a higher likelihood of race condition scenarios
• While server-side deployments offer improved tracking durability and potential enhanced privacy features, they may result in higher conversions discrepancies in reporting when compared to client-side tracking.
• A hybrid approach, using both server-side and client-side methods, combined with match IDs, may provide the best solution by balancing durability and accurate conversion tracking.

Floodlight tags with server side tracking

As digital advertising evolves, many marketers are looking toward server-side tracking to improve data accuracy, bypass browser restrictions, and enhance privacy controls. However, when implementing floodlight tags in a server-side container, advertisers often encounter measurement challenges.

A floodlight tag is a tracking pixel used by Google Marketing Platform, specifically in Campaign Manager 360, to track user interactions on a website. Floodlight tags are part of Google’s suite of tools for advertisers and help to measure the effectiveness of their campaigns by tracking actions such as page visits, conversions (like purchases or sign-ups), or other defined user behaviours.

How server-managed floodlights work

It may be somewhat counter intuitive, but when you implement a floodlight tag via server side Google Tag Manager (GTM), the floodlight request is not actually performed by the tagging server itself.

Instead the role of your tagging server is to control the logic of when and how the request is made. This means that your tagging server will instruct the users browser to make a floodlight request, when certain rules and trigger conditions are satisfied.

In most instances these conditions are met based on an incoming GA4 structured request to your tagging server.

In the example diagram below, a GA4 purchase event is sent to the tagging server, let’s assume the tagging server has been configured to fire a floodlight tag when a purchase event happens, and the purchase is for a specific type of product (a purple widget).

When these conditions are satisfied, in response to the GA4 purchase event request, the tagging server will instruct the users browser to make a subsequent floodlight request.

Race conditions

In the time period between the purchase event arriving at the tagging server, the tagging server responding to the request and instructing the user browser to make a floodlight request, it can take a few couple seconds for the entire process to be completed.

It’s this short period of delay which can lead to what’s known as a race condition.

Why do race conditions happen?

Browser behaviour: Browsers prioritise user navigation over background network requests, meaning analytics or tracking requests may get cut off.

Latency: If the server-side tracking setup is slow, the user can leave the page before the request finishes.

Single-threaded JavaScript execution: The click event and navigation happen almost simultaneously, making it hard to guarantee the Floodlight request fires first.

Louder’s approach to server managed floodlights

At Louder, our traditional approach to date has been to recommend our clients deploy a floodlight tag for each conversion action (with the same advertiser ID, but different group tag and activity tag strings), both in a server side and client side context. Then compare conversion numbers reported to see if there is alignment between the two types of implementation.

In the case of conversion points where a race condition is likely to apply, we’ve recommended our clients utilise a step before or after a button click as the conversion point to minimise under counting of conversions where possible. However this workaround can often come at the expense of conversion accuracy or sometimes is just not feasible, especially if the outbound link leads to an external domain where our client is not able to deploy any tagging.

Despite being aware of these limitations when deploying these floodlight configurations, unfortunately we’ve still often encountered large reported conversion discrepancies between client side and server-side conversions.

Over the last couple of years at different times we’ve raised support requests with Google or consulted with other certified Google partners via the partner forums, but to date we still don’t feel we have all the information we need to determine if firing floodlight tags server-side is really beneficial for our clients.

Discrepancy issues with server managed floodlights

When we drill down into conversion differences between client-side and server-side managed floodlights, often what we find is that the largest conversion gaps apply to view-through conversion (VTC) tracking.

But wait, don’t server-managed floodlights still require client side requests to take place? So shouldn’t that allow for view-through conversion reporting? In theory, yes it should, but in practice it appears there are some additional differences. We don’t fully understand what they are yet, but we have a couple of hypothesis as to what could be going on.

Attribution with browser-based cookies

The first theory is around Google’s attribution system which relies on browser-based cookies such as (FLC, IDE and possibly a couple of others) to link ad impressions to conversions. However, server configurations may fail to attach all the necessary tracking cookies or perhaps there is some disruption to Google’s expected flow of data? As a result there is missing or incomplete view-through conversion (VTC) tracking data.

Modelled data

The second theory relates to modelled data. We know that Google uses modelled data for view-through conversion (VTC) reporting, especially in environments where direct attribution is limited due to cookie restrictions, privacy policies, or ad blockers are present. If floodlights are deployed server side, there may be important browser based signals that are missing in these requests, which Google uses to inform and model view-through conversion activity. As a result of these missing input signals, it’s possible that Google is not able to provide this modelled data, hence the super low volume of reported view-through conversion activity we see for server-side deployed floodlights.

Third party cookies haven’t gone away yet

It’s also quite possible that Google was aware of these server-side floodlight conversion reporting limitations, but didn’t see an immediate need to prioritise fixing them because Google had planned to phase out third party cookies already. But due to multiple push-backs on the original third party cookie deprecation deadline and some legal challenges launched in different jurisdictions around the world, as of the time this article is being written (March 2025), the humble third party cookie is still with us - just!

Therefore its conceivable the engineering teams at Google may not have prioritised fixing view-through conversion reporting for server-managed floodlights, simply because not even they thought we’d still be dealing with third party cookies still!

Instead their focus is likely to have been around prioritising feature enablement based on Google’s privacy sandbox initiative (which was designed to replace the third party cookie dependence).

Server-side vs. client-side floodlights

The table below summarises some of the benefits of each respective deployment type based on what we know about each right now and may help you evaluate which is the right approach for your business.

Scenario	Client-side floodlight	Server-side floodlight
View-through conversions (VTC)	✅ Required for tracking impressions	❌ Does not work properly
Click-based conversions (CTC)	✅ Works	✅ Works
Conversion where race condition could occur	✅ Works (subject to implementation)	❌ Measurement challenges will require careful consideration
Bypass ad blockers	❌ Often blocked	✅ Works (fires from the server)
First-party data enhancement	❌ Limited to what browser sends	✅ Can enrich data with CRM/user info
Privacy control (e.g., GDPR, CCPA)	❌ Google receives all data	✅ Can filter data before sending to Google
Deployment costs	✅ Low cost, easy deployment with tag management solution (TMS)	❌ Costs associated with tag manager infrastructure and added complexity.

Could a hybrid approach work?

Other marketing platforms such as Facebook, TikTok and Snap provide server-side tracking solutions that rely on unique identifiers (such as an event ID) to link and deduplicate user actions across devices and sessions. When setting up these deployments for our clients we’ve found an Event ID is a super helpful way to measure observable conversion uplift. This deployment types often requires using both server and client side managed tagging deployments simultaneously.

Here’s a couple of examples of how their reporting UIs demonstrate this:

Snap

Snap displays a graph with an overlap percentage below it in their event manager reports.

Meta

Meta offers a similar reporting UI, showing event deduplication - based on a supplied event ID.

TikTok

Like Snap and Meta, TikTok’s events manager UI is similar and shows event_id coverage and de-duplication stats.

So does CM360/DV360 and Floodlight reporting offer similar?

Going back to October 2020, Floodlight started to offer a match ID for offline conversion attribution. Although we’ve only recently noticed this field type showing up in GTM and sGTM Floodlight templates and their respective configuration UI’s, as seen in screenshots taken below:

Client side GTM

Server side GTM

Key summary

At this point, we at Louder haven’t yet started tested using match ID with Floodlight tags deployed in sGTM to see how effective it is when used with Floodlights, and to date haven’t seen reporting information like that seen in the social media platforms above.

However in theory if implemented correctly, it could enable a best of both worlds scenario, i.e a client side view-through conversion measurement ability, along with server-side durability and observable click through conversion uplift, and where overlap exists conversion counts are deduplicated.

As of right now though, documentation from Google’s side seems somewhat limited - only briefly mentioning match ID (but not making a recommendation on it’s use cases), we’ve also followed up with some experts at Google to try and seek clarity from their side also. Once we know a bit more and have had time to test this approach out for ourselves, we’ll be sure to provide an updated recommendation.

Get in touch

In the interim if you need help with your server-side tagging solution, please feel free to get in touch with the team at Louder.