Comment le suivi des événements enregistre ce que les utilisateurs ont vraiment fait

Qu'est-ce que le suivi des événements en product analytics ?

Les outils de product analytics utilisent le suivi des événements pour enregistrer des actions utilisateur nommées comme signup_completed ou checkout_started avec des propriétés qui décrivent chaque action, ce qui transforme des données de trafic par page en relevé de ce que les gens ont vraiment fait. Une page vue dit que quelqu'un a atteint l'écran de checkout. Un événement dit qu'il a démarré le checkout, sur le plan annuel équipe, depuis la page de tarifs, et qu'il n'est jamais revenu. Flowsery livre le suivi des objectifs et des événements à côté de son web analytics intégré, si bien que le même compte contient les chiffres de trafic et le relevé au niveau des actions.

Quelles sont les deux parties d'un événement ?

Un événement a un nom et un ensemble de propriétés, et la répartition entre les deux décide si la donnée reste interrogeable un an plus tard. Le nom identifie l'action et reste constant à chaque occurrence. Les propriétés portent ce qui change d'une occurrence à l'autre: quel plan, quelle source, combien, combien de temps. Mettez l'action dans le nom et les variables dans les propriétés, et chaque question sur cette action devient un filtre au lieu d'un nouvel événement.

Cinq événements avec de bonnes propriétés répondent à plus de questions que cinquante événements sans aucune. Ces cinq-là soutiennent un funnel d'inscription, une comparaison de checkout plan par plan, un rapport sur les codes promo et une métrique d'expansion d'équipe sans un seul appel de tracking supplémentaire. Les noms de propriétés de ce tableau suivent le motif object_adjective que PostHog documente dans ses bonnes pratiques de product analytics, avec is_ réservé aux booléens.

À quoi ressemble un événement mal nommé à côté d'un bon ?

Un événement mal nommé pousse le détail variable dans le nom, ce qui fait éclater une action en un nouvel événement pour chaque combinaison. Voici la même inscription, suivie deux fois.

// Mal suivi: le plan et la page sont figés dans le nom
track("Clicked Signup Button On Pricing Page Annual");
track("clicked_signup_button_on_pricing_page_monthly");
track("Signup Btn - Homepage");
 
// Bien suivi: un seul nom stable, les variables en propriétés
track("signup_completed", {
  signup_source: "pricing_page",
  plan_slug: "team_annual",
  is_invited: false
});

Le premier bloc produit trois noms d'événement pour une seule action, si bien que la réponse à "combien de personnes se sont inscrites la semaine dernière" est une somme manuelle qui casse dès que quelqu'un ajoute une quatrième page de tarifs. Le second bloc produit un nom d'événement et trois filtres. Demandez à un marketeur de nommer l'action à voix haute, puis vérifiez que tout ce qu'il a dit après le verbe a fini dans une propriété, pas dans le nom.

Quelle convention de nommage d'événements une équipe doit-elle choisir ?

La convention qui marche est celle qui est écrite et appliquée à chaque événement, et les deux conventions publiées ne sont pas d'accord sur les détails. Les bonnes pratiques de product analytics de PostHog demandent du snake_case en minuscules, des verbes au présent et une structure category:object_action comme account_settings:forgot_password_button_click. Le playbook de planification de données d'Amplitude demande du Title Case avec une structure [Noun] + [Past-Tense Verb] comme Song Played, gardée du point de vue de l'utilisateur, si bien que Message Sent veut dire que l'utilisateur l'a envoyé.

Les deux marchent. Les mélanger, non, parce que Signup Completed, signup_completed et signup:button_click deviennent trois lignes sans rapport dans la même liste. Les exemples de cet article utilisent du snake_case avec des verbes au passé, ce qui se lit objet puis action et trie ensemble tous les événements liés par ordre alphabétique: checkout_completed atterrit à côté de checkout_started.

Une contrainte dure se place sous la convention que vous choisissez. Les limites de collecte d'événements GA4 de Google plafonnent un nom d'événement à 40 caractères, autorisent 25 paramètres d'événement par événement, plafonnent un nom de paramètre à 40 caractères et la plupart des valeurs de paramètre à 100 caractères, et ne posent aucune limite au nombre d'événements nommés distinctement pour les flux de données web tout en plafonnant les flux de données app à 500 par utilisateur de l'app. Un nom category:object_action suivi d'un nom long atteint ce plafond de 40 caractères plus vite que les équipes ne le pensent, et GA4 arrête silencieusement de rapporter comme événement clé un nom trop long.

En quoi le suivi des événements diffère-t-il de l'autocapture ?

Le suivi des événements nomme l'action dans le code de l'application avant la livraison, tandis que l'autocapture enregistre automatiquement chaque clic et chaque soumission de formulaire et vous laisse définir le sens après coup à partir de la structure de la page. L'autocapture donne à une équipe un flux fonctionnel dès le premier jour et casse en silence quand une refonte change le sélecteur CSS auquel elle correspondait. Un événement nommé se déplace avec le code où il vit, donc le renommage d'un composant emporte l'appel de tracking avec lui. La plupart des équipes font tourner les deux: l'autocapture pour la longue traîne exploratoire, les événements nommés pour les chiffres qui apparaissent dans un deck de board.

Comment les propriétés transforment-elles des événements en funnel ?

Deux événements qui partagent une propriété deviennent une étape de conversion, et c'est ainsi qu'un funnel de conversion se construit à partir de données d'événements brutes. Le taux de complétion d'une étape tient en une division:

step conversion rate = completed events / started events x 100

Avec 4,000 événements checkout_started et 1,240 événements checkout_completed sur une semaine, l'étape de checkout convertit à 31 pour cent. Ajoutez plan_slug comme répartition et ce chiffre unique se scinde en un taux par plan, et c'est là que le vrai problème apparaît. Les propriétés sont aussi ce à partir de quoi les dimensions personnalisées se construisent, donc le schéma que vous concevez pour les événements est le même schéma qui segmentera vos rapports plus tard.

Combien d'événements une équipe doit-elle instrumenter ?

Instrumentez les actions qui apparaissent dans une décision, et arrêtez-vous là. Un événement que personne n'a filtré depuis trois mois est de la dette de schéma: il coûte du quota, il encombre le sélecteur d'événements, et il se dégrade sans que personne le remarque. Commencez par les étapes du chemin vers le revenu, ajoutez les actions qui séparent un compte retenu d'un compte perdu, puis ajoutez de nouveaux événements quand une question précise n'a aucune donnée derrière elle.

Un schéma plus petit garde aussi la surface de vie privée petite. Flowsery est sans cookies et hébergé dans l'UE par conception, et les propriétés qu'une équipe choisit de ne pas envoyer sont celles qui n'auront jamais besoin d'une politique de rétention. Les équipes qui pèsent ce compromis face à une installation orientée Google peuvent lire la comparaison entre analytics respectueux de la vie privée et GA4.

Comment vérifier qu'un événement se déclenche correctement ?

Déclenchez l'action vous-même, puis confirmez que l'événement est arrivé avec le bon nom et les bonnes propriétés avant de faire confiance au moindre graphique bâti dessus. L'échec le plus coûteux est un événement qui part avec une propriété nulle ou mal orthographiée, puisque le compte a l'air sain pendant que chaque répartition perd des lignes en silence. Regarder une vraie session à côté du flux d'événements attrape l'écart d'une façon qu'un dashboard ne peut pas: Flowsery enregistre chaque session utilisateur et se connecte aux replays PostHog ou Amplitude déjà enregistrés, sans réinstrumentation, donc le replay et le journal d'événements se retrouvent côte à côte.

Refaites ce contrôle après chaque livraison front-end qui touche un parcours suivi. Un événement qui a cessé de se déclencher produit une ligne plate, et une ligne plate se lit comme un problème produit jusqu'à ce que quelqu'un ouvre le code.

Questions fréquentes

Qu'est-ce qu'un événement en analytics ?

Un événement est une seule action nommée qu'un utilisateur a faite, enregistrée avec un horodatage et un ensemble de propriétés qui la décrivent. checkout_started avec plan_slug: team_annual est un événement. Une page vue est un type d'événement particulier, enregistré automatiquement par la plupart des scripts d'analytics.

Quelle est la différence entre un nom d'événement et une propriété d'événement ?

Le nom identifie l'action et reste identique à chaque occurrence, ce qui permet de le compter. La propriété porte le détail qui change entre les occurrences, ce qui permet de filtrer et de grouper. Tout ce sur quoi vous voudriez filtrer appartient à une propriété, jamais au nom.

Les noms d'événements doivent-ils être au passé ou au présent ?

Les deux conventions sont publiées et les deux marchent, alors choisissez-en une et faites-la respecter. Le playbook de planification de données d'Amplitude documente du Title Case avec des verbes au passé, et les bonnes pratiques de PostHog documentent du snake_case en minuscules avec des verbes au présent. Le coût d'un changement en cours de route, ce sont deux jeux de noms qui décrivent les mêmes actions.

Combien de propriétés un seul événement doit-il porter ?

Envoyez les propriétés sur lesquelles vous filtreriez ou grouperiez, et laissez le reste. GA4 autorise 25 paramètres d'événement par événement d'après les limites de collecte d'événements de Google, ce qui est un plafond et non un objectif. Cinq à huit propriétés bien choisies sur un événement central couvrent la plupart des questions de reporting.

Le suivi des événements exige-t-il des cookies ?

Non. Enregistrer qu'une action a eu lieu n'a besoin d'aucun cookie, puisqu'un cookie existe pour faire persister une identité entre les visites plutôt que pour capturer l'action elle-même. Flowsery fonctionne sans cookies et hébergé dans l'UE, et enregistre quand même les événements avec leurs propriétés.

Qu'est-ce qui casse un schéma d'événements avec le temps ?

Les événements renommés, les événements ajoutés au coup par coup sans convention, et les propriétés qui cessent d'être remplies après un refactor. Chacun laisse le graphique intact pendant que la donnée sous-jacente dérive. Une convention de nommage écrite plus un contrôle après chaque livraison sur les parcours suivis en évitent la plus grande partie.

Qu'est-ce que la dette de schéma dans le suivi des événements ?

La dette de schéma est un événement que personne n'a filtré depuis trois mois. Elle coûte du quota, encombre le sélecteur d'événements et se dégrade sans que personne ne le remarque, jusqu'à ce que quelqu'un audite le schéma.

L'autocapture peut-elle remplacer les événements nommés ?

La plupart des équipes utilisent les deux plutôt que de choisir l'un ou l'autre. L'autocapture couvre la longue traîne exploratoire et donne à une équipe un flux fonctionnel dès le premier jour, mais elle casse silencieusement quand une refonte change le sélecteur CSS qu'elle ciblait. Les événements nommés couvrent les chiffres qui apparaissent dans un rapport pour la direction, car renommer un composant emporte l'appel de tracking avec le code où il vit.

Quelle est la limite de caractères GA4 pour un nom d'événement ?

Google limite un nom d'événement à 40 caractères dans GA4 et limite aussi un nom de paramètre à 40 caractères, la plupart des valeurs de paramètre étant plafonnées à 100 caractères. Une structure category:object_action plus un nom long atteint cette limite plus vite que prévu, et GA4 arrête silencieusement de signaler un nom trop long comme événement clé.

Comment calcule-t-on un taux de conversion de funnel à partir d'événements ?

Divise les événements terminés par les événements démarrés et multiplie par 100. Avec 4 000 événements checkout_started et 1 240 événements checkout_completed en une semaine, l'étape de paiement convertit à 31 pour cent. Ventiler ce chiffre par une propriété comme plan_slug transforme un taux unique en un taux par plan.