Measure Camp Paris 2017 – Les 15 astuces pour Google Tag Manager

Après un Measure Camp 2017 une nouvelle fois très smooth, plein de belles conférences, de belles rencontres (et aussi de mojitos), je vous livre, comme promis, une petite synthèse de la mienne (de conférence, pas de rencontre), j’ai nommé « Les 15 Meilleures Astuces Sur Google Tag Manager (La 7ème Va Vous Étonner) ».

Parce que je ne suis pas trop fan de recracher un deck brut sur Slideshare, je préfère reprendre les différents points pour aller plus loin que les slides et essayer (dans la mesure du possible) de reproduire un maximum de mes blagues lourdes de la conf.

Donc, pour ceux qui n’étaient pas sur place, le concept est simple : partager une quinzaine d’astuces liées à GTM (web, surtout, apps, un peu), de la plus simple à la plus complexe, dont j’ai pu éprouver l’utilité dans la vraie vie. C’est un peu comme un post de Simo Ahava, mais en moins bien, mais en français (c’est le jeu, ma pauvre Lucette).

Astuce #01 : Publier un container à vide à sa création

Lorsqu’on insère pour la première fois GTM sur un site, un bon réflexe est de tester, dans un premier temps, que le snippet est bien inséré (au bon endroit du DOM, sans caractères parasites…), et que les attributs standards (gtm.js, page load, etc…) remontent correctement dans le data layer. Or, lorsque le snippet d’un container non publié est appelé sur une page web, on se prend une belle erreur dans les dents :

La raison est simple : à chaque chargement du snippet GTM, votre navigateur va chercher votre fichier gtm.js unique à votre setup (contrairement à l’appel de GA en dur, où il va chercher la librairie analytics.js qui est située à un emplacement statique : https://www.google-analytics.com/analytics.js). Dans le cas de ce blog, mon fichier unique est https://www.googletagmanager.com/gtm.js?id=GTM-KLZQMSP.

En principe, rien de bien grave, mais le problème, c’est que si entre le moment où vous avez remis le snippet à votre développeur et le moment où il est live, vous avez peut être déjà démarré votre setup. Et que vous n’avez pas forcément envie de publier ces changements. Donc, cela veut dire création d’un workspace (on en parle plus bas) ou suppression des changements, publication…#relou.

Par conséquent, quand vous créez un container, pensez à le publier à vide, et, histoire de démarrer sur de bonnes bases, à le notifier dans le nom de version de votre container :

J’aime même aller plus loin dans ma maniaquerie, et, avant la publication, désactiver toutes les variables intégrées, afin d’avoir le conteneur le plus épuré possible :

Astuce #02 : Utiliser des suffixes tags / plan de marquage

Je ne vais pas vous la faire, je pense que vous utilisez déjà des préfixes pour nommer vos tags, variables, et triggers dans GTM.

En revanche, une question qui se pose souvent est le lien entre plan de marquage et setup GTM. Cas typique : je dois modifier une nomenclature d’événement, ou ajouter un cas (par exemple, parce qu’un nouveau bouton de partage social pour un obscur réseau social asiatique a été intégré). En grand professionnel que je suis, j’ai documenté ceci dans mon plan de marquage, mais je ne retrouve pas forcément à quel(s) tag(s) cela correspond dans GTM.

Solution hyper simple, mais qui nécessite un chouïa de rigueur : utiliser un suffixe commun pour tous les tags entre plan de marquage de setup dans GTM :

Utilisation des IDs GTM dans un plan de marquage

Exemple de setup GTM sur application

(oui, je sais, ça fait des screenshots avec beaucoup de floutage, on se croirait dans un reportage sur le petit Grégory)

Alors attention, faire ceci demande une certaine rigueur, dans le sens où vous devez vous astreindre à systématiquement maintenir ceci. De plus, il n’est pas possible d’utiliser cette approche si vous avez des tags d’events ou de pages vues génériques avec des routeurs sur les attributs qui passent dans le data layer (ce que je ne recommande pas, mais c’est un autre débat).

Astuce #03 : Utiliser intelligemment les dates d’expiration

Celle-ci est plutôt simple : l’option de « calendrier de déclenchement des balises personnalisées », présente depuis un bon moment sur GTM, permet, comme son nom l’indique plutôt clairement, de ne déclencher un tag qu’entre deux dates bien précises :

C’est un cas que l’on va typiquement utiliser pour des tags média, qui peuvent n’avoir à se déclencher que pendant une période bien précise. Plutôt que d’avoir à enclencher une publication spécifiquement pour retirer le tag, autant profiter de cette option pour l’anticiper.

Petit aparté tant qu’on est sur le sujet des tags média : personnellement, j’essaye de systématiquement indiquer une date « limite » pour l’ensemble de ces tags. Même s’il faut faire des checks réguliers, cela force à faire régulièrement du ménage, et éviter de surcharger les utilisateurs de milliards de cookies qui vont alimenter toutes les DMP des interwebs.

Astuce #04 : Utiliser intelligemment les workspaces

Je vous avais bien dit qu’on allait se reparler des workspaces! Cette feature est apparue à l’été 2016 après avoir été attendue de longue date. Pour faire simple, l’idée est de permettre à plusieurs personnes de travailler, en parallèle, sur un container, puis de fusionner leurs modifications et de la publier. Oui, c’est plus ou la même chose que l’utilisation d’un outil de versionning en dèv (type Git ou SVN).

L’utilisation la plus évidente des workspaces, c’est le cas où plusieurs interlocuteurs (une agence média, un web analyste, une autre personne en charge de la CRM…) sont amenés à faire des changements en simultané sur un même container.

Ce qu’il faut bien comprendre avec les workspaces, c’est qu’ils se créent depuis la dernière version publiée : concrètement, imaginons que la V12 de votre container contienne 40 tags, puis que vous ayez, hors publication, ajouté 6 tags (soit un total de 46 tags, pour ceux qui suivent). Eh bien si, à ce moment précis, vous créez un nouveau workspace, vous repartirez de la version qui en contenait 40.

Par contre, la différence avec un système de versionning est que vous n’allez pas fusionner (merger, comme on dit chez les gens de l’informatique des internets) vos différents workspaces avant de publier, mais après : on publie une branche, on la publie, puis on y ajoute une autre branche qu’on avait pas publié, etc…

Astuce #05 : Utiliser un random number pour limiter le sampling

La variable {{Random Number}} de GTM fait exactement ce qu’on lui demande : générer un nombre entre 0 et 2 147 483 647 (très précisément), qui, comme toute variable qui se respecte, est déclenché dés qu’on l’invoque, typiquement, dans un trigger :

Ici, on a par exemple divisé ce nombre par 2, ce qui nous donne donc 50% de chances que notre tag soit déclenché. On peut tout à fait diviser par 4 ou plus.

Au-delà de l’astuce pure et dure, je milite (surtout lorsqu’on a pas la chance d’être un nanti qui travaille avec GA360 ou autre outil plus ou moins open bar) pour ne pas systématiquement chercher à ouvrir les vannes lorsqu’on cherche à vérifier l’efficacité d’un nouveau CtA ou autre. Alors certes il faut faire attention aux ratios (si on compare un événement envoyé une fois sur 2 à l’ensemble de ses sessions…), mais disons que ça fait plutôt le job sur un élément assez isolé.

Cela permet aussi de tester sur un tout petit échantillon si on n’est pas sûr de la tête qu’auront les remontées (si on se base sur un sélecteur CSS pas vraiment maîtrisé en remontant les ancres des liens ou autre…).

J’avais déjà traité de l’utilisation du random number dans ma conférence de 2016, pour une utilisation légèrement malhonnête : l’idée était de déclencher un tag d’événement bidon pour faire baisser gratuitement le taux de rebond. Mais depuis, j’ai grandi. Je suis devenu plus mature. Je veux répandre l’amour et la bonté dans le monde du tag management.

Astuce #06 : Utiliser une custom dimension « ID et version GTM »

Facile à mettre en place, allégresse immédiate. Ici, les choses se passent en deux temps : tout d’abord, on commence par activer deux variables natives de GTM, Container ID et Container Version.

Ensuite, on intègre ces deux variables, séparées par un pipe (bah oui, c’est élégant, un pipe), dans une custom dimension de scope hit ou session, que l’on pense bien à utiliser pour surcharger tous ses tags GA (pages vues, events, & cie) :

Premier intérêt : si vous avez, pour une raison quelconque, plusieurs containers qui envoient du trafic sur une même webproperty GA, cela peut vous donner une idée de l’utilisation de chacun dans un custom report de ce type :

Mais surtout, c’est la partie « Version » qui peut être utile : lorsqu’on a la chance d’être sur GA 360, les données qui remontent dans l’interface sont très vite disponibles. Genre. Très vite :

Du coup, lorsque vous faites une publication GTM, et que vous voulez très rapidement voir si les remontées se font correctement, il suffit d’utiliser un petit segment de ce type :

Ainsi, s’il y a besoin de rectifier le tir, vous pouvez le faire très rapidement.

Astuce #07 : Utiliser une custom dimension “nom du tag”

Celle-ci est totalement dans le même esprit, mais à mon sens encore plus pratique pour faire du débug. Le principe est très simple : vous surchargez l’ensemble de vos tags GA avec une même custom dimension, de scope hit, qui reprend le nom du tag tel que vous l’avez mis dans GTM.

Je pense que vous voyez venir le truc, ici l’intérêt est, avec une simple dimension secondaire sur un rapport standard, ou bien un custom report, de voir quel tag GTM est à l’origine de la remontée dans GA.

Cela fait clairement gagner un temps fou lorsque vous avez un event qui ne remonte pas correctement, croyez-moi.

Seul contrainte : c’est une procédure assez manuelle, parce que vous devez recopier à la main le nom du tag, et le mettre à jour si jamais vous décidez de donner une petite jeunesse à votre nomenclature.

Plus largement, cela permet aussi, dans une certaine mesure, de faire de l’analyse sur l’utilisation de vos tags GTM, et de voir lesquels sont les plus déclenchés:

Astuce #08 : Utiliser des try…catch dans ses tags

Nous sommes régulièrement amenés à injecter du Javascript « non templatisé » via GTM. Pour toutes sortes de tags média / publicitaires qui n’existent pas nativement dans l’outil (Weborama, typiquement), mais aussi pour faire des choses beaucoup plus cool.

Par exemple, on peut tout à fait envoyer le tag ci-dessous, en séquentiel après un tag de page, pour alimenter un local storage qui nous donnera le numéro de la page vue par l’utilisateur. Intéressant pour savoir si une page donnée créé plus d’engagement (ex : clic sur des boutons de partage social, scroll…) lorsqu’elle est vue plus loin dans la « vie » de l’utilisateur (non, je ne dirai pas l’INTERNAUTE) :

if(!localStorage.getItem('trkNbPagesVues'))
    //Si le local storage comptant le nombre de pages vues n'existe pas...
		{
		localStorage.trkNbPagesVues = 1;
        //...on le créé
		}

	else{
		localStorage.trkNbPagesVues = parseInt(localStorage.trkNbPagesVues)+1;
         //Dans le cas contraire, on l'incrémente simplement
		}

(l’idée étant, bien sûr, de requêter le local storage en question via une variable pour la mettre dans une CD de scope hit.

Or, vu que nous ne sommes ni 1/ Des stars du JS, 2/que nous sommes un peu feignants sur les tests, et que 3/ Les deux premier points peuvent tout à fait être conciliables, je conseille fortement d’encapsuler tout ce qui est JS dans une instruction try…catch comme ceci :

<script>

  try{
	if(!localStorage.getItem('trkNbPagesVues'))
    //Si le local storage comptant le nombre de pages vues n'existe pas...
		{
		localStorage.trkNbPagesVues = 1;
        //...on le créé
		}

	else{
		localStorage.trkNbPagesVues = parseInt(localStorage.trkNbPagesVues)+1;
         //Dans le cas contraire, on l'incrémente simplement
		}
    }
  
catch(err){
	dataLayer.push({
		event : 'errorGTM',
		errorTag : 'JS - Calcul du nombre de pages vues - GTMPV01',
		errorJs : err
		});}

</script>

L’idée est que, si ce qui est dans le </try> provoque une erreur quelconque, un datalayer.push est envoyé, et passe notamment en argument le « err », qui est l’erreur telle qu’elle s’affiche dans la console de débug. Bien évidemment, l’intérêt, par la suite, va être d’utiliser ceci pour envoyer un tag d’event dans GA :

Typiquement, la mise en place de cette mécanique m’a permis de voir (chose très complexe dans le cadre d’une recette « classique ») que le local storage n’était pas supporté par Safari, en mode anonyme :

Une fois que l’on a l’erreur, il suffit en général d’une petite recherche dans Stack Overflow pour retrouver la cause, et de résoudre le problème tranquillement.

Dans le même esprit, autre mécanique que je n’ai pas encore explorée : les variables GTM qui erreurs JS natives :

Ces variables ont l’inconvénient d’être assez gourmandes (surtout si vous appelez plein de scripts publicitaires qui peuvent être rejetés par un adblocker), mais peuvent également être assez puissantes. Si quelqu’un a eu l’occasion de les tester sur un site à grande échelle, je suis preneur de son feedback.

Astuce #09 : Protéger le tracking des campagnes internes

Un grand classique : vous utilisez, pour tracker vos « campagnes internes », un paramètre d’URL du type « campaign » ou encore une ancre dans l’URL de destination. Par exemple, sur l’incroyable site www.ouest-france.fr, un clic sur la barre « En ce moment » qui récapitule les sujets chauds de la semaine renvoie vers une URL contenant l’ancre « from-en-ce-moment » :

Pour faire remonter un event ou surcharger le hit de page avec une custom dim, c’est simple, il suffit d’utiliser la variable native de GTM qui va chercher les ancres, ou alors « fragment » comme le nomme mystérieusement l’interface :

Or, le problème, si vous déclenchez un event simplement basé sur la présence de l’ancre, est plus ou moins le même que les fu***** UTMs : si une célébrité comme Squeezie, Barrack Obama ou Yoann Gourcuff partage un lien comportant cette ancre sur un réseau social, le compteur va être totalement faussé.

Donc, bonne pratique, ajouter à son trigger un contrôle sur le referrer (là encore, variable native qui fait totalement son job) :

Apparté technique : même si cette méthode est beaucoup utilisée, cela reste assez moyen de « gaspiller » des ancres ou paramètres, qui ont un sens sémantique, et peuvent générer du duplicate content (kikoo les SEO), ou encore rendre votre cache moins efficace (kikoo le sysadmin). Si vous voulez tracker des clics, utilisez un listener de clics. Point à la ligne.

Astuce #10 : Mettre ses données e-commerce à plat

On arrive à l’avant-dernière astuce de GTM version web, sûrement la plus complexe, qui est liée à l’enhanced e-commerce.

Pour ceux qui ont déjà au l’occasion de faire une implémentation GA enhanced e-commerce via GTM, vous avez sûrement sagement regardé la doc de Google, qui préconise, par exemple, d’alimenter de la sorte le data layer sur une page de checkout :

<script>
/**
 * A function to handle a click on a checkout button. This function uses the eventCallback
 * data layer variable to handle navigation after the ecommerce data has been sent to Google Analytics.
 */
function onCheckout() {
  dataLayer.push({
    'event': 'checkout',
    'ecommerce': {
      'checkout': {
        'actionField': {'step': 1, 'option': 'Visa'},
        'products': [{
          'name': 'Triblend Android T-Shirt',
          'id': '12345',
          'price': '15.25',
          'brand': 'Google',
          'category': 'Apparel',
          'variant': 'Gray',
          'quantity': 1
       }]
     }
   },
   'eventCallback': function() {
      document.location = 'checkout.html';
   }
  });
}
</script>

(Si tu as déjà fourni ce genre de specs à un développeur et qu’il a essayé de te casser les genoux, tape dans tes mains)

Donc oui, mais non. Non, parce qu’implémenter ceci en dur sur votre site revient à assumer toute la complexité de GA directement côté dèv. Et donc que GTM n’a plus vraiment de valeur ajoutée. Dans le même ordre d’esprit, imaginez que vous ayez besoin d’accéder à un attribut lié à un produit pour poser un autre tag quelconque (par exemple, vous devez poser un tag de retargeting sur tous les produits de la marque Adidas). Eh bien s’il faut aller fouiner dans un objet lui-même enfoui dans le data layer, c’est faisable, mais contraignant.

Donc, nous allons refaire les choses proprement, étape par étape, en reprenant l’exemple de nos étapes de checkout :

Step 1 : sur toutes ces pages, faire poser un data layer à plat (ou n’oublie pas d’alimenter le data layer avant l’appel au snippet GTM) :

var dataLayer = [{
	'checkoutStep' : '1',
	'productName' : 'Super baskets',
	'productBrand' : 'Adidas',
	'productSize' : '42',
	'productPrice' : '70'
        //On peut en mettre plein d'autre, hein, c'est pour l'exemple là, on se CALME
	}];

Step 2 : dans GTM, nous allons mmapper ces différentes variables au sein de GTM

Pour reprendre notre point de pose de tag de retargeting vu plus haut, on a déjà l’avantage de pouvoir accéder, facilement, à nos différents attributs produits directement via GTM.

Step 3 (le plus intéressant) : on créé notre mappeur. En fait, ce qu’on va tout simplement faire, c’est reprendre ce que Google nous racontait dans la doc, et le mettre en place purement via GTM, en s’appuyant sur les variables en question :

dataLayer.push
		({
		'ecommerce':
			{
			'checkout':
				{
				'actionField':
					{
					'step':{{DL - checkoutStep}}
					},
				'products':
					[{
					'name':{{DL - productName}},
					'id': {{DL - productId}},
					'price':{{DL - productPrice}},
                    'brand' : {{DL - productBrand}},
					'category':{{DL - productCategory}},
                    'quantity': 1
					}]
				}
			}
		'event':'MapperEEC'		
		});

L’idée est de déclencher ce tag en JS custom sur toutes les pages où vous avez un attribut ‘checkoutStep’ de renseigné (par exemple). Notez bien que l’on pousse le fameux attribut ‘event’ après avoir mis en place notre mapper. Il va nous servir dans un instant.

Step 4 : envoyer le tag de page

Notre mapper, en tant que tel, ne sert à rien ; il va falloir maintenant envoyer un bon vieux tag de page GA, qui ira utiliser ce data layer que nous avons mis en place (en pensant à cocher les options qui vont bien dans GTM) :

Pour le déclenchement, il faut bien penser à n’envoyer le tag de page qu’après avoir « dimensionné » notre data layer. C’est donc pour ça que que le trigger est basé sur l’event « MapperEEC » :

Voilà. C’est tout. Alors évidemment, ne croyez pas que ça va être aussi facile. Vous devrez paramétrer différents mappers correspondant aux différents cas que vous devrez tracker : impressions, étapes du checkout, remboursements…Forcément, les attributs produits ne seront pas exactement les mêmes selon les cas.

Évidemment, la question qui se pose tout de suite, c’est « Hé t’es sympa, mais comment je fais si j’ai plusieurs produits? ». Cela va nécessiter un peu plus de travail, mais sans que ça soit si complexe.

Côté data layer « en dur », il faut indiquer les attributs séparés par des pipes : ‘productBrands’ : ‘Nike|Adidas|Puma’, ‘productIDs’ : ‘123456|789456|333222’, etc…

Là où c’est un peu plus complexe, c’est pour faire le mapper : il faut, pour créer le sous-objet « product », faire une boucle « for » sur la longueur de ces différents attributs ({{productsBrands}}.split(‘|’).length()) pour créer le sous-objet « products ». Après, je vais pas non plus faire tout le boulot pour vous, hein? Allez, tchouk tchouk, on y va là!

Astuce #11 : Factoriser ses triggers

Vous pouvez avoir, pour différentes raisons, un container GTM placé sur différents domaines. Typiquement, il peut s’agir d’une batterie de mini sites, sur lesquels vous avez un tracking factorisé et assez généraliste : imaginons que ces sites soient www.monsupersite.com, www.encoreunsite.com, www.untroisiemesite.com…Potentiellement, cette liste peut être amenée à évoluer avec des nouveaux sites.

Imaginons maintenant que, sur ces sites, vous ayez un certain nombre de tags génériques, en plus de votre tag de page GA : un tag de retargeting Adwords, un autre pour Facebook, encore un pour votre super solution de DMP, etc…

Le premier réflexe, pour gérer ces différents tags, est d’utiliser ce type de trigger :

Petit apparté : évitez d’utiliser le trigger « All Pages », qui est un gros risque si jamais vous vous faites scrapper tout votre contenu, et qu’il est exécuté sur un domaine tiers.

Le problème, c’est que si vous avez différents triggers qui utilisent cette même regex, vous devez, à chaque fois, les mettre à jour. C’est typiquement la tâche qui passe à la trappe lors d’une publication, et dont on voit l’impact quelques jours plus tard lorsqu’on reçoit un coup de fil d’une agence média hystérique parce qu’ils n’ont pas pu vendre les données de vos utilisateurs à leur solution de DMP.

Du coup, il est possible de factoriser tout ceci, assez simplement, avec une variable en JS comme ceci :

Cette variable ne va retourner « true » que dans le cas où le nom d’hôte correspond à la liste que vous avez rentré dans votre regex (et vu que, justement, il s’agit d’une regex, vous pouvez même avoir des conditions assez fines sur les URLs).

Ensuite, vous n’avez plus qu’à conditionner vos tags via un filtre sur cette regex, et hop, en avant Guingamp :

Comme ça, dés que vous avez besoin d’ajouter un ou plusieurs domaines à votre liste, facile : il suffit de mettre à jour la variable JS, et vos tags suivront tout seuls, comme des grands.

Astuce #12 : Exporter et mettre à jour ses containers d’apps

Allez, fini avec GTM web, maintenant parlons un peu des apps.

Sur une page web, l’exécution de GTM est assez mécanique : la page se charge, le snippet GTM est lu, et (bien évidemment), à moins de changer de snippet, vous n’aurez jamais à le changer.

Sur une app, c’est (un peu) plus compliqué, puisque votre container est embarqué en dur : concrètement, cela veut dire que vos gentils développeurs d’apps Android et iOS doivent inclure dans leur app un fichier JSON qui reprend l’ensemble de vos tags, triggers, et variables.

Il suffit d’aller dans l’admin d’un container GTM app, et de cliquer sur « Télécharger » au niveau de la dernière version de votre container :

Pour autant, ne croyez pas que vous devez inclure le le container à chaque publication, et donc, faire une soumission d’app. Lorsqu’un utilisateur lance l’app, cette dernière tourne avec le container qui est embarqué, mais vérifie sur les serveurs de Google s’il existe une version plus récente, auquel cas il se met à jour.

Il faut retenir deux choses :

1/ S’il y a une différence entre la dernière version de votre container embarquée dans l’app, et la dernière version publiée dans votre admin GTM, le temps que la mise à jour se fasse, ne vous étonnez pas si vous avez des hits qui partent encore mais qui ne correspondent pas à votre derniers updates, et donc 2/Dès que vous faites une publication, pensez à exporter le container et à le donner à vos développeurs, pour qu’ils puissent l’inclure lors de leur prochaine publication. Cela ne veut pas dire que ce delta n’existera plus, mais au moins, vous le diminuerez

#comboMagique : l’astuce 06 (utilisation d’une CD avec l’ID et la version de votre container GTM) vous permet de voir quels hits sont concernés par ce delta, ce qui peut être bien pratique.

Astuce #13 : Avantages et inconvénients de GTM V4/V5 apps

Vous n’êtes pas sans savoir que depuis 2016, Google intègre de plus en plus la suite d’outils pour apps Firebase à son écosystème. En particulier, cela est vrai pour l’analytics et le tag management. Penchons-nous un instant sur la façon dont fonctionne GTM depuis l’arrivée de Firebase.

La première chose importante à comprendre, c’est que Firebase en lui-même est un outil d’analytics. Je ferai peut-être un article spécifique à son sujet un jour, mais sachez que si l’outil est moins malléable que GA, il apporte une vision intéressante et nettement plus « user centric » (forcément, quand on a pas besoin de dépendre des cookies…).

Pourquoi est ce que je parle de ça dans le cadre d’un article sur GTM? Parce que dans le cadre de cette intégration accrue de Firebase, vous avez désormais un choix à faire lors de la création d’un container GTM pour une application iOS ou Android :

Choix d'une version de container GTM pour app

Si vous choisissez de passer par Firebase (autrement dit, la Version 5 de Google Tag Manager, par opposition à l’ « Ancienne version » qui est la V4), cela va signifier, concrètement, que plutôt que de faire passer des attributs dans un data layer, vous allez poser du tracking Firebase, en dur. Oui, oui, c’est bien ça, vous allez poser du tracking qui va venir alimenter la partie « Analytics » de Firebase.

L’intérêt (puisque c’est quand même, en général, GA qui nous intéresse), c’est que Firebase va servir de « passe-plat » pour venir alimenter des tags d’écran ou d’event dans votre UA app. Concrètement, dans Firebase, vos développeurs ne vont faire que renseigner un type d’élément : des events. Que ça soit pour un affichage d’écran, un partage social, une activation de réglage quelconque, event, event, et encore event. A chaque event peut être associé un certain nombre d’attributs (le réseau social du partage, le nom du screen, la valeur du réglage…). En fin de compte, GTM permettra (en V5 donc) de faire un routage élégant de ces éléments vers votre UA, en capitalisant intelligemment sur les variables.

En somme, ce n’est pas très différent d’un plan de marquage à base de data layer comme on en a l’habitude sur les apps, si ce n’est qu’en plus, vous avez Firebase en tant qu’outil d’analytics exclusivement pensé pour votre app.

GTM V5 possède quelques autres avantages : de nouveaux tags sont intégrés nativement (AppsFlyer, Tune…), ainsi que de nouveaux triggers, qui permettent de tracker nativement la réception d’une notification, la première ouverture de l’app…Très prometteur sur le papier, mais je n’ai pas encore eu le temps d’avérer leur efficatité.

Astuce #14 : Débugguer facilement ses apps sous Firebase

Spéciale dédicace à mon collègue Valérian Hélias, qui est l’auteur de cette merveilleuse trouvaille après avoir fouiné dans les tréfonds de la doc Firebase.

On continue sur les apps et Firebase, avec une astuce qui va, j’en suis convaincu, vous faire gagner un bon paquet d’heures de santé mentale : le débuggueur intégré de Firebase.

Pour les chanceux (ou pas) qui ont déjà fait du débug d’apps, vous devez savoir à quel point c’est une fucking tannée. Pour ceux qui n’ont pas de chance, le setup minimaliste, c’est de proxifier votre wifi sur lequel vous connectez votre smartphone, puis de sniffer les tags GA via un outil comme Fiddler. C’est franchement lourd, parce que ça requiert du setup, parce que les hits GA partent en batch (environ toutes les 2 minutes), et surtout parce que vous ne pouvez pas vraiment voir ce qui part à la racine, dans Firebase.

Pour ceux qui sont proches de leurs développeurs, il existent une bonne alternative intermédiaire : avoir directement accès à Xcode et/ou Android Studio, pour pouvoir accéder aux versions en cours de dèv de vos apps (en se branchant par exemple sur leur Git), les builder sur un device physique ou virtuel, et afficher les logs Firebas dans la console de débug. C’est très pratique, mais ça nécessite pas mal de setup.

Voilà à quoi ressemble la fameuse console de débug de Xcode :

Mais en fait, il existe une solution à peu près parfaite, aussi complète que le débug sur Xcode, mais qui requiert nettement moins de setup.

Cela nécessite un tout petit peu de travail côté développeur, puisqu’ils doivent inclure une instruction spécifique pour les versions de test (la doc est disponible ici si ça vous intéresse).

Une fois que vous avez récupéré la version de test en question (souvent, via une application intermédiaire comme TestFlight ou Beta), vous n’avez plus qu’à aller dans la partie « Debug View » de votre console Firebase, où vous voyez passer, quasiment en live (il y a à peine une quinzaine de secondes de décalage), les paramètres Firebase (l’équivalent du data layer) :

Cet écran est un summum de la smoothitude de l’esthétique du debugging. Vous voyez tous les events qui sont passés depuis les 30 dernières minutes, ceux qui sont en erreur, les paramètres qui passent conjointement à chaque event, et même les propriétés utilisateur (qui sont une sorte de data layer persistant, idéales pour les CD de scope session, j’en reparlerai un jour). Bref, c’est juste la fête du slip pour débugguer Firebase comme vous débuggueriez (débuggueriez, ça se dit, ça?) votre data layer, OKLM, sur votre site web.

Ainsi, cela veut dire que si des tags GA ne se délenchent pas correctement, vous pourrez facilement identifier si le problème vient de l’alimentation via Firebase, ou de votre setup GTM.

Astuce #15 : Débuter sur GTM

J’avais profité de ma conf au MeasureCamp pour faire un peu d’autopromo pour ce blog, et notamment pour mon formidable tutoriel sur GTM que j’ai fait avec tellement d’amour et de tendresse. Après, si vous êtes déjà arrivés au bout de ces 4450 mots, je pars du principe que vous accrochez sur GTM, et que le sujet vous intéresse un minimum.

Astuce #15,2 : Le deck

Bon, et si vous y tenez vraiment, j’ai quand même uploadé le deck de ma conférence sur Slideshare :

Si vous avez trouvé ça nul, génial, que vous n’avez rien compris, ou que vous attendiez avec trop d’impatience les bagels pour écouter que ce soit, bien évidemment, n’hésitez pas à lacher vos comms’ comme on disait à la grande époque de Skyblog, où bien à m’envoyer un petit tweet, courriel, snap, poke, fax, recommandé, pigeon voyageur…

6 commentaires

  1. Merci Aristide, on retrouve le professionnalisme, et aussi le ton humoristique de tes interventions. Ayant moi-même opéré dans le domaine du TMS, mais pour une solution sans container, je découvre le nombre incroyable de points d’attention auxquels je n’aurais pas pensé…
    Comme quoi, l’expérience c’est utile 🙂
    Et oui, ouest-france.fr est un bien beau site à l’image du journal que j’ai souvent lu (j’ai surtout écumé les résultats sports du lundi matin à titre perso, et les jeux d’été de Rophi en dernière page).
    Cordialement,
    YML

  2. Hello Aristide,

    Merci pour ta réponse à ma question sur l’étape 4/7 du DL qui me renvoit ici.
    J’ai lu ton astuce #10 mais comme je ne suis absolument pas dev avec la boucle for tu m’as perdu ah ah ah !
    Je vais en parler avec mon dev en lui proposant les deux solutions reco google et ta reco 😀 !
    A part le fait de devoir déclarer les variables du DL sous cette forme exemple avec la reco google : ecommerce.purchase.actionField.id
    Quelle(s) autre(s) fonctionnalités perd-t-on ?

    Merci 🙂

    Amélie.

    • @Amélie, tu verras, ton dèv te remerciera!
      Attention cependant, on ne « perd » pas de fonctionnalité (au sens de ce qui remonte dans GA) en faisant un data layer « à plat », c’est simplement qu’on assume un mapping complexe et très spécifique à GA dans GTM, et non pas côté dèv, en dur.

      • Hello Aristide,

        Je reviens vers toi, pour te tenir au courant ! C’était déjà tellement sympa de ta part de me répondre 🙂
        Mon dev a choisi de suivre à la lettre la reco google (premier implémentation de GTM pour lui)
        Pour le moment, ce n’est pas bloquant à mon niveau on verra dans le temps 🙂 !
        Merci en tout cas !

        • Justement je suis en train d’écrire un article sur enhanced e-commerce, je vais aller plus loin dans la méthodo, avec page de démo & cie, ça te donnera l’occasion de comparer!

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *