Three settings people skip in Meta's Conversions API
Matching browser events with server-side ones breaks on day one in most accounts. Event ID, deduplication and test events belong at the start of the setup, not the end.
A Conversions API setup usually ends like this: the server sends events, events show up in the dashboard, everyone calls it done. A week later someone notices conversions look inflated and nobody knows which number to trust.
The cause is normally one of three settings. Done on the first day they take ten minutes; done later, the historical data cannot be recovered.
One · The event ID has to be identical on both sides
If the same purchase is sent from both the browser and the server, the only way the platform can tell they are one event is a shared identifier. That identifier must carry the same value on both sides and be derived from the event itself — an order number, for instance. An ID generated in the browser and never passed to the server has exactly the same effect as no ID at all.
Two · Deduplication has a time window
Deduplication does not look back forever. If the gap between the browser event and the server event widens — because server-side events are batched and sent overnight, say — the matching window closes and the two are counted separately. Batching looks convenient, and that is precisely why it is the most common source of double counting.
The safest approach is to send server events within the same minutes as the browser event, even if not in the same request. If a delay is unavoidable, choose it deliberately and accept the window knowingly.
Three · Test events get turned OFF before launch
The test event code used during setup, left in place afterwards, sends real events into the test stream. They keep appearing in the dashboard but never enter optimisation. This is the hardest setup error to diagnose: everything looks like it works, there are simply no results.
Before you call the setup finished
- Make a test purchase and confirm the event appears on both the browser and the server side but is counted as one conversion.
- Check event match quality on several consecutive days; setups that look fine on day one and degrade afterwards are common.
- Verify in the code, not in the dashboard, that the test event code is absent from production.
- Measure how many seconds behind your server events are, and write that number down somewhere.
No performance decision taken before those four is trustworthy — if measurement is broken then optimisation is broken too, and automation makes its decisions on that same broken measurement.