# Le plan d’événements

> Canal public — documentation de l’application 4.1.0. Respecter les mentions de disponibilité propres à chaque service.

Source : [Le plan d’événements](/services/analytics/plan-evenements/)

Sur le site, et par ton agent dans l’app 4.0.0 ou plus récente, une fois ton jeu branché.

Le module mesure seul les arrivées, les départs, les achats et les erreurs. Les étapes propres à ton jeu (tutoriel terminé, manche gagnée, boutique ouverte) sont des **événements** que ton agent ajoute dans le code. Le **plan d’événements** en est la liste, et dit pour chacun s’il arrive comme prévu.

## Comment ton agent s’en sert

1.  **Il conçoit le plan avec toi** : chaque événement, à quoi il sert, où il part dans le jeu, et ce qu’il transporte.
2.  **Il le déclare**, puis **écrit le code** qui envoie chaque événement.
3.  **Il marque chaque événement écrit**, avec l’endroit du code qui l’envoie.
4.  **Tu publies et tu joues.** Le plan se vérifie sur les données reçues de ton jeu publié.

Demande-lui simplement « fais le plan d’événements de mon jeu ». Il ne dit jamais qu’un événement marche avant qu’il soit conforme.

## Les cinq états

Le panneau Plan d’événements ouvre la page « Ton jeu » de tes stats. Sa première ligne compte les événements conformes et les écarts ; chaque événement suit avec son état :

| État | Ce qu’il veut dire |
| --- | --- |
| **Prévu** | Déclaré, pas encore écrit dans le code. |
| **Écrit** | Ton agent dit avoir écrit le code. Rien n’est encore arrivé. |
| **Reçu** | Des envois arrivent, sans problème, mais une donnée prévue n’a pas été vue. |
| **Conforme** | Des envois arrivent, avec chaque donnée prévue, au bon format. |
| **Écart** | Des envois arrivent avec un problème. La ligne en dessous dit lequel. |

**Conforme ne vient que des données reçues**, jamais de la parole de ton agent. Le plan se lit sur les 7 derniers jours. Quand ton agent change la forme d’un événement (ses données, leur format, son rôle), il repasse à **Prévu**, et seuls les envois suivants comptent.

## Les causes d’un écart

| Cause affichée | Ce qui se passe |
| --- | --- |
| « La prop … arrive en … ; le plan la déclare en … » | Une donnée arrive dans un autre format que prévu (un texte au lieu d’un nombre). |
| « La prop … manque sur … occurrences » | Une donnée prévue comme obligatoire manque. |
| « Reçu avec le rôle … au lieu de … » | Le code envoie l’événement avec un autre rôle que celui du plan. |
| « … occurrences en quarantaine » | Des envois sont mis à part : ils ne comptent pas dans tes chiffres. |
| « Plus reçu depuis … h alors que le jeu tourne » | L’événement a cessé d’arriver alors que ton jeu a encore des joueurs. |

Un écart se corrige dans le code : demande à ton agent de le régler, puis publie. Un événement échantillonné ou coupé n’est pas compté comme arrêté : le panneau le dit à part.

## Un test dans Studio

Le module dort dans Studio : un test n’envoie rien aujourd’hui, et la vérification se fait sur ton jeu publié. Si des envois venus de Studio existent, l’événement porte la mention « en test Studio ». **Un test dans Studio ne compte jamais dans les chiffres de ton jeu**, ni dans son plafond d’événements.

## Bon à savoir

-   **Vrai ou faux, ou du texte ?** Une donnée « vrai/faux » arrive comme le mot `true` ou `false`. Un texte qui ne contient que ces deux mots ne se distingue donc pas d’un vrai/faux : les deux sont acceptés.
-   Le plan n’existe qu’une fois ton jeu branché : voir [Brancher ton jeu](/services/analytics/brancher/).
-   Écrire le plan revient au propriétaire du projet. Un éditeur avec qui les stats sont partagées le lit, son agent aussi, sans pouvoir le changer.

## Pour aller plus loin

-   [Analytics de jeu](/services/analytics/)
-   [Brancher ton jeu](/services/analytics/brancher/)
-   [Les paliers d’Analytics](/services/analytics/paliers/)