Ouvrez n'importe quel outil d'analytics conçu ces cinq dernières années, on vous dira la même chose : tout est un événement. Une page vue est un événement. Un scroll est un événement. Un achat est un événement. Ça ressemble à un détail technique dont le développeur se chargera. Ce n'en est pas un. Ça change ce que vous pouvez mesurer, ce que vous obtenez gratuitement, et la quantité de travail qui vous sépare d'un rapport exploitable.
GA4 en a fait la norme pour une grande partie du web, et beaucoup d'équipes ont migré sans qu'on leur explique ce que ce modèle implique vraiment. Cet article explique ce qu'est réellement le modèle événementiel, ce qu'il vous apporte, ce qu'il casse en silence, et dans quels cas l'ancienne façon de penser donne encore la meilleure réponse.
Ce que veut vraiment dire « modèle événementiel »
La question, c'est comment votre outil stocke une visite. Trois modèles se sont succédé.
Par page vue. L'outil enregistre un hit par page chargée. Vous savez où les gens sont allés et dans quel ordre. Tout ce qui n'est pas un chargement de page, un clic sur un bouton, une vidéo lancée, un formulaire commencé puis abandonné, reste invisible sauf si vous greffez un suivi supplémentaire.
Par session. L'outil regroupe ces pages vues dans une session, une visite avec un début et une fin. Les événements existent ici aussi, et c'est généralement là que naît la confusion : Universal Analytics suivait très bien les clics sur un bouton. Mais un événement était un second type de hit, avec son schéma rigide catégorie, action, libellé, accroché à une session qui restait l'unité de référence. Le taux de rebond, la durée de session et les pages par session existent parce que c'est la session qu'on compte.
Par événement. Il ne reste qu'un seul type de hit. Une page vue, un scroll, un clic et un achat sont le même enregistrement : un nom, un horodatage, et les paramètres que vous y avez attachés. La page vue n'a plus de statut particulier, c'est simplement un événement qui s'appelle page_view. Les sessions existent toujours, mais elles sont calculées à partir du flux au lieu d'être la chose stockée.
Le basculement n'est donc pas que les événements sont apparus. C'est que le nombre de types d'enregistrement est passé de deux à un, et que la page vue a perdu sa place privilégiée.
Ce dernier basculement fait tout. Dès qu'une page vue cesse d'être un cas à part, l'outil n'a plus d'opinion sur ce qui compte chez vous. C'est à la fois le cadeau et la facture.
Ce que le modèle apporte vraiment
Il serait malhonnête de présenter ça comme une régression. Le modèle événementiel résout de vrais problèmes que le modèle par session ne savait pas traiter.
- Une seule forme pour tout. Une vidéo lancée, un filtre appliqué, une offre sélectionnée et une inscription sont stockés à l'identique, donc tous comptables, segmentables et plaçables dans un funnel de la même manière. Sous le modèle par session, tout ce qui n'était pas une page vue était un citoyen de seconde zone.
- Plus de plafond à ce que vous mesurez. Si votre produit tient dans une seule page, le modèle par page vue voit une visite et rien d'autre. Le modèle événementiel voit chaque action utile. Pour toute interface qui ressemble à une application, c'est la différence entre avoir des données et ne pas en avoir.
- Des funnels sur ce que vous voulez. Comme les étapes ne sont que des événements, un funnel peut mélanger librement visites de pages et actions personnalisées : arrivé sur la page tarifs, ouvert le sélecteur d'offre, démarré le paiement, acheté. Vous n'êtes plus limité à des suites d'URL.
- Le même modèle sur le web et en application. Une session ne veut pas dire la même chose dans une app mobile et sur un site. Un événement, si, et c'est pour ça que les outils multiplateformes ont convergé vers lui.
Ce qu'il casse
Voici la partie que les guides de migration passent sous silence.
Rien n'existe tant que vous ne l'avez pas défini. Sous le modèle par session, l'outil savait ce qu'était une page vue, donc les rapports existaient dès le premier jour. Dans un modèle purement événementiel, l'outil ne connaît que ce que vous lui avez dit. Si personne ne nomme et n'envoie un événement « demande de devis », aucun rapport n'affichera jamais de demandes de devis, et rien ne vous préviendra que le chiffre est absent plutôt que nul.
Le nommage devient le vrai travail. C'est le dérapage que personne n'anticipe. Trois équipes taguent le même bouton en un an et vous vous retrouvez avec cinq noms d'événement pour une seule action. Aucun ne s'agrège. Chaque rapport doit en choisir un et sous-compter en silence.
La cardinalité devient une vraie contrainte. Pousser un numéro de commande ou une URL complète dans un paramètre semble anodin. À volume, ça produit des milliers de valeurs distinctes, et les outils réagissent en plafonnant, en regroupant dans un panier « autre », ou en supprimant le détail. La donnée a l'air complète et ne l'est pas.
Votre historique n'est plus comparable. Un « taux de rebond » par session et un « taux d'engagement » par événement ne mesurent pas la même chose : comparer une année sur l'autre à cheval sur une migration, c'est rapporter deux définitions différentes. Bon à savoir avant que quelqu'un présente ce graphique en comité.
Plus de lignes, donc plus d'estimations. Les modèles événementiels multiplient le nombre d'enregistrements, et certains outils répondent aux grosses requêtes en les échantillonnant. Sur GA4, ce n'est pas hypothétique : ses rapports d'exploration sont échantillonnés au-delà d'un seuil, et c'est un problème à part entière (voir pourquoi les rapports GA4 sont des estimations).
Trois modèles, ce que vous obtenez vraiment
Côte à côte, sur les points qui décident de votre semaine :
| Par page vue | Par session | Par événement | |
|---|---|---|---|
| Rapports utiles dès le premier jour | Oui | Oui | Seulement ce que vous avez tagué |
| Mesure les actions hors page | Non | En greffe | Nativement |
| Fonctionne sur les applications monopage | Non | En partie | Oui |
| Tunnels mêlant pages et actions | Non | Limité | Oui |
| Effort de mise en place avant d'en tirer quelque chose | Aucun | Faible | Continu |
| Survit à trois équipes et deux ans | Rien ne dérive | Dérive modérée | Exige une convention de nommage |
| Comparable entre web et application | Non | Non | Oui |
Trois de ces sept lignes ne vont pas au modèle événementiel, et ce sont les plus faciles à sous-estimer au moment de choisir un outil. Il gagne sur la capacité et perd sur la discipline, et c'est la discipline qui lâche en silence.
Quand l'ancienne façon de penser gagne encore
Soyons directs : beaucoup de sites étaient mieux servis par le modèle qu'on leur a fait quitter.
Si votre site, c'est quelques dizaines de pages de contenu et un formulaire de contact, les questions intéressantes sont : quelles pages attirent du trafic, lesquelles perdent les gens, et combien de demandes sont arrivées. Ce sont des questions de pages vues et de sessions. Le modèle événementiel y répond aussi, mais il vous demande de configurer pour retrouver une information que vous obteniez gratuitement.
Le raisonnement par sessions reste aussi le bon angle chaque fois que l'unité de valeur est réellement la visite. Pour les médias, la documentation et la plupart du marketing de contenu, la question est « jusqu'où cette visite est-elle allée », et c'est une pensée en forme de session, quelle que soit la façon dont la donnée est stockée en dessous.
La règle honnête : plus votre site se comporte comme une application, plus le modèle événementiel mérite son coût. Plus il se comporte comme un ensemble de documents, plus ce coût est de la pure surcharge.
Comment Sublim vous aide
Sublim prend la bonne moitié du modèle événementiel sans vous tendre la page blanche. Les événements courants sont captés dès le chargement du script : pages vues, engagement, téléchargements, leads de formulaire et ajouts au panier sont là avant que quiconque ait défini quoi que ce soit, et vos rapports de base fonctionnent dès le premier jour. Au-delà, un événement personnalisé tient en un appel sublim.trackEvent() avec paramètres et revenu optionnels, et vous pouvez lister les noms d'événements que votre site a réellement enregistrés au lieu de deviner ce qui a été tagué, ce qui est généralement la façon dont on repère une dérive de nommage. Les funnels acceptent indifféremment visites de pages et événements personnalisés comme étapes, et associer un événement à un objectif en fait une conversion analysable. Et si vous préférez ne pas faire transiter tout ça par un tag manager, ce chemin est couvert aussi (voir le suivi des événements sans GTM).
