A WordPress form, WooCommerce order, or CRM stage can wait in a queue before Meta Conversions API receives it. If the worker sets event_time to the retry time, browser and server events can drift apart, deduplication becomes harder to interpret, and reporting assigns the conversion later than it occurred.
Use this when Meta CAPI events are retried after network errors, rate limits, CRM delays, consent checks, or queue outages and Events Manager reports timing or deduplication concerns.
Quick answer
Meta CAPI Queue Delay and Original Event Time Policy should be handled with a narrow evidence-first workflow: capture original seconds, persist event id, separate queue timestamps, then verify the result before making broader changes.
What to check first
- Capture original event time in Unix seconds at the accepted form, order, or CRM transition.
- Store the same stable event ID with the original timestamp before the event enters the queue.
- Record queued_at, attempted_at, retry_count, consent snapshot, and final provider response separately.
- Set an age policy that holds or discards events that are too old for the business and platform rules.
- Compare one browser and server test pair in Events Manager after a controlled queue delay.
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 original seconds | Capture original event time in Unix seconds at the accepted form, order, or CRM transition. | Every retry retains the original event_time and event_id. |
| Persist event ID | Store the same stable event ID with the original timestamp before the event enters the queue. | Queue timestamps explain processing delay without changing conversion time. |
| Separate queue timestamps | Record queued_at, attempted_at, retry_count, consent snapshot, and final provider response separately. | Browser and server test events pair as expected after the controlled delay. |
| Set age policy | Set an age policy that holds or discards events that are too old for the business and platform rules. | Expired or consent-ineligible events follow a documented hold or discard policy. |
Why this usually happens
- Workers often generate timestamps from the current clock during each retry.
- Milliseconds can be sent where the endpoint expects Unix seconds.
- The event ID can be regenerated with each queue attempt.
- Consent state may change while the event waits and requires an explicit policy decision.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
{
"event_name": "Lead",
"event_time": 1784041331,
"event_id": "lead_01J2W8N6",
"action_source": "website",
"queue_meta": { "queued_at": 1784041332, "attempted_at": 1784041991, "retry_count": 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 original seconds
- Persist event ID
- Separate queue timestamps
- Set age policy
- Test browser pairing
What to tell the client or owner
Provide event name, original event time, event ID, queued time, attempt times, retry count, server clock offset, consent snapshot, provider result, and deduplication outcome.
Production verification checklist
- Every retry retains the original event_time and event_id.
- Queue timestamps explain processing delay without changing conversion time.
- Browser and server test events pair as expected after the controlled delay.
- Expired or consent-ineligible events follow a documented hold or discard policy.
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, fix Meta CAPI event timing.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references
Close events that should no longer be replayed
Preserving original event_time is necessary, but not every backlog item should retry forever. Use the Meta CAPI queue age, discard, and replay policy to classify temporary errors, repairable data, consent exclusions, and events outside the accepted age.