Comment une convention de nommage des événements survit à son premier renommage

Pourquoi une convention de nommage des événements compte-t-elle ?

Choisir une convention de nommage des événements coûte peu au premier jour et cher au deux centième, parce que Google Analytics 4 n'applique jamais un renommage aux données déjà collectées. Chaque nom incohérent que vous expédiez devient une seconde ligne définitive dans tous les rapports groupés par événement, et le seul moyen de fusionner ces lignes après coup est de recalculer les données vous-même dans un entrepôt.

Le problème n'est ni théorique ni cosmétique. Trois développeurs instrumentent le même bouton sur trois sprints et vous récoltez signup_click, SignupClick et click_signup. GA4 traite les trois comme des événements distincts, car "event names are case sensitive. For example, my_event and My_Event are distinct events." Votre entonnoir se coupe en trois, votre décompte d'événements clés vaut un tiers de la vérité, et personne ne s'en aperçoit avant que quelqu'un ne compare le tableau de bord à Stripe. La discipline plus large est traitée dans le suivi des événements ; cette page parle des noms eux-mêmes.

Quels noms GA4 refuse-t-il d'emblée ?

GA4 rejette les noms et les préfixes réservés, et les règles de nommage de Google annoncent la conséquence sans ambiguïté : "If you try to use a reserved prefix or name, Analytics will display an error message." Les règles qui valent pour tous les noms tiennent en trois lignes :

• "Event names must start with a letter. Use only letters, numbers, and underscores. Don't use spaces."
• "Event names are case sensitive."
• "Event names can include English and non-English words and letters."

Pour les flux de données web, Google réserve query_id comme préfixe et réserve dix-neuf noms d'événements purs et simples. Ceux qui mordent une équipe d'implémentation sont les plus plausibles, ceux vers lesquels vous iriez naturellement :

Réservé sur le web	Pourquoi vous l'auriez choisi
click	Le nom évident pour n'importe quel gestionnaire de clic
error	Le nom évident pour une erreur côté client
scroll	Le nom évident pour un événement de profondeur de défilement
file_download	Le nom évident pour un téléchargement de PDF
page_view	Le nom évident pour une vue de page virtuelle dans une application monopage
session_start	Le nom évident pour l'équivalent d'une ouverture d'application
user_engagement	Le nom évident pour un événement de temps passé
video_start	Le nom évident pour un événement de lecteur vidéo
ad_impression	Le nom évident pour un emplacement d'annonce maison

La plupart de ces événements sont déjà envoyés pour vous par la mesure améliorée, et c'est précisément pour ça qu'ils sont réservés. Vérifiez ce que votre propriété collecte sans configuration avant de nommer quoi que ce soit, et voyez l'autocapture pour ce que la collecte automatique attrape et n'attrape pas.

La référence du Measurement Protocol ajoute une seconde liste, plus longue, qui s'applique quand vous envoyez des événements côté serveur, dont first_open, first_visit, app_exception, os_update et toute la famille firebase_, et note que "ad_impression, in_app_purchase and screen_view events are only allowed for App streams."

Les paramètres ont leurs propres réservations. Le nom firebase_conversion est réservé, et les noms de paramètres "cannot begin with" _, firebase_, ga_, google_ ou gtag.. Les noms de propriétés utilisateur ne peuvent pas commencer par _, firebase_, ga_ ou google_, et les noms first_open_time, first_visit_time, last_deep_link_referrer, user_id et first_open_after_install sont pris.

Quelles limites de longueur s'appliquent ?

Quarante caractères pour le nom d'événement, et la sanction en cas de dépassement est plus étrange qu'un simple rejet. Les limites de collecte d'événements de Google indiquent qu'un nom d'événement va jusqu'à "40 characters," puis ajoutent : "If you mark an event as a key event and the event exceeds 40 characters, then the event will not be reported as a key event because the appended _c will be missing." L'événement continue de se collecter. Il cesse simplement d'être comptabilisable comme événement clé, en silence, parce que GA4 ajoute _c en interne et que le nom ainsi rallongé déborde.

Les limites voisines façonnent une convention autant que la limite de nom :

Limite	Valeur
Longueur du nom d'événement	40 caractères
Noms d'événements distincts, flux web	Aucune limite
Noms d'événements distincts, flux app	500 par utilisateur de l'app
Paramètres d'événement par événement	25
Longueur du nom de paramètre	40 caractères
Longueur de la valeur de paramètre	100 caractères
Valeur page_title	300 caractères
Valeur page_referrer	420 caractères
Valeur page_location	1 000 caractères
Propriétés utilisateur par propriété	25
Longueur du nom de propriété utilisateur	24 caractères
Longueur de la valeur de propriété utilisateur	36 caractères

La valeur de paramètre à 100 caractères est celle qui piège les équipes. Un nom de produit, une requête de recherche ou une chaîne d'erreur de formulaire la dépassera, et c'est la valeur qui est coupée, pas l'événement qui est refusé. Le nom de propriété utilisateur à 24 caractères est plus serré encore, plus court de seize caractères que la limite de nom d'événement, ce qui est une bonne raison de ne pas recopier vos noms d'événements dans vos noms de propriétés utilisateur.

Le nombre illimité de noms d'événements distincts sur le web est un piège plutôt qu'une permission. Rien ne vous empêche d'expédier quatre cents noms d'événements ; les rapports deviennent simplement inutilisables, et chaque nom doit être enregistré comme définition personnalisée avant d'apparaître dans la plupart des analyses. Ce coût d'enregistrement est traité dans la mise en place des dimensions personnalisées.

L'objet ou l'action en premier ?

Le conseil courant est de mettre l'objet en premier, cart_added et video_played, au motif que les rapports trient par ordre alphabétique et que les noms objet d'abord regroupent tous les événements portant sur la même chose. C'est un bon conseil, et il contredit Google.

Les événements recommandés de Google mettent l'action en premier. Le jeu retail à lui seul donne add_payment_info, add_shipping_info, add_to_cart, add_to_wishlist, begin_checkout, purchase, refund, remove_from_cart, select_item, view_item, et le jeu général ajoute earn_virtual_currency, join_group, login, search, select_content, share, sign_up, spend_virtual_currency, tutorial_begin et tutorial_complete.

Ce détail compte parce que les événements recommandés ne sont pas cosmétiques. Google les décrit comme des "standardized events for different business verticals (e.g., retail, travel, games) that unlock prebuilt reporting panels," là où les événements personnalisés sont des "events that you define yourself because no prepopulated automatic, enhanced, or recommended event fits your needs" et sont "accessible using custom reports." Renommer add_to_cart en cart_added pour la cohérence interne vous coûte les rapports e-commerce prêts à l'emploi.

La règle qui tient sépare donc par origine, pas par goût. Utilisez l'orthographe de Google partout où un événement recommandé existe, exactement telle que publiée, et n'appliquez votre propre motif objet d'abord qu'aux événements que Google ne définit pas. Une convention qui produit add_to_cart à côté de pricing_table_viewed a l'air incohérente sur le papier et c'est la seule version qui préserve à la fois les rapports et l'ordre de tri. Quel que soit l'ordre retenu, le snake_case en minuscules est la seule casse qui évite le piège de la sensibilité à la casse, puisqu'une convention où n'importe quel caractère peut varier de casse est une convention qui finira violée.

Choisir l'ordre du nom d'événement

1

Vérifier la liste des événements recommandés. Regarder si Google définit déjà un événement pour ce que vous suivez, comme add_to_cart ou begin_checkout.

2

Correspondance trouvée. Utiliser l'orthographe exacte de Google, action en premier, pour conserver les rapports e-commerce préconstruits.

3

Aucune correspondance. Appliquer votre propre schéma objet en premier à partir d'une liste fermée de verbes et d'objets.

Que coûte le renommage d'un événement après le lancement ?

Il vous coûte votre historique, définitivement, et il vous coûte l'un de vos cinquante emplacements. La documentation de Google sur le renommage d'événements est catégorique sur le premier point : "Modified and new events do not apply to historical data." La modification réécrit les événements à partir de maintenant, et seulement à partir de maintenant. Chaque ligne déjà dans la propriété garde l'ancien nom, et aucun retraitement n'existe pour la corriger.

Deux autres contraintes se tiennent à côté. "An hour or more passes before modifications take effect," donc le correctif n'est même pas immédiat une fois appliqué. Et "you can modify up to 50 existing events and create up to 50 events based on existing events," ce qui fait de la fonction de modification une trousse de secours, pas une couche de nommage sur laquelle vous appuyer indéfiniment.

Le coût concret d'un seul renommage est donc :

• Une coupure définitive dans tous les rapports groupés par nom d'événement, à la date du changement.
• Toute définition d'événement clé, audience ou entonnoir référençant l'ancien nom doit être dupliquée sur le nouveau, sans quoi elle cesse de compter. La différence entre les deux notions est posée dans événements clés et conversions.
• Les comparaisons d'une année sur l'autre à cheval sur la frontière doivent être recousues à la main.
• L'un de vos cinquante emplacements de modification, immobilisé tant que l'ancien nom arrive encore depuis une page en cache ou une version d'app non publiée.

Rien de tout cela ne se rattrape en payant plus ou en attendant plus, et c'est tout l'argument en faveur d'un après-midi passé sur le document de nommage avant que la première balise ne parte.

À quoi ressemble une convention qui tient ?

Une convention, ce sont quatre décisions couchées par écrit, pas une liste de noms. Prenez chacune une fois et la liste s'écrit toute seule.

Casse : snake_case en minuscules uniquement, pour les noms comme pour les paramètres. Lettres, chiffres et underscores sont de toute façon tout ce que GA4 accepte, et les minuscules suppriment le seul moyen pour deux événements identiques de diverger.

Vocabulaire : une liste fermée de verbes et une liste fermée d'objets. view, select, add, remove, submit, start, complete couvre la plupart des sites. Deux verbes qui veulent dire la même chose, c'est ainsi que signup_submit et signup_complete se retrouvent tous les deux en production.

Ordre : l'orthographe de Google là où un événement recommandé existe, l'objet d'abord partout ailleurs, et l'exception écrite noir sur blanc dans le document pour que l'ingénieur suivant ne la normalise pas discrètement.

Placement du détail : le détail variable va dans les paramètres, jamais dans le nom. form_submit avec un paramètre form_name est un événement que vous pouvez filtrer ; newsletter_form_submit, contact_form_submit et demo_form_submit sont trois événements que vous ne pouvez pas comparer sans construire un rapport par formulaire, et ils brûlent trois de vos enregistrements de définitions personnalisées au lieu d'un.

Longueur : gardez les noms sous 40 caractères avec de la marge, parce que la sanction sur les événements clés ajoute _c à ce que vous avez choisi et que l'échec est silencieux.

Foire aux questions

Quels caractères un nom d'événement GA4 peut-il contenir ?

Des lettres, des chiffres et des underscores, et le nom doit commencer par une lettre. Google formule la règle ainsi : "Event names must start with a letter. Use only letters, numbers, and underscores. Don't use spaces." Les lettres non anglaises sont autorisées : "Event names can include English and non-English words and letters."

Les noms d'événements GA4 sont-ils sensibles à la casse ?

Oui. Les règles de nommage de Google indiquent que "event names are case sensitive. For example, my_event and My_Event are distinct events." Il n'y a aucune étape de normalisation, donc deux orthographes du même événement produisent deux lignes indépendantes dans tous les rapports groupés par nom d'événement.

Que se passe-t-il si j'envoie un nom d'événement réservé ?

Analytics le refuse et affiche une erreur. Les règles de nommage d'événements disent que "if you try to use a reserved prefix or name, Analytics will display an error message." Les noms réservés sur le web incluent click, error, scroll, file_download, page_view, session_start, user_engagement et video_start.

Faut-il utiliser objet_action ou action_objet ?

Utilisez l'orthographe exacte de Google pour ses événements recommandés, qui mettent l'action en premier, et l'objet en premier pour tout le reste. Le jeu recommandé de Google contient add_to_cart, begin_checkout, select_item et view_item, et les renommer vous fait perdre les panneaux de rapports prêts à l'emploi que Google y rattache.

Puis-je renommer un événement GA4 après le lancement ?

Vous pouvez le renommer vers l'avant, jamais vers l'arrière. Google indique que "modified and new events do not apply to historical data," que "an hour or more passes before modifications take effect," et que vous "can modify up to 50 existing events and create up to 50 events based on existing events."

Quelle longueur peut faire un nom d'événement GA4 ?

40 caractères. Le dépassement a une conséquence précise, au-delà du simple rejet : Google avertit que "if you mark an event as a key event and the event exceeds 40 characters, then the event will not be reported as a key event because the appended _c will be missing."

Que se passe-t-il si une équipe utilise des noms d'événements incohérents ?

GA4 traite chaque variante comme un événement distinct, car les noms d'événements sont sensibles à la casse. Si trois développeurs nomment le même bouton signup_click, SignupClick et click_signup, cela produit trois lignes séparées dans chaque rapport, le tunnel de conversion se divise en trois et le nombre d'événements clés tombe au tiers de la réalité. Personne ne s'en aperçoit avant qu'on compare le tableau de bord à une autre source de données comme Stripe.

Y a-t-il une limite au nombre de noms d'événements que je peux envoyer à GA4 ?

Un flux web n'impose aucune limite au nombre de noms d'événements distincts, mais cette absence de limite joue contre vous. Les noms d'événements apparaissent d'eux-mêmes, mais chaque paramètre que vous y attachez réclame un emplacement de définition personnalisée, si bien que quatre cents noms donnent des rapports illisibles. Un flux d'application, lui, plafonne à 500 événements distincts par utilisateur.

Quelle est la différence entre un événement personnalisé et un événement recommandé ?

Un événement recommandé est l'un des noms standardisés de Google pour un secteur comme le retail ou le voyage, et Google indique qu'il débloque des panneaux de rapports préconstruits. Un événement personnalisé, vous le définissez vous-même parce qu'aucun événement automatique, amélioré ou recommandé ne correspond, et il n'apparaît que dans les rapports personnalisés que vous construisez. Renommer add_to_cart en cart_added par souci de cohérence interne fait perdre le panneau préconstruit associé.

Les événements clés comptent-ils toujours après le renommage de l'événement qu'ils suivent ?

Pas automatiquement. Toute définition d'événement clé, audience ou tunnel qui pointait vers l'ancien nom doit être dupliquée sur le nouveau nom, sinon elle cesse de compter dès que le changement prend effet. Cette duplication ne coûte aucun emplacement de modification, seul le renommage lui-même consomme l'un des cinquante que GA4 autorise.