互動影遊上線後看什麼數據：選擇率、完成率、重玩率與結局分布

互動影遊上線後，播放量只能說明入口被打開過。真正能改進作品的數據是：玩家到達哪個節點、是否完成選擇、選擇後是否繼續、是否回來看另一條路，以及結局分布是否符合設計意圖。

最小事件包括：story_start、node_enter、choice_impression、choice_submit、node_complete、ending_reach、replay_start。每筆事件帶匿名使用者或裝置識別碼、工作階段、作品版本、節點、分支和時間。

工作階段中斷規則要明確，例如 30 分鐘無活動即結束。否則使用者隔天回來會被錯誤算成一次超長觀看。

節點到達率 = 到達節點的不重複工作階段數 / 開始作品的工作階段數。用於定位流失，但需結合前一節點時長與載入錯誤。

選擇提交率 = 提交選擇次數 / 看見選擇次數。低值可能來自文案難懂、按鈕遮擋、倒數計時或技術故障。

選擇率 = 某選項提交次數 / 該節點全部提交次數。它描述分布，不直接代表哪個選項更好。

完成率 = 到達任一結局次數 / 開始作品次數。應按版本、裝置與來源拆分。

重玩率 = 完成後在觀察期間內重新進入有效分支的使用者數 / 完成使用者數。不要把誤重新整理和斷線恢復算成重玩。

後悔率：選擇後很快返回或重新開始附近節點的比例。它可能表示玩家後悔，也可能表示按鈕誤觸，需要結合停留時間和裝置檢查。

結局分布：各結局占完成使用者的比例。過度集中可能是設計有明顯最優解，也可能是其他路徑有 bug；到達人數極少的結局則要檢查前置條件是否過嚴。

選擇點前大量流失，先查節奏和載入；看見選項卻不提交，查 UI 與文案；某選項幾乎無人選擇，檢查它是否顯得無條件更差；重玩低，檢查第二輪遊玩是否提供新資訊及回看工具；結局異常集中，檢查狀態與提示。

按作品版本展示漏斗、節點熱圖、選擇分布、結局分布與 7/30 日重玩。所有指標都應顯示樣本數，樣本小不做誇張結論。還要區分內部測試、創作者預覽和真實使用者。

競品通常不會公開這些內部數據，因此本文是方法建議，不代表任何平台實際表現。DramaFork 應從第一版就統一事件字典，避免作品增加後才發現舊數據無法比較。

每筆事件至少包含事件名稱、匿名主體、工作階段、作品與版本、節點與選項、用戶端時間、伺服器接收時間、裝置和來源。狀態值不必把完整劇情或使用者輸入上傳，可以記錄必要的列舉值、雜湊或結果類別。事件命名和欄位型別形成版本化數據字典，變更時說明相容方式。

重複提交、離線快取和斷線重傳可能把一次選擇記成多次。用戶端產生事件 ID，伺服器端以冪等方式去重；時間順序以伺服器時間和單調序列共同判斷。創作者預覽、自動測試與正式流量必須帶環境欄位，否則內部點擊會污染作品指標。

節點到達下降，先查上一段是否過長、媒體錯誤或路徑條件導致無法到達；選擇曝光高而提交低，檢查按鈕遮擋、文案理解和限時壓力；提交後大量退出，檢查結果是否與選項承諾衝突；重玩開始高卻很快結束，可能是已讀跳過不足或新內容太晚出現。

結局分布需要同時展示到達該結局的前置路徑和樣本數。某結局只有百分之一使用者到達，可能是隱藏獎勵，也可能是條件 bug；設計目標決定是否異常，不能機械地追求均勻。

紀錄能告訴團隊哪裡發生變化，卻不能單獨解釋為什麼。針對異常節點回看錯誤紀錄、可用的匿名操作序列和使用者訪談，並詢問玩家看到了什麼、期待什麼、為何離開或重新開始。不要把相關性直接寫成劇本因果，也不要用小樣本百分比製造確定性。

隱私上採用數據最小化原則：只蒐集改進體驗所需欄位，說明用途和保留期限，限制存取，並為刪除和匯出請求建立流程。自由文字和生成式對話風險更高，預設不應進入一般分析表。一個有用的儀表板不僅算得準，也讓團隊知道哪些數據根本不該蒐集。