Pourquoi éditeurs et adtech ne s'intéressent pas aux API de la Privacy Sandbox ?
Parmi les différentes briques de la Privacy Sandbox (la techno de Google pour Chrome qui remplacera de nombreux cas d'usage des cookies tiers voués à disparaître), il y en a une qui est stratégique pour les éditeurs mais dont personne ne parle : le volet composé de cinq API pour "renforcer la sécurité et la garantie du respect de la vie privée des utilisateurs inter-sites", ce que Google nomme dans son jargon "cross-site privacy boundaries", soit le cœur du réacteur pour les éditeurs.
Le JDN a sollicité une quinzaine d'experts chez de grands médias, publishers, régies et adtech sell side et buy side… Seule une petite poignée d'entre eux s'est déclarée à même de commenter ces innovations, certains souhaitant rester anonymes. A quelques mois à peine de la mise à disposition du marché de ces outils pour un usage généralisé (bien que non obligatoire), la plupart de nos interlocuteurs avouait ne s'y être pas penché. Pourquoi un tel désintérêt ?
"Il s'agit de questions extrêmement techniques et complexes"
"Toutes ces API sont testées sur des portions très faibles d'inventaires, dans des modes de test des navigateurs. Pour le moment, les groupes de travail auxquels nous avons participé se sont uniquement focalisés sur Topics (Topics est, avec Fledge, l'API la plus connue de la Privacy Sandbox, dédiée pour sa part au ciblage d'audiences, ndlr.)", commente un responsable d'une régie d'un grand groupe média français. "Je pense que ce sujet intéresse beaucoup les publishers, mais il s'agit de questions extrêmement techniques et complexes que peu d'entre eux peuvent comprendre en profondeur", commente le responsable d'une technologie française d'optimisation publicitaire au service des publishers.
"La documentation sur ces API est abondante mais très technique, elle est conçue pour les ingénieurs. On ne trouve pas de présentation claire et complète sur les use cases pour les publishers et les marketeurs", confirme un ingénieur d'une importante adtech parmi les rares actives dans les tests de la Privacy Sandbox. Et il ajoute : "N'oublions pas que l'API au cœur de la garantie de la privacy pour les utilisateurs – fenced frames – ne deviendra vraiment obligatoire qu'à partir de 2026. Pourquoi ce délai alors que les cookies tiers eux seront supprimés en 2024 ?", s'interroge-t-il ? Un calendrier donc confus, qui vient s'ajouter à de nombreux et complexes changements techniques qui peuvent sans doute expliquer l'attitude désabusée de l'industrie.
Tâchons alors de comprendre. Ces cinq API – first-party sets, shared storage, CHIPS, fenced frames et federated credential management – ont pour but d'offrir des moyens de contrôle de l'information qui peut être partagée entre différents sites qui interagissent entre eux quand l'utilisateur navigue sur Chrome. Le principe de base, assuré par fenced frames, est de rendre ce partage de données impossible par défaut, et ce selon Google afin d'éviter tout risque de tracking ainsi que de sécuriser un maximum les données des utilisateurs. Pour pallier cependant à certains besoins et cas d'usage, les API telles que first-party sets, CHIPS ou shared storage autorisent certains partages des données on site de manière très cadrée.
"D'un point de vue opérationnel ce sera très compliqué à mettre en place"
"Du point de vue de la privacy, ces API sont solides et représentent une vraie avancée pour les utilisateurs", commente Hugo Moreau, directeur produit chez Adagio. "Pour les éditeurs, l'autre point fort de ces API est leur capacité à prévenir tout risque de fuite de données", ajoute Anh-Tuan Gai, cofondateur et CEO du SSP. De l'avis de la majorité de nos interlocuteurs, nul doute en effet que, contrairement aux autres navigateurs ayant supprimé les cookies tiers, Google cherche à proposer des solutions alternatives pour permettre de continuer de répondre à tous les cas d'usage et besoins business des éditeurs et des marques, y compris en matière de qualité de l'expérience de l'utilisateur.
La difficulté en revanche est la complexité à les mettre en place : "Tout cela est très beau sur le papier, mais d'un point de vue opérationnel ce sera très compliqué à installer pour une majorité d'éditeurs", préviennent ces experts. "Nous sommes sur un outil beaucoup plus complexe qui impliquera d'intégrer de nombreuses couches techniques supplémentaires pour chaque domaine. C'est très différent de ce qui se passe aujourd'hui : une régie ou un groupe média possédant différents domaines est considéré comme un tout et les choses se font beaucoup plus simplement", résume Grégoire Gaffié, directeur de la monétisation de Reworld Media.
"Quand le petit ou moyen éditeur verra la masse de travail que cela représentera de gérer tous ces paramètres , il baissera les bras"
Et ce n'est que la partie visible de l'iceberg, alertent certains de nos interlocuteurs, car en réalité, en rendant le partage des informations par défaut impossible et ses exceptions complexes à mettre en place entre le site de l'éditeur et des outils externes – comme les plateformes publicitaires de l'open web –, Google renforcera indirectement sa position dominante dans l'adtech, au détriment des autres plateformes. "Quand le petit ou moyen éditeur verra la masse de travail que cela représentera pour lui de gérer tous ces paramètres pour intégrer d'autres partenaires que Google (des SSP sur le header bidding par exemple), il baissera les bras, et laissera Google s'occuper de tout", déclare Anh-Tuan Gai.
Prenons un autre exemple : l'API federated credential management de la Privacy Sandbox, qui couvre le cas d'usage spécifique du partage d'identifiants de connexion entre un service et un site, comme cela se fait aujourd'hui avec le Facebook Connect par exemple. "Aujourd'hui ces mécanismes utilisent les cookies tiers et des redirections, qui représentent autant de failles de sécurité. Le but demain avec cette nouvelle API est de conserver cette facilité de connexion pour l'ensemble des utilisateurs sur tous les sites mais en s'appuyant sur Chrome", explique Hugo Moreau, en précisant par ailleurs que ce type d'outil pourra à terme inspirer les autres navigateurs, tels que Safari et Firefox.
Tout semble simple, fonctionnel et de plus conforme à la privacy. Où est donc le problème pour l'éditeur ? "Google dispose de 4 milliards de logins déjà et avec ces nouvelles API toute l'intelligence server side sera de son côté soit autant d'identifiants permettant de qualifier ces audiences et de maîtriser le capping. Il va de soi que dans ces conditions, les acheteurs en quête d'efficacité devront en toute logique passer par les outils publicitaires de Google", explique Anh-Tuan Gai. Le petit ou moyen éditeur ne sera-t-il pas tenté lui aussi de laisser Google gérer ses uses cases et notamment sa monétisation au lieu de se battre pour développer sa data first ou ses utilisateurs logués ? "Sans disposer d'autres sources de revenus que Google, l'éditeur ne pourra jamais le challenger ne serait-ce que sur les prix", conclut Anh-Tuan Gai. Sans compter qu'à moyen terme, c'est tout un marché qui risque de disparaître et avec lui la capacité à challenger les acteurs dominants.
Du côté des régies
Quid des régies ? Du moins pour ce qui est du ciblage des audiences et la maîtrise du capping, elles n'ont en réalité pas besoin de la Privacy Sandbox pour continuer d'opérer la monétisation de leurs inventaires. Il suffit de disposer de l'envergure et du savoir-faire nécessaires pour se brancher directement à Google Ad Manager (GAM), le SSP et ad exchange de Google : "Google Ad Manager est tellement efficace pour le cookieless que je n'ai même pas besoin de m'intéresser à la Privacy Sandbox", déclare Paul Ripart, directeur commercial programmatique et data chez Prisma Media. "GAM m'offre tout ce dont j'ai besoin – Publisher provided signals, PPID, secured signals, etc. – pour permettre à mes acheteurs de cibler efficacement et de manière granulaire mes inventaires cookieless dans un environnement programmatique lui-même dominé par Google." Des solutions qui, de surcroît, autorisent la transmission d'ID universels, des cookies 1st party, des segments contextuels (taxonomie IAB) et même des cookies 1st party en cross domaine. GAM ne répond cependant pas encore aux besoins du reciblage et de la mesure de l'efficacité.