Ask a CRM team how a campaign performed and the answer is usually a send count. "We issued 2,400 offers." That is an activity number wearing the costume of a result. The two figures that answer the question — what the campaign cost and what came back — almost always live in different systems.
Send counts are not reported because anybody believes they are the point. They are the only figure the campaign tool can produce on its own. The CRM issues the offer, the wallet grants it, the payment stack records the deposit, and the warehouse sees three unrelated rows. Joining them per offer is a project nobody has scoped, so the number that survives into the weekly deck is the one that needed no join. The cost of that is not the missing figure — it is that a campaign which loses money looks identical to one that makes money, for as long as both are measured in sends.
A deposit needs a boundary, or every deposit a player ever makes is available as evidence for whichever campaign claims it first. How long after an offer a deposit is plausibly that offer working is a commercial judgement, and it belongs in configuration where somebody can see it and argue with it — a window that lives inside a query gets widened quietly when results are thin.
Keeping the expected cost beside the actual one makes the comparison free, and recording whether that expectation came from a real history or from an assumption stops a guess becoming a planning input.
In Ludora an award is created when the offer is issued, carrying no cost. The casino's grant event is matched back to it and charged against it; a deposit inside the window is credited to the same record, with how long it took. Reporting is then arithmetic rather than inference: a campaign sums its own awards and reports a net, an average time to convert, and the share of offers that were issued and never granted.
Because it measures what the CRM did, not what happened afterwards. Two campaigns with identical send counts can differ completely in what they cost and what they brought back. The send count survives into reports because it is the only figure the campaign tool can produce without joining data from the wallet and the payment stack.
No, and it is the most common substitution. Offers go untaken and wallets refuse grants, so the face value of what was offered overstates the spend. The cost is what the casino actually credited, which means it has to arrive as a grant event from the casino and be attached to the offer that caused it. Until that event arrives the honest value is nothing, not an estimate.
That is a commercial judgement, not a technical constant — a few days is defensible for a reload, and five weeks almost certainly belongs to something else. What matters more than the exact number is that it is written down in configuration where somebody can see it and disagree with it. A window that lives inside a query tends to get widened quietly when results are thin.
They should be left alone. Operators grant bonuses constantly for reasons that have nothing to do with CRM — support goodwill, VIP gestures, compensation for an outage — and a system that attributes every grant it sees to the nearest campaign is flattering its own numbers. A grant with no offer behind it is ordinary rather than an error.
Because otherwise nobody ever finds out which forecasts were any good. Storing both on the same record makes the comparison free, and recording whether the forecast came from a real history or from an assumption keeps a guess from quietly becoming a planning input. A forecast labelled as an assumption is fine; one that used to be an assumption and is no longer labelled is not.