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

Pourquoi cette présentation?

En un mot : nous sous-exploitons les outils de tag management

Et ça m’énerve.

Un peu d’histoire...

Pour les plus jeunes…

Il y a une époque où les plans de marquage ressemblaient à ça…

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

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”

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%)

L’approche “passe plat” (les 80% tristes)

GTM ne fait que transiter les informations

“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.

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

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

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

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

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…)

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

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

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)

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

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

Sale (tourne en boucle)+ dépendance à

Jquery

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

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?

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

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)

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

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

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

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

hunt.js, la librairie super cool pour la visibilité des éléments

https://goo.gl/tPzCmo

hunt.js dans la pratique

On commence par appeler la librairie au sein de GTM...

hunt.js dans la pratique

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

Les éléments du DOM qu’on peut scrapper sans scrupule

Meta robots (utile pour le SEO)

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...

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)

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”

Tout est possible à une seule condition

DO CU MEN TERPas 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)

Doc de l’alimentation du Data Layer

Doc des dépendances front

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

Merci !

Aristide Riou | @aristweet