Meta browser and server events can share an event ID but arrive with timestamps that reflect different moments, timezones, queue delays, or retries. A drift audit connects the browser event, server event, lead record, and retry history.
Use this for WordPress lead forms, WooCommerce purchases, CRM events, and server-side Meta CAPI queues where deduplication or event quality looks inconsistent.
Quick answer
Meta CAPI Deduplication Event Time Drift Audit should be handled with a narrow evidence-first workflow: capture pair, normalize time, match business action, then verify the result before making broader changes.
What to check first
- Capture event name, event ID, browser time, server event time, receipt time, lead ID, and retry count.
- Normalize timestamps to UTC while preserving the original event time.
- Confirm browser and server events describe the same user action and business record.
- Find queue workers that replace original event time with retry or processing time.
- Test one normal event, one delayed event, and one retry with the same stable event ID.
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 pair | Capture event name, event ID, browser time, server event time, receipt time, lead ID, and retry count. | Browser and server events use the same stable event ID for one business action. |
| Normalize time | Normalize timestamps to UTC while preserving the original event time. | Original event time remains unchanged during queue retries. |
| Match business action | Confirm browser and server events describe the same user action and business record. | Drift and receipt delay stay within the team's documented operational threshold. |
| Fix retry clock | Find queue workers that replace original event time with retry or processing time. | Test Events and server logs show one deduplicated outcome. |
Why this usually happens
- Browser code and server code can create timestamps in different units or timezones.
- A retry worker may stamp the current time instead of preserving the original action time.
- The same event ID can be reused accidentally across different leads.
- Long CRM delays can turn a website lead event into a later business-stage event.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
event_pair:
event_name: Lead
event_id: lead_20491_submit
browser_event_time: 1783778472
server_event_time: 1783778474
received_at: 2026-07-11T14:01:15Z
retry_count: 0
drift_seconds: 2
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 pair
- Normalize time
- Match business action
- Fix retry clock
- Test drift cases
What to tell the client or owner
Share the tested event IDs, time units, timezone, drift, receipt delay, retry behavior, and any rows suppressed as mismatches.
Production verification checklist
- Browser and server events use the same stable event ID for one business action.
- Original event time remains unchanged during queue retries.
- Drift and receipt delay stay within the team's documented operational threshold.
- Test Events and server logs show one deduplicated outcome.
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, repair Meta CAPI deduplication for WordPress.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Block Meta CAPI timestamp drift before upload
Run the Meta CAPI event_time clock-skew test across browser time, server UTC, queue delay, retries, future clocks, and seconds-versus-milliseconds fixtures while preserving the original event ID and action time.
Monitor NTP drift on every WordPress Meta CAPI worker
Add the Meta CAPI NTP drift monitor for WordPress workers to preserve original action time, measure host offset and queue age, reject invalid units, and stop retries from mutating event_time or event ID.
Helpful references
Confirm the timestamp unit
When browser and server event times differ by orders of magnitude, use the Meta CAPI seconds versus milliseconds test before changing retry or deduplication logic.