Meta Conversions API events can be rejected, delayed, misattributed, or deduplicated incorrectly when event_time is generated from a server with clock drift, encoded in milliseconds instead of seconds, converted through a local timezone, replaced during a retry, or set to the queue-processing time. A successful HTTP response alone does not prove the event timestamp is useful.
Use this for WordPress leads, WooCommerce purchases, CRM-qualified leads, offline conversions, queue workers, webhook retries, and browser plus server Meta event deduplication.
Quick answer
For one controlled event, preserve the browser action time, original server receive time, normalized Unix seconds event_time, queue enqueue time, every upload attempt, current server UTC, event ID, and Meta response. Calculate future skew and queue age. Retries must keep the original event_time and event ID, while the attempt time changes. Reject local payloads with milliseconds, implausible future values, or timestamps older than policy before sending.
What to check first
- Record browser UTC, server UTC, NTP status, application timezone, database timezone, queue timezone, and worker host for one event.
- Capture event ID, event_name, event_time, enqueue time, attempt time, retry number, HTTP response, and Meta diagnostic identifiers.
- Calculate whether event_time is Unix seconds, milliseconds, a formatted string, future-skewed, or replaced by the worker clock.
- Compare the browser Pixel event and server CAPI event for the same event ID and original customer action.
- Simulate delayed queue processing, retry, daylight-saving boundary, server clock drift, and seconds-versus-milliseconds fixtures.
Why this usually happens
- JavaScript Date.now returns milliseconds while many conversion APIs expect Unix seconds.
- Retry workers often rebuild the whole payload and accidentally replace original event data with attempt-time values.
- Containers, database servers, browsers, and WordPress can expose different clocks and timezones even when logs look readable.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
event_id,event_time,server_now,queue_age_s,future_skew_s,attempt,meta_state
lead-8812,1786539600,1786539608,8,-8,1,accepted
purchase-441,1786532400,1786539600,7200,-7200,3,accepted
lead-8813,1786540320,1786539600,0,720,1,blocked_local
lead-8814,1786539600000,1786539600,0,huge,1,blocked_schema
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Choose one UTC source for the original customer action time. | Record browser UTC, server UTC, NTP status, application timezone, database timezone, queue timezone, and worker host for one event. | Normal events have plausible UTC time and low measured transport delay. |
| Convert event_time to integer Unix seconds at the event boundary. | Capture event ID, event_name, event_time, enqueue time, attempt time, retry number, HTTP response, and Meta diagnostic identifiers. | Delayed retries keep the original event_time and event ID. |
| Persist original event_time and event ID before enqueueing. | Calculate whether event_time is Unix seconds, milliseconds, a formatted string, future-skewed, or replaced by the worker clock. | Future-skewed and millisecond fixtures are blocked before upload. |
| Add local guards for units, future skew, queue age, and missing timestamps. | Compare the browser Pixel event and server CAPI event for the same event ID and original customer action. | Browser and server events deduplicate without losing the original action time. |
Decision rule
Approve when event_time consistently represents the original action in Unix seconds, retries preserve it, clock drift is monitored, invalid units fail locally, and Meta diagnostics join to the same stable event ID.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Normal event | Server sends within 10 seconds | Accepted with event_time near the customer action |
| Delayed queue | Worker runs two hours later | Original event_time and event ID remain unchanged |
| Future clock | Worker host is 12 minutes ahead | Local guard blocks or corrects the payload |
| Millisecond value | 13-digit event_time | Schema guard rejects before API upload |
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Choose one UTC source for the original customer action time.
- Convert event_time to integer Unix seconds at the event boundary.
- Persist original event_time and event ID before enqueueing.
- Add local guards for units, future skew, queue age, and missing timestamps.
- Verify Meta acceptance, deduplication, diagnostics, and attributed event state with a controlled fixture.
Production verification checklist
- Normal events have plausible UTC time and low measured transport delay.
- Delayed retries keep the original event_time and event ID.
- Future-skewed and millisecond fixtures are blocked before upload.
- Browser and server events deduplicate without losing the original action time.
What to tell the client or owner
Give the owner the affected versions, exact fixture, stable IDs, UTC timeline, before and after evidence, decision, rollback point, unresolved risks, and next review date.
Mistakes to avoid
- Do not change several production layers at once. Preserve the failing evidence and isolate one variable per test.
- Do not use a successful status or screen message as the only proof. Verify the business outcome and the underlying record.
- Do not leave debug logging, broad credentials, test orders, or temporary exceptions active after the review.
- Do not close the incident without recording the fixture, timestamps, owner, result, and rollback point.
Questions teams ask during testing
Can this be tested on staging?
Start on staging with production-like versions, cache, data shape, and integrations. Finish with one controlled production fixture when the result depends on real routing, provider, or edge behavior.
What evidence should be retained?
Keep the smallest useful set: stable IDs, UTC timestamps, sanitized request or log excerpts, expected result, actual result, version inventory, and the final verification.
When should the change be rolled back?
Roll back when a revenue, privacy, security, or publishing path fails and the cause cannot be isolated inside the approved maintenance window.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, 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 Meta CAPI timestamps.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references