Mobile app affiliate tracking: installs and subscriptions without an MMP

Why app tracking is harder than web tracking

On the web, affiliate tracking is a solved problem. A visitor taps a creator's link, a cookie or URL parameter records the referral, and the checkout on the same site ties the sale to the creator. A mobile app breaks that chain in two places: the App Store or Google Play sits between the link and the first launch, and the payment goes through Apple or Google rather than your own checkout.

So mobile affiliate tracking has two separate jobs. Attribution answers which creator brought this user. Verification answers whether the purchase is real and what it was worth. An MMP does the first job for paid ads. A creator program needs both, per person, because at the end of the month you send someone money.

The attribution methods, and what each one can see

Each method below either knows the creator for certain or makes a best guess. Use the exact ones wherever you can, and let the fallback catch the rest.

• A code the user types. The creator says use code MAYA in a video or podcast, and the user types it into a field in your onboarding or on your paywall. It's an explicit action by the user, works the same on iOS and Android, and needs no permission. It's also the only method that works when there's no link to tap: audio, livestreams, word of mouth.

• A link that carries the code into the app. When the app is already installed, a universal link or Android App Link can open it with the code in the URL, and web apps, PWAs and Capacitor or Cordova apps can read the code from their launch URL. What doesn't work on iOS is passing a parameter through an App Store install: the App Store hands nothing from the link to your app on first launch.

• The Google Play Install Referrer. On Android, Google Play keeps the referrer parameter from the Play Store link and lets your app read it after install through the Play Install Referrer API, together with the click and install timestamps. A creator link that puts the code in the referrer gives an exact match. iOS has no equivalent.

• A code your app already knows. If your own deep link or promo flow captures the code, store it on the user. With RevenueCat that means writing it as a subscriber attribute, so every purchase event carries the creator's code.

• Link-click matching, as a fallback. When someone taps a creator's link, installs from the store and the code never reaches the app, the install can be matched to the recent tap on that link. It's best effort, so it should be limited to a short window and to your own app, and any exact method should override it.

• Ad-network attribution. SKAdNetwork and AdAttributionKit on iOS, and MMP tracking links, measure installs from ads. They're built for paid campaigns, not for paying individual creators (more on that below).

When methods disagree, the rule should be simple and written down. In InfluTo, a typed code beats a link tap, the most recent of several taps wins, and once a user's first purchase is attributed, that creator keeps the user for every renewal.

Method by method: what's exact and where it works

Exact means the creator is known for certain, with no modelling involved.

What Apple allows without the IDFA or ATT

Apple requires the App Tracking Transparency prompt for tracking, which it defines as linking data from your app with data from other companies' apps, websites or offline properties for targeted advertising or ad measurement, or sharing it with data brokers. The IDFA, Apple's advertising identifier, is only available after the user agrees.

Apple also forbids fingerprinting, consent or not. Its developer agreement says you may not derive data from a device for the purpose of uniquely identifying it, and apps that include SDKs doing so can be rejected. That rules out matching installs by combining device model, screen size, timezone or similar signals.

First-party creator attribution needs neither. A typed code is the user's own input, and an exact link hands over a code, not an identity. InfluTo never reads the IDFA or any advertising ID, and its documentation says not to request ATT for it. Its link-click matching never compares device characteristics such as model, screen size or timezone, links nothing across other apps or websites, and only ever decides between referred by this creator and organic.

Where SKAdNetwork fits, and where it doesn't

SKAdNetwork, and AdAttributionKit, which builds on it, are Apple's privacy-preserving frameworks for ad attribution. A registered ad network signs its ad impressions. If the user installs and opens the app within the attribution window, the device sends a delayed postback to the ad network, and to you if you opt in, with a conversion value and no user identity.

That design is why it can't run a creator program. A creator's caption or bio link isn't a signed ad impression, a postback can't tell you which of 50 creators drove an install, and it can't follow one subscriber's renewals and refunds month after month. If you boost a creator's video as a paid ad, measure that ad with the ad network and your MMP like any other campaign, and keep the creator's own code and link for commission.

Pay on verified purchases, not installs

An install is a weak thing to pay for. Many installs never reach the paywall, many trials never convert, and an install count is the easiest number to inflate. The event that matters to a subscription app is a paid purchase, and it has to be checked with the store before any money moves:

• A purchase can be fake or a test. A purchase reported only by the app could come from a sandbox account, TestFlight or a modified client. Apple and Google can confirm whether a transaction is real and which environment it came from.

• Renewals happen without the app. A subscriber who renews in month seven may not have opened your app for weeks. Only the store, or a service that listens to it, sees that renewal.

• Refunds come from the store. Apple and Google process refunds and chargebacks. Your commission system has to hear about them to reverse what it credited.

There are two common ways to get verified purchase events: a RevenueCat webhook if you already use RevenueCat, or the App Store Server API and the Google Play Developer API directly. InfluTo supports both, one path per platform. It records a commission only after the store has confirmed the purchase, reverses it on a refund, and never moves money for sandbox purchases.

A setup that works without an MMP

1. 1

   Give every creator a code and a link. The same short code works typed or inside the link, so a creator can say it in a video and post it in their bio.

2. 2

   Add a code field before the first purchase. An optional "Have a code?" step in onboarding catches most people, and a small link on the paywall catches the rest. Prefill it when the install was already matched, so the user only has to confirm.

3. 3

   Check attribution on first launch. Ask the SDK at launch, before the paywall decides what to show, so a link-click match or a code carried in the launch URL or Install Referrer is picked up in the same session.

4. 4

   Connect a verified purchase source. Either the RevenueCat webhook, with the creator's code written as a subscriber attribute, or store-direct validation with your App Store and Google Play credentials.

5. 5

   Test one referred purchase end to end. On a sandbox build, install through a test creator's link or type their code, buy, and confirm the purchase shows up attributed to that code before you invite real creators.

When do you still need an MMP? When you buy ads across several networks and need one view of which network deserves the credit. The two layers don't conflict: the MMP keeps measuring paid campaigns, and the creator platform pays on store-verified purchases. The MMP vs affiliate platform guide below covers the split.