When a Meta Conversions API request times out, WordPress or a queue worker may retry it. Generating a new event ID for each attempt can turn one lead or purchase into several logical events, while changing key payload fields between attempts makes diagnostics and deduplication harder to trust.
Use this for WordPress forms, WooCommerce orders, membership signups, or CRM lead events sent through both Meta Pixel and Conversions API with a server retry queue.
Quick answer
Generate one stable event ID when the business event is accepted, share it with the browser event, and persist it with the canonical server payload. Every retry must reuse that event ID and logical event time. Track attempt time separately, classify temporary versus permanent errors, and close the queue only after an accepted or terminal outcome.
What to check first
- Define the business moment that creates the event ID, such as accepted form entry or paid order transition.
- Persist event name, original event ID, logical event time, source URL, action source, consent state, and normalized user data before sending.
- Reuse the identical event ID and stable logical fields for every temporary retry.
- Record attempt number, attempt time, HTTP result, Meta trace or diagnostics, and next action separately from the payload.
- Compare browser and server events in Meta diagnostics for deduplication rather than merely counting two network requests.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Choose the accepted business event and generate its stable ID once. | Define the business moment that creates the event ID, such as accepted form entry or paid order transition. | Browser and server channels use the same event name and original event ID. |
| Persist the canonical payload and consent state before delivery attempts. | Persist event name, original event ID, logical event time, source URL, action source, consent state, and normalized user data before sending. | Every server retry preserves stable logical fields and records attempt metadata separately. |
| Change retry workers to reuse event ID and logical event time. | Reuse the identical event ID and stable logical fields for every temporary retry. | Timeout recovery produces one logical event in Meta diagnostics. |
| Classify temporary, permanent, duplicate, and accepted outcomes with bounded retries. | Record attempt number, attempt time, HTTP result, Meta trace or diagnostics, and next action separately from the payload. | Permanent errors stop retry and expose a repairable reason without leaking user data. |
Why this usually happens
- Retry code often calls the same event-construction function that generates a new random identifier.
- A network timeout does not prove Meta rejected the first request, so a new ID risks double counting.
- Browser events may derive IDs from the page while server events derive them from a later webhook or job.
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_id: lead_8a921f4c
event_time: 1786369231
action_source: website
event_source_url: https://example.com/contact
attempt: 2
attempt_time: 2026-08-10T14:22:18Z
retry_reason: transport_timeout
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 |
|---|
| Browser and server success | One accepted form with shared event ID | Meta receives two channels and treats them as one logical event |
| Server timeout | First server attempt times out, second succeeds | Both attempts reuse the original event ID and only one event is counted |
| Permanent validation error | Malformed test parameter | Queue stops automatic retry and exposes the field error for repair |
| Page revisit | Reload thank-you page after acceptance | No second business event ID is generated for the same lead |
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 the accepted business event and generate its stable ID once.
- Persist the canonical payload and consent state before delivery attempts.
- Change retry workers to reuse event ID and logical event time.
- Classify temporary, permanent, duplicate, and accepted outcomes with bounded retries.
- Run browser, timeout, invalid-payload, and revisit fixtures in Meta diagnostics.
Decision rule
Retry only temporary transport or service failures with the original event ID and canonical payload. Stop and repair permanent data errors. Never issue a fresh ID merely because the prior response is uncertain.
Production verification checklist
- Browser and server channels use the same event name and original event ID.
- Every server retry preserves stable logical fields and records attempt metadata separately.
- Timeout recovery produces one logical event in Meta diagnostics.
- Permanent errors stop retry and expose a repairable reason without leaking user data.
Field notes
- Keep the stable ID free of raw email, phone, or customer names.
- Store the original event time separately from each delivery attempt time.
- A successful HTTP response is not the same as proven deduplication. Review platform diagnostics and event counts.
Questions teams ask during testing
What if the first attempt timed out after Meta accepted it?
Reuse the original event ID. That is the case deduplication is meant to protect.
Can browser and server event times differ?
Minor transport differences occur, but both should describe the same business event and share the stable ID.
How many retries should run?
Use bounded backoff appropriate to the error and business deadline, then surface unresolved events to an owner.
Mistakes to avoid
- Do not create a new event ID for each retry attempt.
- Do not use page-load time as a replacement for the original accepted event time.
- Do not retry permanent validation errors indefinitely.
- Do not place unhashed personal data in queue logs or event IDs.
What to tell the client or owner
Give the owner the business trigger, browser and server event IDs, original event time, attempt history, retry classifications, Meta diagnostics result, counted outcome, and unresolved queue IDs.
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, verify Meta browser and server event deduplication.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references