インタラクティブ映像ゲームの公開後に見るデータ：選択率、完了率、リプレイ率とエンディング分布

公開後に最も重要なのは指標をずらりと並べることではなく、プレイヤーが選択肢を理解しているか、円滑に完了できるか、探索したいと思うか、コンテンツや技術がどの地点で進行を阻むかという4つの問いを分けることだ。選択率、完了率、リプレイ率とエンディング分布は、実際の表示とプレイ機会を分母とし、バージョン、プラットフォーム、初回／リプレイ別に集計する必要がある。

ある選択肢の選択率＝その選択肢を選んだ人数÷その選択肢を見て、かつ選ぶ資格があった人数。条件、言語、リソース、先行ルートによって表示対象が変わるため、全プレイヤー数で割ってはいけない。時間制限のある選択では、時間切れ、入力なし、画面のフォーカス喪失も別々に集計する。

判断にかかった時間の分布も併せて見る。ほぼ全員が瞬時に同じ選択肢を押す場合、答えが明白すぎる可能性も、文言の配置が既定の選択を生んでいる可能性もある。長い迷いは価値観の葛藤がうまく機能しているためかもしれないし、選択肢が分かりにくいためかもしれない。テストの録画とフィードバックを合わせて解釈する。

起動、プロローグ完了、各チャプター到達、初回エンディング、正常終了までをファネルにする。各段階でメディアエラー、クラッシュ、読み込み時間、自発的な離脱も確認する。コンテンツによる離脱と技術による離脱を混同してはいけない。

完了率はコホート別に見る。初回プレイ日、プラットフォーム、バージョン、言語、端末の性能区分で分ける。ホットフィックス後に全体が上昇しても、新規プレイヤーの構成が変わっただけかもしれない。変化は同種のコホート同士で比較する。

リプレイには、エンディング後に新しいルートをクリックする、序盤のチャプターに入り直す、既読スキップを使う、一定の日数以内に2回目のセッションを始める、といった定義が考えられる。まず「初回エンディング後7日以内に新しいタイムラインを開始する」など、製品の目標に合う定義を選ぶ。クラッシュ後の再起動や、ミスを修正するためのセーブデータ読み込みは除外する。

次にリプレイの深さを見る。開いただけなのか、新しいノードやエンディングに到達したのか。開始は多いのに進行が少ない場合、繰り返しの内容が多すぎる、スキップが使いにくい、案内が方向を示していない可能性がある。

各エンディングの割合は、少なくとも1回完了したプレイヤーを分母とし、初回と累計を区別する。到達者が極端に少ないエンディングは、もともと隠し報酬なのかもしれない。主要なエンディングにほとんど誰も到達しない場合は、プレイヤーの好みを論じる前に、条件、セーブ、経路が正常かを検証する。

エンディング数が少なくても、体験が単調とは限らない。主要エンディングとエピローグの派生を階層別に表示し、到達に必要な重要な状態を確認する。棒グラフを均等にするために無理に物語を変えてはいけない。

各重要ノードで、到達人数、選択肢の表示、送信、メディア準備失敗、離脱、平均待ち時間、次のノードへの到達を並べて表示する。これにより、ボタンのクリックは正常なのに動画の切り替え後に大勢が消える問題を発見できる。選択率だけでは、このような途切れを見落とす。

セーブの復元、既読スキップ、アクセシビリティ設定にも健全性の指標を設ける。復元成功率、スキップ後の新しいコンテンツへの到達率、タイマー補助使用後の完了率などだ。目的はプレイヤーを評価することではなく、機能が約束した役割を果たしているか確認することにある。

サポートへの問い合わせ、レビュー、コミュニティの議論、インタビューを定期的に分類し、肯定・否定だけを数えるのではなく、本来の意味を保つ。「誤解を招く選択肢」「字幕が速すぎる」「キャラクターの動機が不明」など、繰り返されるテーマをノードとバージョンに結び付ける。データは異常のある場所を示し、プレイヤーの言葉はその理由を理解する助けになる。

少数のコメントをそのまま全体の代表として扱ってはいけないし、全体平均で具体的な障害を否定してもいけない。2種類の証拠を相互に照合する。

選択肢の文言を変える前に、期待する結果を書き出す。理解の誤りが減り、送信率が上がり、同時に関係性の分岐に対する満足度は下がらないこと。ホットフィックス後は目標指標とガードレール指標を観察し、完了率を上げる一方で意味のある迷いを失わないようにする。

すべての分布を最適化する必要はない。作品が意図的にある選択をつらくしたり、あるエンディングを希少にしたりすることもある。プレイヤーが理解し、技術が信頼でき、創作目標に合っていれば、均等さを求める必要はない。

必要な匿名イベントだけを収集し、適切な通知と制御手段を提供し、ポリシーに従ってアクセスと保存期間を制限する。内部テスト、ボット、重複送信、異常な時計データを除外する。ダッシュボードにはイベントのバージョン、サンプル数、データの遅延を表示する。データパイプラインを信頼できない場合は、重大なコンテンツ判断を一時停止する。

初日は起動、クラッシュ、ダウンロード、セーブなどの進行を阻む問題に注目する。最初の週はチャプターファネルと繰り返されるフィードバックを見て、サンプルが安定してから選択とエンディングを分析する。数十人のコアファンをもとに早々に物語を変えると、ノイズを増幅しやすい。各レビューで観察、解釈、証拠の強さ、決定、再確認の時期を記録する。

コンテンツ実験と緊急修正は分ける。誤った経路の修正は速やかに公開できる。選択肢の意味やエンディング条件を変える場合は、バージョンの明示、ガードレール指標、プレイヤーへの説明が必要になる。そうしなければ、変更前後のコホートが異なる作品に接するため、データを直接比較できない。

次のステップ：選択率、チャプター完了、リプレイ、エンディング分布について、それぞれ正確な定義、分母、集計を分ける軸、実行につなげられるアクションを記す。10件のテストセッションで手動再計算し、ダッシュボードと生のイベントが一致することを確認する。