Voorbereiding op SQL-sollicitatiegesprekken · Les

Retentie op dag N en voortschrijdende retentie

Het verschil tussen klassieke, voortschrijdende en begrensde retentiedefinities.

Les 3 van 413 stappen

Retentie op dag N en voortschrijdende retentie is een gratis Voorbereiding op SQL-sollicitatiegesprekken-les op CoddyKit. Dit is les 3 van 4. Je kunt de volledige les hieronder gratis lezen en daarna in de browser praktisch oefenen met een ingebouwde code-editor en een AI-begeleider die 24/7 beschikbaar is. Deze les maakt deel uit van het leertraject Voorbereiding op SQL-sollicitatiegesprekken. Je voortgang wordt gesynchroniseerd op het web en in de CoddyKit-app. De cursus Voorbereiding op SQL-sollicitatiegesprekken bevat in totaal 4 lessen.

Waarom retentie meerdere definities heeft

Een interviewer zal zelden alleen zeggen: "bereken retentie". De scherpe vervolgvraag is: welke retentie? Dezelfde gegevens leveren heel andere cijfers op, afhankelijk van de definitie.

De drie die je moet kennen: Day-N-retentie (klassiek), rolling-retentie (onbegrensd) en retentie met een begrensd venster. Het verschil kennen en vragen welke variant het bedrijf wil, is op zichzelf de vaardigheid die wordt getoetst.

Day-N-retentie (klassiek)

Day-N-retentie vraagt: was de gebruiker precies op dag N na zijn eerste actie actief? Day-1, Day-7 en Day-30 zijn de standaardstatistieken voor mobiele apps.

Het sleutelwoord is precies. Een gebruiker die op dag 6 en dag 8 actief was, maar niet op dag 7, heeft onder de klassieke definitie geen retentie op Day-7. Deze precisie maakt het aantal strikt en de curve grillig.

Het verschil in dagen berekenen

Day-N-retentie draait om het aantal dagen tussen het begin van het cohort en elke activiteitsdag. In Postgres levert het aftrekken van twee datums direct een geheel getal met het aantal dagen op.

In andere dialecten: DATEDIFF(day, start, d) in SQL Server en DATEDIFF(d, start) in MySQL. Noem het dialect; het concept, een dag-offset, is identiek.

WITH cohort AS (
  SELECT user_id, MIN(event_at::date) AS day0
  FROM events GROUP BY user_id
),
act AS (
  SELECT DISTINCT user_id, event_at::date AS day
  FROM events
)
SELECT c.user_id, (a.day - c.day0) AS day_n
FROM cohort c
JOIN act a ON a.user_id = c.user_id;

Een query voor Day-7-retentie

Voor het retentiepercentage op Day-7 tel je de unieke gebruikers bij wie de dag-offset gelijk is aan 7 en deel je dit door de cohortgrootte. Gebruik voorwaardelijke aggregatie, zodat teller en noemer uit één leesbewerking komen.

De gelijkheid = 7 (niet >= 7) is het kenmerk van klassieke retentie. Als je een ongelijkheid gebruikt, verander je de definitie ongemerkt.

WITH dn AS (
  SELECT c.user_id, (a.day - c.day0) AS day_n
  FROM cohort c JOIN act a ON a.user_id = c.user_id
)
SELECT
  COUNT(DISTINCT CASE WHEN day_n = 7 THEN user_id END) AS d7_retained,
  COUNT(DISTINCT user_id)                               AS cohort_size,
  ROUND(100.0 * COUNT(DISTINCT CASE WHEN day_n = 7 THEN user_id END)
        / NULLIF(COUNT(DISTINCT user_id), 0), 1)         AS d7_pct
FROM dn;

Rolling-retentie (onbegrensd)

Rolling-retentie op dag N stelt een mildere vraag: was de gebruiker op dag N of op een willekeurige latere dag actief? Een gebruiker telt als behouden op dag 7 als die op dag 7, dag 20 of ooit daarna terugkeerde.

Dit levert een gladdere, hogere curve op en heeft vaak de voorkeur voor het meten van langdurige betrokkenheid. De kenmerkende wijziging is van = N naar >= N op de laatste activiteitsdag.

Rolling-retentie met MAX-dag

De nette manier om rolling-retentie te berekenen: zoek voor elke gebruiker de laatste actieve dag-offset (MAX); daarna heeft een gebruiker op dag N rolling-retentie als die maximumwaarde >= N is.

Na MAX heeft elke gebruiker één rij, dus tellen is eenvoudig. Hierdoor zie je ook duidelijk dat rolling-retentie monotoon is: als een gebruiker op dag 30 behouden is, is die dat op elke kleinere N.

WITH last_day AS (
  SELECT c.user_id, MAX(a.day - c.day0) AS max_day_n
  FROM cohort c JOIN act a ON a.user_id = c.user_id
  GROUP BY c.user_id
)
SELECT
  COUNT(*)                                          AS cohort_size,
  COUNT(*) FILTER (WHERE max_day_n >= 7)            AS rolling_d7,
  ROUND(100.0 * COUNT(*) FILTER (WHERE max_day_n >= 7)
        / NULLIF(COUNT(*), 0), 1)                    AS rolling_d7_pct
FROM last_day;

Retentie met een begrensd venster

De middenweg is retentie met een begrensd venster: minstens één keer actief binnen een venster rond dag N, bijvoorbeeld op dag 5 tot en met 9 voor een metriek voor "week 1". Dit staat gebruikers toe die niet op de exacte dag actief zijn, maar maakt de curve minder glad dan volledig rolling.

Dit is de meest realistische definitie voor bedrijven, omdat werkelijk gebruik vaak geclusterd is. De query gebruikt BETWEEN op de dag-offset.

SELECT
  COUNT(DISTINCT CASE WHEN day_n BETWEEN 5 AND 9
                      THEN user_id END) AS week1_retained,
  COUNT(DISTINCT user_id)               AS cohort_size
FROM dn;

Drie definities, dezelfde gebruiker

Maak het verschil concreet. Een gebruiker begint op dag 0 en is daarna alleen op dag 9 actief.

  • Klassieke Day-7: niet behouden (geen activiteit precies op dag 7).
  • Rolling Day-7: behouden (maximale dag 9 >= 7).
  • Begrensde 5–9, week 1: behouden (dag 9 valt binnen het venster).

Dezelfde gegevens, drie antwoorden. Vertel in een interview één voorbeeld zoals dit om te bewijzen dat je de betekenis begrijpt, niet alleen de syntaxis.

Periodegranulariteit: dag versus week versus maand

"Day-N" is een specifiek geval van period-N. Voor een B2B-product met maandelijks gebruik is retentie per dag ruis; je zou per maand groeperen en naar maand-N vragen. De werkwijze is identiek, alleen de granulariteit verandert.

Stem de granulariteit af op het natuurlijke gebruiksritme van het product en zeg dat ook. Dagelijks voor mobiele consumentenproducten, wekelijks of maandelijks voor tragere B2B-tools.

-- weekly grain: offset in whole weeks
SELECT
  c.user_id,
  FLOOR((a.day - c.day0) / 7) AS week_n
FROM cohort c
JOIN act a ON a.user_id = c.user_id;

De valkuil van overleving en volwassenheid

Een subtiele vraag voor senior niveau: rapporteer geen Day-30-retentie voor een cohort dat pas 10 dagen oud is. Het heeft nog niet de kans gehad om op dag 30 actief te zijn, dus de waarde is kunstmatig 0 en betekent niet dat de retentie werkelijk laag is.

Bescherm dit door bij Day-N alleen cohorten op te nemen waarvan de leeftijd >= N is. Filter op CURRENT_DATE - day0 >= N. Als je dit vergeet, lijken recente cohorten catastrofaal slecht.

WITH cohort AS (
  SELECT user_id, MIN(event_at::date) AS day0
  FROM events GROUP BY user_id
)
SELECT *
FROM cohort
WHERE (CURRENT_DATE - day0) >= 30;  -- mature enough for Day-30

Een definitie hardop kiezen

Het beste interviewantwoord is geen query, maar een wedervraag: "Wil je klassieke Day-N-retentie, rolling-retentie of retentie met een begrensd venster? En wat is de natuurlijke periode?"

Geef vervolgens de afweging: klassiek is strikt en geschikt voor productfuncties met een specifiek activeringsmoment; rolling overschat de kortetermijnretentie, maar legt blijvende betrokkenheid over de hele levensduur vast; begrensd is het realistische compromis. Laten zien dat je bewust een metriek kiest, is het hele doel van deze les.

Snelle controle

De eerste actie van een gebruiker is dag 0; de enige andere activiteit is op dag 12. Heeft deze gebruiker volgens elke definitie retentie op Day-7?

Samenvatting: retentiedefinities

Belangrijkste punten over Day-N- en rolling-retentie:

  • Klassieke Day-N: actief precies op dag N (offset = N) — strikt, grillige curve.
  • Rolling: actief op dag N of later (MAX offset >= N) — gladder, monotoon en een maat voor blijvende betrokkenheid.
  • Begrensd: actief binnen een venster (BETWEEN) — het realistische compromis.
  • Pas dag toe op elke periodegranulariteit die bij het gebruiksritme van het product past.
  • Rapporteer Day-N alleen voor volwassen cohorten (leeftijd >= N) om de valkuil van overleving te vermijden, en vraag altijd welke definitie het bedrijf bedoelt.
Gratis beginnen

Leer SQL met een AI-tutor — gratis

Schrijf echte code en voer die uit in je browser, krijg direct hulp van een AI-tutor die 24/7 beschikbaar is en ga verder waar je gebleven bent op het web of in de app.

Cursussen
30
Lessen
120

Veelgestelde vragen

Is de les “Retentie op dag N en voortschrijdende retentie” gratis?

Ja — de volledige tekst van “Retentie op dag N en voortschrijdende retentie” kun je hier gratis op het web lezen. Als je interactief wilt oefenen met een ingebouwde code-editor en een AI-begeleider die 24/7 beschikbaar is, en de rest van de cursus Voorbereiding op SQL-sollicitatiegesprekken wilt ontgrendelen, kun je upgraden naar CoddyKit PRO. De cursus Voorbereiding op SQL-sollicitatiegesprekken bevat in totaal 4 lessen.

Wat leer ik in “Retentie op dag N en voortschrijdende retentie”?

Het verschil tussen klassieke, voortschrijdende en begrensde retentiedefinities. Je oefent met Voorbereiding op SQL-sollicitatiegesprekken door code rechtstreeks in de browser uit te voeren. Een AI-begeleider die 24/7 beschikbaar is beantwoordt je vragen terwijl je de les doorwerkt.

Heb ik ervaring nodig om met Voorbereiding op SQL-sollicitatiegesprekken te beginnen?

Ervaring vooraf is niet nodig. Voorbereiding op SQL-sollicitatiegesprekken op CoddyKit is opgebouwd voor beginners tot gevorderden, zodat je hier of bij het begin kunt starten en in je eigen tempo kunt leren. Dit is les 3 van 4.

Hoe lang duurt de les “Retentie op dag N en voortschrijdende retentie”?

De meeste lessen van CoddyKit duren ongeveer 5–10 minuten. Elke les is kort en interactief, zodat je gestaag vooruitgaat en op het web en in de app precies verdergaat waar je was gebleven.

Kan ik code schrijven en uitvoeren in deze les over Voorbereiding op SQL-sollicitatiegesprekken?

Ja. Elke les over Voorbereiding op SQL-sollicitatiegesprekken bevat een ingebouwde code-editor, zodat je rechtstreeks in je browser echte code kunt schrijven en uitvoeren en direct feedback van AI krijgt — lokale installatie is niet nodig.

Alle lessen in deze cursus

  1. Een cohort definiëren op basis van de eerste actie
  2. Een retentiematrix maken
  3. Retentie op dag N en voortschrijdende retentie
  4. Query's voor churn en terugkerende gebruikers
← Terug naar Voorbereiding op SQL-sollicitatiegesprekken