Google Ads

Google Ads Enhanced Conversions for Leads Consent Suppression

HandL WP Engineering·Jul 4, 2026

Enhanced conversions for leads can improve matching, but consent logic must decide what data is eligible for advertising upload. The WordPress form can still store and route the lead while suppressing hashed user data for Google Ads when consent is denied.

Use this for Elementor, Gravity Forms, Contact Form 7, booking forms, and custom WordPress forms that capture lead data and pass qualified outcomes to Google Ads.

Quick answer

Google Ads Enhanced Conversions for Leads Consent Suppression should be handled with a narrow evidence-first workflow: capture consent state, separate lead and ad rules, normalize identifiers, then verify the result before making broader changes.

What to check first

Record consent state at form submit and preserve it with the lead, not only in the browser session.
Separate operational lead storage from advertising upload eligibility in the CRM or upload queue.
Hash and upload user-provided data only when consent, policy, and account configuration allow it.
Keep click IDs, form IDs, and consent fields together so suppression can be audited later.
Test accepted, denied, unknown, and changed-consent paths before enabling automated uploads.

Diagnostic table

Use this table to keep the work practical. It connects the symptom to evidence and a verification step.

Action	Evidence to collect	How to verify
Capture consent state	Record consent state at form submit and preserve it with the lead, not only in the browser session.	Denied-consent leads remain in the CRM but do not enter the enhanced conversion payload.
Separate lead and ad rules	Separate operational lead storage from advertising upload eligibility in the CRM or upload queue.	Allowed-consent leads include normalized and hashed eligible fields only.
Normalize identifiers	Hash and upload user-provided data only when consent, policy, and account configuration allow it.	Retry jobs preserve the original consent decision unless a valid update is recorded.
Suppress in queue	Keep click IDs, form IDs, and consent fields together so suppression can be audited later.	Upload logs include accepted rows, skipped rows, and suppression reasons.

Why this usually happens

The form sends the lead to the CRM correctly but the upload queue does not read consent state.
Consent Mode is configured for tags, but server-side or offline uploads use a separate path.
A sales rep changes the lead stage without the original consent fields attached.
A retry job uploads previously suppressed user data because it only checks conversion status.

Field notes

Keep a suppression reason. Future audits need to know whether a row was skipped for missing consent, missing identifiers, bad formatting, or business qualification.
Consent handling may require legal review. The technical job is to make the data path auditable.

Useful command or data shape

Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.

lead_upload_decision:
  lead_id: EL-22018
  consent_ad_user_data: denied
  consent_ad_personalization: denied
  crm_status: qualified
  operational_record: keep
  enhanced_conversion_payload: suppress
  upload_note: qualified lead retained, ad user data not sent

Safe fix order

Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.

Capture consent state
Separate lead and ad rules
Normalize identifiers
Suppress in queue
Audit skipped rows

What to tell the client or owner

Explain to the marketing team that conversion quality can still be reported while ad user data is suppressed for leads that do not meet consent rules.

Production verification checklist

Denied-consent leads remain in the CRM but do not enter the enhanced conversion payload.
Allowed-consent leads include normalized and hashed eligible fields only.
Retry jobs preserve the original consent decision unless a valid update is recorded.
Upload logs include accepted rows, skipped rows, and suppression reasons.

Mistakes to avoid

Do not judge the fix by one browser or the homepage only.
Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
Do not add a cache, security, or tracking plugin while the original problem is still unclear.
Do not leave test users, temporary debug logs, or broad API keys active after verification.

When HandL WP should help

Bring in help when this affects leads, checkout, search visibility, malware risk, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.

If this is active on a production site, audit Google Ads lead tracking and consent handling.

Related HandL WP guides

Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.

Helpful references

Google Ads Consent Mode Lead Tracking