The symptom

Enhanced conversions went live months ago, the setup guide was followed, and the feature reports as active in Google Ads. Then a client's legal team, or your own account manager after a procurement questionnaire, asks a version of the same question: when a visitor refuses the cookie banner, does the hashed email address still leave the browser?

Nobody on the account is sure. The banner has a marketing toggle and the tag manager has two boxes that both sound like "advertising consent", ad_user_data and ad_personalization, and whoever wired the consent signals mapped both to the same toggle without checking whether they control the same thing. They do not.

The honest answer to the legal team's question is "we think so, but we have not verified it", which is not an answer procurement, or a regulator, will accept twice.

Why it happens

Consent Mode v2 has four consent types, and two of them get confused constantly because both apply to advertising. Google Tag Manager Help defines ad_user_data as consent "for sending user data to Google for advertising purposes" and ad_personalization as consent "for personalized advertising". Close enough in wording to map onto one banner category, and different enough in effect that doing so gets the wrong data sent, in one direction or the other.

What a denial actually switches off, per signal

Google's own consent mode documentation is specific about this, and the specificity is the part worth reading closely. Under an ad_user_data denial: "Personal data collection for online advertising is disabled, including: user_id, Enhanced conversions: Hashed first party data." That is enhanced conversions named directly, in Google's own list of what a denial removes.

ad_personalization denial disables a different, narrower set: "Remarketing in Google Ads, Display & Video 360, Search Ads 360, Personalized advertising with Google's advertising products." Enhanced conversions is not on that list. A visitor can refuse personalized advertising and still have their hashed data sent for conversion matching, because that is a separate consent question from whether they see remarketing ads.

Mapped onto one toggle, both directions of error are live. Deny only what should stop remarketing, and hashed customer data still goes out if the mapping happened to route ad_user_data as granted. Deny what should only affect personalization, and enhanced conversions gets switched off for visitors who never objected to that specifically. Neither error shows up in a dashboard. Enhanced conversions either keeps reporting a match rate or it does not, and nothing in Google Ads tells you which consent signal produced that number.

What is actually inside the payload this gate protects

Google Ads Help states the fields enhanced conversions may carry: "first-party customer data such as an email address, name, home address, and/or phone number". None of it leaves in that form. The same documentation requires hex SHA256 hashing, after removing whitespace, lowercasing, converting phone numbers to E.164, and stripping periods before the domain in certain email formats. Google receives a hash it cannot reverse, not the underlying value. That is a data-minimisation detail worth knowing, and it is not the consent question. Whether the hash gets built and sent at all is decided upstream of hashing, by ad_user_data.

Consent Mode v2's basic and advanced split does not change this gate

Advanced mode, once a visitor denies consent, still sends "consent state and measurements without cookies", according to the same consent mode documentation, which is what feeds Google's conversion modeling for the base conversion event. Nothing in that documentation describes a cookieless substitute for the hashed enhanced-conversions fields specifically. The mode a banner runs in changes how the underlying conversion gets modeled. It does not appear to change whether ad_user_data being denied stops the hashed fields, which by Google's own description it does either way.

What good looks like

Treat this as two separate facts to verify, not one setting to trust. First, which of the two signals your enhanced conversions tag actually reads, confirmed rather than assumed from how the banner categories were labelled. Second, that a denial of that specific signal removes the hashed fields, and that a denial of the other signal does not remove them when it should not. That is a technical verification, done once per client and revisited whenever the tag setup or the banner changes.

The reason it matters more than most consent wiring is the accountability duty sitting behind it. GDPR Article 5(2) requires a controller to "be responsible for, and be able to demonstrate compliance with" the data protection principles, and Article 7(1) requires being able to "demonstrate that the data subject has consented" where processing rests on consent. "We mapped a toggle and assumed it worked" does not demonstrate anything. "Here is the signal our enhanced conversions tag reads, and here is confirmation that a denial of it withholds the hashed fields" does. That second sentence is what Archon Consent is built to produce as part of wiring a client's consent setup, not a document written afterward to justify a guess.

This sits inside the same four-decision framework covered in Consent Mode v2 without throwing data away, specifically the decision about how banner categories map onto Google's consent types. Enhanced conversions is the sharpest example of why that mapping decision is not cosmetic: get it wrong here and either compliant traffic gets under-measured, or refused traffic gets sent anyway, and only one of those two mistakes will ever surface on its own.

FAQ

If a visitor denies personalized advertising, does that also stop enhanced conversions?

Not according to Google's own documentation. ad_personalization denial is described as disabling remarketing and personalized advertising features. Enhanced conversions is named specifically under the ad_user_data denial instead. The two are separate consent questions, and a setup that treats them as one will get at least one of them wrong.

Does advanced consent mode send the hashed enhanced conversions fields even when ad_user_data is denied?

Google's consent mode documentation describes advanced mode as sending "measurements without cookies" on a denial, which feeds conversion modeling for the base event. It does not describe that as covering the hashed enhanced-conversions fields, which are listed separately as disabled under an ad_user_data denial. Treat the two as unrelated rather than assuming one substitutes for the other.

Is ad_storage consent relevant to enhanced conversions at all?

Google's documentation ties enhanced conversions' hashed data specifically to ad_user_data, not to ad_storage. ad_storage governs cookie and device-identifier storage for advertising generally. Treating it as the enhanced conversions gate is a common mix-up, but it is not what Google's own list of what an ad_user_data denial removes says.

What exactly do we need to be able to show if a client's legal team asks?

Which of the two signals the enhanced conversions tag actually reads, and evidence that a denial of that signal withholds the hashed fields while the other signal behaves as documented. That is a specific, checkable claim, and it is the level of detail GDPR's accountability requirement asks for, not a general assurance that "consent mode is implemented".

Does this apply the same way outside the EEA?

The consent types and their documented effects are the same wherever they are implemented. What differs is whether local law requires collecting consent for this data in the first place, which is a separate, per-market legal question outside what Google's documentation covers.

If you cannot currently say which consent signal your clients' enhanced conversions tags read, a free tracking audit checks it account by account.