이벤트 기록이 없다고 학생이 포기했다고 단정할 수는 없습니다

연습 문제 앱이 시작, 문제 열기, 답안 제출을 기록한다고 가정해 봅시다. 시연 후 파일에는 가상 이벤트 18행이 있습니다. '몇 명의 학생이 끝냈나요?'라는 질문에는 이 파일만으로 답할 수 없습니다. 사람의 ID가 아니라 시도 ID를 담고 있기 때문입니다. 한 사람이 여러 번 시도할 수 있고, 한 번의 시도로 여러 행이 생길 수도 있습니다.

기록된 시도 수는 첫 단계에서 2건, 다음 단계에서 3건 줄어듭니다. 이는 파일의 차이일 뿐, 누군가 해당 화면에서 포기했다는 증거는 아닙니다. 사용자가 멈췄거나 앱 또는 네트워크에 문제가 생겼거나 로그가 도착하지 않았을 수 있습니다.

시도를 센 다음, 그 숫자의 의미를 묻기

가상 CSV를 prototype_events라는 테이블에 불러오면 다음 SQL로 세 수치를 확인할 수 있습니다. 가상 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를 올바르게 만들고 재사용해야 합니다. 새로운 시도에 예전 ID를 잘못 쓰면 DISTINCT 집계에서 그 시도가 빠집니다.

원인을 구분하려면 어떤 증거가 더 필요할까요?

서버의 submission_accepted 이벤트가 있다면 브라우저 기록이 없어도 답안이 도착했음을 확인할 수 있습니다. 클라이언트 오류 기록은 일부 실패를 설명할 수 있습니다. 명시적인 종료 동작이 기록된 시도에서는 의도적인 종료를 확인할 수 있지만, 그 기록이 없다는 이유만으로 의도를 추론할 수는 없습니다. 새로 추가한 기록에도 누락과 관측 범위의 한계가 있습니다.

화면을 바꾸거나 시제품이 실패했다고 판단하기 전에 무엇을 단위로 셌는지, 현재 데이터로 배제할 수 없는 설명은 무엇인지 밝혀야 합니다. 이벤트 그래프만으로 사람의 경험을 알 수는 없습니다.