Screen View dalam analitik seluler — apa itu, metrik apa dan cara melacak

Apa itu Screen View?

Screen View — peristiwa analitik yang dikirim saat membuka layar aplikasi seluler. Peristiwa ini berisi nama layar (screen_name), kelas (screen_class), dan stempel waktu. Berbeda dengan analitik web, di mana page_view terikat pada URL, di aplikasi seluler layar diidentifikasi berdasarkan nama Activity, Fragment, ViewController, atau Custom View.

Struktur peristiwa Screen View

Parameter previous_screen sangat penting: memungkinkan rekonstruksi urutan transisi dan pembuatan Screen Flow — peta jalur pengguna di aplikasi.

Screen View vs Page View: perbedaan utama

Screen View dan Page View memecahkan tugas yang sama — mencatat tampilan — tetapi di lingkungan yang berbeda. Di web, URL mengidentifikasi halaman secara unik, dan Page View terikat pada pemuatan dokumen. Di aplikasi seluler, layar adalah status UI, yang belum tentu sesuai dengan alamat terpisah.

• Page View terikat pada permintaan HTTP dan URL — Screen View terikat pada peristiwa siklus hidup Activity/ViewController
• Page View tidak terduplikasi saat kembali (menggunakan cache) — Screen View dikirim ulang setiap kali layar dibuka
• Page View rata-rata lebih pendek — pengguna menelusuri halaman web lebih cepat daripada layar seluler dengan elemen interaktif

Perbedaan lainnya — kedalaman konteks. Screen View di aplikasi seluler menyertakan parameter status: apakah pengguna masuk, data apa yang dimuat, apakah layar dibuka dalam mode edit. Page View di web jarang membawa konteks seperti itu — hanya mencatat fakta pemuatan URL. Ini membuat Screen View lebih informatif untuk analitik produk, karena setiap peristiwa dapat disegmentasikan berdasarkan status.

Kesalahan umum saat bekerja dengan Screen View

Kesalahan pertama — mengirim screen_view pada setiap perubahan status dalam layar (beralih tab, membuka pop-up). Screen View hanya boleh mencatat transisi lengkap ke layar baru, bukan interaksi mikro.

Kesalahan kedua — menggunakan nama kelas teknis alih-alih nama yang dapat dibaca. "ProductDetailActivityKt" tidak berguna bagi analis — gunakan "Product Details" di screen_name.

Kesalahan ketiga — mengirim screen_view tanpa bidang yang sesuai. screen_name kosong menciptakan kumpulan catatan sampah yang tidak dapat dikelompokkan. Selalu kirim setidaknya screen_name dan screen_class, bahkan di layar pengujian.

Bagaimana cara melacak Screen View?

Implementasi pelacakan Screen View tergantung pada arsitektur navigasi. Mari kita lihat pendekatan otomatis dan manual pada contoh Jetpack Compose dan SwiftUI.

Android: pelacakan otomatis di Jetpack Compose

Gunakan LifecycleEventObserver di tingkat NavigationComponent. Setiap kali pengguna pindah ke rute baru, peristiwa screen_view dipicu.

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()
            )
        }
    }
}

// Koneksi di NavHost
fun NavBackStackEntry.trackScreenView(analytics: AnalyticsProvider) {
    lifecycle.addObserver(ScreenTrackingObserver(analytics))
}

Pendekatan ini memastikan bahwa screen_view dikirim setiap kali layar kembali ke latar depan, termasuk kembali dari latar belakang. Lifecycle.Event.ON_RESUME adalah momen yang tepat untuk pelacakan, bukan ON_START atau ON_CREATE.

iOS: pelacakan otomatis di SwiftUI

Di SwiftUI, pengubah onAppear yang terintegrasi di setiap View digunakan. Untuk otomatisasi, dibuat ViewModifier.

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))
    }
}

// Penggunaan:
ProductDetailView()
    .trackScreen("Product Details")

Pengubah trackScreen ditambahkan ke View mana pun dengan satu baris. Ini adalah solusi yang bersih dan terukur untuk proyek SwiftUI.

Screen View di proyek multi-modul

Di proyek dengan arsitektur modular, setiap modul dapat menggunakan penamaan layarnya sendiri, yang menyebabkan duplikasi screen_name. Enum terpusat ScreenName memecahkan masalah — semua layar dinamai sesuai standar tunggal di satu tempat. Menambahkan layar baru hanya membutuhkan konstanta baru di enum, bukan pencarian di seluruh kode.

Gunakan sealed class untuk mendeskripsikan screen_name dengan pengelompokan berdasarkan fitur: ProfileScreen.CHANGE_PASSWORD, OrdersScreen.ORDER_HISTORY, CatalogScreen.SEARCH_RESULTS. Ini menyederhanakan pemfilteran di laporan analitik.

Screen Flow: analisis transisi antar layar

Screen Flow (atau Path Analysis) — visualisasi urutan layar yang dilalui pengguna. Ini adalah alat utama untuk mengidentifikasi hambatan dalam navigasi.

Membangun Screen Flow

Setiap Screen View dengan parameter previous_screen membuat tepi grafik: CatalogScreen → ProductDetails → CartScreen. Dengan mengagregasi semua transisi, peta jalur dibangun. Corong tiga langkah berdasarkan Screen Flow menunjukkan di mana pengguna keluar.

• Langkah 1: HomeScreen → CatalogScreen (95% lolos)
• Langkah 2: CatalogScreen → ProductDetails (65% lolos — 35% keluar)
• Langkah 3: ProductDetails → AddToCart (30% lolos — kehilangan 35% lagi)

Menurut data Mixpanel (2024), analisis Screen Flow mengungkapkan hingga 40% masalah UX yang tidak terlihat saat menganalisis peristiwa individual. Misalnya, transisi yang sering ProductDetails → HomeScreen tanpa pembelian menunjukkan masalah dengan harga atau deskripsi produk.

Analisis Drop-off

Drop-off — titik di mana pengguna meninggalkan skenario. Jika setelah layar pemuatan 60% pengguna pergi, masalahnya ada pada kecepatan pemuatan atau animasi. Jika setelah Paywall — pada harga atau nilai langganan.

Screen Flow di Firebase dan BigQuery

Firebase tidak menyediakan laporan Screen Flow siap pakai, tetapi data screen_view tersedia di BigQuery. Buat kueri yang mengelompokkan transisi berdasarkan pasangan (previous_screen, screen_name) dan menghitung frekuensi. Hasilnya — matriks transisi yang dapat divisualisasikan di Looker Studio sebagai diagram Sankey.

Lengkapi Screen Flow dengan segmentasi: terpisah untuk pengguna baru (7 hari pertama) dan yang kembali. Pengguna baru lebih sering terjebak di layar orientasi, pengguna berpengalaman lebih cepat mencapai tindakan target. Perbandingan dua aliran mengungkapkan hambatan adaptasi.

Alat untuk analitik Screen View

Pemilihan alat untuk Screen View tergantung pada anggaran, tumpukan teknologi, dan detail yang diperlukan. Mari kita lihat tiga solusi populer.

Firebase Analytics (gratis)

Firebase secara otomatis melacak layar melalui parameter screen_view di setiap peristiwa. Tidak memerlukan kode tambahan setelah integrasi SDK. Keterbatasan: screen_name dihasilkan dari Activity/ViewController, yang tidak selalu memberikan nama yang dapat dibaca.

Amplitude (profesional)

Amplitude menawarkan Pathfinder bawaan — pembuat Screen Flow visual. Mendukung user property dan segmentasi berdasarkan kohort. Memungkinkan penggantian nama layar di sisi server tanpa perubahan pada kode aplikasi.

Mixpanel (segmen menengah)

Mixpanel menyediakan laporan Flows secara real-time. Dapat menunjukkan tidak hanya transisi linier, tetapi juga percabangan — layar mana yang dikunjungi setelah layar tertentu. Terintegrasi dengan iOS, Android, Flutter, dan React Native SDK.

Dampak Screen View pada kinerja

Setiap peristiwa screen_view adalah pengiriman data jaringan. Jika aplikasi mengirim screen_view pada setiap peralihan tab (20+ per menit), ini menciptakan beban tambahan. Optimasi: buffer screen_view dan kirim secara batch setiap 5 detik. Firebase secara otomatis mengagregasi peristiwa, tetapi SDK kustom dapat mengirim setiap panggilan segera.

Ukur overhead pelacakan: tambahkan stempel waktu ke setiap screen_view dan hitung penundaan dari onResume hingga pengiriman. Jika penundaan melebihi 100 md, pelacakan memengaruhi UX. Gunakan thread latar belakang untuk pengiriman agar tidak memblokir thread UI. Pada perangkat kelas bawah, perbedaannya terlihat.