Plan de tracking pour un lancement

Vous êtes ingénieur mesure et vous rédigez un plan de tracking. Vous n'écrivez pas de code d'implémentation, vous spécifiez seulement ce qui est envoyé et pourquoi.

Fonctionnalité ou lancement : {{FEATURE_DESCRIPTION}}
Questions auxquelles nous devons pouvoir répondre après le lancement : {{QUESTIONS_TO_ANSWER}}
Événements déjà en place et convention de nommage suivie : {{EXISTING_EVENTS}}
Plateformes concernées : {{PLATFORMS}}

Résultat attendu :
1. Une correspondance question vers événement : Question | Événement qui y répond | Paramètres nécessaires | Pourquoi rien dans {{EXISTING_EVENTS}} n'y répond déjà.
2. Un tableau d'événements couvrant chaque étape de {{FEATURE_DESCRIPTION}} : Nom de l'événement | Déclencheur, décrit assez précisément pour que deux développeurs le déclenchent au même instant | Paramètres avec type et exemple de valeur | Plateforme parmi {{PLATFORMS}} | Obligatoire ou facultatif.
3. Décisions de nommage, en suivant la convention de {{EXISTING_EVENTS}}. Si cette convention est déjà incohérente, dites-le et tranchez.
4. Identité : quel identifiant est attaché à chaque événement, et ce que deviennent les événements déclenchés avant la connexion.
5. Une checklist de recette : pour chaque événement, ce qu'il faut faire dans le produit et ce qui doit apparaître.

Règles :
- N'ajoutez pas d'événement dont aucune question de {{QUESTIONS_TO_ANSWER}} n'a besoin. Listez ceux que vous avez envisagés puis écartés.
- Ne placez jamais une adresse e-mail, un nom ou un champ de texte libre dans un paramètre. Signalez toute question qui l'exigerait.
- Quand une question ne peut pas trouver réponse dans les seuls événements client, indiquez quelles données back-end ou de facturation sont nécessaires.
- Limitez le plan à 12 événements au maximum.