Une agence de tracking qui a cessé de faire de la maintenance

Une agence construite autour de la mesure

Brandon Teuben et Martijn Udo se sont rencontrés en tant que freelances, en construisant ensemble des stacks de tracking complètes et des data warehouses. Brandon avait passé 12 ans dans le marketing digital, dont un an et demi chez IPG Media Brands en Australie : il sait donc gérer des campagnes. Ils ont pourtant laissé la publicité de côté, car ils voulaient que chaque heure passée dans l’entreprise aille à la mesure.

Ce choix vient de ce que Brandon a vu au sein des agences marketing. Environ 90 % du chiffre d’affaires venait de la publicité, le tracking étant vendu en complément. Les nouvelles recrues étaient formées comme spécialistes de la publicité, et l’on faisait appel à un spécialiste du tracking quand la mesure demandait de l’attention.

Ce positionnement détermine le travail qui arrive. Les entreprises demandent rarement à FunnelTrack de mettre en place un simple pixel Meta. Elles arrivent avec des problèmes plus difficiles, souvent des problèmes qu’une autre agence a déjà tenté de résoudre.

De petits problèmes qui ne s’arrêtaient jamais

Brandon travaille sur des implémentations server-side depuis 8 à 10 ans, la plupart sur Google Cloud. Google Cloud faisait le travail, mais chaque implémentation était une configuration sur mesure qui demandait une attention continue. Les problèmes étaient petits et variés : des enregistrements DNS côté client disparaissaient et mettaient le sous-domaine hors ligne, les configurations se heurtaient aux limites de Google Cloud Platform, des processus se bloquaient lors de gros backfills vers le data warehouse, et chaque client actif demandait une vérification mensuelle.

Avec une base de clients en croissance, cela est devenu une charge de travail mensuelle fixe dont aucune des deux parties ne voulait. FunnelTrack ne voulait pas gagner sa vie en maintenant de l’infrastructure, et les clients ne voyaient aucune raison de payer pour cela. Pendant ce temps, la demande augmentait. Il y a huit ans, Brandon devait expliquer à quoi servait le server-side tracking ; ces deux dernières années, les entreprises le demandent par son nom.

Comment TAGGRS est arrivé

FunnelTrack travaille avec la stack que le client utilise déjà. L’agence a découvert TAGGRS par un client qui avait créé un compte, n’arrivait pas à terminer la configuration seul et lui a demandé de prendre le relais. Le premier projet s’est assez bien passé pour continuer, pour trois raisons : TAGGRS est une entreprise néerlandaise facile à joindre, le support analysait chaque problème de fond au lieu d’envoyer un lien vers la documentation, et une configuration client en ligne ne demandait ensuite plus de temps actif.

Ce qui était au départ une préférence est désormais la pratique standard. Chaque nouveau client de FunnelTrack passe sur TAGGRS.

Pourquoi l’implémentation prend des semaines

Le server-side tracking prend en charge une grande partie de la mesure d’une entreprise, parfois toute. Brandon qualifie l’implémentation de sujette aux erreurs : une erreur peut casser une mesure qui fonctionnait avant le début du projet. FunnelTrack ne construit donc jamais le server-side par-dessus la configuration existante. Là où une construction empilée prend une journée, la configuration en parallèle prend 2 à 3 semaines ; mais quand une construction empilée tourne mal, toutes les mesures aboutissent au même endroit et la cause est difficile à trouver.

Le rapport de consentement de TAGGRS est celui que l’équipe ouvre le plus. Il montre régulièrement des achats sans consentement enregistré, généralement parce que le consentement est arrivé tard dans la session ou que le visiteur a fermé la bannière. Cette décision est respectée sur le serveur comme dans le navigateur : FunnelTrack utilise donc le rapport pour conseiller ses clients sur une bannière qui amène les visiteurs à choisir plus tôt.

Ce que montre l’exécution en parallèle

Les deux configurations mesurent les mêmes événements au même moment : la différence correspond aux données qui manquaient au client.

L’ampleur de l’écart dépend de l’audience. Les entreprises aux prix plus élevés touchent davantage d’utilisateurs Apple, et c’est Safari qui limite le plus le tracking. L’équilibre entre trafic mobile et desktop joue de la même façon.

Il y a d’autres gains. Avec le server-side comme source principale, le conteneur du navigateur est réduit à l’essentiel, ce qui aide au chargement des pages ; les tags lourds comme le pixel TikTok partent en premier. La logique de marge tourne sur le serveur, si bien qu’aucune donnée de bénéfice n’atteint le front-end. Les ventes qui n’atteignent jamais la page de remerciement, comme les achats dans le navigateur intégré d’Instagram, sont réintégrées à partir des données du back-end. Et certains clients abandonnent des outils dédiés à la mesure du bénéfice et aux conversions hors ligne, économisant des milliers d’euros par mois.

À retenir

• Une hausse de 0 % vous apprend quelque chose. Si le server-side correspond exactement au client-side, quelque chose dans la configuration est généralement cassé. Empiler sur les IDs de conversion existants masque ce problème.
• Plus lent, c’est plus fiable. Deux à trois semaines d’exécution en parallèle coûtent moins cher que le dépannage d’une construction empilée.
• La plupart des pertes de données soudaines viennent du sous-domaine. Un développeur a modifié ou supprimé les enregistrements DNS. FunnelTrack demande à chaque client de ne pas toucher au sous-domaine.
• Annoncez les limites dès le départ. Le consentement refusé et les pages de confirmation qui ne se chargent jamais laissent encore des données non mesurées, même si l’infrastructure facilite leur traitement par la suite.
• La configuration terminée est une fondation. La mesure du bénéfice, les flux du back-end et des datasets que vous pouvez interroger avec l’IA tournent sur la même infrastructure : chacun devient un court projet de suivi.