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

インタラクティブ映像ゲームの公開後、再生数からわかるのは入口が開かれたことだけです。作品の改善に本当に役立つデータは、プレイヤーがどのノードに到達したか、選択を送信したか、選択後も続けたか、別のルートを見るために戻ってきたか、そしてエンディング分布が設計意図に合っているかです。

最低限のイベントには、story_start、node_enter、choice_impression、choice_submit、node_complete、ending_reach、replay_startがあります。各イベントには匿名のユーザーまたはデバイスの識別子、セッション、作品のバージョン、ノード、分岐、時刻を記録します。

セッションの終了ルールを明確にする必要があります。例えば、30分間操作がなければ終了とします。そうしないと、翌日に戻ってきたユーザーが、極端に長い1回の視聴として誤って集計されます。

ノード到達率 = ノードに到達したユニークセッション数 / 作品を開始したセッション数。離脱箇所の特定に使いますが、直前のノードの長さや読み込みエラーも併せて確認する必要があります。

選択送信率 = 選択の送信数 / 選択肢の表示数。低い値は、わかりにくい文言、隠れたボタン、カウントダウン、技術的な不具合が原因かもしれません。

選択率 = 特定の選択肢の送信数 / そのノードでの全送信数。分布を表すものであり、どの選択肢が優れているかを直接示すものではありません。

完了率 = いずれかのエンディングへの到達数 / 作品の開始数。バージョン、デバイス、流入元ごとに分けて見る必要があります。

リプレイ率 = 完了後、観測期間内に有効な分岐へ再び入ったユーザー数 / 完了したユーザー数。誤った再読み込みや接続切断からの復帰をリプレイに数えないでください。

後悔率：選択後、すぐに戻ったり、近くのノードを再開したりする割合です。プレイヤーの後悔を示す場合もあれば、ボタンの誤操作を示す場合もあるため、滞在時間やデバイスと併せて確認する必要があります。

エンディング分布：完了したユーザーに占める各エンディングの割合です。過度に集中している場合、設計上明らかな最適解があるか、別のルートにバグがある可能性があります。到達者が極めて少ないエンディングは、前提条件が厳しすぎないか確認する必要があります。

選択地点の前で大量に離脱する場合は、まずテンポと読み込みを確認します。選択肢を見ても送信しない場合は、UIと文言を確認します。ある選択肢がほとんど選ばれない場合は、それが無条件に不利に見えないか確認します。リプレイが少ない場合は、2周目で新しい情報が得られるか、見返すためのツールがあるか確認します。エンディングが異常に集中している場合は、状態とヒントを確認します。

作品のバージョンごとに、ファネル、ノードのヒートマップ、選択分布、エンディング分布、7日／30日のリプレイを表示します。すべての指標にサンプル数を表示し、サンプルが少ないときは誇張した結論を出しません。内部テスト、制作者プレビュー、実際のユーザーも区別する必要があります。

競合サービスは通常、こうした内部データを公開していないため、本記事は方法についての提案であり、いずれのプラットフォームの実績も表していません。DramaForkは最初のバージョンからイベント辞書を統一し、作品が増えた後に過去のデータを比較できないと気づく事態を避けるべきです。

各イベントには、少なくともイベント名、匿名の主体、セッション、作品とバージョン、ノードと選択肢、クライアント時刻、サーバー受信時刻、デバイス、流入元を含めます。状態値の記録のために、物語全体やユーザー入力をアップロードする必要はなく、必要な列挙値、ハッシュ、結果のカテゴリを記録できます。イベント名とフィールドの型をバージョン管理されたデータ辞書にまとめ、変更時には互換性の確保方法を説明します。

重複送信、オフラインキャッシュ、接続切断後の再送によって、1回の選択が複数回記録される可能性があります。クライアントでイベントIDを生成し、サーバーで冪等性を確保して重複を排除します。時系列はサーバー時刻と単調増加するシーケンスを組み合わせて判断します。制作者プレビュー、自動テスト、本番トラフィックには必ず環境フィールドを付けます。そうしないと、内部のクリックが作品の指標を汚染します。

ノード到達が減ったら、まず直前の区間が長すぎないか、メディアエラーがないか、ルート条件によって到達不能になっていないかを確認します。選択肢の表示が多いのに送信が少ない場合は、ボタンの隠れ、文言の理解、制限時間によるプレッシャーを確認します。送信後に大量の離脱がある場合は、結果が選択肢の約束した内容と食い違っていないか確認します。リプレイの開始は多いのにすぐ終わる場合は、既読部分のスキップが不十分か、新しい内容の登場が遅すぎる可能性があります。

エンディング分布には、そのエンディングに到達するための前提ルートとサンプル数を併せて表示する必要があります。ユーザーの1パーセントしか到達しないエンディングは、隠し報酬かもしれませんし、条件のバグかもしれません。異常かどうかは設計目標で決まるため、機械的に均等な分布を目指してはいけません。

ログはどこで変化が起きたかをチームに伝えられますが、それだけでは理由を説明できません。異常のあるノードについて、エラーログ、利用可能な匿名の操作履歴、ユーザーインタビューを見返し、何を見たか、何を期待したか、なぜ離脱または再開したかをプレイヤーに尋ねます。相関関係をそのまま脚本上の因果関係として記述したり、小さなサンプルの割合で確実性を作り出したりしないでください。

プライバシーについては、データ最小化の原則を採用します。体験の改善に必要なフィールドだけを収集し、用途と保存期間を説明し、アクセスを制限し、削除やエクスポートの依頼に対応する手順を整えます。自由記述のテキストや生成AIとの対話はリスクが高いため、原則として通常の分析テーブルに入れるべきではありません。役に立つダッシュボードは、正確に計算するだけでなく、そもそも収集すべきでないデータをチームが理解できるようにするものです。