Telemetry · Learning note · English
A missing event does not prove a student gave up
Eight starts, six question opens, three submissions. The count is clear; the story behind it is not.
Imagine a small practice-question app that logs flow_started, question_opened, and answer_submitted. After a demo, its file holds 18 fictional event rows. Someone asks, “How many students finished?”
That file cannot answer the question. It contains trial IDs, not people. A person could try twice, and a trial can generate several rows. We can count distinct recorded trials at each step:
| Recorded event | Distinct trial IDs |
|---|---|
flow_started | 8 |
question_opened | 6 |
answer_submitted | 3 |
The recorded count falls by two and then by three. Those are gaps in a file. They do not prove that two people left one screen and three left the next. Someone may have stopped, the app may have crashed, a request may have failed, or a log event may not have arrived.
Count attempts, then ask what the count means
If the fictional CSV is loaded as a table named prototype_events, this query checks the three recorded counts:
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;It returns 8, 6, 3. COUNT(*) would answer a different question: how many rows arrived. If the app retries a delivery, duplicate rows could inflate that count. A stable trial ID helps, but only if the app generates and reuses it correctly. Reusing an old ID for a new attempt would hide that attempt from a DISTINCT count.
What would help separate the explanations?
A server-side submission_accepted event could show that an answer arrived even if the browser event did not. A client error event could identify some failed attempts. An explicit exit action could confirm a deliberate stop when that exit event is recorded. Each new signal has its own coverage and delivery limits; absence is still not proof of intent.
This matters well beyond a classroom app. A chart of recorded events is easily mistaken for a story about people. Before changing a screen or declaring a prototype unsuccessful, name the unit you counted and list the explanations the current data cannot rule out.