La fin des cookies tiers : les navigateurs prennent le contrôle de la publicité en ligne

Voici ce que cela signifie pour la confidentialité des utilisateurs et votre entreprise.

Les cookies tiers sont progressivement supprimés par les navigateurs et de plus en plus de limites leur sont imposées.

La plupart des outils d'analyse, de publicité et d'attribution en ligne se démènent pour trouver des alternatives à la collecte de données. Cette réduction a également un impact sur nos rapports.

Mais comprendre pourquoi les navigateurs limitent les cookies et quels sont les cadres juridiques au niveau des États et des pays est essentiel avant de rechercher des alternatives.

Alors commençons par là…

Pourquoi les navigateurs limitent-ils les cookies ?

La présentation de Simo Ahava à Superweek 2020 ci-dessous montre une chronologie des changements de navigateur mis en œuvre au fil du temps.

Les produits technologiques prennent désormais des mesures plus courtes pour apporter des modifications. Le taux d'application des fonctionnalités d'amélioration de la confidentialité augmente également.

Nous avons constaté plus d'améliorations de la confidentialité dans les navigateurs en 2019 qu'au cours des 5 années qui ont précédé.

Dans mon article, "Les navigateurs poussent-ils pour un avenir sans cookie avec Safari ITP, Firefox ETP et Chrome Privacy Sandbox ? », je parle longuement des raisons de ces changements :

Des navigateurs comme Safari et Firefox (et dans une moindre mesure, Chrome) souhaitent également protéger leurs utilisateurs de ces types de cookies, qui sont utilisés pour créer des profils d'utilisateurs et des intérêts d'achat. Ces informations seront ensuite vendues et utilisées pour cibler les utilisateurs sur d'autres sites. Le vendeur d'annonces réalisera un bénéfice plus élevé sur un placement d'annonce avec une intention vérifiée par rapport à une impression d'annonce simple. Les leaders de l'industrie de la publicité comprennent que la voie à suivre est moins de suivi et plus de placements d'annonces qui correspondent à l'intention de l'utilisateur sur la page (en utilisant la correspondance des annonces de contenu).

Cette idée vient de John Wilander qui a publié ce billet de blog pour Webkit. Selon Wilander, "Intelligent Tracking Prevention a été conçu pour protéger la confidentialité des utilisateurs en empêchant le suivi intersite".

Il s'agit de se concentrer sur les sites Web établissant une relation plus étroite avec leurs propres utilisateurs (dans le contexte d'un site unique pour ITP et le contexte d'une organisation pour Chrome) et d'empêcher les tiers de fournir cela.

Webkit, l'organisation derrière ITP dans Safari et l'un des projets de John Wilander, explique cela plus en détail dans sa politique de prévention du suivi :

Le suivi de WebKit empêchera tout suivi secret et tout suivi intersite (même s'il n'est pas secret). Ces objectifs s'appliquent à tous les types de suivi énumérés ci-dessus, ainsi qu'aux techniques de suivi qui nous sont actuellement inconnues. Si une technique de suivi particulière ne peut pas être complètement empêchée sans nuire indûment à l'utilisateur, WebKit limitera la capacité d'utilisation de la technique. Par exemple, limiter la fenêtre de temps pour le suivi ou réduire les bits d'entropie disponibles - des points de données uniques qui peuvent être utilisés pour identifier un utilisateur ou le comportement d'un utilisateur.

Webkit sait qu'il y a un effet secondaire involontaire de leur projet ITP. L'analyse et la mesure d'audience dans le cadre d'un site unique ne sont pas quelque chose qu'ils veulent bloquer. Les outils d'analyse et de test A/B qui améliorent l'expérience utilisateur ne sont pas combattus.

La question est similaire à ce que traitent les nouvelles lignes directrices de la directive européenne ePrivacy (mises à jour en juillet 2019) et les réglementations ePrivacy non encore mises en œuvre. Les nouvelles règles et technologies créent un vide juridique ou technologique que nous ne pouvons pas encore combler.

En ce qui concerne les navigateurs, nous espérons obtenir de nouvelles fonctionnalités telles que isLoggedIn, Private Click Measurement et Chrome SameSite OrganizationID (First Party Sets).

Mais puisque nous n'avons pas encore ces alternatives, que nous reste-t-il ? Doit-on les ignorer comme le font la plupart des entreprises, suite aux mises à jour de la directive ePrivacy par l'ICO et la CNIL ?

Le RGPD européen ouvre la voie aux limitations légales

La loi sur la protection de la vie privée la plus stricte au monde est le RGPD européen.

Les directives récemment mises à jour de l'ICO (UK's Privacy Authority) et de la CNIL (France Privacy Authority) condamnent également le placement de la plupart des cookies sur les appareils des utilisateurs avant leur consentement actif (et l'utilisation d'astuces telles que les boutons "Accept All", les cases à cocher pré-cochées ou la radio boutons). Les directives, mises à jour en juillet 2019, ne seront appliquées qu'en juillet 2020. Dans le même temps, le règlement ePrivacy (toujours en projet) a prévu certaines exclusions pour les cookies. Celles-ci stipulent toutes que les tests A/B, les analyses et la mesure de l'efficacité des publicités (même les tests de publicités) sont autorisés .

Le 8 novembre 2019, le gouvernement finlandais a publié une proposition révisée de règlement ePrivacy avec quelques modifications. Dans cette proposition, certains cookies peuvent être déposés sans consentement, comme le dernier projet de Règlement ePrivacy (de novembre 2019) le précise aux articles 8, 17aa et article 21a ci-dessous :

Article 8 : « Protection des informations de l'équipement terminal des utilisateurs finaux, 1(d) il est nécessaire à la mesure d'audience du web , à condition que cette mesure soit effectuée par le fournisseur du service de la société de l'information demandé par l'utilisateur final ou par un tiers pour le compte d'un ou de plusieurs prestataires du service de la société de l'information, pour autant que les conditions prévues à l'article 28 ou, le cas échéant, à l'article 26, du règlement (UE) 2016/679 soient remplies. 2(c) elles sont nécessaires aux fins d'un comptage statistique limité dans le temps et dans l'espace à la mesure nécessaire à cette fin et les données sont rendues anonymes ou effacées dès qu'elles ne sont plus nécessaires à cette fin.

Article 17 bis : « Les utilisateurs finaux attachant une grande importance à la confidentialité de leurs communications, y compris de leurs déplacements physiques, ces données ne peuvent être utilisées pour déterminer la nature ou les caractéristiques d'un utilisateur final ou pour établir le profil d'un utilisateur final, afin, par exemple, d'éviter que les données ne soient utilisées à des fins de segmentation, pour surveiller le comportement d'un utilisateur final spécifique ou pour tirer des conclusions concernant la vie privée d'un utilisateur final. Pour la même raison, l'utilisateur final doit être informé de ces activités de traitement en cours et avoir le droit de s'opposer à un tel traitement.

Article 21 bis : « Les cookies peuvent également être un outil légitime et utile, par exemple, pour évaluer l' efficacité d'un service de la société de l'information fourni, par exemple la conception de sites Web et la publicité ou en aidant à mesurer le nombre d'utilisateurs finaux visitant un site Web , certaines pages d'un site Web ou le nombre d'utilisateurs finaux d'une application. Ce n'est pas le cas, cependant, en ce qui concerne les cookies et identifiants similaires utilisés pour déterminer la nature de qui utilise le site, qui nécessite toujours le consentement de l'utilisateur final.

En termes simples, la mesure d'audience Web à l'aide d'un outil d'analyse ou d'un outil tiers n'a pas besoin de consentement aux cookies. Vous pouvez obtenir des statistiques à partir de ces données, mais vous ne pouvez pas les segmenter pour "tirer des conclusions concernant la vie privée d'un utilisateur final" - les données doivent être anonymes.

Le GDPR ouvre l'espace pour les tests A/B et la personnalisation (avec l'option de retenue pour mesurer l'efficacité d'une expérience) pour le contenu, les publicités ou la conception. Cela me donne l'espoir que nous sommes sur la bonne voie pour conserver les puissantes solutions de test A/B dont nous disposons actuellement, mais en nous concentrant sur l'efficacité du message et sur la fourniture de meilleures expériences Web. Nous devrions condamner les pratiques telles que la distinction de petits groupes ou d'individus et la segmentation basée sur des traits facilement identifiables comme le sexe, la race, l'âge ou toute donnée personnelle (telle que définie par le RGPD).

Les navigateurs et les lois sur la confidentialité visent la même chose. Ils sont tous les deux à la tête de ce mouvement, ce qui signifie qu'ils sont même en avance sur les nouvelles solutions alternatives. Leur objectif principal n'est pas de vous empêcher d'analyser les utilisateurs (sur votre site) ou de faire des tests A/B pour améliorer et optimiser l'expérience utilisateur. Ils sont là pour empêcher la construction d'identités sur des emplacements tiers en dehors du contexte du site unique, sans le consentement actif de l'utilisateur. Plus d'informations à ce sujet dans cet article que j'ai écrit.

L'avenir des navigateurs

Les trois navigateurs les plus utilisés actuellement sont Chrome, Safari et Firefox, mais des alternatives plus respectueuses de la vie privée comme Brave se développent rapidement. Chrome est le plus utilisé (64 % des appareils dans le monde), suivi de Safari avec 18 % (et des tablettes jusqu'à 60 %), et de Firefox avec environ 4 % (moins de 1 % sur mobile), selon ce résumé. Ce que ce bloc de puissance fait avec leurs technologies, guidant 76% à 85% du trafic mondial, est essentiel pour comprendre ce que vous devez utiliser pour votre marketing en ligne.

MozillaFirefox

Mozilla détient environ 4 % de la part de marché globale, avec une fourchette estimée entre 8 % et 12 % sur ordinateur et <1 % sur mobile (sources Statcounter, NetmarketShare et WikiMedia). Il offre une protection de la vie privée contre les empreintes digitales et les cookies tiers en utilisant Enhanced Tracking Protection (ETP).

ETP bloque tous les cookies tiers s'ils figurent sur cette liste de Disconnect. Les cookies propriétaires ne sont pas bloqués et la liste de déconnexion semble être catégorisée à l'aide d'une étape intermédiaire et peut-être remplacée par une liste organisée par Mozilla, en fonction de leurs conversations communautaires. Le maintien de cette liste est un processus assez laborieux, mais une étape solide vers la confidentialité. Une fois qu'une source est sur la liste, aucun cookie tiers ne peut être défini. Il n'y a pas de feuille de route claire sur l'orientation de Mozilla Firefox ETP, mais la priorité semble être le raffinement, la catégorisation et l'expansion de la liste des cookies et des empreintes digitales.

Pomme Safari

Le navigateur iOS par défaut a une part de marché entre 20% et 60% sur mobile et tablette, selon Wikipedia (novembre 2019). La part de marché globale est de 18 %. Safari est le navigateur le plus vocal en matière de confidentialité. En 2019, il est sorti avec ITP 2.1, ITP 2.2 et ITP 2.3. C'est également l'équipe de Webkit derrière ITP, qui propose des solutions alternatives aux problèmes introduits par ITP.

Examinons maintenant de plus près les API LoggedIn, Private Click Measurement et Storage Access et voyons comment ils peuvent résoudre certains des problèmes introduits en 2019.

est connecté

John Wilander d'Apple Webkit a proposé une amélioration du W3C (en septembre 2019) sur une norme qui peut aider à la base juridique du RGPD d'un contrat. En Europe, cette base juridique offre la liberté d'utiliser des cookies sur les utilisateurs et bien plus encore, mais uniquement avec le consentement de l'utilisateur. Wilander propose d'utiliser quelque chose de similaire au niveau du navigateur. C'est quelque chose que je pense que les navigateurs accepteront comme base légale à l'avenir.

isLoggedIn est une fonctionnalité du navigateur qui peut refuser l'état côté client (par exemple, les cookies non-session, localStorage) à moins que l'utilisateur ne soit connecté à un fournisseur de confiance. Il est à craindre que l'obsession d'obtenir des données utilisateur puisse conduire à des connexions inutiles juste pour accéder à l'état isLoggedIn et au "contrat" ​​de la base juridique GDPR pour faire des choses comme le reciblage publicitaire. J'ai vécu cela de première main. Dans l'exemple ci-dessous, le site immobilier espagnol Habitaclia essaie de me connecter, alors que l'information est disponible en fermant la pop-up. La valeur de la connexion pour moi en tant qu'utilisateur est nulle, donc cette pratique est apparemment inutile (attention, cela vient d'Espagne, où le RGPD est appliqué).

Mais comme ITP, isLoggedIn sera essayé et amélioré, et j'espère qu'il sera adapté. Il y a eu beaucoup de va-et-vient à ce sujet en 2019 dans le canal W3C, mais aucune autre action n'a été entreprise depuis lors. En théorie, cela pourrait créer une solution technique à la rigidité de la base juridique que seuls les cookies et le consentement peuvent désormais fournir. En Europe, cela offrirait un moyen simple pour tous les outils de savoir si un utilisateur est connecté sur un site et s'il existe une base légale pour collecter des données personnelles.

Mesure des clics privés

La Private Click Measurement (anciennement appelée Privacy-Preserving Ad Click Attribution), par l'équipe Webkit, est une proposition du W3C qui permettrait une attribution simple mais efficace des conversions. Il s'agit d'une proposition plus formelle d'amélioration de isLoggedIn mais pas encore considérée comme un standard du W3C. Pour les tests A/B, cela peut s'avérer utile lors de la conversion dans un environnement de panier d'achat hors site. C'est quelque chose que nous envisagerons de mettre en œuvre lorsqu'il sera disponible publiquement. Vous pouvez lire la suggestion d'implémentation dans cet article. Mi-janvier, Apple Safari et Mozilla Firefox se sont ralliés à cette initiative pour l'élever à un standard formel. Sa limite est de 64 campagnes et un déclencheur de conversion aléatoire avec un délai de 24 à 48 heures (ce qui rend plus difficile pour vous de localiser la conversion, augmentant ainsi la confidentialité), mais avec le soutien de Firefox et Safari, il semble gagner du terrain.

Les limites sont également quelque chose que l'équipe Chrome (Chromium) trouve trop restrictives, et c'est la raison pour laquelle ils ont proposé la nouvelle API de mesure des conversions.

Google Chrome

Chrome détient plus de 64 % des parts de marché dans le monde (dont 67 % sur les ordinateurs de bureau uniquement). Chrome est une centrale électrique dans le monde des navigateurs et un acteur controversé dont les principaux revenus proviennent des produits publicitaires de Google. Avec une part de 25 % à 65 % pour les mobiles et 67 % pour les ordinateurs de bureau, c'est le navigateur le plus dominant au monde. Mais les choses changent, et nous l'avons déjà vu… les navigateurs peuvent tomber en disgrâce. Toutes les préinstallations d'Android risquent de ne pas enregistrer Google Chrome si elles ne se concentrent pas sur la confidentialité.

Digiday résume bien cela :

Les modifications récentes visant à restreindre le suivi par des tiers dans les navigateurs Safari d'Apple et Firefox de Mozilla se sont avérées perturbatrices pour les éditeurs, les fournisseurs de technologies publicitaires et les agences. Pourtant, la confidentialité sur le Web devenant de plus en plus une préoccupation majeure des consommateurs, Google subit une certaine pression concurrentielle pour emboîter le pas.

Ian Lowe, vice-président marketing de la plateforme de gestion du consentement Crownpeak, déclare :

Alors que la pression monte, Google cherche à montrer de plus en plus de moyens d'évoluer positivement dans le sens de la confidentialité tout en maintenant le modèle de revenus.

MêmeSite

La mise à jour SameSite de février 2020 concernant Chrome 80 obligera les propriétaires de sites Web à étiqueter explicitement les cookies tiers qui peuvent être utilisés sur d'autres sites. Digiday explique très bien le changement :

Google a annoncé pour la première fois en mai de l'année dernière que les cookies qui n'incluent pas les étiquettes "SameSite=None" et "Secure" ne seront pas accessibles par des tiers, tels que les sociétés de technologie publicitaire, dans Chrome version 80 et au-delà. Le label Secure signifie que les cookies doivent être définis et lus via des connexions HTTPS.

À l'heure actuelle, la valeur par défaut du cookie Chrome SameSite est : "Aucun", ce qui permet aux cookies tiers de suivre les utilisateurs sur les sites. Mais à partir de février, les cookies seront par défaut "SameSite=Lax", ce qui signifie que les cookies ne sont définis que lorsque le domaine dans l'URL du navigateur correspond au domaine du cookie - un cookie propriétaire.

Tout cookie avec l'étiquette "SameSite=None" doit également avoir un indicateur sécurisé, ce qui signifie qu'il ne sera créé et envoyé que via des requêtes effectuées via HTTPs. Pendant ce temps, la désignation « SameSite=Strict » restreint complètement le partage entre sites, même entre différents domaines appartenant au même éditeur. »

Firefox de Mozilla et Edge de Microsoft ont annoncé qu'ils adopteraient également la valeur par défaut SameSite=Lax. Sans cet étiquetage, nous commencerons à voir de plus en plus d'avertissements dans la fenêtre contextuelle de la console Chrome, comme celle ci-dessous.

Selon Digiday :

La mise à jour SameSite et Google Ads de Google en février empêchera les entreprises de technologie publicitaire qui n'ont pas de relation principale avec un consommateur d'"écouter" les enchères publicitaires afin de créer des profils d'utilisateurs à l'aide de catégories de contenu. Dans le système actuel, si un utilisateur visite un site comme ESPN.com, l'échange de Google renvoie des informations dans le flux d'enchères qui incluent le sujet contextuel "sports" aux enchérisseurs potentiels. Une plate-forme côté demande et d'autres sociétés de technologie publicitaire telles que les plates-formes de gestion de données sont capables de voir ces informations et pourraient, en théorie, les utiliser pour créer des profils d'utilisateurs comportementaux à l'insu de l'utilisateur. Il n'est pas clair si cela se produit régulièrement dans la pratique, mais cette possibilité présente un risque GDPR. La création de profils d'utilisateurs sur la base des données d'enchères est également interdite par les règles publicitaires de Google.

Les modifications de SameSite semblent relever d'un projet plus général sur lequel travaille Google Chrome, appelé Privacy Sandbox.

Bac à sable de confidentialité

La mission de Privacy Sandbox est de "créer un écosystème Web prospère, respectueux des utilisateurs et privé par défaut", selon cette page Chromium. L'approche générale de Chrome, tout comme celle de Webkit, consiste à réactiver le suivi intersites, mais sans implications pour la confidentialité des utilisateurs. Cela signifie qu'ils ne veulent pas perdre les fonctionnalités publicitaires, mais peuvent également voir que la confidentialité devient un problème qu'ils ne peuvent plus ignorer.

Voici une déclaration révélatrice de l'équipe:

Nous pensons qu'une partie de la magie du Web réside dans le fait que les créateurs de contenu peuvent publier sans aucun gardien et que les utilisateurs du Web peuvent accéder librement à ces informations, car les créateurs de contenu peuvent se financer grâce à la publicité en ligne. Cette publicité est beaucoup plus précieuse pour les éditeurs et les annonceurs et plus attrayante et moins ennuyeuse pour les utilisateurs lorsqu'elle est pertinente pour l'utilisateur. Nous prévoyons d'introduire de nouvelles fonctionnalités pour servir les cas d'utilisation qui font partie d'un Web sain qui est actuellement réalisé grâce au suivi intersite (ou des méthodes qui ne peuvent être distinguées du suivi intersite). Au fur et à mesure que cette fonctionnalité deviendra disponible, nous imposerons de plus en plus de restrictions sur l'utilisation des cookies tiers, qui sont le mécanisme le plus courant pour le suivi intersite aujourd'hui, et nous finirons par les abandonner complètement. Parallèlement à cela, nous combattrons agressivement les techniques actuelles de suivi intersites non basées sur les cookies, telles que les empreintes digitales, l'inspection du cache, la décoration des liens, le suivi du réseau et les jointures d'informations d'identification personnelle (PII) .

Michael Kleber, un ingénieur logiciel de Google qui travaille sur la confidentialité et la prévention du suivi dans Chrome, décrit le plan de l'entreprise pour évoluer vers un Web sans suivi. Il suggère de passer des cookies à des "API plus adaptées" qui ne permettent pas un suivi sans entrave des individus sur le Web et explique comment Chrome explore l'utilisation de Federated Learning of Cohorts (FLoC) (partie du projet Privacy Sandbox) pour continuer à autoriser les publicités ciblées par centres d'intérêt sur le Web. Il encourage les développeurs à "nous aider à imaginer un monde sans cookies tiers ni autres vecteurs de suivi".

Déclaration des cookies propriétaires appartenant à la même organisation

Un autre projet sur lequel Chrome travaille dans le cadre de l'initiative Privacy Sandbox est First Party Sets (Justin Schuh, directeur de Chrome Engineering a commencé à en parler en août 2019).

Ce projet propose un nouveau mécanisme de plate-forme Web pour déclarer une collection de domaines connexes en tant qu'ensemble propriétaire. Il s'agit d'une itération de la « politique de confiance unique et de même origine v2 » et des « domaines affiliés » de Wilander.

Ici, le navigateur considérera les domaines comme membres d'un ensemble si les domaines s'inscrivent et si l'ensemble respecte la politique UA, afin d'intégrer à la fois les besoins de l'utilisateur et du site. Les domaines s'inscrivent en hébergeant un manifeste JSON à l'adresse https://<domain>/.well-known/first-party-set. Les domaines secondaires pointent vers le domaine propriétaire tandis que le domaine propriétaire répertorie les membres de l'ensemble, un numéro de version pour déclencher les mises à jour et un ensemble d'assertions signées pour informer la politique UA. En voici un exemple :

 https://a.example/.well-known/first-party-set { "owner": "a.example", "version": 1, "members": ["b.example", "c.example"], "assertions": { "chrome-fps-v1" : "<base64 contents...>", "firefox-fps-v1" : "<base64 contents...>", "safari-fps-v1": "<base64 contents...>" }, } https://b.example/.well-known/first-party-set { "owner": "a.example" } https://c.example/.well-known/first-party-set { "owner": "a.example" }

Déclarer vos domaines propriétaires aux navigateurs vous permet d'inclure tous les domaines de votre organisation. Cela permet aux navigateurs de bloquer plus facilement les outils tiers qui utilisent les cookies et les scripts propriétaires. Si vous disposez de personnalisation, de tests A/B, d'analyses, de systèmes d'attribution ou d'outils de parrainage, placez-les sous les domaines de votre organisation, comme les cookies côté serveur et CNAME. Assurez-vous de vérifier quelles parties vous amenez sous vos domaines car ils deviennent votre responsabilité (vous devrez bientôt les déclarer aux "douanes" du navigateur avant d'entrer dans l'appareil du visiteur).

API de mesure des conversions

Se référant aux spécifications de l'API de mesure de conversion, Steven Englehardt de Mozilla a déclaré :

Je voudrais exprimer les préoccupations de Mozilla concernant l'introduction d'un identifiant intersite à haute entropie, que j'ai également exprimées lors de la réunion susmentionnée du TPAC. L'identifiant à haute entropie des « données d'impression » donne au site de l'éditeur la possibilité d'obtenir des informations sur l'activité d'un utilisateur individuel sur un site autre que le sien. Il s'agit d'une violation explicite de la politique anti-pistage de Firefox, et nous n'allons pas implémenter une API qui facilite une telle violation car elle permet le suivi intersites. Le site éditeur peut connaître des informations sur les individus en associant la valeur « données d'impression » à un identifiant utilisateur au moment de l'enregistrement de la conversion (c'est-à-dire lorsque l'utilisateur clique sur une annonce sur le site éditeur). Ensuite, les informations révélées par la valeur "conversion-metadata" peuvent être associées au compte de cet utilisateur via le lien créé par la valeur "impression data". En pratique, il peut s'agir d'informations sensibles comme si cet utilisateur a effectué un achat sur le site de destination ou s'il s'est enregistré pour un compte. Pour comprendre la gravité du risque associé au fait de permettre à l'éditeur de collecter des données d'activité associées à un individu via cette API, considérez que l'éditeur peut être un moteur de recherche ou un réseau social qui agit comme le principal point d'accès d'un utilisateur au reste du Web. . Les éditeurs dans cette position sont susceptibles d'en savoir plus sur l'activité d'un utilisateur individuel sur un grand nombre de sites de destination, et ainsi de construire une image assez complète de l'activité d'achat hors site, de l'activité d'inscription hors site de cet utilisateur, etc.

De plus, Safari (Webkit) exprime le scepticisme du public, en particulier autour des métadonnées d'impression 64 bits.

D'une manière ou d'une autre, tous les autres navigateurs cherchent à résoudre le problème d'attribution pour les annonceurs en utilisant soit l'API Conversion Measurement proposée par Chrome, soit l'API Private Click Measurement proposée par Safari. Une fois cela en place, tous les navigateurs offriront aux annonceurs suffisamment d'incitations pour travailler avec eux tout en protégeant la confidentialité sur le Web.

Tourterelle ou apprentissage fédéré des cohortes (FLoC)

Michael Kleber a développé une nouvelle proposition appelée Two Uncorrelated Requests, Then Locally-Executed Decision On Victory (TURTLE-DOV) ou TURTLEDOVE (version mise à jour de PIGIN).

Bien qu'il ne soit pas encore clair comment Turtledove ou l'apprentissage fédéré des cohortes (FLoC) se dérouleront, l'équipe de Chrome met toutes ces solutions en discussion et voit laquelle obtient l'adhésion des équipes de confidentialité de Safari, Firefox et Brave. La proposition de FLoC offre une approche différente du ciblage publicitaire, en se concentrant sur les intérêts généraux des gens plutôt que sur des actions spécifiques.

Dans le modèle FLoC, les annonceurs et les réseaux publicitaires n'ont aucun contrôle sur les groupes dans lesquels se trouvent les personnes. Au lieu de cela, le navigateur lui-même est responsable du regroupement d'une manière ou d'une autre de groupes de "personnes similaires", avec une grande latitude dans la manière dont il propose sa notion de similarité. . Le navigateur peut alors prendre des mesures pour empêcher son regroupement de permettre le suivi ou de révéler des caractéristiques sensibles. PIGIN répond à ce cas d'utilisation, et une partie de cet explicatif est réutilisée ici. Dans cette proposition, le navigateur contrôlait l'appartenance aux groupes d'intérêt (comme dans celle-ci), mais une petite quantité d'informations sur les groupes d'intérêt était envoyée avec la demande d'annonce contextuelle habituelle (et il n'y avait pas d'enchère dans le navigateur).

Les commentaires du W3C Web-Advertising Business Group et Privacy Interest Group et des communautés de recherche sur les navigateurs et la confidentialité ont mis en évidence les faiblesses de cette conception.

La possibilité d'associer l'affectation d'un groupe d'intérêt d'un annonceur à l'identité de première partie d'une personne sur le site d'un éditeur est considérée comme une fuite de confidentialité trop importante, même avec les mesures d'atténuation proposées par l'Explicateur. L'analyse des adhésions aux listes d'utilisateurs dans le monde réel montre que même la "petite quantité d'informations sur les groupes d'intérêt" proposée consommerait trop du budget de confidentialité d'une page. L'ajout d'une enchère dans le navigateur dans TURTLEDOVE est un moyen de remédier aux deux faiblesses en matière de confidentialité. Les discussions avec les participants de l'écosystème publicitaire ont rendu plus plausible l'adoption d'un composant d'enchères dans le navigateur.

Comment fonctionnerait TURTLEDOVE ? La proposition est une nouvelle API pour répondre à ce cas d'utilisation tout en offrant certaines avancées clés en matière de confidentialité :

• Le navigateur, et non l'annonceur, détient les informations sur ce que l'annonceur pense intéresser une personne.
• Les annonceurs peuvent diffuser des annonces en fonction des centres d'intérêt, mais ne peuvent pas combiner ces intérêts avec d'autres informations sur la personne, en particulier qui elle est ou quelles pages elle visite.
• Les sites Web visités par la personne et les réseaux publicitaires utilisés par ces sites ne peuvent pas connaître les intérêts publicitaires de leurs visiteurs.

Cela semble être une bonne solution pour la confidentialité et fait du navigateur un acteur puissant dans le monde de la publicité. De cette façon, je vois des entreprises comme Apple (Safari Webkit), Firefox et Brave soutenir cela comme de nouveaux modèles de revenus, tout en respectant la vie privée. Pourtant, cela nécessiterait un transfert de pouvoir massif des réseaux publicitaires vers les navigateurs.

Le côté serveur nous sauvera tous

Certains fournisseurs prétendent que la méthode côté serveur résout tous les problèmes et qu'elle permet la personnalisation ou les tests A/B. Mais la méthode côté serveur ne vous permettra pas de faire grand-chose sans comprendre l'état du client (utilisateur dans un navigateur). Pour cela, vous avez toujours besoin de cookies propriétaires. Comment configurez-vous ces cookies propriétaires ? Vous devez présenter les mêmes variantes pour les tests A/B et la personnalisation de manière à ce qu'elles restent d'une session à l'autre pour que cela fonctionne. La prise d'empreintes digitales n'est pas légale et les navigateurs suivent et désactivent ces méthodes. Ce n'est pas transparent du tout. Vous ne pouvez utiliser que des cookies de première partie définis sous un sous-domaine du site principal et utiliser des ensembles de première partie pour indiquer que vous possédez ce sous-domaine.

Côté client contre côté serveur n'est pas un débat qui a du sens dans cette discussion.

Vous pouvez appeler la personnalisation du site client et les outils de test A/B hybrides, car ils déplacent la responsabilité de la configuration des cookies vers un domaine de confiance (ensembles propriétaires) au sein de l'organisation. Cependant, dans ce cas, tous les outils du site client seraient hybrides, car ce sera la seule façon de le faire à l'avenir.

Suppression des cookies tiers. Et après?

Les signes sont clairs, les cookies sont morts… enfin, pas vraiment. La plupart des articles en ligne parlent de la mort des cookies. Bien que nous ayons vu de nombreuses API capables de prendre en charge une partie du travail des cookies, rien n'indique que les cookies vont encore quelque part.

Les cookies tiers disparaîtront complètement, et c'est une bonne chose pour la confidentialité.

Justin Schuh, directeur de Chrome Engineering a récemment déclaré : "Nous prévoyons de supprimer progressivement la prise en charge des cookies tiers dans Chrome (et) notre intention est de le faire d'ici deux ans". Chrome commencera par les spécialistes du marketing de conversion, car ils prévoient de lancer les premiers essais d'origine d'ici la fin de 2020, en commençant par la mesure de la conversion et en suivant par la personnalisation.

Webkit (Apple Safari) et Chrome (Google) aideront à ouvrir la voie à la confidentialité des navigateurs, Apple poussant Google à opter pour plus de confidentialité tout en ne résolvant pas de nombreux problèmes de confidentialité iOS.

Je prédis que de plus en plus d'entreprises européennes essaieront d'amener les utilisateurs à se connecter et à s'enregistrer (en espérant ne pas utiliser les services Google ou Apple) et appliqueront la base juridique sur le contrat.

L'intérêt d'optimiser le consentement ou de présenter certains avantages lors de la phase de connexion (comme le one-click d'Amazon) montre clairement que la bataille en Europe sera entièrement liée aux connexions.

En tant qu'optimiseurs, nous devrons nous assurer qu'au niveau organisationnel, nous avons tous les domaines (de première partie) prêts à être partagés avec les navigateurs. Un pas dans cette direction peut consister à dresser un inventaire des scripts et des fournisseurs respectueux de la vie privée. Ensuite, donnez à ce cookie propriétaire l'accès via votre solution CNAME centrale tout en conservant tous les outils sensibles à la confidentialité (création de profils intersites).

Nous serons légalement tenus de demander le consentement au Royaume-Uni (selon l'ICO), mais je prévois que les directives de la CNIL pour les exceptions sur les tests A/B et les analyses limitées ouvriront la voie à une exception européenne pour ceux qui correspondraient à la nouveau règlement ePrivacy. Sans cela, nous n'aurons que des analyses basées sur les sessions et nous ne pourrons pas nous connecter aux utilisateurs individuels. Les tests A/B utilisant le moniteur standard au niveau de l'utilisateur et la boucle de conversion ne s'appliquent pas dans ce cas et nous devrons nous rabattre sur l'amélioration continue, en surveillant ces améliorations de conversion et en les corrélant.

Les non-Européens peuvent être testés sur l'utilisation de cookies propriétaires (ceux que Convert Experiences fournit) et doivent commencer par un inventaire de tous les scripts et fournisseurs auxquels l'organisation fait confiance pour les apporter aux sous-domaines utilisant des CNAME. Les conversions peuvent être suivies à l'aide des différentes API Click ou Conversion Attribution en cours de développement. Peut-être que les tests A/B peuvent les relever pour les différentes variantes et maintenir la cohérence si les navigateurs ne suivent pas la réflexion de la CNIL en les excluant des blocs de cookies, bien que dans les formats actuels, cela semble peu probable. La cohérence provient des cookies de confiance propriétaires.

L'analyse basée sur l'utilisateur utilisant des techniques telles que isLoggedIn sera probablement étendue et unifiée sur tous les navigateurs, permettant aux lois sur la confidentialité de transférer la responsabilité de la définition du contrat aux mécanismes du navigateur. Cela donne aux navigateurs un nouveau pouvoir. Combiné avec de nouvelles API pour les mesures d'intention, les catégories d'annonces et le suivi des conversions, la bataille est lancée pour savoir qui détient la plus grande part de marché des navigateurs et offre les plus grands réseaux publicitaires au monde.

Des temps intéressants à venir… J'espère vraiment que cet article vous aidera à clarifier où les lois sur la confidentialité et les navigateurs sont susceptibles d'aller. Une chose est certaine. Préparez votre équipe d'optimisation et d'analyse à planifier les changements le moment venu (ce sera plus tôt que vous ne le pensez).

Avez-vous des questions? Continuons la conversation sur LinkedIn.