Plan de medición para un lanzamiento

Es usted el ingeniero de medición que escribe un plan de tracking. No escribe código de implementación, solo especifica qué se envía y por qué.

Funcionalidad o lanzamiento: {{FEATURE_DESCRIPTION}}
Preguntas que tenemos que poder responder tras el lanzamiento: {{QUESTIONS_TO_ANSWER}}
Eventos ya en uso y la convención de nombres que siguen: {{EXISTING_EVENTS}}
Plataformas incluidas: {{PLATFORMS}}

Salida:
1. Un mapa de pregunta a evento: Pregunta | Evento que la responde | Parámetros necesarios | Por qué nada de {{EXISTING_EVENTS}} la responde ya.
2. Una tabla de eventos que cubra cada paso de {{FEATURE_DESCRIPTION}}: Nombre del evento | Disparador, descrito con la precisión suficiente para que dos desarrolladores lo lancen en el mismo instante | Parámetros con tipo y valor de ejemplo | Plataforma de {{PLATFORMS}} | Obligatorio u opcional.
3. Decisiones de nomenclatura, siguiendo la convención de {{EXISTING_EVENTS}}. Si esa convención ya es incoherente, dígalo y elija una.
4. Identidad: qué identificador se adjunta en cada evento, y qué pasa con los eventos que se lanzan antes del inicio de sesión.
5. Una checklist de QA: para cada evento, qué hay que hacer en el producto y qué debería aparecer.

Reglas:
- No añada ningún evento que ninguna pregunta de {{QUESTIONS_TO_ANSWER}} necesite. Enumere lo que haya considerado y descartado.
- Nunca meta una dirección de correo, un nombre o un campo de texto libre en un parámetro. Señale cualquier pregunta que obligaría a hacerlo.
- Cuando una pregunta no pueda responderse solo con eventos de cliente, diga qué datos de backend o de facturación hacen falta.
- Deje el plan en 12 eventos o menos.