Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Devenir best friend forever avec vos développeurs measure camp nantes 2016

177 views

Published on

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

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Devenir best friend forever avec vos développeurs measure camp nantes 2016

  1. 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. 2. Pourquoi cette présentation? En un mot : nous sous-exploitons les outils de tag management Et ça m’énerve.
  3. 3. Un peu d’histoire... Pour les plus jeunes… Il y a une époque où les plans de marquage ressemblaient à ça…
  4. 4. 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
  5. 5. 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”
  6. 6. 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%)
  7. 7. L’approche “passe plat” (les 80% tristes) GTM ne fait que transiter les informations
  8. 8. “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.
  9. 9. 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
  10. 10. Listener de clic basé sur un attribut CSS un peu random
  11. 11. Listener de scroll en se basant sur la position d’un CtA
  12. 12. Scrapping très crado d’evars issues d’Adobe Analytics
  13. 13. 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…)
  14. 14. 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
  15. 15. La question qui tue : comment trouver le bon équilibre?
  16. 16. 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)
  17. 17. Problèmes de performance (ex : tracking visibilité pop-in)
  18. 18. Problèmes de performance (ex : tracking visibilité pop-in) Sale (tourne en boucle) + dépendance à Jquery
  19. 19. Imprécision dans la mesure (ex : tracking menu déroulant)
  20. 20. 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?
  21. 21. 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
  22. 22. 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)
  23. 23. 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
  24. 24. 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
  25. 25. Les listeners de clics et d’autres trucs (sans Jquery!)
  26. 26. 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
  27. 27. hunt.js, la librairie super cool pour la visibilité des éléments https://goo.gl/tPzCmo
  28. 28. hunt.js dans la pratique On commence par appeler la librairie au sein de GTM...
  29. 29. hunt.js dans la pratique ...et puis on fait des trucs avec (ex : scroll jusqu’à la visibilité d’un élément)
  30. 30. Les éléments du DOM qu’on peut scrapper sans scrupule Meta robots (utile pour le SEO)
  31. 31. 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...
  32. 32. 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)
  33. 33. 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”
  34. 34. 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)
  35. 35. Doc de l’alimentation du Data Layer
  36. 36. Doc des dépendances front
  37. 37. 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
  38. 38. Merci ! Aristide Riou | @aristweet

×