MMP vs Affiliate Platform: Which One Tracks Creators

MMP vs affiliate platform is a question with a dull answer: they are not substitutes. A mobile measurement partner grades ad networks, and the operating system hands it postbacks whose fields disappear below a crowd-size threshold. An affiliate platform holds a named person, a rate, a ledger row per charge and a payout. Most subscription apps running a creator program need the second and never touch the first.

Some need both, which is an ordinary architecture rather than a failure to choose.

What follows: what an MMP is built for, what an Apple attribution postback actually contains as of 2026-09-14, the eight columns that separate the two products, the one place they genuinely overlap, and a five-question test for which one you are buying.

#They are not substitutes, and only one of them can pay a person

Buy a mobile measurement partner when money leaves your account towards an ad network. Buy an affiliate platform when money leaves your account towards a person. AppsFlyer, Branch, Adjust and Singular do the first. A commission ledger does the second. The two products differ in their unit, not in their accuracy.

AppsFlyer states the unit on its own glossary page: mobile attribution is "a method for determining which campaigns, media partners, and channels delivered specific app installs", verified on 2026-09-14. Read the nouns. Campaigns, media partners, channels. No person appears in it, and none is meant to.

A commission is the opposite shape: a payment of a specific amount to one identified individual, computed from one identified charge, reversible when that charge is refunded, and repeated every time the same subscriber renews. No aggregation of campaigns produces it.

Why subscription apps need their own affiliate layer stops at the category boundary. This page carries the argument into the field names, because the founders who write asking "can I just use Branch?" deserve a mechanism rather than a category claim.

Our opinion, stated once and then evidenced: if you have never bought a paid install, an MMP is a purchase you do not need yet, and deep linking is the only part of it you will miss.

#An MMP is built to grade ad networks, and the postback shows it

An MMP sits between your app and the networks you buy media from. It receives signed postbacks, deduplicates them, decides which network won the install, and reports spend against installs. The design constraint is that no individual must be resolvable across apps, so the data arrives coarse by construction rather than by omission.

Apple's AdAttributionKit documentation names three participants: ad networks that sign ads and receive postbacks, publisher apps that display those ads, and advertised apps that update conversion values as people engage. Your app is the third one. It is the object being measured, not the party holding the record.

Winner selection is explicit: a maximum of six impressions considered per conversion, click-through beating view-through, and up to five losing networks each getting one nonwinning postback, verified on 2026-09-14. That machinery settles disputes between networks buying the same user.

Adjust draws the same boundary in its own words. Its ad network integration guide states that Adjust "will only share attribution details with the partner who is given credit for the attribution", and that a partner "will know that another partner drove an install, but they won't know the other partner's name or campaign details". The counterparty is an organisation with a contract, not a person with a payout address.

Its CJ Affiliate setup page makes the identity model concrete: Adjust forwards install and event by default, with placeholders including {revenue_float} and {random_user_id}. The identifier sent to the affiliate side is random. Correct for a network integration, useless as a join key for your own ledger. Both pages verified on 2026-09-14.

We read all three vendors' docs in one sitting while scoping our own normalizer, and the vocabulary is consistent throughout. Partner, network, campaign, source. The absence of a creator noun is not an oversight. It is the product.

#Is SKAdNetwork deprecated in favour of AdAttributionKit?

No, not as of 2026-09-14. Apple's SKAdNetwork class reference carries no deprecation notice and still lists iOS 11.3 as its introduction. AdAttributionKit arrived in iOS 17.4 and is the newer surface. Apple documents both running together.

The opposite claim circulates as settled fact. We opened the class reference on the day of writing rather than repeating it, which is the only reason this section says no.

Apple's interoperability article sets out how the pair behaves, verified on 2026-09-14:

• "AdAttributionKit works with both the App Store and alternative app marketplaces, while SKAdNetwork works specifically with the App Store."
• The .adattributionkit and .skadnetwork ad network ids are compatible across both, so no framework-specific id is needed.
• Impressions from both are sorted together and one winner is chosen, and SKAdNetwork conversion value calls are mirrored into AdAttributionKit.

Read as an operator: AdAttributionKit is the direction of travel, because it covers alternative marketplaces, and the two are wired to coexist rather than to cut over. Neither of them changes the creator question. Both report campaigns.

#Four things a commission needs that a postback cannot carry

A commission needs an identity you chose, a row for every charge including the ones years out, a rate attached to a person, and a reversal path. Apple's postback carries none of the four, and it is not designed to. Each one fails for its own documented reason.

1. An identity you chose. The postback identifies an ad network and a hierarchical source identifier of two, three or four digits. Your billing webhook identifies a subscriber by app_user_id on RevenueCat or metadata.customer_user_id on Stripe. No field is common to both, so there is nothing to join on.
2. A row per charge, past day 35. Apple's conversion window article documents three windows measured from first launch: days 0 to 2, days 3 to 7, and days 8 to 35, verified on 2026-09-14. The framework stops after the third. A monthly subscriber's second charge lands around day 30 and the thirteenth around day 395.
3. A rate attached to a person. Conversion values are engagement buckets the advertiser configures. Apple sends a fine-grained conversion-value only in the first postback, and a coarse-conversion-value in lower data tiers and in the second and third. A bucket is not an amount, and no percentage of a bucket is payable.
4. A reversal. A refund arriving 40 days after the charge has to claw the commission back. Postbacks have no reversal semantics, because an install that happened stays happened.

Click to enlarge

Then the threshold, where small creators disappear. Apple assigns each download a postback data tier that decides how much detail the postback may contain. The tier "takes into account the crowd size associated with the app or domain displaying the ad, the advertised app, the country the advertised app was installed in, and the hierarchical source identifier that the ad network provides", verified on 2026-09-14.

The fields that move with the tier are named: source-identifier, conversion-value, coarse-conversion-value, publisher-item-identifier, marketplace-identifier and country-code. At Tier 0 the system sends only the first postback and omits the marketplace identifier. Apple's ad attribution page puts it plainly: the publisher item id "is conditional and only displays when privacy thresholds are met".

Apple publishes the inputs to the tier and not the boundaries, so nobody outside Apple can name the install count at which a creator becomes visible. We will not guess at one. The direction is clear enough: a creator sending 30 installs a month is the population the mechanism exists to hide, and hiding them is it working correctly.

Timing compounds it. The first postback goes out after a random delay of 24 to 48 hours, the second and third after 24 to 144. Our attribution windows post covers what creator conversion lag does to the timer you do control.

#An affiliate platform's unit is a person, and its output is a payment

An affiliate platform starts from a creator record, attaches a commission rate to it, and writes one ledger row per billing event that traces back to that creator. The attribution step is the cheap part. The expensive part is everything after the money arrives, which is where the two categories stop resembling each other.

The join is first-party and boring. A creator link lands on your own domain, your SDK records the referral, your app calls identify with the user id you already use, and your billing provider posts a revenue event carrying that same id. No device graph, no crowd size, no ad network id. Our webhook reference lists the exact field each provider sends, and the whole integration is two calls.

What the ledger then has to survive is a list nobody enjoys: a trial that charges nothing, a renewal that charges again at the same price, a plan change that charges a prorated amount, a refund that reverses a row you already marked earned, and the store's cut between the price and your proceeds. The full policy set is in the RevenueCat wiring.

Creator-facing reporting is the requirement people underestimate. A creator needs to see their own clicks, their own conversions and their own balance, and nothing belonging to anyone else. That is a scoped view over a per-person ledger. An MMP's surface is the inverse: one media buyer looking across every partner.

Our opinion, from watching founders try it the other way: when a creator disputes a number, only a row with a timestamp, an event id, an amount and a rate settles it. An aggregated postback cannot, and neither can a campaign-level dashboard. That failure mode is why the categories stay separate.

#Eight columns separate an MMP from an affiliate platform

One of these rows is not a feature gap: an MMP has no commission ledger because a ledger is not the product it sells. The eight dimensions below are the ones that actually decide a purchase. Read the unit of attribution row first, because every other row follows from it.

Two price cells need their footnote in the open. Branch's pricing page lists Basics, Essentials and Enterprise, caps Basics at 3 ad partners, 3 data partner webhooks and 3 ad partner postbacks, and publishes no prices at all; Essentials and Enterprise both require a demo request. AppsFlyer publishes Zero, Growth at $0.07 per conversion after the first-year package of 12,000 free conversions, and an Enterprise tier behind a demo request. Adjust's pricing page returned a bot check rather than content when we opened it on 2026-09-14, so we have no verified figure and will not estimate one.

The ledger and payout rows are absences, and we state them carefully. We checked both pricing pages on 2026-09-14 and found no commission calculation and no payout rail listed. Branch's own affiliate marketing guide puts the obligation on the publisher: to get commission structures right, publishers have to follow the path from referral link through install to later conversions themselves.

For the tools that do hold a ledger, the full affiliate software comparison prices thirteen, and the mobile-native tools compared goes deeper on four.

#Deep linking is the real overlap, and keeping both is legitimate

Three things sit in the intersection: deep linking, deferred deep linking and install attribution. Everything else in either product is exclusive to it. If Branch already routes your links, the correct move is usually to keep Branch and add a ledger beside it, not to replace anything.

All three define the shared piece in near-identical terms. Branch calls deferred deep linking a feature that sends a user to specific content "even if the user doesn't have the app downloaded at the time the link is clicked", and AppsFlyer uses almost the same sentence. Adjust documents a deferred deep link routing a user through the app store to install first, and that all Adjust deep links defer automatically under the TrueLink name. Verified on 2026-09-14.

Click to enlarge

We do not compete with Branch on deep linking and we do not ask anyone to remove it. Routing a link correctly across iOS, Android, the mobile web, an in-app browser and a fresh install is a long tail of platform behaviour, and a vendor maintaining that tail for a decade handles cases we have not seen. Our SDK claims a referral from a Universal Link and falls back to a creator code, a narrower job on purpose.

The composite is short to describe. Branch resolves the link and hands your app a destination plus its own link data. Your SDK reads the creator parameter out of it, records the attribution, and calls identify with your user id. Your billing provider posts the revenue event carrying that id, and the commission is created. The two never have to agree, because they are keyed on different things.

Cost the pair before you commit. Take a program producing 3,000 attributed conversions a month. On AppsFlyer's published Growth rate that is 36,000 in a year, minus the 12,000 free in the first-year package, leaving 24,000 chargeable at $0.07: $1,680 in year one and $2,520 in a steady year. A flat $79 affiliate plan is $948 a year. The two bills are not buying the same thing, which is why one does not cancel the other.

Our opinion on when the pair earns its keep: run both once mis-crediting an ad network costs you more than the MMP does. Below that, an MMP is an expensive deep link.

#Choose an MMP if, choose an affiliate platform if

Almost everyone reaching this page needs one product, and the deciding fact is whether you buy media. The five questions after the lists settle the case where both look plausible.

Choose an MMP if:

• You buy installs from ad networks and need to know which one to credit.
• You need SKAdNetwork and AdAttributionKit postbacks handled and reconciled against network-reported numbers.
• Your counterparties are affiliate networks with contracts rather than individual creators. Adjust ships partner setups for exactly that shape.
• You need install fraud filtering across paid sources.
• Deep linking across every platform edge case is a requirement you would rather buy than build.

Choose an affiliate platform if:

• You pay named people a percentage or a fixed amount, and they expect to see their own numbers.
• Your commissions continue past the first charge, which means past day 35.
• A refund has to reverse money you have already recorded as earned.
• You need a payout artefact: a statement, an export, a transfer, a tax form.
• Your revenue arrives as a billing webhook from RevenueCat, Adapty, Superwall, Stripe or Paddle rather than as a store install.

When both lists describe you, work through these in order and stop at the first clear answer.

1. Add up last month's paid media spend. Zero closes the MMP question and you are choosing an affiliate platform. Anything material means you are probably running both.
2. Count the people you owe money to by name. If that is a count of humans rather than networks, no MMP feature closes the gap.
3. Check the date of your oldest paying commission-eligible subscriber. More than 35 days past their first launch, and the store framework has already stopped reporting on them.
4. Look at how your smallest creator would appear. If their monthly volume is in the tens, assume the postback tier hides them and plan on a first-party join instead.
5. Decide who deep linking belongs to. If a vendor already owns it, keep them and buy only the ledger. If nobody does, decide whether Universal Links and creator codes cover your channels before adding a second bill.

Question three is the one founders skip and the cheapest to answer. If your oldest paying subscriber is on month nine, every renewal since month two has been invisible to the framework people keep recommending.

#Where MyAppAffiliate fits

We are the affiliate side of this comparison, and we hold none of the MMP side. No SKAdNetwork or AdAttributionKit postback handling, no ad network integrations, no install fraud module, and no plan to build them. If you buy paid media, keep your MMP.

Shipping today: six SDKs behind two calls, start and identify, with the iOS package at 0.3.0; webhook ingestion for RevenueCat, Adapty, Superwall, Stripe and Paddle, each with signature verification and one normalized event vocabulary; last-touch attribution joined on your own user id; commissions with the rate snapshotted onto each row; founder and creator dashboards, the creator view scoped to that creator alone; and an idempotent CSV payout export that matures commissions and reconciles to the payout total. Attribution is first-party with no IDFA and no fingerprinting, documented on the iOS SDK page.

Not shipped, and stated as such: automatic reversal of a commission on refund, still documented as an MVP limitation; plan changes and prorations, which the normalizer ignores; and automated Stripe Connect payouts, which sit on the Scale tier of our pricing as planned rather than built. Our deferred install match, used when there is no link and no code, resolves on a hashed IP inside a short window and misses people on shared networks. For a program spanning a web product too, one attribution engine across mobile and web covers how one appId serves both.

#Open your billing export and find the day-35 line

Sort your paying subscribers by start date and count how many are more than 35 days past their first launch.

That count is the share of your revenue no store attribution framework will ever report against a creator, and it is the whole case for a ledger in one figure. Then read how attribution windows work and set the two timers you do control.