event_id and deduplication

If the same conversion reaches your pixel twice, Meta counts it twice — and your optimisation, reporting and audiences all drift. The fix is a stable event_id: a fingerprint that lets Meta recognise and drop duplicates.

How the event_id is built

Most builds the identity of every event like this:

event_id = {sub_id}_{event_name}_{UTC conversion time}

where the time key is YYYYMMDDTHHMMSSffffffZ — the conversion's timestamp in UTC, down to the microsecond. Because the preview, the sending worker and Meta's own dedup all use this exact same key, one conversion has one identity everywhere.

Three layers that prevent duplicates

1. In the database — a conversion is unique on (click_id, status, datetime), so one Keitaro conversion is stored once.
2. Before sending — the worker checks (pixel_id, conversion_id, event_name) and skips pairs it has already written, so re-runs can't double-send locally.
3. At Meta — events already sent successfully (sent or partial) are excluded by their event_id before the next batch, and Meta deduplicates on event_id as a final safety net.

Failed events are the exception by design: error rows don't block a retry, so a conversion that errored once is sent again next run.

Why the time is clamped but the id isn't

Meta rejects events older than 7 days — the same error 2804003 you'd see in Events Manager — so Most clamps the outgoing event_time into a safe window. The event_id, though, is always built from the original conversion time — clamping the delivery time never changes the event's identity, so deduplication stays correct. More on the window in pixel warming.

What this means for you

You can re-run loads, do incremental syncs, and warm a pixel repeatedly without fear: the same conversion is sent once. That's automatic in Most.

Sources