One purchase. Two paths. One shared event ID.

Identify the action before the send

A browser event and a server event can describe the same purchase. That is useful only if the receiving platform can recognize their relationship. Treat the purchase as one business action with two possible delivery paths, and decide how both paths obtain the same event identity.

Meta's documentation states that the Pixel eventID must match the corresponding Conversions API event_id. It also identifies event_name and event_id as deduplication parameters. These details deserve an explicit place in the event specification, rather than being added as an afterthought during troubleshooting.

Generate once, reuse deliberately

Choose a point in your application flow where the action is known and its identity can be made available to both implementations. Avoid generating an unrelated random value separately in the browser tag and the server tag. Two unique values may each be valid identifiers while failing to describe the same action.

Define how the identifier behaves when a page reloads, a request retries, or a customer places a second order. A repeated delivery of the same action should remain recognizable. A genuinely new action needs its own identity. Have the implementation owner document this behavior so that future changes preserve it.

Test a pair, then test exceptions

For a known test purchase, capture the event name and identifier from both delivery paths. Compare the values exactly, including capitalization and formatting. Also confirm that both paths are intended for the same Meta data source and represent the same business action.

Next, test the less tidy journeys. Reload the confirmation page. Exercise the application's retry behavior in a safe environment. Place a second test order. Record the expected identity in each case before evaluating the result. This checks the design itself, instead of only demonstrating that two requests can be sent.

• Same action: matching event identity across browser and server.
• Repeated delivery: stable identity according to the event design.
• New action: a new identity, with the intended event name.

Keep the rollout explainable

Inventory existing integrations before adding another delivery path. A theme script, a platform integration, and a tag-manager configuration may need different owners during review. Keep the confirmed test pair and the integration inventory in the handover notes.

Use current Meta documentation to check all API requirements and diagnostics before launch. Deduplication is one part of a complete implementation; on its own, it does not confirm that every required field or consent behavior is configured.