Server Side Conversion Delivery: From MMP and Tracker to Meta and TikTok CAPI

Server side conversion delivery is the chain that moves a conversion from the system that measured it to the ad platform that optimizes on it, server to server. In an app-install funnel that chain has three links: an MMP attributes the install, a postback hands the event to the tracker, and the tracker or a delivery layer sends it into Meta CAPI or the TikTok Events API. Each hop reshuffles identifiers, and each is a place where the signal can arrive incomplete, late, or twice.

This guide walks each hop: which ID it generates, how postbacks are wired between Keitaro, Binom, Voluum, and RedTrack, and which checks to run before scaling spend. For the division of labor between the tools, see MMP vs affiliate tracker and server-side tracking vs browser pixel.

What server side conversion delivery actually means

A browser pixel depends on a browser: a tag fires, a cookie identifies the visitor, a page hosts the conversion moment. A pure app install has none of those: the signal starts inside the app, and the MMP measures it through the SDK. Once a web page joins the funnel, the pixel joins the SDK, and both events have to agree. That is why server side conversion delivery is the default architecture for app-install campaigns rather than an upgrade.

The same logic pushes web funnels toward server delivery: cookies disappear, ad blockers eat tags, and platforms reward events they can verify. The motivation is covered in cookieless attribution for affiliate tracking.

The three hops: click ID out, conversion back

At the identifier level, every chain that works looks the same:

Click      -> tracker generates a unique click ID
Offer URL  -> the ID rides with the user into the offer or app flow
Conversion -> a postback carries that ID back
Delivery   -> the tracker joins conversion to click and sends the event to Meta CAPI or TikTok Events API

Voluum documents the pattern explicitly: a unique click ID per click rides the offer URL as s2=, and the network returns it in the postback, where #s2# is replaced by the network's macro. Binom runs the same exchange with and cnv_id.

Self-reporting networks break the symmetry: Meta, Google Ads, and TikTok self-attribute installs by device ID when the MMP notifies them, passing no click data through attribution links. The click-ID chain still matters: tracker reporting and the delivery leg depend on identifiers that survived the earlier hops.

Where the click ID lives: ttclid, external_id, , #s2#

The names change, the job does not: the outgoing click ID must come back unchanged in the postback, or the conversion cannot be joined to its click. Keitaro URL-encodes placeholder values by default; a suffix keeps them raw. A lost ID still lets the event fire, but anonymous: no sub-ID, no landing context, no deduplication key.

Binom's documented pair, offer link and returning postback:

Offer link to the network:  your-network.example/offer?sub1={clickid}
Network postback to Binom:  your-binom.example/click.php?cnv_id={sub1}&payout={sum}&cnv_status={status}

The MMP leg: SRN attribution and postback limits

Meta, Google Ads, and TikTok are self-reporting networks: no attribution links carry their click data to the MMP. The network self-attributes when the MMP notifies it about an install, matching the event against its own device-level click logs, while MMP postbacks run within the partner data retention period under SRN limits on user-level data.

AppsFlyer's click lookback window defaults to 7 days: installs inside it count as non-organic, installs after it as organic, and for SRNs the window aligns with the network's own reporting.

Adjust fires callbacks the moment a trigger happens, an ad engagement through a link URL or an in-app event through the SDK. The callback carries advertising IDs, attribution, and app data in real time; since Adjust stores no raw data, callbacks are the only way to move raw data onto your own servers.

Privacy modes cut the leg short. With Aggregated Advanced Privacy enabled for the app or the TikTok partner, install and in-app postbacks go out only for installs credited to the ad network; organic installs postback nowhere. Volume toward TikTok is configurable per partner, all media sources including organic or this partner only, and the postback template follows the user's consent status.

The tracker leg: receiving and firing S2S postbacks

Keitaro configures S2S postbacks per campaign on the S2S Postbacks tab: the URL, the GET or POST method, and the conversion status that triggers the send. A traffic source preset adds the postbacks automatically, carries the source's click ID back, and every outgoing postback with its response is visible in Maintenance, then Logs, then S2S postbacks. The set also covers , , , and .

The status mapping placeholder keeps one URL valid for several statuses:

your-api.example/conversion?cid={external_id}&status={status:lead=0 sale=1 rejected=2}&revenue={revenue}

RedTrack accepts conversions three ways with different reliability: a direct API integration is backend-to-backend and the most reliable; an S2S postback does not depend on cookies but needs support from the network, CRM, or shop; a pixel or postback script is the simplest path and duplicates conversions when a thank-you page gets refreshed. In the S2S flow every system stores the same unique click session ID, and the conversion type rides along as &type=event-name.

Binom exposes the same controls from the other side: the incoming postback carries cnv_id, payout, cnv_status, cnv_currency, and to_offer, while disable_postback=1 switches off the outgoing postback toward the traffic source. Voluum's rule: its placeholders #s2# and #price# must match the macros the affiliate network supports.

The Meta leg: CAPI event requirements

Meta validates four fields on every server event: event_name, a standard or custom name; event_time, unix time in seconds; action_source, declaring where the event happened (website, app, email, phone_call, chat, and others, set by the sender); and user_data, the customer information map.

The deadline is strict: event_time may sit at most 7 days in the past, and the check is batch-wide. If a single event in a request is older, the whole request fails and none of its events are processed; a backfill job that mixes fresh conversions with one stale record delivers nothing.

For the concrete Keitaro wiring of this leg, see Facebook CAPI through Keitaro.

The TikTok leg: Events API and ttclid matching

The TikTok Events API takes an access token and runs standalone or as a second channel next to the Pixel. On every ad click TikTok appends ttclid, its Click ID, to the landing page URL and links it to the campaign. Web events carrying the Click ID through the Pixel or the Events API are matched for attribution, audience building, delivery optimization, and measurement.

So the delivery leg has a hard requirement: the event fired toward TikTok must carry the ttclid captured at click time, or it lands unmatched. Tracker-side setup, including token macros, is covered in TikTok Events API for affiliate trackers.

Deduplication: one event_id discipline across both channels

Meta deduplicates a browser event against a server event by the pair of event_id and event_name (browser terms: eventID and event) sent to the same pixel. Matching pairs discard later copies, but only within 48 hours of the first event carrying that event_id. Two documented consequences matter: a server event is not dropped when no browser event arrived in the previous 48 hours, even if an identical one arrives later; and on a single source nothing is deduplicated, so two identical server events both count. Meta also recommends passing fbp, fbc, or external_id identically in both channel types.

TikTok's rule is broader: identical event name plus event_id arriving within 48 hours count as duplicates, and deduplication works inside a single channel too - Pixel to Pixel as well as Events API to Events API. For the Pixel plus Events API pair, it applies to copies arriving after the first five minutes inside the 48-hour window. Separate events without overlap do not need it.

Trackers make the discipline concrete: RedTrack uses its rtclickid, or a role assigned to a parameter, as the Event ID it sends toward Meta on both paths.

Delay budget: postback latency vs API deadlines

A conversion in this chain is already late when it fires: the install happens, the MMP attributes it, a postback reaches the tracker, the delivery layer formats and sends the event. The total sits against Meta's fixed deadline: an event whose event_time is older than 7 days fails, and in a batch it fails the entire request.

Treat the budget as an engineering question. When events stop arriving on time, the search order is the chain itself: the MMP's postback queue, the tracker's outgoing postback log, then the delivery layer's retries. The diagnostic checklist lives in Meta CAPI event delays.

Common failure points

The same failures show up in every stack audit:

• Browser and server events without a shared event_id: on Meta a single source never deduplicates; on TikTok the event_id plus event_name pair decides in any channel combination.
• A lost external_id on one hop: the event fires but cannot be joined to its click, taking sub-IDs and landing context with it.
• Organic installs missing from reports under Advanced Privacy: postbacks go out only for installs the ad network is credited with, so the gap is by design.
• Pixel or postback scripts duplicating conversions when the thank-you page refreshes, the documented weakness of the simplest RedTrack intake method.
• A stale event_time poisoning a whole CAPI batch: one old record fails the request, and the fresh conversions inside it are not processed either.
• Conversion events switching off mid-campaign: Meta can disable conversion events for individual verticals at any time, and the stop comes from platform policy, not from the tracker.

QA checklist before scaling the chain

Before scaling spend on server side conversion delivery, run one test conversion through every link and read the logs in order:

1. Click a live ad and confirm the click ID appears in the tracker with the right sub-IDs.
2. Trigger the conversion and confirm the incoming postback carries that same ID.
3. Check the tracker's outgoing postback log (Keitaro: Maintenance, then Logs, then S2S postbacks) for the fired event and the endpoint's response.
4. In Meta Events Manager, use Test Events to confirm the name, action_source, and event_id.
5. Compare the event_id on the browser and server paths; it must be identical on both.
6. Check the timestamps: nothing older than 7 days enters a Meta batch, and both channels sit inside the 48-hour deduplication window.
7. Repeat the test after any change to statuses, macros, or templates; a renamed macro breaks silently.

Sources