Bahar dönemi açıldı 😎

Ruhu ısıtan sıcak tonlarla tasarımı yenileme zamanı. Her gönderinin bahar enerjisi yayması için yeni bir tasarım topladım 🔥

Şimdi ürün sorularına geçelim 👇

Sana iki tablo veriliyor - users ve events. Ve görev için 20 dakikan var:
«M0–M3 kohortlarına göre retention hesapla»

Ve işte burada takılıp kalıyorlar.
Peki nereden başlamalı? 🤔

En kolayı - SQL ile değil, kafanda bir resimle başlamak. Bir spor salonu hayal et.
100 kişi abonelik satın aldı - bu senin kohortun.
Genelde bu kohort %100 olarak kabul edilir. Buna M0 denir.
Ama bir nüans var: bu bir doğa kanunu değil, sadece yazılı olmayan bir anlaşma.
Ertesi gün 60 kişi geldi - 1. Gün = %60.
Bir hafta sonra 40 kişi geldi - 7. Gün = %40.

Mantık değişmiyor.
Sadece günler yerine aylar var.
Ve spor salonu yerine ürün var.

1️⃣ Junior seviyesi - her kohorta kaç kişinin geldiğini anlamak
SELECT
  DATE_TRUNC('month', registration_date) AS cohort_month,
  COUNT(DISTINCT user_id) AS new_users
FROM users
GROUP BY 1
ORDER BY 1;

Burada hata varsa, her şey bitti. Çünkü DATE_TRUNC ve DISTINCT, ürün bloğunun temelidir.
En azından PostgreSQL ve benzeri lehçeler için.

2️⃣ Sonraki seviye - kimin geri döndüğünü anlamak
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;

Burada tuzaklar var 🤔

Bu kod, tarihlerin zaman olmadan DATE olarak saklanması durumunda normaldir.
Ama TIMESTAMP ise, basit eşitlik hesaplamayı bozabilir.
Çünkü birinin olayı 2023-12-08 00:01, diğerininki 2023-12-08 19:42 ve resmi olarak bu aynı değer değil.

Yani ya tarihe dönüştürmek ya da aralıklarla hesaplamak gerekir.
Mantık her zaman aynıdır:
✅ kohortu sabitle → kimin döndüğüne bak

M1, M2, M3 için neredeyse aynı, ancak önemli bir nokta var:
👉 sadece tarihleri değil, kayıt ayına göre takvim aylarındaki kaymayı karşılaştırırlar (kulağa karmaşık geliyor, şimdi açıklayacağım)

Yani +30 gün değil. Aylar farklı uzunlukta olduğu için bu hesaplama kayar.
Aylık retention için takvim aylarındaki kaymaya bakılır, sadece 30 gün eklenmez.

❌ Başka nerelerde tuzak var

1️⃣ Kişiler yerine olayları saymak
Bir kullanıcı 5 olay yaptı.
Ve birden retention %100'ün üzerinde çıktı.
Yani kişilerin dönüşünü değil, aktiviteyi sayıyorsun.

2️⃣ INNER JOIN kullanmak
Ve seçimde sadece geri dönenler kalır.
Ayrılanlar kaybolur.
Güzel bir rakam elde edilir. Ama tamamen yanlış bir tablo.

3️⃣ Hesaplama tabanını sabitlememek
Kohort büyüklüğü genelde %100 kabul edilir ve her şey bundan hesaplanır.
Tabanın kayarsa, yüzdeler çöp olur.

Ve sonra asıl sorun başlar... düşünme ve yumuşak beceri testi. İşte deneyim azsa en zorlu yol burasıdır.
Çünkü mülakatta sana sormazlar:
«Retention nasıl hesaplanır?»

Ama sorarlar:
«D30 düştü. Neden?»

İşte burada... Ve bu noktada SQL kimseyi etkilemez.

✅ Normal düşünce akışı şöyledir:
- retention'ı kohortlara ayır
- edinme kanallarına bak
- aktivasyonu kontrol et
- onboarding bozulmuş mu diye bak
- sürümlerden önceki ve sonraki davranışı karşılaştır
Daha derine inilebilir, ancak başlangıç için bu temeller yeterli.

❌ Diyaloğu hemen bitirecek cevap
«Şey… retention düştü çünkü kullanıcılar daha az geri dönmeye başladı..»

Teşekkürler Kaptan. Ama bu bir analist cevabı değil, tahmin.

Basitçe söylemek gerekirse:
Retention SQL ile ilgili değil, davranışla ilgilidir.
SQL sadece rakamı çıkardığın bir kürektir.

İnsanların neden geri dönmeyi bıraktığını açıklayamıyorsan,
yüzdelerin kendi başına hiçbir şey anlatmaz 🤷‍♀️

Ürün bloğunda hiç sorun yaşadınız mı? Ürün yönünü seviyor musunuz yoksa mühendislik kısmını mı daha çok seviyorsunuz? 👇