Mobile Retention
Part of Mobile referral programmes
Preventing repeated referral rewards
Define one referral entitlement, make credit retries safe, resolve competing claims and reconcile issued rewards.
Define one entitlement for each qualifying referral under a stated programme rule to prevent repeated referral rewards. Store it centrally, and make credit issuance safe to retry. Repeated app events, server requests or device changes must not create another reward for the same entitlement.
Define what can earn a reward
A programme might allow one reward for a new eligible customer’s first qualifying action, subject to a referrer limit. The exact rule is a product choice. State it before building the flow, so the app, reward service and support team use the same definition.
An entitlement record can identify the programme rule version, referrer, invited customer, qualifying action, decision status and relevant times. Keep customer identity in the appropriate account system and minimise personal information copied into the reward ledger. An analytics event or referral URL alone is a weak basis for issuing a financial or account credit.
Status / Meaning
- Pending
- Qualification, a reversal window or credit outcome remains unresolved.
- Awarded
- The intended credit is confirmed as issued for this entitlement.
- Declined
- The claim did not meet a stated rule.
- Reversed
- An issued reward was undone under a stated rule.
These are suggested internal states. A user-facing explanation can be simpler but should make a pending decision clear.
Referral Reward Eligibility Rules: Key Considerations
- Weak Basis for Reward
- Referral URL click or analytics event only
- Strong Basis for Reward
- Confirmed qualifying action (e.g., completed booking, first purchase)
Entitlement Status Definitions
- Pending
- Qualification unresolved; reversal window open
- Awarded
- Credit confirmed as issued
- Declined
- Claim failed to meet stated rules
- Reversed
- Reward undone under policy
Make retries safe
Use a unique key for the entitlement, and enforce uniqueness in the system that decides rewards. When concurrent requests arrive, only one should reserve that entitlement for issuance. Pass the same stable idempotency key to a credit provider if it supports one. Do not mark a reward as awarded merely because a credit request was sent: a timeout can leave the external outcome unknown.
If the credit provider cannot guarantee idempotent retries, check its transaction records or reconcile an uncertain attempt before sending another. A client-side “already rewarded” flag cannot protect an account used on multiple devices.
Check the qualifying action at its authoritative source. For a booking-based rule, use the confirmed booking record rather than a tap event. Apply the stated pending or reversal rule if the booking is cancelled or payment is reversed. Keep the rule version attached to past decisions when programme terms change.
Resolve competing and suspicious claims
One person may open several referral links before acting. Choose a rule for competing valid claims, and explain it where it affects rewards. Neither first-link nor last-link attribution proves which invitation persuaded the person. Keep a claim unresolved when evidence cannot support an award.
Review self-referrals and repeat accounts using proportionate signals. Shared devices and households can also belong to different genuine people. Route ambiguous cases to review rather than treating one signal as proof of abuse. Limit access to review data and record a reason for a declined claim.
Preventing Referral Fraud: Key Controls
- Review self-referrals and duplicate accountsUse proportionate signals; avoid automatic rejection
- Avoid relying on single signalsShared devices and households may involve genuine users
- Route ambiguous cases to reviewDocument reason for decline; limit access to sensitive data
- Apply consistent attribution ruleChoose between first-link or last-link—do not assume intent
Reconcile entitlements and credits
Compare entitlement decisions with credits or vouchers actually issued. An entitlement can be reserved while an external credit fails, or a credit can be duplicated outside the referral ledger. Keep the provider transaction reference and final outcome with the entitlement, so an uncertain operation can be investigated without issuing another reward by accident.
The implementation should be checked against repeated events, simultaneous requests, credit timeouts, cancellations, account changes and support corrections. No product test is claimed here.
