GTM / banniĂšres cookie / trigger group : au secours

💡
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, le cart, le checkout, le purchase, etc

  • M : le nombre de choix utilisateur dans la banniĂšre cookie. Le plus souvent les consentements analytics et publicitaire 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 triggers
Configuration 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.
Image without caption
⚠
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.
Image without caption
⚠
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 fonction envoiEventsSupplementaires 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
javascript
window._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
javascript
if (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, dont OnConsentChanged 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
Image without caption

Edward Bunzl

10 ans dans le conseil dont 4 chez Converteo en tracking et Web Analyse. Ingénieur de formation à Télécom Paris. Edward supervise le succè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
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].

Powered by Notaku