CRM-стек казино: сегментація, кампанії, персоналізація

Повний текст статті

💡 18+. Матеріал для платформ/операторів і маркетингових/аналітичних команд iGaming. Не заклик до гри. Всі приклади - про корпоративну архітектуру та безпечну комунікацію з користувачами.

1) Цілі CRM в iGaming

Зростання LTV і утримання: вчасно повернути гравця відповідним каналом і оффером.

Зниження вартості комунікацій: розумний вибір каналу/часу/частоти.

Типовий комплаєнс: RG/AML/opt-in, вікові/гео-обмеження, заборони на промо для вразливих груп.

Прозора атрибуція: розуміти, що реально працює.

2) Референс-архітектура CRM-стека


Events (PAM/Wallet/RGS/Payments/Web/App)
│
├─CDP (Identity + Profiles + Consent) ──Feature Store (real-time + batch)
│         │
│         ├─Segmentation Service (rules, SQL, ML lists)
│         └─Orchestrator (Journeys/Triggers/Limits)
│                  │
│                  ├─Channels: Push / Email / SMS / On-site / In-app / Call
│                  └─Offers Engine (bonuses, missions, jackpots)
└─BI/DWH (attribution, uplift, experiments)

Ключові елементи:

CDP (Customer Data Platform) з профілем гравця і дозволами (consent).
Orchestrator сценаріїв/кампаній з частотними лімітами і RG-правилами.
Feature Store для онлайнових/батч-ознак (RTP-схильність, улюблені провайдери, ризик).
Offers Engine - генерація і виконання офферів (правила + ML).
Канали з єдиними контрактами і зворотним зв'язком (delivery/open/click/reply/spam).

3) Подієва модель і профіль гравця

3. 1 Базові події

`session. started/ended`

`bet. placed/settled` (stake/win/in_bonus/provider/game)
`wallet. debit/credit` (reason, latency)

`payment. intent	authorized	captured	refund	withdraw`
`bonus. issued	consumed	expired`
`rg. limit. hit	reality_check`
`crm. delivery	open	click	unsubscribe	complaint`

3. 2 Профіль (фрагмент)

json
{
"player_id":"p_123",  "brand_id":"A",  "region":"EU",  "locale":"de-DE",  "rg_status":{"self_excluded":false,"limits":{"loss_daily":100}},  "consents":{"email":true,"push":true,"sms":false,"profiling":true},  "features":{
"tenure_days":186,   "dep_count_30d":3,   "churn_score":0. 62,   "fav_providers":["studio_x","live_y"]
},  "last_seen_at":"2025-10-22T21:10:00Z"
}

Правила: всі PII - токенізувати; зберігати ознаку згоди і дату зміни. Будь-яке спілкування - тільки при діючому opt-in.

4) Сегментація: правила + ML

4. 1 Правила (rule-based)

SQL/візуальні конструктори: «DE + dep_count_30d=0 + last_seen>7d + consent. email».

Довідники сегментів (VIP, новачки, high-value, dormant).

Оновлення: real-time (стрім) для критичних тригерів, batch (5-60 хв) для широких кампаній.

4. 2 ML-списки

Churn propensity, Next Best Action/Game, Deposit intent, Offer sensitivity.

Навчання в DWH, скоринг в Feature Store; пояснюваність: топ-ознаки, довіра.

5) Оффери та персоналізація

5. 1 Типи офферів

Бонуси (депозитний/кешбек/free spins), місії/квести, турніри, джекпот-призи, персональні рекомендації ігор/категорій.

5. 2 Правила сумісності

RG: виключити самовиключених/лімітних; вік/ліцензія/регіон.

Економіка: max cost per player/day, вейджер/макс-ставка, блок конфліктів.

Анти-спам: частота per канал і per player.

5. 3 Генерація оффера (приклад API)


POST /v1/offers/generate
{
"player_id":"p_123",  "context":{"intent":"reengage","channel":"email"},  "constraints":{"max_cost_minor":500,"rg_safe":true}
}
→ 200 {
"offer_id":"of_777",  "template":"bonus_cashback",  "params":{"percent":10,"cap_minor":2000,"wagerx":15},  "expires_at":"2025-10-24T21:00:00Z"
}

6) Оркестрація кампаній і тригерів

6. 1 Тригери (real-time)

`bet. settled'з нетривіальним програшем → «втішний» кешбек (якщо RG дозволяє).

`payment. failed'( 3-DS/AVS) → підказка/альтернативний PSP.

`churn_score>0. 7 & last_seen>14d' → ланцюжок re-engage (push→email).

6. 2 Джорні (journeys)

Граф станів: enter → wait → check → send → evaluate → next step.

Умови входу/виходу, дедуп по гравцеві, cooldown між кроками, автоматичний opt-out при відписці/скарзі.

6. 3 Частотні ліміти та пріоритети

Per channel/day/week, глобальний «message cap», пріоритет VIP/інцидентних повідомлень.

«Four-eyes» на чутливі кампанії (ручне затвердження офферів високого номіналу).

7) Канали і доставка

Канал	Коли використовувати	Особливості
Push	швидкий тригер, мобайл-очікування	тихий годинник, deep-link, пермішені
Email	складні оффери/контент	DMARC/SPF/DKIM, прогрів, сегрегація IP
SMS	критично швидко	дорого, коротко, юридичні обмеження
In-app/On-site	контекст в продукті	контентні рекомендації, персональні банери
Call/Support	VIP/ризикові кейси	журнал розмов та ліміти

Deliverability: домени, репутація IP, прогрів, спам-тригери; трекінг'delivery/open/click/unsubscribe/complaint'.

8) Персоналізація контенту та рекомендацій

Правила + ML-гібрид: спочатку фільтри за ліцензією/провайдеру, потім ранжування ML (history-based + popularity/novelty).

Контекст: пристрій/час/гео/категорія.

Guardrails: виключати «небезпечні» для RG патерни (тривалі сесії/високі ставки), обмеження за бонусними обмеженнями.

Шаблони: багатомовний контент (BCP-47), плейсхолдери для змінних оффера, A/B-варіанти.

9) Експерименти та атрибуція

A/B/n з поділом на рівні профілю (persistent bucketing).

Uplift-моделювання: таргетуємо тих, у кого очікуємо приріст від контакту (а не всіх).

Атрибуція: last-touch + позиційні моделі; для тригерів - «побачив/відкрив/клікнув → дію (депозит/повернення/залучення)».

Guardrails: не погіршити RG-показники (зростання спрацьовувань лімітів, скарг).

10) Метрики та SLO CRM

Доставка: delivery rate, open/click, complaint/unsubscribe.

Бізнес: uplift депозитів/реактивацій, ARPU uplift, churn-down, ROI кампаній, cost per engaged.

Операції: час генерації оффера, p95 «sobytiye→otpravka», черга повідомлень, ретраї.

RG/Комплаенс: % блокованих по RG, частка контактів з уразливими, скарги.

Цілі SLO (орієнтири):

real-time тригер «sobytiye→dostavka» p95 ≤ 30-90 с;
batch кампанії до 15 хв;
complaint rate < 0. 1%, unsubscribe <1% по розсилці.

11) Безпека, приватність, згоди

Consents версіонуються; для кожної комунікації логуємо «на якій підставі відправили».

PII-ізоляція: токени/псевдо-ID в CRM, прямі контакти - в захищених сховищах каналів.

RLS/ABAC: доступ по бренду/регіону/ролі (support/marketing/analytics).

WORM-аудит: зміни сегментів, правил, офферів, масових розсилок.

Витіснення по регіону (data residency), «право на забуття».

12) Інтеграційні контракти (фрагменти)

Подія для тригера


POST /v1/events
{
"event_type":"payment. failed",  "trace_id":"tr_a1b2",  "player_id":"p_123",  "payload":{"psp":"X","reason_code":"3DS_TIMEOUT"},  "occurred_at":"2025-10-23T11:21:05Z"
}

Відправка повідомлення (абстрактний канал)


POST /v1/messaging/send
Headers: X-Idempotency-Key: msg_001
{
"channel":"email",  "player_id":"p_123",  "template_id":"tpl_reengage_01",  "personalization":{"first_name":"Alex","offer_id":"of_777"},  "frequency_policy_id":"fp_default"
}
→ 202 {"delivery_id":"dlv_9k","status":"QUEUED"}

Feedback з каналу


POST /v1/messaging/feedback
{
"delivery_id":"dlv_9k",  "event":"open    click    bounce    complaint    unsubscribe",  "occurred_at":"2025-10-23T11:22:05Z"
}

13) Операційна гігієна

Календар кампаній: чорні вікна (матчі, релізи, рег-періоди), «тихі години».

Контент-рев'ю: орфографія, юридичний дисклеймер, відповідність бренду та ліцензії.

Дедуп: не надсилати два повідомлення про ту ж подію протягом X хвилин.

Back-pressure: обмежувати пікові розсилки, прогрів доменів, пріоритизація транзакційних повідомлень.

14) Чек-листи

Архітектура та дані

Єдина CDP, профілі, consents, RG-статуси.
Стрім подій і batch воронки; Feature Store real-time + batch.
Outbox/CDC, ідемпотентна відправка і feedback-петля.
RLS/ABAC, PII-ізоляція, WORM-аудит.

Сегментація та офери

Набір «скелетних» сегментів + ML-листи.
Політики сумісності (RG, економіка, ліцензії).
Частотні ліміти per канал і глобально.

Оркестрація та канали

Джорні з cooldown і авто-виходом за відпискою/скаргою.
Канальний моніторинг deliverability, репутація доменів/IP.
Трекінг deep-link і конверсії до гаманця/ставки.

Експерименти/вимірювання

A/B/n + uplift; guardrails RG.
Атрибуція і ROI, звіт по витратах (канал/PSP/локаль).

15) Червоні прапори (анти-патерни)

Масові розсилки без частотних лімітів і RG-фільтрів.

Кампанії на гравців без opt-in або з простроченою згодою.

Персоналізація, що використовує PII у відкритому тексті без необхідності.

Відсутність feedback-петлі: немає даних про доставку/скарги.

«Жорстко прошиті» правила без A/B і телеметрії.

Відправка бонусів без контролю економіки (cap, бюджет, конфлікт правил).

Зберігання контактних даних в логах/дашбордах.

16) Підсумок

Сильний CRM-стек в iGaming - це не тільки «розсилка листів». Це подієва платформа з єдиним профілем, згодою і RG-обмеженнями; розумною сегментацією і генерацією офферів; оркестратором джорні з частотними лімітами і зворотним зв'язком каналів; і вимірюванням uplift/ROI замість «відкриттів заради відкриттів». Так ви підвищуєте LTV і утримання, знижуєте вартість контакту, дотримуєтеся комплаєнс - і робите комунікації доречними, своєчасними і безпечними.