Friend invites friend. Both land in the right place.
Every member gets a personal link. The friend lands inside the invite after installing, the referrer is credited, and suspected fake installs are flagged so you can check them before you hand out a reward.
- Who runs it
- Marketers, product
- Time to set up
- One app release
- Plan
- Growth, for the link API
A personal link for every member.
Your app makes each member a link that carries their referrer ID and what they're inviting people to, such as a challenge or a group run. A cold install then drops straight into that shared context.
- The referrer ID travels with the link, through the store and the install.
- Members share it however they like: messages, social, a QR code.
- Links are made by your backend through the API, so nobody makes them by hand.
The friend lands inside the invite.
Whether the friend already has Stride or installs it first, the app opens on Jon's invite, with the group and the next run on screen. Accepting is one tap.
- Works on iPhone and Android, including after a fresh install.
- The app knows who invited them from the first open.
- Your app decides what each side gets, and when.
Referred users who stay, per referrer.
Count the referred installs that reached a real milestone, like a first workout, from the events your app sends. Installs that look manufactured are flagged, so a member farming their own invites stands out before any reward goes out.
- Installs and activations per referrer.
- The share of invites that install, and of installs that activate.
- With webhooks on Growth, your backend hears about each install as it happens.
Reward the friend who stays.
When the reward fires decides who your programme attracts. Your app pays the reward; here's what each trigger buys you.
Cheap to game
Simple, but an install is the easiest thing to fake. Expect reward-chasers and reinstall loops.
Better, still thin
Filters some bots, but an account costs nothing to create. Check the install flags before paying out.
Reward what you wanted
Fire the reward on a first workout or a first purchase, from the events your app sends. You only pay for friends who actually used the app.
One-time setup, then it's all yours.
Your developer adds the LinkTrail SDK once, creates each member's link through the API, and reads the referrer when the app opens. After that, every invite lands correctly.
LinkTrail.onLink(link => {
// link.customData = { referrer: "user_4821", invite: "sunday-long-runs" }
showInvite(link.customData.referrer, link.customData.invite);
});The full walkthrough: Referral programme: friend-gets-friend that actually attributes
Fitness apps live and die on social proof — a friend's streak, a shared challenge, a 'come train with me.' Referral is the natural growth loop, but only if the referrer's identity survives the install and you can credit them without getting gamed.
What problem does this solve?
An existing member shares a personal invite. The friend installs, and should land in the inviter's challenge — with both sides eligible for the referral reward once the friend completes a first workout.
How do you set the links up?
Each member gets a personal deferred link carrying their referrer ID and the challenge to join, so a cold install drops straight into shared context.
{
"deepLinkPath": "/challenge/spring-shred",
"customData": { "referrer": "user_4821", "reward": "1-month-pro" }
}How do you stop referral abuse?
- Bind the reward to a real activation event (first completed workout), not the install.
- Tie the referrer ID to the matched install server-side so credit can't be spoofed by the client.
- Detect self-referral with device and match signals before paying out.
When should the reward actually fire?
At the first genuine activation, not the install — and the gap between those two choices is the difference between a growth loop and a budget leak. Paying on install means paying for anyone who can produce a device, which is a bounty on fraud rather than on members. Paying on first completed workout means paying only when someone did the thing your product exists for.
| Trigger | Cost exposure | What you're really buying |
|---|---|---|
| Install | Highest | A device. Trivially farmed. |
| Signup | High | An email address. |
| First workout | Moderate | A user who used the product once. |
| Week-one retention | Lowest | A member. Slowest to pay out. |
First workout is usually the right compromise: late enough to be meaningful, early enough that the referrer doesn't forget they invited anyone. Whichever you pick, hold the payout briefly rather than firing it instantly — a short delay costs almost nothing in perceived responsiveness and catches the obvious abuse patterns before money moves.
How do you handle the reward on both sides?
Decide both sides server-side, from the matched install, and never from anything the client reports. The inviter's reward should be issued against the referrer ID that your server bound to that install; the invitee's should be issued against their own activation. If the client can assert either, both are spoofable.
- 1The invitee installs from a personal link carrying the referrer ID and the challenge.
- 2The SDK delivers the payload on first open; the app joins the challenge and shows who invited them.
- 3Your server binds the referrer ID to the matched install — this is the record of truth, not the client's copy.
- 4On first completed workout, the server checks self-referral signals and the referrer's recent payout velocity.
- 5Both rewards issue, and the referrer gets a notification naming the friend who activated.
That last step matters more than it looks. A referral program with no feedback loop trains people to invite once; naming the friend who activated is what makes someone invite a second time.
Which metric should you watch?
Activated referrals per inviter — installs that reached the first-workout milestone, attributed to the referrer. That's the number that tells you the loop compounds, rather than just generating reward-chasing signups.
Two supporting numbers make it interpretable. Track the share of invites that install at all, which tells you whether the share surface works, and the share of installs that activate, which tells you whether the landing experience does. A loop that looks weak is nearly always failing at one of those two specifically, and the combined number won't tell you which. The same loop runs two-sided in a marketplace, where sellers share their own listings and bring the buyers — that version is marketplace listings.
Which teams own a referral programme?
- Growth marketers
- Mobile product teams
Which LinkTrail features does a referral programme need?
- Deferred deep linking
- Custom link payloads (referrer id)
- Fraud scoring — device repeat and IP velocity (Scale)
- Webhooks on install and event
Referral programme questions.
How do you stop referral abuse in a fitness app?
Bind the reward to a real activation event such as a first completed workout, tie the referrer ID to the matched install on your server so the client can't spoof it, and check device and match signals for self-referral before paying out.
When should a referral reward fire?
At the first genuine activation, not the install. Paying on install pays for anyone who can produce a device; paying on a first completed workout pays only when someone used the product. Hold the payout briefly to catch obvious abuse before money moves.
Which metric shows a referral programme is working?
Activated referrals per inviter — installs that reached the first-workout milestone, attributed to the referrer — supported by the share of invites that install and the share of installs that activate.
If you're doing this, you'll probably want these.
Group invites
Invite links that put new installs straight inside the group, class or team they were invited to.
Marketplace sellers
When a seller shares a listing and a buyer installs, the seller gets the credit.
Shared content
When someone shares a recipe, a listing or a workout, the friend lands on that thing, not your home screen.
Make your first referral link.
Free for your first 5,000 users. No card, no sales call.