Mobil analitikte Screen View — nedir, temel metrikler ve nasıl izlenir

Screen View Nedir?

Screen View, bir mobil uygulama ekranı açıldığında gönderilen bir analitik olayıdır. Olay, ekran adını (screen_name), sınıfı (screen_class) ve bir zaman damgasını içerir. page_view'in bir URL'ye bağlı olduğu web analitiğinin aksine, mobil uygulamalarda ekranlar Activity, Fragment, ViewController veya Custom View adıyla tanımlanır.

Screen View Olayının Yapısı

previous_screen parametresi özellikle önemlidir: geçiş sırasını geri yüklemeye ve Screen Flow'u (uygulama içindeki kullanıcı yollarının haritası) oluşturmaya olanak tanır.

Screen View vs Page View: Temel Farklar

Screen View ve Page View aynı görevi çözer — bir görüntülemeyi kaydetmek — ancak farklı ortamlarda. Web'de, bir URL bir sayfayı benzersiz şekilde tanımlar ve Page View belge yüklemeye bağlıdır. Mobil uygulamalarda, bir ekran, mutlaka ayrı bir adrese karşılık gelmeyen bir UI durumudur.

• Page View HTTP isteği ve URL'ye bağlıdır — Screen View Activity/ViewController yaşam döngüsü olayına bağlıdır
• Page View geri dönerken tekrarlanmaz (önbellek kullanılır) — Screen View ekran her açıldığında yeniden gönderilir
• Page View genellikle daha kısadır — kullanıcılar etkileşimli öğelere sahip bir mobil ekrana kıyasla bir web sayfasını daha hızlı görüntüler

Bir diğer fark ise bağlam derinliğidir. Mobil uygulamadaki Screen View, durum parametrelerini içerir: kullanıcının kimlik doğrulaması yapılıp yapılmadığı, hangi verilerin yüklendiği, ekranın düzenleme modunda açık olup olmadığı. Web'de Page View nadiren böyle bir bağlam taşır — yalnızca URL yükleme olayını kaydeder. Bu, Screen View'ı ürün analitiği için daha bilgilendirici hale getirir, çünkü her olay duruma göre segmentlere ayrılabilir.

Screen View ile Çalışırken Tipik Hatalar

İlk hata, bir ekran içindeki her durum değişikliğinde (sekme değiştirme, popup açma) screen_view göndermektir. Screen View yalnızca yeni bir ekrana tam geçişi kaydetmeli, mikro etkileşimleri değil.

İkinci hata, okunabilir bir ad yerine teknik sınıf adını kullanmaktır. “ProductDetailActivityKt” bir analist için işe yaramaz — screen_name'de “Product Details” kullanın.

Üçüncü hata, ilgili alanlar olmadan screen_view göndermektir. Boş bir screen_name, gruplanamayan gereksiz kayıtlar oluşturur. Test ekranlarında bile her zaman en azından screen_name ve screen_class'ı iletin.

Screen View Nasıl İzlenir?

Screen View izlemenin uygulanması, gezinme mimarisine bağlıdır. Jetpack Compose ve SwiftUI örneğini kullanarak otomatik ve manuel yaklaşımları inceleyelim.

Android: Jetpack Compose'da Otomatik İzleme

NavigationComponent düzeyinde LifecycleEventObserver kullanın. Bir kullanıcı yeni bir route'a her gittiğinde, screen_view olayı tetiklenir.

class ScreenTrackingObserver(
    private val analytics: AnalyticsProvider
) : LifecycleEventObserver {

    override fun onStateChanged(
        source: LifecycleOwner,
        event: Lifecycle.Event
    ) {
        if (event == Lifecycle.Event.ON_RESUME) {
            val route = source.getRouteFromLifecycleOwner()
            analytics.logScreenView(
                screenName = route.screenName,
                screenClass = source.getLocalClassName()
            )
        }
    }
}

// NavHost'ta bağlantı
fun NavBackStackEntry.trackScreenView(analytics: AnalyticsProvider) {
    lifecycle.addObserver(ScreenTrackingObserver(analytics))
}

Bu yaklaşım, arka plandan dönüş de dahil olmak üzere, ekran ön plana her döndüğünde screen_view'ın gönderilmesini sağlar. Lifecycle.Event.ON_RESUME izleme için doğru andır, ON_START veya ON_CREATE değil.

iOS: SwiftUI'da Otomatik İzleme

SwiftUI'da her View'da yerleşik olan onAppear değiştiricisi kullanılır. Otomasyon için bir ViewModifier oluşturulur.

struct ScreenTrackingModifier: ViewModifier {

    let screenName: String

    func body(content: Content) -> some View {
        content.onAppear {
            Analytics.shared().logScreenView(
                name: screenName,
                className: "\(Self.self)"
            )
        }
    }
}

extension View {
    func trackScreen(_ name: String) -> some View {
        modifier(ScreenTrackingModifier(screenName: name))
    }
}

// Kullanım:
ProductDetailView()
    .trackScreen("Product Details")

trackScreen değiştiricisi, tek bir satırla herhangi bir View'a eklenir. Bu, SwiftUI projeleri için temiz ve ölçeklenebilir bir çözümdür.

Çok Modüllü Projelerde Screen View

Modüler mimariye sahip projelerde, her modül kendi ekran adlandırmasını kullanabilir, bu da screen_name'in tekrarlanmasına yol açar. Merkezi bir ScreenName enum'u sorunu çözer — tüm ekranlar tek bir yerde tek bir standarda göre adlandırılır. Yeni bir ekran eklemek, tüm kodda arama yapmak yerine yalnızca enum'da yeni bir sabit gerektirir.

Özelliğe göre gruplandırma ile screen_name'i tanımlamak için sealed class kullanın: ProfileScreen.CHANGE_PASSWORD, OrdersScreen.ORDER_HISTORY, CatalogScreen.SEARCH_RESULTS. Bu, analitik raporlarında filtrelemeyi basitleştirir.

Screen Flow: Ekranlar Arası Geçiş Analizi

Screen Flow (veya Yol Analizi), bir kullanıcının geçtiği ekran sırasının görselleştirilmesidir. Gezinmedeki darboğazları belirlemek için birincil araçtır.

Screen Flow Oluşturma

previous_screen parametresine sahip her Screen View bir grafik kenarı sağlar: CatalogScreen → ProductDetails → CartScreen. Tüm geçişler birleştirilerek bir yol haritası oluşturulur. Screen Flow'a dayalı üç adımlı bir huni, kullanıcıların nerede ayrıldığını gösterir.

• Adım 1: HomeScreen → CatalogScreen (%95 devam eder)
• Adım 2: CatalogScreen → ProductDetails (%65 devam eder — %35 ayrılır)
• Adım 3: ProductDetails → AddToCart (%30 devam eder — %35 daha kaybederiz)

Mixpanel (2024)'e göre, Screen Flow analizi, tek tek olayları analiz ederken görünmeyen UX sorunlarının %40'ına kadarını ortaya çıkarır. Örneğin, satın alma olmadan sık sık ProductDetails → HomeScreen geçişi, fiyat veya ürün açıklamasıyla ilgili bir soruna işaret eder.

Terk Analizi (Drop-off)

Drop-off, kullanıcının bir senaryoyu terk ettiği noktadır. Yükleme ekranından sonra kullanıcıların %60'ı ayrılırsa, sorun yükleme hızı veya animasyondadır. Bir Paywall'dan sonraysa — abonelik maliyeti veya değerindedir.

Firebase ve BigQuery'de Screen Flow

Firebase hazır bir Screen Flow raporu sağlamaz, ancak screen_view verileri BigQuery'de mevcuttur. Geçişleri çifte (previous_screen, screen_name) göre gruplandıran ve sıklığı sayan bir sorgu oluşturun. Sonuç, Looker Studio'da Sankey diyagramı olarak görselleştirilebilen bir geçiş matrisidir.

Screen Flow'u segmentasyonla tamamlayın: yeni kullanıcılar (ilk 7 gün) ve geri dönen kullanıcılar için ayrı ayrı. Yeni kullanıcılar genellikle onboarding ekranlarında takılıp kalırken, deneyimli kullanıcılar hedef eylemlere daha hızlı ulaşır. İki akışı karşılaştırmak, adaptasyon darboğazlarını ortaya çıkarır.

Screen View Analizi İçin Araçlar

Screen View analizi için araç seçimi bütçeye, yığına ve gereken ayrıntı düzeyine bağlıdır. Üç popüler çözümü inceleyelim.

Firebase Analytics (ücretsiz)

Firebase, her olaydaki screen_view parametresi aracılığıyla ekranları otomatik olarak izler. SDK entegrasyonundan sonra ek kod gerektirmez. Sınırlama: screen_name, Activity/ViewController'dan oluşturulur ve bu her zaman okunabilir adlar üretmez.

Amplitude (profesyonel)

Amplitude, yerleşik bir Pathfinder (görsel Screen Flow oluşturucu) sunar. Kullanıcı özelliklerini ve kohort segmentasyonunu destekler. Uygulama kodunda değişiklik yapmadan sunucu tarafında ekranları yeniden adlandırmaya olanak tanır.

Mixpanel (orta segment)

Mixpanel, gerçek zamanlı Flows raporu sağlar. Yalnızca doğrusal geçişleri değil, aynı zamanda dallanmaları da gösterebilir — belirli bir ekrandan sonra hangi ekranların ziyaret edildiğini. iOS, Android, Flutter ve React Native SDK'larıyla entegre olur.

Screen View'ın Performansa Etkisi

Her screen_view olayı bir ağ verisi gönderimidir. Bir uygulama her sekme değişiminde (dakikada 20+) screen_view gönderiyorsa, gereksiz yük oluşturur. Optimizasyon: screen_view'ları arabelleğe alın ve her 5 saniyede bir toplu olarak gönderin. Firebase olayları otomatik olarak toplar, ancak özel SDK'lar her çağrıyı hemen gönderebilir.

İzlemenin ek yükünü ölçün: her screen_view'a bir zaman damgası ekleyin ve onResume'dan gönderime kadar olan gecikmeyi hesaplayın. Gecikme 100 ms'yi aşarsa, izleme UX'i etkiler. UI iş parçacığını engellememek için gönderme için bir arka plan iş parçacığı kullanın. Düşük seviyeli cihazlarda fark belirgindir.