Server-Side Tracking and Consent Mode v2: Data Quality in 2026
What server-side tagging gives you, how it differs from Google tag gateway, how Consent Mode v2 works, and where to start so Smart Bidding gets clean data.
AdsConcept teamGoogle Partner · Google Ads practitioners
In short
- Conversion data isn’t lost because of the “death of cookies”: in 2025, Chrome walked back its plan to disable third-party cookies. The losses come from blockers, Safari and Firefox restrictions, declined consent and tagging errors.
- Data protection works in layers: clean tagging and Consent Mode v2, enhanced conversions, offline conversion import from your CRM, and only then Google tag gateway or server-side GTM.
- Server-side tracking gives you control over your data, longer-lived first-party cookies and fewer third-party scripts, but it doesn’t bypass user consent and it doesn’t fix poorly designed events.
- Consent Mode v2 is required for traffic from the EEA, the UK and Switzerland. Advanced mode enables conversion modeling for users who decline cookies.
- Data quality isn’t a one-time setup. It’s a monthly check.
A few years ago, the market was bracing for the “end of cookies,” and server-side tagging was sold as the cure. In 2025, Google decided not to deprecate third-party cookies in Chrome and wound down most of the Privacy Sandbox technologies. Yet data loss didn’t go anywhere, because it was never just about Chrome.
Let’s look at where the losses actually come from, what server-side tracking does about them, and where you can do perfectly well without it.
Where data gets lost
- Ad and tracker blockers. Browser extensions, and some browsers by default, block requests to well-known analytics and advertising domains.
- Safari and Firefox restrictions. Safari limits the lifetime of cookies set via JavaScript and, in private browsing, may strip known tracking parameters from URLs. Someone clicks your ad on an iPhone, comes back a week later, and the link to the click is already gone.
- Declined consent. If you get traffic from the EEA and a visitor declines cookies, your tags can’t store identifiers.
- Technical errors. A redirect that strips the GCLID, a form hosted on a third-party service that doesn’t pass parameters, a payment gateway that “breaks” the session, duplicate tags.
- Cross-device journeys. The click happens on a phone, the lead form is submitted from a laptop. Without enhanced conversions, that conversion often isn’t attributed to the ad.
For Smart Bidding, every lost conversion is a signal that “this click didn’t work.” The algorithm lowers bids on the audiences and queries that are actually driving sales.
Layers of data protection
We build measurement from simple to complex. There’s no point skipping the lower layers to get to the upper ones.
| Layer | What it is | What it solves | What it doesn’t solve |
|---|---|---|---|
| 1. Clean tagging and Consent Mode v2 | Google tag or GTM, correct events, a consent banner | Duplicates, event errors, legally sound data collection | Blockers, Safari restrictions |
| 2. Enhanced conversions | Hashed email or phone number sent with the conversion | Cross-device conversions, part of the cookie-related losses | Losses when the tag is blocked entirely |
| 3. Offline conversion import from your CRM | Sending qualified leads and sales to Google Ads | Optimizing for real sales instead of form fills | Losses at the website level |
| 4. Google tag gateway | The Google tag loads from your domain via a CDN or load balancer | Part of the blocking of Google domains, with no separate server | Data processing and enrichment |
| 5. Server-side GTM | Your own server container that receives and forwards events | Data control, filtering, longer-lived cookies, sending to multiple platforms | User consent, the quality of the events themselves |
How server-side tagging works
In the classic setup, the visitor’s browser sends data directly to Google Analytics, Google Ads, Meta and other services. Each service means a separate script and a separate request to a third-party domain.
In the server-side setup, the browser sends events to your own endpoint, such as a subdomain or a path on your website. That’s where a Google Tag Manager server container runs, and it:
- Receives events through clients, such as the GA4 client.
- Processes them: strips personal data from URLs, adds data from your database (margin, customer status), and filters out bots and test events.
- Forwards them to GA4, Google Ads, the Meta Conversions API and other platforms, now from the server.
- Sets first-party cookies through an HTTP response from your domain, which makes them longer-lived than cookies set by a script.
An important technical detail for Safari: for server-set cookies to truly count as first-party, the server container needs to run on the same infrastructure as the website or be reachable through a path on the main domain. If the subdomain points to completely different IP addresses, Safari may apply the same restrictions it applies to script-set cookies.
What you need to launch
- a server container in GTM;
- hosting: Google Cloud Run or a managed server-side GTM service;
- a custom domain or path configured for the container;
- web tags reconfigured to send data to the server container;
- GA4, Google Ads and other platform tags moved into the server container;
- monitoring: a server container is infrastructure, and it needs to be watched.
Hosting is a monthly cost, and the amount depends on your traffic. That’s why we calculate whether the gain in data accuracy pays off for your specific volume.
What server-side doesn’t do
This is where most of the myths live, so let’s be direct:
- It doesn’t bypass consent. If someone has declined advertising cookies, the server container has to respect that decision just like the browser one does.
- It doesn’t fix bad events. If a “purchase” event fires twice in the browser, the server will faithfully forward both.
- It doesn’t bring back every blocked user. Some blockers work not only by domain but also by request patterns.
- It doesn’t replace enhanced conversions or offline conversion import. These are different mechanisms that complement each other.
Google tag gateway: the lighter option
Google tag gateway for advertisers lets you load the Google tag from your own domain instead of Google’s domains. It’s set up through a CDN, such as Cloudflare, or your own load balancer, and turned on in your Google tag settings.
How it differs from server-side GTM: there’s no separate server and no data processing or enrichment. It’s a way to make the standard tag more resilient with minimal effort. For many small and mid-sized businesses, it’s a sensible first step before full server-side tagging.
Consent Mode v2
Consent Mode passes the user’s cookie choices to Google tags. Version 2 uses four parameters:
ad_storage— storage of advertising cookies;analytics_storage— storage of analytics cookies;ad_user_data— consent to send user data to Google for advertising;ad_personalization— consent to personalized advertising and remarketing.
For traffic from the EEA, the UK and Switzerland, Consent Mode v2 is required to keep measurement, remarketing and personalization working. For details, see Google’s help article on consent mode.
Basic and advanced modes
| Basic mode | Advanced mode | |
|---|---|---|
| When tags load | Only after consent | Immediately, with consent set to “denied” by default |
| What’s sent without consent | Nothing | Cookieless pings for modeling |
| Conversion modeling | General model | Advertiser-specific model based on your site’s data |
| Who chooses it | Businesses taking the most cautious approach | Businesses that need complete data for Smart Bidding |
What this means for Ukrainian businesses
If your site gets traffic only from Ukraine, Google’s EEA requirement doesn’t formally apply to you. But there are a few caveats:
- e-commerce stores that ship abroad, services for Ukrainians living abroad, travel and education almost always have EEA traffic;
- Ukrainian personal data law also requires a lawful basis for processing and is gradually moving closer to European rules;
- a consent banner and Consent Mode are also about user trust.
Legal assessment should come from a lawyer. Our area is the technical implementation: the consent banner, a certified consent management platform (CMP), and correctly passing consent signals to your tags.
Data quality: what to check every month
- The share of visitors who give consent, and how it changes after banner updates.
- Enhanced conversions diagnostics in Google Ads.
- The status of every conversion action and the absence of duplicates.
- The share of CRM leads that have a GCLID.
- Whether purchase counts in Google Ads, GA4 and your back office match, allowing for attribution differences.
- Self-referrals in GA4: payment gateways and your own domains shouldn’t show up as traffic sources.
- The share of “(not set)” in key GA4 reports.
- Server container health, if you have one: errors, latency, load.
Where to start
- Audit your current measurement. What gets counted, from where, and where the duplicates are.
- A measurement plan. Which events matter, which of them are primary conversions, and what value they carry.
- Consent Mode v2, if you have EEA traffic.
- Enhanced conversions for key actions.
- Offline conversion import from your CRM for lead generation.
- Google tag gateway or server-side GTM, depending on traffic volume, the number of ad platforms and how much data processing you need.
What to do next
Before you talk about servers, open the conversions list in Google Ads and reconcile the last month against your CRM or back office. If the gap is large and unexplained, the problem is most often at layer one, in your tagging, not in the lack of a server container.
If you want to build measurement systematically, the AdsConcept team runs analytics audits and sets up GA4, Google Tag Manager, Consent Mode v2, enhanced conversions, offline conversion import and, where it’s justified, Google tag gateway and server-side GTM.