How to analyze LTV and cohort in iGaming
1) Why cohort analysis in iGaming
iGaming is a "long" vertical: players pay not one-time, but a series of deposits. The cohort approach answers two main questions:1. whether the purchase paid off (when and due to what), 2. what is the future tail of revenue (how much more will we earn on this cohort).
Without cohorts, you confuse seasonality, bonuses and shock effects with the real quality of traffic.
2) Basic definitions (on one sheet)
Cohort - a group of users grouped by key event date (often: click/reg/FTD).
GGR (Gross Gaming Revenue) - bets − wins.
NGR (Net Gaming Revenue) - GGR minus bonuses/jackpots/commissions of game/payment providers, gaming duty, chargeback/refund.
ARPU_Dn - average revenue per player by day n (usually by NGR).
Cum_ARPU_Dn = cumulative ARPU at day n.
LTV - discounted total revenue per player over horizon T (or infinite).
Payback - the minimum n at which the CAC/CPA Cum_ARPU_Dn ≥.
Retention_Dn - the proportion of the cohort active on day n (login/rate/deposit).
2nd-dep rate - the proportion of FTD players who made a second deposit for the period.
3) Where to cut off "day zero": choice of cohort axis
Click cohort - need media optimization and attribution.
Reg cohort - need product/CRM for activation and KYC.
FTD cohort (recommended for P & L/ROI) - more accurately links CAC and money tail.
You can keep all three, but make financial decisions on the FTD cohort.
4) Data model: what events and amounts to store
Events (minimum): 'registration', 'kyc _ approved', 'deposit _ success {amount, currency, is _ ftd}', 'withdrawal', 'refund', 'chargeback', game events for GGR (if available).
Атрибуты: `click_id`, `utm_`, `geo`, `device/os`, `payment_method`, `brand`, `offer`.
Time: store in UTC; in the windows of reports - the locale of the project.
Money: keep in the transaction currency and in the "report currency" (at the exchange rate on the date of the event).
NGR by day t:
NGR_t = GGR_t
− BonusCost_t
− ProviderFee_t
− PaymentFee_t
− GamingDuty_t
− Chargeback_t
5) Main cohort metrics
5. 1. Monetization
ARPU_Dn = (Σ NGR[0..n]) / FTD
ARPPU_Dn = (Σ NGR[0..n]) / ActivePayers_Dn
Deposit per Payer_Dn, Avg_Deposit_Size_Dn - useful for VIP slices.
5. 2. Behavior/Quality
Retention_D1/D7/D30/D90 (login/rate/dep)
2nd-dep rate, 3rd-dep rate
Cashout rate, Chargeback rate- KYC pass-rate, FTD lag (рег→FTD)
5. 3. Purchasing economics
CPA (or CAC) = Spend/FTD- Payback - the day the CPA Cum_ARPU ≥
- ROAS_Dn = (Σ NGR[0..n]) / Spend; ROI_Dn = (Σ NGR − Spend − Direct Opex) / Spend
6) Showcases and reports: what to build in BI
Actual tables:- `fact_events` (event-level: user, ts, type, amount, currency)
- 'fact _ spend '(channel/day/geo/creative)
- 'fx _ rates' (courses)
- `dim_user`, `dim_utm`, `dim_geo`, `dim_device`, `dim_brand/offer`
1. cohort_ftd_daily — FTD-когорты: `cohort_date`, `users_ftd`, `NGR_d`, `deposits_d`, `retention_d`, `2nd_dep_d`.
2. cohort_cum - cumulative metrics on day n: 'cum _ ARPU _ Dn', 'cum _ ROAS _ Dn', 'payback _ day'.
3. channel_cohort — связка с UTM: `source/medium/campaign/content`.
Heat maps: Cum_ARPU by rows (cohorts) and columns (day 1.. 90).
7) Formulas and mini-example
Baseline (monthly X-channel, FTD-cohort D0):- FTD = 1 000; Spend = 50 000; к D30: ΣNGR = 94 200.
CPA = 50 000 / 1 000 = 50
ARPU_D30 = 94 200 / 1 000 = 94. 2
Cum_ARPU_D30 ≥ CPA? Yes → payback achieved earlier.
Payback rough score: Average day. ARPU ≈ 94. 2 / 30 = 3. 14 → 50 / 3. 14 ≈ D16
(more precisely, according to the cumulative ARPU curve day-by-day).
2nd-dep rate_D30 = 32% (for example) - signal of quality and future tail.
8) LTV forecast: How to rate the long tail
8. 1. Simple extrapolation (operating)
Plot the daily ARPU contribution after D30 (D31..D120) on historical cohorts of similar geo/sources/brands.
Apply the tail multiplier: 'LTV _ D120 ≈ Cum_ARPU_D30 × k', where 'k' is from history (for example, 1. 35 for a specific geo/product).
8. 2. Parametric models (when there is a lot of data)
BG/NBD (repeated "purchases" = deposits) → frequency forecast.
Gamma-Gamma (monetary amount) → the forecast of the average size of the deposit/NGR on the active payer.
Mixed models with VIP/mass segmentation (log-normal/gamma by amounts).
8. 3. Discounting
'LTV = Σ_{t=0..T} (NGR_t/ Users_FTD )/( 1 + r) ^ {t/30} ', where r is the monthly rate (1-2 %/month for the plan file).
9) Segments that 'make the weather'
GEO (taxes/payments/currency)- Device/OS (iOS vs Android)
- Payment methods (fee and permitted amounts)
- Creative/angle/land (different expectations → different depth)
VIP layers (for example, NGR P95/P99) - keep them separate: they "pull" the tail and make noise in the middle.
10) Quality diagnostics by cohort
Normally high CR (click→reg) but weak CR (reg→FTD) → onboarding/payments problem.
High FTD, but 2nd-dep rate low → bonus hunters, weak retention.
A good Cum_ARPU_D7, beyond the plateau → there is no CRM mechanic (missions, promotions, segmented offers).
Chargeback/refund surge → anti-fraud/payment sources, gray channels.
11) Common mistakes (and how to avoid)
1. Read by GGR → systemically overestimate ARPU/LTV. → Always by NGR.
2. Mixing timezones/currencies → float D0/D1/Payback. → Keep UTC + report currency.
3. Cohort by click for P&L → noisy attribution. → For money, use FTD.
4. Solutions on small samples → mask variance. → Enter thresholds (≥30 -50 reg or ≥300 -500 clicks/bundle; for LTV - ≥200 FTD/slice).
5. Without chargeback/refund → an inflated tail. → Include "negative" events.
6. Average hospital temperature → hiding VIP/creative effects. → Segment.
7. Ignore 2nd-dep → validate cohort quality prior to rate/cap increase.
12) Mini-guide to visualizations
Heatmap Cum_ARPU (cohort × days) - you can see the tilt of the tail.
Retention curves D1..D90 - by logins and by deposits (two curves).
Водопад NGR: GGR → −Bonus → −ProviderFee → −PaymentFee → −Duty → −Chargeback.
Payback points along the channels are the "break-even CPA" line.
VIP Pareto - 20/80 (or 10/90): NGR's share of the top x% of players.
13) Data quality control
Server-side event (deposits/outputs), idempotency by 'event _ id'.
Alerts: delay of postbacks> 15 min, break "operator↔DWH," share of events without 'click _ id'.
Reconciliation of amounts (NGR) between sources once a week; log of "rejected/corrected" events.
14) Cohort LTV implementation checklist
Data and events
- S2S chain: 'reg/KYC/FTD/2nd _ dep/refund/chargeback' (UTC, currency)
- NGR formula agreed (what exactly is/is not included)
- Currencies are converted by event date; "report currency" is stored
- Витрины `cohort_ftd_daily`, `cohort_cum`, `channel_cohort`
Metrics and Reports
- Cum_ARPU D1/D7/D30/D90, Retention, 2nd-dep rate
- Payback by cohort vs CPA; ROAS/ROI
- VIP slices (P95/P99), payment methods, device/geo
Processes
- Statistics threshold and rules for disabling/indexing rates
- Retro Weekly: Top/Anti-Bundle, Insider Transfer
- operator↔DWH Reconciliation, Incident Log
15) 30-60-90 plan
0-30 days - Frame and hygiene
Describe the NGR formula, include S2S on key events.
Collect baseline cohort showcases (FTD axis) and Cum_ARPU D1/D7/D30.
Set up delay/variance alerts; provide currencies/TZ.
31-60 days - Depth and quality
Add 2nd-dep, Retention, chargeback/refund to reports.
Introduce Payback threshold and rules for indexing cohort quality rates.
Segmentation: geo/device/payment/VIP; creative/land report.
61-90 days - Forecast and management
BG/NBD + Gamma-Gamma pilot or historical tail ratio.
Plan-actual for LTV and Payback; CPA/bonus bone what-if scenarios.
Standardization of playbooks: launches, reconciliations, escalation of anomalies.
16) The bottom line
Cohort analysis and LTV in iGaming is a system: correct axis (better than FTD), fair NGR revenue, event and currency discipline/timezone, cumulative curves and quality control (2nd-dep, Retention, chargeback). Add tail forecast (models or historical ratios), statistical thresholds and rate indexation processes - and budget decisions become fast, reproducible and profitable.