Google Analytics et Google Tag Manager « at scale » : gérer une implémentation dans une grosse organisation

Ça fait maintenant une dizaine d’années que je traîne ma carcasse sur les outils de la suite Google Marketing Platform, et notamment Google Analytics / Tag Manager. Au cours de cette (déjà) décennie, au delà d’avoir vu évoluer (pas tant que ça) ces outils, je me suis rendu compte de 2 choses :

• Sur chaque projet / site / client, se posent toujours les questions du nombre de webproperties (UA) et de vues, de containers GTM… Et d’ailleurs, parfois, les questions ne se posent pas. Enfin pas assez. Conséquence…
• …lorsqu’il s’agit de rattraper des « erreurs » à ce niveau, on le paye cash. Si ça vous est déjà arrivé, vous le savez. Expliquer à un client / collègue que du jour au lendemain, son SEO va passer de 30 à 10%, qu’il ne va plus pouvoir utiliser d’UTMs mais des « paramètres internes », qu’il risque soudainement d’être soumis à plus d’échantillonnage… Pas toujours super fun. Et pas toujours simple à vendre si vous êtes une agence / free lance, quand bien même l’erreur a été faite par votre prédécesseur.

Spoiler alert : il est possible que cet article contienne quelques coups de gueule. Toute ressemblance avec des personnes existantes ou ayant existé est purement fortuite (non).

Côté Google Analytics

Commençons par les bases, voulez-vous, à savoir l’organisation sur la partie Google Analytics. Si on analyse ceci froidement d’un point de vue technique, GA pose un cookie top-level domain pour chaque UA. Donc, la logique veut que l’on ait un UA par top level domain (TLD). Si j’ai un site e-commerce monsite.com, avec ensuite des répertoires monsite.com/fr, monsite.com/de… pour chaque pays, je fais la répartition vue par vue. Si j’ai la même logique, mais avec une arbo avec des sous-domaines (fr.monsite.com, de.monsite.com)… Même principe, donc.

Donc je pense (coup de gueule incoming) que tout setup où « oh bah on a mis le sous-domaine du e-commerce à part du site édito parce que, bah, voilà quoi, c’est deux trucs différents » (en gros, parce qu’on ne s’est pas posé la question) est tout simplement une erreur. Il y a une convention, on la respecte, point barre. Sauf si on a une bonne raison de ne pas le faire.

Donc, pourquoi donc ferait-on un choix différent, à savoir utiliser plusieurs UAs pour un même top level domain? A mon sens, il n’y a que 2 bonnes raisons de le faire :

• Vous avez besoin de beaucoup de vues. Genre, plus de 20. Parce que oui, si vous n’êtes pas au courant, Google limite, au moment où j’écris ces lignes, le nombre de vues à 20 par propriété. Si vous avez un site e-commerce avec 35 pays, ayant chacun leur sous-répertoire ou sous-dossier, on peut donc router via GTM sur 35 UAs différents (même si vous allez souffrir pour tout configurer).
• L’échantillonnage. Vous avez par exemple 3 ou 4 sous-domaines, qui fleurtent gentiment avec les limites dés que vous tapez les données sur une période un peu conséquente, et vos analyses peuvent être faites de façon autonome d’un sous-domaine à l’autre. Donc si on peut éviter de se prendre de l’échantillonnage, autant ne pas se priver.

A contrario, je vois souvent des différenciations faites qui ne sont à mon sens pas justifiées :

• Le « on s’est dit que c’était 2 trucs différents » sus-mentionné. Allez directement en prison, ne passez pas par la case départ, ne touchez pas 20 000 francs.
• Il y a aussi le cas de « ce sont 2 équipes qui travaillent totalement en autonomie et ne se parlent pas ». Okay, mais qu’elles ne se parlent pas au travers de 2 vues, et non pas de 2 UAs, ça ne devrait pas changer grand chose à leur quotidien de ne pas se parler.
• « Comment on va faire pour l’historique des données? ». Eh bien le stagiaire qui fait GA –> CTRL + C, Excel –> CTRL + V va apprendre qu’il devra le faire sur un nouvel UA. Ce n’est pas comme si c’était un être humain.

La question peut, en revanche, se poser dans l’autre sens. Je m’explique : un client possède un ensemble de sites variés, qui peuvent être situés sur un ensemble de domaines eux aussi variés. J’ai par exemple travaillé, dans ma jeunesse, pour un constructeur automobile qui possédait un site « principal », et, pour les demandes d’essai, un domaine par véhicule (essai-voiture1.fr, essai-voiture2.fr)….

Déjà, il faut toujours se poser la question de savoir si tout passer sur un seul TLD est une option ou pas, en expliquant les avantages par rapport à un cross-domain tracking (dont je ne vais pas vous ré-expliquer la foultitude d’inconvénients ici), et surtout en se retenant de défenestrer le directeur artistique qui trouvait que essai-voiture1.fr ça « passait mieux en print » (toute ressemblance est purement fortuite, que je vous dis). Et puis les bénéfices SEO, j’en passe et des meilleures.

Si cette option n’est pas envisageable, on peut malgré tout « consolider » ces différents domaines au sein d’un seul et même UA, éventuellement en prenant soin d’ajouter le nom d’hôte au page path de GA, et en étant vigilant dés qu’il s’agit d’analyser des metrics de récurrence quand une analyse porte sur plusieurs domaines.

Deux derniers points d’importance :

• Le fait d’avoir Google Analytics 360 (pour les chanceux qui sont dans ce cas) peut solutionner les 2 cas « légitimes » ci-dessus : en effet, pas de problème d’échantillonnage, et possibilité d’étendre le nombre de vues au-delà de 20 pour un même UA (il suffit de demander gentiment au support de Google, ou bien de passer par la gentille agence qui prend ses 20% de marge fait le relais avec ledit support).
• Faut-il avoir un UA pour la prod et un pour la préprod? A mon sens, non, on respecte la logique du top level domain si votre préprod est sur quelque chose comme staging.monsite.com, on fait le distinguo par des vues. Ça n’a l’air de rien, mais ça peut toujours être utile de tester des choses (typiquement, un setup enhanced e-commerce) de bout en bout, et de vérifier la bonne remontée de GA sur votre commande faite en préprod. Eh bien si vous avez un setup un peu fin (custom dimensions, content grouping, filtres…), bon courage pour vous taper tout le boulot en double sur les 2 UAs. Et si vous ne voulez tout simplement pas de la préprod dans vos données, filtrez la à la racine côté GTM.

(de toute façon, GA c’est bientôt mort, avec GA V2 on va devoir ré-apprendre tout ça, le temps que tout le monde migre ça prendra à peine 8 ans).

Côté Google Tag Manager

Passons maintenant côté GTM. Comme pour GA, je vais partir d’un postulat technique, qui est souvent oublié par pas mal de monde (coucou les « non technical marketers ») :

GTM, ce n’est que du Javascript. GTM fait partie de votre codebase.

Lisez cette phrase 4 fois, et répétez-la à voix haute (vos voisins vous jugeront, mais après tout, ils déjà savent que vous êtes une personne étrange). Au même titre que vos CSS, votre app Ruby on Rails, votre microservice agnostique Java QuatrePointDouze, le JS généré par GTM est une brique de votre code comme une autre. Certes, une brique très encadrée, mais qui ne vous empêche pas de péter la prod (allez, on est entre nous, on sait que ça vous est déjà arrivé, on ne se cache rien ici).

A partir de là, j’ai une règle qui peut être parfois dure, mais finalement pleine de bon sens : un repo = 1 container. Un re-quoi? Un repository, une base de code, un truc disponible sur Git(hub|lab|machin) et sur lequel vos développeurs commitent lorsqu’ils ne sont pas occupés à s’engueuler pour savoir si Java est plus performant que PHP pour les microservices d’authentification.

Typiquement, j’ai parfois vu un gros e-commercant posséder plusieurs sites européens, gérés sur un gros CMS (à tout hasard, Magento), mais pour lequel une obscure agence avait décidé qu’il fallait mettre un container GTM par pays.

Toujours est-il que dans ces cas de figure, le code PHP, JS ou autre est en règle générale commun à l’ensemble des pays. Donc, gérer les particularités locales (UA, ID de Pixel Facebook, de compte Google Ads…) à base de bonnes grosses tables de correspondance n’a rien d’insurmontable.

Petit apparté : étape conjointe mais néanmoins nécessaire, l’étude de la stack technique d’un client en amont de l’implémentation. Je vois encore trop de webanalystes avoir déjà vendu un projet de « dashboard user centric 360 ta sœur » sans avoir la moindre idée de la techno qu’il y a derrière, du nombre de dèvs impliqués sur le projet, de la dette technique… Ce qui conduit souvent à des implémentations qui se finissent dans les larmes et le sang (du client).

Donc, un repo = un container GTM. Si vous avez un CMS « sur étagère » (WordPress, Prestashop) il est très possible que vous ayez un module GTM qui existe quelque part. Et si vous utilisez quelque chose d’un peu plus bas niveau type MVC (Ruby on Rails, Django, Laravel), intégrer le snippet GTM dans le template HTML de base est d’une facilité déconcertante, tout comme calculer un data layer.

Voilà pour la règle générale, passons maintenant aux exceptions :

Comme pour la partie sur GA, on ne peut pas passer à côté du client qui a, au même titre que pléthore de domaines, pléthore de sites, sur plein de technos différentes, certains très temporaires, certains plus durables.

Une nouvelle fois, il est toujours utile d’avoir une discussion (armes tranchantes toujours interdites) sur la cohérence technique de votre client / employeur. Est-ce bien raisonnable de faire un site « de campagne » sur React alors que tout redirige vers le site « amiral » en « CéPlusPlus » où il faut donner son groupe sanguin et son numéro de sécurité sociale pour pouvoir passer une commande? Je digresse, mais dans ce cas, il faudra être malin pour ce qui est de l’organisation côté GTM : gérer un nouveau container par site « poubelle » est une option, tout comme avoir un gros container avec une configuration assez générique « by design », et gérer quelques particularités (events, tags média…) au cas par cas.

Très concrètement, pour parler de mon expérience perso chez Ouest France, la structure était plutôt simple :

• Une petite dizaine de containers pour les sites qui nécessitaient le plus de finesse dans l’implémentation : le site éditorial, le site avec la liseuse du journal papier, le site e-commerce (souscription d’abonnements), le site de gestion de compte (désabonnement, transferts…). Chacun de ces sites avait une techno particulière, son product owner, son équipe de dèv, son rythme de releases… Donc GTM suivait la vie de chacun de ces sites.
• Un gros container « minimaliste » avec un setup destiné à tourner sur, bah, le reste, en fait. En particulier, les nombreux sous-domaines gérés par des partenaires extérieurs, mais aussi des petits sites pas ou peu maintenus, sur lesquels un simple tag de page fait le job. A noter que ce container a beau être minimaliste, sa config doit tout de même être faite avec finesse, pour s’adapter à tous les sites présents (whitelist de domaines, routing vers des UAs…).

A noter que ce type d’organisation ne doit pas nécessairement être figé, un site pouvant passer d’un container dédié (« Ouah il faut absolument qu’on mesure les clics sur le footer de ce nouveau site sur la verticale de la planche à voile ») à un container générique (« bon finalement la planche à voile c’est pas si porteur, c’est de la faute de Google News »). Donc, cela peut être un bon réflexe d’en parler en toute transparence au dèv en charge de l’implémentation : « hé cousin, l’ID du container peut changer, tu as moyen de prévoir une variabilisation, voire de pouvoir changer ceci sans nécessairement passer par une mise en prod? Merci, bisous ».

Autre point un peu dans la même veine et pas nécessairement simple à gérer, le cas d’une organisation ou une entité centrale va gérer certaines choses (typiquement, l’analytics), mais où les entités locales vont gérer d’autres choses (typiquement, les tags média). Celui là est un grand classique, et j’ai vu de véritables usines à gaz générées par ce type de setup (attention, âmes sensibles s’abstenir) :

Le central gère un gros GTM, met environ 3 mois à intégrer le moindre bout de JS, et chaque publication passe par une passe du département QA. Parfois, ils refusent d’intégrer un tag, parce qu’il est « dangereux ». Parfois, il y a besoin de faire une « analyse technique » du tag (mec, c’est un pixel Facebook, tu n’as pas envie de savoir ce qu’il y a dedans). Bref, le tag management ça devait être un truc un peu rigolo et flexible, mais bon en fait non (« oui mais attends pour une mise en prod en dur c’est plutôt 7 mois lol »).

A un moment donné, un petit rigolo dans une entité locale trouve le moyen d’intégrer un GTM « enfant » dans le GTM « parent ». Le central met 1 an à s’en rendre compte, et c’est une vraie boucherie : il y a des conflits de data layer, de config GA, du JS injecté n’importe comment…

Concrètement, ce genre de configuration central / local est toujours délicat à gérer, mais je vais me mouiller : j’aurais une préférence pour que l’entité centrale garde le contrôle sur un container GTM unique, en étant bien organisé, avec un process de demandes clair pour que les interlocuteurs locaux puissent faire des demandes, et qu’elles soient publiées rapidement. Même si ce n’est a première vue pas le truc le plus fun d’avoir une bonne orga de tags média, les gérer avec un regard « central » peut permettre d’avoir des choses un minimum factorisés. Par exemple, si un pays a déjà mis en place un setup de pixel Facebook un peu avancé (abonnement newsletter, conversion, consultation de contenu…), et qu’un autre pays arrive avec une demande un peu similaire, il est souvent possible de conserver un seul tag dans GTM en variabilisant simplement l’ID du compte Facebook. Comme ça, plusieurs pays bénéficient de l’expertise en tag management du central, le tout est déployé plus vite, et cela génère moins de code, donc un site plus performant. Amen.

A noter qu’il existe une autre feature un peu méconnue dans GTM qui peut être super utile pour gérer finement ce cas : les Zones. Très concrètement, il s’agit de faire du « GTM Inception », avec un container « enfant » appelé depuis le parent, mais de façon très contrôlée : on peut par exemple décider que le container enfant ne peux gérer que certains types de tags (Criteo, Google Ads, AB Tasty…). Problème : les Zones sont une feature exclusive à GTM 360 (oui, il existe un GTM 360, et c’est à peu près la seule feature intéressante par rapport à la version gratuite), donc ce n’est pas une possibilité pour les petites gens qui n’ont pas de sous.

Au même titre que je finissais la partie GA par la question de savoir s’il fallait un UA pour la prod, et un autre pour la préprod, même question ici : faut-il un container GTM dédié pour la préprod? A mon sens non, c’est au contraire une erreur technique : on dit toujours que la préprod doit être autant que possible iso prod, donc pourquoi en serait-il autrement côté GTM? Bien sûr il est parfois nécessaire d’éviter le déclenchement de tags en préprod, mais cela se gère sans problème avec des triggers bien affûtés.

Il existe aussi une feature assez méconnue de GTM permettant de gérer ceci plus prudemment, les « environnements » :

Si vous tenez absolument à déployer de façon contrôlée (bon, après, il y a aussi la preview GTM qui est en elle-même une sorte de préprod), je vous conseille de l’utiliser, même s’il y a quelques petites subtilités à conntaître (promis, un jour je ferai un article sur le sujet).

Et pour les apps iOS et Android?

La question de GTM sur les apps (iOS / Android) concerne sans doute une très faible minorité d’entre vous, mais je pense qu’il est utile d’en parler, car le principe est finalement le même : un container par codebase paraît également une mesure logique. Il y a simplement 2 subtilités à avoir en tête :

• Même si vos apps iOS et Android sont strictement identiques d’un point de vue paramètres Firebase (=data layer), et que ce que vous routez sur GA est également iso, il est obligatoire d’avoir un container par OS. Donc un container iOS, un container Android, même si les tags, triggers et variables sont les mêmes.
• Dans certains cas, un même repo peut générer plusieurs apps. Par exemple, les applications Android Ouest France, Courrier de l’Ouest, et Maine Libre sont à peu près identiques en termes de code, bien que différentes sur les stores. Et si on souhaite tout de même rediriger vers 3 UAs différents, pas besoin d’avoir 3 containers GTM, on peut utiliser la variable native « ID de l’application » (son nom « technique ») pour faire ce genre de table de correspondance :

Smooth, non?

Et pour AMP?

Une nouvelle fois, j’imagine que cela ne doit pas concerner une immense majorité du (pourtant très distingué) lectorat de ce blog, mais je vais couvrir le 4ème type de container GTM, à savoir celui concernant les pages AMP.

La démarche sera finalement la même, mais arrêtons nous tout de même sur la façon dont est faite une page AMP : il s’agit au final ni plus ni moins qu’une page sous un format HTML un peu particulier. Dans l’immense majorité des cas, ce qu’il y a en back (classiquement, dans un WordPress ou un Drupal) est strictement identique, et typiquement, le data layer peut être déversé exactement avec la même logique sur une page web « classique » et sur une page AMP. Différence importante, cela dit : impossible d’exécuter des tags en JS sur une page AMP (dommage, hein?).

Pourquoi je vous parle de tout ça? Tout simplement parce qu’il est tout à fait raisonnable d’avoir un container AMP aligné sur le repo / CMS qui gère votre éditorial (WordPress, Drupal), dans une configuration forcément plus minimaliste. Et donc, si vous avez un même repo qui gère plusieurs domaines / UA, il n’y a pas plus de raisons, dans le cas d’AMP, d’avoir des containers différenciés, une bonne vieille table de correspondance des familles fera parfaitement le job.

Conclusion

Si vous ne deviez retenir que 3 choses de cet article, les voilà :

• Prendre une décision d' »architecture » concernant GA et GTM doit démarrer par une bonne compréhension de la logique technique qu’il y a derrière ces 2 outils.
• Il faut impérativement comprendre comment fonctionne l’organisation de votre client / entreprise.
• Il est également impératif de savoir quelle est la (les) stack(s) technique(s) derrière ce que vous allez tracker.

J’ai essentiellement parlé de GA et GTM, mais je pense que les gens plus experts que moi sur d’autres outils de la suite Google (Data Studio, Search Console, BigQuery), voire d’autres outils (Adobe, Matomo…) pourront tout à fait transposer et adapter cette réflexion à leurs problématiques.

Il est tout à fait possible que j’aie loupé / oublié certaines choses, et que vous ne soyez pas d’accord : n’hésitez pas à en parler dans les commentaires ou sur Twitter. En cas de désaccord profond, je connais quelques très bons parkings pas très éclairés de supermarché de la région rennaise où régler ça « à l’amiable ».

A très bientôt, tendresse et chloroquine.