One order, from the ad to Meta

Nine steps, with the actual payload at each one. Press play, or open any step.

Start free

Captured
Browserpurchase_1042
Your serverpurchase_1042
Cleaned
Phone 01712-345678
+8801712345678
650037f7…6e05c08c
Counted once
purchase:order:1042
2 copies → 1 event
Delivered
Meta CAPI212 ms
GA4188 ms
TikTok240 ms

One sample order. Timings are illustrative.

Follow the parcel

1 / 9

1
Where: Browser
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.

Ways to track

Pick how your store sends events

Every way comes with every plan, the free one included, and they run together without counting anything twice.

Direct

Most stores start here

Plugin, script or server SDK: no server of your own
A pixel id and token per platform
Deduplicated, hashed and retried for you

How Direct works

Google tag gateway

gtag.js and Tag Manager load from your own domain
GA4 and Google Ads hits get past ad blockers
Keeps Google's own cookies and sessions

About your own tracking domain

Your GTM dataLayer

One Custom HTML tag in your web container
Reads the GA4 ecommerce events you already push
No server container to host or pay for

Set up with Tag Manager

Planned

Hosted server GTM

For agencies with their own server container logic
Today: keep your sGTM host and add Trakero beside it
The same Meta event id keeps both from double counting

Run both side by side

Already on Stape, PixelFly or your own sGTM?

Your pixels, datasets and history stay. Only the system that sends to them changes, one platform at a time.

Read the move guide

Connect one platform
Add Meta (or GA4, or TikTok) in Trakero with the same pixel id you use today.
Switch off the old sender
Pause that platform's tag in the old system the same day, so no purchase is sent twice.
Check, then move the next
When Events Manager shows Trakero's events, repeat for the next platform.

Three promises

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.

WooCommerceShopifyWordPress

track.yourstore.comTrakero

MetaGoogle AnalyticsGoogle AdsTikTok

Your store → your domain → Meta, Google, TikTok

Start counting every order today

Create a free account, connect your store and watch a test order arrive in Meta Events Manager.

Start free Run the free scan

Free plan · No card needed · Set up in one afternoon

One order, from the ad to Meta

Follow the parcel

A shopper taps your Meta ad+

She buys. The thank-you page reports the purchase+

Ingestion validates and hashes, before anything is stored+

One atomic step: seen before? If not, queue it+

Your store's server sends the same order+

The ledger keeps one purchase and two receipts+

Delivered to Meta, server to server+

And to Google Analytics 4+

If Meta is down, nothing is lost+