Dans cet article nous allons expliquer notre voyage dans le monde luxuriant des implémentations GTM et banniÚres cookie, la source de leur complexité, et une solution élégante que nous avons trouvée pour gérer nos implémentations GTM de façon standardisée.
Si vous voulez vous Ă©vitez toute la partie technique et voulez directement regarder notre solution, rendez-vous en bas de page avec ce lien đ
đšâđ» Comme on aime lâopen source, quelques ressources supplĂ©mentaires :
- Tous les tags prĂ©sentĂ©s sont observables sur notre GTM dont vous trouverez lâexport ci-dessous
gtm.txt
25.0KB
- Les snippets de code seront bientÎt mis à jour sur un répertoire Github public sous licence MIT, et donc réutilisables par tous
đ Restez attentifs Ă nos prochaines publications !
- Site démo pour voir le fonctionnement de notre solution en live, et un exemple de code complet intégrant également le consent mode.
- Sur un autre sujet Oussama vous prĂ©sentera bientĂŽt comment gĂ©rer des tags mĂ©dia sur plusieurs sites et plusieurs langues dans une seule variable GTMâŠ
Problématique
Toute personne qui a dĂ©jĂ fait de la configuration GTM sâest dĂ©jĂ tirĂ© les cheveux sur lâimplĂ©mentation de la banniĂšre cookie, et Ă raison car le sujet est complexe :
- Les
dataLayer.push
peuvent ĂȘtre envoyĂ©s avant / aprĂšs lâacceptation des finalitĂ©s de la banniĂšre
- LâimplĂ©mentation doit fonctionner Ă la fois si lâutilisateur arrive sur le site ou sâil a dĂ©jĂ naviguĂ© et donnĂ© son consentement
- Il peut y avoir plusieurs Ă©vĂ©nements Ă envoyer Ă lâarrivĂ©e sur une page : page vue,
item_view_list
, âŠ
Notre voeu pieux : un GTM simple
Nous cherchons Ă rĂ©duire au maximum le nombre de triggers dans GTM. La plupart des solutions ci-dessous dĂ©multiplient leur nombre, câest un inconvĂ©nient de taille qui complexifie le conteneur et notre quotidien de web-analyste difficile.
Dans la suite de lâarticle nous Ă©valuerons la complexitĂ© des diffĂ©rentes solutions en fonction de plusieurs facteurs
- N : le nombre dâĂ©vĂ©nements sur lesquels des tags spĂ©cifiques doivent se dĂ©clencher. Par exemple, des tags de remarketing sont souvent configurĂ©s sur la
homepage
, lecart
, lecheckout
, lepurchase
, etcâŠ
- M : le nombre de choix utilisateur dans la banniĂšre cookie. Le plus souvent les consentements
analytics
etpublicitaire
sont gérés dans GTM mais il peut y en avoir plus
- La présence de limitations
Voyage dans le temps des implémentations CMP
Au commencement tout Ă©tait simple
Avant lâarrivĂ©e des banniĂšres cookie, lâimplĂ©mentation Ă©tait assez simple : chaque Ă©vĂ©nement avait une trigger personnalisĂ©e avec le nom de lâĂ©vĂ©nement, fin de lâhistoire.
Configuration GTM
Résumé de la configuration
ElĂ©ments Ă maintenir : N triggers dâĂ©vĂ©nements
Puis sont arrivées les banniÚres cookie
Les banniÚres cookies ont tout de suite complexifié la tùche avec la nécessité de prendre en compte les choix utilisateurs effectués.
Variante 1 : gestion via trigger déclencheur
Cette solution se base sur la solution historique en enrichissant la trigger dâune condition qui va vĂ©rifier via une variable si le consentement appropriĂ© pour le tag a Ă©tĂ© donnĂ©.
Nouvelle complexitĂ© : la variable qui va cherche le consentement de lâutilisateur doit ĂȘtre faite en javascript. Le code est spĂ©cifique pour chaque CMP.
Nouvelle complexité : il faut dupliquer ces triggers par type de consentement
- pour un tag GA sur une page produit â trigger
product_view and analytics_consent_given
- pour un tag remarketing qui se dĂ©clenche sur la mĂȘme page â trigger
product_view and remarketing_consent_given
Configuration GTM
Résumé de la configuration
- ElĂ©ments Ă maintenir : N x M triggers dâĂ©vĂ©nements avec condition sur les consentements. Les tags sont donc dupliquĂ©s pour chaque finalitĂ© de consentement
- Variable javascript à créer pour récupérer les consentements, le code change selon la CMP
Variante 2 : gestion via tag bloquant
Pour remĂ©dier Ă la complexitĂ© de duplication des tags pour chaque cas dâusage (
product_view
, checkout
, transaction
, âŠ), on peut dĂ©placer les restrictions sur les consentements utilisateur en trigger bloquant. On passe alors de NxM Ă N+M triggersConfiguration GTM
Résumé de la configuration
- ElĂ©ments Ă maintenir : N triggers dâĂ©vĂ©nements + M triggers de consentements
- Variable javascript à créer pour récupérer les consentements, le code change selon la CMP
La problématique de ces solutions
Le principal inconvĂ©nient est que les Ă©vĂ©nements arrivant Ă lâacceptation de lâutilisateur ne sont pas dĂ©clenchĂ©s. Câest un problĂšme majeur. Un des impacts est que le hit de la premiĂšre page nâest pas envoyĂ©, ce qui peut fausser les donnĂ©es de landing page, la source de la session, etcâŠ
Dans le screen suivant on voit quâĂ lâarrivĂ©e sur un site deux dataLayer push sont effectuĂ©s avant que les consentements ne soient donnĂ©s.
Nouvelle complexité : les événements envoyés avant acceptation ne sont pas envoyés
Il faut donc aller chercher ailleurs.
Les triggers group Ă la rescousse, ou pasâŠ
Les triggers group sont un concept GTM qui permet dâattendre que deux Ă©vĂ©nements se soient produits avant dâenvoyer un tag. Sur le papier, cela semble rĂ©pondre Ă notre problĂ©matique. Des implĂ©mentations utilisant ce concept ont alors vu le jour.
Variante 1 : via trigger déclencheur
On reprend ici la mĂȘme premiĂšre variante que prĂ©cĂ©demment mais Ă la sauce trigger group
Configuration GTM
Résumé de la configuration
- ĂlĂ©ments Ă maintenir : N x M triggers group dâĂ©vĂ©nements avec condition sur consentement, les tags sont donc dupliquĂ©s pour chaque finalitĂ© de consentement
- Variable javascript à créer pour récupérer les consentements, le code change selon la CMP
- On rĂ©sout Ă priori la gestion des Ă©vĂ©nements envoyĂ©s avant lâacceptation
Variante 2 : via trigger bloquant
Configuration GTM
Analyse
- Comme pour les prĂ©cĂ©dents cas, la gestion en trigger bloquante permet de ne pas dĂ©dupliquer les diffĂ©rents tags dĂ©clencheurs, câest donc un avantage par rapport Ă la solution prĂ©cĂ©dente
- En revanche, il faut disposer dâun message clair dataLayer de la CMP indiquant quâun consentement, ce qui nâest pas chose Ă©vidente. Sur le dernier point, les diffĂ©rentes CMP implĂ©mentent diffĂ©rents types de pushs dataLayer ce qui nâaide pas Ă avoir une dĂ©marche standardisĂ©e
Résumé de la configuration
- ĂlĂ©ments Ă maintenir : N triggers group dâĂ©vĂ©nements + M triggers de consentements
- Variable javascript Ă crĂ©er pour rĂ©cupĂ©rer les consentements + une autre variable pour dĂ©tecter quâun consentement a Ă©tĂ© donnĂ©
Les limitations cachées des triggers groups
CâĂ©tait trop beau pour ĂȘtre vrai⊠les triggers groups ont en rĂ©alitĂ© des limitations qui les rendent dĂ©conseillĂ©es dans les implĂ©mentations GTM, en plus de leur complexitĂ© Ă la mise en place.
Le problÚme évident : un déclenchement par page
Les triggers group ne peuvent se dĂ©clencher quâune fois par page. On peut donc faire une croix sur pas mal de cas dâusage
- Les parcours en SPA oĂč il faut envoyer plusieurs pages vues
- Les Ă©vĂ©nements qui peuvent sâenvoyer en double comme des
view_item_list
qui sâenvoient au fur et Ă mesure du scroll utilisateur
Nouvelle complexitĂ© : Les triggers group ne peuvent se dĂ©clencher quâune fois par page
Le problÚme caché : la mutation du dataLayer
Une trigger group se manifeste comme un message dans le dataLayer aprĂšs que les X messages attendus se soient rĂ©alisĂ©s, mais rien ne garantit que les variables du datalayer nâaient pas changĂ© entre-temps
Prenons le cas dâun tag GA configurĂ© pour ĂȘtre dynamique, qui permet de minimiser le nombre de tags envoyĂ©s.
Si lâon suit la logique des triggers group, nous allons avoir un souci car lâevent se dĂ©clenche sur le dataLayer push du trigger group, et lâinformation du nom de lâĂ©vĂ©nement passĂ© est donc perdue.
Nouvelle complexitĂ© : Les triggers group ne garantissent pas lâintĂ©gritĂ© des paramĂštres envoyĂ©s dĂšs quâils sont dynamisĂ©s dans les tags, ce qui limite les possibilitĂ©s de rationalisation dans GTM
RĂ©capitulons
Le tableau suivant récapitule les différentes solutions et introduit la solution mise au point par Starfox
Avant | Sans trigger group (variante 2) | Avec trigger group (variante 2) | Solution Starfox | |
Eléments à implémenter | N triggers event | N trigger event + M trigger consentement | N trigger group event + M trigger consentement | N trigger events + M trigger consentement |
Limitations | - dataLayer push envoyĂ©s avant consentement non gĂ©rĂ©s | - impossible de dĂ©clencher plusieurs fois le mĂȘme Ă©vĂ©nement
- bugs en cas de tags dynamiques | ||
ComplexitĂ©s supplĂ©mentaires | Variable js spĂ©cifique Ă chaque CMP Ă crĂ©er | - complexitĂ© dâimplĂ©mentation
- Variable js spĂ©cifique Ă chaque CMP Ă crĂ©er | - Un peu dâĂ©changes avec le dĂ©veloppeur |
Notre solution retenue
Explication
Notre solution vise à pallier au souci commun derriÚre toutes ces implémentations :
- ne pas savoir si un Ă©vĂ©nement est envoyĂ© dans le dataLayer avant ou aprĂšs lâacceptation
- ne pas savoir si lâutilisateur a dĂ©jĂ prĂ©alablement envoyĂ© son consentement
Elle consiste Ă dĂ©porter la complexitĂ© cĂŽtĂ© dĂ©veloppeur pour nâenvoyer des dataLayer push quâau moment ou un consentement est donnĂ© (arrivĂ©e de lâutilisateur) ou en dĂ©tectant quâil a dĂ©jĂ Ă©tĂ© donnĂ© (lâutilisateur a dĂ©jĂ donnĂ© ses consentements sur sa page dâarrivĂ©e et vient dâarriver sur une autre page).
Ce fonctionnement permet de partir que pour tout Ă©vĂ©nement reçu, lâutilisateur a dĂ©jĂ donnĂ© ses choix. ce qui nous apporte un double avantage
- lâĂ©vĂ©nement peut ĂȘtre traitĂ© tout de suite dans GTM sans attente (et sans passer par des triggers groups)
- les consentements peuvent continuer Ă ĂȘtre gĂ©rĂ©s en triggers bloquants
Câest bien beau tout ça mais ça doit ĂȘtre compliquĂ© ?
En fait non. Les CMP mettent Ă disposition des mĂ©thodes qui permettent dâĂ©couter lâarrivĂ©e dâun consentement utilisateur sans avoir Ă faire un
eventListener
maison. Selon les CMP, lâimplĂ©mentation peut changer.Le code de principe reste le mĂȘme :
javascript// récupérer les variables de page et les pousser dans le dataLayer var variablesDePage = {'page_category': 'xxx', etc...} dataLayer.push(variablesDePage); // préparer les différents dataLayer push à envoyer function envoiEventsSupplementaires() { dataLayer.push({event: 'view_item_list', attributes...}) // etc... } // gérer le consentement utilisateur if (utilisateurADejaDonneSonConsentement) { // à adapter selon la CMP dataLayer.push({event: 'page_view'}); sendEvents() } else { // pas de choix utilisateur : il faut attendre le choix de l'utilisateur when (consentGiven) { dataLayer.push({event: 'page_view'}); sendEvents() }
Quelques précisions
- on envoie lâĂ©vĂ©nement de
page_view
en dehors de la fonctionenvoiEventsSupplementaires
car câest cette derniĂšre qui est le plus complexe Ă mettre en place par le dĂ©veloppeur
- Toute la complexitĂ© est de trouver le bon code pour chaque CMP pour gĂ©rer lâĂ©coute des consentements utilisateur
Exemple de code pour les différentes solutions
Axeptio
javascriptwindow._axcb.push(function(axeptio) { axeptio.on("cookies:complete", function(choices) { dataLayer.push({event: 'page_view'}); envoiEventsSupplementaires() }) });
Le SDK dâAxeptio est trĂšs bien fourni. comme
optanonwrapper
pour Onetrust la variable _axcb
peut ĂȘtre crĂ©Ă©e en avance de lâexĂ©cution de la CMP et exĂ©cuter du code une fois que le script CMP est chargĂ©.La mĂ©thode
axeptio.on(âcookies:completeâ
se dĂ©clenche Ă la fois lorsque lâutilisateur donne ses choix pour la premiĂšre fois mais aussi sur une page suivante dans sa navigation sâil a dĂ©jĂ fait ses choix. OneTrust
javascriptif (document.cookie.indexOf('OptanonAlertBoxClosed')>0) { sendEvents() } else { function OptanonWrapper() { OneTrust.OnConsentChanged(function() { dataLayer.push({event: 'page_view'}); envoiEventsSupplementaires() }) } }
- Le cookie
OptanonAlertBoxClosed
est crĂ©Ă© lorsque lâutilisateur ferme la banniĂšre cookie (et donc a fait ses choix).
- La fonction
OptanonWrapper
est faite pour ĂȘtre appelĂ©e une fois que le script de la CMP est chargĂ©, Ă ce moment toutes les mĂ©thodes javascript de cette derniĂšre sont accessible, dontOnConsentChanged
qui repĂšre le moment ou un utilisateur donne ses consentements
- On ne peut pas utiliser de maniÚre élégante le cookie pour détecter un choix utilisateur, il faudra scripter une vérification toutes les secondes par exemple (ou autre pas de temps).
Résumé des possibilités offertes par les SDK
OneTrust | Axeptio | |
DĂ©tection dâun consentement dĂ©jĂ donnĂ© | PrĂ©sence du cookie OptanonAlertBoxClosed , a lâavantage dâexister dĂšs le chargement dâune page sans avoir Ă se baser sur un dlpush onetrust par exemple | Fonctionnement dĂ©jĂ inclus dans le mĂ©canisme dâĂ©coute |
Ăcoute dâun consentement qui arrive | La fonction OptanonWrapper peut ĂȘtre dĂ©finie cĂŽtĂ© client, elle est automatiquement appelĂ©e une fois que OneTrust se charge.
Dans cette fonction, utiliser la mĂ©thode OneTrust.OnConsentChanged pour Ă©couter lâarriver dâun consentement | on peut dĂ©finir une fonction dans window._axcb.push qui sera appelĂ© au chargement du sdk
sdk.on('cookies:completeâ permet dâexĂ©cuter du code une fois le consentement donnĂ© ou si le sdk dĂ©tecte quâil lâa dĂ©jĂ Ă©tĂ© (le fait de gĂ©rer ces deux cas est une force) |
Auteur
Edward Bunzl
10 ans dans le conseil dont 4 chez Converteo en tracking et Web Analyse. IngeÌnieur de formation aÌ TeÌleÌcom Paris. Edward supervise le succeÌs client et la R&D interne.
Suivez Starfox Analytics sur Linkedin
Un besoin, une question ? Notre équipe vous répondra au plus vite.
â Suivez Starfox sur Linkedin
Suggérer une amélioration
Quelque chose nâest pas clair, vous souhaitez contribuer Ă la base de connaissance ou simplement, suggĂ©rez des amĂ©liorations ? Contactez [email protected].