An event ID should answer “Which business action is this?” A request ID answers “Which delivery attempt is this?” Confusing those questions is a common design route to duplicate or missing conversion events. For a ChatGPT measurement integration, define the business identity before writing separate browser and server senders.
The contract is an agreement between the systems that observe the action. It specifies when identity is created, where it is stored, how it reaches each sender and when a genuinely new action needs a new value. This article concerns that preventive design. Duplicate-event troubleshooting investigates an implementation that is already producing suspicious results.
Start from the business event boundary
For a purchase, decide which authoritative action means the purchase is complete in your business system. Do not casually use a page load as the identity boundary if the same confirmation page can be loaded repeatedly. A reload is a new browser action but not necessarily a new purchase.
For a lead, decide whether a corrected submission is the same lead action or a separate one under your measurement definition. The technical identifier cannot resolve an undefined business rule. Write that rule with the business owner before deciding whether an existing record key is suitable.
Avoid tying identity to a mutable value such as the current order total. A price correction should not silently create a new apparent purchase because the ID formula includes the amount. Identity and event attributes have different responsibilities.
Assign ownership of ID creation
Choose one component to create or derive the action identity and persist it with the business record. Other components should receive that identity rather than generating their own substitutes. In a typical internal design, the authoritative backend can expose an appropriate event identifier to the permitted browser flow after confirmation.
That is an architectural recommendation, not a universal requirement that every website use the same implementation. Some systems already have stable event identities; others need a dedicated field. Check the platform’s current identifier requirements and your own privacy constraints before adopting a format.
Do not put an email address, phone number or other unnecessary personal value into the identifier. Use an opaque or otherwise appropriate internal representation. The purpose is to distinguish actions, not to embed customer details in logs and network messages.
Specify the cross-route mapping
Map the browser’s event_id option to the server event’s id field. Both must describe the same action and use the same Pixel ID and event name; custom events also need matching custom_event_name. Put those field names in the contract so implementation teams can compare their payloads directly with the OpenAI conversion setup examples.
Write a concrete example with invented identifiers. Action purchase-example-82 might be persisted once, sent through the browser and reused by the server. A server timeout followed by another attempt keeps purchase-example-82. The next genuine purchase receives another identity.
Include custom event naming in the contract when applicable. An identical identifier attached to inconsistent event names does not express a consistent event contract. Event-name governance covers how names remain stable as teams add new actions.
Identity follows the action
- Create once
Assign identity when the defined action becomes real.
- Share the value
Browser and server use the same persisted event identity.
- Retain on retry
A new delivery reuses the ID; a new action receives another.
Define lifetime and collision handling
Specify how long the business system retains the identity for retry and diagnosis purposes under its policy. Do not invent a platform deduplication retention guarantee. Your internal retention requirement should be based on supported delivery behavior and the operational recovery window you need.
Decide what happens if an identifier is unexpectedly reused for a distinct action. The system should surface the conflict rather than quietly substituting a random value only on one route. A one-sided repair can break browser/server matching and leave the original collision unexplained.
Consider multiple stores, environments or tenants where internal order numbers may repeat. The identity design needs enough context to avoid unintended collisions within the relevant source and event scope. Keep test and production configuration explicit rather than relying on a developer remembering which environment is active.
Turn the contract into executable examples
Define a small test matrix: one action delivered once, the same action retried, both routes delivering the same action, two distinct actions and a confirmation-page reload. State the expected identity relationship for each case before implementation begins.
The tests should verify the identity values themselves, not only successful HTTP responses. A valid request can still carry the wrong action ID. Also verify that a retry preserves the original business timestamp and attributes according to the supported event semantics rather than inventing a new action history.
Keep the contract with the integration owner and review it when checkout, forms or sending infrastructure changes. Source auditing checks where the resulting messages go. The platform references are OpenAI Conversions API and Measurement Pixel. A good ID design makes retries boring because every sender agrees which business action it is describing.
Sources and scope
Specify how one business action receives and shares a durable event identity before browser and server integrations are implemented.
Working methods and examples are editorial suggestions. Check current platform requirements and available features before implementation.