AnalyticsMay 31, 202610 min read

Cookieless Tracking for Ecommerce: First-Party Data, Server-Side Events, and Why Your Conversion Numbers Are Wrong

Chrome's third-party cookie deprecation is reshaping ecommerce attribution. Here's what a working cookieless stack looks like — first-party tracking, server-side events, and the conversion gap nobody's reporting honestly.

StoreVitals Team

The third-party cookie has been on a slow march to deprecation for six years. Safari and Firefox removed cross-site cookies years ago; Chrome has now finished its phased rollout and treats third-party cookies as restricted by default for the majority of users. The marketing tooling industry is still adjusting. Most ecommerce stores haven't seriously rebuilt their measurement stack and are operating with reported conversion numbers that are off by 20–60% from reality.

This isn't a privacy editorial. It's a practitioner's guide to what a working ecommerce tracking stack looks like in 2026 without relying on third-party cookies, what the typical conversion measurement gap is, and how to close it.

What Actually Stopped Working

Third-party cookies enabled three things that ecommerce stores depend on:

  1. Cross-domain user identification. A customer clicks a Facebook ad, lands on your store via the Facebook redirect, then purchases. The third-party cookie on facebook.com was how Facebook knew the same person who saw the ad was the one who converted.
  2. Retargeting audiences. Pixels on your product pages dropped third-party cookies. Ad platforms read those cookies on other sites to show your products to people who'd browsed them.
  3. View-through attribution. If a customer saw your display ad on a news site (not your store), the third-party cookie tracked that impression so you could attribute later conversions to it.

All three are now degraded. Facebook's Conversions API and Google's Enhanced Conversions try to reconstruct what's lost via server-side event passing, but the reconstruction is incomplete. The honest answer is: your reported ROAS in Meta and Google Ads is overstated by some platforms (the platforms claim conversions they only loosely attributed) and understated by others (you're not sending enough first-party signal back to the platforms).

The Typical Conversion Measurement Gap

Compare three numbers for the same time period:

  • Conversions reported by Meta Ads Manager
  • Conversions reported by Google Analytics 4 (with Google Ads conversion linker)
  • Conversions in your actual order database (Shopify Orders, etc.)

For most ecommerce stores without a deliberate cookieless tracking strategy, the gaps look like this:

  • Meta Ads: claims 100 conversions. Real attributable: 50–70. Inflated because Meta defaults to a 7-day click + 1-day view attribution window and now has to extrapolate when its third-party cookie data is missing.
  • GA4: reports 80 transactions for paid traffic. Real: 120. Understated because GA4's BigQuery export only captures sessions where cookies survived, and a chunk of mobile Safari and Brave traffic gets attributed as "(direct)" or "(unassigned)".
  • Order database: shows 130 actual paid orders. The truth.

The marketing team optimizes against the GA4 number (under-counted) and the Meta number (over-counted) and ends up making the wrong bid decisions. The CFO sees the Shopify number and asks why the marketing reports don't match.

The Cookieless Stack: What to Build

Layer 1: First-party identifier

You need a stable, first-party identifier that follows a visitor across sessions and devices when possible. Options:

  • Logged-in user ID (best): if a visitor creates an account or logs in, you have a permanent identifier. Push this to GA4 as user_id and to Meta's Conversions API as external_id.
  • Email hash (next best): when an email is captured (newsletter signup, checkout, etc.), SHA-256 hash it and use as identifier. Meta CAPI, Google Enhanced Conversions, and TikTok Events API all accept hashed emails.
  • First-party cookie with UUID: set a first-party cookie at first visit, store a server-side UUID, persist that UUID across sessions. This is what GA4's _ga cookie does, but you can do it yourself for better control.

Layer 2: Server-side event tagging

Browser-side tracking pixels are increasingly blocked (ad blockers, ITP, Safari tracking prevention). Send events server-side from your store backend:

  • Shopify: use Shopify's Customer Events API or Pixel API to push purchase events. For Conversions API, use the official Meta and Google Ads integrations or pipe through a CDP.
  • Custom storefronts: emit a server-side event for every key action (PageView, AddToCart, InitiateCheckout, Purchase). Send to a server-side GTM container or directly to platform APIs.
  • WooCommerce: the Pixel Manager plugin or PixelYourSite Pro now both support server-side Conversions API for Meta and Google.

Layer 3: Match key enrichment

When sending a conversion to Meta CAPI or Google Enhanced Conversions, the more match keys you send, the higher the match rate (and the more accurately the conversion gets attributed). Send all of these when available:

  • Email (SHA-256 hashed)
  • Phone number (SHA-256 hashed, normalized to E.164)
  • First name, last name (hashed, lowercased)
  • City, state, ZIP, country (hashed)
  • External ID (your customer ID, hashed)
  • Client IP and User-Agent (sent as-is, used by platform for additional matching)
  • Click ID (fbclid for Meta, gclid for Google) — capture from URL params at first visit, persist in first-party cookie, send back with conversion

Meta CAPI match rates with just email hash: 40–50%. With email + phone + name + IP + click ID: 80–90%. The match rate directly affects how much of the conversion volume Meta will attribute back to your campaigns.

Layer 4: Click ID capture and persistence

The most common gap. Customers click an ad with ?fbclid=... or ?gclid=..., navigate around your site for a few minutes, the URL params get lost in client-side navigation, and the click ID is never persisted. When they convert 3 days later, the click ID isn't sent back with the Purchase event, so Meta can't deterministically attribute it.

Fix: at first page load, read the URL params. If fbclid, gclid, ttclid, or twclid are present, persist to a first-party cookie with a 90-day expiry. On every server-side conversion event, read the cookie and include the click ID.

Layer 5: Consent mode

For traffic from regions requiring consent (EU, UK, increasingly Canada and California for certain data types), implement Google Consent Mode v2 and Meta's Consent Mode equivalent. When consent is denied, the platforms can still receive aggregated, anonymized event signals and model the missing conversions. Without consent mode, denied-consent users contribute zero signal — they vanish from your reports.

What You Don't Need

Some things that get sold as "cookieless solutions" aren't worth the effort:

  • Browser fingerprinting: Safari and increasingly Chrome are actively blocking fingerprinting. Reliable identification rates are 20–30% and falling. Not worth the legal/privacy complications.
  • UID2 (Unified ID 2.0): the open-source post-cookie identifier from The Trade Desk. Promising but adoption is uneven — works well for The Trade Desk and a few ad partners, not for Meta or Google.
  • FLoC / Topics API: Google's cohort-based targeting. Usable for upper-funnel display advertising but not for ecommerce conversion measurement.

The Server-Side GTM Question

Server-side Google Tag Manager (sGTM) lets you proxy events through your own server (hosted on Google Cloud or self-hosted) before forwarding to ad platforms. Benefits: complete control over what data is sent, ability to enrich events with server-side data (e.g., add the customer's lifetime value to every purchase event), reduced client-side JS load (some tags can be moved entirely server-side), and resistance to ad blockers (the requests go to your domain, not facebook.com or google-analytics.com).

Costs: $50–500/month in Google Cloud hosting depending on traffic volume, or a flat fee with managed providers like Stape ($20–200/mo), Addingwell, Taggrs, or self-hosted on a Hetzner box. Worth it for stores doing >$50K/month in revenue.

Privacy-Friendly Alternatives to GA4

Some stores have moved partially or fully off GA4 because of the cookieless complications. Alternatives in active use:

  • Plausible Analytics, Fathom, Simple Analytics: cookieless by design, GDPR-compliant without consent banners. Lighter analytics features than GA4 but accurate session counts.
  • Matomo (self-hosted or cloud): full-featured GA alternative. Can run cookieless or with consent.
  • PostHog: event-based analytics with optional self-hosting. Captures more product-analytics-style data than GA.
  • Pirsch: European-hosted, GDPR-strict, very lightweight.

For ecommerce specifically, the gap with GA4 is that none of these have native Google Ads integration for bid optimization. So most stores end up running GA4 (for Google Ads), Meta Pixel + CAPI (for Meta Ads), and one additional product-analytics tool of choice. Three tracking stacks, not one.

What to Audit Now

  1. Click ID persistence: open your store in an incognito window. Append ?fbclid=test123&gclid=test456 to a URL. Navigate around the site. Check whether the click IDs are still accessible (via cookies or URL state) when you reach checkout. If not, you're losing them.
  2. CAPI / Enhanced Conversions match rate: in Meta Events Manager and Google Ads, check the match quality score. Below 5/10 means too few match keys are being sent. Below 3/10 is broken.
  3. Conversion gap report: compare your Meta-reported conversions, GA4-reported transactions, and actual Shopify orders for the past 30 days. Quantify the gap.
  4. Consent mode status: if you have any EU traffic, verify Consent Mode v2 is firing properly. Use Google's Tag Assistant to inspect.
  5. Server-side GTM viability: for stores >$50K/month revenue, evaluate moving to sGTM. The 12-month payoff is typically a 10–15% increase in reported (and bid-able) conversions.

The Underlying Truth

The honest version of cookieless tracking is this: nothing fully replaces what third-party cookies did. Some signal is gone for good — particularly view-through attribution and unaided cross-device matching. What's left is a stitched-together stack of first-party data, server-side events, consent-mode modeling, and hashed match keys. Done well, it recovers 80–90% of the signal that was lost. Done poorly, you're looking at 40–60%.

The stores that adapt fastest will have a measurable advantage over the next 2–3 years: their bid algorithms in Meta and Google Ads will get better training data, their lookalike audiences will be more accurate, and their reported ROAS will more closely match reality. Stores that don't adapt will keep wondering why their ad performance "feels" worse than it used to be.

Run a StoreVitals scan. We'll check whether your store has the foundational privacy and tracking infrastructure in place: proper consent banner (if required), first-party tracking setup, cookie security flags (SameSite, Secure, HttpOnly), and the SSL/HSTS configuration that's a prerequisite for any modern tracking stack to work reliably.

cookiesfirst-party dataattributionprivacy

See these issues on your store?

Run a free scan and find out in seconds.

Run Free Scan