Fondations et concepts clés de la digital analytics

Ouvrez n'importe quel rapport analytics et trois chiffres apparaissent côte à côte : users, sessions, events. Ils décrivent le même trafic, ils ne correspondent jamais aux chiffres du système financier, et presque toutes les disputes sur « les analytics qui se trompent » se révèlent être des disputes sur le sens de ces trois mots. L'objet au centre de la digital analytics est construit, pas trouvé. Quelqu'un a décidé ce qui compte comme event, quand une session expire, et quel identifiant tient lieu de personne. Cette leçon définit cet objet, puis montre d'où les données viennent physiquement : le navigateur, ou vos propres serveurs.

Ce qu'est réellement la digital analytics

La digital analytics est la collecte et l'interprétation des enregistrements d'interaction avec des produits et canaux digitaux : sites web, applications, objets connectés, emails, blocs publicitaires. Ce qui la distingue du reste de votre patrimoine de données, c'est l'unité d'enregistrement. Un CRMCRMCustomer Relationship Management : logiciel et stratégie pour gérer et analyser les interactions clients tout au long de leur cycle de vie.Voir la définition complète → stocke des lignes sur des clients. Un grand livre stocke des lignes sur des transactions. La digital analytics stocke un flux ordonné dans le temps de petits faits comportementaux, chacun horodaté, rattaché à une identité et à un contexte, puis les agrège à la demande.

Le vocabulaire, énoncé une fois et avec précision :

• Event : une interaction enregistrée. Un nom plus un ensemble de paramètres (le Web SDK d'Adobe les appelle des champs XDM ; d'autres outils parlent de properties). add_to_cart avec item_id, price, currency est un event.
• Session, appelée visite dans Adobe Analytics : un groupe d'events issus de la même identité, clos par un timeout d'inactivité, conventionnellement 30 minutes.
• User, appelé visiteur : un identifiant, pas un être humain. Le plus souvent un cookie ou un device ID, parfois un identifiant de connexion.
• Dimension : un attribut selon lequel vous segmentez. Pays, type d'appareil, source de trafic, nom de page.
• Métrique : un nombre que vous agrégez. Events, sessions, revenu, panier moyen.
• Hit : la primitive plus ancienne, un appel unique au serveur de collecte. Adobe Analytics a compté les pages vues et les appels de liens personnalisés de cette manière pendant deux décennies ; le modèle event-based l'a absorbé.

Sous-concept 1 : l'event, et ce qui y est rattaché

Un event a trois parties : ce qui s'est passé (le nom), les détails (les paramètres), et qui et quand (identité et timestamp). Tout le reste en analytics n'est que de l'arithmétique appliquée à cela.

Prenez un service de streaming comme Spotify. Une écoute est un event. Ses paramètres portent le titre, le fait que l'écoute vienne d'une recherche, d'une playlist enregistrée ou d'une recommandation algorithmique, le type d'appareil, et jusqu'où l'auditeur est allé dans le morceau avant de passer au suivant. Aucun de ces éléments n'est un rapport distinct. Ce sont des champs sur un seul enregistrement, et les rapports sont construits ensuite en les comptant et en les groupant.

C'est pourquoi le design des events décide des questions auxquelles vous pourrez répondre. Si l'event d'écoute ne porte pas la source de l'écoute, aucun dashboard, quel que soit son prix, ne vous dira si les recommandations battent la recherche. Vous ne pouvez pas récupérer un paramètre que vous n'avez jamais envoyé. La méthode de construction de ce schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → relève d'une leçon ultérieure ; ce qui compte ici, c'est de comprendre que l'event est l'atome et que ses paramètres sont la limite de votre curiosité future.

Sous-concept 2 : sessions et users sont des conventions, pas des faits

Une session n'existe pas dans la nature. C'est une règle de regroupement. GA4 en ouvre une avec un event session_start et la ferme après 30 minutes sans activité ; Adobe Analytics applique un timeout de visite comparable, configurable par report suite. Universal Analytics démarrait une nouvelle session dès que la source de campagne changeait en cours de visite, ce qui gonflait le nombre de sessions pour quiconque cliquait sur plusieurs publicités. GA4 a abandonné cette règle. Même comportement, chiffre différent, parce que quelqu'un a changé une définition.

« User » est encore plus flou. Ce que vous comptez, c'est un identifiant : un cookie first-party dans un navigateur, un app instance ID sur un téléphone, ou un identifiant de connexion si la personne s'authentifie. Une personne sur un ordinateur portable, un téléphone et une enceinte connectée, cela fait trois identifiants jusqu'à ce qu'une connexion les recolle. Un compte partagé dans un foyer, c'est l'inverse : plusieurs personnes compressées en un seul user. Safari limite à sept jours les cookies écrits par JavaScript, si bien qu'un visiteur revenant au deuxième mois peut arriver comme un user entièrement nouveau.

Traitez un décompte de users comme un décompte d'identifiants sous une règle de stitching énoncée. Écrivez la règle. Quand deux outils divergent de 20 %, c'est généralement pour cette raison.

Sous-concept 3 : dimensions contre métriques, et scope

Les dimensions décrivent, les métriques mesurent. « Recherche organique » est une valeur de dimension ; « 1 482 sessions » est une métrique. Chaque rapport est une ou plusieurs métriques ventilées par une ou plusieurs dimensions, c'est pourquoi l'appariement doit être licite.

Le piège est le scope. Une dimension peut être attachée à un event (la page où un clic a eu lieu), à une session (le canal qui a démarré la visite), ou à un user (première source d'acquisition, pays d'inscription). Les métriques ont aussi un scope. Demandez un taux de rebond, une métrique au niveau session, ventilé par une dimension au niveau event, et l'outil renverra quelque chose. Ce sera absurde.

Adobe a rendu cette distinction explicite bien avant la plupart des outils, avec les props (variables de trafic qui décrivent le hit et ne persistent pas) et les eVars (variables de conversion qui persistent selon une expiration définie et prennent le crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →édit des events de succès ultérieurs). Même valeur dans les deux, comportement d'attributionattributionUn framework qui attribue le crédit d'une conversion aux différents touchpoints y ayant contribué, afin de mesurer quels canaux et quelles interactions génèrent réellement des résultats.Voir la définition complète → différent, rapport différent. Les dimensions à forte cardinalité sont l'autre danger : mettez une URL brute avec ses query strings dans une dimension et vous générez des centaines de milliers de valeurs uniques, la plupart des outils regroupent la traîne dans « (other) », et votre rapport cesse discrètement de faire la somme.

Sous-concept 4 : collecte client-side et server-side

Chaque event arrive dans vos analytics depuis l'un de deux endroits.

La collecte client-side s'exécute dans le navigateur de l'utilisateur ou dans votre application mobile : du JavaScript ou un SDK observe une interaction et envoie une requête à un endpoint de collecte. Elle voit des choses qu'aucun serveur ne verra jamais : profondeur de scroll, survols, abandon de formulaire, taille d'écran, le referrer, le fait que la vidéo se soit réellement lancée. Elle est aussi fragile. Les ad blockers la bloquent, les limites de confidentialité des navigateurs raccourcissent ses identifiants, les connexions mobiles faibles perdent des beacons, et n'importe qui peut forger une requête vers l'endpoint.

La collecte server-side envoie l'event depuis une infrastructure que vous contrôlez, généralement le backend de votre application, après confirmation du fait. Commandes, remboursements, renouvellements d'abonnement, échecs de paiement et annulations pour fraude relèvent de ce côté, parce que votre serveur connaît la vérité et le navigateur ne connaît que ce qu'on lui a dit. Adobe (qui vend une suite analytics, lisez donc ses recommandations en conséquence) prend en charge les deux voies : un SDK navigateur pour les données d'interaction, et une APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → server-side d'insertion de données pour les events qui naissent dans vos systèmes.

Un troisième dispositif, le server-side tagging, garde le navigateur comme origine mais route le premier saut vers un container que vous exploitez, lequel redistribue ensuite les données vers les vendors. Il restaure une part de résilience et vous donne un point de contrôle où les règles de consentement et de PII peuvent être appliquées avant que quoi que ce soit ne sorte.

La plupart des stacks sérieuses font tourner les deux côtés et doivent ensuite les réconcilier. Décidez à l'avance quel côté fait foi pour chaque chiffre. Le revenu depuis le serveur. Le comportement d'interaction depuis le client. N'additionnez jamais les deux en appelant cela un total.

Cas réels

Spotify Wrapped, lancé chaque décembre depuis 2016, est la démonstration publique la plus claire de ce qu'est un flux d'events. Rien n'y provient d'un sondage ou d'un dashboard. C'est une année d'events d'écoute individuels, chacun portant un titre, un artiste, un timestamp et un contexte, rejoués par auditeur et comptés. Le produit n'est possible que parce que l'atome a été conçu pour contenir assez de détail.

La trajectoire d'Adobe elle-même montre l'objet redéfini sous une industrie. Adobe Analytics a été construit autour du hit : une page vue ou un appel de lien personnalisé, décrit par des props et des eVars. Son Web SDK plus récent envoie à la place des experience events au format XDM, plus proches du modèle schemaschemaUn schema est le plan formel qui définit comment les données sont structurées, nommées, typées et reliées entre elles au sein d'une base de données, d'un fichier ou d'un message.Voir la définition complète →-first vers lequel le reste du secteur a convergé. Même vendor, mêmes clients, une unité d'enregistrement différente, et toutes les comparaisons historiques ont dû être reconstruites autour d'elle.

Actions pour le CMO

• Publiez une fiche de définitions d'une page : ce qui clôt une session, ce qu'est un identifiant, comment l'activité connectée et anonyme est recollée, ce que signifie « utilisateur actif » dans votre entreprise. Diffusez-la à la finance et à vos agences. La plupart des litiges de mesure s'arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →êtent là.
• Pour chacun de vos dix principaux chiffres reportés, notez s'il est collecté client-side ou server-side. Si le revenu vient du navigateur, déplacez-le.
• Vérifiez le scope des dimensions de vos rapports standards avant d'agir sur une ventilation. Une métrique de session ventilée par une dimension d'event s'affichera sans broncher et vous induira en erreur.

Erreurs courantes qui tuent les résultats

• Lire « users » comme « personnes ». C'est un décompte d'identifiants sous une règle de stitching, et cette règle change chaque fois qu'un éditeur de navigateur modifie sa politique de cookies.
• Comparer des nombres de sessions entre deux outils dont les règles de timeout et de campagne diffèrent, puis demander à votre équipe d'expliquer l'écart. Il n'y a pas d'écart à expliquer, seulement deux définitions.
• Supposer que la donnée server-side est une vérité neutre. Elle est aveugle à tout ce que l'interface a fait et ne porte que l'identité que vous avez pensé à transmettre.
• Laisser entrer des URL brutes, des chaînes de recherche ou des ID dans les dimensions sans regroupement, puis se demander pourquoi une grosse ligne « (other) » avale la traîne de chaque rapport.