Multidimensional player scoring
Two players deposit the same amounts at the same frequency - and under classic RFM they get the same high score. But one brings the casino profit, while the other drains money through wins and withdrawals. RFM only asks when, how often and how much was paid - a single number for each question. RFMVPS answers those same three questions differently - from a combination of signals rather than a single number - and adds three more dimensions that RFM does not see at all.
We did not just bolt three new axes (Velocity, Profitability and Security) onto the classic Recency, Frequency and Monetary - every axis is now a composite score built from several signals, not a flat metric.
| Recency |
|---|
Not just the date of the last deposit. The sum of all financial activity, adjusted for players awaiting a withdrawal.
| Frequency |
|---|
Not the number of visits per month. Regularity of activity, assessed against the player's profile: newcomer, regular or VIP.
| Monetary |
|---|
Not the deposit sum. Total monetary contribution: how much was deposited, how much it brought the casino, what the peak activity looked like.
| Velocity |
|---|
Which direction is the player moving right now? Is engagement growing or fading - before it becomes visible in deposits.
| Profitability |
|---|
Is the casino making money on this player, or is it the other way around - is the player draining money through wins, withdrawals and reinvestment.
| Security |
|---|
How well-verified is the player, and how much of their turnover rests on their own money rather than on bonuses.
Velocity catches a slowdown in activity before it becomes visible as a drop in deposits - while there is still time to reactivate, not after the player has already left.
A new player with a high first deposit does not always get attention until they build up a volume history. A multidimensional score catches the potential earlier, before classic RFM has had time to gather enough data.
A player who looks valuable from the deposit sum alone can turn out to be unprofitable or a bonus hunter - without P and S this is only visible after the fact, once the money has already been spent.
Instead of one overall score - different signals for different decisions: who to retain, who to reactivate, and who not to spend the bonus budget on.
The "segment → offer" matrix from the report turns into a standing loop: the CRM picks and issues the personal bonus by the player's segment on its own, not from a one-off assignment in the report. The "Automation of personal bonus offers" add-on is ordered on top of package C - as a separate proposal after the audit.
Based on a combination of the six axes, players can be grouped into strategic segments - not a universal list, but an illustration of why multidimensional scoring is needed instead of a one-dimensional one. An example of the logic: a player with rising Velocity and high Monetary is a candidate for an accelerated VIP upgrade. A player with falling Recency but historically high Monetary is a candidate for urgent reactivation, before they are lost. A player with low Security is a candidate for a bonus-policy review, not for new offers.
The specific categories, thresholds and how they are prioritized are part of our internal assessment methodology. At Level C you get the full RFMVPS across six axes - calculated as of the audit, in the report. Segmentation becomes a live loop with the "RFMVPS (integration)" add-on: a regular recalculation and an attribute in the CRM that routes offers and communications in real time. The add-on is ordered on top of package C - as a separate proposal after the audit.
A player who registered a few days ago by definition has little history. Classic RFM scores Monetary by total sum and Frequency by deposit count over the period, so a fresh account scores low on both purely because of its age - not because the player is low value. A newcomer with one large deposit looks the same as a random account and goes unnoticed until they build up history - and by then, the window for attention may already be missed.
A newcomer, a regular player and a VIP are not scored on RFMVPS with the same ruler - the thresholds and weights adapt to the player's profile. For a newcomer, the key signal is not accumulated volume but the quality of the first step and how quickly they keep moving.
| Metric | A typical new account | This player |
|---|---|---|
| R (Recency) | Recent | Recent |
| F (Frequency) | Low (little history) | Low (little history) |
| M (Monetary) | Low | Low |
RFM looks at the total sum over the period, not the size of a single deposit - both look equally insignificant, even though this player's deposit is larger.
| Axis | A typical new account | This player |
|---|---|---|
| R (Recency) | Recent | Recent |
| F (Frequency) | Low (little history) | Medium (several deposits) |
| M (Monetary) | Low | Medium (first deposit above median) |
| V (Velocity) | Low (a one-off action) | Rising (a deposit right after the first one - momentum is already visible at an early stage) |
| P (Profitability) | Neutral (little history) | Good (positive balance for the casino) |
| S (Security) | Low (little history) | Medium (verification passed with no delays) |
Neither the volume nor the frequency of deposits alone would have singled this player out among hundreds of ordinary newcomers - RFM would simply see "another new account" and leave them in the general onboarding flow until they build up history on their own, if they ever do. But the size of the first deposit (M), the early dynamics (V) and a clean security signal (S) together raise their priority right away - personal contact and reinforced onboarding happen in the first few days, not a month later, by which point the player has either become a VIP on their own or gone to a competitor.
The "shark vs whale" and "underrated newcomer" examples show two different sides of the same idea: a single axis never gives the full picture. Where Monetary alone either overestimates a player (a shark that looks like a whale) or underestimates one (a newcomer with no history) - lifecycle grading and all six axes working together give a decision that actually reflects the player's reality, not just one slice of their behavior.
At Level B - module B6 · VIP - aggregates and grades: RFMVPS grades on aggregates, without going down to the player level. At Level C - module C5 · Retention and churn: the full RFMVPS across all six axes. On top of package C, the "RFMVPS (integration)" add-on is ordered separately - a live CRM attribute with regular recalculation instead of a one-off snapshot in the C5 module's report. The full package composition is in the catalog on the Level Matrix page.
Calculating all six axes needs per-player data at the level of individual operations, not just period totals: the date and time of every deposit and withdrawal, deposit and withdrawal sums by individual transaction, the bonus load - what share of turnover is built from promo mechanics rather than the player's own money, verification status for the player and the payment method, and betting and play-activity history between deposits.
For Level B - the per-player cumulative export and period aggregates, with no warehouse and no personal data. For Level C - read-only access to event tables (payments, bets, bonuses, sessions) on history, not on aggregates. Player contacts are not needed at any level.
At Level B, only the per-player cumulative export is available - how much and when, in total, with no row-level event history, so some axes are cut down: Recency is calculated only by deposit date, without bets and withdrawals - the more precise formula accounting for bets and withdrawals is not available without event history. Frequency and Velocity are not available at Level B - both axes need to see individual deposits over time, not just their sum for the period. Monetary, Profitability and Security are calculated in full at Level B, but on period aggregates rather than on event history as at Level C. Level C (module C5) gives the full RFMVPS across all six axes on transaction and event history - there you see not just how much and when in total, but what happened and in what sequence.
An add-on on top of package C: the one-off RFMVPS calculation in the C5 module's report turns into a live CRM attribute with regular recalculation, rather than a one-off snapshot as of the audit. This is how segmentation becomes visible and usable by the operator - routing offers and communications in real time.
No. Add-ons and integrations, including "RFMVPS (integration)", are not included in the base price of Level C and are ordered as a separate proposal after the audit.
