.svg){kind=icon}
This builds one complete, working rule from nothing: pay your partners the full rate the first time a customer buys, and a reduced rate every time that same person buys again. It takes about ten minutes and it is the best first rule to build, because everything else in Customer Value is a variation on it.
What you will build
The problem this solves
You pay 20% for a sale. A customer buys in March, then again in June, then again in September. Your partner earns the full 20% acquisition rate three times, but they only acquired that customer once. The second and third sales were going to happen anyway.
You want to keep paying 20% for genuinely new customers and something closer to 10% for repeats. The hard part has never been the payout maths. It is that nothing in the conversion itself says this is the same person as last time.
The shape of it
The rule builder is three screens. Everything you are about to do lives on one of them, and the Rule Summary panel on the right updates as you go so you can always see what you have built so far.
Part one: get the identity flowing
This happens outside the rule builder, and it has to be working before the rule can do anything.
Fire a test conversion and confirm it shows up in the Conversion Events report before you go any further. If it is not there, no rule you build will work, and the rule will not tell you why.
Part one, checked
Text is the choice that matters here, and it is the one you cannot undo.
Part two: General
Go to Customer Value, then Manage Payout & Revenue Rules, and add a rule.
That one toggle is the choice worth slowing down for, because it decides who the goal is about.
Part three: Timeframe
Click Next. This screen decides when the rule is live and whether a customer's progress ever goes back to zero.
Part four: Behavior
Click Next. This is the screen that does the work, and it has one trap in it.
The condition, and the mistake almost everyone makes
Your first instinct will be to build the condition on the email, because the email is the thing that tells you somebody is a repeat. That instinct is wrong, and chasing it costs people about twenty minutes.
What people try first
Custom Data Point: Customer Email
Operator: ...?
And then they stop, because there is no operator that means has been seen before. Conditions compare a value against a number. They cannot ask about history.
What actually works
Metric: Total of Base Conversion Events
Operator: Greater Than
Number: 1
More than one conversion for this person means they have bought before. That is exactly what a repeat customer is, and it is a number, so a condition can test it.
The toggle between Metric and Custom Data Point is the first thing on the condition, and it is the fork in the road.
The outcome
Click Add to save the rule.
Check it worked
Do not take the save confirmation as proof. Put two conversions through with the same recognisable email, a few minutes apart.
Do the same on the first conversion and that field should show a dash. That is the rule working correctly, not failing: at that point the customer had exactly one conversion, which is not greater than one.
If nothing happened
| What you see | What it usually means |
|---|---|
| The data point is missing from the conversion | The parameter name does not match. Compare it against the Parameter column character by character, including case. |
| Both conversions are there but neither carries the rule | They were counted as two different people. Check that the email value is identical on both, with no trailing space and no change of case. |
| The rule applied to the first conversion too | The operator is probably Equal To rather than Greater Than, or the number is 0 rather than 1. |
| The report returns No Record Found | Almost always the date range, not the rule. It defaults to today only. Widen it to Year to Date. |
What you have now
A live rule that pays the full rate the first time somebody buys and a reduced rate every time after that, working out who is who on its own, with no list to maintain.
Quick reference
| Setting | Value | Why |
|---|---|---|
| Data point type | Text | An email is a label, not a number |
| Progress Towards The Goal Is | Shared | A repeat customer is a repeat customer whoever sent them |
| Goal Cycle | Continuous | Being a repeat customer never resets |
| Apply Condition To | Metric, not Custom Data Point | The condition counts conversions. The data point identifies the person. |
| Condition | Total of Base Conversion Events, Greater Than, 1 | More than one conversion means they have bought before |
| Outcome Type | Substitution | The reduced rate replaces the normal payout, and repeats every time |
Common questions
Because the data point? is how Everflow knows which conversions belong to the same person. Once it knows that, counting their conversions is what tells you they are a repeat. Asking whether an email has been seen before is not something a condition can do, and there is no operator for it.
Yes. Any value that stays the same for one person works, such as a customer ID? from your own system, or a stable hash of the email. Do not use anything that changes between visits, like a session ID or an order number.
Same build, one change. Choose Bonus instead of Substitution and your amount is added on top of the normal payout rather than replacing it. Note that a bonus applies once per cycle, so on a Continuous cycle it pays once per customer rather than on every repeat purchase.
Yes, with a second rule on the same metric using a higher number. Build one rule for Greater Than 1 and another for Greater Than 4, and give them different outcomes.
→ Introduction To Customer Value — what a rule decides, and the five shapes people build.
→ How To Send User IDs & Data Points For Customer Value — the developer-facing setup, and how to prove the values arrived.
→ Paying On Net Gaming Revenue (NGR) With Customer Value — a monthly revenue share that carries a losing month forward.
→ Paying On Token & Credit Spend With Customer Value — the same machinery for an AI product, where the money arrives in token packs after the signup.
