GH GambleHub

Oyuncu tutma analizi

Oyuncu tutma analizi

Elde tutma, ürün ekonomisinin özüdür: Bir oyuncu ne kadar uzun süre aktif kalırsa, LTV ne kadar yüksek olursa, gelir o kadar istikrarlı olur ve planlama o kadar öngörülebilir olur. Aşağıda tam bir çerçeve bulunmaktadır: doğru tanımlardan hayatta kalma modellerine ve yeniden aktivasyon devresine.

1) Tanımlar ve muhasebe birimleri

Birim: oyuncu (user/master_id) - varsayılan olarak; Kısa vadeli görevler için bir "hesaba/cihaza" izin verilir, ancak bunu metrik pasaporta kaydedin.
Aktivite: iade kriteri (≥1 seansı/ ≥1 oranı/ ≥1 depozito) - kayıt.
Retention Dn: Referans tarihinden sonra n gününde dönen kohort oranı.
Rolling/Braket: Rolling D7 (herhangi bir günde 1-7) vs Exact D7 (günde 7).
Churn: ≥T gün boyunca etkinlik yok (örneğin, 14/30); Ürün kuralı olarak belirtilir.
Kohortlar: kayıt tarihine göre/ilk depozito/ilk oyun - pazarlama/ürün görevi için seçin.

💡 Altın kural: Etkinlik tetikleyicisini, saat dilimini, referans tarihini ve çalkalama kuralını önceden düzeltin.

2) Temel analitik: kohortlar ve tutma eğrileri

Kohort ısı haritaları: D1/D3/D7/D14/D30/D60; Köşegenler, sürümler ve kampanyalar arasında karşılaştırılabilir.
Sağkalım eğrileri: 0 günden N'ye kadar aktif olanların oranı (sağkalım eğrisi).
Eğri geometrisi: tatillerin/sürümlerin "adımları"; Erken "çöküş", onboarding problemleri, "uzun kuyruk", çekirdek sadık.

Pseudo-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) Hayatta kalma ve tehlike modelleri

Kaplan-Meier: model dışı hayatta kalma skoru (S (t)); Eğrinin ve yaşam medyanının "şekil soyulması" için kullanışlıdır.
Cox PH/Hızlandırılmış Arıza Süresi: Özelliklerin (ülke, kanal, platform, bonuslar, içerik) tehlike (çıkış riski) üzerindeki etkisinin açıklayıcı modelleri.
Ayrık zaman tehlikesi (güne göre günlük): Ürün analizi ve takvim özellikleri için esnek.
Yeniden etkinleştirme olay-Model ayrı ayrı (rakip riskler) veya bir Markov zincirinde bir geçiş olarak.

4) Markov ve yarı Markov modelleri

Yeni - Aktif - Uykuda - Çalkalanmış - Yeniden Etkinleştirildi.
Geçişler: Dönem başına olasılıklar (gün/hafta).
Değer: "Aktif'de kalma olasılıklarını ortalama kontrol/frekans ile çarpın - LTV'ye beklenen katkıyı elde edin.

5) Paket saklama ve LTV

LTV ( indirim).
Esneklik: D7 artışı X pp, LTV artışı % Y (geçmiş verilerden/modellerden).
Önceliklendirme: Erken elde tutmayı (D1-D7) etkileyen iyileştirmeler neredeyse her zaman en karlı olanlardır.

6) Tutma segmentasyonu

Onboarding kohortları: 0 günde ilk içerik/oyun kategorisi/davranış modeli.
Geo/platform/kanal: UX ve beklenti farklılıkları; Takvim/tatiller için ayarlayın.
Davranış/değer: RFM (Sonluk-Frekans-Parasal), çıkış riski, karlılık.
Teşviklere yanıt: tekliflere/bildirimlere yükselme-tepki segmentleri.

7) Nedensellik ve deneyler

A/B: onboarding, öğreticiler, push stratejileri; Ana metrik - D7/D14/D30 tutma, korkuluklar - şikayetler, yanıt süresi, RG.
Yarı-deneyler: Randomizasyon mümkün olmadığında DiD/sentetik kontrol (örn. bölgesel kickouts).
Yükseltme modelleri: etkinlik olasılıkları değil, hedef getiri kazanımları; Qini/AUUC'yi değerlendirin.

8) Yeniden etkinleştirme: tetikleyiciler ve politika

Sinyaller: Frekans düşüşü, N gün yatırma yok, anormal derecede düşük kontrol, 2. oturum olmadan onboarding tamamlandı.

Karar tablosu (örnek)

DurumBağlamEylemSoğumaKorkuluklar
'risk _ churn ≥ 0. 8 '&' değeri _ q ≥ 0. 8`VIPKişisel teklif L7dROMI≥0
'No _ session ≥ 7д' & 'no _ deposit ≥ 14д'Kütle segmenti. + e-posta "geri" itin...5dzhaloby≤Kh
'RG _ risk ≥ τ'Herhangi birrouse/konsey RG1d% FPR≤1

Histerezis: "Göz kırpmamak" için sinyaller için farklı giriş/çıkış eşikleri.
Kanallar: uygulama içi, push, e-posta, SMS, çağrı merkezi - oran sınırı ve öncelikleri ile.

9) Tutma metrikleri

D1/D7/D30 (Rolling/Exact), WAU/MAU, Yapışkanlık (DAU/MAU).
Hayatta kalma medyan/nicelikler; aralıklarla tehlike.
Yeniden etkinleştirme oranı (R30), Dormancy payı.
ROMI yeniden etkinleştirme, NNT (1 geri dönüş başına kaç kişi).
Adalet: Ülkeye/platforma göre metrik farklılıklar; Geçersiz özellikleri politikalardan hariç tutun.

10) Tutma panoları

Kohort ısı haritası + trend çizgileri D1/D7/D30.
Bölümlere göre hayatta kalma/tehlike grafikleri.
Erken yaşam hunisi: yükle? reg? KYC? 1 igra? 1 th mevduat.
Eylem haritası: signal ^ resteniye ^ kanal ^ iskhod (conversion to return).
Korkuluklar: verilerin tazeliği, olayların kapsamı, şikayetler, RG göstergeleri.

11) Veri ve kalite

Olaylar: kanonik şema (UTC, sürümler), idempotency, deadup.
Kimlikler: kullanıcı/cihaz/e-posta/telefon - köprüler ve altın girişi.
Windows ve TZ: UTC + yerel görünümlerinde depolama; Tek tatil takvimi.
Filtreler: Botlar/QA/dolandırıcılık - kohort ve faaliyetlerden hariç tutulur.
Sürüm metrikleri: Changelog ile 'RET _ D7 _ vN'.

12) Pseudo-SQL/python tarifleri

Kohort tarafından haddeleme 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)

Ayrık tehlike (günlüğe göre günlük)

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) Yükseltme hedefleme tutma

Bölgeler: İkna edilebilir (temas kurarsak geri dönecektir), Emin şeyler (geri dönecektir vb.), Kayıp nedenler, Rahatsız etmeyin (temas zararları).
Metrikler: uplift @ k, Qini/AUUC; Siyaset - biz bütçe için yükselterek üst k temas.
Korkuluklar: temas frekansı, RG/etik, temas nedeninin açıklanabilirliği.

14) Operasyonel operasyon

SLO: tutma panosu güncelleme ≤ 06:00 kilit.; Risk puanlamasının gecikmesi ≤ 300 ms; Karar - Eylem ≤ 5 с.
İzleme: eğrilerin segmentlere göre kayması, özellik sürüklenmesinin PSI'ı,'olay sonu ".
Runibooks: D1 damlası (onboarding/release), D7 damlası (content/frequency), yerel iletişim kanalı arızaları.

15) Sık yapılan hatalar

Ünitelerin karıştırılması (sessii↔polzovateli), TZ, etkinlik pencereleri.
Rolling ve Exact göstergelerinin eşit olarak karşılaştırılması.
Botları/sahtekarlığı görmezden gelmek - şişirilmiş D1/D7.
Nedensel doğrulama olmadan korelasyon üzerine sonuçlar.
Histerezis/cooldowns yok - temas yorgunluğu.
LTV ile bağlantı yok - CR'yi optimize ediyoruz, ancak değeri değil.

16) Yayın Öncesi Tutma Döngüsü Kontrol Listesi

  • Metrik pasaport (etkinlik tetikleyici, pencere, TZ, sürüm)
  • Kohort raporları ve segmentlere göre hayatta kalma/tehlike
  • Çıkış ve yükselme risk modelleri, kapas ve korkuluk kanalları
  • Müdahaleler için Plan A/B ve/veya yarı-deneyler
  • Tazelik/kapsama/şikayetler/RG panoları
  • Olay Runybooks, Hysteresis ve Politikada Oran-Limitleri
  • LTV ve ROMI ile paket tutma; Beklenen değere göre önceliklendirme

Toplam

Elde tutma analizi sadece bir "kohortların ısı haritası'değil, yönetilen bir sistemdir: doğru tanımlar, hayatta kalma/tehlike modelleri, değerle ilişki, hedefli ve etik müdahaleler, titiz etki değerlendirmesi ve operasyonel korkuluklar. LTV'yi istikrarlı bir şekilde artıran ve dışarı akışı azaltan bir "izle, anla, karar ver, harekete geç, öğren" döngüsü oluşturursunuz.

Contact

Bizimle iletişime geçin

Her türlü soru veya destek için bize ulaşın.Size yardımcı olmaya her zaman hazırız!

Telegram
@Gamble_GC
Entegrasyona başla

Email — zorunlu. Telegram veya WhatsApp — isteğe bağlı.

Adınız zorunlu değil
Email zorunlu değil
Konu zorunlu değil
Mesaj zorunlu değil
Telegram zorunlu değil
@
Telegram belirtirseniz, Email’e ek olarak oradan da yanıt veririz.
WhatsApp zorunlu değil
Format: +ülke kodu ve numara (örneğin, +90XXXXXXXXX).

Butona tıklayarak veri işlemenize onay vermiş olursunuz.