Calculate your Loyalty Economy

This calculation gives you your earn rate: how many tokens a typical action should earn.

Work this out once, for your whole economy, before you configure any loyalty solution. It gives you a target earn rate per action which the number every token-paying mechanism (reward rules, quests, levels, perks, achievements) should average out to.

Since you'll typically have several of these active at once, this target isn't something you type into a single field. Instead, once they're set up, you check their blended payout against this target and adjust any one mechanism's Amount if the blend drifts too far off.

1. Start with how many tokens fit inside your budget:

   Allowance = B × P

   This is your monthly token allowance per user. It's simply your budget converted into tokens, using your peg rate.

2. Then divide that across how often a typical user acts, to get your earn rate:

   E = Allowance ÷ Am

   Am is your median monthly activity, from the table above. Round E to a whole number.

Output: An earn rate (E)

Example: Say you're running a loyalty programme. You've decided you're willing to pay out $2 worth of tokens per active user, per month (B), and you've set your peg so that 100 tokens equal $1 (P). Your typical user takes 20 qualifying actions a month (Am), things like logging in or placing a bet.

You want to work out a target earn rate, then check whether your actual reward rules and quests, blended together, pay out close to it.

1. First, work out your total token budget for that typical user:

Allowance = B × P = $2 × 100 = 200 tokens

In plain terms, if a typical user logs in and places bets at their usual pace all month, you're willing to let them walk away with 200 tokens.

2. Then spread that across their 20 actions, to find out what a single action should be worth on average:

E = Allowance ÷ Am = 200 ÷ 20 = 10 tokens per action

So on average, every qualifying action a typical user takes should earn them about 10 tokens. That's your target.

Now, you don't actually have one reward rule or quest paying exactly 10 tokens every time. You have several rules and quests running at once, each paying something different. Say your typical user's 20 actions break down like this:

• They log in most days: 15 logins/month, 5 tokens each

• They place a handful of bigger bets: 5 bets/month, 30 tokens each

So, Add up everything this user actually earns in a month:

(15 × 5) + (5 × 30) = 75 + 150 = 225 tokens

Then spread that back across their 20 actions, the same way you did for the target:

225 ÷ 20 = 11.25 tokens per action

Your actual rules average 11.25 tokens an action against a target of 10, about 12.5% over. That's close enough to leave as-is. If the gap were much wider, say 15 instead of 11.25, you'd lower the Amount on your daily login or bet-size rule until the blended average comes back down near 10.

Recalculate the blend whenever you add, remove, or change a reward rule or quest, since each change shifts what your rules pay out on average, and check it against your target again.

Run this before you add a new item to your redeem catalogue with a stated real-world value, such as a $5 gift card. It converts that value into tokens using your peg, then checks whether it's affordable within your chosen timeframe against your budget. If it fails, adjust the item's value, its timeframe, or your budget, not the earn rate.

1. Convert the item's price into tokens, using the same peg:

   Price = R × P

2. Check that this specific item is actually affordable within the timeframe you want:

   R ÷ T ≤ B

Output: An item priced in tokens (Price), and a pass or fail on affordability

Where this applies: Price maps directly to Product price in tokens (Physical, Digital), Price (tokens) (Internal Rewards), or Conversion Rate (Currency) on that redeem option.

Example: Say you want to add a $5 gift card to your catalogue, and you want users to reach it within T = 1 month. Your peg (P) is 100 tokens per dollar, and your budget (B) is $2 per active user, per month.

1. Price = $5 × 100 = 500 tokens

2. $5 ÷ 1.0 = $5.00 per month

   This affordability check ($5.00) is 2.5 times your $2.00 budget.

When a check fails, fix the inputs, not the earn rate. You have three ways of doing this:

• Stretch T (make the item take longer to reach)

• Cut R (lower the item's value)

• Raise B (increase the budget)

Stretching T to 2.5 months resolves it: $5 ÷ 2.5 = $2.00 per month.

An earn rate that's affordable for a typical user can still be dangerous for your most active ones. This calculation checks that, and sets a hard limit.

Work it out once, for your whole economy. Then, every time you add or change a reward rule, quest, level bonus, or perk, add up the maximum tokens a single user could earn from everything they're eligible for, and check that total against the cap you set.

If it's higher, tighten the frequency or amount on one or more of those rules until it isn't, paying particular attention to a Currency redeem option's Conversion Rate, since an overly generous rate is the fastest way to blow past this cap.

1. First, work out how much more active your heaviest users are:

Disp = Ah ÷ Am

For example, your heaviest users take five times as many qualifying actions as a typical user (Disp = 5). Left unchecked, they could cost you five times your budget, $10 a month each, purely from being more active, with no mistake anywhere in your setup.

2. So you set a cap:

Cap = k × B × P (k is how much overspend you'll tolerate, usually 2–3)

Then check your blended cost, across your whole user base, still lands close to budget once the cap is applied.

Our example: with the cap applied, this blends to $2.20 against a $2.00 budget, close enough to sign off. Without the cap, that same population would have blended to $2.80, a 40% overrun caused by just one heavy-user group in ten.

Output: a monthly earn cap per user (Cap).

There's no platform setting that limits how many tokens a user can earn. Cap is a calculated figure you can use as a target when setting reward token amounts on your reward rules, quests, level bonuses, and perks.

Example: Continuing the running example, your budget (B) is $2, your peg (P) is 100 tokens per dollar, your typical user (Am) takes 20 qualifying actions a month, and your heaviest users (Ah) take 100.

1. Disp = Ah ÷ Am = 100 ÷ 20 = 5

Your heaviest users are five times as active as a typical user. Left unchecked, they could cost you five times your budget, $10 a month each, purely from being more active, with no mistake anywhere in your setup.

2. To set a Cap k = 2:

   Cap = 2 × $2 × 100 = 400 tokens per user, per month

This example assumes 1 in 10 users is a heavy user. Use your own numbers here, based on how your users actually split between typical and heavy.

Now check your blended cost across your whole user base, using a weighted average of what each group costs:

Blended cost = (share of typical users × typical cost) + (share of heavy users × heavy user cost)

• Without the cap, a heavy user costs $10/month:

(0.9 × $2) + (0.1 × $10) = $1.80 + $1.00 = $2.80

That's a 40% overrun on your $2.00 budget (B), caused by just one heavy-user group in ten.

• With the cap applied, a heavy user costs $4/month instead:

(0.9 × $2) + (0.1 × $4) = $1.80 + $0.40 = $2.20

That's only 10% over your $2.00 budget, close enough to sign off.

Check whether a brand-new user can reach the cheapest item in your redeem catalogue (under Redeem > Options) within about a week of typical activity:

Cheapest ÷ (E × Am ÷ 30) < 7 days

If they can't, most won't stick around long enough to find out what else is on offer. Nothing in the product will warn you this is happening, the widget won't show an error, engagement will just quietly decline.

Output: Confirmation that your cheapest redeem catalogue item is attainable

Where this applies: If this check fails, lower the price on your cheapest offering in the catalogue, or raise the token amount on the reward rule or quest that feeds it. It's a check you run against decisions you've already made elsewhere, not a new field of its own.

Every item you add to your redeem catalogue (under Redeem > Options) needs a token price. Work this out once per item, using the same peg you used everywhere else:

tokens = currency value × P

Currency conversion rate

For a Currency redeem option, the Conversion Rate takes the currency value of one token, not a token price. Enter 1 ÷ P, which converts your peg from tokens per unit of currency into currency per token. For example, with a peg of 100 tokens per dollar, enter 0.01, meaning each token is worth $0.01.

If everything in your catalogue costs more than a new user can earn in a month, you've built a savings account nobody uses, and you'll see it show up as a low redemption rate.

Output: A token price for each item in your catalogue.

Example: Continuing the running example, your peg (P) is 100 tokens per dollar. Say you're pricing three items for your catalogue: a $0.40 sticker, a $2 gift card, and a $5 gift card.

Sticker: $0.40 × 100 = 40 tokens
$2 gift card: $2 × 100 = 200 tokens
$5 gift card: $5 × 100 = 500 tokens

You'd repeat this same calculation for every item you add, whatever its real-world value is.

Where this applies: Type the result directly into Product price in tokens (Physical, Digital) or Price (tokens) (Internal Rewards) on that redeem option. For Conversion Rate (Currency), enter 1 ÷ P.