Enhanced conversions says false: five checks before trust

On this page

1. The false flag is not the same thing as a failed conversion
2. Check 1: the account setting and terms must be active
3. Check 2: consent must be set before the conversion request
4. Check 3: populated fields still need valid input and hashing
5. Check 4: inspect the conversion request, not just the tag card
6. Check 5: Ads diagnostics are the processing result
7. Trust the chain only when all five layers agree

Short answer: treat allow_enhanced_conversions: false as a clue, not a verdict. Seeing email, phone or name fields in a debugger proves only that the page or tag can see those values. It doesn't prove enhanced conversions are enabled in the account, permitted by the current consent state, formatted and hashed correctly, attached to the conversion request, accepted for the right conversion action or processed by Google Ads. Check those layers in that order, without exposing the raw values.

The false flag is not the same thing as a failed conversion

allow_enhanced_conversions is an implementation detail you may encounter in a debug view or request. Google doesn't document that field as the final status of an enhanced conversion. Its current verification instructions tell you to inspect the conversion hit's em parameter and then use the Ads diagnostics report (Google Ads Help, checked 24 September 2026).

That distinction matters because three separate things may be true at once:

• the ordinary Google Ads conversion tag fired;
• user-provided fields existed in the page or GTM variable;
• no usable enhanced-conversion payload reached Google.

Enhanced conversions supplement an existing conversion by sending hashed first-party data. They don't replace the base conversion action, and a false-looking flag doesn't by itself tell you whether that base conversion was recorded (Google Ads Help, checked 24 September 2026).

Use the five checks below as a decision tree. Stop at the first failed layer. Fixing a later one won't repair an earlier failure.

Check 1: the account setting and terms must be active

Start in Google Ads, not in the browser. Under Goals → Settings → Enhanced conversions, confirm that enhanced conversions are turned on and that the customer data terms have been accepted. Google's setup guide says enhanced conversions for web and leads now share one on/off setting, with website tags, Data Manager and API connections feeding the same setting from April 2026 (Google Ads Help, checked 24 September 2026).

The diagnostics report calls out a specific Enhanced conversions not in use state when the customer data terms haven't been accepted. Google also says data sent before those terms are accepted won't be processed (Google Ads Help, checked 24 September 2026). That can produce the confusing case where the tag sees populated variables but the account refuses to use them.

Also verify the conversion ID and label. A perfectly formed request sent against the wrong action is not evidence that the action you're inspecting works. If the action is imported from Google Analytics, stop: Google's current setup page says imported Analytics goals aren't supported for enhanced conversions. Use a Google Ads conversion action implemented with the Google tag or GTM instead (Google Ads Help, checked 24 September 2026).

Check 2: consent must be set before the conversion request

A debugger can display personal data even when the consent state prevents advertising use. Visibility inside GTM is not permission to transmit it.

Google's developer guide requires the default consent state to be set before commands that send measurement data, then updated after the visitor interacts with the consent controls (Google for Developers, checked 24 September 2026). Inspect the event timeline, not only the final state:

1. the consent default runs before the Google tag or GTM conversion event;
2. the relevant advertising consent signals have the expected values;
3. the CMP sends an update after the visitor's choice;
4. the conversion occurs after that update when consent is required for the implementation;
5. no stale page, SPA route or duplicate container overwrites the state.

If consent changes after the conversion event, a later granted state doesn't prove the earlier request carried user-provided data. Trigger a fresh test conversion after the update rather than reading the last state in the debugger.

Check 3: populated fields still need valid input and hashing

Next, inspect the enhanced-conversions object at the conversion event. Do this in GTM preview or Tag Assistant, and never copy raw email addresses, phone numbers or names into a ticket, screenshot or shared log.

Google's diagnostics distinguish missing data from bad data. Empty variables, selectors that fail on mobile, invalid email formats, phone numbers without a country code and incomplete address fields can all prevent a useful payload. When the Google tag performs the transformation, it uses SHA-256 before sending first-party customer data (Google Ads Help, checked 24 September 2026).

Don't hash blindly twice. Follow the selected implementation method: pass normalised raw values only where Google's tag is meant to hash them, or pass SHA-256 values where the interface explicitly expects pre-hashed input. The browser view should tell you which value entered the tag; the network request tells you what left it.

The useful checkpoint is the em parameter on the conversion hit. Google's diagnostics page says:

• no em parameter means enhanced-conversion data wasn't sent;
• tv.1~em. means the parameter was present but empty;
• an error suffix such as e0, e1, e2 or e3 points to formatting, browser, hashing or insecure-page failures;
• a proper hash appears as a long value rather than the original personal data (Google Ads Help, checked 24 September 2026).

This is stronger evidence than a populated GTM variable because it checks the outgoing payload.

Check 4: inspect the conversion request, not just the tag card

Open DevTools Network, clear the log, trigger one fresh conversion and filter for the Google Ads conversion request. Match its conversion ID and label to the action you intend to test. Then inspect only non-sensitive fields: request time, destination, status, consent parameters and whether a non-empty hashed em value exists.

Use this sequence:

1. confirm the conversion tag fired once;
2. find the corresponding network request;
3. match the action ID and label;
4. check the consent state carried by that request;
5. check for a non-empty hashed em value;
6. record the timestamp and request status, but redact the payload before sharing evidence.

Tag Assistant can show whether the tag fired, what triggered it and which network requests resulted (Google Ads Help, checked 24 September 2026). A successful HTTP response proves transport, not attribution. It doesn't prove Google matched the hash, tied the base conversion to an ad interaction or made that conversion usable by bidding.

Keep click identifiers in this diagnosis too. Enhanced conversions are documented as a supplement to the existing conversion, using hashed data to improve matching. They aren't evidence that a lost or stripped click identifier has been repaired. Check whether the landing and conversion journey preserved the applicable Google Ads identifier, but don't infer successful attribution merely because user data was present (Google Ads Help, checked 24 September 2026).

Check 5: Ads diagnostics are the processing result

Finish in Goals → Summary → Diagnostics for the exact conversion action. Google's report separates Excellent, Good, Needs attention and No recent data states. It also reports missing data, incorrect formatting, coverage and match rate (Google Ads Help, checked 24 September 2026).

These statuses answer questions the browser cannot:

Allow time for account-side reporting. Google's diagnostics documentation says coverage can appear within hours, while match-rate updates can take up to 24 hours. Low-volume accounts may not receive alert detail when fewer than 20 conversions occurred in the previous seven days (Google Ads Help, checked 24 September 2026). Don't keep changing the implementation during that window; you'll destroy the clean test you need to compare.

Trust the chain only when all five layers agree

A reliable test has one account setting, one consent timeline, one test conversion, one matching network request and one account-side diagnostic result. Save the timestamps and action identifiers. Redact every user-provided value.

If allow_enhanced_conversions still says false but the correct request contains a hashed em value and Ads diagnostics show the action recording enhanced conversions, the flag is stale or non-authoritative. If the flag says true but the request has no usable em, trust the request. If the request looks right but diagnostics stay empty after the documented processing window, check the action mapping, traffic volume and account terms before touching the tag again.

For a full audit of the tag, consent state, conversion action and bidding handoff, conversion measurement is part of our implementation work.

Sources

1. 1.Google Ads Help — About enhanced conversions · Checked 2026-09-24
2. 2.Google Ads Help — Set up enhanced conversions using the Google tag · Checked 2026-09-24
3. 3.Google Ads Help — Enhanced conversions tag diagnostics · Checked 2026-09-24
4. 4.Google for Developers — Set up consent mode on websites · Checked 2026-09-24
5. 5.Google Ads Help — Tag Assistant troubleshooting · Checked 2026-09-24