The ideal tracking model for Meta
The complete architecture: browser pixel and Conversions API on the server sharing the same event_id, first-party identity to raise EMQ, and the checkout sale flowing back to the ad days later.
Browser-only tracking loses what ad blockers and iOS block. Server-only tracking loses the browser context (fbp, fbc) that lets Meta match the event to the click. The ideal model uses both — the same event through both paths, with the same event_id, and Meta discards the copy. This guide shows how CrazyLeads assembles it end to end.
The architecture in one picture
- 01The CrazyLeads pixel runs on the site: collects pageviews and events, captures fbclid, generates a first-party fbp and resolves the visitor’s identity.
- 02In the browser, the event goes to the Meta pixel (fbq) with a unique event_id.
- 03On the server, the same event goes out through the Conversions API with the SAME event_id — enriched with email, phone and geography from the identity graph.
- 04Meta deduplicates by event_id: counted once, with the best of both worlds.
Duplication is the most expensive mistake: an event counted twice inflates conversions, misleads the optimization algorithm and erodes trust in the number. event_id deduplication is not optional — it is the centerpiece of the model.
Event Match Quality: what drives your cost
EMQ (Event Match Quality) measures how much of the event Meta can link to a logged-in person. High EMQ = more attributed conversions = better optimization = lower CPA. Every user_data parameter adds up:
| Parameter | Where CrazyLeads gets it | Match weight |
|---|---|---|
| em / ph (email, phone) | Identity graph: forms, checkout, identify | The strongest |
| fbc (ad click) | Built from the fbclid on arrival — does not depend on the Meta cookie | Strong |
| fbp (browser cookie) | Generated first-party by the pixel; survives fbevents ad blocking | Strong |
| external_id | Stable lead ID in the CDP (sent hashed) | Medium |
| ct / st / zp (geography) | Address declared at checkout, else visit geolocation | Medium |
This is where a CDP changes the game: the Hotmart purchase event carries no cookie at all — but the graph knows which visitor became that buyer, and the CAPI event goes out with fbc, fbp, email and phone together. A server event with browser-grade matching.
The sale flowing back to the ad (server-side)
The click happens on your site; the purchase, on the Hotmart or Kiwify checkout — sometimes days later, on another device. The link is our identifier (cl_ussid) that the pixel injects into the checkout link (sck/xcod parameters). When the sale webhook arrives, the identifier ties the purchase to the visitor, and the Purchase goes out through CAPI with full attribution.
A rule learned in production: if your checkout builds sck with UTMs, put cl_ussid at the START of the template. Hotmart truncates the field at 283 characters — at the end, the identifier is always the victim; at the start, the cut only takes the UTM tail.
Setting it up in CrazyLeads
- 01Install the pixel on the site (see "Install the pixel") and register your Meta pixel on the source — fbq becomes mirrored with a shared event_id.
- 02Create the Meta CAPI destination under Deliveries, with a System User token from Events Manager, and test the connection.
- 03Create one Delivery per event that matters: Purchase (approved sale), Lead, InitiateCheckout — with filter (e.g. status APPROVED) and mapping measured against real events on the screen itself.
- 04Check parameter coverage (em, ph, fbc, fbp) on the destination’s Quality panel — and EMQ plus deduplication in Events Manager.
The ideal model checklist
- Browser AND server sending the same event with the same event_id (dedup visible in Events Manager).
- Purchase firing ONCE per sale — approved sale, not generated boleto nor expired PIX.
- fbc and fbp present on most events (coverage on the Quality panel).
- Email and phone arriving on bottom-of-funnel events.
- cl_ussid at the start of the checkout sck.
- test_event_code used BEFORE real traffic goes live.
The why of each piece — and the mistakes we have watched cost real money — is in the full blog article on the ideal tracking model, with payload details in the Deliveries technical reference.