Measurement

Consent Mode v2 and AI Referral Traffic: What Survives a Denied Consent, and How to Keep the Signal

· · 13 min read

If your site serves European visitors, AI referral traffic is the channel most damaged by consent, and the damage is almost never accounted for. The referrals from ChatGPT, Perplexity, Claude and Gemini are small, so a reject rate of 40% does not remove a rounding error, it removes the evidence that the channel exists. The teams asked to prove that AI search sends business are usually the same teams whose banner is quietly deleting the proof.

Consent Mode v2 is the mechanism that decides what is left. This article is about how it treats a visit that arrives from an AI assistant and declines analytics storage: what the cookieless ping still carries, which properties get behavioural modelling and what modelling does and does not do to an AI referral row, and how to implement and report the channel so that the number you present is one you can defend. It assumes you have a compliant banner already; if not, start with the cookie banner guide, which covers the law and the banner itself. The channel-group setup that makes AI referrals visible in GA4 in the first place is in tracking AI referral traffic.

Key takeaways

  • Under a denied analytics_storage, GA4 tags still send cookieless pings, and Google’s documentation lists the referrer among the fields those pings can include, so AI referral landings are countable without consent.
  • What the ping cannot carry is an identifier, so the landing is countable but the session, the return visit and the conversion are not joined to it.
  • Behavioural modelling needs at least 1,000 denied events a day for 7 days and 1,000 consented daily users on 7 of the previous 28 days, which most sites with a meaningful AI channel do not meet.
  • A basic implementation that blocks tags until consent gets no pings and no modelling, so for the AI channel it is strictly worse than the advanced pattern.
  • Report AI referral traffic under consent in three tiers: consented sessions, cookieless landings by source, and modelled sessions where eligible, with the consent rate for the channel alongside.

An AI-referred visit carries two things your analytics needs: a source and an identity. Consent takes the second, and the assistants often take the first.

The source problem exists with or without consent. Assistants strip or weaken the referrer on many surfaces, and the visits that survive with a usable source are the desktop web clicks, which is why measured AI traffic is an undercount everywhere. That problem and its fix are the subject of attributing conversions from AI assistants.

The identity problem is the one Consent Mode v2 governs. When a visitor from the EEA declines analytics storage, no first-party analytics cookie is set, so there is no client ID to tie the landing pageview to the pages that follow, to a return visit next week or to a conversion. In a channel with thousands of sessions a month the loss is a percentage. In the AI channel, where a B2B site may see a few hundred sessions and a handful of conversions, the loss can be the whole conversion count. Both problems land on the same visit, and each needs a different answer.

Consent Mode v2 is Google’s protocol for telling its tags what the visitor allowed. It is not a banner; it receives the banner’s decision and changes tag behaviour. Version 2 added two parameters for advertising, ad_user_data and ad_personalization, alongside the original ad_storage and analytics_storage, and Google’s setup guide requires the default state to be set before any measurement command, with wait_for_update to give an asynchronous banner time to answer.

The part that matters for AI referrals is what happens on denial. GA4’s consent mode documentation states that when visitors deny consent, instead of storing cookies, tags send pings to Google, and it lists what those pings can include: functional information such as the timestamp, the user agent and the referrer, plus coarse information such as the consent state and a random number generated on each page load. With analytics_storage denied, no analytics cookies are set, accessed or read, and the cookieless pings are used for behavioural and conversion modelling.

Read that list from the AI channel’s point of view. The referrer is in it. A landing from perplexity.ai, or from a link carrying utm_source=chatgpt.com, reaches Google’s servers with its source attached even when the visitor rejected everything. What is missing is any way to say that the next pageview came from the same person. The count of AI-referred landings survives denial; the sessions, users and conversions built on top of it do not.

Two implementation choices decide whether you get even that. The documentation distinguishes an advanced implementation, where tags load before the dialog and send cookieless pings on denial, from a basic one, where tags are blocked until consent is granted. Only the advanced pattern produces pings and behavioural modelling; the basic one produces nothing for a denied visitor. And consent collected through the IAB TCF is a special case: the same page says that when users deny consent through a TCF solution, GA4 cannot model the missing data.

Behavioural modelling: who qualifies, and what it does to AI referral rows

Behavioural modelling is Google’s answer to the identity gap: it estimates users and sessions for the visitors who declined, trained on the visitors who accepted. It is also where most European measurement plans quietly fail, because the eligibility bar is higher than the sales pitch implies.

GA4’s behavioural modelling documentation sets out the prerequisites: consent mode enabled on every page, implemented in the advanced pattern, at least 1,000 events per day with analytics_storage denied for at least 7 days, and at least 1,000 daily users sending events with consent granted for at least 7 of the previous 28 days. It adds that meeting those thresholds does not guarantee eligibility, because the model applies further criteria on data quality. A site with 20,000 sessions a month and a 40% reject rate is close to the line; a consultancy site or a niche SaaS blog is nowhere near it, and never will be.

For a property that does qualify, the same page explains what modelling touches. In reports it applies to user and session metrics, not to event counts, so page_view, first_visit and session_start are reported as collected. And because a denied visitor has no persistent identifier, those first_visit and session_start events are sent on every page load, which inflates them. Modelled data is also excluded from audiences, from segments with a sequence, from retention reports and from the BigQuery export.

The consequence for the AI channel is precise. The referrer travels in the ping, so the source dimension is available, but Google does not document how modelled sessions are distributed across sources, so a modelled AI referral session count is an estimate whose method you cannot inspect. And anyone reading AI referral session_start counts in a report with modelling off is reading a number inflated by every page a denied visitor loaded. Neither is wrong to report; both have to be labelled.

The referrer survives; the session does not

Put the two documents together and a practical rule falls out for every property, eligible for modelling or not.

Under denied consent, the reliable AI referral metric is landings by source: the count of first pageviews per session whose referrer or campaign source names an assistant. That count reaches GA4 in the pings, it does not depend on an identifier, and it is not inflated by repeat session_start events if you count only the landing pageview. Everything derived from continuity, engaged sessions, pages per session, returning users and conversion rate, is unavailable for the denied share of the channel and modelled at best for the rest.

That rule shapes the reporting. The consented share of the AI channel supports the full funnel. The denied share supports a landing count and nothing else, unless you keep the join yourself. For a European site, the honest conversion rate for AI referrals is the rate among consented AI sessions, presented with the consent rate for that channel, not a site-wide figure that silently treats denied AI visitors as if they never arrived.

The implementation has five parts, and the order matters as much as the code.

1. Advanced consent mode, with regional defaults. Load the Google tag on every page before the banner, set defaults to denied only for the regions where a banner is required, and update on interaction. Google’s setup guide recommends scoping defaults by region so that measurement is preserved where banners do not apply, and warns that consent defaults do not work if the code runs out of order. This site’s own banner sets every storage type to denied by default except security_storage, waits 500 milliseconds for a stored decision, and calls the update the moment the visitor chooses.

<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){ dataLayer.push(arguments); }
  gtag('consent', 'default', {
    'ad_storage': 'denied',
    'ad_user_data': 'denied',
    'ad_personalization': 'denied',
    'analytics_storage': 'denied',
    'wait_for_update': 500,
    'region': ['AT','BE','BG','HR','CY','CZ','DK','EE','FI','FR','DE','GR','HU','IE','IS','IT','LV','LI','LT','LU','MT','NL','NO','PL','PT','RO','SK','SI','ES','SE','GB','CH']
  });
  gtag('consent', 'default', {
    'ad_storage': 'granted',
    'ad_user_data': 'granted',
    'ad_personalization': 'granted',
    'analytics_storage': 'granted'
  });
  gtag('set', 'url_passthrough', true);
</script>

2. URL passthrough. With analytics_storage denied, the setup guide says URL passthrough can be used to send event and session-based analytics without cookies across pages, by appending parameters to same-domain links. It keeps a denied AI visitor’s second and third pageviews connected to the landing without storing anything on the device. Check that your redirects preserve the appended parameters and that nothing in your analytics treats them as page variants.

3. A source signal that does not need storage. Derive the AI source on the landing page, in memory, from document.referrer and the landing URL, and attach it as an event parameter to the landing pageview and to any consent update event the banner fires. Nothing is written to the device, so the parameter travels in the cookieless ping under denial and in the normal hit under consent. That gives you two things the standard setup does not: a landing count by AI source that is consent-independent, and a consent rate per AI source, because the update event carries the source too.

4. An edge count as the control. Your CDN or server log records the Referer header for every request without touching the visitor’s device. An aggregate count of landing requests per day whose referrer names an assistant, with no identifier kept, is the number you check GA4’s ping-based count against. Whether that log processing needs its own legal basis is a question for your privacy lead, not for this article; storage on the device is what the consent rules govern, and a server-side aggregate does not touch it.

5. The conversion join, server-side, under consent. For consented AI visitors, keep the source in a first-party cookie and record it at conversion through a server-side container, so the join does not depend on GA4’s session model. For denied visitors there is no lawful join without a consent, and the honest report says so. The build for this is what full-funnel tracking covers.

The report for a European property has three tiers and one denominator.

TierDataSupports
Consented AI sessionsStandard GA4 rows with identifiersFull funnel, conversion rate, return visits
Cookieless AI landingsPing-based landing counts by source, checked against the edge countChannel size, trend, page-level demand
Modelled AI sessionsOnly if the property is eligibleEstimated sessions and users, labelled as modelled

The denominator is the consent rate for the AI channel, computed from the consent update events that carry the source parameter. It is often different from the site-wide rate, because AI-referred visitors arrive on deep informational pages rather than the home page, and it is the figure that converts the consented conversion count into a channel estimate. If 55% of AI-referred visitors consent and consented AI sessions produced 11 conversions, the defensible statement is “11 observed, roughly 20 estimated, on the assumption that denied visitors convert like consented ones”, with that assumption written down.

One check catches most reporting errors: compare the cookieless landing count with the edge count for the same days. If GA4’s ping-based figure is far below the log, tags are being blocked before they can send, usually by a basic implementation or by a consent template that fires late. If it is far above, you are counting repeated session_start events rather than landings.

The EEA policy constraint

None of this is optional for sites that use Google’s advertising products with European visitors. Google’s EEA consent mode update states that to keep using its tags for measurement, personalised advertising and remarketing with EEA users, you must collect consent and share the consent signals with Google, and that preventing tags from loading until the banner is answered means Google cannot verify consent and may lose data. The underlying EU user consent policy requires legally valid consent for cookies where the law requires it and for ad personalisation, with records of consent and clear revocation instructions.

For the AI channel that policy is an ally. The same advanced implementation it pushes you towards is the one that keeps the cookieless ping, and with it the only consent-independent evidence that AI assistants are sending you visitors at all.

Frequently asked questions

Does GA4 still record AI referral traffic if the visitor rejects cookies?

Partly. With advanced consent mode, tags send cookieless pings on denial, and Google documents that those pings can include the referrer, so a landing from perplexity.ai or a link tagged utm_source=chatgpt.com is counted by source. No identifier is sent, so the visit cannot be joined to later pages, return visits or conversions. With a basic implementation that blocks tags until consent, nothing is recorded.

Does behavioural modelling fill in the AI referral sessions that were denied?

Only for properties that qualify, and only for user and session metrics. Eligibility needs at least 1,000 denied events a day for 7 days and 1,000 consented daily users on 7 of the previous 28 days, and Google says meeting those thresholds does not guarantee it. Modelled data does not apply to event counts, is absent from BigQuery export, and Google does not document how modelled sessions are split across sources, so treat modelled AI sessions as an estimate.

Because a denied visitor has no persistent identifier, GA4 sends first_visit and session_start on every page load, and Google’s documentation notes the resulting inflation in reports. Count landing pageviews by source instead of session_start events when measuring the denied share of the channel.

Storing anything on the device that is not strictly necessary is what the consent rules govern, so a persistent source cookie set before consent is the wrong pattern. Derive the source in memory on the landing page and send it as an event parameter instead; write it to a cookie only after analytics consent is granted, and keep an aggregate server-side count as the consent-independent check.

Is URL passthrough enough to keep AI referral sessions connected?

It connects same-domain pageviews for a denied visitor by appending parameters to internal links, so the landing and the pages that follow can be sent as session-based analytics without cookies. It does not create an identifier, does not survive a return visit and does not enable a conversion join, so it improves page-level reporting for denied AI visitors without changing what can be attributed.