GH GambleHub

Analyse der Spielerbindung

Analyse der Spielerbindung

Retention ist der Kern der Produktökonomie: Je länger ein Spieler aktiv bleibt, desto höher der LTV, desto stabiler das Einkommen und desto vorhersehbarer die Planung. Unten ist der vollständige Rahmen: von korrekten Definitionen über Überlebensmodelle bis hin zur Re-Aktivierungsschleife.

1) Definitionen und Rechnungseinheiten

Einheit: Spieler (user/master_id) - Standard; für kurzfristige Aufgaben ist „Konto/Gerät“ zulässig, aber notieren Sie dies im Metrikdatenblatt.
Aktivität: Rückgabekriterium (≥1 Sitzung/ ≥1 Wette/ ≥1 Einzahlung) - fix.
Retention Dn: Anteil der Kohorte, die am n-ten Tag nach dem Referenzdatum zurückgekehrt ist.
Rolling/Bracket: Rolling D7 (an jedem der Tage 1-7) gegen Exact D7 (genau am 7. Tag).
Churn (Abfluss): Inaktivität ≥T Tage (z. B. 14/30); wird als Produktregel angegeben.
Kohorten: nach dem Datum der Registrierung/erste Einzahlung/erstes Spiel - wählen Sie unter der Aufgabe Marketing/Produkt.

💡 Goldene Regel: Aktivitätsauslöser, Zeitzone, Referenzdatum und Abflussregel vorab erfassen.

2) Grundlegende Analytik: Kohorten und Retention-Kurven

Kohortenwärmekarten: D1/D3/D7/D14/D30/D60; Diagonalen sind vergleichbar zwischen Releases und Kampagnen.
Überlebenskurven: Anteil der Aktiven von Tag 0 bis N (Überlebenskurve).
Geometrie der Kurve: „Sprossen“ der Feiertage/Releases; früher „Zusammenbruch“ → Onboarding-Probleme, „langer Schwanz“ → der Kern der Loyalen.

Pseudo-SQL: Kohorte 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) Überlebens- und Hazard-Modelle

Kaplan-Meier: Nicht-Modell-Survival-Bewertung (S (t)); nützlich für die „Entformung“ der Kurve und des Medians des Lebens.
Cox PH/Accelerated Failure Time: Erklärbare Muster des Einflusses von Merkmalen (Land, Kanal, Plattform, Boni, Inhalt) auf Hazard (Abflussrisiko).
Discrete-time hazard (Logits nach Tagen): Flexibel für Produkt-Analysen und Kalender-Features.
Ereignis „Re-Aktivierung“: separat modellieren (Wettkampfrisiken) oder als Übergang in die Markov-Kette.

4) Markov- und Halbparkmodelle

Neu → Aktiv → Dormant → Churned → Reactivated

Übergänge: Wahrscheinlichkeiten pro Zeitraum (Tag/Woche).
Wert: Multiplizieren Sie die Wahrscheinlichkeiten des Aufenthalts in „Active“ mit dem durchschnittlichen Check/Frequenz - erhalten Sie den erwarteten Beitrag zum LTV.

5) Halteband und LTV

LTV ≈ Σ (Retention_t × ARPU_t × der Diskont).
Elastizität: D7-Anstieg um X Prozentpunkte → LTV-Anstieg um Y% (aus historischen Daten/Modellen).
Priorisierung: Verbesserungen, die sich auf die frühe Bindung auswirken (D1-D7), sind fast immer die profitabelsten.

6) Retention Segmentierung

Onboarding Kohorten: Erste Inhalte/Spielkategorie/Verhaltensmuster am Tag 0.
Geo/Plattform/Kanal: Unterschiede zwischen UX und Erwartungen; Kalender/Feiertage anpassen.
Verhalten/Wert: RFM (Recency-Frequency-Monetary), Abflussrisiko, Rentabilität.
Die Antwort auf Stimuli: Segmente durch Uplift-Reaktion auf Offers/Notifications.

7) Kausalität und Experimente

A/V: Onboarding, Tutorials, Push-Strategien; Hauptmetrik - D7/D14/D30 retention, guardrails - Beschwerden, Antwortzeit, RG.
Quasi-Experimente: DiD/synthetische Kontrolle, wenn eine Randomisierung nicht möglich ist (z.B. regionale Rollouts).
Uplift-Modelle: Zielen Sie auf den Return-Gewinn und nicht auf die Wahrscheinlichkeit der Aktivität ab; Bewerten Sie Qini/AUUC.

8) Re-Aktivierung: Auslöser und Politik

Signale: Frequenzabfall, keine Einzahlungen N Tage, ungewöhnlich niedriger Check, abgeschlossenes Onboarding ohne 2. Session.

Entscheidungstabelle (Beispiel)

BedingungDer KontextDie HandlungKuldaunGuardrails
`risk_churn ≥ 0. 8` & `value_q ≥ 0. 8`VIPPersönliches Angebot LROMI≥0
`no_session ≥ 7д` & `no_deposit ≥ 14д`Massensegm. Push + E-Mail „zurück zu“...zhaloby≤Kh
`RG_risk ≥ τ`Jederrauza/RG-TippFPR≤1%

Hysterese: Verschiedene Eingangs-/Ausgangsschwellen für Signale, um nicht zu „blinken“.
Kanäle: In-App, Push, E-Mail, SMS, Callcenter - mit Rate-Limit und Prioritäten.

9) Retentionsmetriken

D1/D7/D30 (Rolling/Exact), WAU/MAU, Stickiness (DAU/MAU).
Überlebensmedian/Quantil; hazard in Intervallen.
Reactivation rate (R30), Dormancy share.
ROMI Re-Aktivierung, NNT (wie viele Kontakte pro 1 Return).
Fairness: Unterschiede der Metriken nach Ländern/Plattformen; Entfernen Sie ungültige Zeichen aus den Richtlinien.

10) Haltedashboards

Kohortenthermokarte + Trendlinien D1/D7/D30.
Survival/Hazard Charts nach Segmenten.
Frühes Leben Trichter: install→reg→KYC→1 igra→1 Einzahlung.
Aktion Karte: signal→resheniye→kanal→iskhod (conversion to return).
Guardrails: Frische der Daten, Berichterstattung über Ereignisse, Beschwerden, RG-Indikatoren.

11) Daten und Qualität

Ereignisse: kanonisches Schema (UTC, Versionen), Idempotenz, Dedup.
Identitäten: Benutzer/Gerät/E-Mail/Telefon - Brücken und goldener Eintrag.
Fenster und TZ: Speicherung in UTC + lokale Ansichten; Ein einziger Kalender der Feiertage.
Filter: Bots/QA/Betrug - aus Kohorte und Aktivitäten ausschließen.
Versionierung der Metriken: 'RET _ D7 _ vN' mit changelog.

12) Pseudo-SQL/Python-Rezepte

Rolling D30 nach Kohorten

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 (Skizze)

python t_i - time to outflow or censorship; e_i - event indicator
S(t) = Π_{t_i ≤ t} (1 - d_i / n_i)

Discrete-hazard (Logit nach Tag)

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-Retention Targeting

Zonen: Persuadables (kommen zurück, wenn wir in Kontakt kommen), Sure things (kommen zurück und so), Lost causes, Do-not-disturb (Kontakt tut weh).
Metriken: uplift @ k, Qini/AUUC; Politik - Kontakt top k auf uplift unter dem Budget.
Guardrails: Cap auf Kontakthäufigkeit, RG/Ethik, Erklärbarkeit der Kontaktursache.

14) Betriebsbetrieb

SLO: Update des Retention Dashboards ≤ 06:00 Uhr Lok.; Latency-Scoring-Risiko ≤ 300 ms; Decision→Action ≤ 5 с.
Überwachung: Kurvenverschiebungen nach Segmenten, PSI-Merkmalsdrift, „Ereignisabbruch“.
Runibuki: Drop D1 (Onboarding/Release), Drop D7 (Content/Frequenz), lokale Störungen der Kommunikationskanäle.

15) Häufige Fehler

Mischen von Einheiten (sessii↔polzovateli), TZ, Aktivitätsfenstern.
Vergleich von Rolling und Exact Indikatoren als gleichwertig.
Ignoriere Bots/Betrug → überteuerte D1/D7.
Schlussfolgerungen zur Korrelation ohne kausale Überprüfung.
Mangel an Hysterese/Couldounts → Kontaktmüdigkeit.
Keine Bindung an LTV - wir optimieren CR, aber nicht den Wert.

16) Checkliste vor Freigabe der Haltekontur

  • Datenblatt der Metriken (Aktivitätsauslöser, Fenster, TZ, Version)
  • Kohortenberichte und Survival/Hazard nach Segmenten
  • Abfluss- und Uplift-Risikomodelle, Kappen- und Guardrails-Kanäle
  • Plan A/B und/oder Quasi-Experimente für Interventionen
  • Fresh Dashboards/Coverage/Reklamationen/RG
  • Runibooks der Vorfälle, Hysterese und Rate-Limits in der Politik
  • Retentionsbündel mit LTV und ROMI; Priorisierung nach erwartetem Wert

Summe

Die Retention-Analyse ist nicht nur eine „Kohorten-Wärmekarte“, sondern ein überschaubares System: korrekte Definitionen, Survival/Hazard-Modelle, Value-Relation, gezielte und ethische Interventionen, rigorose Effektbewertung und operative Guardrails. Sie bauen einen „Beobachten → Verstehen → Entscheiden → Handeln → Lernen“ -Zyklus auf, der den LTV stetig erhöht und den Abfluss verringert.

Contact

Kontakt aufnehmen

Kontaktieren Sie uns bei Fragen oder Support.Wir helfen Ihnen jederzeit gerne!

Telegram
@Gamble_GC
Integration starten

Email ist erforderlich. Telegram oder WhatsApp – optional.

Ihr Name optional
Email optional
Betreff optional
Nachricht optional
Telegram optional
@
Wenn Sie Telegram angeben – antworten wir zusätzlich dort.
WhatsApp optional
Format: +Ländercode und Nummer (z. B. +49XXXXXXXXX).

Mit dem Klicken des Buttons stimmen Sie der Datenverarbeitung zu.