資料埋點不能上線前才想：選擇率、退出點和結局怎樣記錄

互動影遊的埋點應在節點資料定型時設計，因為真正有用的資料必須知道玩家看見了什麼、可以選什麼、最終選了什麼，以及技術上是否成功播放。只記錄按鈕點擊會把未曝光、誤觸、退出和載入失敗混在一起，得出錯誤的劇情判斷。

先列產品問題：玩家在哪一章離開？某個選項沒人選是因為不吸引人，還是根本沒出現？結局少有人到達是條件太難，還是玩家不願走？重玩者在尋找什麼？每個問題對應指標和最少事件，不要把所有介面操作都上傳。

資料不能回答「為什麼」的全部。量化分析發現異常後，再結合可用性觀察、留言和訪談解釋。低選擇率可能是文案、角色價值觀或前置狀態造成，不能自動判定為壞分支。

至少記錄工作階段開始與結束、節點進入、媒體準備成功或失敗、選項曝光、選擇提交、狀態里程碑、結局到達和重玩開始。共用欄位包括匿名工作階段 ID、遊戲版本、平台、語言、節點或選項 ID、時間與必要的實驗版本。

選項曝光事件同時記錄本次可見選項集合和計時規則；提交事件記錄選擇 ID、從曝光到提交的時長、是否逾時。這樣選擇率的分母是「真正看見該選項的人」，不是所有玩家。

程式無法可靠地收到每次關閉通知，尤其是當機、斷電或行動裝置上的程式被系統清除時。可在節點進入與關鍵播放階段記錄輕量心跳，下次啟動再判斷上次工作階段是否未正常結束。區分主動退出、背景逾時、當機和正常結束。

退出點不只記錄節點，還記錄播放進度、是否正在等待選擇、最近一次載入耗時和是否重複觀看。玩家在同一影片的 90% 處離開，可能是內容問題；在 0% 處離開且載入失敗，更像技術問題。

結局事件記錄主要結局 ID、尾聲變體、關鍵狀態摘要、總時長、重試次數和是否使用跳過。不要上傳完整逐影格行為或自由文字，只保留回答設計問題所需的欄位。

為關鍵選擇建立路徑漏斗，而不是儲存每一種完整排列。完整路徑組合會迅速變得稀疏，也增加隱私和分析負擔。通常章節入口、關鍵節點與結局足以定位問題。

事件字典包括名稱、觸發時機、欄位類型、範例、負責人、用途、保留期限和版本。事件名稱保持穩定，新增欄位應向後相容；改變含義時建立新版本，不能悄悄沿用舊欄位。

每個事件只由一個系統觸發。若按鈕、節點管理器和播放器都傳送「選擇完成」，資料會重複。提交成功後產生唯一事件 ID，離線重傳也能去除重複資料。

只蒐集必要資訊，避免姓名、原始裝置識別碼或玩家輸入內容。說明蒐集目的、保留時間與退出方式；適用地區的具體法律要求應由合格人員審查。未同意分析時，遊戲核心流程仍應可執行。

開發日誌與分析資料分開。前者可在本機包含詳細狀態以協助除錯，後者只上傳彙總所需欄位。測試帳號與正式玩家也要標記隔離，避免污染上線資料。

為每個事件撰寫測試案例：何時應出現、何時不應出現、欄位是否合法。跑一條已知路徑，手算預期事件，再與後台逐一比對。測試離線、重新連線、重複提交、跨版本和系統時間異常。

最後製作一張最小儀表板：章節到達率、節點退出率、選項曝光與選擇率、各結局人數、首輪完成時長、重玩啟動率、媒體失敗率。若某個圖表不能支持決策，就不要為了「資料豐富」而長期維護。

每個指標旁邊補一句「它不能說明什麼」。完成率下降不能單獨證明劇情變差，重玩率高也可能來自存檔故障或成就要求。發布改動前保留版本分組，避免把新玩家組成變化誤判為內容效果。樣本很小時展示人數與區間，不用小數點製造確定感。

資料評審要形成行動：繼續觀察、深入研究、修復技術或調整內容，並指定負責人和複查日期。沒有行動的問題不值得持續蒐集更多欄位。

下一步：選三個最重要的設計問題，為每個問題寫指標公式、所需事件和決策門檻；隨後讓測試人員用一條固定路徑核對原始事件，確認分母沒有錯。