Chrome keeps third-party cookies: what changes for CRM

The question reached us within hours. A retail team we work with had spent six months rebuilding their tagging, their consent record and their customer identity keys, and every milestone in that plan was pinned to a date in Chrome. That date has now gone away. Do they stop?

Google has said it will not deprecate third-party cookies in Chrome as planned. Rather than switching them off, the browser is to offer people an explicit choice about cross-site tracking. The Privacy Sandbox work continues, Safari and Firefox are unchanged, and the small Chrome population already running without third-party cookies has not been un-restricted by the news.

Our answer was no, do not stop. That is not stubbornness about a plan. It is that the case for owning your customer data never rested on the deprecation date in the first place, and a programme built to survive that date is a better programme for a dozen reasons that have nothing to do with Chrome.

Who has actually been given a reprieve

The relief here is real, and it belongs almost entirely to paid media. Retargeting pools stay addressable for longer. View-through attribution keeps working in the tools that report it. Cross-site frequency control in display does not break next quarter. Publishers keep a chunk of programmatic yield they were bracing to lose.

None of that is a CRM capability. If your lifecycle programme depended on any of those four things, something has been mislabelled in your org chart.

It is also a reprieve with an unknown shelf life. A choice screen is not the same as no change. Where browsers and operating systems have previously put an explicit tracking prompt in front of people, take-up has generally been low. Nobody outside Google can tell you today what the prompt will say or how often it will appear. Planning a two-year roadmap on the assumption that the population stays intact is a bet, not a plan.

The CRM case was never a cookie case

Third-party cookies have never done the work a CRM programme depends on. Ask what they actually carried for you and the list is thin.

Identity on your own domain runs on a first-party cookie, a login, or an order confirmation, and none of those are affected. Consent records live in your own database. Suppression lists live in your ESP and your warehouse. Order history, service events, support contacts and product usage are all yours already. Email and SMS reachability turns on authentication and consent, not on browser storage.

Where CRM does touch the third-party world is narrower: syncing an audience to an ad platform to suppress existing customers, or to seed a lookalike, or to run a paid layer of a win-back. Those syncs already run on hashed email rather than cookies in most stacks, which is why they survive either way.

So the deprecation date was never the reason to invest in first-party data. The reasons were that you cannot personalise on data you do not hold, cannot prove incrementality on data you cannot join, and cannot answer a regulator with a data set you do not control.

Keep the consent and tagging work exactly where it is

The two projects most at risk of being quietly shelved this month are Consent Mode and server-side tagging. Both are worth finishing, for reasons that survive the announcement intact.

• The binding constraint in the UK and EU is the regulator, not the browser. The rules on storing and reading information on a device did not move today, and consent for non-essential storage is still required whatever Chrome does.
• Consent signals have to reach your analytics and your ad tags either way. A programme that cannot say which contacts consented to what, and when, has a compliance problem long before it has a measurement problem.
• Server-side tagging pays for itself on data quality and page weight. Fewer client-side scripts, one controlled path out to vendors, and a copy of the event stream you can send to your own warehouse.
• Ad blockers, network-level filtering and mobile app contexts already remove a slice of client-side measurement. That slice does not come back because a deprecation was cancelled.

If the business case for these projects was written as "Chrome is turning cookies off", rewrite the business case rather than cancelling the work. The second version will be more honest and will age better.

Measurement stays broken, so fix it properly

The part of this that CRM teams should care about is measurement, and it is not improved by the reprieve. Cross-site attribution was degrading before the announcement, is degrading now in Safari and Firefox, and will degrade further whenever the choice screen arrives.

We have been here before in email. When Apple's privacy changes made opens unreliable, the teams that coped were the ones who stopped treating a vendor-reported metric as ground truth and moved to outcomes they could observe themselves. The same discipline applies here, and the reasoning we set out in life after the open rate transfers directly.

In practice that means three things. Hold back a control group on your major programmes and measure the difference in revenue per customer rather than the difference in clicks. Join sends, sessions and orders in your own warehouse on your own identity key, so the numbers do not depend on a third party's window. And run occasional geo or time-based tests for the channels where person-level measurement is genuinely gone.

None of that is new advice. It was the right answer when the deadline existed and it is the right answer now.

What to tell the people who read the headline

Somebody senior will ask whether the privacy programme can be cut. A short, specific answer works better than a defence of the roadmap.

• The deadline has moved; the direction has not. Two of the three major browsers already block cross-site tracking by default.
• Nothing in our lifecycle roadmap was dependent on the deprecation date, so nothing in it changes.
• The paid media plan does get easier for a while, and that saving should be banked rather than spent on rebuilding a retargeting habit we are trying to grow out of.
• The consent and tagging projects continue, because they are driven by law and by data quality, neither of which Google controls.

Then go back to the unglamorous work. Fix the identity key that still fails on guest checkout. Get the consent timestamp and source into a field somebody can query. Write down which events are collected server-side and which are not. That list was the real project all along, and it has no deadline at all.