Mobil Retention Metrikleri: D1, D7 ve D30'u Doğru Okumak

Bir mobil uygulamanın günlük aktif kullanıcı sayısı yükselirken bile retention eğrisi aşağı bakıyorsa, büyüme kalıcı değildir — yeni kullanıcı akışı kesildiği an rakamlar geri düşer. Mobil retention metrikleri, özellikle D1, D7 ve D30, bu kalıcılığı ölçmenin standart yoludur; ama App Store Connect panelinizdeki D7 rakamı ile kendi backend'inizdeki D7 rakamı neden birbirini tutmuyor sorusunun cevabı, çoğu ekibin sandığından daha teknik bir yerde saklı: kohort tanımı, sayım penceresi ve "cihaz mı hesap mı" sorusu. Bu yazıda Apple ve Google Play'in resmi tanımlarını karşılaştırarak D1/D7/D30'u doğru okumanın ve bir ürün kararına bağlamanın pratik yolunu anlatıyorum.

💡 Pro Tip: D7 retention'ını tek bir yüzde olarak rapor etmeden önce, hangi kohort penceresini (kurulum günü mü, kurulum haftası mı) kullandığını başlığa yaz — üç ay sonra kendi geçmiş verinle bile sağlıklı karşılaştırma yapamazsın.

İçindekiler

• D1, D7 ve D30 Retention Nedir?
• Retention'ın Üç Farklı Tanımı ve Hangisini Seçmelisiniz
• Kohort Penceresi ve Zaman Dilimi Tuzağı
• Yeniden Yükleme, Çoklu Cihaz ve Hesapsız Kullanıcı Sayımı
• Mağaza Paneli ile Kendi Analitiğiniz Neden Uyuşmuyor
• Kendi Kohort Tablonuzu Kurmak: SQL ve Event Şeması
• Event isimlendirme kuralları
• Retention Eğrisini Okumak: Düşüş Nerede Kırılıyor
• Eğriyi zaman içinde karşılaştırırken dikkat edilecekler
• Retention'ı Hangi Ürün Kararına Bağlamalısınız
• Ölçüm Kurulumu Kontrol Listesi
• SSS
• D1, D7 ve D30 retention nasıl hesaplanır?
• Mağaza paneliyle kendi analitiğim neden farklı gösteriyor?
• Retention'ı hangi ürün kararına bağlamalıyım?
• Apple ve Google Play retention'ı aynı şekilde mi tanımlıyor?
• Reinstall yapan bir kullanıcı D1 retention'ımı etkiler mi?
• Güncelleme (Eylül 2026)
• Sonuç
• Kaynaklar

D1, D7 ve D30 Retention Nedir?

D1, D7 ve D30 retention, aynı gün uygulamayı kuran bir kullanıcı kohortunun kurulumdan sırasıyla 1, 7 ve 30 gün sonra uygulamaya geri dönme oranını ölçer. Apple'ın resmi tanımı şöyle: "retention tells you the percentage of active devices that installed the app on the selected day and opened the app a certain number of days later" — yani retention, seçili günde kurulum yapan ve belirli gün sayısı sonra tekrar açan aktif cihazların yüzdesidir. D1 retention için tanım daha da somut: "Day 1 retention shows the percentage of active devices that opened your app 1 day after installation."

Genel formül şu şekilde yazılabilir:

1D_n retention (%) = (kurulum gününden n gün sonra uygulamayı açan cihaz sayısı / aynı gün kurulum yapan toplam cihaz sayısı) × 100

Burada kritik bir ayrıntı var: uygulamayı kurup hiç açmayan kullanıcılar bu hesabın ne payına ne paydasına girer. Apple bunu açıkça belirtiyor: "Users who install your app but never open it do not qualify, and are not counted in the numerator or the denominator of the calculation." Bu tek cümle, "kurulum sayım" ile "retention sayım"ın neden farklı paydalar üzerinden çalıştığını açıklıyor.

Retention'ın Üç Farklı Tanımı ve Hangisini Seçmelisiniz

"Retention" tek bir standart değil, en az iki resmi tanım ve bir de sizin ürününüze özgü üçüncü bir tanım var.

Apple, retention'ı cihaz bazlı ve "uygulamayı açma" eylemine dayalı ölçüyor. Google Play ise farklı bir soruya cevap veriyor: kullanıcı uygulamayı cihazında tuttu mu (açması şart değil). Play Console yardım sayfası bunu şöyle tanımlıyor: "Installers who kept your app on at least one of their devices for the number of days shown." Yani aynı kullanıcı tabanı için iki panel, iki farklı soruya cevap verdiği için iki farklı yüzde üretebilir — bu bir hata değil, tanım farkıdır.

Üçüncü seçenek, kendi ürününüzün "değerli oturum" tanımıdır — örneğin bir e-ticaret uygulamasında salt açılışı değil, sepete ürün eklemeyi ya da bir içerik uygulamasında en az bir makale okumayı "gerçek dönüş" saymak isteyebilirsiniz. Bunun resmi bir kaynağı yok; bu tamamen sizin event şemanıza bağlı bir ürün kararıdır ve mağaza panellerinin gösterdiği rakamdan kasıtlı olarak farklı çıkabilir.

Kohort Penceresi ve Zaman Dilimi Tuzağı

Apple'ın kohort tablosunda satırlar aynı anlama gelir: "Rows represent cohorts of users who installed your app on the same day." Yani her satır, o gün kurulum yapan kullanıcı grubunun zaman içindeki geri dönüş davranışını gösterir. Buraya kadar sezgisel — ama tuzak, paydanın geriye dönük büyüyebilmesinde.

Apple bunu açık bir örnekle anlatıyor: "if someone installs your app on January 1st, but doesn't open it until January 10th, then the denominator for all January 1 retention rates will increase by one on January 10…" Yani 1 Ocak kohortunun D1 retention'ı, 3 Ocak'ta baktığınızda size kesin görünse bile, 10 Ocak'ta biri gecikmeli olarak ilk kez uygulamayı açtığında o kohortun paydası büyür ve geçmiş tarihli yüzde geriye dönük değişir. Pratik sonuç: son 7-10 günün retention rakamlarını "kesin" diye raporlamayın; bu pencere hâlâ kapanmamış olabilir.

Yeniden Yükleme, Çoklu Cihaz ve Hesapsız Kullanıcı Sayımı

Apple'ın "Installations" metriği, aynı cihaza yapılan yeniden yüklemeleri, aynı Apple Hesabını paylaşan birden fazla cihaza indirmeleri ve Family Sharing kurulumlarını ayrı ayrı sayar, tekilleştirmez: "Redownloads on the same device, downloads to multiple devices sharing the same Apple Account, and Family Sharing installations are included." Bu, bir kullanıcının telefonunu değiştirip uygulamayı yeniden kurmasının bile kurulum sayınızı artırabileceği anlamına gelir — retention paydası da buna göre şişer.

Google Play tarafında mantık tersine işliyor: "Your 'Installers' data only includes unique users who installed your app for the first time" — yani Play Console'daki "Installers" verisi yalnızca gerçek ilk kurulumu sayar, yeniden yüklemeler ayrı bir kategoride raporlanır. Aynı olayı (reinstall) iki platform iki farklı şekilde metriğe dahil ediyor; D1/D7/D30 rakamlarınızı platformlar arası karşılaştırırken bu farkı hesaba katmazsanız, "Android'de retention neden daha düşük görünüyor" gibi yanlış bir soruyla baş başa kalırsınız.

Mağaza Paneli ile Kendi Analitiğiniz Neden Uyuşmuyor

Bu sorunun kök nedeni tek bir şey değil, üst üste binen dört filtre:

• Opt-in veri: Apple Analytics yalnızca veri paylaşımını kabul eden kullanıcılardan veri toplar — "Analytics in App Store Connect provides usage data collected from users who have agreed to share their data." Kendi backend'iniz muhtemelen tüm kullanıcı tabanınızı görüyor, Apple paneli ise yalnızca opt-in alt kümeyi.
• Gizlilik eşiği: Küçük kohortlarda Apple veri göstermeyebilir — "To protect user privacy, Analytics only shows data after a certain number of data points are available." Yeni bir ülkede az sayıda kurulum varsa grafik boş ya da eksik çıkabilir.
• Minimum işletim sistemi sürümü: Apple'ın çoğu metriği belirli bir minimum OS sürümünü koşul koyar: "Based on devices running a minimum of iOS 8, macOS 11, tvOS 9, or visionOS 1." Çok eski cihazlardaki kullanıcılarınız panelde görünmeyebilir.
• watchOS dışı bırakma: "Analytics doesn't include data from watchOS" — eğer watchOS companion app'iniz varsa, o kullanıcılar App Store Connect retention rakamına hiç girmez.

Kendi analitik altyapınızı Firebase üzerine kurduysanız (Firebase, "web, Apple, veya Android uygulamanızı insanların nasıl kullandığını anlamanıza" yardımcı olan genel amaçlı bir üründür ve 500 farklı olaya kadar sınırsız raporlama sunar), bu da beşinci bir filtre katmanı ekler: Firebase kendi event tanımınıza göre çalışır, mağaza paneli ise yukarıdaki dört kurala göre.

Kendi Kohort Tablonuzu Kurmak: SQL ve Event Şeması

Mağaza panellerine bağımlı kalmadan kendi retention rakamınızı hesaplamak istiyorsanız, ihtiyacınız olan asgari event şeması şudur:

1{
2  "event_name": "session_start",
3  "user_id": "anon-install-id",
4  "install_date": "2025-03-01",
5  "event_date": "2025-03-08",
6  "platform": "ios"
7}

Bu şemayı bir event tablosuna yazdıktan sonra, kohort bazlı Dn retention'ı hesaplayan genel amaçlı bir sorgu şu şekilde kurulabilir (herhangi bir veri ambarı diyaline uyarlanabilir):

1-- Kurulum kohortu başına Dn retention hesaplama
2WITH installs AS (
3  SELECT user_id, MIN(event_date) AS install_date
4  FROM app_events
5  WHERE event_name = 'first_open'
6  GROUP BY user_id
7),
8opens AS (
9  SELECT e.user_id,
10         DATE_DIFF(e.event_date, i.install_date, DAY) AS day_n
11  FROM app_events e
12  JOIN installs i USING (user_id)
13  WHERE e.event_name = 'session_start'
14)
15SELECT i.install_date,
16       COUNT(DISTINCT CASE WHEN o.day_n = 1 THEN o.user_id END) * 1.0
17         / COUNT(DISTINCT i.user_id) AS d1_retention,
18       COUNT(DISTINCT CASE WHEN o.day_n = 7 THEN o.user_id END) * 1.0
19         / COUNT(DISTINCT i.user_id) AS d7_retention
20FROM installs i
21LEFT JOIN opens o USING (user_id)
22GROUP BY i.install_date;

Aşağıdaki tablo gerçek bir uygulamanın verisi değildir, yalnızca yukarıdaki sorgunun ürettiği çıktının nasıl okunacağını göstermek için varsayımsal bir örnek kohorttur:

Bu örnekte 1 Mart kohortunda D1 retention %38, D7 retention %21, D30 retention %9 olarak hesaplanır (kurulum başına açan kullanıcı sayısının kurulum sayısına bölünmesiyle). Kendi verinizde bu üç rakamı yan yana görmek, eğrinin nerede kırıldığını anlamanın ilk adımıdır.

Event isimlendirme kuralları

Kendi kohort altyapınızı kurarken en sık yapılan hata, "app_open" olayını birden fazla anlamda kullanmaktır: hem uygulama ön plana geldiğinde hem de belirli bir ekran açıldığında aynı event'i loglarsanız, D1/D7/D30 sorgunuz gerçekte olduğundan daha yüksek bir retention üretir. İki ayrı event tutmanızı öneririm: session_start (uygulama ön plana her geldiğinde, arka plandan dönüşler dahil) ve first_open (yalnızca kurulumdan sonraki ilk açılış). Retention hesabınızda session_start kullanın, first_open yalnızca kohortun başlangıç tarihini belirlemek için gereklidir — ikisini karıştırırsanız kohort tablonuzun paydası yanlış kurulum tarihine göre gruplanır.

Retention Eğrisini Okumak: Düşüş Nerede Kırılıyor

Retention eğrisini okurken ben genelde iki noktaya bakarım: ilk düşüşün ne kadar dik olduğu ve eğrinin nerede düzleşmeye başladığı. D1'den D7'ye sert bir düşüş genelde onboarding'de bir sürtünme noktası olduğuna işaret eder — kullanıcı uygulamayı bir kez açmış ama değer önerisini anlamadan ayrılmış demektir. D7'den D30'a doğru eğrinin yatay bir çizgiye yaklaşması ise genelde "kalıcı kullanıcı tabanınızın" büyüklüğünü gösterir; bu noktadan sonra kalan kullanıcılar artık alışkanlık haline getirmiş kullanıcılardır ve düşüş hızı yavaşlar.

Kohort penceresi tuzağını (bir önceki bölümde anlattığım geriye dönük payda büyümesini) hesaba katmadan son birkaç günün eğrisini yorumlamayın — o veri henüz "kapanmamış" olabilir.

Eğriyi zaman içinde karşılaştırırken dikkat edilecekler

Aynı kohort penceresini kullansanız bile, eğriyi ay-ay ya da sürüm-sürüm karşılaştırırken iki şeyi sabit tutmanız gerekir: veri kaynağı (mağaza paneli mi kendi backend'iniz mi) ve platform karışımı (iOS/Android oranı değiştiyse, birleşik retention rakamı da kayar çünkü iki platformun az önce anlattığım reinstall/tekilleştirme kuralları farklı). Bir sürüm güncellemesinden sonra D1 retention'da ani bir sıçrama görürseniz, önce "gerçekten mi onboarding iyileşti" diye sormadan önce ölçüm tarafında bir şey değişip değişmediğini (yeni bir event, farklı bir SDK sürümü, kohort tanımında bir kayma) kontrol et — ölçüm değişikliği, ürün değişikliğinden çok daha sık yanlış pozitif üretir.

Retention'ı Hangi Ürün Kararına Bağlamalısınız

Üç rakamı ayrı ayrı takip etmenin asıl amacı, her birini farklı bir ürün kararına bağlamaktır. D1 düşükse genelde sorun onboarding akışındadır — ilk açılışta kullanıcıya değeri ne kadar hızlı gösterdiğinize bakın. D7 düşükse alışkanlık döngüsü (habit loop) ve bildirim/e-posta stratejinizi gözden geçirmenin zamanıdır. D30 ise genellikle monetizasyon zamanlamasıyla ilişkilidir: bir abonelik modeliniz varsa deneme süresinin bitişi genellikle bu pencereye denk gelir, bu yüzden fiyatlandırma ve deneme süresi kararlarınızı D30 verinizle birlikte değerlendirmek mantıklıdır.

Ölçüm Kurulumu Kontrol Listesi

Bu makalede geçen kuralları tek bir kontrol listesine indirgeyecek olursam:

• Kohort penceresini sabitleyin: gün mü hafta mı kullandığınızı raporun başlığına yazın.
• Veri kaynağını belirtin: mağaza paneli mi kendi backend'iniz mi, ikisi farklı payda kullanır.
• Reinstall/çoklu cihaz kuralını netleştirin: Apple tekilleştirmez, Google Play ilk kurulumu ayırır — platformlar arası karşılaştırmada bunu telafi edin.
• Opt-in ve gizlilik eşiğini hatırlayın: küçük kohortlarda mağaza paneli veri eksik gösterebilir.
• Minimum OS sürümü filtresini kontrol edin: eski cihaz kullanıcılarınız panelde görünmeyebilir.
• Son günlerin verisini "kesin" saymayın: kohort penceresi geriye dönük büyüyebilir.
• Her rakamı bir ürün kararına bağlayın: D1→onboarding, D7→alışkanlık döngüsü, D30→monetizasyon zamanlaması.
• Event isimlerini ayırın: session_start ile first_open'ı aynı olayda birleştirmeyin, aksi halde kohort paydanız yanlış kurulum tarihine göre gruplanır.
• Platform karışımının etkisini izole edin: iOS/Android oranı değiştiğinde birleşik retention rakamınızın da kaymasını bekleyin, bunu ürün değişikliği sanmayın.

Bu listeyi bir sonraki raporunuzdan önce gözden geçirmek isterseniz, yazının sonundaki "Okuyucu Ödülü" bölümünde aynı kontrol listesinin işaretlenebilir hâlini bulabilirsiniz.

SSS

D1, D7 ve D30 retention nasıl hesaplanır?

D1, D7 ve D30 retention, aynı gün kurulum yapan kullanıcı kohortunun kurulumdan sırasıyla 1, 7 ve 30 gün sonra uygulamaya geri dönme yüzdesidir. Apple'ın tanımına göre bu, seçili günde kurulum yapan ve belirli gün sayısı sonra uygulamayı açan aktif cihazların yüzdesidir; hiç açmayan kullanıcılar hesaba dahil edilmez.

Mağaza paneliyle kendi analitiğim neden farklı gösteriyor?

Dört filtre üst üste biniyor: Apple Analytics yalnızca opt-in kullanıcıları görür, küçük kohortlarda gizlilik eşiği yüzünden veri eksik gösterebilir, çoğu metrik minimum bir OS sürümü koşulu taşır ve watchOS verisi dahil değildir. Kendi backend'iniz muhtemelen bu filtrelerin hiçbirine tabi olmadan tüm kullanıcı tabanınızı görür.

Retention'ı hangi ürün kararına bağlamalıyım?

D1'i onboarding akışına, D7'yi alışkanlık döngüsü ve bildirim stratejinize, D30'u ise genellikle monetizasyon ve abonelik zamanlamasına bağlamak pratik bir yaklaşımdır. Her rakamı ayrı bir soruya cevap verdiği için ayrı bir aksiyon planına bağlamak, tek bir "genel retention" hedefinden daha faydalıdır.

Apple ve Google Play retention'ı aynı şekilde mi tanımlıyor?

Hayır. Apple, uygulamayı fiilen "açma" eylemine dayalı cihaz bazlı bir tanım kullanır. Google Play Console ise kullanıcının uygulamayı cihazında "tutup tutmadığına" bakar, açması şart değildir. Aynı kullanıcı tabanı için bu iki tanım farklı yüzdeler üretebilir.

Reinstall yapan bir kullanıcı D1 retention'ımı etkiler mi?

Platforma göre değişir. Apple'ın Installations metriği aynı cihaza yapılan yeniden yüklemeleri ve çoklu cihaz kurulumlarını tekilleştirmeden sayar, bu da paydanızı şişirebilir. Google Play Console'da ise "Installers" verisi yalnızca gerçek ilk kurulumu sayar, yeniden yüklemeler ayrı raporlanır.

Güncelleme (Eylül 2026)

Bu makale ilk kez 12 Mart 2025'te yayımlandı. Aradan geçen ~18,5 ayda D1/D7/D30 retention'ın tanımı aslında değişmedi, ama ölçüm altyapısı ve kıyaslama verisi önemli ölçüde değişti.

1) Apple, App Store Connect Analytics'i 25 Mart 2026'da köklü şekilde güncelledi. 100'den fazla yeni metrik eklendi; en kritik değişiklik cohort analizinin native olarak gelmesi: indirme tarihi, indirme kaynağı ve teklif (offer) başlangıç tarihine göre kullanıcı davranışını zaman içinde izlemek artık üçüncü parti araç gerektirmiyor. Kaynak: MacRumors, 25 Mart 2026.

2) Apple'ın resmi retention tanımı hâlâ "hesap" değil "aktif cihaz" bazlı. Bu, "mağaza paneliyle kendi analitiğim neden farklı" sorusunun köküne değiyor: Apple cihaz sayıyor, çoğu üçüncü parti analitik kullanıcı/pseudo-ID sayıyor.

3) Google, Android tarafında planladığı Privacy Sandbox altyapısını 17 Ekim 2025'te büyük ölçüde rafa kaldırdı. Attribution Reporting API, Protected Audience, Protected App Signals ve Topics API emekliye ayrıldı. Kaynak: Privacy Sandbox resmi blog.

4) Apple'ın AdAttributionKit'i artık re-engagement (yeniden-etkileşim/redownload) ölçümü ekliyor. SKAdNetwork deprecate edilmedi, iki çerçeve 2026'da birlikte çalışıyor. Kaynak: Admiral Media, 2026.

5) iOS 26 ile (Eylül 2025) Safari'de "Advanced Fingerprinting Protection" tüm gezinme modlarında varsayılan oldu. Bu doğrudan D1/D7/D30 tanımını değiştirmiyor ama web-to-app attribution zincirlerinin gürültüsünü artırıyor. Kaynak: Apple Newsroom, Haziran 2025.

6) App Tracking Transparency (ATT) opt-in oranı 5. yılında yaklaşık %38'e yükseldi ve her yıl kademeli artıyor. Kaynak: SignalSeal, 2026.

Özetle değişen: Apple'ın cohort analiz derinliği, AdAttributionKit'in re-engagement ölçümü, Android'de dört Privacy Sandbox API'sinin emekliye ayrılması, ATT opt-in oranının artışı. Değişmeyen: D1/D7/D30'un temel tanımı, Apple'ın cihaz-bazlı sayımı, reinstall'ın ayrı metrik olması.

Sonradan yayımlanan ilgili yazılar:

• StoreKit 2 abonelik rehberi
• App Store Connect'te abonelik teklif kodları
• Google Play Billing v7 rehberi
• iOS App Store'da 1 milyon dolarlık gerçek strateji

Sonuç

D1, D7 ve D30 retention'ı doğru okumanın anahtarı, tek bir "doğru" tanım aramak değil, hangi kaynağın hangi soruya cevap verdiğini bilmektir: Apple cihazın açılıp açılmadığını, Google Play cihazda tutulup tutulmadığını sorar, siz ise kendi ürününüze özgü "değerli oturum" tanımını seçersiniz. Kohort penceresinin geriye dönük büyüyebileceğini unutmadan, her rakamı ayrı bir ürün kararına (D1→onboarding, D7→alışkanlık döngüsü, D30→monetizasyon) bağlayın.

Kaynaklar

• Apple — App Retention (App Store Connect Analytics) — D1/D7/D30 retention'ın resmi tanımı, kohort penceresi davranışı ve "hiç açmayan kullanıcı sayılmaz" kuralı.
• Apple — Metrics Definitions (App Store Connect Analytics) — Installations, Active Devices ve minimum OS sürümü şartlarının resmi tanımları.
• Apple — Analytics Dashboard Overview — Opt-in veri toplama, gizlilik eşiği ve watchOS hariç tutma kuralları.
• Google Play Console Yardım — Retention Raporu — Google Play'in "installers who kept your app" tanımı ve ilk kurulum/yeniden yükleme ayrımı.
• Privacy Sandbox — Update on Plans for Privacy Sandbox Technologies — Android'de Attribution Reporting API, Protected Audience, Protected App Signals ve Topics API'nin emekliye ayrılma duyurusu.
• Firebase — Google Analytics for Firebase Dokümantasyonu — Firebase Analytics'in genel ürün kapsamı ve olay raporlama limitleri.
• MacRumors — App Store Connect Receives New Metrics (25 Mart 2026) — Apple'ın 2026 cohort analizi güncellemesinin haber teyidi.
• Apple Newsroom — Apple Elevates the iPhone Experience with iOS 26 (Haziran 2025) — Safari'de Advanced Fingerprinting Protection'ın tüm gezinme modlarına varsayılan olarak genişletildiğinin resmi duyurusu.
• Admiral Media — AdAttributionKit iOS Measurement Playbook — AdAttributionKit'in re-engagement ölçüm yeteneği üzerine teknik özet.
• SignalSeal — ATT Five Years On — App Tracking Transparency opt-in oranının 2026 itibarıyla seyri.