Многомерный скоринг игроков
Два игрока вносят одинаковые суммы с одинаковой частотой – и по классическому RFM получают одинаково высокую оценку. Но один приносит казино прибыль, а второй вымывает деньги через выигрыши и выводы. RFM спрашивает только когда, как часто и сколько заплатили – по одной цифре на каждый вопрос. RFMVPS считает те же три вопроса иначе – по совокупности сигналов, а не по одной цифре, и добавляет ещё три измерения, которых RFM не видит вовсе.
Мы не просто добавили три новых оси (Velocity, Profitability и Security) к классическим Recency, Frequency и Monetary – каждая ось теперь составная оценка из нескольких сигналов, а не плоские метрики.
| Recency (Давность) |
|---|
Не просто дата последнего депозита. Совокупность всех финансовых активностей, с поправкой на игроков, ожидающих вывод.
| Frequency (Частота) |
|---|
Не число визитов в месяц. Регулярность активности, оцениваемая относительно профиля игрока: новичок, обычный или VIP.
| Monetary (Монетизация) |
|---|
Не сумма депозитов. Совокупный денежный вклад: сколько внёс, сколько принёс казино, какова была пиковая активность.
| Velocity (Скорость) |
|---|
В каком направлении движется игрок прямо сейчас? Растёт вовлечённость или затухает – раньше, чем это станет видно по депозитам.
| Profitability (Доходность) |
|---|
Зарабатывает ли казино на этом игроке, или наоборот – игрок вымывает деньги через выигрыши, выводы и реинвестицию.
| Security (Безопасность) |
|---|
Насколько игрок верифицирован и насколько его обороты завязаны на собственные деньги, а не на бонусы.
Velocity ловит замедление активности раньше, чем оно станет заметно по падению депозитов – когда ещё есть время на реактивацию, а не когда игрок уже ушёл.
Новый игрок с высоким первым депозитом не всегда попадает в фокус внимания, пока не накопит историю по объёму. Многомерная оценка ловит потенциал раньше, чем классический RFM успеет набрать достаточно данных.
Игрок, который выглядит ценным по одной лишь сумме депозитов, может оказаться убыточным или бонус-хантящим – без P и S это заметно только постфактум, когда деньги уже потрачены.
Вместо одного общего скоринга – разные сигналы для разных решений: кого удерживать, кого реактивировать, а на кого не тратить бонусный бюджет.
Матрица «сегмент → оффер» из отчёта превращается в постоянный контур: CRM подбирает и выдаёт персональный бонус по сегменту игрока сама, а не по разовому назначению в отчёте. Надстройка «Автоматизация персональных бонусных офферов» заказывается сверх пакета C – отдельным предложением после аудита.
На основе комбинации шести осей игроков можно группировать в стратегические сегменты – не универсальный список, а иллюстрация того, зачем нужен именно многомерный, а не одномерный скоринг. Пример логики: игрок с растущей Velocity и высокой Monetary – кандидат на ускоренный апгрейд в VIP. Игрок с падающей Recency, но исторически высокой Monetary – кандидат на срочную реактивацию, пока не потерян. Игрок с низким Security – кандидат на пересмотр бонусной политики, а не на новые предложения.
Конкретные категории, пороги и приоритет их назначения – часть нашей внутренней методологии оценки. На уровне C вы получаете полный RFMVPS по шести осям – расчёт на момент аудита, в отчёте. Живым контуром сегментация становится с надстройкой «RFMVPS (интеграция)»: регулярный пересчёт и атрибут в CRM, который маршрутизирует офферы и коммуникации в реальном времени. Надстройка заказывается сверх пакета C – отдельным предложением после аудита.
У игрока, который зарегистрировался несколько дней назад, по определению мало истории. Классический RFM оценивает Monetary по общей сумме и Frequency – по числу депозитов за период, поэтому у свежего аккаунта оба показателя низкие просто из-за возраста – не потому, что игрок неценный. Новичок с одним крупным депозитом выглядит так же, как случайный аккаунт, и остаётся незамеченным, пока не наберёт историю – а решающее окно для внимания к этому моменту уже может быть упущено.
Новичок, обычный игрок и VIP в RFMVPS оцениваются не по одной линейке – пороги и веса подстраиваются под профиль игрока. Для новичка ключевым сигналом становится не накопленный объём, а качество первого шага и то, как быстро он продолжает движение.
| Метрика | Обычный новый аккаунт | Этот игрок |
|---|---|---|
| R (Recency) | Недавно | Недавно |
| F (Frequency) | Низкая (мало истории) | Низкая (мало истории) |
| M (Monetary) | Низкая | Низкая |
RFM смотрит на общую сумму за период, а не на размер одного депозита – оба выглядят одинаково незначительными, даже если у этого игрока депозит крупнее.
| Ось | Обычный новый аккаунт | Этот игрок |
|---|---|---|
| R (Recency) | Недавно | Недавно |
| F (Frequency) | Низкая (мало истории) | Средняя (несколько депозитов) |
| M (Monetary) | Низкая | Средняя (первый депозит выше медианы) |
| V (Velocity) | Низкая (разовое действие) | Растущая (депозит сразу после первого – momentum уже виден на раннем этапе) |
| P (Profitability) | Нейтральная (мало истории) | Хорошая (положительный баланс для казино) |
| S (Security) | Низкая (мало истории) | Средняя (верификация пройдена без задержек) |
Ни объём, ни частота депозитов сами по себе не выделили бы этого игрока среди сотен обычных новичков – RFM увидел бы просто «ещё один новый аккаунт» и оставил бы его в общем потоке онбординга, пока он сам не наберёт историю – если вообще наберёт. Но размер первого депозита (M), ранняя динамика (V) и чистый сигнал безопасности (S) вместе поднимают его приоритет сразу – персональный контакт и усиленный онбординг происходят в первые дни, а не через месяц, когда игрок либо станет VIP сам, либо уйдёт к конкуренту.
Примеры «акула vs кит» и «недооценённый новичок» показывают две разные стороны одной и той же идеи: одна ось никогда не даёт полной картины. Там, где Monetary в одиночку либо переоценивает игрока (акула, которая выглядит как кит), либо недооценивает его (новичок без истории) – градация по жизненному циклу и совместная работа всех шести осей даёт решение, которое действительно отражает реальность игрока, а не только один срез его поведения.
На Level B – модуль B6 · VIP – агрегаты и грейды: грейды RFMVPS на агрегатах, без выхода на уровень игрока. На Level C – модуль C5 · Retention и churn: полный RFMVPS по всем шести осям. Сверх пакета C отдельно заказывается надстройка «RFMVPS (интеграция)» – живой атрибут в CRM с регулярным пересчётом вместо разового среза в отчёте модуля C5. Полный состав пакетов – в каталоге на Level Matrix.
Для расчёта всех шести осей нужны данные по каждому игроку на уровне отдельных операций, а не только итоговые суммы за период: даты и время каждого депозита и вывода, суммы депозитов и выводов по отдельным транзакциям, бонусная нагрузка – какая часть оборота образована промо-механиками, а не собственными деньгами, статусы верификации игрока и способа оплаты, история ставок и игровой активности между депозитами.
Для Level B – кумулятивная выгрузка по игроку и агрегаты за период, без склада и без персональных данных. Для Level C – read-only доступ к таблицам событий (платежи, ставки, бонусы, сессии) на истории, а не на агрегатах. Контакты игроков не нужны ни на одном уровне.
На Level B доступна только кумулятивная выгрузка по игроку – сколько и когда в сумме, без построчной истории событий, поэтому часть осей урезана: Recency считается только по дате депозита, без ставки и вывода – более точная формула с учётом ставок и выводов недоступна без истории событий. Frequency и Velocity недоступны на Level B – обе оси требуют видеть отдельные депозиты во времени, а не только их сумму за период. Monetary, Profitability и Security считаются на Level B полноценно, но на агрегатах периода, а не на истории событий, как на Level C. Level C (модуль C5) даёт полный RFMVPS по всем шести осям на истории транзакций и событий – там видно не только сколько и когда в сумме, а что происходило и в какой последовательности.
Надстройка сверх пакета C: разовый расчёт RFMVPS в отчёте модуля C5 превращается в живой атрибут в CRM с регулярным пересчётом, а не разовый срез на момент аудита. Так сегментация становится видима и используема оператором – маршрутизирует офферы и коммуникации в реальном времени.
Нет. Надстройки и интеграции, включая «RFMVPS (интеграция)», в базовую стоимость Level C не входят и заказываются отдельным предложением после аудита.
