モバイル分析におけるScreen View — 定義、主要指標、追跡方法

Screen Viewとは？

Screen Viewは、モバイルアプリケーションの画面が開かれたときに送信される分析イベントです。イベントには、画面名（screen_name）、クラス（screen_class）、タイムスタンプが含まれます。page_viewがURLに紐づくウェブ分析とは異なり、モバイルアプリケーションでは、画面はActivity、Fragment、ViewController、またはCustom Viewの名前で識別されます。

Screen Viewイベントの構造

previous_screenパラメータは特に重要です。これにより、遷移のシーケンスを復元し、Screen Flow（アプリケーションを通るユーザーパスのマップ）を構築できます。

Screen View vs Page View：主な違い

Screen ViewとPage Viewは同じタスク（表示の記録）を解決しますが、異なる環境で機能します。ウェブでは、URLがページを一意に識別し、Page Viewはドキュメントの読み込みに紐づきます。モバイルアプリケーションでは、画面はUIの状態であり、必ずしも個別のアドレスに対応するわけではありません。

• Page ViewはHTTPリクエストとURLに紐づく — Screen ViewはActivity/ViewControllerのライフサイクルイベントに紐づく
• Page Viewは戻る際に重複しない（キャッシュが使用される） — Screen Viewは画面が開かれるたびに再度送信される
• Page Viewは一般的に短い — ユーザーはインタラクティブな要素を持つモバイル画面よりもウェブページを速く閲覧する

もう一つの違いはコンテキストの深さです。モバイルアプリケーションのScreen Viewには、ユーザーが認証されているか、どのデータが読み込まれているか、画面が編集モードで開かれているかなどの状態パラメータが含まれます。ウェブのPage Viewがそのようなコンテキストを持つことはほとんどなく、URLの読み込みという事実のみを記録します。これにより、Screen Viewはプロダクト分析においてより情報価値が高くなり、各イベントを状態ごとにセグメント化できます。

Screen Viewを扱う際の典型的な誤り

最初の誤りは、画面内の状態変更（タブの切り替え、ポップアップの開封）のたびにscreen_viewを送信することです。Screen Viewは、マイクロインタラクションではなく、新しい画面への完全な遷移のみを記録する必要があります。

2番目の誤りは、読みやすい名前の代わりに技術的なクラス名を使用することです。「ProductDetailActivityKt」はアナリストにとって無意味です。screen_nameには「Product Details」を使用してください。

3番目の誤りは、対応するフィールドなしで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に1行で追加できます。これはSwiftUIプロジェクトのためのクリーンでスケーラブルなソリューションです。

マルチモジュールプロジェクトにおけるScreen View

モジュラーアーキテクチャのプロジェクトでは、各モジュールが独自の画面命名を使用する可能性があり、screen_nameの重複を引き起こします。集中管理されたScreenName列挙型がこの問題を解決します。すべての画面が1か所で単一の標準に従って命名されます。新しい画面を追加するには、列挙型に新しい定数を追加するだけでよく、コード全体を検索する必要はありません。

sealed classを使用して、機能ごとにグループ化したscreen_nameを記述します：ProfileScreen.CHANGE_PASSWORD、OrdersScreen.ORDER_HISTORY、CatalogScreen.SEARCH_RESULTS。これにより、分析レポートでのフィルタリングが簡素化されます。

Screen Flow：画面間の遷移分析

Screen Flow（またはパス分析）は、ユーザーが通過する画面のシーケンスを可視化したものです。これは、ナビゲーションのボトルネックを特定するための主要なツールです。

Screen Flowの構築

previous_screenパラメータを持つ各Screen Viewは、グラフのエッジを提供します：CatalogScreen → ProductDetails → CartScreen。すべての遷移を集約することで、パスマップが構築されます。Screen Flowに基づく3ステップファネルは、ユーザーがどこで離脱するかを示します。

• ステップ1：HomeScreen → CatalogScreen（95%が進行）
• ステップ2：CatalogScreen → ProductDetails（65%が進行 — 35%が離脱）
• ステップ3：ProductDetails → AddToCart（30%が進行 — さらに35%を損失）

Mixpanel（2024年）によると、Screen Flow分析は、個別のイベント分析では見えないUX問題の最大40%を明らかにします。例えば、購入なしでの頻繁な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日間）と再訪ユーザーを分けて分析します。新規ユーザーはオンボーディング画面で立ち往生することが多く、経験豊富なユーザーは目標アクションに速く到達します。2つのフローを比較すると、適応のボトルネックが明らかになります。

Screen View分析ツール

Screen View分析のためのツール選択は、予算、スタック、必要な詳細レベルによって異なります。3つの人気ソリューションを見てみましょう。

Firebase Analytics（無料）

Firebaseは、各イベントのscreen_viewパラメータを介して自動的に画面を追跡します。SDK統合後、追加のコードは必要ありません。制限：screen_nameはActivity/ViewControllerから生成されるため、常に読みやすい名前になるとは限りません。

Amplitude（プロフェッショナル）

Amplitudeは、内蔵のPathfinder（ビジュアルScreen Flowビルダー）を提供します。ユーザープロパティとコホートセグメンテーションをサポートします。アプリケーションコードを変更せずに、サーバー側で画面名を変更できます。

Mixpanel（ミッドマーケット）

Mixpanelは、リアルタイムのFlowsレポートを提供します。線形の遷移だけでなく、分岐（特定の画面の後にどの画面が訪問されるか）も表示できます。iOS、Android、Flutter、React Native SDKと統合されます。

Screen Viewがパフォーマンスに与える影響

各screen_viewイベントはネットワークデータ送信です。アプリがタブを切り替えるたび（毎分20回以上）にscreen_viewを送信すると、不必要な負荷が発生します。最適化：screen_viewをバッファリングし、5秒ごとにバッチ送信します。Firebaseは自動的にイベントを集約しますが、カスタムSDKは各呼び出しを即座に送信する可能性があります。

追跡のオーバーヘッドを測定します：各screen_viewにタイムスタンプを追加し、onResumeから送信までの遅延を計算します。遅延が100msを超える場合、追跡はUXに影響を与えます。UIスレッドをブロックしないよう、バックグラウンドスレッドで送信します。ローエンドデバイスでは、その差は顕著です。