缺少事件紀錄，不代表學生放棄了

假設一款練習題應用程式會記錄開始、開啟題目和提交答案。示範後，檔案裡有 18 筆虛構事件。有人問：「有多少學生完成了？」這份檔案回答不了。它記錄的是嘗試 ID，不是人的身分。同一個人可能嘗試多次，一次嘗試也可能產生多筆紀錄。

記錄數量先減少 2，再減少 3。這只是檔案中的缺口，不能證明有人在相應頁面放棄。使用者可能停下，應用程式可能故障，請求可能失敗，日誌事件也可能未送達。

先統計嘗試，再問數字代表什麼

將虛構 CSV 匯入名為 prototype_events 的資料表後，可以用以下查詢核對三個數量： 虛構 CSV

SELECT
  COUNT(DISTINCT CASE WHEN event = 'flow_started' THEN trial_id END) AS started,
  COUNT(DISTINCT CASE WHEN event = 'question_opened' THEN trial_id END) AS opened,
  COUNT(DISTINCT CASE WHEN event = 'answer_submitted' THEN trial_id END) AS submitted
FROM prototype_events;

結果是 8、6、3。COUNT(*) 統計收到的資料列數，回答的是另一個問題。事件重試可能造成重複資料列。穩定的嘗試 ID 有幫助，但前提是應用程式正確產生並重複使用它；若新嘗試誤用了舊 ID，去重計數就會漏掉它。

還需要哪些證據來區分原因？

伺服器端的 submission_accepted 事件可以表明答案已送達，即使瀏覽器事件遺失。用戶端錯誤事件可解釋部分失敗。若明確的退出動作有被記錄，可以確認相應嘗試中的主動退出；沒有這筆紀錄，仍不能推斷意圖。新增的每種信號本身也有涵蓋範圍與送達限制。

在修改介面或宣稱原型失敗前，先說明統計單位，以及現有資料無法排除哪些解釋。事件圖表不會自動告訴我們人的實際經歷。