Affiliate tracking on the web is a solved problem. A link, a cookie, a webhook on checkout, done. You know exactly which partner sent the customer who just paid.
I tried to run the same playbook inside my own subscription app and hit a wall. On mobile, the money moves through a system that is designed to forget where the user came from.
This is the story of why in-app purchase attribution is hard, and how I ended up building the thing I could not buy.
The problem in one sentence
A creator posts your link. Someone taps it, lands on the App Store, installs your app, and subscribes three days later. By the time the purchase happens, every trace of the creator who caused it is gone.
On the web the browser carries the context the whole way. On iOS and Android it does not. The tap happens in one place, the install in another, and the purchase in a third, and Apple and Google are under no obligation to connect them for you.
So you get a strange situation. Creator marketing clearly works for apps. Almost nobody can measure it.
Why the obvious solutions do not work
The first thing you reach for is a promo code. Give each creator a code, count the redemptions. It falls apart fast. Codes get screenshotted and shared, they leak to deal sites, and StoreKit promo codes are limited and clumsy to manage at scale. You are measuring code theft as much as referrals.
The second thing you reach for is an existing affiliate platform. Almost all of them assume a web checkout. They wait for a browser event that, inside the App Store purchase flow, never fires. There is no cookie in that flow to read.
The third thing, if you are a certain kind of engineer, is "I will just build it." Which is where I ended up. It turns out to be two hard problems wearing a trench coat.
Hard problem one: surviving the install
You need the referral to survive the trip through the store. That is deferred deep linking.
When the app opens for the first time, it has to ask "was I installed because of a specific referral?" and get an answer. The mechanics differ by platform. Deep-link providers, install referrer APIs on Android, and fingerprint or clipboard-based matching on iOS all play a part, and none of them is perfect on its own. Apple's privacy changes have made the naive approaches less reliable over time.
The lesson I took from this stage: treat attribution as probabilistic and store the raw signals, do not throw away a click id just because you matched on something else. You will want to reconcile later.
Hard problem two: proving the purchase
Say you have matched the install to a creator. You still cannot pay anyone yet, because you do not know if the user actually bought something real.
This is where a lot of naive affiliate setups quietly leak money. They pay on the signup, or on a client-side "purchase succeeded" callback that a determined person can fake, or on a subscription that gets refunded a week later.
You want to pay on a verified purchase. That means a server-side source of truth for the transaction.
If you already run subscriptions through RevenueCat, you have this. Their webhooks give you a trustworthy signal that a real purchase happened, renewed, or refunded. If you are on raw StoreKit, you are validating receipts and handling App Store Server Notifications yourself.
Two details in there caused me the most grief.
The attribution window. People do not subscribe the instant they tap. Set the window too tight and you rob creators of the slow-burn conversions they earned. Too loose and you credit them for purchases they had nothing to do with. It is a business decision disguised as a config value, and you want it explicit, not hard-coded in three places.
The commission model was its own rabbit hole
I assumed commission would be the easy part. It was not.
Flat fee per conversion is simple to reason about and simple for a creator to understand. "You get five pounds per subscriber." Great for predictability.
Percentage of revenue aligns incentives better for subscriptions, because a creator who sends you a customer that stays for a year is worth far more than one who churns in a month. But now you are tracking commission across renewals, tiers, upgrades, downgrades and refunds over time, which is a lot more state.
Then there are tiers, where your best partners earn more, and multi-level or "daisy chain" arrangements where a creator earns a slice from creators they recruit. Each of these is a small feature and a large pile of edge cases.
If I were starting again I would ship flat-fee-per-verified-purchase first, get the attribution and payout loop solid end to end, and only then add percentage and tiers. The attribution is the hard part. The commission maths multiplies whatever correctness problems you already have.
What I would tell someone building this today
Store raw signals, attribute later. Clicks, install referrers, first-open context. Do not compute a single answer at install time and bin the evidence.
Pay on verified purchases only, from a server-side feed. Never on a signup or a client callback.
Make the attribution window an explicit, single source of truth.
Keep the creator's view honest. The thing that actually makes creators keep promoting you is seeing the same real-time numbers you see. Trust is the product, not a feature.
The disclosure
I built this out far enough that it became its own product, Insert Affiliate, so treat this as disclosure rather than a neutral survey. It plugs into RevenueCat and the usual verification providers and handles the payout side through Stripe.
But you do not need my thing to take the lessons. The hard, interesting engineering here is the same whoever you build it with: carry the referral through the install, prove the purchase server-side, and only pay on money you actually keep.
If you have solved deferred deep-link matching on modern iOS in a way you are happy with, I would genuinely like to hear how in the comments. It is the part that never feels finished.
Top comments (0)