Firebase Analytics ile Mobil Uygulama Kullanıcılarını Anlamak
Yeni yayınlanan bir uygulamada müşteri genelde şunu soruyor: "Kaç kişi indirdi?" Oysa asıl önemli soru şu olmalı: indirenlerin kaçı ikinci gün geri döndü, hangi ekranda takılıp kaldılar, sepete ekleyip ödemeyi tamamlamayanlar nerede vazgeçti. Firebase Analytics tam da bu soruların cevabını ücretsiz veriyor, kurulumu da göründüğünden basit.
Otomatik toplanan veriler yeterli değil
Firebase SDK'sını uygulamaya ekler eklemez ekran görüntüleme (screen_view), ilk açılış (first_open), oturum süresi gibi bazı olaylar otomatik toplanmaya başlıyor. Ama bu veri tek başına iş kararı almaya yetmiyor. "Ürün detay ekranı 10 bin kez görüntülendi" bilgisi güzel ama "kaçı sepete ekledi, kaçı ekleyip ödeme yapmadı" sorusunun cevabını vermiyor. Bunun için özel olayları (custom event) tanımlamak gerekiyor: add_to_cart, begin_checkout, purchase gibi. Firebase'in önerdiği standart event isimlerini kullanmak, ileride Google Ads ya da diğer entegrasyonlarla uyumluluk açısından önem taşıyor, rastgele isimlendirme sonradan veri karmaşasına yol açıyor.
Huni analizi nerede kayıp yaşandığını gösteriyor
Funnel — yani huni — analizi, kullanıcının belirli adımlardan geçerken hangi noktada düştüğünü gösteriyor. Örneğin bir kayıt akışında: uygulama açılışı → kayıt ekranı görüntüleme → telefon doğrulama → profil tamamlama şeklinde dört adımlı bir huni kurduğunuzda, genelde en büyük kayıp telefon doğrulama adımında görülüyor. Bunun sebebi SMS kodunun geç gelmesi olabilir, form tasarımı karmaşık olabilir ya da kullanıcı basitçe vazgeçmiş olabilir. Huni verisi olmadan bu tahmin, veriyle birlikte kesinliğe dönüşüyor. Firebase konsolunda bu analiz için event'lerin doğru sırayla ve doğru parametrelerle gönderiliyor olması şart, aksi halde huni bozuk görünür.
Segmentasyon ve kullanıcı özellikleri
Bütün kullanıcıları tek grup gibi değerlendirmek yanıltıcı olabiliyor. Firebase'de user property tanımlayarak kullanıcıları abonelik durumu, kayıt tarihi, tercih ettiği kategori gibi kriterlere göre segmentlere ayırmak mümkün. Bu sayede "premium kullanıcıların ortalama oturum süresi" ile "ücretsiz kullanıcıların oturum süresi" ayrı ayrı karşılaştırılabiliyor ve bu genelde ürün kararlarını doğrudan etkiliyor.
iOS ve Android'de veri toplama farkları
App Tracking Transparency (ATT) sonrası iOS'ta kullanıcı izin vermezse bazı veri toplama kısıtlanıyor; Apple'ın gizlilik politikaları gereği iOS uygulama geliştirme projelerinde bu izin akışını doğru kurgulamak veri kalitesini doğrudan etkiliyor. Android tarafında ise Google Play politikaları daha esnek olsa da, Play Console'da veri güvenliği formunun eksiksiz doldurulması gerekiyor. Android + iOS çift platform paketi geliştirilen projelerde her iki platformda da event isimlerinin birebir aynı tutulması, konsolidasyonlu raporlama için kritik bir detay — sık atlanan bir nokta.
Veriyi düzenli okumak alışkanlık meselesi
Kurulum bir kere yapılıyor ama asıl fayda düzenli takip ediyorsanız ortaya çıkıyor. Haftalık bazda aktif kullanıcı sayısı, retention (elde tutma) oranı ve en çok kullanılan üç ekranı gözden geçirmek, yeni özellik kararlarını sezgiyle değil veriyle almayı sağlıyor. BigQuery entegrasyonu açıldığında bu veriler ham haliyle dışa aktarılabiliyor, daha derin analiz isteyen ekipler için bu kapıyı baştan açık bırakmak ileride zaman kazandırıyor.
İlgili Yazılar
Projenize özel, şeffaf bir mobil uygulama fiyat teklifi için fiyat rehberimize göz atabilir veya bizimle iletişime geçebilirsiniz.
