MMP Postback to CAPI Mapping: How an MMP Event Becomes a Platform Server Event
The MMP postback is one vocabulary, the platform payload the other - the CAPI mapping between them is the translation layer describing the same conversion. The mobile measurement partner - AppsFlyer, Adjust - speaks in its own postback grammar: its own event names, its own attribution identifiers, its own revenue fields. The platform's Conversions API - Meta, TikTok, Snap, Reddit, Pinterest - expects its own field names, its own hashing rules, its own deduplication keys. The mapping layer is what turns one into the other without losing identity or double-counting.
The Two Vocabularies
| Concept | MMP postback | Platform CAPI payload |
|---|---|---|
| Conversion identity | The MMP's event instance or transaction identifier | event_id / client_dedup_id family |
| Event name | The MMP's in-app event name | The platform's enum value or custom name |
| Revenue | The postback's revenue and currency | The payload's value and currency fields |
| User identity | Device identifiers (GAID/IDFA), hashed contact data if collected | user_data: hashed email/phone, mobile IDs |
| Click attribution | The MMP's attribution record | The platform's own click or cookie identifiers |
The mapping is deterministic by design: for the same measured conversion, the same postback must always produce the same payload. Anything creative in this layer - fresh identifiers per send, event names that drift - shows up later as double counts or matching losses on the platform side.
Which Fields Carry the Weight
The conversion identity maps the MMP's transaction or event instance identifier into the platform's dedup field - Meta's event_id, Snap's client_dedup_id, Reddit's conversion_id. This is the value the platform's deduplication job consumes, and it must be identical to what any browser-side tag computed for the same conversion. The user identifiers map into the user_data family: hashed email and phone where the app collected them, and the mobile identifiers - Snap documents madid lowercase and unhashed, plus idfv and anon_id for app events - that app attribution consumes directly. The click reference maps the MMP's attribution record into the platform's click field where one exists, such as Snap's sc_click_id from the landing URL.
Where Deduplication Sits
A measured app conversion can reach the platform twice: once forwarded by the MMP, once sent by your own server pipeline. The platforms that coordinate multi-channel delivery - Snap's client_dedup_id across pixel, SDK, and API within 48 hours; Meta's event_id pairing - count on the mapping layer to send the same identity from both paths. The per-network mechanics are in Snapchat conversion events, the mobile identifiers in Snapchat app conversions through MMPs, and the Meta pattern in Meta pixel and CAPI event deduplication.
Owning the Mapping
Hand-rolled, the mapping lives in your delivery service: postback in, per-platform payload out, with hashing, batching, and retries per network. Teams consolidating this layer use MOST - one postback in, correct per-platform payloads out across six networks; Pixel Activator validates a single conversion by hand. The surrounding stack - tracker, MMP, and delivery - is mapped in the MMP, tracker, and CAPI stack guide.
Frequently asked questions
Sources
Sources
- Manual testing and validation: Pixel Activator fires free test events while you tune parameters.
- Automated delivery: Most routes conversions from your tracker or CRM continuously, with deduplication and retries handled.
