First-party tracking after cookie deprecation: a practical setup.

Most business owners I talk to are waiting for a single date. The day Chrome finally kills third-party cookies, the "cookiepocalypse," the moment their tracking is supposed to break. That date has been pushed back so many times it's become a running joke inside the industry, and I understand why it's easy to conclude the whole thing is overblown and there's no urgency to act.

Here's the problem with that thinking. Safari's Intelligent Tracking Prevention has blocked third-party cookies since 2020. Firefox's Enhanced Tracking Protection has done the same since 2019. Between them, depending on your audience, that's commonly somewhere between a quarter and half of your traffic where third-party cookie tracking has already been dead for years. Chrome's timeline is irrelevant to that traffic. It was never going to save it, and waiting for Chrome to move is waiting for a deadline that, for a huge share of your visitors, already passed.

If a third of your conversions are happening in a browser where third-party cookies don't work, you don't have a future problem. You have a current one, and it's been quietly cutting your reported conversions for years.

You're planning for the wrong risk

This matters because it changes what "urgent" means. If you're treating cookie deprecation as a Chrome-shaped cliff edge you'll deal with when Google finally commits to a date, you're optimising for the wrong risk entirely. The actual risk is the one already sitting in your GA4 property and your Google Ads account right now, in the form of under-counted conversions, inflated cost-per-acquisition numbers, and attribution that quietly favours whatever channel happens to survive cookie blocking best. I see this constantly when I run a tracking health check for a new client. The gap between what actually happened and what got measured is rarely subtle.

The fix isn't a single tool or a plugin. It's a first-party data architecture, and it's built in a specific order because each layer depends on the one before it. Here's how I sequence it.

Step one: a first-party CNAME subdomain

Everything starts with a subdomain of your own site, something like data.yoursite.com, pointed via CNAME at your analytics and tagging infrastructure. This is the foundational move. Without it, your tracking requests are still being fired from a third-party domain as far as the browser is concerned, and ITP and ETP will treat the cookies accordingly, aggressive expiry, partitioning, or outright blocking. With a first-party subdomain in place, the browser sees requests coming from your own domain and treats the resulting cookies the way it treats any other first-party cookie on your site. This single DNS change is what makes everything downstream of it actually work.

Step two: server-side tagging behind the subdomain

Once that subdomain exists, route your tag infrastructure through a server-side container running behind it rather than firing tags client-side from the browser. This does two things at once. It keeps requests first-party end to end, and it gives you control over what data leaves your server and when, which matters for both accuracy and privacy compliance. I've written about the mechanics of setting up server-side GTM in detail elsewhere, so I won't repeat the whole build here, but the short version is that your container becomes the single point where events are received, enriched, and forwarded to GA4, Google Ads, and any other destination you configure, instead of a dozen scattered browser-side pixels each doing their own thing.

Step three: GA4 configured for first-party cookies

With the subdomain and server container in place, GA4 needs to be told to actually use them. That means setting the cookie domain to your first-party subdomain rather than the default, and setting a sensible cookie lifetime. Google's default of two years sounds generous, but Safari's ITP will cap script-writable cookies at seven days regardless of what you configure, unless the cookie is set server-side through a first-party HTTP response, which is exactly what your server-side container now lets you do. Get this step wrong and you've built the plumbing but left the tap off.

Step four: Consent Mode v2, implemented properly

This is where I see the most self-inflicted damage. A lot of implementations I audit have Consent Mode installed but misconfigured, defaulting every signal to denied before the consent banner has even loaded, and never correctly updating those signals once a visitor actually responds. The result looks like compliance but behaves like a tracking outage. Every visitor who hasn't yet interacted with the banner gets counted as a full rejection, which artificially collapses your measured conversion volume regardless of what people actually chose. Done properly, Consent Mode v2 passes accurate ad_storage and analytics_storage signals based on real user choice, and Google's modelling fills in the gaps for genuinely denied consent rather than for banner-loading delay. This is the difference between consent mode protecting your data and consent mode quietly destroying it.

Step five: Enhanced Conversions, for web and for leads

With first-party infrastructure and accurate consent signals in place, Enhanced Conversions is what claws back the match rate that cookie blocking took from you. The idea is straightforward: hash first-party customer data you already collect, email address, phone number, at the point of conversion, and send that hashed data alongside the conversion event. Google matches it against signed-in Google accounts to attribute the conversion even when the cookie-based click ID never made it through. Enhanced Conversions for web covers on-site purchases and form fills. Enhanced Conversions for leads covers the offline step, when a lead submitted on your site becomes a qualified deal or a closed sale days or weeks later in your CRM, and you feed that outcome back to Google Ads using the same hashed identifiers. For anyone running lead generation through paid search, this second piece is usually the bigger win, because it's the step that finally lets the platform optimise toward revenue instead of raw form fills.

Step six: CRM-matched data as the source of truth

The most durable first-party asset you have isn't a cookie at all. It's your CRM. Every contact record, every deal stage, every closed-won outcome is data you collected directly, with consent, that no browser policy can touch. Matching that CRM data back to ad platforms through Enhanced Conversions for leads is one use of it. The other is feeding it into lifecycle marketing, remarketing audiences, email sequences, lookalike seeding, so the same first-party record that improves your Ads bidding also drives retention and repeat revenue. This is the piece that turns tracking infrastructure into an actual growth system rather than a reporting fix, and it's usually where business systems work and marketing tracking start to overlap.

How to actually sequence this

None of this needs to happen in one sprint, and trying to ship it all at once is usually a mistake because each layer needs to be verified before the next one is built on top of it. A realistic phasing looks like this: get the CNAME subdomain and server-side container live and verified in week one, migrate GA4 and confirm cookie behaviour in week two, fix Consent Mode signals and validate them against real consent choices in week three, then layer in Enhanced Conversions for web and leads once the underlying data is trustworthy, with CRM matching as the final, ongoing piece. Each stage is independently useful. You don't have to wait until the whole stack is finished to start seeing better numbers.

Where this fits

This is the core of what I do under conversion tracking work: building the first-party architecture that makes your reported numbers match what actually happened, regardless of what any single browser vendor decides to do next. If you want a sense of how much of this is already missing from your own setup, the fastest way to find out is to run the Tracking Health Check. It takes a few minutes and gives you a live score against exactly the gaps described here.

Filed under: Tracking · First-party data · Privacy · 2026