1594. Identidad de la lección
Esta lección convierte una pregunta de diseño en una especificación de telemetría pequeña y revisable. No implementa un sistema de seguimiento ni produce un panel de métricas.
1595. Objetivo de aprendizaje
Al terminar esta lección, podrás redactar una especificación mínima de telemetría que conecte cada evento con una decisión, defina un esquema sin ambigüedades, minimice y clasifique los datos identificativos y establezca límites útiles de muestreo e interpretación.
1596. Por qué importa
La telemetría solo es útil cuando sus datos pueden respaldar una decisión de diseño concreta. Un nombre de evento sin un significado preciso genera una falsa sensación de certeza: dos personas pueden recopilar el mismo evento e interpretarlo de formas distintas. Recopilar demasiado también aumenta la exposición de privacidad y el coste de mantenimiento sin mejorar la decisión.
Los identificadores requieren especial cuidado. Un identificador de partida o sesión no es anónimo por definición. Puede ser seudónimo o permitir vincular registros según cómo se genere, cuánto tiempo persista, qué otros campos lo acompañen y quién pueda acceder a él. Por eso, una especificación precisa define el alcance, la rotación, la vinculación, la conservación y el acceso de los identificadores, en lugar de limitarse a afirmar que no hay datos personales.
Una especificación precisa ofrece a un asistente de programación con IA un contrato comprobable para una implementación posterior, pero mantiene en el desarrollador la responsabilidad sobre el significado de los datos y la justificación de su recopilación.
1597. Conocimientos previos
Ya deberías poder:
- Formular una decisión de gameplay y la evidencia que podría informarla.
- Distinguir una acción del jugador de una interpretación sobre su intención.
- Aplicar el enfoque de la lección anterior, centrado en decisiones, para rechazar métricas sin un propósito accionable.
- Describir el estado de gameplay relevante sin implementar un sistema de telemetría.
La lección anterior, 4.4 L1 — Mide una decisión, no un panel de fantasía, estableció que la telemetría comienza con una decisión y no con una lista de cifras interesantes.
1598. Concepto central
Un evento de telemetría es un contrato de medición, no simplemente un mensaje de registro.
Una especificación útil responde cinco preguntas:
- ¿Qué ocurrió? Define el hecho observable de gameplay.
- ¿Cuándo ocurrió? Define la transición de estado aceptada u otro disparador semántico, e indica si las repeticiones son válidas.
- ¿Qué contexto hace falta? Incluye solo los campos necesarios para interpretar el evento o respaldar la decisión indicada.
- ¿Qué tan completa y representativa es la medición? Declara los supuestos sobre muestreo, datos faltantes y duplicados.
- ¿Qué no debe inferirse? Registra la ambigüedad y los límites de interpretación.
Un conjunto mínimo no es el que tiene menos nombres de eventos a cualquier precio. Es el conjunto más pequeño capaz de responder la decisión actual sin depender de supuestos ocultos.
Usa esta ficha para cada evento:
Nombre del evento
Decisión que respalda
Disparador
Campos obligatorios y valores permitidos
Clasificación, alcance y rotación de identificadores
Vinculación prohibida o permitida
Límites de conservación y acceso
Regla de muestreo
Comportamiento ante duplicados y reintentos
Gestión de datos faltantes
Ambigüedad conocida
Interpretaciones fuera de alcance
1599. Modelo mental
Usa la cadena Decisión → Evento → Contexto → Límites:
| Etapa | Pregunta | Prueba |
|---|---|---|
| Decisión | ¿Qué podría cambiar a partir de esta evidencia? | Nombra una elección concreta de diseño. |
| Evento | ¿Qué hecho observable proporciona la evidencia? | Describe un disparador semántico, no una motivación ni una entrada que el juego haya rechazado. |
| Contexto | ¿Qué campos permiten interpretar el hecho? | Elimina los campos que no afectan la decisión. |
| Límites | ¿Qué podría volver incompleta o engañosa la evidencia? | Declara el muestreo, los datos faltantes, los duplicados, el tratamiento de identificadores y la ambigüedad. |
Si un campo no puede justificarse dentro de esta cadena, elimínalo o márcalo como fuera de alcance. Si no puedes nombrar la decisión, todavía no crees el evento.
1600. Reglas de muestreo que se pueden revisar
No basta con escribir «muestreado» o indicar un porcentaje. Una regla de muestreo útil especifica:
- Población elegible: ¿Qué partidas, sesiones, versiones u ocurrencias pueden entrar en la muestra?
- Unidad de muestreo: ¿La selección se realiza por partida, por sesión, por jugador o por evento individual?
- Método o tasa de inclusión: ¿Cómo se selecciona la unidad y con qué tasa estable?
- Coherencia entre eventos vinculados: Una vez incluida una unidad, ¿se registran juntos todos los eventos necesarios para la comparación?
- Límites de interpretación: ¿Qué poblaciones o conductas pueden quedar sobrerrepresentadas, ausentes o ser demasiado inciertas para compararlas?
Usa esta plantilla breve:
Población elegible:
Unidad de muestreo:
Método o tasa de inclusión:
Coherencia entre eventos vinculados:
Límites de interpretación:
La captura completa registra todas las ocurrencias elegibles, sujeta a los límites de entrega y conservación. Puede ser adecuada para un evento infrecuente y central para la decisión, pero no elimina los datos faltantes ni la ambigüedad.
Una muestra estable por partida selecciona una partida elegible una sola vez mediante una regla aleatoria documentada y después registra todos los eventos vinculados necesarios para comparar esa partida. Por ejemplo, una partida seleccionada registra tanto la revelación de la ruta como su selección cuando se produzcan.
No muestrees por separado eventos vinculados de revelación y selección. Si cada evento se selecciona de forma independiente, puede conservarse una revelación y descartarse su selección correspondiente, o al revés. La proporción resultante mezclaría la conducta de gameplay con pérdidas causadas por el muestreo y no permitiría realizar la comparación prevista sin correcciones adicionales.
1601. Ejemplo concreto
Supón que la pregunta de diseño es: ¿Hay que señalizar con más claridad la primera ruta opcional? El equipo necesita comparar la exposición a la ruta con su selección. No necesita un registro completo de cada acción del jugador ni afirma medir el abandono sin definir antes un resultado observable de abandono.
Una especificación austera podría incluir estos eventos:
Evento: optional_route_revealed
Decisión respaldada: Decidir si hace falta ajustar la facilidad para descubrir la ruta.
Disparador: Durante una partida elegible activa, el juego cambia route_alpha de no revelada a revelada por primera vez.
Campos: run_id, route_id, progress_band, reveal_source
Valores permitidos:
route_id = route_alpha
progress_band = early | middle | late
reveal_source = environmental_cue | interaction | unknown
Clasificación del identificador: run_id es un identificador seudónimo, generado al azar y limitado a la sesión.
Alcance y rotación: Generar un run_id nuevo para cada partida; no reutilizarlo entre partidas.
Vinculación: No vincular run_id con una cuenta, una huella del dispositivo, una ubicación ni otro identificador persistente.
Conservación y acceso: Conservar los registros por partida solo durante el periodo de análisis documentado y eliminarlos después; limitar el acceso a las personas que realizan el análisis indicado.
Minimización de datos: No recopilar nombres de cuenta, texto libre, huellas del dispositivo, ubicación ni campos ajenos a la decisión.
Muestreo: Captura completa de los eventos elegibles porque el evento es infrecuente y central para la decisión.
Duplicados: Como máximo un evento por route_id y run_id.
Datos faltantes: Si no se recibe el evento, clasificar la exposición como desconocida; no tratar la ausencia como prueba de que la ruta no se reveló.
Ambigüedad: El evento muestra que la ruta pasó a ser observable, no que el jugador la viera o la comprendiera.
Fuera de alcance: No inferir la motivación del jugador a partir de este evento.
Evento: optional_route_selected
Decisión respaldada: Comparar la selección de la ruta después de la exposición.
Disparador: Durante la misma partida elegible, el juego acepta la transición de ruta y cambia la ruta activa a route_alpha.
Campos: run_id, route_id, progress_band, selection_order
Valores permitidos:
route_id = route_alpha
progress_band = early | middle | late
selection_order = first_choice | later_choice
Tratamiento del identificador: Aplicar la misma clasificación, alcance, rotación, vinculación, conservación y límites de acceso de run_id.
Muestreo: Captura completa para la misma población elegible que optional_route_revealed.
Coherencia: La revelación y la selección comparten la misma decisión de inclusión por partida; nunca se muestrean por separado.
Duplicados: Como máximo un evento de selección de route_alpha por intento de ruta.
Datos faltantes: Si faltan los datos de exposición o selección, excluir la partida de una comparación completa o marcarla como incompleta; no contarla silenciosamente como una no selección.
Ambigüedad: La selección no demuestra que la ruta se eligiera a causa de la revelación.
Fuera de alcance: No tratar la no selección como confusión sin evidencia adicional.
Observa lo que no aparece: entradas en bruto, movimiento del ratón, explicaciones en texto libre, identificadores de cuenta, huellas persistentes del dispositivo ni afirmaciones sobre la intención del jugador. Los eventos permiten una comparación, pero no demuestran causalidad. El identificador se clasifica y se somete a reglas aunque sea temporal y no esté vinculado a una cuenta.
1602. Flujo de trabajo con IA
Usa la IA como revisora de la especificación, no como autoridad sobre lo que debe medirse.
- Escribe tú primero la decisión y un borrador del evento.
- Pide a la IA que detecte disparadores indefinidos, campos innecesarios, riesgos de identificación o vinculación, duplicados, datos faltantes, reglas de muestreo incompletas y afirmaciones que excedan la evidencia.
- Compara la revisión con las reglas reales del gameplay y rechaza las sugerencias que añadan recopilación sin aportar valor a la decisión.
- Revisa la especificación manualmente.
- Pide a la IA que convierta el contrato final en una lista de comprobación. Verifica que conserve el disparador, los campos, los límites de los identificadores, la unidad de muestreo, la coherencia entre eventos vinculados, la regla para datos faltantes y las notas de ambigüedad.
Prompt útil:
Revisa esta especificación de telemetría como una persona revisora de esquemas. No añadas eventos salvo que una decisión de diseño declarada los requiera. Señala disparadores ambiguos, campos innecesarios, riesgos de clasificación o vinculación de identificadores, límites ausentes de conservación o acceso, duplicados, reglas de muestreo incompletas, gestión de datos faltantes e interpretaciones que los datos no pueden respaldar. Agrupa los hallazgos por evento.
No pidas a la IA que implemente un sistema de seguimiento en esta lección. El entregable es el contrato de medición, no el código.
1603. Errores comunes
Considerar que el contexto no tiene coste
Campos como entradas en bruto, respuestas de texto libre, marcas temporales demasiado precisas, identificadores de cuenta o identificadores persistentes del dispositivo pueden crear problemas de privacidad e interpretación sin responder la decisión actual. Clasifica cada identificador, limita su alcance y rotación, prohíbe la vinculación innecesaria entre partidas y declara los límites de conservación y acceso.
Muestrear por separado eventos vinculados
Una revelación y su selección posterior forman una comparación dentro de la misma partida. Muestrearlas por separado puede producir registros sin correspondencia y distorsionar la relación aparente. Selecciona primero una unidad estable y registra de forma coherente los eventos vinculados de esa unidad.
Tratar una ausencia como un resultado
Un evento ausente puede indicar un fallo de entrega, una sesión interrumpida, una exclusión debida a la regla de muestreo o un caso no observado. Define si la ausencia se clasifica como desconocida, incompleta o excluida. No la conviertas silenciosamente en éxito, fallo, cancelación o ausencia de ocurrencia.
Registrar una entrada en vez del hecho de gameplay
Una pulsación puede reasignarse, rechazarse, bloquearse o ignorarse. Si el evento pretende medir una cancelación, actívalo cuando el juego acepte la acción y cambie el intento al estado cancelado.
1604. Práctica guiada
Crea una especificación para esta decisión:
¿Debe ajustarse el coste de un intento fallido, o se está interpretando mal la tasa de fallo porque los jugadores cancelan antes de completar el intento?
Usa un contexto de gameplay pequeño e inventado: el jugador inicia una interacción arriesgada, puede completarla o cancelarla y puede recibir un resultado de fallo. No implementes nada.
Redacta como máximo tres eventos. Para cada uno, completa esta plantilla:
Nombre del evento:
Decisión respaldada:
Disparador:
Campos obligatorios y valores permitidos:
Clasificación de identificadores:
Alcance y rotación de identificadores:
Límites de vinculación:
Límites de conservación y acceso:
Población elegible:
Unidad de muestreo:
Método o tasa de inclusión:
Coherencia entre eventos vinculados:
Límites de interpretación del muestreo:
Comportamiento ante duplicados o reintentos:
Gestión de datos faltantes:
Ambigüedad conocida:
Interpretación no respaldada:
Tu especificación debe incluir un evento que distinga el inicio de un intento de la recepción de su resultado. Decide si hace falta un evento de cancelación; inclúyelo solo si cambia la decisión. Si lo incluyes, usa como disparador la transición aceptada al estado cancelado, no la pulsación de una entrada en bruto.
Después realiza una pasada de minimización y completitud:
- Elimina al menos un campo o evento candidato que solo resulte interesante y anota por qué lo rechazaste.
- Sustituye las motivaciones inferidas por estados o secuencias observables.
- Clasifica cada identificador y define su alcance, rotación, vinculación, conservación y límites de acceso.
- Declara si las ocurrencias elegibles se capturan por completo o se muestrean.
- Si se muestrean eventos vinculados, usa una sola decisión de muestreo estable para toda la unidad de comparación.
- Define qué ocurre cuando un evento se reintenta, se duplica, llega tarde o falta.
- Nunca cuentes silenciosamente los datos faltantes como éxito, fallo, cancelación o ausencia de ocurrencia.
1605. Evaluación práctica
Entrega la especificación de una página mediante la evaluación práctica asociada. Este artefacto es la principal evidencia evaluada de la lección. El cuestionario sirve como comprobación complementaria.
1606. Validación / evidencia
La especificación cumple el estándar de la lección cuando:
- Todos los eventos incluidos respaldan la misma decisión de diseño nombrada.
- Cada disparador describe una condición semántica y observable de gameplay.
- Los campos obligatorios tienen significados o valores delimitados.
- Se rechaza explícitamente al menos un campo o evento candidato con una justificación vinculada a la decisión.
- Cada identificador está clasificado y tiene límites de alcance, rotación, vinculación, conservación y acceso.
- La regla de muestreo identifica la población elegible, la unidad, el método o tasa de inclusión, la coherencia entre eventos vinculados y los límites de interpretación.
- El comportamiento ante duplicados, reintentos, retrasos y datos faltantes está explícito.
- La ocurrencia del evento se distingue de la intención del jugador.
- Cada evento documenta al menos una ambigüedad o interpretación no respaldada.
- No se exige implementar un sistema de seguimiento, construir un panel ni afirmar una motivación del jugador.
Un compañero o una IA que actúe como revisora deberían poder determinar cuándo se activa cada evento, qué registros pueden compararse, cómo se gestionan los identificadores y cómo se trata la evidencia incompleta sin preguntarte qué querías decir.
1607. Comprobación de conocimientos
Usa el cuestionario asociado para comprobar si reconoces disparadores semánticos, contexto necesario, muestreo coherente y límites de los datos faltantes. Usa la evaluación práctica para demostrar que puedes redactar y minimizar la especificación completa.
1608. Ideas clave
- La telemetría es un contrato de medición conectado con una decisión de diseño concreta.
- Define transiciones de gameplay aceptadas en lugar de motivaciones o entradas en bruto cuando lo importante sea la transición.
- Un identificador temporal puede seguir siendo seudónimo o permitir vinculaciones; clasifícalo y somételo a límites.
- Una regla de muestreo útil nombra la población, la unidad, el método de inclusión, la coherencia entre eventos vinculados y los límites de interpretación.
- Muestrea los eventos vinculados de forma coherente para no confundir pérdidas de muestreo con conductas de gameplay.
- La telemetría mínima exige justificar tanto lo que se elimina como lo que se recopila.
1609. Siguiente lección
Continúa con 4.5 — Balance con datos. La siguiente lección evaluará qué puede respaldar un conjunto de datos recopilado y qué no, una vez documentados sus límites de muestreo, datos faltantes y ambigüedad.
1610. Comprobación
Responde estas preguntas por tu cuenta antes de leer las respuestas.
¿Cuál es el disparador más sólido para un evento destinado a medir una cancelación?
Mostrar respuesta y explicación
Respuesta: Mientras hay un intento activo, el juego acepta la acción de cancelar y cambia el intento al estado cancelado.
Por qué: La transición aceptada al estado cancelado es el hecho semántico y observable que se quiere medir. Una entrada en bruto puede ignorarse, bloquearse o reasignarse; las demás opciones infieren un estado interno.
¿Cuándo debe incluirse un campo en un esquema de evento mínimo?
Mostrar respuesta y explicación
Respuesta: Cuando sea necesario para interpretar el evento o respaldar la decisión declarada.
Por qué: Un esquema mínimo incluye solo el contexto necesario para interpretar el evento o respaldar la decisión declarada. La curiosidad futura, las sugerencias de la IA y la identificación precisa no justifican la recopilación.
¿Qué regla de muestreo conserva mejor una comparación entre la revelación y la selección de una ruta?
Mostrar respuesta y explicación
Respuesta: Seleccionar partidas elegibles con una única regla aleatoria documentada y registrar después ambos eventos vinculados en cada partida seleccionada.
Por qué: Una decisión de inclusión estable por partida mantiene comparables los eventos vinculados. Muestrear cada evento por separado puede dejar revelaciones y selecciones sin correspondencia, mezclando pérdidas de muestreo con conductas de gameplay.
¿Por qué deben documentarse los duplicados, los reintentos y los datos faltantes?
Mostrar respuesta y explicación
Respuesta: Para evitar que los problemas de entrega o los registros ausentes se confundan con otras ocurrencias o resultados de gameplay.
Por qué: Sin reglas para duplicados, reintentos y datos faltantes, el comportamiento de entrega o los registros ausentes pueden distorsionar los recuentos y volver ambigua la evidencia de gameplay.