1581. Identidad de la lección
Esta lección establece un criterio de telemetría centrado en las decisiones. Un evento útil no es simplemente un dato que se puede recopilar: es una evidencia que puede informar una decisión de diseño concreta.
1582. Objetivo de aprendizaje
Al terminar esta lección, podrás rechazar eventos de telemetría que no respalden una decisión de diseño definida o que excedan los límites de lo que sus datos pueden demostrar legítimamente.
1583. Por qué importa
Un panel grande puede dar una sensación de control sin ayudar a nadie a elegir una acción. En un juego, un diseñador puede querer saber si los jugadores evitan una ruta arriesgada, no comprenden un objetivo o cancelan una interacción después de que se presenta un coste. Cada pregunta necesita evidencias diferentes. Si un evento no está vinculado a una decisión, la IA puede ayudar a generar nombres y consultas, pero no puede darle un propósito válido. La telemetría centrada en decisiones mantiene la medición conectada con el criterio de diseño, en lugar de convertirla en una colección de datos por sí misma.
1584. Conocimientos previos
Ya deberías poder:
- distinguir una señal observable de una interpretación;
- definir un plan pequeño de observabilidad con interpretación, responsable y respuesta;
- separar una pregunta de gameplay de una preferencia de presentación;
- identificar la acción del jugador y el estado del juego relevantes para una decisión.
El prerrequisito inmediato es 4.3 L2 — Diseña un plan pequeño de observabilidad.
1585. Concepto central
Toda propuesta de evento necesita un contrato de decisión:
- Decisión: ¿Qué decisión de diseño podría informar esta evidencia?
- Propósito del evento: ¿Qué acción o estado del jugador registra el evento?
- Alcance: ¿A qué jugadores, segmento de sesión, versión, contexto o periodo describe?
- Límite de interpretación: ¿Qué puede sugerir este evento y qué no puede demostrar?
Rechaza el evento cuando falta la decisión, cuando el evento no mide el comportamiento relevante, cuando el alcance no está definido o cuando la interpretación afirma más de lo que permiten los datos.
Usa esta prueba:
Si este evento cambiara, ¿qué consideraríamos cambiar en el juego?
Si la respuesta es “nada”, el evento puede ser interesante, pero todavía no respalda una decisión.
1586. Modelo mental
Usa la cadena Decisión → Evidencia → Alcance → Límite.
| Paso | Pregunta | Señal de fallo |
|---|---|---|
| Decisión | ¿Qué elección podría cambiar con esta evidencia? | La propuesta dice “interesante” o “útil” sin nombrar una acción. |
| Evidencia | ¿Qué evento registra un comportamiento relevante para esa elección? | El evento registra una estadística cercana, pero no el comportamiento en sí. |
| Alcance | ¿Dónde y cuándo se aplica la evidencia? | Se usa un total de toda la sesión para explicar un encuentro concreto. |
| Límite | ¿Qué explicaciones alternativas siguen abiertas? | El evento se trata como una prueba de motivación, confusión o disfrute. |
La cadena no sirve para recopilar más eventos. Sirve para filtrar y eliminar los que no pueden respaldar una decisión defendible.
1587. Ejemplo concreto
Supón que un encuentro de sigilo contiene un atajo arriesgado. La pregunta de diseño es:
¿Debemos hacer más visible el atajo, o su bajo uso es una elección intencional de jugadores que comprenden el riesgo?
Considera tres eventos propuestos:
encounter_started: registra que el jugador entró en el encuentro.shortcut_seen: registra que el juego presentó la señal del atajo mientras el jugador estaba en el estado del encuentro definido para esa señal.shortcut_used: registra que el jugador eligió el atajo.
encounter_started aporta contexto, pero no responde si los jugadores vieron el atajo. shortcut_used mide la elección, pero por sí solo no muestra si los jugadores vieron la opción y la rechazaron. shortcut_seen aporta evidencia de que el juego presentó la señal, aunque tampoco demuestra que el jugador la viera o entendiera el riesgo.
Un plan acotado podría comparar shortcut_seen y shortcut_used entre jugadores que llegaron al encuentro, dentro de una versión y un contexto de encuentro definidos. Una exposición alta con poco uso podría respaldar una decisión sobre visibilidad solo si se combina con otras evidencias, como intentos de interacción observados o un cambio controlado en la presentación. No demuestra que a los jugadores no les gustara el atajo ni que les resultara confuso.
El objetivo no es seleccionar automáticamente los tres eventos. Es declarar qué decisión puede respaldar cada uno y rechazar cualquier interpretación que supere sus evidencias.
1588. Error común
El error común es considerar valiosa una métrica porque es precisa, fácil de agregar o visualmente impresionante. Un dato como “acciones promedio por sesión” puede ser correcto y aun así no tener relación con la decisión sobre un encuentro específico. Otro error es interpretar una correlación como intención: los jugadores que cancelan una interacción después de una advertencia pueden haberla entendido mal, haber cambiado de prioridad, haber encontrado un problema técnico o simplemente haber elegido otra estrategia. La telemetría reduce las posibilidades; no lee directamente la motivación del jugador.
1589. Práctica guiada
Evalúa los siguientes eventos propuestos para una sola pregunta:
¿Debería cambiarse el coste de una interacción arriesgada porque los jugadores la evitan?
Para cada evento, escribe una frase para cada campo del contrato de decisión:
session_durationinteraction_prompt_showninteraction_confirmedinteraction_cancelled_after_promptresource_spent_on_interaction
Después clasifica cada evento como conservar, conservar como contexto o rechazar para esta decisión.
Usa estos criterios:
- Conservar: mide directamente un comportamiento relevante para la decisión.
- Conservar como contexto: ayuda a definir el alcance o una explicación alternativa, pero no puede responder por sí solo.
- Rechazar para esta decisión: no tiene un efecto plausible sobre la decisión o su interpretación sería demasiado amplia.
La decisión más importante no es la etiqueta elegida. Es explicar qué cambiaría si la evidencia se comportara de forma inesperada. Por ejemplo, si interaction_cancelled_after_prompt es alto mientras interaction_confirmed es bajo, identifica al menos dos explicaciones posibles antes de recomendar un cambio de diseño.
1590. Validación / evidencia
Tu evidencia será un contrato de decisión completado para al menos tres eventos propuestos. Debe incluir:
- una decisión de diseño explícita;
- la acción o el estado que registra cada evento;
- un alcance definido, como encuentro, segmento de sesión, versión o grupo de comparación;
- un límite de interpretación para cada evento;
- una decisión de conservar, contextualizar o rechazar;
- una declaración sobre qué evidencia adicional haría falta antes de cambiar el juego.
La entrega es satisfactoria si rechaza al menos un evento por una razón relacionada con la decisión, no porque sea simplemente “mal dato”. También debe distinguir entre la evidencia de lo que hicieron los jugadores y las afirmaciones sobre por qué lo hicieron.
1591. Puntos clave
- La telemetría se justifica cuando respalda una decisión de diseño definida.
- El propósito de un evento y su significado no son lo mismo: una acción registrada todavía necesita límites de interpretación.
- El alcance evita convertir una observación local en un patrón universal de los jugadores.
- Un evento útil puede acotar una decisión sin demostrar la motivación del jugador.
- Rechazar telemetría irrelevante forma parte del diseño de observabilidad; no es perder información.
1592. Siguiente lección
Continúa con 4.4 L2 — Especifica un conjunto mínimo de eventos de gameplay.
1593. Comprobación
Responde estas preguntas por tu cuenta antes de leer las respuestas.
¿Qué debe definirse antes de seleccionar los eventos de telemetría?
Mostrar respuesta y explicación
Respuesta: La decisión de diseño que la evidencia podría informar.
Por qué: Un evento de telemetría debe existir en relación con una decisión. Sin una decisión definida, la recopilación puede convertirse en un ejercicio de panel sin un propósito accionable.
¿Por qué es importante definir el alcance al interpretar un evento?
Mostrar respuesta y explicación
Respuesta: Evita tratar una observación local como un patrón universal.
Por qué: El alcance indica dónde y cuándo se aplica la evidencia. Limita las generalizaciones excesivas, aunque no garantiza que toda interpretación sea correcta.
¿Cuál es la razón más sólida para rechazar un evento dentro de un plan de telemetría específico?
Mostrar respuesta y explicación
Respuesta: El evento no puede afectar de forma plausible la decisión definida.
Por qué: Un evento debe evaluarse frente a la decisión que pretende respaldar. Puede ser útil en otro contexto, pero eso no lo hace relevante para este plan.
¿Qué puede establecer normalmente la telemetría sobre el comportamiento del jugador?
Mostrar respuesta y explicación
Respuesta: Un comportamiento observable dentro de un alcance definido.
Por qué: La telemetría registra acciones o estados observables dentro de un alcance definido. Puede acotar las explicaciones, pero no demuestra directamente la motivación ni ofrece una descripción completa de la experiencia.