Referral attribution is the technical problem underneath every referral program: when User B installs your app because User A shared a link, how does the app know that? How does it know precisely which user referred them? And how does it handle the gap between "User B taps the link" and "User B opens the app for the first time after installing"?
The answers to these questions determine whether your referral program credits the right people, catches fraud, and gives you accurate data on program performance. Get them wrong and your program either fails to reward real referrers (which kills participation) or issues rewards without reliable attribution (which invites fraud and distorts your metrics).
The referrals page with stats cards, referral list, and leaderboard tabs.
The Full Attribution Journey
When referral attribution works correctly, here is what happens:
User A shares a referral link. The link contains User A's referral ID as a parameter, along with any other relevant context (a specific product they shared, a campaign ID, an expiration timestamp).
User B taps the link. The link click is recorded with a timestamp, the referrer's ID, and User B's device context (IP address, user agent, device type).
User B is redirected to the App Store or Google Play. At this point, the URL bar disappears. The browser's URL context is gone. The referral parameter cannot be passed directly to the app store listing.
User B installs the app. Depending on the device and attribution method, the referral context either survives this step (with deferred deep linking) or is lost (without it).
User B opens the app for the first time. The app needs to retrieve the referral context from step 2 and associate it with User B's new account.
User B completes the qualifying action. The app checks the stored referral parameter, confirms it is valid, and issues the reward to both parties.
Steps 3-5 are where most attribution implementations fail. The app store install creates a context gap that ordinary URL tracking cannot bridge.
Why Standard URL Tracking Fails on Mobile
On the web, tracking a user's journey from a clicked link to a conversion is relatively straightforward. Cookies or URL parameters persist across page loads within the same browser session. If a user clicks a referral link on a website, proceeds to a checkout, and completes a purchase, the attribution chain is intact.
On mobile, the flow through the app store creates a hard break in this chain:
- The user taps a link in their browser (or a messaging app)
- They get redirected to the App Store
- They download and install the app
- They open the app
The app open is a new process that has no connection to the original browser session. It cannot read cookies. It cannot read the URL that triggered the App Store redirect. Without additional infrastructure, the app has no way to know the user arrived because of a referral link, let alone which specific referral link.
This is the problem deferred deep linking solves.
Deferred Deep Linking for Referrals
Deferred deep linking is the mechanism that bridges the context gap between a link click and an app first open. The "deferred" part means the deep link is delivered not when the link is clicked (because the app is not installed yet) but when the app is opened for the first time after install.
The basic mechanism works like this:
When User B taps the referral link, the link passes through an attribution server (Tolinku's infrastructure, in this case). The server records the click and stores the referral parameters associated with User B's device context.
User B is redirected to the App Store. The referral parameters are stored server-side, associated with identifiers derived from the device context at click time.
After install, when User B opens the app for the first time, the app calls the attribution server's API. The server matches the current device context to the stored click event and returns the referral parameters.
The app receives the referral parameters and stores them on the new user's account.
The matching between step 2 and step 3 is based on device context that persists across the install: on iOS, this relies on deterministic matching when Universal Links are available, and on probabilistic matching (IP address, device characteristics, timing) as a fallback. On Android, App Links provide similar deterministic matching.
For a deeper explanation of how deferred deep linking works under the hood, see Deferred Deep Linking: How It Works and the deferred deep linking concepts documentation.
Deterministic vs. Probabilistic Attribution
There are two approaches to attributing a click to an install, and referral programs benefit from understanding the difference.
Deterministic attribution
Deterministic attribution creates a certain, verified connection between a specific click and a specific install. On iOS, Universal Links provide this: when a Universal Link is tapped, iOS can open the app directly (bypassing the browser entirely) or pass known device identifiers through the transition. On Android, App Links provide similar capability.
Tolinku's referral links use Universal Links (iOS) and App Links (Android) as the primary attribution mechanism. When a user who already has the app installed taps a referral link, the app opens directly with the referral parameters, creating a deterministic attribution chain.
When the app is not installed, the user goes through the App Store. On iOS, if the user has the same Apple ID on both devices, or if other identifiers are available, deterministic matching may still be possible. But this is less reliable than the direct-open scenario.
Probabilistic attribution
When deterministic matching is not possible, probabilistic attribution uses device signals (IP address, device model, OS version, screen resolution, user agent, timestamp) to create a fingerprint at click time and match it to the same fingerprint at install time.
Probabilistic attribution is less accurate than deterministic but provides a useful fallback. The accuracy decreases with network-level privacy protections (VPNs, carrier-level NAT) and device-level privacy settings (iOS's App Tracking Transparency framework, for example).
For referral programs specifically, the accuracy of probabilistic attribution matters because it affects reward fairness. If probabilistic attribution incorrectly assigns a credit, either a referrer goes unrewarded or an unqualified install triggers a payout. Good referral attribution systems use probabilistic as a fallback and flag low-confidence matches for review rather than automatically issuing rewards.
Cross-Device Tracking Challenges
Cross-device referral attribution is a harder problem: User A shares on their laptop, User B sees it on their phone and installs the app. Or User A shares on iOS, User B is on Android.
The cross-platform case (iOS share to Android install, or vice versa) is handled by the fact that the referral link is a web URL. The link's click is recorded regardless of which platform taps it. The install is attributed by the same deferred deep link mechanism on whichever platform the user installs on.
The cross-device same-platform case (desktop share to mobile install) requires the referral link to work correctly on mobile web. Tolinku's referral links handle this by detecting the requesting device at click time: a click from desktop records the click, then when the same user later installs on mobile (matched probabilistically via IP and timing), the attribution can still be made.
The reliability of cross-device attribution is inherently lower than same-device attribution. If your referral program relies heavily on desktop-to-mobile flows, budget for a higher miss rate in your attribution estimates.
Tolinku's Approach to Referral Attribution
Tolinku's referral system is built around the same deep link infrastructure used for all link types, extended with referral-specific attribution logic.
When you create a referral link in Tolinku:
- The link contains a referrer parameter that identifies the referring user
- Clicking the link records a click event with device context
- If the app is installed, Universal Links or App Links open the app directly with the referral context
- If the app is not installed, the user is redirected to the appropriate app store, and the referral context is deferred for retrieval on first open
- On first open, the app SDK calls the Tolinku attribution API to retrieve any pending referral context
The rewards and attribution documentation explains how attribution data flows through to reward fulfillment and how to configure attribution windows (the time period within which an install must occur after a click for attribution to apply).
For the technical setup of referral links and attribution parameters, see the referral links documentation.
Attribution Windows
An attribution window is the period after a link click during which an install can be attributed to that click. If User B taps a referral link on Monday and installs the app on Friday, an attribution window of 7 days would credit the referral. An attribution window of 3 days would not.
Setting the right attribution window involves a tradeoff:
- Longer windows credit more installs as referrals, which increases reward payouts but also increases the chance of false attribution (the user might have installed organically anyway)
- Shorter windows miss genuine referrals from users who had a longer consideration period, which under-rewards referrers and reduces trust in the program
For most mobile apps, a 7-day attribution window is a reasonable default. For apps with longer purchase cycles (high-value products, subscription services), a 14 or 30-day window may be more appropriate.
Attribution windows should be disclosed in your referral program terms. If a referrer shares a link and their friend installs outside the attribution window, the referrer is entitled to know why they did not receive credit.
Handling Attribution Fraud
Attribution fraud in referral programs exploits the gap between click recording and install verification. Common patterns:
Click injection (Android): Malware on an Android device broadcasts fake click events to attribution providers just before an app is installed, hijacking the attribution credit. Google has documented this extensively and Play Protect works to mitigate it, but it remains a concern for high-value referral rewards.
Referral self-attribution: A user creates multiple accounts (or uses multiple devices) and refers themselves. If your fraud detection only checks for matching IP addresses, this can be defeated by using mobile data vs. Wi-Fi on different devices.
Install farms: Groups of devices install an app and complete enough onboarding to trigger referral rewards, then repeat at scale.
The mitigations described in the referral program launch checklist cover the basics. For high-value referral programs, additional measures like requiring a payment method on file, monitoring for device fingerprint clustering, and setting velocity limits per referrer are worth implementing before reaching significant scale.
Measuring Attribution Quality
Beyond tracking raw referral attribution counts, measure attribution quality over time:
- Attribution match confidence: For probabilistic matches, what percentage have high confidence vs. low confidence? High rates of low-confidence matches suggest your deterministic attribution is not working properly.
- Referral fraud rate: What percentage of attributed referrals are flagged as suspicious? A sudden spike in this rate often signals an exploit being actively used.
- Attribution lag distribution: How long after a link click do attributed installs occur? A spike in installs at exactly the edge of your attribution window may indicate gaming.
Accurate referral attribution is the foundation that every other part of your referral program depends on. Time spent getting it right before launch pays back in cleaner data, more trustworthy rewards, and a program users actually believe in.
For more on the referral program lifecycle, see Building Referral Programs That Work or the Tolinku referrals overview.
Get deep linking tips in your inbox
One email per week. No spam.
