Kochava is a long-established MMP with a straightforward partner model: a click URL that accepts your macros directly, an impression URL for view-through attribution, and postbacks whose payload arrives as nested device, event, and network objects. This guide wires it to an affiliate tracker end to end. For the architecture behind trackers and MMPs generally, start with the mobile attribution guide.
Where Kochava Fits
Two traits shape the integration. First, Kochava's click URL takes attribution context as plain query parameters โ campaign_id, click_id, affiliate_id, sub-affiliate slots โ with no proprietary renaming to learn, which makes the macro mapping the easiest in this series. Second, Kochava exposes click and impression endpoints side by side, so view-through attribution is a first-class option rather than an add-on. That flexibility is useful and needs discipline: impression-attributed conversions deserve their own payout rules.
Step 1 โ Build the Click URL
The advertiser issues a campaign-specific Kochava click URL; your tracker appends its context per click:
https://control.kochava.com/v1/cpi/click
?campaign_id={campaign_id}
&campaign_name={campaign_name}
&click_id={click_id} // your click ID โ the round-trip key
&affiliate_id={affiliate_id}
&sub_aff_id={sub_aff1}
&sub_aff_id2={sub_aff2}
&country={country}
&device_id={deviceid}The mapping is one-to-one with your tracker macros โ {click_id}, {campaign_id}, {affiliate_id}, {sub_aff1} โ so the only real rule is completeness: populate affiliate_id and the sub-affiliate slots on every click, because that is the granularity at which both you and the advertiser will want quality reports later. Kochava supports up to six sub-affiliate parameters if your program runs deep sub-ID structures.
Step 2 โ Impression Tracking, Priced Separately
Kochava's impression endpoint mirrors the click endpoint:
https://control.kochava.com/v1/cpi/imp
?campaign_id={campaign_id}&click_id={click_id}Fire it from placements that render without a click and Kochava can attribute installs view-through within the advertiser's impression window. Commercially, treat view-through as its own conversion class: shorter windows, lower (or zero) payout, and separate reporting. An impression is cheap to generate at scale, which makes undifferentiated view-through payouts a fraud magnet.
Step 3 โ Configure the Postbacks
In Kochava's partner configuration, the advertiser registers your tracker's endpoints for install and for each in-app event you pay on:
// Install
https://track.yourdomain.com/postback
?click_id={cid}&affiliate_id={aff_id}&sub_aff_id={sub_aff1}
&country={country}&device={device_type}
// In-app event
https://track.yourdomain.com/postback
?click_id={cid}&event={event}&payout={revenue}¤cy={currency}Event names must match the advertiser's Kochava event configuration exactly โ agree the list in writing before launch, the same discipline as Adjust's event tokens. Enable event postbacks even on pure CPI deals: post-install activity is your install-farm detector.
Step 4 โ Parse the Nested Payload
Kochava postback payloads group fields into three objects, and your ingestion needs to read all of them:
{
"device": { "adid": "...", // Android advertising ID
"idfa": null, "idfv": "...",
"ip": "...", "os": "iOS", "country": "US" },
"event": { "event_name": "purchase",
"timestamp_unix": 1752742800, // seconds
"revenue": 12.50, "currency": "USD",
"is_fraud": false, "fraud_reason": null },
"network": { "name": "yournetwork",
"campaign_id": "...", "site_id": "aff_1042",
"transaction_id": "click-abc123" } // your click ID
}The joins: your click ID comes back in the network object's transaction field, publisher identity in site_id, revenue and the fraud verdict in the event object, and device identity in the device object โ where the Android advertising ID is named adid, Kochava's convention. Timestamps are unix seconds, unlike Branch's milliseconds.
Step 5 โ Verify, Filter, Deduplicate
Kochava postbacks are verified with a shared secret hashed over the raw body โ recompute, compare constant-time, reject mismatches before parsing. Affclix does this automatically when the Postback Secret is configured and logs unsigned integrations as a visible warning. Behind verification, the standard payable-event gates apply: honour Kochava's own fraud verdict (event.is_fraud with fraud_reason) as a hard block, drop events whose network name is organic, deduplicate on click ID + event name against retries, and run survivors through your tracker-side fraud layers.
Reconciliation and Gotchas
- Conversions without publisher attribution โ the click URL was missing
affiliate_idor sub-affiliate slots. Kochava passes through what it receives; it cannot invent what the click never carried. - Android device IDs missing โ you are reading
gaid; Kochava's field isadidinside the device object. - View-through conversions inflating payouts โ impression attribution enabled without separate payout rules. Split the conversion classes before launch, not after the invoice dispute.
- Events silently missing โ event name drift between your CPA rules and the advertiser's Kochava event configuration. Names must match exactly.
- Numbers diverge from the Kochava dashboard โ reconcile against Kochava's detail reporting API (per-install rows, keyed by your App GUID and API key) rather than dashboard aggregates.
Affclix's Kochava integration generates the click and impression URLs pre-mapped, parses the nested payload including the adid and unix-seconds conventions, verifies signatures, honours Kochava's fraud flags, and pulls detail reports for reconciliation.
