Referral Reward

Most users who receive a referral code never share it, or users whose code was redeemed never realize they earned the reward: either pattern makes this journey worth building. Make sure code creation, valid use and reward earning are tracked against the code owner, that the reward actually configured for the referrer and the friend can be read inside the flow, and that push permission and email subscription are stored. If sharing is low because the share path is awkward or the reward is unclear, review the program and the invite screen first; a reminder cannot repair that.

Incremental valid code use vs control

The journey's contribution is how many more codes in the messaged group see a valid use than codes in the control group; an opened push or a reported share is not a gain on its own.

How it is counted: Every referral code assigned at entry to either group forms the denominator; the numerator is the codes with at least one valid use within the same follow-up window from assignment, and the gap between the two groups is the journey's effect. Whether a message was delivered or clicked does not change the denominator.

Also track

• Code sharing rateAmong assigned codes, the share recorded as shared; the intermediate step before use, and the behavior the sharing reminder is actually aimed at.
• Result by branchRead codes that were used and unused at the check separately: the journey can only move use in the branch that got the sharing push; in the reward branch, check that the reward was reported correctly, and do not blend the two into one rate.
• Reward earning and invalid useCount valid use apart from reward earning and from qualified new customers; if repeated use of the same code or invalid transactions climb, the reward promise needs a review.
• Push opt-outs and unsubscribesWatch users who turn off push after the sharing reminder and who unsubscribe after the reward email; a message that implies a reward nobody earned turns into a complaint.

• Trigger and entryGiving a user a referral code starts the journey for that code. Code owners are split at random into the journey group and a control group that receives neither the reward email nor the sharing push; the reward itself is granted under the same rules in both groups.
• Who must not enterEach referral code opens its own journey instance: no second flow for the same code, and expired or invalid codes do not enter. A user whose code is already used at the check never enters the sharing reminder branch.
• Timing and channelsThree days after the code is received, the journey checks whether it was used. If it was, an email tells both parties they earned the reward; if not, a push asks the user to share the code; there is no further touch.
• Exit and handoffAfter the reward email or the sharing push is sent, the journey ends in its single exit with no re-entry. Nothing passes to another journey; a later redemption does not reopen this flow, and the reward is handled by the program's own rules.
• Frequency and consentExactly one message per referral code, either the email or the push. Email needs a subscription and push needs push permission; the message promises only the reward the program actually defines and never sends invitations on the user's behalf.

1. 1If valid code use in the journey group does not beat the control group, the push either pulled forward users who would have shared anyway or had no effect; push opens and share events do not make up for that. Let the valid-use gap between the two groups drive the decision, and check from time to time that the message promises only the configured reward.
2. 2A 3-day wait and a single touch are all this result covers. Read reward earning from the program's own records; do not equate the number of uses with qualified new customers or purchases, and count any reminder that reached an already used code separately as a data fault.
3. 3When valid code use is a rare event, a small gap can be chance; before the test, use the sample size calculator with your current use rate and the smallest lift you want to see to find the codes needed per group, then divide by the daily number of new codes to plan how many days the test must run.