Tracking Stack: MMP + Tracker + CAPI for App-Install Campaigns

A tracking stack for app-install campaigns is four systems acting as one: ad networks that sell installs, an MMP that measures them, a tracker that keeps your ROI math, and a CAPI channel that feeds conversions back for optimization. Miss one junction and the budget keeps flowing while the signal dies between the click and the ad account.

This guide assembles the stack in order: each layer's role, the data flow across three junctions, the iOS consent layer, and the checks that prove it works before you scale. The wider frame is covered in server-side tracking for performance marketing.

What is a full tracking stack for app-install campaigns?

Buying installs on Meta and TikTok is simple; the layers appear in measurement. Meta, Google Ads, and TikTok are self-reporting networks: they attribute installs against their own device-level click data, passing nothing through attribution links. An MMP such as AppsFlyer or Adjust measures the install from inside the app through its SDK. A tracker such as Keitaro or RedTrack keeps click-level accounting with your payout data. A CAPI delivery leg pushes confirmed conversions into the platforms' server APIs - what their optimization engines train on.

Each layer covers the blind spots of the others: the network's numbers are the network's numbers, an MMP without a tracker has no payout-level ROI, a tracker without an MMP never sees the install because that data is born in the SDK, and without the CAPI leg platforms optimize on clicks while real conversions stay invisible. A working tracking stack is what happens when none of these gaps stays open.

What role does each layer play?

Two documented details fix these roles. First, SRNs self-attribute: when the MMP notifies the network about an install, the network matches it against its own click logs - no attribution links involved. Second, on iOS the MMP's SRN attribution runs through SKAdNetwork and Aggregated Advanced Privacy rather than deterministic matching, with lookback windows between 1 and 28 days depending on the network. Where the two tools overlap, and when you need both, is covered in MMP vs affiliate tracker.

How does data flow through the tracking stack, step by step?

1. A user clicks a TikTok ad and lands on the tracking link from the MMP dashboard. It carries the mandatory macros: idfa or gps_adid, ip, user_agent, and clickid=CALLBACK_PARAM, where TikTok passes its callback parameter as click ID.
2. The app installs; the MMP SDK reports it.
3. The network self-attributes the install once the MMP notifies it. In a SAN setup such as Adjust's, the integration hands the network all installs, and the network does the matching.
4. Postbacks flow out of the MMP: in-app events return to the network within the partner retention period, and a configured feed carries events to the tracker.
5. The tracker records the conversion under its click with subid and status.
6. The delivery leg pushes the event into Meta CAPI and the TikTok Events API.

Ad click  -> MMP tracking link: clickid=__CALLBACK_PARAM__, idfa/gps_adid, ip, user_agent
Install   -> MMP attributes it (SRN self-attribution or device ID match)
Postback  -> tracker stores subid + status
Delivery  -> Meta CAPI dataset and TikTok Events API with event_id and action_source=app

Every arrow above is a place where identifiers get rewritten or dropped; the hop-by-hop failure catalog lives in server side conversion delivery.

Where does the event ID live across the stack?

• The network's click ID: TikTok sends its callback parameter inside the tracking link as clickid=CALLBACK_PARAM; on TikTok's web side that role belongs to ttclid.
• The tracker's click ID: the subid issued at click time and expected back in the postback, together with a conversion status.
• The event_id inside the CAPI payload. Meta deduplicates across its channels - SDK, MMP, and App Events API - by the pair of event_id and event_name, and wrong event_ids cause false deduplication that distorts reporting.

The working rule: an identifier is born once, in the leftmost system that owns it, and travels through every junction unchanged. The moment a hop regenerates an ID, the conversion can no longer be joined to its click, and reporting and deduplication both lose their key.

Junction 1: from the ad network to the MMP

Tracking links come from the MMP dashboard with the attribution macros listed above. SAN integrations differ slightly: in Adjust, links are created automatically, the SAN receives all installs from Adjust, and the network attributes from its own engagement data. The integration needs network credentials - a token, a login-password pair, or a key - plus Adjust SDK v4.0.0 or newer, so partner parameters from the SDK map into the network's parameters.

Watch the direction of postbacks - the most common mix-up in a tracking stack. Attribution flows from the network into the MMP, but event postbacks flow the opposite way: AppsFlyer sends in-app postbacks back into the SRN within the partner retention period, and in the TikTok integration the postback event list is configured on the MMP side, with TikTok event names mapped to AppsFlyer, Adjust, or Singular names. Expect the network to push events into your MMP, and you will wait for a postback that was never supposed to arrive.

TikTok's own guidance is to measure app campaigns through an MMP; the documented fallback without one is the Traffic objective and click monitoring.

Junction 2: from the MMP to the tracker

What arrives here is a postback: an HTTP request announcing a conversion, with a minimum of two parameters - the click ID (subid) and a status. Keitaro documents the receiving end concretely: the Postback URL is protected by a postback key that authenticates requests, and non-standard parameter names such as clickid, type, or profit are remapped to subid, status, and payout in the Postback URL settings.

One honest caveat: whether a given MMP can forward events to an external tracker, and in which format, is a per-MMP integration setting. Official documentation describes partner postbacks as a configurable capability, not a universal guarantee, so wire the feed and prove it with a real install before trusting it.

There is also a documented fallback when an incoming request cannot be arranged: Keitaro supports loading conversions manually or through API import.

Junction 3: into Meta CAPI and the TikTok Events API

On the Meta side, app events arrive through three channels - the Facebook SDK, the MMP, and the App Events API - and the Conversions API dataset consolidates them in one interface. Server events for app activity must carry action_source set to app and go to the dataset endpoint:

POST graph.facebook.com/{API_VERSION}/{DATASET_ID}/events?access_token={TOKEN}

{
  "data": [
    {
      "event_name": "purchase",
      "event_time": 1788100000,
      "event_id": "install-2026-09-04-0137",
      "action_source": "app",
      "advertiser_tracking_enabled": 1,
      "application_tracking_enabled": 1,
      "user_data": {
        "client_ip_address": "203.0.113.24"
      }
    }
  ]
}

Two fields bite people here. client_ip_address must not be hashed and, unlike SDK events, must be added manually inside user_data on the server path. advertiser_tracking_enabled carries the ATT prompt result and application_tracking_enabled the app-level tracking setting, both as 0 or 1.

On the TikTok side, the Events API is the server connection between TikTok and your marketing data, covering web, app, and offline events. In setup you pick the integration method and mode: standalone, or a second channel next to the Pixel - the recommended one. The API requires an access token, and the connection is validated afterwards with TikTok's diagnostic tools. Tracker-side wiring of this leg, including token macros and event testing, is covered in TikTok Events API for affiliate trackers.

What does the iOS ATT layer change in the stack?

Apple requires apps that collect user data and share it for tracking across apps and websites to use AppTrackingTransparency: requestTrackingAuthorization shows the prompt, trackingAuthorizationStatus reports the outcome. That consent state travels into CAPI payloads as application_tracking_enabled and gates deterministic attribution on iOS.

Beside the deterministic stack, aggregate frameworks report installs. SKAdNetwork defines three participants - ad networks, advertised apps, and the developer, who can opt in to copies of winning postbacks. With SKAN 4 on iOS 16.1 and newer, conversion value updates across three windows with up to three postbacks per signed ad, and Apple's postback data tier, driven by crowd anonymity, limits the detail each carries. One network receives the winning postback; up to five others with qualified impressions receive non-winning copies. AdAttributionKit continues the same model, adding re-engagement and alternative marketplaces, with Postbacks 1 through 3 and the same tiering.

In practice these feeds sit next to your tracking stack, not inside it: AppsFlyer serves SKAN postbacks through an API, including a feed of blocked install postbacks, and iOS SRN attribution runs through SKAN and Aggregated Advanced Privacy instead of device matching. For postback schedules, conversion values, and the reasons iOS numbers disagree with dashboards, see SKAdNetwork and AdAttributionKit reporting. Meta's web-side iOS fallback, Aggregated Event Measurement, touches the app stack only at the edges and has its own setup guide.

How do you verify the tracking stack before scaling spend?

1. Click a live ad and confirm the click ID appears in the tracker with the expected sub IDs.
2. Trigger one in-app conversion on a test device and confirm the postback arrived with correct subid and status.
3. In Meta Events Manager, run the Verify your setup step from the official CAPI flow: it confirms events arrive, deduplicate, and match correctly.
4. Validate the TikTok Events API connection with TikTok's diagnostic tools.
5. Reconcile counters across layers. Small gaps are normal: SRN lookback windows run 1 to 28 days and SKAN postbacks arrive late by design. A large constant gap points at a broken junction, not platform discrepancy.
6. Repeat the pass after any change to macros, postback templates, or event names; a renamed macro breaks the chain silently.

Verify from the click forward: a problem in junction 2 makes every downstream check meaningless.

Where does Most fit in a tracking stack?

The stack ends at its last junction: confirmed conversions must keep flowing into Meta CAPI and the TikTok Events API as long as the campaign runs, with the same event IDs and deduplication discipline on every push. Most handles that leg automatically, routing tracker conversions into the CAPI channels with retry queues, so the tracking stack you assembled keeps reporting without anyone exporting CSVs. For a one-off validated test event before any wiring, Pixel Activator does it for free.

Summing up: four layers, three junctions, one discipline - identifiers born once and passed through unchanged. Verify with a real install, then scale.

The Mobile Stack Cluster

• Snapchat app conversions through MMPs - the MMP route to Snap
• MMP postback to CAPI mapping - how an MMP event becomes a platform server event
• SKAdNetwork and AdAttributionKit reporting - iOS attribution without device identifiers

Sources