移动分析中的Screen View — 是什么、有哪些指标及如何跟踪

什么是Screen View？

Screen View — 在打开移动应用屏幕时发送的分析事件。该事件包含屏幕名称（screen_name）、类（screen_class）和时间戳。与page_view绑定URL的Web分析不同，在移动应用中，屏幕根据Activity、Fragment、ViewController或Custom View的名称进行识别。

Screen View事件结构

previous_screen参数尤为重要：它可以重建过渡序列并构建Screen Flow — 应用中的用户路径图。

Screen View vs Page View：主要区别

Screen View和Page View解决相同的任务 — 记录查看 — 但在不同的环境中。在Web上，URL唯一标识页面，Page View与文档加载绑定。在移动应用中，屏幕是UI状态，不一定对应单独的地址。

• Page View与HTTP请求和URL绑定 — Screen View与Activity/ViewController生命周期事件绑定
• Page View在返回时不重复（使用缓存） — Screen View在每次屏幕打开时重新发送
• Page View平均更短 — 用户浏览网页比浏览带有交互元素的移动屏幕更快

另一个区别 — 上下文深度。移动应用中的Screen View包含状态参数：用户是否登录、加载了哪些数据、屏幕是否以编辑模式打开。Web上的Page View很少携带这样的上下文 — 它只记录URL加载的事实。这使得Screen View对产品分析更具信息性，因为每个事件都可以按状态进行细分。

使用Screen View时的典型错误

第一个错误 — 在屏幕内的每次状态变化时（切换标签、打开弹出窗口）发送screen_view。Screen View应仅记录到新屏幕的完全过渡，而不是微交互。

第二个错误 — 使用技术类名称代替可读名称。"ProductDetailActivityKt"对分析人员毫无用处 — 请在screen_name中使用"Product Details"。

第三个错误 — 在没有相应字段的情况下发送screen_view。空的screen_name会创建一组无法分组的垃圾记录。始终至少发送screen_name和screen_class，即使在测试屏幕上也是如此。

如何跟踪Screen View？

实现Screen View跟踪取决于导航架构。让我们以Jetpack Compose和SwiftUI为例，了解自动和手动方法。

Android：Jetpack Compose中的自动跟踪

在NavigationComponent级别使用LifecycleEventObserver。每当用户导航到新路由时，screen_view事件就会触发。

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中连接
fun NavBackStackEntry.trackScreenView(analytics: AnalyticsProvider) {
    lifecycle.addObserver(ScreenTrackingObserver(analytics))
}

该方法确保在每次屏幕返回前台时（包括从后台返回）发送screen_view。Lifecycle.Event.ON_RESUME是跟踪的正确时机，而不是ON_START或ON_CREATE。

iOS：SwiftUI中的自动跟踪

在SwiftUI中，使用内置于每个View中的onAppear修饰符。为了实现自动化，创建了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))
    }
}

// 使用：
ProductDetailView()
    .trackScreen("Product Details")

trackScreen修饰符可通过一行代码添加到任何View。这是SwiftUI项目的一个干净且可扩展的解决方案。

多模块项目中的Screen View

在模块化架构的项目中，每个模块可能使用自己的屏幕命名，导致screen_name重复。集中式枚举ScreenName解决了这个问题 — 所有屏幕在一个地方按照统一标准命名。添加新屏幕只需要在枚举中添加新常量，而无需搜索整个代码库。

使用sealed class按功能分组描述screen_name：ProfileScreen.CHANGE_PASSWORD、OrdersScreen.ORDER_HISTORY、CatalogScreen.SEARCH_RESULTS。这简化了分析报告中的过滤。

Screen Flow：屏幕间过渡分析

Screen Flow（或Path Analysis） — 用户经过的屏幕序列的可视化。这是识别导航瓶颈的主要工具。

构建Screen Flow

每个带有previous_screen参数的Screen View创建一个图边：CatalogScreen → ProductDetails → CartScreen。通过聚合所有过渡，构建路径图。基于Screen Flow的三步漏斗显示用户在何处流失。

• 步骤1：HomeScreen → CatalogScreen（95%通过）
• 步骤2：CatalogScreen → ProductDetails（65%通过 — 35%离开）
• 步骤3：ProductDetails → AddToCart（30%通过 — 再损失35%）

根据Mixpanel（2024）的数据，Screen Flow分析揭示了多达40%的UX问题，这些问题在分析单个事件时不可见。例如，频繁的ProductDetails → HomeScreen过渡而未购买表明产品价格或描述存在问题。

Drop-off分析

Drop-off — 用户离开场景的点。如果加载屏幕后有60%的用户离开，问题在于加载速度或动画。如果在Paywall之后 — 在于订阅价格或价值。

Firebase和BigQuery中的Screen Flow

Firebase不提供现成的Screen Flow报告，但screen_view数据在BigQuery中可用。创建一个查询，按（previous_screen，screen_name）对过渡进行分组并计算频率。结果是一个过渡矩阵，可以在Looker Studio中可视化为桑基图。

用细分补充Screen Flow：分别针对新用户（前7天）和回访用户。新用户更常在引导屏幕上卡住，有经验的用户更快到达目标操作。比较两个流揭示了适应瓶颈。

Screen View分析工具

选择工具取决于预算、技术栈和所需的详细程度。让我们来看三种流行的解决方案。

Firebase Analytics（免费）

Firebase通过每个事件中的screen_view参数自动跟踪屏幕。集成SDK后无需额外代码。限制：screen_name从Activity/ViewController生成，并不总是提供可读的名称。

Amplitude（专业版）

Amplitude提供内置的Pathfinder — 可视化Screen Flow构建器。支持user property和按群组细分。允许在服务器端重命名屏幕，而无需更改应用程序代码。

Mixpanel（中端）

Mixpanel提供实时Flows报告。不仅能够显示线性过渡，还能显示分支 — 在特定屏幕之后访问了哪些屏幕。与iOS、Android、Flutter和React Native SDK集成。

Screen View对性能的影响

每个screen_view事件都是网络数据发送。如果应用在每次切换标签时（每分钟20+次）发送screen_view，就会产生额外负载。优化：缓冲screen_view并每5秒批量发送一次。Firebase自动聚合事件，但自定义SDK可能立即发送每次调用。

衡量跟踪的开销：在每个screen_view中添加时间戳，并计算从onResume到发送的延迟。如果延迟超过100毫秒，跟踪会影响用户体验。使用后台线程进行发送，以免阻塞UI线程。在低端设备上，差异很明显。