データ計測はリリース直前に考えない：選択率・離脱地点・エンディングの記録方法

インタラクティブ映像ゲームのデータ計測は、ノードデータが固まる段階で設計するべきだ。役立つデータには、プレイヤーが何を見て、何を選べて、最終的に何を選んだのか、さらに技術的に再生が成功したのかが必要だからだ。ボタンのクリックだけを記録すると、未表示、誤操作、離脱、読み込み失敗が混ざり、ストーリーについて誤った判断をしてしまう。

まずプロダクトに関する問いを挙げる。プレイヤーはどの章で離脱するのか。ある選択肢が誰にも選ばれないのは、魅力がないからか、それとも表示されていないからか。あるエンディングへの到達が少ないのは、条件が難しすぎるからか、それともプレイヤーがその道を進みたくないからか。再プレイする人は何を探しているのか。それぞれの問いに指標と最小限のイベントを対応させ、画面上の操作をすべてアップロードしない。

データだけでは「なぜ」のすべてには答えられない。定量分析で異常を見つけたら、ユーザビリティの観察、コメント、インタビューも合わせて解釈する。選択率が低い原因は、文言、キャラクターの価値観、それまでの状態にあるかもしれず、自動的に悪い分岐と判断してはいけない。

少なくとも、セッションの開始と終了、ノードへの進入、メディア準備の成功または失敗、選択肢の表示、選択の送信、状態のマイルストーン、エンディングへの到達、再プレイの開始を記録する。共通フィールドには、匿名セッションID、ゲームのバージョン、プラットフォーム、言語、ノードまたは選択肢のID、時刻、必要な実験バージョンを含める。

選択肢の表示イベントには、その時点で表示された選択肢の集合と時間制限のルールも記録する。送信イベントには、選択ID、表示から送信までの時間、タイムアウトの有無を記録する。これにより、選択率の分母は全プレイヤーではなく「実際にその選択肢を見た人」になる。

プログラムは、終了通知を毎回確実に受け取れるわけではない。特に、クラッシュ、停電、モバイルOSによるアプリの終了時は難しい。ノードへの進入時や再生の重要な段階で軽量なハートビートを記録し、次回起動時に前回のセッションが正常に終了しなかったかを判断できる。自発的な離脱、バックグラウンドでのタイムアウト、クラッシュ、正常終了を区別する。

離脱地点では、ノードだけでなく、再生の進捗、選択待ちだったか、直近の読み込み所要時間、再視聴だったかも記録する。プレイヤーが同じ動画の90%地点で離脱するなら、コンテンツの問題かもしれない。0%地点で離脱し、読み込みも失敗しているなら、技術的な問題の可能性が高い。

エンディングイベントには、主要エンディングID、エピローグのバリエーション、重要な状態の要約、合計所要時間、再試行回数、スキップの使用有無を記録する。フレーム単位の完全な行動履歴や自由入力テキストはアップロードせず、設計上の問いに答えるために必要なフィールドだけを残す。

すべての完全な選択順序を保存するのではなく、重要な選択について経路のファネルを作る。完全な経路の組み合わせはすぐにデータがまばらになり、プライバシーと分析の負担も増やす。通常は、章の入口、重要なノード、エンディングだけで問題の特定に十分だ。

イベント辞書には、名前、発火タイミング、フィールドの型、例、担当者、用途、保持期間、バージョンを含める。イベント名は安定させ、フィールドの追加では後方互換性を保つ。意味を変える場合は新しいバージョンを作り、古いフィールドを黙って使い回してはいけない。

各イベントを発火させるシステムは一つだけにする。ボタン、ノード管理、プレイヤーがすべて「選択完了」を送信すると、データが重複する。送信成功後に一意のイベントIDを生成すれば、オフライン時の再送でも重複を排除できる。

必要な情報だけを収集し、氏名、生のデバイス識別子、プレイヤーの入力内容は避ける。収集目的、保持期間、収集を拒否する方法を説明する。適用地域の具体的な法的要件は、資格を持つ専門家が確認するべきだ。分析に同意しなくても、ゲームの基本的な流れは動作しなければならない。

開発ログと分析データを分ける。前者はトラブルシューティングのために詳細な状態をローカルに含めてもよいが、後者は集計に必要なフィールドだけをアップロードする。テストアカウントと実際のプレイヤーも識別して分離し、リリース後のデータに混入させない。

各イベントについて、いつ発生するべきか、いつ発生してはいけないか、フィールドが有効かを確認するテストケースを書く。既知の経路を一つ実行し、想定イベントを手計算してから、バックエンドと一件ずつ照合する。オフライン、再接続、重複送信、バージョンをまたぐ動作、システム時刻の異常をテストする。

最後に最小限のダッシュボードを作る。章への到達率、ノードでの離脱率、選択肢の表示と選択率、各エンディングの人数、初回プレイの完了時間、再プレイ開始率、メディア失敗率を表示する。意思決定を支えられないグラフは、「データの充実」のためだけに長期的に維持しない。

各指標の横に「この指標からは何が分からないか」を一文で補足する。完了率の低下だけではストーリーの悪化を証明できず、再プレイ率の高さもセーブの不具合や実績の条件による場合がある。変更をリリースする前にバージョン別のグループを保持し、新規プレイヤーの構成変化をコンテンツの効果と誤認しないようにする。サンプルが非常に少ない場合は人数と区間を表示し、小数点で確実さを演出しない。

データレビューは行動につなげる。観察の継続、詳しい調査、技術的な修正、コンテンツの調整を決め、担当者と再確認日を指定する。行動につながらない問いのために、さらに多くのフィールドを継続して集める必要はない。

次のステップ：最も重要な設計上の問いを三つ選び、それぞれについて指標の計算式、必要なイベント、判断のしきい値を書く。その後、テスターに固定の経路を一つ使って生のイベントを照合してもらい、分母に誤りがないことを確認する。