Google Ads Enhanced Conversions for Leads Troubleshooting: The Six-Layer Diagnostic That Finds Your Real Match-Rate Leak

This is a hands-on guide for paid media buyers and marketing managers running google ads enhanced conversions for leads at real spend. If you want the short version of google ads enhanced conversions for leads troubleshooting: stop trusting the green check, segment your match rate by source, and check the phone format first.

The Green Check Only Confirms Data Is Arriving, Not That It’s Matching

The Diagnostics tab in Google Ads has one job: tell you whether conversions are being received. It does not tell you whether those conversions are being matched back to a click. Two different questions, and the gap between them is where most lead-gen accounts quietly bleed signal.

Enhanced Conversions for Leads (ECL) is Google’s system for tying offline outcomes back to ad clicks. You send hashed user data (email, phone, name, address) or a stored gclid (the click ID Google attaches to ad-driven visits), and Google tries to match it to the original click. The match is what feeds Smart Bidding, Google’s automated bid strategies like Target CPA and Maximize Conversions.

The misread we see constantly: an account shows “Recording” or a green status indicator in the Enhanced Conversions for Leads diagnostics section, and the operator assumes the system is healthy. Meanwhile the actual match rate is sitting well below a healthy band, and Smart Bidding has been training on a broken shape for weeks.

If your tCPA is drifting, your CPL is climbing, and the Diagnostics tab still looks fine, the leak is happening somewhere between your form and Google’s matching engine. There are six places it can be. We will walk all of them.

Know Your Baseline Match Rate Before You Diagnose Anything

The “healthy” number depends on how you are sending data. Two delivery paths exist for ECL:

1. Form-layer (gtag UPD): User-Provided Data is captured by Google’s tag on the page when a lead submits the form. Email and phone get hashed and sent with the conversion event.
2. Offline upload: Your CRM (HubSpot, Salesforce, or a custom stack) sends conversions to Google Ads via the API or a scheduled file upload, with either a stored gclid or hashed user data.

The practical bands operators report differ for each path. Gtag UPD typically matches at the highest rate because user data is captured at the moment of conversion with click context intact. CRM-sourced uploads commonly land lower because the data has been through more hops.

If you are running a CRM upload at 40% and comparing it to gtag UPD numbers, you may not have a comparable problem at all. If you are running gtag UPD in the 30s, you definitely do. Always check the live thresholds in your account’s Diagnostics tab — Google flags accounts that fall below its current healthy band.

Segment match rate by source before you fix anything

The Diagnostics tab gives you one account-level number. That number hides everything. You need to break match rate down by lead source, by campaign, and by phone-format pattern. Two ways:

• Conversions > Sources report in Google Ads. This breaks observed vs. modeled attribution by conversion source. Fastest way to see if one source is dragging the average.
• BigQuery via Google Ads Data Transfer. If you have the transfer running, you can join conversion-action data with upload batch metadata to see match status by segment. The schema is documented in Google’s transfer docs.

If Your Phone Numbers Are Going Up as (555) 123-4567 You’ve Already Lost the Phone Match

This is the first layer to check because it is the most common silent failure across every lead-gen vertical we work in: insurance, mortgage, solar, home services, B2B lead gen. The pattern is the same.

Google’s offline conversion uploads expect phone numbers in E.164 format: a + sign, country code, and digits only. No parentheses, no dashes, no spaces. The format requirement is documented in Google Ads Help for hashed user-provided data.

What Google accepts:

• +15551234567 ✓
• +442071234567 ✓

What gets dropped or fails to match:

• (555) 123-4567 ✗
• 555-123-4567 ✗
• 5551234567 (no country code) ✗ in most cases
• +1 (555) 123-4567 ✗ (the space and parentheses break it)

If your CRM is exporting phones in the formatted U.S. style and your engineer is hashing that string and sending it to Google, the hash will not match the hash Google computed from the click-side data. You get zero credit for that phone field. The email might still match. The phone is dead weight.

On financial services and insurance stacks we audit, moving Salesforce phone exports from (555) 123-4567 to E.164 before hashing is one of the single largest match-rate jumps you can make with one change. The data was always there. The format was killing it.

Hashing rules: lowercase, trim, do not mix hashed and unhashed

The hashing layer has its own quiet failures. The rules per Google’s user-provided data formatting guidelines:

• Email: lowercase, trim leading and trailing whitespace, then SHA-256.
• Phone: E.164 format first, then SHA-256.
• Name and address: lowercase, trim, then SHA-256.
• Do not mix hashed and unhashed fields within the same conversion payload. Operator practice is to keep the entire record consistent so the API parses cleanly.

Hash client-side or let Google hash on ingest?

Unless compliance forces you otherwise, let Google hash it. Send the raw user data over HTTPS and let the Google Ads API normalize and hash it on receipt. Google’s normalizer handles edge cases that most custom hashers miss.

If compliance forces you to hash client-side, test your hashing function against a known-good test record. Sign up for an inbox, submit a form, then manually compute the hash and compare it to what arrived. One off-by-one whitespace error has cost accounts months of training data before anyone caught it.

Your CRM Is Probably Stripping gclid Before the Google Ads Sync Ever Runs

The gclid is the highest-fidelity matching signal Google has. It is a click ID, not a probabilistic match on hashed PII. When gclid is intact and uploaded, the match is essentially guaranteed.

The problem is that your CRM is probably destroying it before the sync runs, and you do not know.

The HubSpot and Salesforce workflow-ordering trap

Most CRMs have an automation layer that runs on contact create and contact update. The dangerous patterns we see repeatedly:

• Email normalization workflows in HubSpot. A workflow fires on contact create that lowercases the email and checks for duplicates. If it finds a duplicate, it merges. The merge often resets custom properties, including gclid, on the surviving record. The Google Ads sync runs later, finds no gclid, and falls back to UPD-only matching at a lower hit rate.
• Duplicate-detection rules in Salesforce. Same mechanism. A new lead with gclid populated gets merged into an existing contact, and the gclid field on the merged record is empty.
• Form-tool intermediaries (Typeform, Jotform, Gravity Forms) that pass to the CRM via Zapier or webhooks. Many do not capture gclid from the page URL by default. You have to wire it as a hidden field.

A 20-record gclid audit you can run this afternoon

Pull the 20 most recently created leads from your CRM that you know came from Google Ads. For each, check three things:

1. Is the gclid field populated?
2. Does the value look like a real gclid (a long alphanumeric string typically starting with letters like Cj0KCQ...)?
3. Does it match the gclid recorded in the original lead-capture log (form submission table, server log, or session record)?

If any of those fail on more than a couple of records, your CRM is your problem, not Google.

Running gclid upload and UPD upload together

Default recommendation: send both. Send the gclid when you have it, and send hashed user data as a fallback. Confirm the conversion action is set to “Count: One” for lead-form conversions, and that you are not running two separate conversion actions for the same event. We cover the broader signal architecture in our piece on server-side conversion tracking for insurance lead buyers.

Consent Mode v2 Quietly Downgrades ECL to Modeled-Only When ad_user_data Is Denied

This is the layer most troubleshooting articles skip, and it is increasingly the cause of unexplained match-rate drops in 2026.

Consent Mode v2 introduced two signals that gate ad-data usage: ad_user_data (whether user data can be sent to Google for advertising purposes) and ad_personalization (whether the data can be used for personalized ads). When ad_user_data is denied, ECL cannot use that user’s hashed PII for an observed match. Google falls back to modeled attribution, where the conversion gets estimated based on aggregate patterns rather than tied to a specific click.

Modeled attribution still feeds Smart Bidding, but the signal is noisier and the credit is statistical. It does not show up as an observed match.

Where this hides

The standard Diagnostics tab does not flag consent-driven downgrade. You have to look at the Conversions > Sources breakdown to see the observed vs. modeled split. If you see a high modeled share for a US-heavy account, something is off in your consent wiring. Most US traffic should default to granted for ad_user_data unless your banner explicitly defaults to denied.

Consent-legitimate vs. consent-misconfigured

Two different problems wear the same clothes:

• Consent-legitimate low match rate: You are running EEA, UK, or California traffic with a strict consent banner. A meaningful share of users deny ad_user_data. This is a real constraint, not a bug.
• Consent-misconfigured low match rate: Your banner defaults to denied, your consent update event fires after the conversion event, or Consent Mode v2 signals were never wired into your Google Tag Manager setup. This is a bug. Fix it and match rate recovers.

We wrote a deeper breakdown of how the recent simplified Consent Mode rollout has been costing US lead-gen advertisers matched conversions: Google’s Simplified Consent Mode Update Is Quietly Costing US Lead Gen Advertisers 8–15% of Matched Conversions.

Fix the Leaking Layer Without Resetting Smart Bidding’s Learning

Finding the leak is half the work. Fixing it without setting Smart Bidding back to zero is the other half.

How match-rate drops corrupt Smart Bidding

When match rate drops, Smart Bidding does not know that underlying conversions are still happening. It sees fewer conversions per dollar of spend, recalculates its CPA expectations, and either bids more conservatively or chases the modeled signal toward lower-quality lead segments. Per Google’s Smart Bidding documentation, the algorithm needs consistent, high-quality conversion data to optimize against. Visible CPL or CPA volatility usually shows up two to four weeks after the match-rate drop, well after the algorithm has absorbed the bad signal.

This is why a quarterly ECL audit is more useful than a one-time setup. The drift is slow enough to miss and fast enough to hurt.

The repair order that protects learning

Do these in this sequence:

1. Fix the leaking layer at the source. Update the CRM phone export to E.164. Reorder the HubSpot workflow so the Google Ads sync runs before email normalization. Wire the missing Consent Mode v2 signal. Whatever the diagnostic identified, fix it upstream so new conversions arrive clean.
2. Backfill recent conversions via offline upload. Google’s ECL upload accepts conversions up to 90 days old for click-based attribution, per the conversion adjustments docs. Pull the last 60–90 days of leads from your CRM, re-export with the corrected format, and upload them as adjustments. This repairs the historical record Smart Bidding is training on.
3. Do not touch bid strategy or conversion action settings during the fix. Changing the target CPA, switching bid strategy, or pausing and re-enabling the conversion action all reset or disrupt the learning phase. Let the corrected data flow into the existing strategy and let the algorithm absorb it.

Recovery timeline

Expect two to three weeks of stabilization after the fix before Smart Bidding’s CPA settles into the new shape. The first week often looks worse before it looks better, because the algorithm is reconciling the backfilled conversions against its recent expectations. Resist the urge to intervene. Patience here is worth more than any optimization you could make.

Verification: what healthy looks like at each layer

After the repair, walk the six layers one more time:

• Form layer: Test submission shows hashed email and hashed phone in the network payload, both in correct format.
• Hashing layer: Test record’s hash matches a manually computed reference hash.
• Normalization layer: Phone in E.164, email lowercased and trimmed, no mixed hashed and unhashed fields.
• CRM upload layer: Recent contacts retain gclid after all workflows have run.
• gclid persistence: Click ID flows from page URL to form submission to CRM record to Google Ads upload without being overwritten.
• Consent mode: ad_user_data and ad_personalization signals fire before the conversion event, and the default state matches your jurisdiction’s actual rule.

If all six pass, your match rate should land in the healthy band for your upload type within one full upload cycle.

Frequently Asked Questions

Why does my account-level ECL match rate look fine at 65% but one campaign is clearly mis-bidding?

Account-level match rate is an average. A single campaign or lead source can be matching at 20% while the rest of the account is at 75%, and the average looks healthy. Smart Bidding optimizes per-campaign, so it sees the 20% directly. Segment match rate by campaign and by lead source in the Conversions > Sources report or via BigQuery to find the offender.

Should I hash user data client-side or let Google hash it server-side?

Let Google hash it unless you have a specific compliance reason to do otherwise. Google’s server-side normalizer handles edge cases that most custom hashing functions miss. You generally get a higher match rate by sending raw data over HTTPS and letting Google normalize and hash on ingest.

How long does it take for ECL match-rate problems to corrupt Smart Bidding, and can I undo it?

Match-rate drops typically show up as CPL or CPA volatility two to four weeks after the drop. The fix is to repair the leaking layer at the source, backfill recent conversions via offline upload (up to 90 days back per Google’s conversion adjustments docs), and avoid touching bid strategy or conversion action settings during the repair. Expect two to three weeks of stabilization after the fix before bidding settles.

What phone format does Google Ads actually require for ECL uploads?

E.164 format: a + sign, country code, and digits only, with no spaces, parentheses, or dashes. A US number should look like +15551234567. Per Google’s hashed user-provided data documentation, formats like (555) 123-4567 or 555-123-4567 are not accepted and the resulting hash will not match Google’s click-side hash.

How does Consent Mode v2 affect ECL match rate?

When the ad_user_data signal is denied for a user, ECL cannot perform an observed match on that user’s hashed PII. Google falls back to modeled attribution, which estimates the conversion based on aggregate patterns. The downgrade does not appear in the standard Diagnostics tab. Check the Conversions > Sources breakdown to see the observed vs. modeled split.

Can I run gtag UPD and offline CRM upload at the same time without double-counting?

Yes, and it is usually the right move. Configure the conversion action with “Count: One” and make sure you are not running two separate conversion actions for the same lead event. Sending both paths gives you the highest possible match rate because each catches conversions the other misses.

Why does my CRM-sourced upload match lower than my gtag-sourced data?

This gap is normal and reflects the fidelity difference between the two paths. Gtag UPD captures user data at the moment of conversion with the click context intact. CRM uploads run later, after workflows, merges, and normalizations have had a chance to corrupt the data. Audit the CRM workflow ordering, the phone format on export, and the gclid persistence on the contact record.

Talk to Our Pay-Per-Call Team About Match Rate and Lead Quality

If you have walked the six layers and your match rate is still leaking, or if you are weighing whether fixing ECL is worth the engineering lift versus shifting to exclusive routed leads in your vertical, that is a conversation worth having. Our pay-per-call team works with insurance, home services, mortgage, and financial services buyers on both the paid-media side and the lead-routing side. Book a free strategy call with Elevarus to build a custom paid media plan, and ask about exclusive lead routing for your vertical and volume.