La fin des cookies tiers vous inquiète ? Pas de problème, voici le tracking server-side

Par Xuoan D. le 23/01/2024

Temps de lecture : 8 min

L'interview de Romain Baert, CEO d'Addingwell.

Annoncée de longue date, la cookiepocalypse a officiellement été enclenchée par Google Chrome en ce mois de janvier 2024. Sur le banc des accusés, le ciblage publicitaire reposant sur une multitude de sources, échangeant des données entre sites via les cookies, ces petits fichiers présents dans les navigateurs des internautes. 

Les big-tech – Apple puis Google – à l’initiative de ce grand chambardement auront toujours suffisamment de datas sur l’audience pour que leurs activités ne soient pas menacées. Mais le risque est plus grand pour l’open web, les éditeurs indépendants, et leurs partenaires ad tech. Comment maintenir un niveau suffisant d’identification des internautes et de leurs parcours pour piloter au mieux la performance publicitaire des campagnes en ligne ? 

En apparence, la langueur du marché face à ce péril a pu surprendre. Mais les alternatives ne manquent pas. C’est le cas du server-side. Cette approche permet l’échange de données entre plateformes côté serveur, et non plus dans le navigateur de l’internaute. Les cookies sont toujours dans la danse, mais en first et non plus en third party, ce qui semble imparable. Il suffisait d’y penser ! Ce contournement, aussi évident que précis techniquement, nécessite d’opter pour les bons partenaires. 

Pour y voir plus clair, la Réclame .mark&tech donne aujourd’hui la parole à Romain Baert, CEO de la solution Addingwell, une infrastructure server-side pour Google Tag Manager. 

Qu’est-ce qui vous a mené vers le sujet du server-side ? 

Romain Baert : J’ai toujours travaillé dans l’univers du digital et des technologies à destination des marketers. L’une de mes précédentes histoires entrepreneuriales, c’était un outil d’attribution multi-touches. L’objectif était de répartir le poids du chiffre d’affaires sur les supports médias en se disant qu’un internaute n’achète pas en une seule visite. On a besoin d’historiser son parcours de navigation. C’était un sujet qui était très algorithmique et consommateur de datas. 

Ensuite, le marché s’est retrouvé dans une configuration un peu bizarre. D’un côté, on va de plus en plus loin en matière d’algorithmie pour modéliser les parcours clients. Et de l’autre, on voit le marché qui limite la collecte de la donnée via les cookies tiers : le RGPD, les adblockers, Safari et bien sûr Chrome depuis quelques jours.

Ainsi, le monde publicitaire sait depuis quelques années que le cookie tiers a une obsolescence programmée. Pourtant, personne ne s’est réellement intéressé à ce sujet-là, parce qu’on a bien compris que c’était compliqué, que celui qui allait soulever le tapis allait devoir investiguer beaucoup en termes de tech. 

Concrètement, comment fonctionne le server-side par rapport à ce qu’on connaît de la pose de cookie tiers ?

R.B. : Le premier point à démystifier est qu’on utilise toujours des cookies avec le server-side. La grande différence est située entre cookies first party et cookies third party. 

Aujourd’hui, quand on dit que Google Chrome stoppe les cookies sur son navigateur, cela ne concerne que les cookies tiers. Le marché n’est pas cookieless. Car si on supprime les cookies totalement, la navigation du web sera déradée, l’enregistrement des paniers e-commerce d’une visite à l’autre ne se fera plus par exemple, etc. La période marque donc la fin des cookies tiers publicitaires uniquement. Historiquement, ce monde-là a été client-side, c’est-à-dire côté navigateur de l’internaute. 

Pour comprendre comment fonctionne le server-side, intéressons-nous justement au client-side. Si je travaille avec une régie média comme Meta par exemple, comment vais-je échanger des données entre mon site web et Facebook ? Meta me fournit un pixel, un tag, et je vais l’installer sur mon site web. Ce tag est hébergé par Facebook, donc c’est facebook.com qui, via mon site, va déposer un cookie dans le navigateur de l’internaute. Ce cookie va historiser le parcours de l’internaute, ce qui permet derrière de faire la publicité ciblée et du retargeting. 

Or, il y a quelques années, Apple et Firefox, ont considéré qu’il n’était pas de leur responsabilité en tant qu’éditeurs de navigateurs de fournir des datas à des tiers. Si un cookie est déposé, il doit l’être par le nom de domaine du site web visité, et non par un tiers. Ajoutez à cela les adblockers qui eux aussi jouent un rôle dans le blocage des cookies tiers.

Ensuite, il y a un enjeu de web performance. Plus je travaille avec des régies médias, plus j’ai de tags client-side, moins mon site est rapide. Moins mon site est rapide, moins j’ai de conversions, et moins mon SEO est bon. Si j’ai 15 partenaires, j’ai 15 tags et donc 15 tiers qui viennent déposer un cookie. 

Et c’est là qu’intervient le server-side. Mes partenaires régies médias ont besoin de la donnée. Je ne peux plus leur fournir au travers du navigateur, mais cela reste faisable côté serveur. On a une plateforme intermédiaire qui, avec un cookie first party, va récupérer les données du navigateur, et depuis le serveur, va administrer les échanges avec les différents partenaires médias de l’annonceur. Meta, Google Ads, Pinterest, TikTok, Google Analytics… toutes ces plateformes peuvent alors recevoir de la donnée.

L’autre avantage, c’est qu’avec la migration server-side, on optimise aussi la performance web, avec un seul tag et autant de cookie.

Cette approche s’affranchit des « lois » d’Apple, de Chrome, de Firefox ou des adblockers, car il n’est ni possible ni souhaitable pour les internautes de bloquer les cookies first party. Cela n’empêche pas le cadre réglementaire du RGPD. Je ne collecte pas de la donnée non consentie sur mon serveur afin de masquer des traitements de données personnelles que je n’aurais pas le droit de faire. C’est via le consentement que l’internaute décide ou non si les échanges de données, server-to-server, se font entre mon serveur et les régies.

Votre solution, Addingwell, ne fonctionne qu’avec GTM, Google Tag Manager. Pourquoi ce choix ?

R.B. : Nous avons conçu une plateforme server-side et compatible Google Tag Manager. La première raison est que c’est l’outil le plus utilisé au monde. Si 98 % des sites de la planète utilisent GTM, notre technologie est immédiatement compatible avec 98 % du marché. 

Ensuite, quand on parle d’un sujet server-side, on emploie presque tous les mots qui font peur à un annonceur : serveur, technologie, migration… Mais en se basant sur GTM, on est capable de faire une plateforme server-side qui s’installe en quelques clics pour un client qui a GA4 et GTM. Sans l’IT, sans DevOps et sans complexité technique.

Enfin, GTM gère lui aussi le server-side. Si bien que toutes les technologies publicitaires et d’analytics du marché se doivent d’être compatibles avec la version server-side de Google Tag Manager. Meta, TikTok, Pinterest, Adobe, Piano, Matomo… ils savent tous travailler avec GTM server-side.

Puisque GTM existe en server-side, est-ce un concurrent de votre solution ?

R.B. : Pour faire tourner du server-side, il y a besoin de deux choses : d’une infrastructure serveur pour réceptionner la donnée et l’envoyer au partenaire. Le gestionnaire de balises va exécuter des tags sur le serveur. Ensuite, c’est aux annonceurs de choisir où héberger cette solution. Quand vous ouvrez un compte GTM, vous ouvrez un conteneur serveur, et c’est gratuit. La seule chose qui vous est demandée derrière par Google, c’est où sont vos serveurs ? Il y a deux possibilités.

La première est que vous créez un ou des serveurs avec Google Cloud Platform et votre carte bancaire, en votre âme et conscience. Cela veut dire que si votre serveur s’éteint, il faut que vous soyez prêts à le redémarrer, à le monitorer. Quel traffic manager, web analyst ou même DSI a envie de prendre ce risque en cas de fort trafic, notamment pendant les soldes ? Tout le système de tagging et donc la stratégie publicitaire peuvent être obsolètes en cas de panne serveur.

La seconde est que vous choisissez un hébergeur du marché. Et c’est ce que nous sommes, pour cet usage bien précis. Nous proposons une infrastructure automatique provisionnée pour GTM server-side.

Quelle est l’étape d’après pour Addingwell ?

R.B. : L’étape en cours, c’est d’abord la croissance. La société a deux ans et plus de 500 clients nous font confiance. Or ces 500 clients viennent principalement de partenaires. Des agences, consultants et freelances accompagnent leurs clients dans une migration server-side. Ils recommandent alors d’opter pour Addingwell. « Ne vous embêtez pas avec les serveurs, Adingwell a une plateforme avec tous les outils de monitoring et de suivi, je vous propose de les installer pour vous. » 30 à 40 nouveaux clients rejoignent Addingwell chaque mois depuis un an. L’enjeu est de maintenir cette croissance.

Le deuxième point est un sujet de R&D. Le server-side, c’est un monde jeune, qui bouge beaucoup. Tous les 6 mois, il se passe quelque chose. Chrome vient de commencer à bloquer les cookies tiers pour 1% des utilisateurs. Mais que se passera-t-il pour le marché à la fin du semestre quand les 99 % restants . En 2023, Google Analytics a arrêté Universal Analytics au profit de GA4. Safari 16.4 a émis des conditions spécifiques à la dépose de cookies côté serveur. Les adblockers mettent à jour leurs règles de blocage également. L’enjeu est de maintenir notre promesse : avec Addingwell, on va garantir la collecte de données post-cookie avec les meilleures techniques pour pouvoir le faire.

Ensuite, l’autre enjeu est de démultiplier les cas d’usage. Le premier souhait des annonceurs est de mettre fin aux cookies tiers pour réhausser leur niveau de qualité de collecte de données et augmenter leur ROI côté média. Une fois qu’ils ont fait ça, certains clients matures vont plus loin. L’annonceur a des informations qui ne sont pas présentes sur son site Internet, mais qui pourraient servir pour de meilleures publicités sur Google Ads notamment. Ocommence à avoir des clients qui servent du server-side pour enrichir à la volée la donnée, avec par exemple le montant de la marge de chaque produit. 

Pourquoi envoyer la marge aux plateformes médias ? Imaginez deux conversions sur un e-commerce. Il y en a une à 500 € et l’autre à 1 000 €. Sauf que sur celle à 500 €, je fais 300 € de marge. Et sur celle à 1 000 €, je ne fais que 100 € de marge parce que c’était un produit soldé. Quand j’envoie ces deux mêmes informations sans la marge, Google Ads considère que la conversion de 1000 € est meilleure que celle de 500 € alors que pour l’annonceur, ce n’est pas du tout le cas. En apportant plus de données de contexte à Google Ads, on permet aux algorithmes de Performance Max d’être encore plus performants. 

C’est tout ?

R.B. : Et non ! 2024 va être une année de migration massive et urgente. En fait, il est déjà un peu trop tard. Tout le monde parle de la fin des cookies tiers de Chrome, mais cela fait plus deux ans qu’il n’y a plus de cookies tiers sur Safari [sur iPhone, iPad et Mac, NDLR]. Le server-side avait un côté ROIste jusqu’alors. Il va devenir obligatoire en 2024 car on ne pourra plus faire de publicité en ligne sans server-side.

News Scan Book

1

2

3

4

5

Précédent Suivant