Oyunçuların tutulması təhlili
Oyunçuların tutulmasının təhlili
Saxlama məhsul iqtisadiyyatının özüdür: oyunçu nə qədər uzun müddət aktiv qalırsa, LTV bir o qədər yüksəkdir, gəlir və proqnozlaşdırıla bilən planlaşdırma bir o qədər sabitdir. Aşağıda - tam çərçivə: düzgün təriflərdən sağ qalma modellərinə və re-aktivasiya konturuna qədər.
1) Müəyyən və uçot vahidi
Vahid: oyunçu (user/master_id) - default; qısamüddətli tapşırıqlar üçün «hesab/cihaz» deyək, lakin bunu metrika pasportunda qeyd edin.
Aktivlik: geri dönüş meyarı (≥ 1 seans/ ≥ 1 dərəcə/ ≥ 1 depozit) - qeyd edin.
Retenshn Dn: referent tarixindən sonra n-ci gündə geri qayıdan kohortanın payı.
Rolling/Bracket: Rolling D7 (hər hansı bir gün 1-7) vs Exact D7 (dəqiq 7-ci gün).
Churn (axın): aktivliyin olmaması ≥ T gün (məsələn, 14/30); məhsul bir qayda kimi verilir.
Kohortlar: qeydiyyat/ilk depozit/ilk oyun tarixinə görə - marketinq/məhsul vəzifəsini seçin.
2) Əsas analitika: kohortlar və retention əyriləri
Kohort istilik kartları: D1/D3/D7/D14/D30/D60; diaqonallar buraxılışlar və kampaniyalar arasında müqayisə edilə bilər.
Sağ qalma əyriləri: 0 gündən N-ə qədər aktiv olanlar (survival curve).
Əyrinin həndəsi: bayramların/buraxılışların «pillələri»; erkən «çöküş» → onbording problemləri, «uzun quyruq» → sadiq nüvəsi.
Psevdo-SQL: kohort D7
sql
WITH regs AS (
SELECT user_id, DATE_TRUNC('day', ts) AS cohort_day
FROM event_register
),
act AS (
SELECT user_id, DATE_TRUNC('day', ts) AS act_day
FROM event_activity
),
d7 AS (
SELECT r. cohort_day,
COUNT(DISTINCT r. user_id) AS cohort_size,
COUNT(DISTINCT CASE WHEN a. act_day = r. cohort_day + INTERVAL '7 day'
THEN r. user_id END) AS retained_d7
FROM regs r
LEFT JOIN act a ON a. user_id = r. user_id
GROUP BY 1
)
SELECT cohort_day, cohort_size,
retained_d7::decimal / NULLIF(cohort_size,0) AS cr_d7
FROM d7
ORDER BY cohort_day;3) Survival və hazard modelləri
Kaplan-Meier: qeyri-modelləşdirilmiş survival (S (t)); həyatın əyrisi və medianı üçün faydalıdır.
Cox PH/Accelerated Failure Time: xarakter təsiri üçün izah edilə bilən modellər (ölkə, kanal, platforma, bonuslar, məzmun).
Discrete-time hazard (gündəlik logit): qida analitikası və təqvim xüsusiyyətləri üçün çevikdir.
«Re-aktivasiya» hadisəsi: ayrıca (competing risks) və ya Markov zəncirinə keçid kimi modelləşdirin.
4) Markov və yarı Markov modelləri
States: New → Active → Dormant → Churned → Reactivated.
Keçid: bir dövr üçün ehtimal (gün/həftə).
Dəyər: "Active 'də qalma ehtimallarını orta çek/tezliyə qədər çoxaltın - LTV-yə gözlənilən töhfəni alın.
5) Tutma bağlama və LTV
LTV ( endirim).
Elastiklik: X pp D7 artımı → Y% LTV artımı (tarixi data/modellər).
Prioritetləşdirmə: erkən saxlanmaya təsir edən təkmilləşdirmələr (D1-D7) demək olar ki, həmişə ən gəlirlidir.
6) Saxlama seqmentasiyası
Cogorts: ilk məzmun/oyun kateqoriyası/gündəlik davranış şablonu 0.
Geo/platforma/kanal: UX və gözləntilər fərqləri; təqvim/bayram düzəliş.
Davranış/dəyər: RFM (Recency-Frequency-Monetary), axın riski, gəlirlilik.
Stimullara cavab: offerlərə/notifikasiyalara uplift reaksiyası seqmentləri.
7) Səbəblər və təcrübələr
A/B: onbordinq, tutoriallar, push-strategiyalar; əsas metrika - D7/D14/D30 retenshn, guardrails - şikayətlər, cavab vaxtı, RG.
Kvazi eksperimentlər: Randomizasiya mümkün olmadıqda DiD/sintetik nəzarət (məsələn, regional çıxışlar).
Uplift modelləri: aktivlik ehtimalını deyil, geri dönüş artımını hədəfləyir; Qini/AUUC qiymətləndirin.
8) Re-aktivasiya: tetikləyicilər və siyasət
Siqnallar: tezliyin düşməsi, N gün depozitlərin olmaması, anormal aşağı çek, 2-ci sessiya olmadan tamamlanmış bağlama.
Decision table (nümunə)
Histeresis: «yanıb-sönməyən» siqnallar üçün müxtəlif giriş/çıxış eşikləri.
Kanallar: in-app, push, e-mail, SMS, çağrı mərkəzi - rate-limit və prioritetlərlə.
9) Tutma metrikası
D1/D7/D30 (Rolling/Exact), WAU/MAU, Stickiness (DAU/MAU).
Survival mediana/kvantillər; fasilələrlə hazard.
Reactivation rate (R30), Dormancy share.
ROMI yenidən aktivləşdirilməsi, NNT (1 qaytarma üçün neçə əlaqə).
Fairness: ölkələr/platformalar üzrə metrik fərqlər; siyasətlərdən qəbuledilməz əlamətləri çıxarın.
10) Dashbord saxlama
Cocort istilik kartı + trend xətləri D1/D7/D30.
Seqmentlər üzrə Survival/hazard qrafikləri.
Erkən həyat hunisi: install → reg → KYC → 1-ci oyun → 1-ci depozit.
Hərəkət xəritəsi: siqnal → həll → kanal → çıxış (conversion to return).
Guardrails: məlumatların təravəti, hadisələrin coverage, şikayətlər, RG göstəriciləri.
11) Məlumat və keyfiyyət
Hadisələr: kanonik sxem (UTC, versiyalar), idempotentlik, dedup.
Kimlik: user/device/e-mail/telefon - körpülər və qızıl yazı.
Windows və TZ: UTC + yerli performans saxlama; vahid bayram təqvimi.
Filtrlər: botlar/QA/frod - koqorta və aktivliklərdən xaric edin.
Metriklərin versiyası: 'RET _ D7 _ vN' c changelog.
12) Psevdo-SQL/piton reseptləri
Kohortlarda Rolling D30
sql
WITH base AS (
SELECT user_id, DATE_TRUNC('day', MIN(ts)) AS cohort_day
FROM event_register GROUP BY 1
),
act AS (
SELECT user_id, DATE_TRUNC('day', ts) AS d
FROM event_activity
),
roll30 AS (
SELECT b. cohort_day,
COUNT(DISTINCT b. user_id) AS cohort_size,
COUNT(DISTINCT CASE WHEN a. d BETWEEN b. cohort_day AND b. cohort_day + INTERVAL '30 day'
THEN b. user_id END) AS any_1_30
FROM base b LEFT JOIN act a ON a. user_id = b. user_id
GROUP BY 1
)
SELECT cohort_day, any_1_30::decimal/cohort_size AS rolling_d30
FROM roll30;Kaplan-Meier (eskiz)
python t_i - time to outflow or censorship; e_i - event indicator
S(t) = Π_{t_i ≤ t} (1 - d_i / n_i)Discrete-hazard (günlük logit)
python
For each user, create records before the event/censorship by day:
target = 1 if there was an outflow on that day; characteristics: calendar, activity, promo, etc.
Training logistic regression/GBM; forecast p_t - probability of outflow on day t.13) Uplift-hədəf saxlama
Zonalar: Persuadables (əlaqə varsa geri qayıdır), Sure things (və belə geri qayıdır), Lost causes, Do-not-disturb (əlaqə zərər verir).
Metrik: uplift @k, Qini/AUUC; siyasət - uplift büdcə ilə top k əlaqə.
Guardrails: əlaqə tezliyi cap, RG/etika, əlaqə səbəblərini izah etmək.
14) Əməliyyat istismarı
SLO: retenshn dashboard yeniləmə ≤ 06:00 lok.; risk hesabının latency ≤ 300 ms; Decision→Action ≤ 5 с.
Monitorinq: seqmentlər üzrə əyrilərin yerdəyişməsi, PSI işarələrinin sürüklənməsi, «hadisələrin qırılması».
Runibook: D1-in düşməsi (onbording/release), D7-nin düşməsi (məzmun/tezlik), yerli rabitə kanallarının nasazlığı.
15) Tez-tez səhvlər
Vahid qarışdırma (seans istifadəçiləri), TZ, fəaliyyət pəncərələri.
bərabər kimi Rolling və Exact göstəriciləri müqayisə.
Ignor bot/froda → şişirdilmiş D1/D7.
Səbəbsiz korrelyasiya nəticələri.
Histerezis/kuldaunların olmaması → kontaktlardan yorğunluq.
LTV ilə heç bir əlaqə yoxdur - CR optimallaşdırın, lakin dəyər deyil.
16) Saxlama konturunun buraxılmasından əvvəl çek siyahısı
- Pasport metrik (trigger fəaliyyət, pəncərə, TZ, versiyası)
- Cocort hesabatları və seqmentlər üzrə survival/hazard
- Risk axını və uplift modelləri, qapaq və guardrails kanalları
- A/B planı və/və ya müdaxilələr üçün kvazi-eksperimentlər
- Təravət/coverage/şikayət/RG daşbordları
- Runibook insidentlər, histerezis və rate-limits siyasətdə
- LTV və ROMI ilə tutma bağlantısı; gözlənilən dəyər prioritetləşdirilməsi
Yekun
Tutma analizi yalnız «istilik kartı cohort» deyil, idarə olunan sistemdir: düzgün təriflər, survival/hazard modelləri, dəyər əlaqəsi, hədəflənmiş və etik müdaxilələr, ciddi təsir qiymətləndirməsi və əməliyyat guardrails. Siz LTV-ni stabil artıran və axını azaldan «müşahidə edin → başa düşün → qərar verin → hərəkət edin → öyrənin» dövrünü qurursunuz.