Mobil Uygulama Analitiği: Ölçülmesi Gereken 10 Metrik

Mobil uygulama analitiği, kullanıcıların uygulamanızı nasıl kullandığını, nerede bıraktığını ve ne kadar gelir getirdiğini olay (event) verisiyle ölçme işidir. Uygulamanın gerçek sağlığını indirme sayısı değil; aktivasyon, D1/D7/D30 retention, churn, DAU/MAU, huni dönüşümü, crash-free oranı, LTV ve CAC gösterir.

Tablo sert: Adjust'ın 2026 Mobile App Trends raporuna göre tüm platform ve kategorilerde ortalama retention 1. günde %26, 7. günde %13, 30. günde %7 seviyesine iniyor. Yani her 100 yeni kullanıcıdan yalnızca 7'si bir ay sonra uygulamayı yeniden açıyor. Bu kaybın hangi adımda başladığını görmeyen ekip, sorunu reklam bütçesiyle kapatmaya çalışır.

Türkiye'de konu bir adım daha kritik. StatCounter verisine göre Ağustos 2026'da Türkiye'deki mobil cihazların %73,77'si Android, %26,22'si iOS kullanıyor. Adjust verisinde Android'in 30. gün retention oranı (%6) iOS'un (%8) gerisinde kaldığı için, Türkiye pazarında mobil uygulama analitiği kurarken Android tarafını ayrıca izlemeniz gerekir.

Bu rehberde 10 metriği tek tabloda, formülü ve referans değeriyle bulacaksınız. Ardından Firebase kurulum mantığını, KVKK ve ATT tarafını ve veriyle alınan 4 ürün kararını adım adım işliyoruz.

Bu rehberde neler var?

• Neden indirme sayısı yetmez?
• 10 metrik tek tabloda: anlamı ve sağlıklı aralık
• Elde tutma metrikleri: aktivasyon, retention ve churn
• Etkileşim ve kalite metrikleri
• Gelir metrikleri: LTV ve CAC
• Firebase Analytics kurulum mantığı
• Gizlilik: KVKK, ATT ve mağaza beyanları
• Veriyle ürün kararı: 4 örnek senaryo
• Sıkça Sorulan Sorular

Neden indirme sayısı yetmez?

İndirme sayısı mağaza sayfanızın performansını ölçer, uygulamanın performansını ölçmez. ASO rehberimizde anlattığımız gibi mağaza dönüşümünü artırmak mümkündür. Ancak indiren kişi ilk oturumda değer görmezse o indirme hiçbir zaman gelire dönüşmez.

Analitik araçları da bu ayrımı baştan yapar. Google'ın otomatik toplanan olaylar listesine göre first_open olayı indirme anında değil, kullanıcı uygulamayı yükledikten sonra ilk kez açtığında tetiklenir. Android'de app_remove olayı ise uygulamanın cihazdan kaldırıldığı anı kaydeder. İndirme ile kullanım arasındaki fark, bu iki olayın arasında saklıdır.

Sağlıklı bir mobil uygulama analitiği sistemi metrikleri üç katmanda toplar:

• Sonuç metrikleri: Gelir, LTV ve LTV:CAC oranı. Yönetimin "bu uygulama para kazandırıyor mu?" sorusunu cevaplar.
• Ürün metrikleri: Aktivasyon, retention ve DAU/MAU. Ürünün alışkanlık yaratıp yaratmadığını gösterir.
• Teşhis metrikleri: Huni adımları, crash ve ANR oranı. "Neden?" sorusunun cevabını verir.

Tek başına bakılan metrik yanıltır. DAU artarken D30 retention düşüyorsa büyümeyi ürün değil reklam taşıyordur. Tersi durumda ürün sağlamdır ama edinme kanalınız zayıftır.

10 metrik tek tabloda: anlamı ve sağlıklı aralık

Aşağıdaki tablo, mobil uygulama analitiği sürecinde izlemeniz gereken 10 metriği tek bakışta özetler. Referans sütunundaki değerler kaynaklı genel ortalamalardır; kendi kategorinizde farklı sonuç almanız normaldir.

Referans değerleri hedef değil, pusula olarak kullanın. Apple, App Store Connect içinde benzer uygulama grubu karşılaştırmaları sunar. Uygulamanız kategori, iş modeli ve indirme hacmine göre bir gruba yerleşir. Ardından D1, D7 ve D28 retention, dönüşüm oranı ve crash oranında grubun 25., 50. ve 75. yüzdelik değerleriyle kıyaslanır.

Apple bu verileri korumak için diferansiyel gizlilik kullanır ve her veri noktasına bir miktar gürültü ekler. Yine de genel pazar ortalaması yerine kendi kategorinizdeki bu kıyası esas almak çok daha isabetli bir tablo verir.

Elde tutma metrikleri: aktivasyon, retention ve churn

Elde tutma, mobil uygulama analitiği içinde en çok karar üreten metrik grubudur. Kullanıcıyı tutamayan uygulamada edinme harcaması, delik kovaya su doldurmaya dönüşür.

1. Aktivasyon oranı

Aktivasyon, yeni kullanıcının uygulamanın vaat ettiği değeri ilk kez yaşadığı andır. Yemek siparişi uygulamasında bu ilk siparişin verilmesidir. Fitness uygulamasında ilk antrenmanın tamamlanması, randevu uygulamasında ilk randevunun onaylanmasıdır.

Formül basittir: aktivasyon olayını tamamlayan kullanıcı sayısını aynı dönemdeki yeni kullanıcı sayısına bölersiniz. Zor olan kısım doğru olayı seçmektir. "Kayıt oldu" genellikle aktivasyon değildir; kullanıcı henüz değeri görmemiştir.

Aktivasyonun önemi veride net görünür. Amplitude'un 2.600'ü aşkın şirketi kapsayan 2025 Product Benchmark Report çalışmasına göre 7. gün performansında en iyi grupta yer alan ürünlerin %69'u, 3. ay retention'da da en iyi gruptaydı. Aynı rapor, ilk kohortun en az %7'sini 7. günde geri getiren ürünlerin aktivasyonda ilk %25'e girdiğini belirtiyor.

Pratik öneriler:

• Kayıt ile değer anı arasındaki adım sayısını sayın ve her gereksiz adımı sorgulayın.
• "Değere ulaşma süresini" (time to value) dakika cinsinden ölçün.
• MVP aşamasında doğrulamanız gereken ilk sinyali aktivasyon olarak belirleyin.

2–4. D1, D7 ve D30 retention

Retention, belirli bir günde uygulamayı ilk kez açan kullanıcı grubunun (kohort) N gün sonra ne kadarının geri geldiğini gösterir. Üç kontrol noktası farklı soruları cevaplar:

• D1 retention: İlk oturum yeterince iyi miydi? Onboarding ve ilk deneyimin karnesidir.
• D7 retention: Uygulama bir alışkanlığa dönüşmeye başladı mı? Bildirim, içerik ve tekrar kullanım nedenlerini ölçer.
• D30 retention: Ürün kalıcı bir ihtiyacı karşılıyor mu? Ürün-pazar uyumuna en yakın sinyaldir.

Örnek bir hesapla somutlaştıralım. 1 Eylül'de 2.000 kişi uygulamayı ilk kez açtı. 2 Eylül'de 480'i, 8 Eylül'de 220'si, 1 Ekim'de 110'u geri geldi. Bu kohortun D1 retention oranı %24, D7 oranı %11, D30 oranı %5,5 olur.

Adjust 2026 verisiyle kıyaslarsak bu örnek uygulama üç noktada da ortalamanın altında kalıyor. İlk düzeltilecek yer D1'dir, çünkü ilk günü kaybedilen kullanıcı 7. güne hiç ulaşmaz.

Retention hesaplarken üç tuzağa dikkat edin:

1. Tanımı sabitleyin. Klasik retention yalnızca tam N. günde gelenleri sayar; "rolling" retention o gün veya sonrasında gelen herkesi sayar. Farklı tanımları karşılaştırmak yanlış sonuç verir.
2. Araçları karıştırmayın. Apple, D30 yerine D28 kullanır ve kohortu haftalık kurar. Firebase ile App Store Connect rakamlarını birebir eşleştirmeye çalışmayın.
3. Kohortu bölün. Platform, edinme kanalı ve uygulama sürümüne göre ayrılmamış bir retention eğrisi, sorunun kaynağını gizler.

Eğrinin şekli de önemlidir. Retention eğrisi bir noktadan sonra yataylaşıyorsa uygulamanın sadık bir çekirdek kitlesi vardır. Eğri sıfıra doğru inmeye devam ediyorsa ürün henüz kalıcı bir ihtiyaca oturmamıştır.

5. Churn oranı

Churn, kaybettiğiniz kullanıcı veya abone oranıdır ve iki farklı bağlamda hesaplanır.

Abonelik olmayan uygulamalarda churn için bir hareketsizlik penceresi tanımlarsınız. Örneğin "30 gün boyunca hiç oturum açmayan kullanıcı kaybedilmiş sayılır" kuralı koyabilirsiniz. Bu durumda churn, aynı kohortun retention oranının tamamlayıcısıdır.

Abonelik uygulamalarında churn, dönem içinde iptal eden veya yenilemeyen abonelerin dönem başındaki aktif abonelere oranıdır. RevenueCat'in 115.000'i aşkın uygulamayı kapsayan State of Subscription Apps 2026 raporu bu tarafta çarpıcı veriler sunuyor:

• Yıllık abonelerin 1 yıl sonra yalnızca %27'si (sert ödeme duvarı) ile %28'i (freemium) aktif kalıyor.
• Yıllık planlardaki iptallerin %35'i ilk ayda gerçekleşiyor.
• Google Play'deki iptallerin %31'i istemsiz, yani ödeme başarısızlığından kaynaklanıyor. App Store'da bu oran %14.

Son madde Türkiye için özellikle önemlidir, çünkü kullanıcıların büyük çoğunluğu Android'de. Kart limiti dolduğunda veya sanal kartın süresi bittiğinde yenileme ödemesi başarısız olur. Google Play Billing'in ödemeyi yeniden deneme özelliklerini açmak ve kullanıcıya uygulama içinde "ödeme yönteminizi güncelleyin" mesajı göstermek, kullanıcının aslında bırakmak istemediği aboneliği kurtarır. Gelir modeli seçimini mobil uygulamadan para kazanma rehberimizde ayrıntılı ele aldık.

Etkileşim ve kalite metrikleri

Mobil uygulama analitiğinde retention, kullanıcının geri gelip gelmediğini gösterir. Etkileşim ve kalite metrikleri ise ne sıklıkla geldiğini, akışın neresinde takıldığını ve uygulamanın teknik olarak ne kadar güvenilir olduğunu gösterir.

6. DAU/MAU oranı (stickiness)

DAU/MAU, günlük aktif kullanıcı sayısının aylık aktif kullanıcı sayısına oranıdır. 0,20 oranı, aylık kullanıcının ortalama olarak ayın yaklaşık 6 gününde uygulamayı açtığı anlamına gelir.

Bu oran kategoriye göre çok değişir. Mixpanel'in 12.000'i aşkın şirketin verisine dayanan State of Digital Analytics 2026 raporunda EMEA bölgesindeki e-ticaret ürünleri için DAU/MAU %21, EMEA mobil oyunları için %31 olarak geçiyor. Mesajlaşma uygulaması ile sigorta uygulamasını aynı hedefe koymak anlamsızdır.

İki uyarı:

• Her uygulama günlük kullanılmaz. Fatura, kiralama veya randevu uygulamalarında WAU/MAU (haftalık/aylık) daha dürüst bir ölçüdür.
• "Aktif" tanımını netleştirin. Firebase'in user_engagement olayı, uygulama en az 1 saniye ön plandayken tetiklenir. Kullanıcıyı bildirimle bir saniyeliğine uygulamaya sokmak DAU'yu şişirir ama değer üretmez. Bu tuzağı push bildirim stratejisi yazımızda ayrıntılı işledik.

7. Huni dönüşüm oranı

Huni (funnel), kritik bir akışın adımlarını sırayla ölçer ve kullanıcının hangi adımda kaybolduğunu gösterir. Onboarding, ödeme ve abonelik akışları için ayrı huniler kurmanız gerekir.

Temsili bir randevu uygulamasının onboarding hunisi şöyle olabilir:

Bu örnekte toplam dönüşüm %16'dır. En büyük kayıp SMS doğrulama adımında (720'den 430'a) ve ilk randevu adımında görülüyor. Ekip önce bu iki adıma odaklanmalıdır; profil adımını iyileştirmek neredeyse hiçbir şey kazandırmaz.

E-ticaret akışında referans olarak Baymard Institute'un 50 çalışmayı derleyen verisine bakabilirsiniz: ortalama sepet terk oranı %70,22. Huni analizinde adımlar arası zaman penceresini (örneğin 24 saat) sabit tutun ve sonuçları platform ile cihaz modeline göre bölün.

8. Crash-free kullanıcı ve ANR oranı

Çöken bir uygulama, diğer tüm metrikleri aşağı çeker. Firebase Crashlytics crash-free metriklerini şöyle tanımlar: crash-free kullanıcı oranı = 1 − (çökme yaşayan tekil kullanıcı ÷ uygulamayı kullanan tüm kullanıcılar). Aynı mantık oturum bazında da hesaplanır.

Google Play bu konuda somut eşikler koyar. Android vitals dokümanına göre kötü davranış eşikleri şunlardır:

• Kullanıcının algıladığı çökme oranı: Tüm cihazlarda günlük kullanıcıların %1,09'u veya daha fazlası; tek bir telefon modelinde %8.
• Kullanıcının algıladığı ANR oranı: Tüm cihazlarda %0,47 veya daha fazlası; tek bir telefon modelinde %8.
• Değerlendirme penceresi: Play, son 28 günün verisine bakar.

Eşiği aşan uygulamanın Google Play'deki görünürlüğü düşebilir ve mağaza sayfasında kullanıcılara uyarı gösterilebilir. Aynı dokümana göre bellek kullanımı ihlallerinin mağaza görünürlüğüne etkisi Şubat 2027'de başlayabilir.

Android'in Türkiye'deki payı düşünüldüğünde bu eşikler doğrudan indirme ve gelir meselesidir. Crashlytics'teki günlük crash-free kullanıcı oranınız %98,9'un altına iniyorsa Play eşiğine yaklaşıyorsunuz demektir; iki metrik de günlük kullanıcıların ne kadarının çökme yaşadığına bakar. Stabilite işinin yayın sonrası bütçedeki yerini mobil uygulama bakım maliyeti rehberimizde anlattık.

Gelir metrikleri: LTV ve CAC

Mobil uygulama analitiği listesindeki son iki metrik, ürün metriklerini paraya çevirir. Retention ne kadar iyi olursa olsun, kullanıcı başına gelir edinme maliyetini karşılamıyorsa büyüme sürdürülemez.

9. LTV (yaşam boyu değer)

LTV, bir kullanıcının uygulamayla ilişkisi boyunca getirdiği toplam gelirdir. En basit formül şudur: LTV = ARPU × ortalama kullanıcı ömrü. Ortalama ömrü de aylık churn oranının tersiyle (1 ÷ aylık churn) tahmin edersiniz.

Örnek hesap: Kullanıcı başına aylık gelir (ARPU) 45 TL, aylık churn %9 olsun. Ortalama ömür 1 ÷ 0,09 ≈ 11,1 ay olur. LTV ≈ 45 × 11,1 ≈ 500 TL çıkar. Bu brüt değerdir; mağaza komisyonu, ödeme altyapısı ve sunucu maliyeti düşüldüğünde net katkı daha düşüktür.

Formül hızlı bir tahmin verir ama gerçekçi değeri kohort bazlı "gerçekleşen LTV" gösterir. Her ay edinilen kullanıcı grubunun 30, 90 ve 180. günlerde toplam ne kadar gelir getirdiğini izleyin. Apple'ın benzer grup karşılaştırmaları da bu mantıkla 35. gün indirme-ücretli dönüşüm oranını ve 35. gün indirme başına geliri raporlar.

10. CAC ve LTV:CAC oranı

CAC (müşteri edinme maliyeti), belirli bir dönemdeki edinme harcamasının aynı dönemde kazanılan yeni kullanıcı sayısına bölünmesiyle bulunur. Reklam harcamasını yalnızca ücretli kullanıcılara bölerseniz "ücretli CAC", organik kullanıcıları da dahil ederseniz "harmanlanmış CAC" elde edersiniz.

LTV:CAC oranı için yaygın başparmak kuralı en az 3:1'dir. Önceki örnekte LTV 500 TL ise, kullanıcı başına 165 TL'nin üzerindeki edinme maliyeti bu kuralı bozar. Oran 1'in altındaysa her yeni kullanıcı şirkete para kaybettirir.

iOS tarafında kanal bazlı CAC ölçümü daha zordur. App Tracking Transparency izni vermeyen kullanıcılarda reklam atıfı toplu ve gecikmeli gelir. Bu yüzden kampanyaları tekil kullanıcı yerine kanal ve kohort düzeyinde, daha uzun bir pencerede değerlendirin. Reklam kanalı tarafını Google Ads hizmetimizde uygulama kampanyalarıyla birlikte planlıyoruz.

Firebase Analytics kurulum mantığı

Firebase Analytics, SDK eklendiği anda oturum, ilk açılış ve ekran görüntüleme gibi olayları otomatik toplamaya başlar. Ancak mobil uygulama analitiği işinin asıl değeri, bu otomatik veriye değil, sizin tasarladığınız ölçüm planına dayanır.

Önce hangi aracın neyi ölçtüğünü netleştirelim:

Küçük ve orta ölçekli uygulamaların çoğu için Firebase Analytics, Crashlytics ve mağaza konsolları üçlüsü yeterli bir başlangıçtır. Kurulumu şu sırayla yapın:

1. Adım: Soruyla başlayın. "Kayıt olan kullanıcı ilk randevusunu oluşturuyor mu?" gibi 3–5 iş sorusu yazın. Her olay en az bir soruya hizmet etmelidir; hiçbir soruya bağlanmayan olay veri çöplüğü üretir.

2. Adım: Ölçüm planı (tracking plan) çıkarın. Her olayın adı, tetiklendiği an, parametreleri ve sorumlusu tek bir tabloda durmalıdır:

3. Adım: Limitleri baştan bilin. Google'ın olay toplama limitlerine göre uygulama veri akışında 500 farklı olay adı, olay başına 25 parametre ve mülk başına 25 kullanıcı özelliği sınırı vardır. Olay adı en fazla 40, kullanıcı özelliği adı 24, değeri 36 karakter olabilir. snake_case adlandırma kuralını ekip standardı yapın.

4. Adım: Kişisel veri göndermeyin. E-posta, telefon numarası veya T.C. kimlik numarasını olay parametresi ya da kullanıcı özelliği olarak göndermeyin. Kullanıcıyı eşleştirmek için veritabanınızdaki rastgele bir iç kimliği kullanın.

5. Adım: DebugView ile doğrulayın. Test cihazında olayların doğru sırayla ve doğru parametreyle geldiğini kontrol edin. Bu kontrolü sürüm öncesi test listenize ekleyin; uygulama yayın kontrol listesi aracımız bu adımları yayından önce gözden geçirmenize yardımcı olur.

6. Adım: Veri saklama süresini ve BigQuery bağlantısını ayarlayın. Google Analytics veri saklama ayarı keşif ve huni raporlarını doğrudan etkiler. 2 ay seçili kalırsa 3 aylık bir kohort analizi yapamazsınız; standart mülklerde süreyi en az 14 aya çıkarın. BigQuery'ye günlük dışa aktarım standart mülklerde günde 1 milyon olayla sınırlıdır.

7. Adım: Crashlytics'i aynı sürümde açın. Analitik ile crash verisini aynı sürümden itibaren toplamak, "D7 neden düştü?" sorusuna sürüm bazında cevap vermenizi sağlar.

8. Adım: Haftalık bir inceleme ritmi kurun. Veri, ancak biri düzenli olarak baktığında işe yarar. Her hafta 30 dakikalık bir mobil uygulama analitiği toplantısı yapın: son kohortların D1 ve D7 oranlarını, en yeni sürümün crash-free oranını ve ana huninizdeki en büyük kaybı kontrol edin. Her ürün değişikliğini yayın tarihiyle ve etkilemesini beklediğiniz metrikle birlikte kayda geçirin. Birkaç ay sonra bu kayıt, kararları sonuçlara bağladığı için ekibinizin en değerli analitik varlığına dönüşür. Toplantıyı kısa tutun ve tek bir karar, tek bir sorumlu ve gelecek hafta izlenecek tek bir metrikle bitirin.

Analitik, crash raporlama ve yönetim paneli gibi kalemlerin projeye etkisini görmek isterseniz mobil uygulama maliyet hesaplayıcımızı kullanabilirsiniz.

Gizlilik: KVKK, ATT ve mağaza beyanları

Mobil uygulama analitiği verisi kişisel veri içerebilir. Bu yüzden kurulumun hukuki ve mağaza politikası tarafı, teknik taraf kadar önemlidir.

KVKK tarafı. Kişisel Verileri Koruma Kurumu'nun Çerez Uygulamaları Hakkında Rehberi, masaüstü ve mobil web siteleri ile web uygulamalarını kapsar. Rehber piksel, local storage ve parmak izi gibi benzer teknolojiler için ayrıca yönlendirme yapmaz. Bu nedenle native uygulama SDK'larını doğrudan düzenlemez, ama mantığı yol göstericidir.

Rehbere göre birinci taraf analitik; yalnızca hedef kitle ölçümü ve teknik iyileştirme amacıyla, anonim istatistik üreterek ve siteler ya da uygulamalar arası çapraz takip yapmadan kullanılırsa açık rıza gerektirmeyen kapsamda değerlendirilebilir. Rehber ayrıca makul veri ömrünü ve verinin üçüncü taraflara iletilmemesini alınacak tedbirler arasında sayar. Firebase gibi üçüncü taraf SDK'lar ise veriyi sağlayıcının sunucularına iletir. Bu durumda rıza muafiyeti tartışmalı hale gelir ve yurt dışına aktarım kuralları da devreye girer.

Pratik yaklaşım şudur: Analitik ve reklam amaçlı izinleri ayrı sorun, Google'ın uygulamalar için consent mode yapısıyla varsayılan izin durumunu tanımlayın ve kullanıcının tercihine göre setConsent ile güncelleyin. Metinleri hukuk danışmanınızla birlikte netleştirin. Uygulama güvenliği ve KVKK uyumunun tamamını mobil uygulama güvenliği rehberimizde ele aldık.

ATT tarafı. Apple'ın kullanıcı gizliliği sayfasına göre "takip", uygulamanızdan toplanan kullanıcı verisini hedefli reklam veya reklam ölçümü için başka şirketlerin verisiyle birleştirmek ya da veri simsarlarıyla paylaşmaktır. Uygulamanızın kendi kullanımını ölçen ve veriyi başka şirketlerin verisiyle birleştirmeyen analitik bu tanıma girmez. Aynı sayfa, bir özelliği takip iznine bağlamanın 5.1.2(i) kuralı gereği yasak olduğunu açıkça belirtir.

Mağaza beyanları. Google Play'in Veri güvenliği bölümü, uygulamanızdaki SDK'ların topladığı veriyi sizin topladığınız veri gibi beyan etmenizi ister. App Store'daki gizlilik etiketleri için de aynı dikkat gerekir. Analitik SDK'sı eklediğiniz her sürümde bu beyanları güncelleyin.

Veriyle ürün kararı: 4 örnek senaryo

Mobil uygulama analitiği ancak karara dönüştüğünde değer üretir. Aşağıdaki senaryolar temsilidir; her biri bir sinyalden karara ve doğrulamaya giden yolu gösterir.

Senaryo 1 — Ankara'da bir kuaför randevu uygulaması, SMS adımında kayıp. Onboarding hunisinde en büyük düşüş SMS doğrulama adımında çıkıyor. Kırılım, kaybın eski Android cihazlarda ve akşam saatlerinde yoğunlaştığını gösteriyor. Ekip Google ve Apple ile giriş seçeneği ekliyor, kullanıcıya randevu adımına kadar misafir olarak gezinme izni veriyor. Doğrulama için değişiklik sonrası iki haftanın kohortu, önceki iki haftanın aktivasyon ve D7 oranlarıyla karşılaştırılıyor.

Senaryo 2 — Yeni sürümden sonra D7 düşüşü. Retention kohortları sürüme göre bölündüğünde düşüşün yalnızca son sürümde başladığı görülüyor. Crashlytics, çökmelerin tek bir Android telefon modelinde yoğunlaştığını gösteriyor. Google Play'in model başına %8 eşiği riske girdiği için ekip yeni özellik geliştirmeyi durdurup düzeltme sürümünü kademeli yayınla çıkarıyor. Başarı ölçütü, o modeldeki crash-free kullanıcı oranının önceki sürüm seviyesine dönmesi.

Senaryo 3 — Düşük DAU/MAU, sağlam D30. Bir fatura takip uygulamasında DAU/MAU düşük görünüyor ama D30 retention kategori ortalamasının üzerinde. Kullanıcılar uygulamayı ayda birkaç kez, ödeme tarihinde açıyor. Ekip bildirimle günlük kullanım zorlamak yerine başarı ölçütünü WAU/MAU'ya ve "zamanında ödeme hatırlatması" olayına çeviriyor.

Senaryo 4 — Ucuz yükleme, pahalı kullanıcı. A kanalı yükleme başına en düşük maliyeti veriyor ama bu kanaldan gelen kohortun D7 retention ve 90. gün geliri en düşük seviyede. B kanalı daha pahalı olmasına rağmen LTV:CAC oranı daha yüksek. Bütçe, yükleme maliyetine göre değil kanal bazlı LTV:CAC oranına göre yeniden dağıtılıyor.

Dört senaryonun ortak dersi aynıdır:

• Ortalama yerine kırılıma bakın: platform, sürüm, kanal ve cihaz.
• Her değişikliği önceden belirlenmiş bir metrik ve kohort karşılaştırmasıyla doğrulayın.
• Metriği uygulamanın doğal kullanım sıklığına göre seçin.
• Sonuca bakmadan önce beklentinizi yazın; böylece veri, varsayımınızı gerçekten sınayabilir.

Sıkça Sorulan Sorular

Mobil uygulama analitiği için hangi araçla başlamalıyım?

Çoğu uygulama için Firebase Analytics, Firebase Crashlytics, App Store Connect ve Google Play Console birlikte yeterli bir başlangıçtır. Hazır kohort raporlarına veya reklam atfına ihtiyaç büyüdüğünde ürün analitiği aracı ya da atıf platformu eklenebilir.

D1 retention oranı kaç olmalı?

Adjust'ın 2026 verisine göre tüm kategorilerde ortalama D1 retention %26'dır; iOS'ta %27, Android'de %24'tür. En isabetli hedef, App Store Connect'teki benzer uygulama grubunuzun 50. yüzdelik değerinin üzerine çıkmaktır.

DAU/MAU oranı nasıl hesaplanır?

DAU/MAU, günlük aktif kullanıcı sayısının aylık aktif kullanıcı sayısına bölünmesiyle bulunur. Örneğin 3.000 DAU ve 15.000 MAU olan bir uygulamanın oranı %20'dir; bu, aylık kullanıcının ayda yaklaşık 6 gün uygulamayı açtığı anlamına gelir.

Retention ile churn arasındaki fark nedir?

Retention, bir kohortun belirli bir süre sonra ne kadarının aktif kaldığını gösterir. Churn ise aynı süre içinde kaybedilen kullanıcı veya abone oranıdır ve abonelik olmayan uygulamalarda retention oranının tamamlayıcısı olarak hesaplanır.

Firebase Analytics ücretli mi?

Hayır; Firebase fiyatlandırma sayfasında Analytics ve Crashlytics, hem ücretsiz Spark planında hem kullandıkça öde Blaze planında ücretsiz olarak listelenir. Veriyi BigQuery'de sorgulamak ise BigQuery kullanım ücretine tabidir; Spark planında BigQuery sandbox sınırları geçerlidir.

Analitik SDK'sı için kullanıcıdan izin almak gerekir mi?

Veri üçüncü taraf bir sağlayıcıya iletiliyorsa veya reklam amaçlı kullanılıyorsa, KVKK kapsamında açık rıza almak güvenli yaklaşımdır. iOS'ta ise yalnızca uygulamanızın kendi kullanımını ölçen ve başka şirketlerin verisiyle birleştirilmeyen analitik için ATT izni gerekmez.

Crash oranı ne zaman tehlikeli seviyeye gelir?

Google Play, son 28 günde günlük kullanıcıların %1,09'undan fazlası çökme yaşadığında veya tek bir telefon modelinde bu oran %8'i aştığında uygulamayı kötü davranış eşiğinde sayar. Bu durumda uygulamanın mağaza görünürlüğü düşebilir ve mağaza sayfasında uyarı çıkabilir.

Mobil uygulama analitiği, yayından sonra eklenen bir rapor ekranı değil, ürün mimarisinde baştan yer alan bir karardır. Ölçüm planı, olay adları ve izin akışı ilk sürümle birlikte tasarlandığında bu 10 metriğin hepsi ilk günden güvenilir veri üretir.

Mobil uygulama geliştirme hizmetimizde analitik ve crash raporlama kurulumunu projenin standart parçası olarak planlıyoruz. Mevcut uygulamanızın ölçüm altyapısını birlikte değerlendirmek için bizimle iletişime geçin.