.svg)
Suite à l’annonce de notre acquisition d’Addingwell en Avril dernier, nous nous sommes entretenus avec Romain Baert, le CEO de l’entreprise, pour explorer l'histoire d'Addingwell, l'importance croissante de l’entreprise et du server-side tracking dans l'écosystème marketing digital, et les raisons stratégiques derrière le rapprochement avec Didomi.
Un échange riche en enseignements sur les défis actuels de la data et la vision future d'une gestion de la donnée plus responsable et performante.
Addingwell : Origines, création et croissance
Question: Pouvez-vous nous parler des origines d'Addingwell et de votre expérience passée qui a mené à cette création ?
Romain Baert: Il y a deux axes principaux qui ont guidé la création d’Addingwell : pourquoi et comment nous avons décidé d'aller vers le server-side, et pourquoi le server-side est important.
Les prémices de l'histoire remontent à l'époque où Julien, François, Jérôme et moi avons travaillé pour une société que j'ai cofondée, Mazeberry. Mazeberry était le leader français de l'attribution marketing, avec pour mission de permettre aux annonceurs de sortir du "last click" dans les analyses d'attribution.
De 2015 jusqu'avant addingwell, nous avons porté ce message pour le retail, expliquant que les achats ne se font pas en un seul clic, mais suivent un parcours. Cependant, les outils d'analyse et les plateformes comme Meta ou TikTok ne montrent souvent que leur propre contribution, ou se basent sur le dernier clic. L'attribution multitouch a été notre travail pendant 7 ans.
Quels étaient les problèmes sous-jacents à ce modèle basé sur les cookies ?
Nous nous sommes rendu compte que tout ce moteur d'attribution était basé sur l'historisation de la donnée via les cookies. Et plus nous allions loin dans l'algorithmie pour affiner les modèles, plus la donnée s'appauvrissait.
Cet appauvrissement est bien connu, notamment avec le RGPD. On ne peut pas manipuler la donnée ou poser un tracker sans consentement. Le marché a cherché d'autres traceurs, mais les autorités de protection des données (DPA) ont précisé que cela concernait tous les trackers, pas seulement les cookies. De plus, il y a des restrictions au niveau des navigateurs : Apple a supprimé les cookies tiers, bloque certains scripts. Les adblockers prennent aussi de plus en plus de place.
Comment cette situation affecte-t-elle les annonceurs ?
Les annonceurs investissent massivement dans des outils d'attribution, comme Mazeberry à l'époque, ou dans des CDP pour la segmentation et le retargeting. Mais sous le tapis, la donnée est en plein appauvrissement. C'est ce constat qui a donné l'idée que le marketing moderne ne peut pas continuer ainsi : on ne peut pas investir autant dans la martech si la data n'est pas fiable.
Et c'est là que le server-side entre en jeu ?
Oui, en parallèle, le marché a commencé à parler de technologies comme le server-side, indiquant que demain, la donnée devra être précise, first-party et gouvernable. Nous avons basé nos recherches sur ces trois mots-clés.
Nous avons réalisé que le monde du client-side (trackers dans le navigateur) allait migrer vers un tracking plus responsable, plus performant, capable de contrer les problèmes liés aux navigateurs, adblockers et à la fin annoncée des cookies tiers.
Addingwell est donc l'inventeur de cette technologie server-side ?
Non, nous ne sommes pas les inventeurs de la techno server-side. C'est un modèle d'échange de données. Les systèmes de gestion de balises (TMS) comme Google Tag Manager se rendent compatibles server-side, demandant aux utilisateurs d'ouvrir leurs propres serveurs.
Nous avons creusé le sujet et vu une rupture technologique : les géants de la tech vont vers le server-side pour lutter contre la fin des cookies tiers et améliorer la gouvernance de la data. Google Tag Manager se dit "server-side ready".
Quel est alors le problème et la mission d'Addingwell ?
Le gros problème est que l'annonceur n'est pas "ready". Il ne sait pas toujours qu'il a des problèmes de data, ne sait pas ce qu'est le server-side, et surtout, il ne peut pas réaliser ce projet en interne facilement, car cela demande des compétences techniques et des ressources IT déjà très sollicitées. Les roadmaps des entreprises sont déjà chargées.
La mission initiale d'Addingwell est donc d'aider le marché à adopter les nouveaux standards du marketing digital, à commencer par le server-side. Il faut migrer rapidement vers ces technologies pour ne pas perdre en vitesse en termes d'attribution, d'investissement marketing ou d'accès aux nouvelles fonctionnalités des plateformes.
Votre vision initiale de l'adoption du server-side a-t-elle été différente de la réalité ?
Oui, au début, nous pensions que le server-side serait un "raz-de-marée" et que les annonceurs en prendraient vite conscience. Nous avons été un peu naïfs car techniquement, c'est trop complexe pour eux, cela demande trop de ressources, et surtout, l'environnement bouge constamment. Les plateformes sortent des API et les changent, les navigateurs modifient leurs règles, les adblockers évoluent. Cette mouvance freine l'adoption : soit on attend malgré la mauvaise qualité des données, soit on ne se lance pas car c'est trop compliqué.
C'est pourquoi Addingwell a voulu simplifier la transition. C’est là l’origine du nom "Addingwell" : ajoutez vos tags en passant en server-side, mais ajoutez-les bien.
Nous nous sommes rendu compte que le premier cas d'usage était simplement la migration. Nous avons donc conçu un outil puissant et simple pour permettre à n'importe quel annonceur, du petit e-commerce au grand groupe international, de déployer son server-side facilement. Le problème est le même pour tous : investir aux bons endroits et avoir le bon retour sur investissement.
Quelle est l'ampleur d'Addingwell aujourd'hui et comment s'est passée sa croissance ?
Addingwell a environ 3 ans et demi d'existence. Nous avons démarré en "garage" et itéré, et aujourd'hui, nous sommes une équipe d'environ 25 personnes avec plus de 1500 clients actifs. Nous avons un réseau de 200 partenaires qui utilisent Addingwell pour leurs clients. Addingwell est un écosystème : il y a le SaaS pour les clients, la communauté que nous animons beaucoup (cas d'usage, templates, documentation), et le réseau de partenaires.
Nous sommes issus du monde des start-up, basés à Euratechnologies à Lille. Nous sommes "bootstraped", financés sur fonds propres, sans levée de fonds. Notre modèle de licence nous a permis de financer une croissance assez folle, triplant quasiment chaque année. Nous gagnons entre 70 et plus de 100 nouveaux clients par mois.
Découvrir le server-side tagging et son essor
Quels types d'annonceurs adoptent le server-side via Addingwell ?
Au début, cela a démarré avec l'e-commerce et le retail, là où l'on dépense beaucoup en marketing et où l'on est très axé sur le ROI. Mais aujourd'hui, les acteurs des médias, du travel, de la banque, de l'assurance, du B2B ont les mêmes besoins.
Tous ceux qui dépense en marketing publicitaire ont besoin d'un bon retour sur investissement. Il n'y a pas de minimum d'investissement ; même un petit annonceur gagne à utiliser Addingwell plutôt que de dépenser sans une bonne donnée.
Le server-side semble avoir eu besoin d'une phase d'évangélisation. Comment cela s'est-il déroulé ?
La première année a effectivement été une phase d'évangélisation. Il fallait expliquer ce qu’était le server-side, que les cookies vont disparaître, et qu'on pouvait gagner 15 à 20% d'optimisation du ROAS (Return on Ad Spend). Les gens étaient convaincus, mais hésitaient à être les premiers.
Heureusement, nous n'étions pas seuls sur ce chemin.
Des acteurs comme Meta ont pris la parole pour annoncer qu'Apple avait coupé les cookies tiers, que leurs performances s'étaient dégradées, et qu'il fallait pousser les annonceurs vers le server-side. Meta a sorti une API compatible avec Google Tag Manager et donc addingwell. Les annonceurs, en discutant avec leur account manager Meta, étaient incités à mettre en place la CAPI (Conversions API). Pour cela, il faut être en server-side. Addingwell a été l'un des premiers acteurs à proposer une solution pour migrer rapidement.
Nous avons même fait un AB test de performance en collaboration avec Meta pour le groupe Rocher (Yves Rocher), dont nous avons publié les résultats et un témoignage. Cela a créé un cas d'usage précis et poussé l'adoption.
Il y a eu un autre phénomène majeur lié à la gouvernance des données, n'est-ce pas ?
Oui, un deuxième phénomène, plus proche de Didomi, a permis de démocratiser l'usage : la gouvernance. Pendant plusieurs mois, Google Analytics a été jugé illégal en Europe à cause de la directive Schrems et des transferts de données personnelles vers les États-Unis. La CNIL et d'autres DPA européennes ont statué que l'utilisation de GA4 n'était pas possible telle quelle.
Le seul moyen possible était de brancher Google Analytics en server-side. Pourquoi ? Parce que votre serveur peut anonymiser les données personnelles avant de les envoyer aux États-Unis.
Cela a créé un nouveau cas d'usage de gouvernance via le server-side. Nous avions pressenti que le server-side augmenterait la gouvernance de la data, car c'est le seul moment où un annonceur voit ses données avant qu'elles n'arrivent dans un outil.
En quoi le server-side améliore-t-il la gouvernance par rapport aux méthodes traditionnelles ?
Avant le server-side, avec une CMP, l'annonceur est responsable de traitement, obtient le consentement, puis dit à ses partenaires "vous avez le consentement, vous pouvez y aller". Il ouvre la porte, les partenaires exécutent du code sur son site sans qu'il ait de visibilité ou de maîtrise sur ce qui est exactement collecté ou envoyé.
Le server-side change cela. L'internaute dit oui, l'annonceur collecte lui-même la donnée selon les règles du consentement, puis c'est lui qui envoie la donnée à Meta, Google Ads, Piano ou Google Analytics. Il ne permet plus à ces acteurs d'exécuter du code sans son contrôle. Nécessairement, il augmente sa gouvernance. Un DPO voit le server-side comme une super arme pour la gouvernance des données. Si on lui demande quelles données sont collectées et à qui elles sont envoyées, il peut le voir sur son serveur, modifier, anonymiser, couper l'envoi.
L’acquisition d’Addingwell par Didomi et la vision pour la suite
Quelle a été la logique derrière l'acquisition d'Addingwell par Didomi ?
Il y a deux perspectives : pourquoi Addingwell a choisi Didomi, et pourquoi Didomi était intéressé par Addingwell.
Vu de notre fenêtre chez Addingwell, qui était bootstraped et en forte croissance, on pourrait se demander pourquoi rejoindre Didomi. Addingwell n'était pas une société à vendre.
Le sujet majeur pour Addingwell est l'international. Nous sommes pionniers et leaders en France. Pour continuer à grossir, il faut aller à l'international. Cela implique des changements et des risques sur des sujets où nous ne sommes pas experts. Beaucoup d'entrepreneurs ne sont pas suffisamment accompagnés ou ne vont pas assez vite à l'international. Le problème server-side est mondial. Si nous y allons seuls, pays par pays, nous prenons le risque de ne pas aller assez vite. Le marché n'attend pas.
Didomi, en revanche, est déjà international. Plus de 50% de leur chiffre d'affaires est fait à l'international. Ils sont présents au Canada, États-Unis, Espagne, Pays-Bas, etc.. Ils peuvent distribuer facilement le produit Addingwell car c'est cohérent avec leurs clients et leur marque. De plus, Didomi a une philosophie très similaire à la nôtre : faire du premium, de la qualité.
Pour nous, c'est une opportunité d'aller plus vite à l'international et de réduire les risques liés à ce sujet. Nous avons trouvé un partenaire qui nous ressemble et est très motivé. Cela nous a incités à ouvrir nos oreilles et à discuter.
Quelle est la vision de l'avenir pour les produits Didomi et Addingwell ensemble ?
La perception du marché post-annonce a été très positive. Des centaines de messages de félicitations, disant que cela fait sens. L'acquisition d'un leader du server-side premium par un leader premium de la CMP est logique. C'est très horizontal : toute collecte de données commence par le consentement, et toute exécution de la donnée passe par le server-side.
Dans cette chaîne, on a besoin du consentement, d'un bon monitoring de la data, d'une bonne exécution côté serveur, et demain d'une bonne analyse, exécution, segmentation. Il y a un projet soutenu par l'investisseur Marlin pour des concentrations de technologie afin d'apporter des solutions plus fortes dans une croissance horizontale.
Quels sont les bénéfices concrets et à court terme pour les clients ?
À court terme, c'est l'intégration des équipes. Les annonceurs auront des interlocuteurs experts sur ces deux sujets sans avoir à interagir avec deux sociétés. C'est une vraie opportunité pour les clients de pouvoir traiter ces sujets ensemble.
Dans l'implémentation server-side, nous avons toujours un DPO impliqué. Avec l'offre server-side de Didomi, les clients ont la garantie que c'est légal, compatible avec leur politique de consentement et lié à leur CMP.
Et à plus long terme, quelles synergies technologiques sont prévues ?
L'un des premier jalons à développer suite à cette alliance technologique visera tout ce qui peut améliorer la puissance de la CMP Didomi. Nous savons que la technologie server-side peut bénéficier énormément à la CMP, et nous souhaitons que cette puissance soit rendu accessible aux clients Didomi.
La CMP, comme d'autres outils, est affectée par la disparition des cookies, les ad blockers, et l'impact sur la web performance. Une CMP qui se charge via un script JavaScript a forcément un impact sur la performance, réagit négativement à certains ad blockers, et a du mal à garder l'identité dans le temps avec la disparition des cookies first-party sur certains navigateurs.
La technologie server-side peut renfoncer la CMP Didomi à tous ces niveaux :
- Une CMP qui se charge plus vite (moins d'impact sur la web perf).
- Une CMP résiliente aux ad blockers, augmentant le taux d'affichage du bandeau de consentement. Aujourd'hui, 10 à 15% des personnes équipées d'ad blockers ne voient pas la bannière de consentement, ne peuvent pas faire de choix, et cela représente de la donnée perdue. Le server-side permet de récupérer cette donnée.
- Une meilleure analyse des données de consentement en conservant l'identité et le choix de préférence.
Ces cas d'usage et intégrations sont prévus prochainement.
Saga de la fin des cookies tiers dans Chrome : Quel impact pour le server-side ?
Parlons de l'actualité. Google a récemment annoncé repousser à nouveau la fin des cookies tiers dans Chrome. Quelle est votre réaction ou analyse ?
Effectivement, l'annonce a eu lieu le jour où nous avons annoncé l'acquisition.
La première chose à garder en tête, c'est que Google ne décide pas pour les autres navigateurs : Depuis 2020, il n'y a plus de cookies tiers sur Apple (iOS), Edge, Brave, et Firefox. Google de son côté a tardé du fait de ses intérêts publicitaires, et par rapport aux difficultés légales posées par sa position dominante sur le marché.
L'entreprise a lancé des initiatives comme The Privacy Sandbox, pour montrer aux acteurs de la publicité ce qu'ils pourraient faire demain, mais pour l'instant, ces solutions n'on pas encore observé d'adoption suffisante.
De plus, Chrome est actuellement sous le coup d'une procédure de démantèlement aux États-Unis au terme de laquelle Google redéfinira probablement sa roadmap. En effet, toute décision court terme qui pourrait renforcer une éventuelle position dominante est probablement très périlleuse.
L'annonce de Google est donc à mon avis très politisée et liée à l'actualité.
Mais l'annonce de Google signifie-t-elle qu'il faut ralentir l'adoption du server-side ?
Absolument pas. Chrome est un gros acteur, mais sa part d'audience varie selon les secteurs (plus faible dans le luxe ou le travel par exemple, qui favorise iOS/Safari). Chaque annonceur peut regarder sa part d'audience hors Chrome dans son Analytics.
Le server-side, même sans la suppression des cookies tiers sur Chrome, sert quand même pour les 50% d'audience (ou plus) qui ne sont pas sur Chrome. Aujourd'hui, le server-side permet déjà 20% d'optimisation du ROAS avec les cookies tiers existants chez Chrome. C'est monumental.
Enfin, améliorer la web performance via le server-side sert aussi chez Chrome, car cela améliore les Web Vitals et donc le SEO, qui est un enjeu majeur pour les annonceurs.
L'épisode de Google Chrome est donc une pause politisée, mais il faut continuer à se préparer et se dire qu'on peut avoir un marketing personnalisé et mieux attribué pour au moins 50% de sa population qui n'est pas sur Chrome. C'est reculer pour mieux sauter.
—
Pour en apprendre plus, visitez le site d’Addingwell et suivez Romain sur LinkedIn.
.avif.avif){kind=tracking}
