"I enabled Enhanced Conversions, but I have no idea whether it's actually being sent." This is the unease you always hit after flipping the switch. Numbers don't change the instant you turn it on, so it's hard to tell whether it's "working" or whether the data is even arriving. That's exactly why it's a feature so often left in the set-it-and-forget-it state.
Does any of this sound familiar?
- You turned Enhanced Conversions on, but can't feel any effect
- The diagnostics show a warning like "Needs attention" or "Not recording"
- You think you're sending email and phone numbers, but the status won't advance
- You've never actually looked to confirm the hashed values are being sent
This guide organizes what to check, and in what order, to confirm Enhanced Conversions are actually being sent. We'll first nail down what the mechanism actually does, then verify it in both the diagnostics screen and DevTools.
First principle: Enhanced Conversions hashes first-party data and sends it
Before checking anything, understanding what Enhanced Conversions sends is the shortcut. If this is fuzzy, you'll be staring at DevTools without knowing what to look for.
Enhanced Conversions takes the first-party data a user entered in a form (email address, phone number, name, address), hashes it with SHA-256 in the browser, sends it to Google, and uses it to supplement conversion measurement (attribution). The raw email address isn't sent as-is — it's converted into an irreversible hash value before being sent.
| Element | What it is | What to check |
|---|---|---|
| Input data | Email, phone, name, address | Does the value exist on / can it be read from that page? |
| Hashing | Irreversible SHA-256 transform | Is raw data being sent unhashed? |
| Destination | Bundled into existing conversion measurement | Does the request contain hashed fields? |
| Consent | User consent such as ad_user_data |
Is it set so nothing is sent without consent? |
The key point: Enhanced Conversions piggybacks an "extra signal" onto your existing conversion measurement. In other words, if the underlying conversion tag itself isn't firing, Enhanced Conversions can't possibly work either. Assuming conversion measurement is already running, we verify whether hashed first-party data is riding on top of it.
Common pitfall: people confuse the click ID (gclid) with Enhanced Conversions, but they play different roles. The gclid is an ID that ties a result to which ad click it came from; Enhanced Conversions is a mechanism that supplements attribution using first-party data. They complement each other. For checking the click-ID side, see The Role of the Click ID (gclid) and Attribution.
Verification method 1: Read the Google Ads diagnostic status
The first thing to look at is the diagnostics in the dashboard. Without touching any code, you can see how Google is judging things on the receiving side.
Open your conversion action under "Goals → Conversions" and check the Enhanced Conversions diagnostics / status. It displays a clue about what's being received.
| Status | Meaning |
|---|---|
| Recording enhanced conversions | Hashed data is being received (healthy) |
| Needs attention | The setup exists, but data isn't received / values are missing |
| Not recording | No data for Enhanced Conversions is arriving |
"Recording" … the receiving side is getting hashed data. The foundation is OK. "Needs attention" / "Not recording" … the tag is there, but the enhanced values aren't arriving. Move to verification method 2 (DevTools) and look at what's actually being sent.
Common pitfall: the diagnostic status has a reporting delay. If it says "Not recording" right after setup, don't conclude it's broken. The reliable move is to use verification method 2 to see, in real time, whether the hashed fields are actually being sent right now.
Reading the diagnostics report: Coverage, Match Rate, and Conversion Uplift
Beyond the top-level status, the diagnostics report contains three metrics that tell you how well Enhanced Conversions is working — not just whether it's on.
| Metric | What it measures | Healthy benchmark |
|---|---|---|
| Coverage | The percentage of eligible conversion events that include sufficient user-provided data | Above 80 % |
| Match Rate | How well the hashed data you send matches Google's signed-in user data | Higher is better; low rates suggest formatting issues or non-Google-account users |
| Conversion Uplift | The additional conversions reported thanks to Enhanced Conversions data | Available for 30 days after Enhanced Conversions starts working |
Coverage is the one you can most directly control. If it's low, it means many conversion events fire without first-party data attached — usually because the value isn't on the page or isn't picked up (see the common-failure section below).
Match Rate depends on data quality. If you're only sending email and many of your customers use addresses that don't match their Google accounts, the rate will be low even though everything is technically configured correctly. Two practical levers: send additional match keys (phone number, address) alongside email, and make sure values are properly formatted before hashing (lowercase, no extra whitespace, standard phone format with country code).
Conversion Uplift appears only after enough data has accumulated. Don't expect it to show a number on day one.
Google labels each conversion action as "Excellent," "Good," "Needs attention," or "No recent data." If you see "Good" rather than "Excellent," the report usually tells you which metric to improve — often it's coverage or the number of match keys you're sending.
Verification method 2: Check in DevTools whether hashed fields are included
When the diagnostic status won't advance, the decisive step is checking the real thing in the DevTools Network tab. Look directly at whether the conversion request contains the hashed first-party data fields.
- Open the page where the conversion occurs (e.g., the completion page after a form submit) and open the DevTools "Network" tab
- Filter for
conversionorgoogleads - See whether a
…/pagead/conversion/…request fires on that action - Check the request contents (parameters) for the hashed email field (
em) and similar
What it tells you: whether the first-party data for Enhanced Conversions is actually being sent, in hashed form.
If a value like em is a long alphanumeric string (a hash), that's a good sign it was hashed in the browser before being sent. Conversely, if the field is absent or empty, the value isn't being picked up (the classic case behind a "Not recording" status in verification method 1).
Common pitfall: if the contents of
emlook like a raw email address (a readable string containing@), beware. It may be configured to send the value unhashed, which is not the intended behavior. Always check that readable raw data isn't riding along.
Verification method 3: Confirm in GTM Preview Mode (for Tag Manager users)
If you set up Enhanced Conversions through Google Tag Manager, the GTM Preview Mode gives you a second real-time verification path that's often easier than reading raw network requests.
- Open the GTM Preview panel (click "Preview" in the top-right of the GTM workspace)
- Navigate to the page where the conversion fires and trigger a test conversion
- In the Preview panel, click the conversion event (e.g.,
purchaseorform_submit) - Open the tag that fired and inspect the Values section — look for the
enhanced_conversion_dataobject or the individual fields (email,phone_number, etc.) - Confirm the fields contain values (they'll appear in their pre-hash form inside Preview Mode — GTM hashes them before the actual request leaves the browser)
What it tells you: whether GTM is picking up the first-party data at the moment the tag fires. This catches selector mismatches and data-layer gaps before you have to dig through encoded network requests.
If the values appear in Preview Mode but the diagnostic status still shows "Needs attention," the problem likely lies downstream — consent blocking the send, or a mismatch between the GTM container in preview and the one published to production. Always publish the container and verify in production after a successful preview test.
Common pitfall: GTM Preview Mode uses your own browser session, so the same "works on my machine" limitation applies. It proves the mechanism works; it doesn't prove data arrives for every visitor path.
Common failures: why Enhanced Conversions "aren't sent"
Once verification methods 1 and 2 reveal that data isn't arriving, the cause generally falls into one of these.
The email (etc.) value isn't on the page / can't be picked up
Enhanced Conversions can only send when the first-party data exists on that page. If the email disappears from the screen after a form submit, or the value isn't carried over after a page transition, there's nothing to pick up.
A CSS selector or variable is misconfigured, so the value isn't read
If you're capturing email or phone via manual setup (CSS selector targeting or data-layer variables), a mismatch in selector or variable name can mean not a single value is picked up. When a site redesign changes the DOM structure, this silently breaks — a classic trap.
Raw data is being sent before hashing
The correct premise is to hash with SHA-256 before sending. Some implementations send raw data instead, which isn't the intended behavior (suspect this if em is a readable string in verification method 2).
Consent (ad_user_data) is missing, so nothing is sent
If you've adopted consent mode, when a user hasn't consented to data use for advertising purposes (ad_user_data isn't granted), the first-party data may not be sent. This is a strong suspect when "the setup is correct but nothing arrives." For details, see Why Consent Mode Makes Your Conversions Drop.
Common pitfall: when you test yourself, you click "Agree" on the consent banner so it sends — but real visitors haven't consented. "It sent on my machine" does not mean "it sends for everyone."
How to improve your match rate
You've confirmed Enhanced Conversions is sending — but the diagnostics report shows a low match rate or minimal conversion uplift. This is a different problem from "not sending": the data leaves your site but doesn't match well on Google's end. Here's what to do.
Send more than just email
Enhanced Conversions supports three match keys: email, phone number, and postal address. Many implementations only send email. Adding phone number and address fields gives Google more signals to match against, which directly raises the match rate — especially when a customer's email doesn't match their Google account.
Clean and format the data before hashing
Google's matching is sensitive to formatting. Before hashing, make sure you:
- Lowercase email addresses (
User@Example.com→user@example.com) - Remove leading/trailing whitespace
- Use the E.164 format for phone numbers (e.g.,
+81312345678for a Japanese number,+14155551234for US) - Trim and standardize address components
If you hash User@Example.com and Google hashes user@example.com, the SHA-256 outputs won't match — and that conversion is lost.
Prefer manual specification over automatic detection
When setting up Enhanced Conversions, Google offers an "Automatic" option that tries to detect email fields on the page. This is convenient but less reliable than manually specifying the CSS selector or data-layer variable for each field. Manual specification gives you control over exactly which value is read, and avoids silent breakage when the page structure changes.
Check that you're sending data on all eligible conversion actions
The diagnostics report may show good match rates on one conversion action but nothing on another. Make sure Enhanced Conversions is enabled on every conversion action that has access to first-party data — not just your primary one.
How to isolate "I set it up but nothing shows"
If the numbers still won't move after all this, the first thing to remember is that Enhanced Conversions is an extra signal that rides on top of your underlying conversion measurement. If the underlying conversion itself isn't recorded, Enhanced Conversions can't take effect ahead of it.
So when you feel "Enhanced Conversions aren't showing up," the first job is to isolate whether the underlying conversion measurement itself is healthy. The diagnostic steps for a zero / not-tracking state are organized in No Conversions in Google Ads? A Step-by-Step Diagnostic Guide. Confirm the foundation is working, then return to the Enhanced Conversions layer on top.
You can also confirm whether the underlying conversion tag fires correctly in How to Verify Your Google Ads Conversion Tag. The order is "the tag fires → the conversion is recorded → the hashed enhanced data rides on top."
What checking on your own machine can't tell you
Verification methods 1 and 2 are both useful, but checking once on your own machine has two structural limits.
- Your environment isn't your visitors' environment. In your own test you consent on the banner and type values into the form, so they're picked up — but real visitors may not have consented and may take paths where the values differ.
emcan be sent on your machine yet be missing under real conditions. - Verification involving an ad click is hard. To properly see "does it really work end to end via an ad, including Enhanced Conversions," you'd need to click a live ad to recreate the path — which carries the risk of an ad-policy violation as a self-click.
Judging "the hashed field fires on my action, so it's fine" tends to miss the problem of data going missing on the real path your visitors take.
Verification checklist
- The underlying conversion tag fires and the conversion is recorded
- Checked the Enhanced Conversions status in the Google Ads diagnostics
- Confirmed the
…/pagead/conversion/…request in the DevTools Network tab - That request contains hashed fields (
em, etc.) - The contents of
emare a hash (a long alphanumeric string), not a raw email - First-party data (email, etc.) exists on the page where the conversion occurs
- CSS selectors / variables match the current DOM structure
- When using consent mode, data is sent with
ad_user_dataconsent present - If using GTM, verified in Preview Mode that the tag picks up the data fields
- Checked the diagnostics report metrics (Coverage, Match Rate, Conversion Uplift)
- Sending more than one match key (email + phone and/or address) where possible
- Email addresses are lowercased and trimmed before hashing
- Confirmed it arrives not just on your machine but on the real visitor path
Frequently asked questions
Q. I enabled Enhanced Conversions but can't tell whether it works. A. First, Enhanced Conversions is a mechanism that "supplements" your existing conversion measurement; it won't suddenly produce big numbers on its own. Before "effect," check "is it being sent correctly." Work through the Google Ads diagnostic status (verification method 1) and the hashed field in DevTools (verification method 2), in that order.
Q. Where in DevTools do I look to know it's "being sent"?
A. In the Network tab, open a …/pagead/conversion/… request and check whether the parameters include a hashed email field (em) and similar. A long alphanumeric string (a hash) is a good sign. If the field is absent or empty, the value isn't being picked up.
Q. I can see a raw email address in em. Is that a problem?
A. Enhanced Conversions is premised on hashing with SHA-256 before sending. If readable raw data is riding along, you may have an implementation that doesn't hash — which is not the intended behavior. Check the implementation.
Q. The setup is correct but it stays "Not recording."
A. Common causes: ① the first-party data isn't on the page / can't be picked up, ② a CSS selector or variable is misconfigured, ③ consent (ad_user_data) is missing so nothing is sent. The diagnostic status also has a reporting delay, so also check in DevTools whether it's firing in real time.
Q. What's the difference between the click ID (gclid) and Enhanced Conversions? A. The gclid is an ID that ties a result to which ad click it came from; Enhanced Conversions hashes the entered first-party data and sends it to "supplement attribution." They play different roles and complement each other.
Q. I heard Enhanced Conversions settings are changing in 2026. What do I need to do? A. Starting in mid-2026, Google is unifying Enhanced Conversions for web and Enhanced Conversions for leads into a single on/off setting at the account level. Google Ads will accept user-provided data simultaneously from website tags, Data Manager, and API connections — you'll no longer need to choose a single implementation method. If you already have Enhanced Conversions enabled and have accepted Google's customer data terms, no action is required; your setup will be migrated automatically. The main practical change is that offline conversion imports and leads uploads move to the Data Manager API (they'll be blocked in the Google Ads API from June 15, 2026).
Conclusion: confirm "is it being sent" with both diagnostics and DevTools
Enhanced Conversions hashes first-party data with SHA-256, sends it to Google, and supplements attribution. Before judging "is it working" by feel, first confirm it's being sent correctly — using both the Google Ads diagnostic status (method 1) and the hashed field (em, etc.) in DevTools (method 2). If it isn't arriving, you can isolate to one of: no value, a selector mismatch, raw-data sending, or missing consent.
But checking on your own machine has limits. Going further — confirming that the hashed first-party data is actually sent, on the real path your visitors take, in production — is what "Enhanced Conversions is working" truly means.
ConversionOK runs your live page in an independent, isolated browser and intercepts the conversion requests actually sent (including the hashed first-party data), then verifies them — with no need to click your own ad and no interference from your office environment. Start with a free static check to confirm the entry point of your Enhanced Conversions measurement.