Referral system in the app: where invitation mechanics break
The referral system brings users exactly as long as the chain "friend invitation → install from invitation → reward" passes without breaks. In practice, breaks are almost always present, and each one quietly consumes a share of invitations that no one then counts. Let's break down exactly where the mechanics break.
The first failure is the loss of connection between the click and the install. A person opens the link, lands in the app store, installs the app, and launches it without invitation context: the signal did not survive to first launch, the install was not tied to the referrer.
Both participants are left without a reward, and the referrer concludes that the mechanics don't work and stops inviting.
The second failure is crediting. If the reward is issued not for an install but for a target action inside the app, it is easy to never receive it: the condition is worded vaguely, the event didn't arrive, and there is nowhere to view the invitation status.
The person who invited a friend cannot see at which step the friend stopped, and loses interest before the chain reaches the reward.
The third failure is bonus abuse. Self-referral from a backup account, multiple devices per person, and automated schemes turn the reward into leakage and the budget into a gift to those who never intended to use the app.
This is closed not after the fact but by rules: limits on the accrual chain, device and profile verification, thresholds, and delayed payout.
Next, we'll cover where to place verification so as to cut off abuse without losing legitimate invitations.
Referral system: options for bonus crediting mechanics
The choice of mechanics starts with three questions: who receives the bonus, for which action, and at what moment it triggers.
One-sided and two-sided rewards affect the invitee's conversion differently, and the trigger threshold determines how much abuse the system can withstand without manual investigations.
The trigger threshold is the main lever against self-referrals: crediting based on the first payment or completed order instead of registration cuts off empty accounts.
The price for this is a longer path to payout, so the interface needs an explicit "bonus pending" status indicating which action is missing.
| Variant | When it fits | Limitations |
|---|---|---|
| One-sided bonus to the referrer | A product where the invitee benefits more from the service itself than from a bonus | The invitee receives no reciprocal benefit — fewer clicks |
| Two-sided reward | Mass services where both sides need to be retained after the first action | More expensive per pair, requires separate accounting for two accruals |
| Reward tiers for a series of referrals | Communities and active users who bring a stream of people | Payout forecasting is more complex, and the appeal of abuse grows |
| Registration bonus without a threshold | Early launch, when speed of building the base matters | Accruals go to accounts that will never become active |
Schemes can be combined: reward tiers on top of a trigger threshold provide both motivation for active users and protection against empty registrations.
When choosing, we calculate the share of pairs reaching the threshold and the number of accruals per referrer — these two values immediately show where the mechanics hit limitations and where they can be strengthened.
How we implement invitation mechanics: work stages
Work proceeds in iterations, not a single sprint: first we pin down exactly where invitees are lost in the current funnel, then assemble the mechanics and test them on real scenarios, not on a demo stand.
Each stage ends with an artifact that can be reviewed and challenged — this way implementation of the mechanics does not turn into a black box.
- Funnel audit. We capture current events: the share of users who reach sending an invitation, installing via the link, and the first target action. We find breaks and decide where the mechanics will have an effect and where the problem lies elsewhere.
- Accrual scheme. We formalize the model: for which action we credit, to whom, with what delay, what counts as a qualified step, how we calculate limits, and how we cut off self-referrals and abuse.
- Designing links and the log. We determine how the referrer and invitee are linked, how the operation is protected from duplicate accrual, how the bonus is canceled when an order is rolled back — everywhere an immutable accrual history remains.
- Implementation in the app. Deep link transition into the app, progress and reward status screens, notifications, correct operation without network: the action is not lost but goes into a queue until connectivity is restored.
- Scenario testing. We run through reinstall, login from another device, account change, first launch without network, payment cancellation. Separately — attempts to bypass limits.
- Observability and handover. We set up step-by-step funnel metrics and alerts for discrepancies in accruals, hand over documentation on the scheme, access, and instructions for manual adjustments. After that, your team runs the mechanics on its own.
What we hand over after launch: artifacts and policies
Referral mechanics live longer than the release: rates change, abuse attempts appear, and support needs to resolve disputed accruals.
So that each such edit does not turn into an urgent release of a new build, we hand over a set of artifacts — your team can make changes based on them without our involvement.
- Accrual policy. Rates and limits for the referrer and invitee, recalculation terms for order refunds, antifraud trigger thresholds, and scenarios for manual balance adjustment.
- Data schema. "User — invitation — event — accrual" relationships: keys, indexes, storage locations for statuses. It shows where the balance came from and where to look for a discrepancy.
- Access matrix. Roles in the admin panel: support sees history but does not credit; marketing edits campaign terms; engineer — configuration. The list is issued with a description and the procedure for revoking rights when an employee leaves.
- Documentation. Description of events that trigger the bonus, the exchange format with the backend, and system behavior when an external service is unavailable.
- Edit procedure. What is changed by configuration without updating the app, and what requires a build release — taking into account the rules of distribution platforms (App Store, Google Play).
- Log and rollback. Accrual logs with an operation ID, instructions for canceling an erroneous bonus and restoring the balance without manual data edits.
Acceptance is not a screen demo but a walkthrough with your engineers: they change the rate themselves and roll back a test accrual. After that, maintenance can be handled by your own team or left to us — this is decided based on the actual situation, not agreed in advance.
Case study: growth in invitations and retention across funnel stages
In the app of the fitness club chain "Atlet", referral mechanics lived on a separate screen: the user sent a link, the invitee registered, and both received a discount on the next renewal.
After three months, the share of users who invited someone held at 8%, and invitee conversion to the first visit — at 12%: they registered "for the future" and never made it to the gym.
We reworked not the bonus amount but the journey: the invitation was embedded at the moment of completing a weekly goal, and the reward was tied to the pair's joint activity, not to registration.
Where it improved
The share of users who sent at least one invitation per month grew from 8% to 23%, and invitee conversion to the target action — from 12% to 31%. Day 30 retention among invitees turned out higher than the app average: 27% vs.
18% for the base — a person comes as part of a pair with someone who already keeps a training rhythm.
Return of "dormant" users improved from 6% to 11%: a reminder about unfinished shared progress worked noticeably better than a solo notification.
Where the hypothesis did not pan out
The reward for merely sending a link doubled the surge of invitations but dropped conversion to the first session — people came "for the discount", not to train.
The accrual was moved to the invitee's second day of activity: the volume of sends dropped, but the share of pairs who reached the gym together tripled.
Separately, we disabled the referral block for new users during the first day — it distracted from completing the onboarding scenario and reduced the share of users who reached the schedule.
How does an install bonus differ from a purchase bonus?
The difference between these schemes is not in the reward amount but in the moment of accrual. An install bonus is credited on the first launch of the app: the device is fresh, and the account is not in the database of already counted ones.
A purchase bonus waits for a confirmed payment event and until then is not reflected in the referrer's balance.
The moment of accrual determines what exactly we are paying for.
An install is cheap to replicate: emulators, reinstallation after a data reset, and logging in again with a new account produce a stream of empty invitations and inflate the user base with people who will not return.
A purchase requires a real payment — faking it costs more than the bonus itself, so abuse loses its point.
| Variant | Accrual moment | What it confirms | Abuse risk |
|---|---|---|---|
| Install bonus | first app launch | new device and activation | high: emulators, reinstalls, data resets |
| Purchase bonus | confirmed payment | real payment event | low, but a narrow invitee funnel |
| Mixed scheme with deferred accrual | recorded immediately, credited after the verification window | activity and first payments | manageable: anomalies are cut off before payout |
Deferred accrual is what is most often chosen in practice.
The event is recorded immediately and visible to the referrer as "pending", while the amount is credited after the verification window: for a purchase bonus — after the return period has passed, for an install bonus — after several days of invitee activity.
Technically, this means that each accrual has a state and a key such that a repeated verification run will not credit twice, and payment cancellation rolls back the bonus and recalculates the referrer's tier.
The choice between schemes is a choice between funnel width and verification volume. An install bonus yields more invitations and requires anti-abuse filters; a purchase bonus filters out junk on its own but brings fewer people.
Deferred accrual allows both effects to be maintained if states and rollbacks are described in the data model before launch.
Frequently asked questions before launching invitations
By the time of evaluation, the same doubts usually surface: what app stores allow, how to distinguish a genuine invitation from abuse, and what will happen to the mechanics after the next release. Below are short answers so that no unclear points remain at the start.
How is the mechanics protected from abuse?
Crediting is tied to the device and account, and the bonus is not credited at the moment of install but after the invitee's confirmed action. Plus limits per participant and detection of anomalous spikes — self-referrals from one device are cut off automatically.
Does this violate app store rules?
We design the mechanics within the rules: the reward is for actions inside the app, terms are described openly, and payouts do not bypass in-app purchases.
We verify the wording of screens and the offer before publication — this removes the main reason a build gets rejected during review.
What if the invitee deletes and reinstalls the app?
A reinstall does not count as a new invitation: the "device — account" link is stored on the service side, and a second bonus will not be credited. If someone received the link but installed the app later, the invitation is preserved and triggers on first authorization.
Will we have to release an update to change the terms?
Bonus amounts, limits, and crediting rules are moved into the service settings — they can be changed without releasing a new version to the store. An app update is needed only for new screens or changed interface logic.
Let's discuss the task and come back with an implementation plan
To make the scope estimate substantive and the implementation plan realistic, it is enough to prepare a few inputs for the conversation. A formal technical specification is not needed: what the product and support teams already have on hand is enough.
- What user actions count as an invitation: install via link, login by code, first purchase — the crediting logic depends on this.
- Where invitations are currently tracked: an in-house database, an accounting system, or spreadsheets, and whether history can be exported from there.
- What the reward looks like — points, a discount, a free period, internal currency — and who credits it.
- Abuse protection rules: invitation limit from one device, disposable number verification, manual review of disputed accruals.
- What analytics already captures: whether the fact of an invitation can be linked to the invitee's subsequent activity.
- Release constraints: when an app update is planned and which store reviews need to be passed.
- Who on your side makes decisions on crediting rules and handles disputed cases.
After the conversation, we will come back with a scope estimate, a stage-by-stage implementation plan, and a pilot proposal: we launch the mechanics on a limited group, compare metrics with expectations, and only then roll out to everyone.
Post-release maintenance includes accrual control, cutting off abuse, and refining rules based on actual data.
Describe the task — we will come back with an estimate and plan.