Privacy Sandbox : ces API qui vont rendre la vie des éditeurs impossible
Un des principes centraux consacrés par la Privacy Sandbox est l'impossibilité à terme pour des sites différents de capter la donnée les uns des autres lorsqu'ils seront en relation. Ce principe sera assuré par l'API fenced frames, une des très nombreuses API de la Privacy Sandbox, la technologie que Google présente au marché comme étant la solution pour renforcer le respect de la vie privée sur Chrome, et qui viendra notamment remplacer de nombreux cas d'usage aujourd'hui assurés par les cookies tiers, voués à disparaître. Ces fenced frames viendront en pratique remplacer les iframes et empêcher le partage de données entre le site qui intègre le contenu (la météo, une carte, une publicité, etc.) et le site externe, qui le fournit : seule sera autorisée la personnalisation de l'expérience sur place à l'instant T.
Soit. Mais qu'est-il prévu pour répondre aux nombreux besoins des éditeurs de faire circuler de la donnée entre différents domaines ou partenaires, ne serait-ce que pour optimiser l'expérience utilisateur ? Deux API sont prévues pour cela : first-party sets et CHIPS. First-party sets permet à chaque groupe propriétaire de différents domaines et sous-domaines offrant des services et contenus pouvant être en relation entre eux d'autoriser le partage, entre ses sites, d'informations stockées dans des cookies concernant des audiences consentantes naviguant dans ces différents domaines. Ce cas d'usage est d'autant plus stratégique qu'à terme le seul outil permettant le partage sur Chrome d'informations entre différents sites quels qu'ils soient, le cookie tiers, ne sera plus disponible à partir de l'été 2024.
Un site d'une marque automobile dédié aux tests de voitures et son autre site dédié aux devis ont tout intérêt à partager les informations concernant un même utilisateur, ne serait-ce que pour fluidifier l'expérience de ce dernier. Même chose entre le site de contenus d'un éditeur média et le site de la même marque dédié aux paiements des abonnements. Cela peut également concerner des sites de différentes marques d'un même groupe (uber.com, ubereats.com ou office.com, live.com, microsoft.com) ainsi que des sites d'une même marque dans différents pays. Les exemples sont nombreux. "Cette API peut également répondre aux besoins d'une régie interne au groupe assurant la monétisation de plusieurs sites. Elle n'autorise en revanche pas le partage de données entre sites appartenant à des groupes différents même si ces derniers sont liés par des partenariats visant le partage d'informations, comme le cas des régies externes", précise Anh-Tuan Gai, cofondateur et CEO d'Adagio.
L'exception à cette règle d'impossibilité du partage entre sites de groupes différents est cependant en partie couverte par l'API CHIPS. Celle-ci permet le partage de cookies pour certains sites externes intégrés dans une page web (un chat, un player, la météo, etc.) afin que ces derniers puissent récupérer les données relatives aux utilisateurs de la page nécessaires à personnaliser leur expérience sur place et uniquement dans ce cas. Ces sites externes ne pourront cependant pas s'accaparer ces données pour d'autres usages, quels qu'ils soient.
Les shared storage pour la mesure du capping et du reach. Vraiment ?
L'API shared storage suit quant à elle le même principe d'autoriser le partage de données entre différents sites mais dans le 'local storage' de la page, où l'on peut intégrer beaucoup plus d'informations que sur un cookie. "C'est une sorte de mini clean room qui permettra de partager des informations entre des sites qui ne sont pas liés", explique Grégoire Gaffié, directeur de la monétisation de Reworld Media.
Comme expliqué par Google lui-même, cette API vient répondre à différents besoins (modules de paiement, cybersécurité mais également ceux de l'industrie publicitaire à de fins de définition de capping de la fréquence d'exposition de la publicité à un même utilisateur) et de mesure du reach. "Dans le shared storage vous pouvez partager des instructions, des scripts de code, pour que ce soit exécuté. On pourra par exemple indiquer que telle publicité ne doit pas être diffusée à un utilisateur qui l'a déjà vu sur un autre site. Le navigateur adaptera l'affichage en fonction", précise Hugo Moreau. "Cette API sera très utile pour la publicité, notamment pour des AB tests et le capping. Elle offrira un espace partagé cross site accessible dans des conditions très précises : ma publicité pourra ne s'afficher que pour certains types d'utilisateurs sans pour autant que je puisse accéder à leurs données", commente le responsable produit d'une très importante adtech mondiale buy side.
En pratique cependant, certains de nos analystes y voient une solution très complexe à industrialiser pour des résultats médiocres. "L'éditeur sera obligé d'injecter ces différentes règles sur le navigateur pour chacun de ses acheteurs, c'est ingérable", analyse Hugo Moreau. "Sans compter que cela alourdira les pages et aura pour effet de baisser les recettes publicitaires de l'éditeur", complète Anh-Tuan Gai. "Cela va rendre très complexe l'intégration de services qui aujourd'hui sont hyper simples à embarquer : je ne suis pas sûr que beaucoup d'éditeurs du marché soient en capacité de tout gérer en interne", analyse Grégoire Gaffié.
Au final et pour résumer : "Toutes ces API exigent beaucoup d'efforts de compréhension, d'investissements en temps et en ressources humaines que le marché n'est pas en mesure d'assumer. Non seulement personne n'y est prêt (il n'y pas grand monde qui teste toutes ces API) et peu de spécialistes croient encore au calendrier fixé par Google", déclare le responsable produit d'une très importante adtech mondiale parmi les seules actives dans les tests de Fledge. Si toutefois Google maintenait son calendrier, toutes ces API seront disponibles pour un usage généralisé dès le troisième trimestre de cette année. La fin du recours aux cookies tiers sur Chrome est quant à elle est toujours prévue pour le deuxième semestre 2024.