Les slides de ma conférence du Measure Camp Nantes 2016, qui traite d'une architecture "dev-friendly" d'implémentation des outils de webanalytics et de tag management

1. Devenir best friend
forever avec vos
développeurs
Comment faire une implémentation
bulletproof de vos outils de
webanalytics
Aristide Riou | @aristweet
Measure Camp Nantes
05 novembre 2016

2. Pourquoi cette présentation?
En un mot : nous sous-exploitons les outils de tag management
Et ça m’énerve.

3. Un peu d’histoire...
Pour les plus jeunes…
Il y a une époque où les plans de
marquage ressemblaient à ça…

5. Et c’était. Juste. Une fucking tannée.
● Mise en prod pour chaque modification (ou alors modifs
périlleuses dans les filtres de GA, processing rules dans
Omniture... #nostalgie)
● Expertise portée par les développeurs (donc techniques plus ou
moins fiables)
● Recette / QA plus complexe (pas de Data Layer comme couche
intermédiaire “juge de paix”)
● Encore aujourd’hui, difficultés à migrer vers GTM et “nettoyer” des
vieilles implémentations

7. Et puis les TMS sont arrivés
● “Seamless tracking integration”
● “All in one tag management”
● “A single snippet required”
● “Happiness, success, money and georgious chicks”

8. Sauf que...ça ne s’est pas vraiment passé comme ça
On a vu arriver 2 types d’approches :
● L’approche “moi pas toucher code site. Internet. HTML. Tout ça”
(80%)
● L’approche “#yolo” (20%)

9. L’approche “passe plat” (les 80% tristes)
GTM ne fait que transiter les informations

15. “Ouais mais c’est plus durable”
FAUX! FAUX! ULTRA FAUX!!!
● On appelle une librairie (gtm.js) pour NADA
● On fait porter des informations orientées GA (ou Adobe, AT…) à un
data layer qui est censé être agnostique
● On continue à donner la responsabilité aux développeurs (qui ont
très franchement mieux à faire)
● Certes, on peut faire des fixes...mais du coup, c’est franchement
du bricolage.

16. L’approche #yolo (les 20% cools, mais un peu fous)
Rien n’est inséré en dur, tout est fait via le TMS.
● Scrapping de contenu pour alimenter des custom dims (header,
h1, h2…) basé sur la structure du DOM.
● Listeners de clics via des classes, des IDs, des attributs CSS divers…
● Tracking d’affichage de pop ins via des fonctions récursives qui
attendent la visibilité d’un élément
● Trucs franchement sales et un peu honteux

17. Listener de clic basé sur un attribut CSS un peu random

18. Listener de scroll en se basant sur la position d’un CtA

19. Scrapping très crado d’evars issues d’Adobe Analytics

20. C’est franchement fun, mais dangereux
● La structure du DOM peut bouger à tout moment
● Problèmes de performance
● On écoute le résultat, et non la cause (ex : visibilité d’une pop in vs
fonction qui la déclenche en JS)
● Compatibilité (commentaires, Jquery, listeners, isVisible…)

21. Bilan : avantages et inconvénients des deux méthodes
+ -
Passe plat
● Plus performant (si bien
fait)
● C’est la faute des dèvs si
ça pète
● Peu de flexibilité (ou alors
fixes un peu sales)
● Les dèvs vous détestent
● Zéro intérêt d’utiliser un
TMS
#Yolo
● Indépendance vis-à-vis
des releases
● Fun
● Dépendance vis-à-vis de la
structure de la page
● Performance
● Les dèvs vous détestent

22. La question qui tue : comment trouver le bon équilibre?

23. Mon parti pris : approche par élimination
C’est OK de scrapper sauf si le scrapping génère :
● Des problèmes de performance
● Une imprécision dans la mesure
● Des incompatibilités en JS
(ces cas se recoupent très souvent)
● Pas d’autre choix (élément non répercuté en front)

24. Problèmes de performance (ex : tracking visibilité pop-in)

25. Problèmes de performance (ex : tracking visibilité pop-in)
Sale (tourne en boucle)
+ dépendance à
Jquery

26. Imprécision dans la mesure (ex : tracking menu déroulant)

27. Imprécision dans la mesure (ex : tracking menu déroulant)
On pourrait cibler l’ID pour tracker
le clic, mais…
-Si le volet ne se déroule pas?
-Si on veut juste tracker
l’ouverture, et pas la fermeture?

28. Imprécision dans la mesure (ex : tracking menu déroulant)
Le Data Layer est alimenté au
moment où se déclenche la fonction
qui déroule la description du produit

29. Problèmes de compatibilité en JS (ex : temps de chargement)
API Navigation Timing
pas compatible avec
les vieilles versions d’IE
Les console.log font
péter certaines
versions d’IE (et puis il
faut les éviter, c’est un
peu sale de toute
façon)

30. Problèmes de compatibilité en JS (ex : temps de chargement)
Dans le doute, on wrappe
toutes nos fonctions dans
un try catch, et on loggue
les erreurs

31. Il nous reste quand même des choses sympas à faire
● Listener des clics via un attribut CSS “data-xxxx” et
querySelectorAll
● Tracking de la visibilité des éléments avec hunt.js
● Scrapping sans scrupule d’éléments forcément durables de la
page : title, meta, URLs…
● Calculs d’éléments de scope user avec le local storage

32. Les listeners de clics et d’autres trucs (sans Jquery!)

33. Les listeners de clics et d’autres trucs (sans Jquery!)
Les attributs
‘data-xxxx’ disposent
de leurs propriétés
nativement
récupérables en JS
#pratique

34. hunt.js, la librairie super cool pour la visibilité des éléments
https://goo.gl/tPzCmo

35. hunt.js dans la pratique
On commence par
appeler la librairie
au sein de GTM...

36. hunt.js dans la pratique
...et puis on fait des trucs avec
(ex : scroll jusqu’à la visibilité
d’un élément)

37. Les éléments du DOM qu’on peut scrapper sans scrupule
Meta robots (utile pour le SEO)

38. Les éléments du DOM qu’on peut scrapper sans scrupule
● Eléments d’URLs (si elles ne changent pas tous les 4 matins)
● Meta desc (et autres meta…)
● Tracking des 404 (via leur attribut “title”, qui en général ne bouge
pas)
● etc...

39. Le local storage pour calculer des éléments niveau user
On incrémente un local
storage à chaque action
sociale (tag déclenché en
séquentiel)

40. Mais je vous vois déjà venir
“Ouais OK t’es bien gentil mais on reste dépendant de la structure du
DOM donc bon moi je veux pas trop m’engager. “
“Et puis bon l’engagement ça m’a toujours fait peur. Regarde, par
exemple avec Cindy qui était en 1ère ES4 4 ça aurait pu marcher, mais
je pense que dans la vie on avait des buts différents, et qu’elle
cherchait vraiment quelque chose sur le long terme”

41. Tout est possible à une seule condition
DO CU MEN TER
Pas besoin de faire des plans de marquage de 500 pages. Deux
onglets dans une spreadsheet suffisent :
● Alimentation du Data Layer (classique)
● Dépendances front (moins classique, mais pourtant simple)

42. Doc de l’alimentation du Data Layer

43. Doc des dépendances front

44. Pour conclure
● Tout est possible…
● ...à condition de bien documenter…
● ...et d’avoir une gouvernance solide sur ce qui est implémenté en
dur / via GTM.
● Faites faire des code reviews à vos dèvs

45. Merci !
Aristide Riou | @aristweet