イベントが記録されていないだけで、生徒が離脱したとは言えない

問題練習アプリが、開始、問題を開く操作、回答の送信を記録するとします。デモ後のファイルには架空のイベントが18行あります。「何人の生徒が終えたのか」と聞かれても、このファイルでは答えられません。あるのは人のIDではなく試行IDです。同じ人が複数回試すことも、1回の試行で複数行ができることもあります。

記録された試行は最初の段階で2件、次の段階で3件減ります。これはファイル上の差であり、その画面で誰かがやめた証拠ではありません。利用者が止めた、アプリや通信に問題が起きた、ログが届かなかった、などの可能性があります。

試行を数え、その数が何を意味するか考える

架空のCSVを prototype_events というテーブルに読み込めば、次のSQLで3つの数を確かめられます。 架空の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を誤用すると、DISTINCT はその試行を見落とします。

原因を見分けるには、ほかに何が必要か

サーバー側の submission_accepted イベントがあれば、ブラウザー側の記録がなくても回答が届いたことを確認できる場合があります。クライアントのエラー記録から分かる失敗もあります。明示的な終了操作が記録された試行なら、意図的に終了したことを確認できます。しかし、その記録がないだけで意図は推測できません。追加する記録にも欠落や到達範囲の限界があります。

画面を変更したり、試作品は失敗だと判断したりする前に、何を単位として数えたか、今のデータで排除できない説明は何かを明らかにしましょう。イベントのグラフだけでは人の体験は分かりません。