How casinos rate players' lifetime value (LTV)

LTV is the present value of the future margin by player or cohort minus bonuses, commissions and taxes. In gambling products, accuracy is particularly important: high bet variances, instant cashouts, cookie-less attributions, and RG requirements make "simple averages" dangerous. Below is a practical scheme where each quantity is defined and the model is transparent to product, finance and compliance.

1) Definitions and boundaries of LTV

Income base:

GGR (Gross Gaming Revenue) = Bets − Payouts.
NGR (Net Gaming Revenue) = GGR − bonuses − provider royalties/aggregation − game taxes (if held at sales/revenue level).

Player Contribution Margin:


PC = NGR
− payment fees
− chargeback/loss (expected)
− support/cost-per-case (expected)

LTV (post-tax, post-fee):


LTV = Σt [ E(PC_t) × Survival_t × Discount_t ]

Where 'Survival _ t' is the probability that the player is active in period t; 'Discount _ t' is the discount factor (cost of capital/inflation).

💡 Important: CAC (cost of attraction) is NOT included in LTV, but compared separately (LTV: CAC).

2) What data is needed (event diagram)

Минимум: `signup`, `kyc_step`, `deposit`, `withdrawal`, `bet_place`, `bet_settle`, `bonus_grant/consume`, `chargeback`, `rg_limit_set`, `self_exclude`.

Reconciliation journals are required: game ↔ cash desk ↔ payments ↔ bank.

Attributes: jurisdiction, channel, device, payment method, risk segment, tax rate on GGR/NGR.

3) How to get "fair" margins from GGR

1. Cancel bonuses and promos (including cashback/missions).

2. Consider provider shares (RGS/aggregator).

3. Apply game taxes (GGR/NGR - by jurisdiction).

4. Subtract payment fees (by method) and expected chargeback.

5. Normalize returns/cancellations (retro corrections in the same period).

6. Divide by channel contribution (if you count LTV by source).

Total - The expected PC_t by period (weeks/months).

4) Approaches to holding forecast (Survival)

A) Cohort deterministic (simple and transparent)

We construct a retention curve by cohorts: 'D7, D30, M2... M12'.

Extrapolate the "tail" (for example, hyperbola/exponent).

Pros: explainable to business. Cons: Rough on an individual level.

B) Survival (Discrete-Time Hazard)

Risk of leaving model by intervals (logit/log-log).

Features: frequency/deposit amounts, live/prematch, fraud rate, RG signals, cashout speed.

Gives' Survival _ t'to the player/segment, easily aggregated.

C) Behavioral patterns of frequency/repeat purchases

BG/NBD, Pareto/NBD to predict the number of active periods/bets.

Combine Recency, Frequency, Monetary and give the tail distribution.

They fit well on CRM/missions (next-best-action).

💡 Practice: Start with cohorts + hazard for control, then add BG/NBD to segments.

5) Discounting and value of money

The discount reflects the cost of capital and forecast risk:


Discount_t = 1 / (1 + r)^t

Where'r 'is the monthly/quarterly rate (in iGaming often 0.5-1.5% per month nominally). For high-risk cohorts, use an increased'r 'or a penalty to Survival.

6) Calculation example (simplified, 6 months)

Dano (1,000 player cohort):

Average NGR1 in M1 = 10 cu/player; 15% monthly M2-M6 reduction.
Payment commissions = 3% of deposits; in simplification, let's take 2% of NGR.
Chargeback expected = 0,4% от NGR.
Retention (activity): M1 = 100%, M2 = 55%, M3 = 40%, M4 = 32%, M5 = 27%, M6 = 24%.
Discount r = 1 %/month

Steps:

1. `PC_t = NGR_t × (1 − 0,02 − 0,004) = NGR_t × 0,976`.

2. 'NGR _ t' = '10 × 0.85 ^ (t − 1)' (15% reduction).

3. `LTV = Σ_{t=1..6} PC_t × Retention_t × Discount_t`.

Let's calculate M1 and M2 (the rest according to the template):

M1: `PC_1 = 10 × 0,976 = 9,76`; contribution = '9.76 × 1.00 × 0.990 ≈ 9.66'.
M2: `NGR_2 = 8,5`; `PC_2 = 8,5 × 0,976 = 8,30`; contribution = '8.30 × 0.55 × 0.981 ≈ 4.48'.
Summing up the M1-M6, get a landmark ~ 24-27 cu. LTV per player in this cohort (depending on rounding).

💡 Top compare with CAC and target LTV: CAC ratio (often 3:1 for sustained growth).

7) LTV by channel and jurisdiction

Divide LTV into post-tax and pre-tax layers: compare channels within the same tax logic.

Consider payment methods: where the share of instant rails and deposit success is higher, LTV is usually higher, all other things being equal.

Include RG events: default limits and quick self-exclusion reduce peak revenue, but improve tail and complaints/1k - LTV becomes more stable.

8) Frequent mistakes and how to avoid them

1. GGR/NGR confusion. First, deduct bonuses/royalties/taxes on the game, then payment commissions.

2. Ignore fraud/chargeback. Use probability-weighted losses.

3. Medium without segments. The behavior of new vs returning, low-risk vs high-risk is different.

4. There are no reconciliation journals. Without journaling, part of the NGR will "leak" or overestimate the PC.

5. Extrapolation too smooth. An admixture of seasonality/tournaments breaks a simple exponent.

6. Compare different bases (post-tax LTV with pre-tax CAC). Bring to one base.

7. Do not consider the cashout rate. It correlates with returns and LTV tail.

9) Security metrics near LTV

Complaints/1k sessions (target ~ 0.6-1.2).

Time to 1st cashout (~ 6-24 hours with KYC passed).

% of approved first conclusions (~ 85-93%).

Deposit success (≥92 -97%).

Share of players with active RG limits and RG ticket response rate.

10) Experiments and causality

Any A/B affecting LTV (missions, margin, payment front), accompany with security metrics: complaints/1k, payout_speed, RG signals.

For channels, use instrumental variables or differences-in-differences if there is a self-selection.

Record the "snapshot date" of the data: LTV forecasts are sensitive to revisions.

11) LTV dashboard structure (gold showcase)

1. Cohort map (signup-month × jurisdiction × channel).

2. Survival curve and PC contribution by month (stacked).

3. LTV by segment (device, risk-tier, payment-mix).

4. LTV: CAC and payback period in weeks/months.

5. Security: complaints/1k, payout SLA, RG activation.

12) Implementation checklist (0-90 days)

Define base: post-tax NGR → PC.
Enable chargeback expected and payment feeds on PC.
Set up journals and reconciliations (game ↔ cash desk ↔ payments ↔ bank).
Build cohorts and simple hazard by retention.
Launch the LTV by cohort/channel/jurisdiction showcase.
Enter discount policy and "snapshot date."
Add security metrics to each LTV report.

13) Mini-FAQ

LTV count before or after taxes/fees?

For management - after (post-tax, post-fee). For external benchmarks, pre-tax can also be stored.

What horizon to take?

More often 12-18 months; "long tail" discount and validate fact.

What about self-excluded players?

They cover the tail of Survival for the date of the event; Consider the impact of RG nujas as a positive risk control.

BG/NBD or cohorts?

Cohorts for transparency, BG/NBD for CRM and fine personalization. Coexist.

The exact LTV in a casino is not a "GGR × factor" formula. This is the discipline: the correct base (post-tax NGR), the expected cost of payments/fraud, the retention model, discount and security metrics nearby. Such LTV not only "looks beautiful on the slide," but also allows you to make decisions: how much to pay for traffic, where to speed up cashout, which missions pay off and in which segments you need to strengthen RG.