Meta Pixel lead tracking should not be checked only by seeing a browser event fire. A useful audit verifies consent state, event ID, browser event, optional server event, CRM record, and duplicate handling.
Use this for WordPress lead forms, Elementor Forms, Gravity Forms, WPForms, Contact Form 7, landing pages, and campaigns where Meta Ads lead reporting does not match the CRM.
Quick answer
Meta Pixel WordPress Lead Tracking Consent Audit should be handled with a narrow evidence-first workflow: test consent states, set event id, match crm lead, then verify the result before making broader changes.
What to check first
- Test denied, granted, and missing consent states before checking the event.
- Confirm the browser lead event includes a stable event ID when server events are also sent.
- Match form submission ID, CRM lead ID, landing page, and event time.
- Check whether hashed customer data is only sent when policy and consent allow it.
- Review duplicate, missing, and delayed events in the same time window.
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 |
|---|---|---|
| Test consent states | Test denied, granted, and missing consent states before checking the event. | Denied consent does not send restricted advertising data. |
| Set event ID | Confirm the browser lead event includes a stable event ID when server events are also sent. | Browser and server events share the same event ID when both are used. |
| Match CRM lead | Match form submission ID, CRM lead ID, landing page, and event time. | Each valid form submission maps to one CRM lead. |
| Check server event | Check whether hashed customer data is only sent when policy and consent allow it. | Duplicate event warnings are understood and documented. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
meta_lead_event:
event_name: Lead
event_id: lead-29481
source: browser_and_server
consent_state: granted
form_id: elementor-consultation
crm_id: HS-77311
dedupe_expected: true
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.
- Test consent states
- Set event ID
- Match CRM lead
- Check server event
- Review dedupe
Production verification checklist
- Denied consent does not send restricted advertising data.
- Browser and server events share the same event ID when both are used.
- Each valid form submission maps to one CRM lead.
- Duplicate event warnings are understood and documented.
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 WordPress lead tracking.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.