Screen View trong phân tích di động — định nghĩa, chỉ số chính và cách theo dõi

Screen View là gì?

Screen View là sự kiện phân tích được gửi khi mở một màn hình ứng dụng di động. Sự kiện chứa tên màn hình (screen_name), lớp (screen_class) và dấu thời gian. Không giống như phân tích web, nơi page_view gắn với URL, trong ứng dụng di động, màn hình được xác định bằng tên của Activity, Fragment, ViewController hoặc Custom View.

Cấu trúc sự kiện Screen View

Tham số previous_screen đặc biệt quan trọng: nó cho phép khôi phục chuỗi chuyển đổi và xây dựng Screen Flow — bản đồ luồng người dùng trong ứng dụng.

Screen View vs Page View: khác biệt chính

Screen View và Page View giải quyết cùng một nhiệm vụ — ghi lại lượt xem — nhưng trong các môi trường khác nhau. Trên web, URL xác định duy nhất một trang và Page View gắn với việc tải tài liệu. Trong ứng dụng di động, màn hình là trạng thái giao diện không nhất thiết tương ứng với một địa chỉ riêng biệt.

• Page View gắn với yêu cầu HTTP và URL — Screen View gắn với sự kiện vòng đời của Activity/ViewController
• Page View không bị trùng lặp khi quay lại (bộ nhớ đệm được sử dụng) — Screen View được gửi lại mỗi khi màn hình được mở
• Page View thường ngắn hơn — người dùng xem trang web nhanh hơn màn hình di động với các phần tử tương tác

Một khác biệt nữa là độ sâu ngữ cảnh. Screen View trong ứng dụng di động bao gồm các tham số trạng thái: người dùng đã được xác thực chưa, dữ liệu nào đã được tải, màn hình có đang mở ở chế độ chỉnh sửa không. Page View trên web hiếm khi mang ngữ cảnh như vậy — nó chỉ ghi lại sự kiện tải URL. Điều này làm cho Screen View trở nên hữu ích hơn cho phân tích sản phẩm, vì mỗi sự kiện có thể được phân đoạn theo trạng thái.

Các lỗi điển hình khi làm việc với Screen View

Lỗi đầu tiên là gửi screen_view khi mỗi thay đổi trạng thái trong màn hình (chuyển tab, mở popup). Screen View chỉ nên ghi lại chuyển đổi hoàn chỉnh sang màn hình mới, không phải tương tác vi mô.

Lỗi thứ hai là sử dụng tên lớp kỹ thuật thay vì tên dễ đọc. “ProductDetailActivityKt” vô dụng đối với nhà phân tích — hãy sử dụng “Product Details” trong screen_name.

Lỗi thứ ba là gửi screen_view mà không có các trường tương ứng. screen_name rỗng tạo ra một tập hợp các bản ghi rác không thể nhóm được. Luôn truyền ít nhất screen_name và screen_class, ngay cả trên màn hình thử nghiệm.

Cách theo dõi Screen View?

Việc triển khai theo dõi Screen View phụ thuộc vào kiến trúc điều hướng. Hãy xem xét các phương pháp tự động và thủ công sử dụng Jetpack Compose và SwiftUI làm ví dụ.

Android: theo dõi tự động trong Jetpack Compose

Sử dụng LifecycleEventObserver ở cấp NavigationComponent. Mỗi khi người dùng điều hướng đến route mới, sự kiện screen_view được kích hoạt.

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

// Kết nối trong NavHost
fun NavBackStackEntry.trackScreenView(analytics: AnalyticsProvider) {
    lifecycle.addObserver(ScreenTrackingObserver(analytics))
}

Cách tiếp cận này đảm bảo rằng screen_view được gửi mỗi khi màn hình trở lại tiền cảnh, bao gồm cả việc trở về từ nền. Lifecycle.Event.ON_RESUME là thời điểm thích hợp để theo dõi, không phải ON_START hay ON_CREATE.

iOS: theo dõi tự động trong SwiftUI

Trong SwiftUI, bộ điều chỉnh onAppear được tích hợp trong mỗi View được sử dụng. Để tự động hóa, một ViewModifier được tạo ra.

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

// Sử dụng:
ProductDetailView()
    .trackScreen("Product Details")

Bộ điều chỉnh trackScreen được thêm vào bất kỳ View nào chỉ với một dòng. Đây là giải pháp sạch sẽ và có thể mở rộng cho các dự án SwiftUI.

Screen View trong các dự án đa mô-đun

Trong các dự án có kiến trúc mô-đun, mỗi mô-đun có thể sử dụng cách đặt tên màn hình riêng, dẫn đến trùng lặp screen_name. Một enum ScreenName tập trung giải quyết vấn đề — tất cả màn hình được đặt tên theo một tiêu chuẩn duy nhất tại một nơi. Thêm màn hình mới chỉ yêu cầu một hằng số mới trong enum, thay vì tìm kiếm trong toàn bộ mã nguồn.

Sử dụng sealed class để mô tả screen_name với nhóm theo tính năng: ProfileScreen.CHANGE_PASSWORD, OrdersScreen.ORDER_HISTORY, CatalogScreen.SEARCH_RESULTS. Điều này đơn giản hóa việc lọc trong báo cáo phân tích.

Screen Flow: phân tích chuyển đổi giữa các màn hình

Screen Flow (hoặc Phân tích luồng) là hình ảnh trực quan về chuỗi màn hình mà người dùng đi qua. Đây là công cụ chính để xác định các điểm nghẽn trong điều hướng.

Xây dựng Screen Flow

Mỗi Screen View với tham số previous_screen cung cấp một cạnh đồ thị: CatalogScreen → ProductDetails → CartScreen. Bằng cách tổng hợp tất cả các chuyển đổi, một bản đồ luồng được xây dựng. Một phễu ba bước dựa trên Screen Flow cho thấy nơi người dùng thoát.

• Bước 1: HomeScreen → CatalogScreen (95% tiếp tục)
• Bước 2: CatalogScreen → ProductDetails (65% tiếp tục — 35% rời đi)
• Bước 3: ProductDetails → AddToCart (30% tiếp tục — chúng ta mất thêm 35%)

Theo Mixpanel (2024), phân tích Screen Flow tiết lộ tới 40% vấn đề UX không thấy được khi phân tích từng sự kiện riêng lẻ. Ví dụ, chuyển đổi thường xuyên ProductDetails → HomeScreen mà không mua hàng cho thấy vấn đề về giá hoặc mô tả sản phẩm.

Phân tích thoát (Drop-off)

Drop-off là điểm mà người dùng rời khỏi kịch bản. Nếu 60% người dùng rời đi sau màn hình tải, vấn đề nằm ở tốc độ tải hoặc hoạt ảnh. Nếu sau Paywall — ở chi phí hoặc giá trị của đăng ký.

Screen Flow trong Firebase và BigQuery

Firebase không cung cấp báo cáo Screen Flow có sẵn, nhưng dữ liệu screen_view có sẵn trong BigQuery. Xây dựng truy vấn nhóm các chuyển đổi theo cặp (previous_screen, screen_name) và đếm tần suất. Kết quả là ma trận chuyển đổi có thể được trực quan hóa trong Looker Studio dưới dạng biểu đồ Sankey.

Bổ sung Screen Flow với phân khúc: riêng cho người dùng mới (7 ngày đầu) và người dùng quay lại. Người dùng mới thường bị kẹt trên màn hình hướng dẫn, trong khi người dùng có kinh nghiệm đến các hành động mục tiêu nhanh hơn. So sánh hai luồng tiết lộ các điểm nghẽn thích ứng.

Công cụ phân tích Screen View

Việc chọn công cụ phân tích Screen View phụ thuộc vào ngân sách, công nghệ và mức độ chi tiết yêu cầu. Hãy xem xét ba giải pháp phổ biến.

Firebase Analytics (miễn phí)

Firebase tự động theo dõi màn hình qua tham số screen_view trong mỗi sự kiện. Không yêu cầu mã bổ sung sau khi tích hợp SDK. Hạn chế: screen_name được tạo từ Activity/ViewController, không phải lúc nào cũng tạo ra tên dễ đọc.

Amplitude (chuyên nghiệp)

Amplitude cung cấp Pathfinder tích hợp — trình xây dựng Screen Flow trực quan. Hỗ trợ thuộc tính người dùng và phân khúc theo nhóm. Cho phép đổi tên màn hình ở phía máy chủ mà không cần thay đổi mã ứng dụng.

Mixpanel (phân khúc trung bình)

Mixpanel cung cấp báo cáo Flows thời gian thực. Nó có thể hiển thị không chỉ các chuyển đổi tuyến tính mà còn cả các nhánh — màn hình nào được truy cập sau một màn hình cụ thể. Tích hợp với SDK iOS, Android, Flutter và React Native.

Tác động của Screen View đến hiệu suất

Mỗi sự kiện screen_view là một lần gửi dữ liệu qua mạng. Nếu ứng dụng gửi screen_view ở mỗi lần chuyển tab (20+ mỗi phút), nó tạo ra tải không cần thiết. Tối ưu hóa: đệm screen_view và gửi theo lô mỗi 5 giây. Firebase tự động tổng hợp các sự kiện, nhưng SDK tùy chỉnh có thể gửi từng cuộc gọi ngay lập tức.

Đo chi phí của việc theo dõi: thêm dấu thời gian vào mỗi screen_view và tính độ trễ từ onResume đến khi gửi. Nếu độ trễ vượt quá 100 ms, việc theo dõi ảnh hưởng đến UX. Sử dụng luồng nền để gửi nhằm không chặn luồng giao diện. Trên các thiết bị cấp thấp, sự khác biệt là đáng kể.