« Pensée axée sur les données» est écrit par des membres de la communauté des médias et contient de nouvelles idées sur la révolution numérique dans les médias.
La chronique d’aujourd’hui est rédigée par Ruben Schreurs, chef de produit du groupe chez Ebiquity.
Tous à bord du train en marche « Topics API sucks » !
Depuis le article de blog par Vinay Goel, directeur produit pour Privacy Sandbox, annonce L’API des sujets de Google proposition a été mise en ligne la semaine dernière, mes chaînes se sont senties comme une chambre d’écho à l’échelle de l’industrie remplie de dénigrement de Google.
Je comprends que les gens soient contrariés par les révélations récentes et les preuves dans procès contre Google. Mais j’ai le sentiment que les émotions accrues sur ces autres questions ont un impact sur une évaluation et un examen pragmatiques de ce problème spécifique notion de sujets.
Je suis relativement en retard à la fête, car j’ai passé plusieurs jours à lire la documentation, à écouter le débat qui se déroule autour du concept et à contempler les avantages et les inconvénients – et même maintenant, je me sens à l’aise de ne partager qu’une opinion provisoire sur son mérite. Ce n’est pas aussi simple que certains le font croire, car de nombreuses questions clés restent sans réponse, mais rien ne va plus :
J’aime bien l’API Topics concept.
Voilà, je l’ai dit.
Il est important d’insister sur le mot « concept », car c’est à peu près ce qu’il est encore à ce stade. Google s’engage activement avec toute personne qui a une opinion pour essayer de répondre questions ouvertes et l’aider à prendre une décision sur les principales fonctionnalités et limitations de l’API, telles que :
- Les sites doivent-ils pouvoir définir leurs sujets, ou les sujets doivent-ils être déterminés par le navigateur ou une entité tierce ?
- Que doit-il se passer si un site n’est pas d’accord avec les sujets qui lui sont assignés par le navigateur ?
- Quelle taxonomie thématique doit être utilisée ? Qui doit le créer et le maintenir ?
- Quelle norme pourrait être utilisée pour déterminer quels sujets sont sensibles ?
Pourquoi est-ce important? Parce que Google a reconnu les failles de FLoC et essaie de façonner un utilitaire qui permet toujours une certaine forme de publicité basée sur les intérêts, mais sans les problèmes de confidentialité et une myriade d’autres problèmes liés à l’utilisation (et à la mauvaise utilisation) des cookies tiers.
L’API Topics n’est pas finalisée et tout est susceptible de changer à mesure que Google intègre les commentaires de l’écosystème et les itère. Là où beaucoup semblent ignorer ce processus de collecte de commentaires comme une façade, je suis prêt à donner à Google le bénéfice du doute et à prévoir d’allouer des ressources pour contribuer aux décisions qui doivent être prises.
La route va être longue. Mais décomposons le concept de l’API Topics tel qu’il se présente actuellement.
L’API Topics vise à fournir un utilitaire de ciblage basé sur les intérêts à tous les « appelants » sur une page Web. Qu’est-ce que cela signifie vraiment?
Les tiers (comme dans les sociétés autres que Google) pourront recevoir plusieurs « sujets » susceptibles d’intéresser un visiteur du site Web en fonction de son historique de navigation des trois semaines précédentes. Par exemple, si j’ai visité foodfordogs.com la semaine dernière, le sujet « animaux de compagnie et animaux/animaux de compagnie/chiens » peut être mis à la disposition des agences de publicité lorsque je visite CNN.com, ce qui permettrait alors à une entreprise d’aliments pour chiens de faire une offre pour me servir une pub.
La marque ne saurait pas qui je suis ni ne disposerait d’autres données de profilage sur moi, mais elle peut utiliser le sujet pour augmenter la probabilité que son annonce soit pertinente pour moi.
Comment les sujets sont-ils attribués au navigateur d’un utilisateur ?
La documentation technique actuelle indique que cela se fera sur la base de « noms d’hôte » – ce qui est un point très important. Les noms d’hôte renvoient aux domaines de premier niveau d’une page Web, tels que example.com ou sports.example.com. Cependant, les noms d’hôte ne fournissent aucune information supplémentaire à partir de la chaîne d’URL complète, ce qui signifie que nous ne pouvons pas utiliser les noms d’hôte pour différencier example.com/sports et example.com/finance.
Ceci est essentiel, car de nombreuses personnes semblent mal comprendre la manière dont les sujets seront attribués au navigateur d’un utilisateur – par exemple, en grattant le contenu des pages des sites Web qu’un utilisateur a visités ou en analysant les données du contenu des e-mails ou des chaînes de recherche.
Google vise à lier les noms d’hôte de sites Web à des sujets, qui peuvent être zéro ou plusieurs – il n’y a actuellement aucune limite fixe – bien que la plage attendue se situe entre un et trois sujets par nom d’hôte.
La seule question flagrante est de savoir si les sites Web devraient être autorisés à définir – ou à remplacer – les sujets qui leur sont attribués. Heureusement, Google le reconnaît et est demander des commentaires et des suggestions de l’industrie. Cela doit être traité, car les sites Web pourraient théoriquement manipuler les sujets qui sont placés et spammer l’API avec les sujets les plus précieux sans héberger de contenu connexe.
Quels sujets peuvent être attribués ?
Encore une fois, Google demande la participation de l’industrie et déclare même que « l’objectif final est que la taxonomie provienne d’une partie externe qui intègre les commentaires et les idées de l’ensemble de l’industrie ». La taxonomie actuelle des concepts peut être trouvée ici et comprend 349 sujets différents.
La transparence intégrée et la nature open source de la prise de décision concernant la taxonomie et les modèles utilisés pour attribuer des sujets aux noms d’hôte de sites Web sont essentielles et pourraient permettre un moyen robuste de permettre un ciblage basé sur les intérêts dans la publicité sans exposer les utilisateurs à la vie privée et risques liés à la protection des données. La taxonomie sera organisée et mise à disposition pour les audits et les utilisateurs pourront contrôler et modifier les sujets qui leur sont attribués ou se désabonner entièrement de l’API Topics.
Comment les sujets sont-ils utilisés pour cibler en fonction des centres d’intérêt ?
En termes très simples, l’API Topics renverra jusqu’à trois sujets distincts à partir du navigateur d’un utilisateur. Les sujets auront au maximum trois semaines et seront générés en fonction des noms d’hôte des sites Web visités par l’utilisateur.
Chaque semaine, cinq « sujets principaux » seront calculés à l’aide des informations du navigateur local, ce qui signifie que cela ne se produit pas sur un serveur cloud obscur hors du contrôle de l’utilisateur. L’idée est d’attribuer au hasard un sixième sujet supplémentaire afin d’introduire un «bruit» qui rend encore plus difficile la prise d’empreintes digitales des utilisateurs en créant et en suivant des combinaisons distinctes de sujets et en les reliant à des utilisateurs individuels.
Les cinq principaux sujets doivent être sélectionnés sur la base d’une semaine d’identifiants de sujet accumulés pour les visites « éligibles » (c’est-à-dire les sites Web qui ont utilisé l’API et les utilisateurs qui n’ont pas désactivé les sujets individuels ou l’ensemble de l’API Topics). De tous ces sujets, les cinq principaux qui surviennent le plus fréquemment en fonction d’un système de classement sera sélectionné et, avec le sujet aléatoire, constituera la liste des sujets d’un utilisateur pour cette semaine.
Il peut y avoir un modèle de pondération qui influence le classement, par exemple, pour s’assurer que des sujets plus granulaires sont considérés comme un moyen d’ajouter de la valeur. Ces informations et la méthodologie de pondération seront soit rendues publiques, soit peut-être même construites et exploitées par un partenaire externe. Tous les sujets et les listes de sujets principaux seront supprimés après la troisième semaine pour assurer un niveau de pertinence grâce à la récence et pour empêcher l’accumulation à long terme de données de profil.
Il convient de noter que tout tiers qui appelle l’API ne recevra jamais que des sujets qui ont été ajoutés au navigateur de l’utilisateur sur un site Web où ce tiers était également présent. Si, par exemple, j’ai visité foodfordogs.com la semaine dernière, mais que la société de technologie publicitaire X n’a pas sa technologie sur le site Web, elle ne recevra pas le sujet « animaux de compagnie et animaux/animaux de compagnie/chiens » lorsqu’elle appellera l’API pour mes sujets sur CNN.com.
Comparé à ce que nous faisons actuellement, cela semble être une manière très imprécise de profiler et de cibler des individus avec des publicités personnalisées.
Oui c’est vrai! Parce que cibler des individus en les profilant et en les suivant sur le Web via des cookies tiers ou (la plupart) des solutions d’identification alternatives est imparfait et rarement (voire jamais) conforme aux réglementations en vigueur en matière de confidentialité.
Les cookies tiers cesseront d’exister et je n’ai pas encore vu de solution d’identification alternative valable qui puisse maintenir le niveau habituel de profilage et de ciblage de manière conforme. Il est temps de se réveiller et de sentir le café. Le système utilisé depuis des années, même après l’introduction du GDPR et d’autres réglementations similaires, touche à sa fin.
Et, franchement, je suis surpris que ça ait duré aussi longtemps.
Vous devriez considérer le concept de l’API Topics comme un moyen d’avoir au moins une méthode pour cibler les utilisateurs en fonction des intérêts sur différents sites Web. Sans l’API Topics ou une autre alternative conforme, sûre et équitable pour les consommateurs, il n’y aura aucun moyen d’ajouter de la pertinence à la publicité en ligne au-delà du ciblage contextuel ou des audiences propriétaires gérées par les éditeurs.
Peut-être que ce ne serait pas une mauvaise chose non plus. Je n’ai pas été du tout impressionné par les soi-disant solutions d’identité alternatives qui utilisent des techniques secrètes d’empreintes digitales ou des e-mails hachés comme identifiants. Mais je considère l’initiative Topics API comme un moyen potentiellement viable, sûr et précieux de maintenir un niveau de ciblage pertinent.
Alors, en quoi l’API Topics est-elle différente de FLoC ?
Ce qui me dérange, c’est que tant de gens positionnent l’API Topics comme une version reskinnée de FLoC, avec laquelle je suis intrinsèquement en désaccord.
Sur la base de la documentation actuelle, il s’agit d’un concept distinct qui met beaucoup plus l’accent sur la conservation humaine, les garanties de confidentialité et les contrôles pour l’utilisateur final. Et, contrairement à FLoC dans son expérience initiale, la génération des sujets d’un utilisateur n’est possible que lorsque les sites Web implémentent et utilisent réellement l’API.
La principale différence – et avantage – est l’accent mis sur la prévention des empreintes digitales. Sur la base du concept actuel, il serait presque impossible de créer des identifiants d’utilisateurs distincts en fonction de l’ensemble de sujets attribués à une personne. Même ainsi, il existe encore certains risques et considérations à ce sujet, dont certains sont décrits ici.
Eh bien, qu’est-ce qu’on fait maintenant?
Examinez et contribuez. Ne criez pas depuis la ligne de touche. Impliquez-vous et influencez la prise de décision.
Oui, il existe des préoccupations et des objections valables concernant le comportement anticoncurrentiel de Google, et moi aussi, j’attends avec impatience plus d’informations et un jugement sur les poursuites en cours contre Google.
Mais, provisoirement, je pense que l’initiative Topics API peut être le début de quelque chose qui pourrait fonctionner, et les intentions et la justification semblent authentiques – dans la mesure où je peux en juger à ce stade. J’espère que Google restera déterminé à être totalement transparent sur les mécanismes, la modélisation et l’infrastructure qui seront construits pour prendre en charge cela. J’espère que Google intègre l’accès des utilisateurs et les contrôles dès la conception. J’espère que Google respecte ses engagements déclarés de travailler avec des partenaires externes.
Et, enfin, j’espère que Google doublera sa responsabilité d’aider à éradiquer les catégories sensibles et les moyens nuisibles de cibler les gens.
Suivre Ruben Schreurs (@RubSchreurs) et Ad Exchange (@adexchanger) sur Twitter.
