Run the Conversions API with the pixel, or instead of it

What this step is

Step 44 (Part VII) is marked hard difficulty, often skipped. It sits one step past basic event tracking because it requires two systems (browser pixel, server event) to agree on one purchase rather than count it twice.

Why both, and how they merge

A server-side event is the same message as a pixel event, sent from the payment system or server instead of the visitor's browser. Nothing on the visitor's side can block it, and a tab closed on the thank-you page can't lose it. A deduplication identifier, minted once per purchase and sent with both the browser event and the server event, is what lets the platform merge the two into one counted sale instead of two. The deduplication window used here is 48 hours.

Fire the browser event first, because the matching window is short. Run the Conversions API alongside the pixel, never instead of it, and check the deduplication rate within a day of launch to confirm the two are merging rather than double counting.

Event Match Quality and product-scoped conversions

Read Event Match Quality per event, aiming for six or better out of ten. Give each product its own conversion definition rather than a shared one; a shared definition teaches the delivery system to chase a blend of buyers nobody chose.

What done looks like

Pixel and server-side events both firing on every purchase, matched by one deduplication identifier, checked for dedup rate within a day of launch, Event Match Quality at six or better, and a conversion definition scoped to one product.

Where it breaks

A browser-only purchase lost when a visitor closes the tab before the pixel fires. A shared conversion definition across several products, which blends buyer types the business never intended to target as one audience.