"Our conversion numbers have been quietly dropping for two years, and nothing in our setup changed." If this sounds familiar, the cause might not be in your configuration. It might be the browser itself.
Third-party cookies are disappearing. Safari and Firefox already block them. Chrome has restricted them significantly. Every ad platform's tracking relies — to some degree — on cookies that browsers are progressively eliminating. The result: conversion counts drift downward, attribution gaps widen, and Smart Bidding gets less data to work with.
The fix isn't a single setting change. It's a shift in strategy: from relying on browser-managed cookies to leveraging first-party data — the information your site collects directly from users. This guide explains what breaks, what replaces it, and how to verify your measurement holds up.
1. What breaks when third-party cookies disappear
Third-party cookies are cookies set by domains other than the one the user is visiting. Ad platforms use them to:
- Track users across sites — connecting an ad click on Site A to a conversion on Site B
- Attribute conversions — matching the conversion back to the specific ad that drove it
- Enable remarketing — recognizing returning users for audience targeting
When these cookies are blocked:
| What worked before | What breaks |
|---|---|
| Google Ads cookie links ad click to conversion | Attribution relies on the gclid URL parameter alone (which can be stripped) |
| Meta Pixel cookie identifies the user across visits | Pixel fires but can't link the user to their ad interaction |
| Cross-site remarketing audiences | Audience pools shrink because users can't be identified across sites |
| View-through conversion tracking | Nearly eliminated — no cookie to connect an ad view to a later site visit |
The practical impact varies by platform:
- Google Ads: Least affected, because Google owns the search engine and the ad network, giving it first-party context
- Meta: Significantly affected, because attribution depends on cross-site cookie matching (hence the heavy push toward CAPI)
- Smaller ad platforms: Most affected, with the least infrastructure to compensate
2. The first-party data toolkit
First-party data is information your website collects directly: form submissions, purchase transactions, email addresses, phone numbers, login status. Because it's collected on your domain, it isn't affected by third-party cookie restrictions.
Here are the tools that use first-party data to maintain conversion tracking:
Enhanced Conversions (Google)
Send hashed first-party data (email, phone, name, address) alongside the conversion tag. Google matches this against its own user data to improve attribution accuracy.
What it solves: Fills the gap when the gclid cookie is lost (e.g., cross-device journeys, ITP clearing cookies, long conversion windows).
How to verify: See Enhanced Conversions Verification.
Conversions API / CAPI (Meta)
Send conversion events from your server directly to Meta's API, bypassing the browser entirely. The event includes hashed user data (email, phone, IP, user agent) for matching.
What it solves: Conversion data reaches Meta even when the Pixel is blocked by ad blockers, ITP, or cookie restrictions.
How to verify: See Verify Meta Conversions API.
Server-Side Tagging (Google Tag Manager)
Move tag processing from the user's browser to a server you control. The server-side GTM container receives events from the browser, processes them, and forwards them to ad platforms.
What it solves:
- First-party cookies set by your server (longer-lived than JavaScript-set cookies under ITP)
- Ad blocker bypass (requests go to your domain, not to
googleadservices.com) - Better data control (you decide what leaves your server)
How to verify: See Server-Side GTM Verification.
Google Tag Gateway
Google Tag Gateway serves Google's tracking scripts and data collection endpoints from your own domain (e.g., analytics.yourdomain.com instead of googletagmanager.com). It sits in front of your server-side GTM container.
What it solves:
- Tracking requests look like first-party traffic to browsers and ad blockers
- Cookies set via the gateway are treated as true first-party cookies with longer lifespans
- Available as a one-click setup on Google Cloud (GCP) or via Cloudflare, Akamai, and other CDNs
Measured impact: Advertisers adopting Google Tag Gateway report a 9–18% increase in measured conversions, primarily from recovering signals lost to ad blockers and ITP cookie restrictions.
Relationship to server-side GTM: Tag Gateway is not a replacement for server-side GTM — it's the networking layer that routes requests through your domain to your server-side GTM container. Think of it as the "front door" that makes your server-side setup invisible to browsers.
Platform-Specific Server-Side APIs Beyond Google and Meta
The article focuses on Enhanced Conversions (Google) and CAPI (Meta), but other platforms have equivalent server-side solutions:
- TikTok Events API: Sends conversion events server-to-server, with hashed email/phone matching. Required for TikTok campaigns if your audience has high ad blocker usage.
- LinkedIn Conversions API: Server-side alternative to the LinkedIn Insight Tag. Supports offline conversions and enhanced matching. Launched in 2023 and now recommended alongside the Insight Tag.
- Pinterest API for Conversions: Server-side events for Pinterest campaigns, with deduplication against the Pinterest Tag.
The pattern is universal: every major ad platform now offers a server-side event pathway. If you're building first-party data infrastructure, plan for multi-platform server-side support, not just Google and Meta.
Customer Match / Custom Audiences
Upload customer lists (hashed emails, phone numbers) directly to ad platforms for targeting and measurement. This is a fully first-party-data approach — no cookies involved at all.
What it solves: Remarketing and audience-based measurement without any cookie dependency.
Consent Mode with Modeling
When users decline cookies, Consent Mode tells Google tags to send cookieless pings. Google uses these pings, combined with data from users who did consent, to model the likely number of conversions from the non-consent group.
What it solves: Recovers some of the conversion data lost from users who decline cookies, without violating their choice.
Limitation: Modeled conversions are estimates, not measured values. Accuracy depends on having enough consenting users to build a reliable model.
3. Building a first-party data strategy
The shift to first-party data isn't about implementing one tool. It's about layering multiple signals so your measurement is resilient regardless of what browsers do next.
Priority 1: Capture user identifiers at the conversion point
At the moment of conversion (form submission, purchase), ensure you capture at least one user identifier that can be used for matching:
- Email address (most reliable — used by Enhanced Conversions, CAPI, Customer Match)
- Phone number (secondary, useful for CAPI and Enhanced Conversions)
- gclid / fbclid / other click IDs (still valuable when present, but can't be the only signal)
Priority 2: Implement server-side pathways
Move your most critical conversion tracking to server-side:
- Google Ads: Enhanced Conversions (easiest) or server-side GTM (more control)
- Meta: Conversions API alongside the Pixel (Meta recommends both — "redundant" events are deduplicated)
- GA4: Server-side GTM with a GA4 server-side client
Priority 3: Set first-party cookies from your server
JavaScript-set cookies face increasingly aggressive browser restrictions:
| Browser | JavaScript-set cookie lifespan | Server-set cookie lifespan |
|---|---|---|
| Safari (ITP) | 7 days standard; 24 hours if the domain is classified as a tracker (e.g., domains that primarily redirect to other sites) | Up to the configured expiration (e.g., 1–2 years) |
| Firefox (ETP) | Varies; cross-site cookies blocked by default | Server-set first-party cookies unaffected |
| Chrome | Third-party cookies restricted; first-party JavaScript cookies not yet capped | Server-set first-party cookies unaffected |
The 24-hour cap in Safari is particularly damaging: if a user clicks an ad today and returns tomorrow to convert, the cookie is already gone. Server-set cookies (via HTTP response headers or Google Tag Gateway) bypass this restriction because Safari treats them as true first-party data.
If you're using server-side GTM or Google Tag Gateway, it can set a first-party cookie on your domain that persists across sessions — maintaining user identity for the full conversion window.
Quantified impact of first-party data tools
How much do these tools recover? Based on industry data:
| Tool | Typical conversion recovery |
|---|---|
| Enhanced Conversions (Google) | 5–15% more attributed conversions |
| Conversions API (Meta) | 15–30% more conversions vs. Pixel alone |
| Server-side GTM + Tag Gateway | 9–18% increase in measured conversions |
| Consent Mode with modeling | 5–20% recovery depending on consent rate |
These aren't additive — there's overlap. But a fully implemented first-party data stack (Enhanced Conversions + CAPI + server-side tagging + Consent Mode) typically recovers 20–35% of the conversions that would otherwise be lost to cookie restrictions and ad blockers.
Priority 4: Consent infrastructure
First-party data strategy still requires consent. Implement a consent management platform (CMP) that:
- Captures user consent choices
- Integrates with Google Consent Mode (sets
ad_storageandanalytics_storageparameters) - Allows you to use consented first-party data while respecting declines
4. What this looks like in practice
Here's how a well-implemented first-party data setup handles different user scenarios:
| Scenario | What happens | Data quality |
|---|---|---|
| User accepts cookies, converts | Tag fires normally, gclid + cookie + enhanced conversion data all available | Full attribution |
| User declines cookies, converts | Tag fires in restricted mode (Consent Mode), enhanced conversion data (hashed email) still sent, CAPI sends server-side event | Partial — but email matching recovers most attribution |
| User blocks ads/tracking (ad blocker) | Client-side tags blocked entirely | CAPI (server-side) still sends the event; client-side is lost |
| Cross-device: clicks ad on phone, converts on desktop | Cookie can't connect the two devices | Enhanced Conversions matches the email across devices |
| Long conversion window (clicks today, converts in 30 days) | ITP may have cleared the cookie after 7 days | gclid from URL parameter + enhanced conversion email recovers the match |
Without first-party data tools, scenarios 2–5 all result in lost conversions. With them, most of the data is recoverable.
5. How to verify your first-party data strategy is working
Check 1: Enhanced Conversions diagnostic
In Google Ads → Goals → Conversions → Diagnostics, check the enhanced conversions status. It should show:
- A match rate (percentage of conversions that were matched via enhanced data)
- Data quality indicators for each field (email, phone, name, address)
If the match rate is near zero, your enhanced conversion data isn't being sent or isn't matching.
Check 2: CAPI event match quality (Meta)
In Meta Events Manager, check the Event Match Quality score for your CAPI events. Meta scores it 1–10:
- 7–10: Good — enough parameters for reliable matching
- 4–6: Moderate — add more parameters (email, phone, IP)
- 1–3: Poor — events are arriving but Meta can't match them to users
Check 3: Compare browser-side vs. server-side event counts
If you're running both client-side and server-side tracking (recommended for Meta), compare the event counts:
- If server-side events significantly exceed client-side, your client-side tracking is being blocked by ad blockers or ITP
- If they're roughly equal, most users are seeing both — but the server-side path provides resilience
Check 4: Cookie lifespan audit
Check how long your first-party cookies actually persist:
- In DevTools → Application → Cookies, look at the expiration dates
- JavaScript-set cookies in Safari will show 7-day (or shorter) expirations
- Server-set cookies should show longer expirations (up to the value you configured)
Check 5: Consent Mode verification
Submit a test conversion under three consent states:
- Consent granted: Full tag fires, all data sent
- Consent denied: Tag fires in restricted mode (no cookies, limited data)
- No consent choice yet: Depends on your default settings (check if the tag fires at all)
For each state, verify what data reaches the ad platform using DevTools Network tab.
6. The modeling question: can you trust modeled conversions?
Google's modeled conversions estimate the conversions that would have been measured if cookies weren't restricted. They appear in your reports alongside measured conversions — sometimes without clear distinction.
When to trust them:
- Your consent rate is above ~30% (enough real data to build a reliable model)
- The modeled numbers are directionally consistent with your backend data
- You're using them for trend analysis and bidding optimization, not exact counting
When to be cautious:
- Very low consent rates (below ~10%) — the model has too little data to work with
- When modeled conversions suddenly spike or drop without a corresponding change in your business
- When comparing platform-reported conversions to exact backend transaction counts
The practical approach: use modeled + measured conversions for bidding and optimization (the platforms are designed for this), but use your backend data as the source of truth for revenue reporting.
Frequently asked questions
Q. Do we still need conversion tags if we have server-side tracking? A. Yes, run both. Client-side tags provide real-time signals and support features like dynamic remarketing. Server-side tracking provides resilience. Most platforms recommend redundant implementation — the platforms deduplicate, so you won't double-count.
Q. Is server-side tagging enough to avoid ad blockers entirely? A. Mostly, but not completely. Server-side tagging routes requests through your domain, so standard ad blockers don't block them. However, aggressive privacy tools that block all third-party communication at the DNS level can still interfere.
Q. How much does server-side tagging cost? A. The main cost is the server infrastructure (a Cloud Run or App Engine instance for Google's server-side GTM). Typical cost: $50–$200/month depending on traffic volume. The implementation cost (developer time to set up and maintain) is often larger than the hosting cost.
Q. Our consent rate is very low. What can we do? A. First, review your consent banner — design, timing, and clarity significantly affect opt-in rates. A well-designed banner typically achieves 30–50% consent. Second, maximize the data you capture from consenting users (implement Enhanced Conversions + CAPI). Third, lean on modeled conversions to fill the gap, while using backend data for truth.
Conclusion: first-party data isn't a project — it's the new baseline
The shift from cookie-dependent to first-party-data-based conversion tracking isn't optional. Browsers are making the decision for you. The question isn't whether to adopt these tools, but how quickly and how completely.
The good news: the tools exist and are mature. Enhanced Conversions, CAPI, server-side tagging, and Consent Mode with modeling cover the vast majority of tracking scenarios. The work is implementation and verification — setting it up, then confirming it actually works under all the scenarios your users encounter.
ConversionOK verifies that the conversion signals your site sends — whether client-side tags, enhanced conversion data, or server-side events — actually reach the ad platform. As the measurement landscape shifts toward first-party data, verification becomes more important, not less, because there are more pathways for data to travel and more points where it can silently fail.