How BATracker Sends Conversions to Meta CAPI & TikTok — With Zero Data Loss

1. Why Server-Side Conversions Matter

Client-side pixels fire from the browser, which means they are at the mercy of the browser. Ad blockers strip them, Safari's ITP and other privacy features shorten or delete the cookies they rely on, and a visitor who closes the tab a fraction of a second early can prevent the pixel from ever firing. Every one of those events is a real conversion the ad platform never sees — which means worse attribution, worse optimization, and a worse-trained algorithm buying your traffic.

BATracker solves this at the server. Because it already keys conversions by click ID through its S2S postback pipeline — immune to ad blockers, ITP, cookie restrictions, and page-close — it can turn around and deliver those same conversions server-to-server to Meta and TikTok. No browser required, no dependency on the visitor's device. And because BATracker runs on a modern Fastify + ClickHouse + Redis + BullMQ stack, it does this in real time, at scale, without cold starts.

2. Sending to the Meta Conversions API

For Meta, BATracker POSTs a JSON payload to the Conversions API endpoint:

Authentication is handled with an access_token included in the payload. That token is never stored in the clear — it is encrypted at rest with AES-256-GCM and decrypted only at send time. Each event carries:

• • event_name — mapped from your internal event: sale/conversion → Purchase, lead → Lead, registration → CompleteRegistration, install → Install, deposit → Purchase, and custom → Custom.
• • event_time — unix seconds, and event_id — the deterministic conversion ID that enables dedup with the browser Pixel.
• • action_source: "website", plus event_source_url.
• • user_data, SHA-256 hashed: em (email), ph (phone), external_id, country, ct (city), st (state/region). Sent raw: client_ip_address and client_user_agent. The fbc click cookie is built from the fbclid as fb.1.{ts}.{fbclid}.
• • custom_data: value (the payout), currency, content_type of "product", and order_id (the conversion ID).

An optional test_event_code lets you validate the integration in Meta's Events Manager Test Events tool before going live.

3. Sending to the TikTok Events API

TikTok works the same way conceptually, with its own endpoint and its own field names. BATracker POSTs JSON to:

Here authentication is an Access-Token HTTP header rather than a payload field. The event carries:

• • event — mapped from your internal event: sale/conversion → CompletePayment, lead → SubmitForm, registration → CompleteRegistration, install → Download, and custom → CustomEvent.
• • event_id — the same deterministic conversion ID, and timestamp in ISO 8601 format.
• • user_data, SHA-256 hashed: email, phone, external_id. Sent raw: ip, user_agent, and ttclid (the TikTok click ID).
• • context: page.url, ip, user_agent; and properties: value, currency, content_type, order_id.

As with Meta, an optional test_event_code is supported for validation before you send live traffic.

4. Meta vs TikTok Field Comparison

Both platforms want the same underlying signal — who converted, when, and for how much — but they name and structure fields differently. BATracker handles the translation for you. Here is a side-by-side of what actually gets sent:

Notice that the event_id is identical in both columns. That single field is what unlocks reliable server-side tracking without double counting — and it is the heart of the next two sections.

5. How Browser + Server Dedup Works

When a conversion happens, two events can legitimately reach the ad platform: one from the browser Pixel that fired on the page, and one from BATracker's server-side call. Left unmanaged, that would count the conversion twice.

BATracker prevents this by sending the same event_id — the deterministic conversion ID — on its server-side event that the browser Pixel already used. Because Meta and TikTok see matching event_ids arrive from both sources, they automatically deduplicate them and count the conversion once. You keep the resilience of the server-side call as the safety net, and if the browser Pixel also made it through, the platform quietly collapses the pair into a single conversion.

6. The No-Data-Loss Reliability Chain

"Zero data loss" is not marketing language here — it is the direct result of how the conversion pipeline is ordered. Every link in the chain exists to guarantee that a conversion, once received, is recorded exactly once and never dropped.

Put together, this ordering means a conversion is durably stored the instant it is received, retried safely if a downstream platform stumbles, and impossible to duplicate no matter how many retries or resends occur. That is what zero data loss actually looks like under the hood.

7. Multiple Pixels & Custom Conversions

Real funnels rarely map to a single event. BATracker lets a campaign carry many pixels, each with its own platform event name. On Meta that can be Purchase, Lead, CompleteRegistration, AddToCart, InitiateCheckout, Subscribe, or ViewContent; on TikTok, CompletePayment, PlaceAnOrder, Subscribe, SubmitForm, Contact, or Download.

Custom conversions take this further. You can map an inbound postback event — say ?event=AddToCart — to a specific platform event on a specific pixel. That means a single funnel can fire a main Purchase pixel and several custom-event pixels off the same traffic. If no custom mapping matches an incoming event, BATracker gracefully falls back to the campaign's primary pixels, so nothing goes untracked.

8. Observability: Pixel & Postback Logs

Reliability you cannot see is just a promise. BATracker logs every single delivery so you can audit exactly what happened, when.

All timestamps in these logs are shown in your workspace timezone, so what you read matches the clock you actually work in. When a platform rejects an event, you see the exact HTTP status and response body — no guessing, no black box.

9. Frequently Asked Questions