.svg){kind=icon}
An AI product almost never makes its money at the signup. Someone creates an account, often on a freemium? tier, and the revenue arrives afterwards — a pack of tokens? this week, a bigger one next month, a subscription? that renews four times before they stop.
If you pay your partners at the signup, you are paying the same amount for an account that spent nothing and an account that spent four hundred dollars. This article builds one rule that waits, adds up what an account actually spends, and pays a bonus when it passes a number you choose.
A token is not a unit of value
Start here, because getting this wrong is the difference between a rule that pays what you agreed and a rule that quietly pays the wrong partners.
It is tempting to set the threshold on the token count — pay a bonus once this account has bought a thousand tokens. It reads naturally and it is how the business talks internally. It is also the one thing not to do.
tokens? are priced in packs, and packs are discounted. Bulk buyers, promotional pricing, regional pricing and loyalty tiers all mean the same thousand tokens are worth different amounts of money depending on who bought them.
Send the money instead. One Number data point carrying what the pack cost, in your currency, and the threshold means the same thing for every account on the platform.
The number you need
One number: what the purchase was worth, sent on the conversion as a custom data point?.
You do not need a new number to calculate. Your billing system already knows what every pack sold for, because it charged for it. That makes this one of the easier Customer Value setups — unlike, say, net gaming revenue, where the figure has to be worked out in arrears.
Your words, and where they live in Everflow
Everflow has no AI mode. It has no idea what a token is, what a companion is, or what a credit buys. That is deliberate — the same machinery serves a casino and a insurance broker — so you supply the nouns. This is the translation.
| You call it | In Everflow it is | Worth knowing |
|---|---|---|
| Token or credit spend | A Number custom data point holding the purchase value | Send what it cost, not how many tokens it was. A token is not a fixed amount of money. |
| Token pack | A conversion carrying that data point | Every pack is its own conversion. The rule adds them up. |
| Subscription renewal | Also a conversion with a value | Renewals and packs can feed the same data point if the deal treats them the same. |
| Free tier / freemium | Nothing, until money moves | A signup with no purchase contributes zero. That is usually correct. |
| Lifetime value | A running total on a Continuous cycle | Continuous never resets, so the total is genuinely lifetime. |
| Spend threshold | A goal condition using Greater Than | There is no "between". Two bands means two rules. |
| Bonus at a threshold | Outcome type Bonus — a flat amount, once per cycle | Bonuses are CPA only. A percentage needs a substitution. |
| Revenue share on spend | Outcome type Substitution, priced off the data point | Replaces the payout rather than adding to it, and has no per-cycle limit. |
| Account or user | A user ID | One key, every event, for the account's whole life. The most common integration miss. |
Step 1: Create the data point
Go to Customer Value → Custom Data Points → + Data Point. Name it for the money, not for the tokens — Token Spend rather than Tokens — because in six months someone else will read this rule and the name is all they will have.
https://<your-tracking-domain>/?nid=1&transaction_id=<tid> &user_id=a_9f31c8 &token_spend=12.00
→ How To Send User IDs & Data Points For Customer Value — the developer-facing setup, and how to prove the values arrived.
Step 2: Choose the window
Create the rule under Customer Value → Payout & Revenue Rules → + Rule, and skip to the Timeframe step. This is the goal cycle?, and it decides how long an account has to reach the threshold.
Continuous
Never resets. The account's total keeps climbing for as long as the rule runs. This is what people mean by lifetime value.
From First Conversion
A window per account, starting on its own first conversion. "Did they spend $100 in their first ninety days?"
Fernly uses thisRecurring
Resets on a shared calendar — every month, quarter, week. Right when the deal is about a period rather than about the account's own life.
Fernly uses From First Conversion?, because every account starts its life on a different day and the question is what did this account spend in its first ninety days, not what did it spend in March.
Step 3: Set the threshold
The Behavior step is where the deal lives. Three controls matter, and one of them is the setting people most often get wrong.
Pick the data point
Data points are grouped by type and only Numbers appear here, which is the product telling you something: if your data point is missing from this list, it was created as Text and cannot be summed.
Pick the operator
There are three operators and no more. There is no between, so a tiered deal — a bonus at $100, a larger one at $500 — is two rules, not one.
Running total, not this purchase
This is the expensive mistake, and it hides well because the rule still fires.
running total? measures everything the account has accumulated in the cycle — on a Continuous cycle that is the account's lifetime value?. The alternative measures only the single purchase that happened to cross the line — so an account that crawls past $100 with a $4 top-up? pays a bonus calculated on $4.
The purchase that crossed the line
The account reached $104 across nineteen purchases. The nineteenth was a $4 top-up, and that is the one that tipped it over $100.
Running total
The outcome is calculated on everything the account accumulated in the window, which is the number the deal was written about.
Step 4: Choose the reward
Set Outcome Type. This is where the deal shape is decided, and there is a constraint worth knowing before you promise anything to a partner.
A bonus? can only pay a flat amount — the payout model is fixed to CPA. If you want the partner to earn a percentage of what the account spent, that is a substitution?, which replaces the payout rather than adding to it, and has no once-per-cycle limit.
A flat amount at a threshold
Added on top of whatever the partner already earned. Capped at once per cycle, and the payout model is fixed to CPA.
A share of what they spent
Replaces the payout rather than adding to it. No per-cycle cap, and it can be priced as a percentage of your data point.
Flat up front, share after
Two rules on the same partner — a signup payout from your ordinary offer settings, and a Customer Value rule for the spend that follows.
Check it worked
The rule is live the moment it saves, and it only looks forward — it will not reach back over spend that already happened.
Look up one account
Go to Customer Value → Conversion Events, enter one user ID, and set the range to cover the whole window. You are checking that a value arrived on each purchase, not just the first. A rule that has not fired yet looks exactly the same whether you are looking at churn? or at an account that simply has not reached the threshold, so the events are the only thing that tells you which.
Or read it as an API call
Build the report you want in the interface, then press Show API Request. It hands you the finished call, with the filters you set already in it.
For an AI team this is usually the more comfortable route — it turns a reporting screen into something you can run on a schedule, diff between runs, or hand to your own assistant.
What you get
Payouts that follow the money
Partners earn on accounts that actually spend, not on accounts that merely signed up.
One rule, every account
The same rule covers every account on the offers it is scoped to. You are not writing one per partner.
A reason to send better traffic
A partner who can see which sources reach the threshold will send more of those. That is the whole point of paying on value.
Something you can query
Show API Request turns the per-account view into a call you can run on a schedule.
Common questions
QDoes Everflow convert tokens into money for us?
No. Everflow stores and adds up whatever number you send it. If you send a token count, the threshold is a token count — with all the problems above. The conversion from tokens to money happens in your billing system, before the value is sent.
QWill a new rule pay on spend that already happened?
No. A rule starts looking at conversions the moment it is saved. It will not reach back over the spend an account accumulated last quarter, so there is no way to retro-pay a partner for an account that was already valuable before the rule existed.
QWhere do I see this per account?
The Conversion Events report is the purpose-built view: one account, every purchase, the data points that arrived on each, and which rule applied. The Flex Report can also break down by user in the network UI, which is the better route when you want per-account figures alongside your ordinary reporting dimensions.
QCan I really not threshold on the token count?
You can — Everflow will happily sum whatever number you send. The question is whether the threshold means the same thing for every account, and with discounted packs and promotional pricing it does not. If your tokens are sold at one fixed price and never discounted, a count is safe. The moment you run a promotion, it stops being.
QWhat about subscriptions as well as packs?
If the deal treats them the same, send both into the same data point and the total covers everything the account spent. If the deal pays differently for a renewal than for a pack, keep them as separate data points so a rule can tell them apart.
QDo refunds and chargebacks come back out?
Only if you send them. Everflow adds up what arrives, so a refund reduces the total when your platform sends a negative value against the same user. Nothing subtracts automatically.
QOur tokens are priced differently per region. Does that matter?
Not if you send the money. That is the main argument for doing it this way — regional pricing, promotions and bulk discounts all resolve themselves once the data point carries the value rather than the quantity. Send it in one currency and convert before you send.
QCan one account trigger the bonus more than once?
Not within a cycle — a bonus is capped at once per cycle per customer. On a Continuous cycle, which never resets, that means once, ever. If you want it to recur, use a Recurring cycle, and the account can earn it again each time the cycle turns over.
QWhy did a rule stop firing after we changed our pricing?
Almost always because the threshold was set against the old prices. If a pack that used to cost $12 now costs $8, accounts take longer to reach $100 and the bonus fires less often. The rule did not change; the money did.
→ Introduction To Customer Value — what a rule decides, and the five shapes people build.
→ How To Send User IDs & Data Points For Customer Value — getting the number flowing in the first place.
→ Build Your First Customer Value Rule — the simplest possible rule, if this is your first one.
→ Paying On Net Gaming Revenue (NGR) With Customer Value — the same machinery, carrying a losing month forward.
