How it works

Follow one order from the ad to Meta

Nine steps, with the actual payload at each one. Press play, or use the arrow keys.

1 / 9 · ← →

Step 1 · Browser

A shopper taps your Meta ad

The landing URL carries fbclid. The Trakero SDK, loaded from your own subdomain, stores it as a first-party _fbc cookie and records the first touch. Nothing is sent to Meta from the browser.

first-party cookies on shop.com.bd

_cdt_vid  v_7c1f…           365 days
_cdt_sid  s_91ab…           30 min, rolling
_fbc      fb.1.1727440000000.IwAR2xK…
_fbp      fb.1.1727440000000.8812349912
_cdt_ft   {"source":"facebook","medium":"cpc","click_id_type":"fbclid"}

A shopper taps your Meta ad. The landing URL carries fbclid. The Trakero SDK, loaded from your own subdomain, stores it as a first-party _fbc cookie and records the first touch. Nothing is sent to Meta from the browser.

She buys. The thank-you page reports the purchase. The SDK posts the purchase as text/plain, so there is no CORS preflight, and to your own subdomain, so blockers that target tracking domains don't match it. If the tab closes, sendBeacon still delivers it.

Ingestion validates and hashes, before anything is stored. Validation, phone normalization (Bengali digits, trunk 0, +880) and SHA-256 hashing happen in memory. Raw contact details never reach Redis, Postgres or a log line. The response is 202 in milliseconds: the shopper's page never waits for Meta.

One atomic step: seen before? If not, queue it. A Lua script checks the idempotency key and appends to a partitioned stream in a single round trip, so the check and the enqueue can't diverge. An SDK retry of the same request is dropped here.

Your store's server sends the same order. When the order is created or confirmed, your backend sends the purchase with a secret key, straight from the order. No browser can block this copy. It carries the cookies the SDK stored, so attribution survives.

The ledger keeps one purchase and two receipts. In one transaction the worker inserts into the identity ledger keyed by the order. The first copy creates the event and one delivery per destination. The second only adds a receipt. The message is acknowledged after the commit, so a crash just replays it harmlessly.

Delivered to Meta, server to server. The dispatcher claims the row, builds the request from the canonical event, and sends it. The event_id is the same as your browser Pixel's, so Meta keeps one copy even if the Pixel also fired. The access token goes in the body, never the URL.

And to Google Analytics 4. The same logical event, shaped for GA4: the _ga client id and session id so it joins the browser session, transaction_id so GA4 dedups the purchase, Google-format hashes, and your shopper's IP for geography instead of our server's.

If Meta is down, nothing is lost. Temporary errors retry with growing, randomized waits, and a circuit breaker pauses a failing destination without spending attempts. A revoked token pauses sending and keeps the events waiting until you reconnect. Every attempt is recorded, and the debugger shows it in plain language.

Never waits on Meta

Ingestion answers in milliseconds and only touches memory and one Redis call. Destinations are called later, by workers.

Never loses silently

Every failure ends in a visible state: retrying, paused, failed with a reason, or a per-event error returned to the sender.

Never counts twice

The order id is the identity. Browser, server, retries and redeliveries collapse into one event, and Meta gets one event_id.

Start free