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.

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.

1. 1The invitee installs from a personal link carrying the referrer ID and the challenge.
2. 2The SDK delivers the payload on first open; the app joins the challenge and shows who invited them.
3. 3Your server binds the referrer ID to the matched install — this is the record of truth, not the client's copy.
4. 4On first completed workout, the server checks self-referral signals and the referrer's recent payout velocity.
5. 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.