Referral Programme Economics: Cost the Reward Promise Before Scaling

A give/get referral offer looks simple: a new customer gets a benefit and the person who referred them earns a reward. The dashboard shows new customers at a low acquisition cost, so the team wants to increase the incentive. But the apparent efficiency may depend on a timing mismatch. The friend benefit has already reduced the first order, while much of the referrer reward has been earned but not redeemed. A report that counts only rewards used this week can make a growing obligation disappear.

This guide builds an operating review for ecommerce brands, consumer subscriptions and early-stage businesses with a defined qualifying transaction. It is not a referral-growth forecast, a fraud detector or an accounting opinion. All figures are synthetic and do not represent Akshay's client results. The method is original Growthcraft synthesis: one acquisition cohort, an explicit cost boundary, a reward ledger and a scenario that makes the outstanding promise visible.

Four decisions to make before increasing the reward

• Count earned awards, not only rewards already redeemed.
• Deduct the friend benefit exactly once and distinguish reward face value from economic cost.
• Compare your redemption assumption with 100% redemption; do not call either scenario a forecast.
• Report cost per attributed customer separately from incremental acquisition cost.

Use the reward promise review framework for ownership and launch gates, the contribution and redemption calculator for the numbers, and the evidence review prompt to challenge an incomplete launch brief.

Why reward design needs a cost contract

Shopify's referral guide discusses two-sided benefits, tiered awards and different reward formats. Those options create different operational obligations; a free product, a cash payment and a discount are not interchangeable cost inputs. Its page currently uses a 2026 title but visibly dates publication to June 7, 2025. Treat it as an existing design reference, not evidence of a new October release or measured keyword demand. Source: Shopify referral programme ideas, checked October 12, 2026.

The useful question is not which reward sounds most generous. It is whether the offer supports the business decision after all relevant costs, qualification rules and customer promises are specified. A low observed redemption rate might reflect an immature cohort, an inconvenient redemption journey or a genuinely low use rate. Those explanations lead to different actions. The spreadsheet should expose the dependency rather than silently treating every unredeemed reward as a permanent saving.

Start with the customer promise in plain language: who receives what, after which action, when it becomes available, and what happens after a return or cancellation. The analyst needs that promise to determine when an award is earned. The support team needs it to explain the programme consistently. The commercial owner needs it to understand exposure. Do not let the implementation invent a different policy from the landing page.

Freeze the cohort and both horizons

Define one acquisition cohort, such as customers whose qualifying first purchase occurred in a specified month. Record the currency, acquisition dates, qualifying transaction, refund treatment, extraction timestamp and contribution horizon. Contribution might cover the settled first order or a fixed period of service. Do not compare one cohort's first-order contribution with another cohort's lifetime estimate under the same label.

Then define a separate reward horizon. An award earned by a September acquisition can be redeemed in November. Keep it linked to the September acquisition cohort for this review, even though the cash movement occurs later. A fixed acquisition cohort does not require all costs to occur during its acquisition month. If future redemption is unknown, retain the award and model its economic cost under explicit assumptions.

Qualification is a business definition, not merely a billing-system label. For example, Stripe Checkout documents first-time transaction restrictions and notes that eligible promotion codes can also be accepted in guest-customer sessions. A billing restriction is therefore not, by itself, proof of a distinct new human or household. Stripe also documents customer, minimum-amount, expiry and redemption controls. Check the actual integration and account behaviour before relying on a restriction. Source: Stripe Checkout discounts, living documentation checked October 12, 2026.

These controls are implementation ingredients, not a complete abuse policy. Define how duplicate accounts, self-referrals, shared addresses, forwarded links and disputed eligibility are investigated. Avoid automatically labelling a person fraudulent from a single matching attribute. Keep customer-level evidence and any appeal process in authorized systems; the public calculator needs aggregate counts only.

Specify what each cost includes

Let N be qualified acquired customers and C their average contribution before the programme benefits entered separately. C should already reflect the ordinary variable costs relevant to the declared horizon: product or service delivery, fulfilment, payment costs, support where allocated and settled refunds. It is not gross sales. The cost contract must say whether discounts are already reflected in net revenue; otherwise a perfectly implemented formula can still double-count the friend benefit.

Let F be the average new-customer benefit cost per qualified customer. If C already includes that benefit, set F to zero and document the treatment. Let A be earned referrer awards, not unique referrers. A can differ from N when rewards are tiered, multiple advocates are eligible or the rules create more than one award. Do not force an artificial one-award-per-customer assumption just because the default example uses one.

Let R be the economic cost per redeemed referrer award under a stated policy. A cash reward has a relatively direct cost. A product reward requires product and fulfilment costs. A discount on a referrer's later purchase requires a declared treatment of foregone contribution and ordinary purchase behaviour. Face value is not automatically the right answer. When the policy is uncertain, run separate cost scenarios instead of averaging unlike reward types without explanation.

The simple model does not credit any additional contribution from the referrer's future purchase. That is a separate hypothesis requiring evidence. Adding the whole future order margin while also assuming the customer would not otherwise have bought can make the offer look artificially profitable. Likewise, an accounting liability or a cash reserve is not determined by multiplying face value by a convenient redemption percentage. Ask the responsible finance team to apply its own policies.

Work through a two-sided reward example

Suppose 200 qualified customers generate 30 currency units each before programme benefits. Each receives a benefit costing 10. Their acquisitions earn 200 referrer awards costing 20 each if redeemed. The programme is allocated 1,000 of other costs. The analyst tests a 60% redemption assumption; this percentage is supplied for illustration, not estimated from real behaviour.

Component	Calculation	Currency units
Base contribution	200 × 30	6,000
Friend benefits	200 × 10	2,000
Referrer rewards, scenario	200 × 20 × 60%	2,400
Other programme costs	Declared allocation	1,000
Contribution remaining	6,000 − 2,000 − 2,400 − 1,000	600
At full redemption	6,000 − 2,000 − 4,000 − 1,000	−1,000

Total programme cost under the 60% assumption is 5,400, or 27 per attributed qualified customer. The model leaves 600, but full redemption removes another 1,600. Neither result establishes incremental profit: the customer count is attributed to the referral programme, and the counterfactual without the offer is unknown.

The algebraic break-even redemption fraction is [N(C−F)−K]/(AR), where K is the other programme cost. Here it is [200(30−10)−1,000]/(200×20)=0.75. At 75% redemption the remaining contribution is exactly zero. Moving from 60% to 75% is a 15-percentage-point increase, not a 15% relative increase. The threshold is a sensitivity diagnostic, not a prediction that redemption will stop there.

If the threshold exceeds 100%, every feasible redemption rate fits the supplied model. If it is negative, even zero reward redemption cannot cover the other costs. When AR is zero there is no redemption-dependent threshold; the base programme may still lose money. When N is zero, cost per acquired customer is undefined, not zero. These edge cases must remain visible in the result and export.

Implement the arithmetic without premature rounding

The function below uses integer minor units for money and basis points for redemption: 60% becomes 6,000 out of 10,000. It is a compact aggregate calculation, not a payment function. Run it in modern Node.js with BigInt support. Inputs are whole minor units; the companion web tool accepts currency units with two decimals and converts them before calculation. Expected economic cost can contain a fractional minor unit, so do not round each award to cents before multiplying.

function rewardBalanceMinor(x) {
  const keys = ["customers","contributionMinor","friendMinor","awards","rewardMinor","redemptionBps","fixedMinor"];
  if (!x || keys.some(k => !Number.isSafeInteger(x[k]))) throw new Error("Integer inputs required");
  if (keys.some(k => k !== "contributionMinor" && x[k] < 0) || x.redemptionBps > 10000) throw new Error("Invalid range");
  const n=BigInt(x.customers), c=BigInt(x.contributionMinor), f=BigInt(x.friendMinor);
  const a=BigInt(x.awards), r=BigInt(x.rewardMinor), p=BigInt(x.redemptionBps), k=BigInt(x.fixedMinor);
  const capacity=n*(c-f)-k, maximumReward=a*r;
  return {
    balanceNumerator: (capacity*10000n-maximumReward*p).toString(),
    denominator: 10000,
    unit: "minor currency units",
    fullRedemptionMinor: (capacity-maximumReward).toString()
  };
}

For the worked example, pass customers=200, contributionMinor=3000, friendMinor=1000, awards=200, rewardMinor=2000, redemptionBps=6000 and fixedMinor=100000. The balance numerator is 600000000 over 10000, giving 60000 minor units, or 600 currency units. Full-redemption contribution is −100000 minor units, or −1,000. The string representation keeps large intermediate integers intact when exporting JSON.

Test more than the default example. At the exact 75% threshold the numerator must be zero. Holding all else fixed, increasing redemption cannot increase contribution. Scaling customer count, award count and allocated programme cost by the same positive integer must scale total contribution by that integer without changing cost per customer. With zero reward cost, changing redemption must have no effect. Reject missing inputs rather than letting JavaScript coerce them into zero.

Build the award ledger around the promise

Store a stable award identifier, anonymous acquisition identifier, programme version, qualification timestamp, reward type, face value, economic-cost policy and lifecycle status. Keep pending qualification, earned, redeemed, reversed and expired states distinct according to the published terms. Do not overwrite an earned award with a redeemed record and lose the original qualification evidence. A status event history makes late changes explainable.

Issuance needs an idempotent business key, such as the qualifying acquisition and reward rule version, with a database uniqueness constraint appropriate to your rules. A repeated payment notification must not earn a second award accidentally. Conversely, two legitimate tier awards must not collapse into one merely because they belong to the same advocate. Test those rules with synthetic records in a non-production environment before launching.

Reconcile the ledger in both directions: every counted award should point to an eligible acquisition, and every qualifying acquisition should have the award outcome required by its rule. Investigate orphan awards, duplicated issuance, reversals after redemption and unprocessed qualification events. Do not silently remove discrepancies from the denominator. The economics calculator cannot repair an incomplete ledger; it only shows the implications of the counts you supply.

Turn the result into a responsible growth decision

The first decision is whether the proposed promise is commercially acceptable under clearly stated scenarios. The second is whether the programme creates additional qualified customers or merely subsidizes purchases that would already have occurred. A referral code answers an attribution question, not the second causal question. A bounded experiment needs a suitable assignment unit, controls for spillover, an outcome horizon, guardrails and an analysis plan; those do not emerge automatically from a break-even calculation.

For a consumer brand, watch settled contribution, returns and customer experience alongside referral participation. For an app, include the variable service cost and reward duration in the chosen horizon. For a startup, explicitly allocate manual review and programme operations rather than calling founder time free. Compare channels only when cost scopes, qualification and maturity are compatible.

A positive scenario with a negative full-redemption result is an exposure to explain, not a reason to make redemption harder or change existing promises. Validate the assumption, approve a bounded test and preserve the support experience. If the data cannot establish the cost boundary or award balance, hold the launch. The useful output is a reproducible cost review and an owned evidence request—not an unsupported claim of viral growth.