How We Solved Referral Attribution for Knudge.me: Crediting the Right Referrer, Automatically, Even After a Fresh Install
How to credit the right referrer when a new user installs your app fresh, using deferred deep linking. A real walkthrough from Knudge.me — and why we built LinkTrace as a Firebase Dynamic Links alternative.
What is deferred deep linking? Deferred deep linking is a technique that carries a link's destination and context through an app install: a user taps a link, installs the app from the App Store or Play Store, opens it for the first time, and still lands on the intended screen with the original data — like a referrer's ID — intact. Without it, the referral context is lost the moment the user passes through the store.
Knudge.me, a mobile learning app, rewards its members with credits when someone they refer joins. The credits are real — members spend them inside the app — and the referral loop is a meaningful driver of growth: friends invite friends, friends join, the referrer gets paid. This is how we solved referral attribution for Knudge.me — and why we built LinkTrace, the tool that runs this loop in production today.
- The Short Version
- The Referral Loop We're Actually Talking About
- The Loop Ran on Firebase Dynamic Links — Until That Stopped Being an Option
- Why No Off-the-Shelf Tool Fit
- How the Install Gets Matched Back to the Referrer
- How We Solved It, End to End
- Building Referral Attribution Into Your Own App
- Frequently Asked Questions
- The Takeaway
The Short Version
To credit the person who referred a new app user, you have to connect the referrer's invite link to that user's install — even when they installed the app fresh from the App Store or Play Store. A normal link can't do this, because the referral context is lost the moment the user passes through the store. The mechanism that preserves it is deferred deep linking: you encode the referrer's identity in the link, and LinkTrace returns it verbatim when the install is matched back to the original click — so the credit posts back to the exact referrer the link carried, automatically, with a couple of API calls.
That's the whole answer. The rest of this post is how we got there.
The Referral Loop We're Actually Talking About
Before the technical part, it's worth being precise about the system, because "referral tracking" gets used loosely and the version with rewards attached is meaningfully harder.
Here's the full loop in Knudge.me:
2. Member sends it → WhatsApp, iMessage, anywhere
3. Friend taps the link
→ If app installed: opens directly
→ If not installed (common case): App Store / Play Store → install → first open
4. App identifies → which member's invite brought this new user
5. Credits post automatically → to the exact referrer, no code paste, no confirmation
Step 4 is the entire problem. The link click in step 3 and the install in step 4 happen in two completely separate environments — a mobile browser and a freshly installed app — with no shared session between them, and the operating system is deliberately designed to stop you from connecting the two. Get step 4 wrong and the whole reward economy on top of it is unreliable.
What makes referral attribution stricter than analytics: A referral here isn't a row in a dashboard; it's a decision about who gets paid. If attribution is off, a member brings in a new user and never gets the credits they earned — or credits go to the wrong member. Both quietly punish the most engaged users, the exact people already evangelizing your app for free. And nothing throws an error when it breaks. You just lose trust slowly.
The Loop Ran on Firebase Dynamic Links — Until That Stopped Being an Option
For a long time, Knudge.me's referral loop ran on Firebase Dynamic Links (FDL). It was free, it handled the deferred install case, and like a lot of teams, it was easy to stop thinking about it as a service with an expiry date. It just worked.
Then Google announced FDL was shutting down, and on August 25, 2025, it did — completely. Every Firebase Dynamic Link now returns a 404. The console had already gone read-only for Dynamic Links back in May 2024. There was no grace period and no drop-in replacement from Google. The plumbing under the referral rewards was on a countdown to breaking.
If your links are returning 404s after August 2025: Firebase Dynamic Links shut down completely on August 25, 2025. Any referral program still relying on FDL has broken attribution — referred installs no longer carry the referrer's context, so rewards can't be credited correctly. Replacing it requires a tool that does deferred deep linking.
Why No Off-the-Shelf Tool Fit
The replacement options sorted into two piles, and neither was built for a team at this stage.
On one side were the enterprise mobile measurement platforms — Branch and AppsFlyer. Genuinely powerful, mature, deep. They're also SDK-heavy and priced for companies several growth stages ahead: pricing that scales on installs or monthly tracked users, which means the bill grows with the exact thing you're trying to grow. For a team that just needed its referral credits to keep working, that was bringing an enterprise contract to a problem that didn't need one.
On the other side was Google's own recommendation: migrate to native Universal Links (iOS) and App Links (Android). Those solve direct deep linking fine — but they don't do deferred deep linking out of the box. They can't carry the referrer's identity through a fresh install, which is the one thing the entire reward loop depended on.
There was no option positioned for a startup that simply needed referral attribution to survive the install — affordable, fast to integrate, without the enterprise tax. So we built one. That's where LinkTrace came from — not from spotting a market, but from a real reward loop that had to keep working and nothing on the shelf that fit it.
| Option | Deferred deep linking | Referral attribution | Integration | Pricing model | Best for |
|---|---|---|---|---|---|
| Native Universal / App Links | No (not built in) | No | Per-platform setup | Free | Direct links only, no attribution needed |
| Branch / AppsFlyer | Yes | Yes, deep | SDK + app store release | Per-install / per-MTU | Larger teams with budget and complex needs |
| LinkTrace | Yes | Yes, focused | API-first, a couple of calls | Flat / startup-priced | Indie devs and early-stage teams crediting referrers |
| Build it yourself | Only if you build it | Only if you build it | High and ongoing | Your engineering time | Teams where attribution is core enough to own outright |
How the Install Gets Matched Back to the Referrer
One distinction matters here, because it's what keeps the credit going to the right member: the referrer's identity is never guessed. You encode it in the link when you create it — a referrerIdentifier, plus anything else you put in customPayload — and LinkTrace returns it verbatim when an install is attributed. So the member who gets credited is the exact one the link carried, not someone inferred after the fact.
What LinkTrace works out is the other half: which click a given install came from. It does that with device fingerprint matching inside a 24-hour attribution window — the new user has to install within a day of tapping the link. If there's a match, the Attribution API returns attributed: true along with the encoded referrer and payload. If there isn't — an organic install, or the window lapsed — it returns attributed: false, and your app runs its normal post-sign-up flow.
Design principle for rewards programs: The credit-back hangs off attributed: true, and you design a clean default for attributed: false, since organic installs are the common no-match case. Encode the referrer in the link, return it verbatim, credit on a match — that's the loop.
How We Solved It, End to End
Here's the actual flow LinkTrace runs for Knudge.me, start to finish.
Step 1: The member generates an invite link
When a member taps "invite a friend," you create a trackable link carrying their referrerIdentifier and whatever screen context you want to land them on. One API call:
Content-Type: application/json
x-api-key: YOUR_API_KEY
{
"referrerIdentifier": "member_8842",
"campaign": "invite",
"customPayload": {
"screenName": "referral_success"
}
}
"success": true,
"data": {
"shortCode": "56ff9241",
"referralLink": "https://app.linktrace.in/r/56ff9241",
"referrerIdentifier": "member_8842"
}
}
You share referralLink with the friend.
Step 2: The friend taps the link and installs
LinkTrace logs the click, records the device fingerprint, stores the customPayload tied to it, and redirects to the right store. The new user has to install within the 24-hour attribution window for the match to hold — this is the exact point where a plain link, or native Universal/App Links, would lose the context.
Step 3: The app calls the Attribution API after sign-up
Once the new user finishes registration, your app makes a single Attribution call — once per user, not on every launch. If the install matches the original click, LinkTrace returns the encoded referrer and payload:
Content-Type: application/json
x-api-key: YOUR_API_KEY
{
"userId": "new_user_internal_id"
}
"success": true,
"data": {
"attributed": true,
"referrerIdentifier": "member_8842",
"campaign": "invite",
"customPayload": {
"screenName": "referral_success"
}
}
}
Step 4: The credit posts back automatically
Because the response carries the exact referrerIdentifier you encoded, your backend credits member_8842 the moment sign-up is confirmed — no manual code entry, no confirmation tap, no reconciliation job. And because customPayload comes back verbatim, you can drop the new user straight onto the referral-success screen. The loop closes itself.
For organic installs: you'll get attributed: false — your default post-sign-up flow just takes over. Design for this case explicitly; it's the common path for users who didn't come through an invite link.
Full request/response fields, the 24-hour window behaviour, and drop-in iOS and Android code for reading the payload are in the LinkTrace deferred deep linking docs.
Integration note: This is API-first. You're making calls and reading a response in your own routing code, not shipping a native SDK and an app store release to test every change. The referral loop above is built on API calls, and that's why it's fast to stand up.
Building Referral Attribution Into Your Own App
If you're designing an app where you want to credit the person who referred a new user, here's what this came down to:
- The hard part isn't generating invite links. It's attributing the install back to the referrer when the new user didn't have your app yet. That's deferred deep linking, and it's where most referral programs silently break.
- Encode the referrer's identity in the link and return it verbatim — don't try to reconstruct who the referrer was after the fact. That's what keeps the credit going to the exact member the link carried.
- Design for the no-match case. Organic installs and expired windows return no attribution, so your default post-sign-up flow has to be clean and ready to run.
- Native links won't do the deferred part. Enterprise platforms will, but they're priced and engineered for a later stage. If you're a startup, that gap is real — it's the gap LinkTrace was built to fill.
- The win condition is the loop closing itself: invite → install → attribution → credit, automatically. If a human has to paste a code or confirm a match, it'll leak.
Frequently Asked Questions
The Takeaway
A referral program with rewards attached is only as trustworthy as its attribution. For Knudge.me, the referrer's identity couldn't be left to guesswork — real credits ride on it — so it's encoded in the link and returned exactly on a match. Firebase Dynamic Links used to carry that loop; when it shut down and nothing on the market fit a startup's needs, we built LinkTrace to carry it instead, and it runs that exact flow in production today: invite, fresh install, a matched install, automatic credit back to the right member.
If you're building the same thing, you don't have to learn it the way this did. The loop is solvable, it can close itself, and the tool that runs it is one you can use too.