Piano Analytics : collecter et contrôler ses événements web

Analyste observant un tableau de bord relié aux événements d’un site web

[no-ez-toc]

Piano Analytics est une plateforme de collecte, d’exploration et d’analyse des usages numériques. Elle peut recevoir des événements provenant d’un site, d’une application ou d’un serveur, puis les rendre exploitables dans des rapports. La qualité du résultat dépend toutefois du plan de marquage, du paramétrage de collecte, du consentement et des contrôles réalisés par l’organisation cliente.

Ce que mesure un événement

Un événement décrit une action ou un état : affichage d’une page, clic, lecture d’un média, ajout au panier ou transaction. Il porte un nom et des propriétés. Une propriété peut identifier la page, le type de contenu ou la position d’un bouton. Avant le code, rédigez un plan précisant le nom, le déclencheur, les propriétés obligatoires, leur type et leur finalité.

Exemple documenté : envoyer un affichage de page

La documentation des SDK Piano Analytics expose la méthode JavaScript pa.sendEvent(eventName, eventData, options). Une implémentation minimale peut envoyer l’événement standard page.display avec une propriété de page :

pa.sendEvent('page.display', {
  page: 'guide_piano_analytics',
  page_chapter1: 'documentation'
});

Ce code suppose que le SDK a été chargé et configuré avec les paramètres du site. Le nom de page et le chapitre doivent suivre votre convention interne. Ne recopiez pas un identifiant de site trouvé dans un exemple public et ne déclenchez pas deux fois l’événement si votre gestionnaire de balises l’envoie déjà.

Implémentation en quatre étapes

  1. Planifier : relier chaque événement à une question métier et à une base juridique ou un choix de consentement applicable.
  2. Configurer : installer le SDK côté client, une collecte côté serveur ou un gestionnaire de balises, avec le site et le domaine de collecte attendus.
  3. Déclencher : envoyer l’événement une seule fois au moment défini, avec des propriétés typées et documentées.
  4. Valider : contrôler la requête, les valeurs reçues et leur présence dans l’interface avant la mise en production.

Contrôler les remontées

Dans les outils de développement du navigateur, filtrez l’onglet Réseau sur le domaine de collecte et réalisez l’action une fois. Vérifiez le code de réponse, le nom d’événement, l’identifiant de site et les propriétés. L’extension Piano Tag Inspector peut aider à inspecter le marquage. Effectuez ensuite un contrôle dans l’outil de données avec un environnement ou une propriété de test clairement isolée.

  • Un événement manque : examinez le déclencheur et le consentement au moment du clic.
  • Il apparaît deux fois : cherchez un double marquage SDK et gestionnaire de balises.
  • Une propriété est vide : contrôlez la variable avant l’appel, pas seulement le rapport final.
  • Les volumes divergent : comparez même période, fuseau, filtres, périmètre et refus de consentement.

Hébergement et domaine de collecte

Piano documente plusieurs architectures : collecte côté client ou serveur, domaine de collecte par défaut géré par Piano, domaine personnalisé ou proxy selon l’offre et la configuration. Le choix influe sur les cookies, les navigateurs, la gouvernance et l’exploitation. Il ne faut pas déduire le lieu exact d’hébergement de la seule URL visible dans un exemple.

La documentation de collecte précise notamment que le domaine par défaut est géré par Piano et que des options de collecte personnalisée existent. L’organisation doit confirmer contractuellement les régions, sous-traitants, durées de conservation et mécanismes de transfert qui concernent son déploiement.

Consentement et conformité : pas d’automatisme

Une capacité technique, un mode de stockage ou une configuration sans cookie ne garantit pas à elle seule la conformité. Le responsable du traitement doit déterminer les données nécessaires, le fondement applicable, l’information des utilisateurs, la durée de conservation et les droits à exercer. La bannière de consentement doit piloter le marquage conformément à cette décision, et ce comportement doit être testé avant et après chaque modification.

Checklist de recette

  • Un événement correspond à une action définie et n’est envoyé qu’une fois.
  • Les propriétés respectent noms, types et valeurs autorisées.
  • Aucune donnée personnelle non prévue n’est transmise.
  • Le refus et l’acceptation du consentement produisent le comportement décidé.
  • Le domaine, l’environnement et l’identifiant de site sont les bons.
  • Les volumes et dimensions sont contrôlés dans un rapport de test.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *