Enhanced Conversions for Leads and WordPress CRM Uploads
Enhanced conversions for leads relies on user-provided data and conversion context. If WordPress loses the email, phone, GCLID, consent, or CRM status, Google cannot match the lead cleanly.
Use this when a WordPress lead goes into HubSpot, Salesforce, Zoho, HighLevel, Pipedrive, or a custom CRM before being uploaded back to Google Ads.
Quick answer
Start with evidence, not a plugin setting. The first useful checks are: Capture the submitted email and phone in a field the CRM keeps. Hash only after normalization, not before trimming and lowercasing. Keep GCLID, GBRAID, WBRAID, UTM, landing page, and form ID with the lead record. Keep every change small enough to reverse.
Fast diagnosis map
Use this map before changing production. It helps separate a real platform issue from a cached page, stale setting, or missing handoff.
| Signal | What it means | Useful next check |
|---|---|---|
| Low match rate | Check access, users, or ownership first | Keep first-party identifiers |
| Only pageview counted | Look for a configuration, plugin, or data mismatch | Normalize then hash |
| CRM export missing click ID | Inspect the layer most likely to be hidden from the normal UI | Preserve click IDs |
| No consent timestamp | Prove whether the problem is still active | Upload qualified stages |
What to check first
- Capture the submitted email and phone in a field the CRM keeps.
- Hash only after normalization, not before trimming and lowercasing.
- Keep GCLID, GBRAID, WBRAID, UTM, landing page, and form ID with the lead record.
- Upload only the CRM milestone that matches the business goal.
- Compare uploaded conversions to real qualified opportunities, not raw form submissions.
Run a focused check
These commands or fields give you a useful starting point. Adapt paths, IDs, and privacy handling to the site before running anything on production.
normalized_email=$(printf '%s' "$EMAIL" | tr '[:upper:]' '[:lower:]' | xargs)
printf '%s' "$normalized_email" | shasum -a 256
required_fields:
- lead_id
- email_or_phone_hash
- click_id_when_available
- conversion_time
- conversion_action
- consent_timestamp
Safe fix order
Do the work in this order so each result can be verified. If a step fails, stop and capture the evidence before making a broader change.
- Keep first-party identifiers
- Normalize then hash
- Preserve click IDs
- Upload qualified stages
- Review diagnostics weekly
Verification checklist
The fix is not done when the warning disappears. Confirm the result from the visitor side, admin side, and reporting side.
- The CRM export includes the same lead ID as the WordPress form entry.
- Hashed values are deterministic across repeated exports.
- Raw personal data is not stored in logs used for debugging.
- Upload errors have owners and retry dates.
Mistakes to avoid
- Do not judge the result by the homepage only.
- Do not clear every cache layer until you know which layer affects the symptom.
- Do not delete evidence before copying filenames, timestamps, versions, and affected URLs.
- Do not make privacy or crawler decisions without writing down the business reason.
- Do not leave temporary debug settings, test accounts, or broad permissions in place.
When HandL WP should help
Bring in help when the issue affects leads, checkout, ads, malware risk, search visibility, or a client production site. HandL WP can trace the problem through WordPress, hosting, tracking, cache, and Search Console, then verify the business workflow after the technical fix.
If this is active on a production site, repair Google Ads lead attribution.