Attribution

Attribution is the process of identifying the origin (or sender) of a download: connecting a person who clicked a link to the same person opening your app minutes later, across an app-store install gap. Invitebase solves this using our proprietary landing pages, never fingerprints. No IP matching, no device-signal matching, no probabilistic attribution. That keeps every integration App Store compliant.

How we attribute referrals

Every referral link points at your hosted offer page on your refr.link domain. When someone taps a referral link, what happens next comes down to one thing — whether they already have your app installed.

The app is already installed

The link opens your app directly through a Universal Link (iOS) or App Link (Android), with the invite code intact. The SDK reads the code on launch and applies the referral right away — nothing else for the user to do. This is the simple path.

The app isn't installed yet

Offer page with Download the app and Redeem your reward buttonsScreenshot coming soon

The tap lands on your hosted offer page. It records the click (creating the referral in the clicked state — repeat taps never create duplicates) and shows who invited the visitor and what both sides get, with two clear buttons:

1. Download the app — sends the visitor to the App Store or Google Play to install.
2. Redeem your reward — opens the app through a Universal Link and applies the invite code. If the app isn't installed yet, this button prompts the visitor to download it first, then applies the code once the app is open.

Either way, the code reaches your app and attribution completes the same way: the SDK attaches referral_code to the new user's first events, and the backend binds that user to the clicked referral, advancing it clicked → signed_up — the linked moment. The reward itself follows once the referral qualifies.

Per-platform mechanics

iOS

Unlike Android, Apple provides no native APIs to pass referrals through install, so Invitebase uses a deterministic clipboard handoff and Universal Links.

Fresh install (deferred attribution):

1. On the offer page, tapping install copies the invite URL to the clipboard (inside the tap gesture, as Safari requires) and hands off to the App Store for app install.
2. Once the user launches the newly downloaded app, call resolveReferral(). This will prompt the user to accept pasteboard permissions, allowing the invite code to flow through to the Invitebase SDK and be attributred.
   1. If a URL was present in the pasteboard, but the read permissions were declined, the SDK can be configured to show a "paste or enter your code" prompt. Invitebase ships a themeable default code-entry screen plus callbacks for fully custom UI.
   2. In the event a user deletes the pasteboard, they will be required to return to the offer page to tap the second CTA - Redeem Referral. This action uses Universal Links to pass the referral directly into your app.
3. The Invitebase SDK recovers the code and applies it with applyCode(code). The code is then validated against the API and attached to the user's events.

Already installed:

If the user has already installed your app, the link opens the app directly via Universal Links with the code intact — no clipboard, no prompt. Your one step is adding applinks:mycompany.refr.link to your app's Associated Domains entitlement. The SDK's handleInbound(url) parses the code from the launch URL.

Attribution is one-shot: once a code is recovered and applied, the SDK persists a resolved flag and never reads the clipboard again on later launches.

Android

Android deferred attribution is deterministic and first-party — no clipboard step needed.

Fresh install:

In the event the user has already installed your app, the offer page appends the code to the Play Store URL's referrer= parameter. The Play Install Referrer API passes it through the install with a near-100% match rate, no prompt, no third party. On first launch the SDK queries InstallReferrerClient, recovers the code, and attaches it to events exactly like iOS. Click and install-begin timestamps come along too — Invitebase uses them to detect click-injection timing anomalies in fraud checks.

Fallback: manual code entry covers the cases the referrer string can't — sideloads and non-Play installs.

Already installed:

App Links open the app directly with the code in the launch URL. Invitebase serves assetlinks.json (your package name + SHA-256 cert fingerprints) on your subdomain; handleInbound(url) does the rest.

As on iOS, the SDK stops querying once attribution is resolved.

Web

The easy case. The offer page (or a snippet on your own page) persists the code in a first-party cookie and localStorage, with expiry aligned to the campaign's qualification window. When the referred user signs up, the Web SDK reads the stored code and attaches it as referral_code on the signup event. After successful attribution the stored code is cleared — one-shot, mirroring the mobile flows.

No third-party cookies, no cross-site tracking: the code is a first-party value on your refr.link page and your own domain.

Attribution windows

Three windows matter, and they're distinct:

• Click-to-signup: how long a stored code stays alive between click and signup. Stored codes (web cookie/localStorage, pending mobile codes) expire in line with the campaign's qualification window, so a click can't attribute a signup months later.
• Signup-to-code-use (the grace period): how long after signup a late-arriving code still attributes. By default a code must be recovered by the time the user signs up — but real invite flows are messy, and a friend often signs up first and only then remembers the code they were supposed to enter. A campaign's optional grace period forgives this: a code applied within N hours after signup (24 or 48 hours is the common choice) attributes exactly as if it had been present at signup — the referral is linked, and the qualification window still anchors at signup, not at code entry. Late codes arrive through the same recovery paths as on-time ones, most often manual entry via applyCode. Configure it in the Campaign Builder; Choose your rewards covers the trade-off — a longer grace period rescues more honest mistakes but widens the window for existing-user abuse.
• Signup-to-qualification: the qualification window itself — how long the referred user has after signup to satisfy the gates. See Qualification gates.

Precedence and edge cases

Last click wins. If a user clicks links from two different referrers, the most recently captured code overwrites the earlier one, and attribution goes to the last referrer before signup.

One referral per user per campaign. A referred user binds to at most one referral in a given campaign. Once attributed, later codes for the same campaign are ignored — attribution never silently reassigns.

Forwarded links. The code, not the click session, is the attribution artifact. If a friend forwards the link to someone else, whoever signs up with the code is attributed to the original referrer.

Manually entered codes. applyCode(code) is a first-class attribution path, not a degraded one: a user who types a code from a screenshot or a podcast attributes exactly like a clicked link. Invalid or expired codes are rejected cleanly so your UI can route back to the entry field. And if the campaign has a grace period configured, applyCode keeps working for a short time after signup — the rescue path for a user who signed up before remembering their code.

Self-referral. If the recovered code belongs to the same person (matching email, device, or payment fingerprint), the referral is blocked before validation — see Fraud prevention.