Frühlingsära eröffnet 😎

Zeit, das Design auf warme, die Seele wärmende Farbtöne zu aktualisieren. Habe ein neues Design zusammengestellt, damit jeder Beitrag Frühlingsenergie ausstrahlt 🔥

So, jetzt gehen wir zu den Produktfragen über 👇

Du bekommst zwei Tabellen - users und events. Und 20 Minuten Zeit für die Aufgabe:
„Berechne, mein Lieber, die Retention nach Kohorten M0–M3“

Und genau hier setzt die Denkblockade ein.
Wo fängt man überhaupt an? 🤔

Am einfachsten - nicht mit SQL, sondern mit einem Bild im Kopf. Stell dir ein Fitnessstudio vor.
100 Leute kaufen eine Mitgliedschaft - das ist deine Kohorte.
Normalerweise wird diese Kohorte als 100% angenommen. Das ist M0.
Aber hier ist der Haken: Das ist kein Naturgesetz, sondern nur eine stillschweigende Übereinkunft.
Am nächsten Tag kommen 60 Leute - Tag 1 = 60%.
Nach einer Woche kommen 40 - Tag 7 = 40%.

Die Logik ändert sich nicht.
Statt Tagen eben Monate.
Und statt Fitnessstudio - das Produkt.

1️⃣ Junior-Level - verstehen, wie viele Leute überhaupt in jede Kohorte kamen
SELECT
  DATE_TRUNC('month', registration_date) AS cohort_month,
  COUNT(DISTINCT user_id) AS new_users
FROM users
GROUP BY 1
ORDER BY 1;

Wenn hier schon ein Fehler ist, kannst du einpacken. Denn DATE_TRUNC und DISTINCT sind die Basis des Produktblocks.
Zumindest für PostgreSQL und ähnliche Dialekte.

2️⃣ Nächste Stufe - verstehen, wer zurückgekommen ist
WITH cohort_dec AS (
  SELECT user_id, registration_date
  FROM users
  WHERE registration_date >= '2023-12-01'
    AND registration_date < '2024-01-01'
)
SELECT
  COUNT(*) AS cohort_size,
  COUNT(DISTINCT CASE WHEN event_date = registration_date + 1 THEN user_id END) AS day1,
  COUNT(DISTINCT CASE WHEN event_date = registration_date + 7 THEN user_id END) AS day7
FROM cohort_dec u
LEFT JOIN events e ON u.user_id = e.user_id;

Hier lauern Fallstricke 🤔

Dieser Code ist in Ordnung, wenn deine Daten als DATE ohne Zeit gespeichert sind.
Aber wenn es TIMESTAMP ist, kann eine einfache Gleichheit die Berechnung durcheinanderbringen.
Weil der eine ein Ereignis um 2023-12-08 00:01 hat, der andere um 2023-12-08 19:42, und formal sind das nicht mehr dieselben Werte.

Also muss man entweder auf Datum umwandeln oder über Bereiche zählen.
Die Logik ist immer dieselbe:
✅ Kohorte festgelegt → geschaut, wer zurückgekommen ist

Für M1, M2, M3 ist es fast dasselbe, aber es gibt einen grundlegenden Punkt:
👉 Man vergleicht nicht einfach Daten, sondern die Verschiebung in Kalendermonaten relativ zum Registrierungsmonat (klingt kompliziert, ich erkläre es gleich)

Also nicht +30 Tage. Monate haben unterschiedliche Längen, daher verschiebt sich diese Berechnung.
Für die monatliche Retention schaut man auf die Verschiebung in Kalendermonaten, nicht einfach +30 Tage.

❌ Wo noch Fallstricke lauern

1️⃣ Man zählt Ereignisse statt Personen
Ein Benutzer hat 5 Ereignisse.
Und plötzlich hast du eine Retention von über 100%.
Das bedeutet, du zählst nicht die Rückkehr von Personen, sondern die Aktivität.

2️⃣ Man verwendet INNER JOIN
Und in der Auswahl bleiben nur die, die zurückgekehrt sind.
Alle, die abgesprungen sind, verschwinden einfach.
Das ergibt eine schöne Zahl. Und ein völlig falsches Bild.

3️⃣ Man fixiert die Berechnungsbasis nicht
Die Kohortengröße wird normalerweise als 100% angenommen, und davon wird alles Weitere berechnet.
Wenn deine Basis schwankt, werden die Prozente zu Müll.

Und dann beginnt das Hauptproblem... der Test auf Denkweise und Soft Skills. Das ist der steinigste Weg, wenn man wenig Erfahrung hat.
Denn im Vorstellungsgespräch wird man dich nicht fragen:
„Wie berechnet man Retention?“

Sondern:
„D30 ist gefallen. Warum?“

Da liegt der Hund begraben... Und hier beeindruckt SQL niemanden mehr.

✅ Ein normaler Gedankengang ist:
- Retention nach Kohorten aufschlüsseln
- Akquisitionskanäle ansehen
- Activation prüfen
- Verstehen, ob das Onboarding kaputt war
- Verhalten vor und nach Releases vergleichen
Man kann noch tiefer graben, aber für den Anfang reichen diese Grundlagen.

❌ Die Antwort, die dein Gespräch sofort beendet
„Nun… die Retention ist gesunken, weil die Benutzer schlechter zurückgekommen sind…“

Danke, Herr Kapitän. Aber das ist keine Antwort eines Analysten, sondern eine Vermutung.

Einfach ausgedrückt:
Retention geht nicht um SQL, sondern um Verhalten.
SQL ist nur die Schaufel, mit der du die Zahl ausgräbst.

Wenn du nicht erklären kannst, warum Leute aufgehört haben zurückzukommen,
dann sagen deine Prozente an sich gar nichts aus 🤷‍♀️

Hattet ihr schon Probleme im Produktblock? Und magt ihr überhaupt die Produktrichtung oder gefällt euch der technische Teil mehr? 👇