Referral growth platform
How it relates to loyalty
The reward economics — reward type and value, minimum order, cap, first-order-only, referrer points — live in your loyalty programme configuration, which the live referral engine reads when minting and converting codes.
This hub owns the governance layer on top: approval to launch, the kill switch, budget, fraud policy and copy — and syncs economics through to the loyalty config so there is one management surface and no split-brain between two places that both claim to set the reward.
If you only want the basic referral mechanic, loyalty referrals covers it. This page is what you need when the programme is spending real money.
The eight tabs
| Tab | What it is for |
|---|---|
| Overview | KPIs, leaderboard, acquisition funnel and timeseries |
| Program | Configuration, launch approval, kill switch, budget |
| Codes | Every minted referral code and its counters |
| Conversions | The per-order ledger, including clawbacks |
| Fraud | The review queue |
| Copy | Versioned, localisable, publishable copy |
| Invites | Campaigns to your existing base |
| A/B tests | Copy experiments |
Governance
| Control | What it does |
|---|---|
| Launch approval | A programme cannot go live without a second person approving it |
| Kill switch | Stops the programme immediately without deleting configuration |
| Rolling budget | A cap on referral reward spend over a rolling window |
| Fraud policy | Thresholds for the detectors below |
A referral programme is an open-ended discount commitment. The kill switch exists because "turn it off now" and "unpick the configuration" are different urgencies, and the rolling budget exists because the failure mode is not one bad order, it is a code spreading somewhere you did not intend.
Copy that matches the offer
The copy tab authors the marketing text. The programme configuration holds the actual reward. These can drift, and when they drift customers arrive at checkout expecting something different from what they get.
Typed incentives in free text — $20 off, 15%, free shipping — are parsed
into a structured offer and reconciled against the configured discount, with
any mismatch surfaced before you publish.
Copy is versioned per locale, with one published row per store and locale. What is published is what the storefront widget renders and what invite campaigns send — so publishing pushes copy live without retyping it into the theme editor.
The conversion ledger
Every referred order becomes a conversion row: which code, which referrer, which referee, the order value and the reward.
Refunds and cancellations reverse the conversion, so the leaderboard and the programme cost reflect kept revenue rather than gross orders. Without clawback, a referral programme's reported performance drifts steadily above reality by exactly your refund rate.
Fraud
Referral fraud is detected heuristically, because the order path has no device fingerprint. The signals are built from what is genuinely available: customer identity, order timing, refund ratios and email quality.
| Signal | Raised | What it catches |
|---|---|---|
| Self-referral attempt | At order time | Someone using their own code. The block happens in the engine; the signal exists so repeat abusers surface |
| Shared identity | At order time | Referrer and referee resolving to the same person |
| Disposable email | At order time | Throwaway addresses used to farm rewards |
| Velocity | Daily sweep | An implausible number of conversions in a window |
| Refund abuse | Daily sweep | A referrer whose referred orders are refunded at an abnormal rate |
The two aggregate detectors need a cross-order view, so they run as a daily sweep rather than inline.
Invite campaigns
Codes were historically minted only for customers who visited the storefront while logged in — which meant there was no way to push the programme to the base you already have.
An invite campaign blasts your published referral copy to a Customer 360 segment by email and SMS, with each recipient's own code and share URL generated or retrieved. Sends run in the background, one recipient at a time, fail soft, and respect email opt-in.
Copy A/B tests
Each referrer is bucketed to a variant deterministically, and that variant's copy is genuinely served to them — in the storefront widget and in invite sends. Serving records an exposure.
The engine stamps the variant on every conversion, so results compare conversions among the exposed, divided by exposures, per arm.
Without three things — copy that is actually served, copy that actually differs, and a denominator of who saw it — a declared "winner" is noise dressed as a result. Creating an experiment therefore requires per-variant copy; there is no way to run a test where both arms show the same thing.
Analytics
| View | What it answers |
|---|---|
| KPI header | Codes minted, conversions, revenue, programme cost |
| Leaderboard | Your most effective referrers |
| Acquisition funnel | Share → click → order |
| Timeseries | Trend over time |
| Code and conversion tables | Paginated detail, with clawbacks visible |
Permissions
| Permission | Grants | Minimum plan |
|---|---|---|
referral:read:all | View the hub | Free |
referral:copy:generate | Generate, edit and save copy | Starter |
referral:manage | Configure, manage codes, triage fraud, run invites | Starter |
referral:copy:publish | Publish copy live to the storefront widget | Pro |
referral:experiment:manage | Launch, decide and abandon experiments | Pro |
referral:approve | Approve a programme launch (checker) | Agency |
Plan tiers
| Capability | Free | Starter | Pro | Agency | Enterprise |
|---|---|---|---|---|---|
| View the hub and analytics | ✓ | ✓ | ✓ | ✓ | ✓ |
| Programme config, codes, conversions | — | ✓ | ✓ | ✓ | ✓ |
| Fraud queue and daily sweep | — | ✓ | ✓ | ✓ | ✓ |
| Copy authoring and versioning | — | ✓ | ✓ | ✓ | ✓ |
| Invite campaigns | — | ✓ | ✓ | ✓ | ✓ |
| Publish copy to the storefront widget | — | — | ✓ | ✓ | ✓ |
| Copy A/B experiments | — | — | ✓ | ✓ | ✓ |
| Launch approval (second checker) | — | — | — | ✓ | ✓ |
Best practices
- Set the rolling budget before you launch, not after the first surprise week.
- Publish copy rather than pasting it into the theme. The published row is what the widget and invites both read, so they cannot drift apart.
- Run an invite campaign to your existing base. Most referral programmes under-perform because nobody knows they exist, not because the reward is wrong.
- Check the reconciliation warning before publishing. A copy-versus-config mismatch is a support ticket per order.
- Let an experiment run to a real sample. Referral conversion rates are low; a two-day test tells you nothing.
See also
- Affiliate program — partner-driven, a different motion
- Loyalty referrals — the reward economics this governs
- Segments & cohorts — building the invite audience
- A/B testing & experiments — the wider experiment platform