12 August 2026

Server-side tagging is entering a new phase. Here’s why Google’s Floodlight changes matter

In summary

• Server-side tagging is entering a new phase as browser-based measurement becomes increasingly difficult and platforms continue to strengthen their server-side capabilities.
• Google’s latest Floodlight changes address one of the biggest limitations of the previous server-side setup: its continued reliance on the browser, which could create race conditions and contribute to lost conversions.
• Reducing that browser dependency could make server-side Floodlights more reliable and change the recommendation for organisations that previously chose client-side or hybrid implementations.
• The bigger story goes beyond Floodlights. As browser restrictions continue to tighten, server-side tagging is moving from a “nice to have” measurement enhancement towards core infrastructure for maintaining reliable first-party signals.

Our position on server-side Floodlights is changing

Last year, we wrote about whether Floodlight tags should be deployed through Server-Side Google Tag Manager (sGTM).

At the time, our answer was deliberately cautious.

Server-side tagging offered clear benefits around measurement durability, data control and reducing reliance on browser-based tracking. The problem was that a server-managed Floodlight wasn’t really entirely server-side.

The tagging server could decide when a Floodlight should fire, but the user’s browser still had to make the Floodlight request.

That distinction had real implications. It introduced a weak point into the process and was one of the reasons we generally recommended clients retain a client-side Floodlight alongside their server-managed implementation while comparing measurement between the two.

Google is now making changes that could change that recommendation.

Why the browser dependency was a problem

Traditionally, when a conversion occurs, a GA4 event is sent from the browser to the tagging server. The server evaluates the conditions configured in sGTM and determines whether a Floodlight should also fire.

But rather than sending that Floodlight request directly, the server instructs the browser to make another request.

Sometimes, that request doesn’t happen.

For example: If someone clicks a button that triggers a conversion and immediately navigates to another page, the browser may have already navigated away from the current page before the Floodlight request is completed.

The result: The conversion never happens because the floodlight request is never made.

This is what’s known as a race condition, and it was one of the practical limitations we identified with server-managed Floodlights. In our own testing, we often encountered discrepancies between client-side and server-managed Floodlight reporting, particularly around view-through activity.

These issues made it difficult to recommend a pure server side only implementation.

So, what’s changing?

Google is changing the way Floodlights can operate through server-side tagging, reducing the reliance on the browser to complete parts of the measurement process.

If more of that process can happen directly through the server, there are fewer opportunities for browser behaviour, page navigation or network conditions to interrupt the request.

There are security benefits too.

Under the previous setup, the browser ultimately needed to make the Floodlight request, which meant Content Security Policies (CSPs) had to remain open to the external endpoints required for that communication.

Moving more of the logic server-side means organisations can begin to tighten those policies and reduce the number of third-party endpoints the browser needs to communicate with directly. Put simply, fewer open connections means fewer potential security gaps.

It also brings the implementation closer to what most people probably assumed “server-side Floodlights” meant in the first place.

We’re continuing to assess the exact implementation behaviour, including the extent to which Floodlights can operate in a pure server-to-server configuration. However, our initial review suggests some of the constraints that previously made us cautious about server-side Floodlights are beginning to disappear.

For organisations that previously decided against moving Floodlights fully server-side, that’s a good reason to look again.

This is bigger than Floodlights

Floodlight is the immediate reason we’re revisiting this conversation. The bigger issue is what’s happening in the browser.

For years, digital measurement has depended heavily on browsers to collect information and communicate directly with advertising and analytics platforms.

That environment is becoming increasingly restrictive.

Apple’s Intelligent Tracking Prevention and subsequent WebKit privacy changes are a good example. The restrictions aren’t simply about third-party cookies anymore. Browsers are becoming better at identifying tracking behaviour itself, including techniques that may be interpreted as fingerprinting.

For measurement teams, that creates a broader problem.

If your measurement architecture depends on the browser communicating directly with an advertising platform, you’re also depending on the browser continuing to allow that communication to happen in the same way.

That’s becoming harder to guarantee.

If the browser restricts a request, the data may never reach the platform.

Server-side tagging changes that architecture. Instead of the browser communicating independently with multiple analytics and advertising platforms, data can first be sent to an organisation’s own first-party tagging server, which can process the information and route appropriate data onwards from there.

That increasingly makes the tagging server a pivotal part of the measurement process.

Server-side tagging is starting to deliver on its original promise

Server-side tagging has been around for years, and we’ve talked about its benefits around first-party data, measurement durability, privacy controls, performance and data enrichment for a long time.

But compromises remained. Floodlights were a good example of legacy tracking behaviour that hadn’t quite been resolved.

Calling something “server-side” while still requiring the browser to complete a critical part of the process isn’t quite the architecture organisations thought they were getting.

As those dependencies are reduced, server-side tagging starts to look much more like the solution it was originally supposed to be.

The browser collects the interaction. Your infrastructure controls what happens to the data. The server handles the communication with downstream platforms.

That’s a more durable architecture than asking a browser to communicate independently with a growing list of advertising and analytics vendors.

And that’s why the Floodlight update matters beyond Floodlights themselves.

From “nice to have” to measurement infrastructure

For a long time, server-side tagging was relatively easy to categorise as a nice-to-have. If an organisation had the budget, technical capability and enough measurement complexity, there were good reasons to implement it. Otherwise, traditional client-side tagging generally did the job.

That calculation is changing.

Browser restrictions are increasing. Platforms are becoming more dependent on high-quality first-party signals. Automated bidding systems need reliable conversion data. And measurement itself is becoming increasingly dependent on infrastructure that organisations can control.

We’ve seen the same conversation emerging around Google Tag Gateway and Server-Side GTM.

The question isn’t necessarily which tagging product an organisation should choose. The more important question is how measurement infrastructure should be designed to remain reliable over the next five years.

That doesn’t mean everyone should immediately move every Floodlight server-side. There are still implementation considerations, and we want to understand more about Google’s new behaviour before making a blanket recommendation around pure server-to-server Floodlight deployments.

Measurement changes should be tested rather than assumed.

But if your organisation previously decided that the discrepancies, race conditions or hybrid architecture weren’t worth the complexity, it’s probably time to look again.

The technical constraints are changing at the same time as the case for reducing reliance on browser-based measurement is getting stronger.

Put those two things together and the direction becomes much clearer: server-side tagging is moving from a measurement enhancement towards core measurement infrastructure.

Louder’s recommendations

• Revisit previous decisions around server-side Floodlights: If race conditions or browser dependencies were the reason you retained a client-side or hybrid implementation, reassess the architecture as Google’s updated capabilities become available.
• Test before removing existing client-side measurement: Validate conversion volumes, attribution and reporting before making server-only implementations your source of truth.
• Reduce unnecessary browser dependencies: Look beyond Floodlights and identify where critical measurement still relies on direct browser-to-platform communication.
• Treat sGTM as infrastructure, not another tag manager: Its long-term value increasingly comes from becoming the controlled first-party layer between your website and downstream measurement platforms.
• Design for where browser measurement is heading: Privacy protections and tracking restrictions are unlikely to reverse. Build measurement architecture around that reality rather than today’s remaining browser capabilities.

Keep in touch

If you’re reviewing your Floodlight setup, Server-Side GTM implementation or broader measurement architecture, Get in touch with the team at Louder.

Want more Louder content?
Add Louder as a Preferred Source in Google Search to see more of our articles when you search and subscribe to our newsletter to receive the latest industry updates straight to your inbox.