Comment recetter son tracking Piano Analytics ? La méthode complète

En bref : recetter son tracking Piano Analytics, c'est vérifier avant chaque mise en production que chaque événement part avec le bon nom, les bonnes propriétés et vers le bon domaine de collecte. Trois outils suffisent : l'extension Tag Inspector, le Stream Inspector du Data Collection Portal et l'onglet Réseau de votre navigateur.

Sur les projets analytics, GA4 aspire toute l'attention. Tapez « comment vérifier mon tracking GA4 » et vous croulez sous les tutos. Tapez la même chose pour Piano Analytics et vous tombez sur la documentation éditeur, très bonne sur l'implémentation, quasi muette sur la recette, puis sur deux ou trois threads. Nous avons donc fabriqué notre propre méthode à force de missions. Je vous la donne au complet.

En quoi la recette Piano Analytics diffère-t-elle d'une recette GA4 ?

La différence est structurelle : sur un projet GA4, vous recettez d'abord un dataLayer, puis la façon dont GTM le transforme en événement. Sur Piano Analytics, il n'y a pas de dataLayer normalisé. Le SDK est appelé directement, et l'événement se déclare via pa.sendEvent() avec son nom et ses propriétés. Votre source de vérité, ce n'est donc pas une couche de données, c'est le plan de marquage confronté au data model Piano.

Deuxième différence : le vocabulaire. Piano Analytics repose sur un modèle événementiel, avec des événements standard nommés selon une convention à point (page.display pour une vue de page, click.navigation pour un clic, transaction.confirmation pour une transaction, av.play pour une lecture média) et plus de 450 propriétés standard disponibles. Une propriété inventée hors de ce référentiel ne remonte pas comme vous l'espérez.

Troisième différence, et c'est celle qui coûte le plus cher : la hiérarchie de chapitres. Les propriétés page_chapter1 à page_chapter3 structurent la catégorisation de vos pages pour le reporting. Autrement dit, toute votre arborescence d'analyse dépend d'un arbitrage à prendre avant de taguer, pas après.

Si vous arrivez de GA4, votre réflexe « je regarde le dataLayer » ne s'applique plus. Si vous arrivez de Matomo, vous débarquez avec des actions et des dimensions personnalisées numérotées, et il faut tout retraduire en événements nommés et en chapitres. Dans les deux cas, la recette n'est pas une formalité de fin de projet.

Pour rappel : recetter, c'est valider un plan de marquage avant mise en production (MEP). Pas « regarder si ça remonte ».

Comment lire un hit Piano Analytics dans son navigateur ?

C'est la compétence de base, et elle s'acquiert en dix minutes. Ouvrez les outils de développement, onglet Réseau, et filtrez sur votre domaine de collecte. Par défaut, il ressemble à xxxxxxx.pa-cd.com, sauf si votre implémentation utilise un CNAME personnalisé.

Ce que vous devez savoir repérer dans la requête :

• Le site ID : le paramètre s, qui identifie le périmètre de collecte. Une erreur ici et vos données partent dans le mauvais site. Ça arrive plus souvent qu'on ne le croit entre préprod et prod.
• L'identifiant visiteur : le paramètre idclient.
• Le payload : une liste d'événements, chacun avec son nom et son bloc de données (les propriétés). C'est là que vous confrontez ligne à ligne avec le plan de marquage.
• La configuration du tag : le script se charge depuis tag.aticdn.net et reçoit au minimum un site et un collectDomain.

Un exemple minimal d'appel, pour fixer les idées :

pa.sendEvent("page.display", {
  page: "fiche_produit",
  page_chapter1: "catalogue",
  page_chapter2: "chaussures"
});

Si vous savez lire ça, vous êtes autonome pour 80 % de la recette. Le reste, c'est de la rigueur et de l'outillage. Et si le geste ne vous est pas encore familier, on l'a détaillé pas à pas, avec un vrai payload décortiqué ligne à ligne : apprendre à lire un hit Piano Analytics.

Quels outils utiliser pour recetter son tracking Piano Analytics ?

Bonne nouvelle, et je le dis d'autant plus volontiers que l'écosystème Piano a mauvaise réputation sur ce point : l'outillage est meilleur qu'on ne le pense.

Tag Inspector, c'est le point d'entrée. Il affiche un tableau des hits, un détail par hit, et un onglet listant le nom de l'événement avec toutes les propriétés collectées et leur type. Vous pouvez copier le JSON d'un hit, et même tester un hit en collant son URL. Si vous êtes connecté à Piano Analytics, l'extension récupère votre session pour vous afficher des informations absentes du hit brut, comme la valeur associée à un ID. Pour moi, c'est le gros point fort : la fonction de test d'un hit est très sous-utilisée alors qu'elle règle la moitié des débats « c'est le tag ou c'est la conf ? ».

Attention à un piège bête : si votre collecte passe par un CNAME personnalisé, pensez à déclarer ce domaine dans la configuration de l'extension. Sinon vous ne voyez rien et vous concluez, à tort, que le tag ne part pas.

Le Stream Inspector est le seul à répondre à la vraie question. Disponible dans Piano Analytics, côté Configuration puis Data Collection Portal, il permet de voir les hits entrants et de filtrer sur certaines valeurs. Le tag qui part correctement, c'est bien. Le hit qui arrive correctement, c'est ce qui compte. Ce sont deux vérifications différentes, et la deuxième est celle qu'on oublie.

Les 8 points de contrôle d'une recette Piano Analytics

Voilà la liste que nous passons systématiquement, dans cet ordre.

1. Configuration par environnement. site et collectDomain corrects, et surtout différents entre préprod et production. Le classique : la préprod qui pollue le site de prod pendant trois semaines.
2. page.display unique par page. Un seul déclenchement, avec la propriété page attendue.
3. Cohérence des chapitres. page_chapter1 à page_chapter3 remplis selon le plan, et de la même façon sur tous les templates. Une page produit qui range son chapitre 1 différemment d'une autre page produit, c'est un rapport inexploitable.
4. Les interactions. Les événements click.navigation avec leurs propriétés de clic et le contexte de page.
5. Le tunnel e-commerce. Les événements de transaction, avec montants, devise et propriétés produit. À recetter sur un vrai achat, pas sur une simulation.
6. L'identification visiteur. L'identifiant utilisateur envoyé, et cohérent d'une page à l'autre.
7. Les états de consentement. Rejouez le parcours dans chaque configuration : consentement total, refus, choix partiel. Piano applique des règles de collecte différentes selon le mode de consentement et le mode de confidentialité configurés. Ce point mérite à lui seul une session de recette dédiée.
8. Le hit arrive. Contrôle final au Stream Inspector. Les sept premiers points valident l'émission, celui-ci valide la réception.

Gardez à l'esprit que sur une single page application, le point 2 se rejoue à chaque changement de route. C'est le nid à doublons.

Quelles sont les erreurs les plus fréquentes ?

Les mêmes reviennent projet après projet.

Les doublons de vues de page. Piano propose un mode Instant Tracking qui déclenche automatiquement les vues de page sans configuration. Pratique pour démarrer. Redoutable si quelqu'un ajoute ensuite des appels manuels sans désactiver l'automatique : chaque page est comptée deux fois, et vous cherchez pendant une semaine pourquoi votre trafic a doublé du jour au lendemain.

Les propriétés hors data model. Une propriété custom inventée dans un coin part bien, mais elle ne s'aligne pas sur le référentiel et vous ne la retrouvez pas là où vous l'attendez dans les rapports. La documentation distingue par ailleurs les propriétés envoyées dans le code, immédiatement disponibles, et les propriétés calculées lors du traitement. Savoir dans quelle catégorie vous êtes évite des heures de doute.

Les chapitres décidés après le tagging. Vous taguez, vous livrez, et trois mois plus tard l'équipe marketing veut une arborescence différente. Retagging complet. Cet arbitrage se prend en atelier, avec les gens qui vont lire les rapports.

L'héritage SmartTag mal purgé. Piano documente une procédure de migration depuis SmartTag. Sur les comptes anciens, il reste souvent des propriétés mappées à la va-vite qui cohabitent avec les nouvelles. Personne n'ose y toucher. Le rapport devient un champ de mines.

Le certificat du domaine de collecte personnalisé. Un domaine de collecte custom implique un certificat à renouveler. Le jour où il expire, la collecte s'arrête. Ce n'est pas un bug de tracking, c'est de l'exploitation, et ça ne se voit dans aucune recette fonctionnelle.

Le navigateur du recetteur. Un bloqueur de publicité actif, et vous validez une implémentation sur une session où la moitié des hits ne partent pas. Recettez toujours sur un profil propre.

Pourquoi la recette manuelle ne tient pas dans le temps ?

Parce qu'elle est parfaite le jour de la MEP et périmée trois semaines plus tard.

Faites le calcul honnêtement. Un tunnel e-commerce sérieux, c'est facilement 40 à 60 événements à contrôler. Multipliez par les états de consentement, par mobile et desktop, et vous êtes à plusieurs centaines de vérifications. Une demi-journée, au mieux, si vous connaissez le site par cœur. Personne ne refait ça à chaque déploiement. Alors on recette la première fois, puis on croise les doigts.

Et une régression de tracking ne prévient pas. Elle ne casse pas le site, elle ne lève aucune erreur, elle n'apparaît dans aucun monitoring technique. Elle se contente de faire disparaître un événement. Vous la découvrez en général six semaines plus tard, quand quelqu'un s'étonne d'un écart entre le back-office et les rapports, ou quand un budget média a été piloté sur des conversions fantômes.

C'est exactement le problème que le monitoring automatisé du dataLayer de MayIA° attaque : un agent IA qui rejoue vos parcours et revérifie chaque événement en continu, avant et après chaque MEP, pour que la recette ne dépende plus de la disponibilité d'un humain. Demander une démo.

Pour conclure

Recetter Piano Analytics n'est pas plus difficile que recetter GA4, c'est simplement moins documenté. Retenez trois choses : votre référence est le plan de marquage confronté au data model, pas un dataLayer ; Tag Inspector plus Stream Inspector couvrent l'émission et la réception, et il faut les deux ; les chapitres se décident avant de taguer, jamais après.

Si vous ne devez retenir qu'une chose : le tag qui part n'est pas le hit qui arrive.

FAQ

Piano Analytics a-t-il un équivalent du DebugView de GA4 ?

Pas sous ce nom, mais la fonction existe. Le Stream Inspector, dans le Data Collection Portal, affiche les hits entrants et permet de filtrer sur des valeurs, ce qui couvre l'usage principal du DebugView. Pour le côté navigateur, l'extension Tag Inspector joue le rôle du débogueur en temps réel.

Faut-il un dataLayer pour utiliser Piano Analytics ?

Non, ce n'est pas requis : le SDK s'appelle directement en JavaScript. Nous recommandons pourtant d'en maintenir un. Une couche de données intermédiaire vous donne un point de contrôle unique, facilite la recette et vous évite de tout retoucher si vous ajoutez un autre outil plus tard.

Comment vérifier qu'un hit Piano Analytics est bien reçu, et pas seulement envoyé ?

En croisant deux vues : l'extension Tag Inspector côté navigateur pour l'émission, le Stream Inspector côté Piano pour la réception. Un hit visible dans le premier et absent du second signale un problème de domaine de collecte, de configuration de site ou de filtrage, pas un problème de tag.

Peut-on recetter le tracking Piano Analytics d'une application mobile ?

Oui. Piano fournit des SDK pour Android, iOS, Flutter, ainsi qu'une version JavaScript sans navigateur et une API de collecte HTTP. La logique de recette reste la même, mais l'inspection passe par un proxy réseau plutôt que par une extension de navigateur, et le contrôle en réception via le Stream Inspector devient encore plus important.

Combien de temps prend une recette Piano Analytics complète ?

Sur un site e-commerce, comptez une demi-journée à une journée pour un premier passage sérieux, en incluant les états de consentement et la double vérification mobile et desktop. La difficulté n'est pas le premier passage, c'est de le refaire à chaque mise en production.