Kohortenanalyse

Die Kohortenanalyse gruppiert Objekte (in der Regel Benutzer) nach einem einzigen Startereignis und vergleicht, wie und wie lange sie aktiv und wertvoll bleiben. Dieser Ansatz trennt den Zeiteffekt im System (Jahreszeiten, Aktionen) vom Alterseffekt der Kohorte (Tage ab Start).

1) Grundlegende Definitionen

Kohorte (cohort): viele Spieler, die durch das Ereignis „Geburt“ vereint sind - Registrierung, erste Einzahlung, erstes Spiel, erster Kauf.
Kalenderachse (Kalenderzeit): tatsächliche Daten (2025-10-01,...).
Altersachse der Kohorte (cohort age): Tage/Wochen seit der „Geburt“ (D0, D1,...).
Haltemetriken: D1/D7/D30 (Exact und Rolling), WAU/MAU, Stickiness (DAU/MAU).
Monetarisierung: ARPU/ARPPU, kumulativer LTV (auf D7/D30/D90).
Rechnungseinheit: Benutzer (user/master_id) - im Reisepass notieren.

💡 Goldene Regel: Geburtsereignis, TZ, Aktivitätsfenster und Ausschlüsse (Bots/QA/Betrug) vorab erfassen.

2) Kohortenarten und wann sie zu wählen sind

Akquise-Kohorten: nach dem Datum der Registrierung/des ersten Besuchs - Bewertung der Kanäle der Anziehung und des Onboardings.
Activation/Monetization-Kohorten: bei der ersten Einzahlung/Kauf - Bewertung der frühen Monetisierung und Promo.
Feature-Kohorten: durch die erste Verwendung von fichi/Spiel Kategorie - die Wirkung von Releases.
Verhaltenskohorten: nach RFM/Startmuster (z.B. „Nachtmobil“).

3) Achsen und Raster: So sehen Sie die Matrix

Kohortenmatrix: Zeilen - Kohorten (Kalender), Spalten - Alter (D0... D90).
Saisonalität: Vergleichen Sie die Diagonalen (gleicher Kalendertag), um saisonale Effekte zu trennen.
Normalisierung: Relative Metriken (CR, Anteile) + kumulativ (LTV), beide anzeigen.

4) Kohorten- und Metrikdatenblatt (Vorlage)

COHORT: `REG_DAY`	`FIRST_DEPOSIT_WEEK`
Altersachse: Tag (D), Horizonte D1/D7/D30/D90.
Aktivität: ≥1 Sitzung oder ≥1 Wette (fix).
Ausnahmen: Bots/Betrug/QA/Duplikate.
Standardsegmente: Land, Plattform, Kanal, Inhaltskategorie, Preissegment.
Metriken: CR, Rolling/Exact retention, kumulativer LTV, ARPU/ARPPU,% zahlend.
Ausführung: 'COHORT _ RET _ v3', Besitzer, Revisionsdatum.

5) Pseudo-SQL: retention matrix (Exact Dn)

sql
WITH regs 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 act_day
FROM event_activity
),
ages AS (
SELECT r. user_id, r. cohort_day, a. act_day,
(a. act_day - r. cohort_day) AS age_days
FROM regs r
JOIN act a ON a. user_id = r. user_id
),
exact AS (
SELECT cohort_day,
age_days,
COUNT(DISTINCT user_id) AS users_active
FROM ages
GROUP BY 1,2
),
coh_size AS (
SELECT cohort_day, COUNT(DISTINCT user_id) AS cohort_size
FROM regs GROUP BY 1
)
SELECT e. cohort_day,
e. age_days,
e. users_active::decimal / NULLIF(c. cohort_size,0) AS exact_retention
FROM exact e
JOIN coh_size c USING (cohort_day)
WHERE age_days IN (1,7,30,90)
ORDER BY cohort_day, age_days;

Rolling Dn (Aktivität an Tag 1... n)

sql
WITH days AS (... as above...),
roll AS (
SELECT cohort_day,
CASE WHEN age_days BETWEEN 1 AND 7 THEN 7
WHEN age_days BETWEEN 1 AND 30 THEN 30 END AS bucket,
COUNT(DISTINCT user_id) AS any_active
FROM days
WHERE age_days BETWEEN 1 AND 30
GROUP BY 1,2
)
SELECT r. cohort_day, r. bucket AS Dn,
r. any_active::decimal / s. cohort_size AS rolling_retention
FROM roll r
JOIN (SELECT cohort_day, COUNT(DISTINCT user_id) cohort_size FROM regs GROUP BY 1) s USING (cohort_day)
ORDER BY cohort_day, Dn;

6) Kohorten-LTV und Monetarisierung

Kumulativer LTV (Dn): Summe der Einnahmen pro Kohortennutzer zu Dn.
ARPU/ARPPU: Einnahmen pro Benutzer/pro zahlendem Dn.
% zahlend: Anteil mit ≥1 Zahlung an Dn.

sql
WITH reg AS (
SELECT user_id, DATE_TRUNC('day', MIN(ts)) AS cohort_day
FROM event_register GROUP BY 1
),
pay AS (
SELECT user_id, amount, DATE_TRUNC('day', ts) AS pay_day
FROM fact_payments
),
ltv AS (
SELECT r. cohort_day,
(pay_day - r. cohort_day) AS age_days,
SUM(amount) AS rev
FROM reg r JOIN pay p USING (user_id)
WHERE pay_day >= r. cohort_day
GROUP BY 1,2
),
cum AS (
SELECT cohort_day, age_days,
SUM(rev) OVER (PARTITION BY cohort_day ORDER BY age_days ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS rev_cum
FROM ltv
)
SELECT c. cohort_day, c. age_days,
c. rev_cum::decimal / NULLIF(sz. cohort_size,0) AS ltv_per_user
FROM cum c
JOIN (SELECT cohort_day, COUNT(DISTINCT user_id) cohort_size FROM reg GROUP BY 1) sz USING (cohort_day)
WHERE age_days IN (7,30,90)
ORDER BY cohort_day, age_days;

7) Überleben/hazard für das Halten

Kaplan-Meier: Non-Model Survival Curve (S (t)) - Anteil der nicht „Verschütteten“.
Hazard-Modelle (Soh/logit-by-days): Einfluss von Merkmalen (Kanal, Land, Plattform, Boni, Inhalte) auf das Abflussrisiko.
Praxis: Wir bauen KM nach Segmenten, dann erklären wir den Unterschied mit dem Hazard-Modell.

8) Saisonalität, TZ und Kalender

TZ: Speichern Sie Ereignisse in UTC, analysieren Sie in der lokalen TZ des Marktes; Seien Sie konsistent.
Kalender: Feiertage/Gehalt/Spiele/Releases - wie Flaggen; Vergleichen Sie Kohorten ähnlicher Wochen.
Gleitendes Fenster: für wöchentliche/monatliche Kohorten - Multiplizität von Feiertagen und Berichtszeiträumen.

9) Segmentierung und Attribution

Segmente: Anziehungskanal, Plattform/OS, Geo, erster Inhalt, Preis/Limits, Zahlungsmethode.
Kohorten-Attribution: „Wer hat geführt“ des Nutzers - Algorithmus erfassen (last non-direct, data-driven).
LTV-Gewichtung: Vergleichen Sie nicht nur CR, sondern auch LTV (D30/D90) nach Kanal/Segment.

10) Visualisierung

Wärmekarte der Kohortenmatrix (CR/LTV).
Die Trendlinien D1/D7/D30 im Kalender.
Survival/Hazard Grafiken.
Bridge „das hat LTV zu D30 verändert“: Beitrag der Zahlenden, Frequenz, durchschnittlicher Scheck.

11) Experimente und Kausalität

A/B: Onboarding, Tutorials, Paywall, Offers. Die Hauptmetrik ist D7/D30 Retention und LTV (D30).
Quasi-Experimente: DiD/synthetische Steuerung für Roll-out über Märkte.
Uplift-Modelle: Ziel Return-Gewinne in der Re-Aktivierung (Qini/AUUC, uplift @ k).

12) Ausbeutung und Ausbeutung

Versionierung: „RET _ D7 _ vN“, „LTV _ D30 _ vN“; changelog, wenn sich die Definition von Aktivität/Währung ändert.
Frische SLO: tägliche Kohorten - bereit bis 06:00 Uhr Lok.; Datenlag ≤ 1 Std.
Qualität: Abdeckung von Ereignissen, Anteil von Duplikaten, Anteil von Bots/Betrug außerhalb von Kohorten.
Zugang: RLS/CLS, PII-Maskierung; Export - nur Aggregate.
Runbooks: Fall von D1 (Onboarding), D7 (Content), Abbruch von Ereignissen/Identitäten.

13) Häufige Fehler (Anti-Muster)

Achsenmischung: Vergleich verschiedener Kohortenalter in verschiedenen Jahreszeiten ohne Korrekturen.
Rolling vs Exact: als ein und dasselbe interpretiert.
Einheiten mischen: Sitzungen im Nenner, Benutzer im Zähler.
Aggregation „Mittelwert“: anstatt Zähler/Nenner zu summieren.
Ignorieren Sie TZ/Kalender: D1-Offset an den Grenzen von Tagen/Feiertagen.
Kein Bot/Fraud/QA-Filter.
Nicht gemeldete Restarts: Split/Merge-Konten ohne Identitätsbrücken.

14) Checkliste vor Veröffentlichung des Kohortenberichts

Geburtsereignis, Einheit, TZ, Aktivitätsfenster definiert
Ausgenommen sind Bots/Fraud/QAs; Identitäten zusammengeführt (golden record)
Gebaut Matrizen CR (Exact/Rolling) und LTV zu D7/D30/D90
Kalender/Feiertage berücksichtigt; Segmente nach Kanal/Plattform/Geo
Survival/Hazard-Grafiken und Bridge LTV hinzugefügt
Metrikversionen und Attributionsalgorithmus dokumentiert
SLO Frische eingerichtet, Überwachung Abdeckung/Duplikate/Fehler
Bereit für Runbooks auf D1/D7 und Ereignisabbrüche

Summe

Die Kohortenanalyse besteht aus zwei Achsen und einer Disziplin: einem festen „Geburtsmoment“, korrekten Fenstern und TZ, Retentions- und LTV-Matrizen, Segmentierung und kausaler Überprüfung von Veränderungen. Dieser Ansatz hilft nicht nur, Kurven zu beobachten, sondern auch Entscheidungen zu treffen: Wo man Onboarding repariert, welche Kanäle man skaliert, welche Inhalte und Angebote die Spieler länger halten und den LTV erhöhen.

Kohortenanalyse