Meta's recommended browser/server deduplication method matches the event name and event ID for the same occurrence sent to the same Pixel. Coordinate the browser eventID and server event_id, preserve that identity on retries, and give genuinely different actions different identities. Build your own safeguards against accidental repeat emissions as well.
What to take away
- Create an identifier for the business occurrence, not for each network request.
- Share the same identity and event meaning between browser and server.
- Test refreshes, retries, and delayed delivery before trusting aggregate counts.
1. Give the occurrence an identity
Imagine a registration operation that creates one account. Your application can persist an opaque occurrence identifier when that operation succeeds. The browser receives the identifier with its confirmation, and the server's delivery record stores the same value. Both channels now refer to the same event.
A person identifier alone is the wrong abstraction for events that can happen repeatedly. One person can perform several legitimate actions. A browser session is also too broad. Keep identity tied to the specific occurrence, and avoid putting personal information into the identifier itself.
2. Coordinate the whole event contract
The browser field is eventID; the Conversions API field is event_id. The event names must also correspond. Meta documents a 48-hour receipt window for matching these browser and server copies. Deliver promptly rather than treating deduplication as a permanent archival reconciliation service.
Your team should agree on the destination dataset and business meaning as part of the same contract. Two systems using the same ID while describing different actions is a modeling defect. A frontend release that renames the event independently of the backend can also break an otherwise sound integration.
| Situation | Identity decision |
|---|---|
| Browser and server describe one signup | Use the same occurrence identity |
| Server retries delivery after a timeout | Reuse the original identity |
| A distinct legitimate action occurs later | Create a distinct occurrence identity |
| Confirmation page is refreshed | Do not create a new business occurrence |
3. Separate retry attempts from new outcomes
A timeout creates uncertainty about delivery, not a second registration. Store attempt count, last response, and next retry time beside the original event record. These operational fields can change without changing the event's identity or the time the customer action happened.
Meta's API guidance recommends stable event IDs for retry deduplication. Still, make the sending application idempotent: processing a repeated business message should not create another outcome record. External deduplication complements this control; it should not be the only defense against a worker consuming the same message repeatedly.
4. Trace one example through both channels
Start with an isolated, controlled test occurrence. Capture a sanitized trace containing the business record reference, destination, event name, occurrence ID, and send time for each channel. Inspect the event diagnostics and check that your intended correspondence is visible.
Do not start by celebrating a percentage in a dashboard. An aggregate can hide two mistakes that partially cancel each other: missing server events and duplicate browser events, for example. A single complete trace is easier to explain and gives the team a concrete reference for later failures.
5. Test the inconvenient journeys
Run a failure matrix around that known example. Keep the expected business count written down before each test. Test infrastructure should isolate synthetic activity from production measurement, including when using diagnostic codes or preview tools.
- Reload the success view and confirm that no new occurrence is invented.
- Lose the server response and retry the existing delivery record.
- Open two tabs that observe the same completed action.
- Delay one channel and inspect the resulting diagnostics.
- Temporarily remove the browser copy and verify the server's independent path.
- Perform a second legitimate action and confirm that its identity is different.
6. Monitor the boundary after every release
Use a release checklist whenever registration logic, tag management, event mapping, or queue behavior changes. Compare source records with intended emissions and investigate a sudden shift in browser/server coverage. Deduplication cannot compensate for sending the wrong business event or for sharing data without the required permission.
Assign ownership of the shared contract, including version changes. In an iGaming team, this often crosses product engineering and acquisition operations. Advellar's tracking support can help surface the required checks around managed Meta access, while the implementation owner maintains the event identity system.
Quick questions
Should every CAPI retry get a new event_id?
No. A retry is another delivery attempt for the same occurrence. Keep the original identity and occurrence time, and record the retry separately in your operational logs.
Can the browser and server generate random IDs separately?
Not for the same occurrence. Independently generated values will differ. Generate or assign the identity once, persist it, and share it through the approved application flow.
Does deduplication prove that campaign attribution is correct?
No. It addresses overlapping event copies. Event eligibility, matching, attribution settings, reporting timing, and the underlying business definition still need their own checks.
Sources & further reading
A clearer way to run your Meta workflow.
Bring your account setup, campaigns and reporting into Advellar.
Create your workspace