Consent Mode v2 and Measuring Without Third-Party Cookies

Two things get conflated here. Consent Mode is a signalling mechanism: it tells Google's tags what a user agreed to, so they adjust behaviour instead of either firing regardless or not firing at all. Cookieless measurement is a separate and larger problem about identity persistence. Solving one does not solve the other.

What the signals actually control

ad_storage — advertising cookies and identifiers
analytics_storage — analytics cookies
ad_user_data — whether user data may be sent for advertising purposes
ad_personalization — whether it may be used for personalised advertising

Version 2 added the last two, and they are consent statements rather than storage permissions. Without them, Google's EU-facing products restrict what they will do with data you send, which is why the sequencing matters: the default state must be set before any tag loads, not after the banner resolves.

<!-- before the tag loads -->
gtag('consent', 'default', {
  ad_storage: 'denied',
  analytics_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  wait_for_update: 500
});

// then, on the user's choice
gtag('consent', 'update', { ad_storage: 'granted', /* ... */ });

Get this order backwards and you have a compliance problem that looks exactly like a working setup, because the tags fire and the data arrives.

Modelling is an estimate and should be labelled as one

With consent denied, tags still send cookieless pings and Google models the conversions those users would have represented. This is genuinely useful and it is not measurement. Modelled conversions cannot be reconciled against your order table, cannot be split arbitrarily, and vary with your consent rate.

The practical consequence is reporting discipline. If the board sees a single conversion number, somebody will eventually try to reconcile it with finance and lose a week. Keep platform-reported figures and actual orders as separate lines that are never added together.

First-party identity is the durable half

Third-party cookies are the part that is going away. What remains is what happens on your own domain, in your own storage, tied to identifiers you control.

capture click identifiers on landing and persist them server-side against the session
hash and store an email or user ID at the point of conversion, with consent
send conversions from your backend keyed on the order, not on a browser event
keep a first-party session identifier that survives Safari's storage limits

This is the same architecture as server-side tracking, which is why the two are usually one project. The consent layer decides what may be sent; the server-side pipeline decides whether it arrives at all.

Consent rate becomes a business metric

Once measurement depends on consent, the banner stops being a legal checkbox and starts setting how much of your data is real rather than modelled. Small, honest changes in wording and layout move consent rates materially, and the difference shows up in every downstream report.

measure consent rate by page type and traffic source, and track it over time
annotate analytics whenever the banner changes, because the step change will look like a traffic event
do not use dark patterns — regulators treat coerced consent as no consent
record the consent state alongside the conversion so you can segment later

What to check now

Most setups have at least one of these wrong, and none of them announce themselves.

default consent set before the tag loads, rather than after
all four v2 signals present, not only the original two
server-side events carrying the consent state instead of defaulting to granted
a documented reconciliation between platform-reported conversions and actual orders

If your server-side container forwards events without the consent state attached, the client-side banner is decorative.