L'internalisation des solutions de mesure et optimisation de l'efficacité marketing : 5 facteurs clés de succès - Partie 2
6 minutes
Arnaud Parent
.svg)
Le lot le plus important et le plus critique dans la migration entre les deux outils réside dans la construction des tags e-commerce, qui comprennent des informations de type produit.
En effet, chez GA4, on retrouve plusieurs produits envoyés au sein d'un sous-objet javascript - l'objet 'items' - pour un seul événement e-commerce.
Chez Piano, les produits sont envoyés " à plat " au sein du même objet javascript que les propriétés* d'événement. On obtient donc autant d'événements que de produits présents dans le Data Layer. "Nous connaissons bien ce pain-point dans l'intégration de notre solution e-commerce. Nous travaillons à simplifier celà très prochainement...", assure Benjamin Diolez, Product Owner chez Piano.
Notez également que le nom des variables diffère entre GA4 et Piano.
Par ailleurs, il existe aussi des différences au niveau des événements 'view_promotion' et 'select_promotion' de GA4, qui peuvent être respectivement nommés 'publisher_impression' et 'publisher_click' ou 'self_promotion.impression' et 'self_promotion.click'. En effet, côté Piano, les événements de type 'publisher' et les événements de type 'self_promotion' peuvent s'utiliser interchangeablement. Par la suite, nous parlerons simplement de 'publisher'.
Et au sein même de ces événements, on retrouve une autre différence importante au niveau de la construction de l'objet 'items' : chez GA4, il est en sous-objet javascript (avec tous les produits concernés dans le sous-objet), alors que chez Piano il n'est pas prévu, ces points de mesure n'étant pas considérés comme e-commerce en mode natif.
De plus, les paramètres standards attendus côté Piano ne sont pas les mêmes que les paramètres standards attendus côté GA4.
Enfin, s'il existe d'autres différences d'événements et de paramètres entre les deux plateformes, la flexibilité de Piano permet de créer autant d'événements personnalisés que souhaité, et offre jusqu'à 1000 propriétés personnalisées pour répondre aisément à chaque cas.
Afin d'adresser le plus efficacement possible les différences de structures entre les deux plateformes, Piano a créé et mis à disposition un template de tag et de variable; celui-ci permet de simplifier énormément le travail de lecture de la structure type GA4 poussée dans le Data Layer au regard de celle que les tags Piano nécessitent.
Construits par Piano et collaborativement améliorés et testés avec fifty-five, ces modèles permettent une migration fluide entre les deux plateformes, et assurent que les événements les plus importants de la collecte soient disponibles dans une interface Piano Analytics sans effort majeur. "Notre collaboration continue avec fifty-five nous a permis de créer un template de tag robuste qui tire parti de toute la flexibilité qu'offre Piano Analytics et son modèle de données. Il est déjà utilisé par les consultants Piano Analytics pour divers projets avec des acteurs de l'e-commerce et retail partout dans le monde", précise Charles Dieppois, Product Manager chez Piano.
Que fait le template ?
En plus de ces fonctionnalités de migration, le template propose différentes actions pour aller au-delà d'une simple migration et améliorer la collecte :
En somme, la migration entre les deux outils est grandement simplifiée. Les templates offrent un gain de temps considérable et évitent l'implication d'autres équipes dans le processus de migration de la collecte. Pour Benjamin Diolez, ce succès découle de l'effort collaboratif à son origine : "Nous avons travaillé main dans la main avec les experts fifty-five, afin de s'assurer de répondre aux besoins et attentes de nos clients et partenaires, en combinant leur connaissance business avec notre expertise du produit."
Piano Analytics offre des capacités plus poussées de mesure et de capacité d'analyse, notamment par la mise en place de l'exemption ePrivacy. En termes d'analyse, Piano propose des analyses e-commerce natives avancées, dont l'analyse de cycle de vie du panier, non disponible nativement dans GA4. Afin de bénéficier de ces analyses, il est nécessaire de mettre en place un 'cart_id' (identifiant de panier) et de l'ajouter à chaque événement e-commerce concerné. Notez que, chez Piano, le 'cart_id' est un paramètre obligatoire pour le bon traitement de la plupart des événements e-commerce. Si cette information n'est pas disponible dans votre dataLayer GA4 (car non standard chez GA4), il sera alors nécessaire de demander son implémentation à votre équipe IT (solution privilégiée), ou, le cas échéant, d'assigner une valeur aléatoire et unique à la journée dans ce paramètre obligatoire. Les analyses de cycle de vie du panier seront partiellement alimentées, et cela assure que les événements e-commerce collectés soient correctement traités. (Par exemple, une solution communément utilisée pour générer un ID unique est de coupler la valeur de l'ID de cookie visiteur à la date du jour, afin d'obtenir une analyse à la portée de la journée.)
Autre point crucial à prendre en compte : la gestion des UTMs. En effet, une lecture exacte des performances d'acquisition de trafic est bien souvent un élément essentiel du digital analytics. La migration doit donc aussi être maîtrisée sur ce point. Pour cela, Piano a mis en place un paramètre de configuration (le " campaignPrefix ") qui permet de lire les UTMs (en plus des clés de Piano " at_ ").
Il est ainsi assez simple de s'adapter au tracking des UTM, et le tracking des liens de campagne n'a pas à être modifié. Ce paramètre de configuration peut être ajouté directement dans le template de variable mis à disposition.
En revanche, une fine différence entre les deux plateformes est à prendre en compte impérativement. Chez GA4, les UTM obligatoires sont 'utm_source' et 'utm_medium'. Ou, chez Piano, les paramètres de campagne obligatoires sont 'at_medium' et 'at_campaign'. De ce fait, si un visiteur arrive sur votre site via le lien tracké suivant :
>> https://monsite.com/?utm_medium=mon-medium&utm_source=ma-source
Piano ne pourra pas lire correctement la source marketing du visiteur, car aucun 'utm_campaign' ne sera attribué à un 'src_campaign'**, et la correspondance suivante s'effectuera :
Une fois le hit arrivé au processing, il n'y aura pas de 'src_campaign' à prendre en compte, et la source de la visite sera donc ignorée d'un point de vue marketing.
Il est donc nécessaire d'ajouter une règle dans votre implémentation afin de toujours avoir une valeur associée à l'UTM 'utm_campaign' (via une variable javascript ou une lookup table, selon vos préférences et besoins).
Une fois ces éléments importants pris en compte dans votre migration, celle-ci se passera de manière bien plus simple et efficace. Si vous avez des questions par rapport à la migration, n'hésitez pas à me contacter : sebastien.roberto@fifty-five.com.
L'équipe fifty-five tient à remercier Charles Dieppois ainsi que Benjamin Diolez pour leur collaboration dans l'optimisation des templates de tags et de variables pour GTM, ainsi que leur participation dans la rédaction de cet article.
* Une propriété chez Piano Analytics est l'équivalent d'une dimension chez Google Analytics. De la même manière qu'il existe des dimensions personnalisées chez Google Analytics, il y a aussi des propriétés personnalisées chez Piano Analytics.
** Le paramètre " src_campaign " correspond au paramètre de hit qui sera créé lorsqu'un paramètre de lien de campagne " at_campaign " ou " utm_campaign " sera rencontré dans l'URL.
Découvrez les dernières actualités, articles, replays de webinars et événements fifty-five dans notre newsletter mensuelle Tea O’Clock.
