Event ID: the value that lets two systems agree a conversion happened once

An event ID is the value two systems use to agree they are describing the same conversion. The browser sends one copy of a purchase, your server sends another, and the platform matches them on that value and counts one. How you generate it follows entirely from the guarantee it has to keep, so state the guarantee first.

• Identical on both transports. Not similar, not derived by 2 different routines — the same string of characters.
• Stable across retries. A refresh, a retry or a queued send hours later must reproduce the same value, or 1 conversion becomes 2.
• Distinct per genuine conversion. Two orders in the same second must not collide, and a returning customer must not reuse the first value.
• Present before either send. If the server mints it after the browser fired, there is nothing to match on.

Four places the value can come from

For purchases the order identifier is usually right: it satisfies 3 of the 4 properties and is reproducible from your own records. For non-order conversions — a lead form, a call, a signup — mint the value server-side when the conversion becomes true. The browser-random strategy produces double counts in week 1; the payload hash produces them in month 6, when an amount field starts serialising as 49.00 instead of 49.

A correlation key, not a primary key

The distinction saves a lot of argument. A primary key identifies a row in a system you control, for as long as that row exists. A correlation key only has to let two independent systems recognise the same occurrence inside a bounded window, and may be discarded afterwards. A primary key you own makes a good event ID; a good event ID is not automatically safe as a primary key, because nothing guarantees it is unique outside the window.

Advertising systems make this distinction constantly, and getting it wrong is how counts drift apart: an occurrence and the record of it are separate things with separate rules, the point in win notice and billable event are not the same.

Wiring it so both copies agree

1. Mint or read the value when the conversion becomes true — the order commits — not when a tag happens to fire.
2. Write it to your record of the order and to the page's data layer in the same operation, as a declared field rather than an ad-hoc variable: see the data layer as a versioned contract.
3. Have both senders read it from that 1 place. A browser tag constructing its own value and a server job constructing another agree until the day they do not.
4. Log it on both sides with the send timestamp and the response, so a mismatch is a query rather than an investigation.
5. Reconcile daily: browser sends, server sends, distinct identifiers. Three numbers with an obvious relationship, and a small internal tools and ops job to raise it when they diverge.

Two systems do not agree that a conversion happened once because they are both correct. They agree because someone gave them the same string to compare.

Where the value shows up afterwards

In a raw analytics export the identifier is a parameter rather than a column, which matters to anyone writing SQL against it — the shape is in what one row of the event export holds. In a platform interface it is invisible: you see the deduplicated count, not the matching, so a divergence is diagnosed from your own logs first. That investigation is its own subject, in the ad platform counts more conversions than you do.

The identifier is one field in a larger payload contract, and the rest of that contract sits under tracking, consent and event pipelines in the marketing and advertising practice.

• deduplication
• conversion tracking
• event pipelines
• identifiers