Telemetry · Nota de aprendizaje · Español
Un evento ausente no demuestra que un estudiante abandonó
Ocho inicios, seis preguntas abiertas, tres envíos. El recuento está claro; la causa, no.
Imagina una pequeña app de ejercicios que registra el inicio, la apertura de una pregunta y el envío de una respuesta. Tras una prueba, el archivo contiene 18 eventos ficticios. Alguien pregunta: «¿Cuántos estudiantes terminaron?». El archivo no puede responder: contiene ID de intentos, no personas. Una persona podría intentarlo dos veces y cada intento podría generar varias filas.
| Evento registrado | ID de intento distintos |
|---|---|
flow_started | 8 |
question_opened | 6 |
answer_submitted | 3 |
El recuento registrado baja en dos intentos y luego en tres. Son huecos en el archivo, no pruebas de que alguien abandonara cada pantalla. Puede que alguien parara, que la app fallara, que una solicitud no llegara o que faltara el evento de registro.
Cuenta intentos y pregunta qué significa el número
Si importas el CSV ficticio en una tabla llamada prototype_events, esta consulta comprueba los tres recuentos: CSV ficticio
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;El resultado es 8, 6 y 3. COUNT(*) contaría las filas recibidas, otra pregunta. Un reintento de envío puede duplicar filas. Un ID estable ayuda, pero solo si la app lo genera y reutiliza bien: usar el mismo ID en un intento nuevo ocultaría ese intento al contar valores distintos.
¿Qué datos permitirían distinguir las causas?
Un evento del servidor, submission_accepted, podría confirmar que llegó una respuesta aunque faltara el evento del navegador. Un evento de error del cliente aclararía algunos fallos. Una acción explícita de salida confirmaría que alguien decidió salir solo en los intentos donde quede registrada. Cada señal también puede perderse; su ausencia sigue sin demostrar intención.
Antes de cambiar una pantalla o declarar que el prototipo fracasó, indica qué unidad has contado y qué explicaciones no permiten descartar los datos. Una gráfica de eventos registrados no cuenta por sí sola la historia de las personas.