Skip to main content

Webinar - Cookieless (ép 2) :
Pilotez vos actions marketing dans un monde de plus en plus cloisonné !

Mois : juillet 2021

Quelles alternatives aux cookies ?

Même si Google vient d’accorder un sursis aux cookies tiers, la question reste d’actualité. Quelles solutions pour les remplacer ? Comment maintenir l’efficacité des activations digitales tout en préservant les données personnelles ? Revue des options.

Un sursis. C’est ce que vient d’accorder Google en annonçant le 24 juin que les cookies tiers ne disparaitront pas de Chrome début 2022. La firme de Mountain View prévoit désormais cette bascule pour mi-2023. Un report d’une grosse année qui s’explique : l’alternative de Google aux cookies tiers n’a pas rallié suffisamment de suffrages (euphémisme) pour s’imposer. Comment adapter la stratégie cookieless à ce nouvel agenda ? Faut-il renoncer à explorer d’autres alternatives ? Quelques éléments de réponse.

Tout d’abord, une évidence : même si les cookies tiers bénéficient d’un sursis, l’histoire est écrite… Rappelons que les cookies tiers, déjà filtrés au sein de Safari et de Firefox, sont condamnés à court terme – car 2023 c’est demain. Les réglementations (RGPD, ePrivacy), la culture du consentement qui se développe peu à peu, la sensibilité générale accrue autour des données personnelles ne laissent pas d’autre choix que de repenser le tracking, au sein des navigateurs comme des apps.

Les cohortes de Google

Sur le papier, c’est d’ailleurs le sens de l’alternative proposée par Google avec sa Privacy Sandbox, une suite d’API pour couvrir les différents usages (ciblage, mesure…). Pour le ciblage, Google compte sur FloC (Federated Learning of Cohorts). L’idée générale : avec FloC, le tracking ne s’effectue plus à l’échelle d’un individu, mais d’une cohorte qui compterait a minima quelques milliers d’individus. Insuffisant pour l’EFF (Electronic Frontier Foundation) qui voit FloC comme un beau moyen de faciliter d’autres méthodes d’identification comme le fingerprinting.

Dans le détail, la méthode pose des questions qui ont très vite contraint Google à renoncer à la tester en Europe, RGPD oblige. Par ailleurs, la mainmise de la firme de Mountain View sur le dispositif a conduit un acteur comme Amazon à annoncer qu’il bloquerait les remontées d’informations vers FloC… Difficile dans ces conditions d’en faire un nouveau « standard ». La copie doit donc être revue. Une année sera-t-elle suffisante pour conformer l’alternative de Google à la réglementation européenne et pour fédérer l’écosystème ? Un gros doute persiste.

Un chantier à poursuivre : la migration server-side

Quelles sont les autres solutions sur la table ? À quels chantiers peuvent s’attaquer les marques pour se préparer au tracking cookieless ? Premier d’entre eux, la migration vers le server-side. Aujourd’hui, avec les cookies, nous sommes dans un mode « client-side » : le navigateur dialogue avec les fournisseurs de services correspondants aux tags activés. Avec le « server-side », ce dialogue se déroule de serveur à serveur.

Le passage au « server-side » est au programme de nombreuses marques. Parmi elles, FLOA Bank. « Une telle migration, nous le savons d’ores et déjà, ne pourra être que partielle, car toutes les solutions que nous utilisons ne sont pas compatibles avec une gestion côté serveur. Mais si nous y parvenons pour quelques tags clés d’acquisition, ce sera déjà un grand pas », juge Carole Vinatier Gresta, Responsable SEO & Tracking de FLOA Bank.

La voie du SSO : pour les médias uniquement ?

Autre voie explorée, le single sign on (SSO) : un login partagé entre plusieurs sites d’un même écosystème. Sans surprise, ce sont les médias qui s’essayent à ce scénario pour proposer une expérience utilisateur « sans couture » (sans re-login d’un média à l’autre) et, aussi, pour être en mesure de partager des données cross-site. Ces « groupements » restent toutefois très locaux et cantonnés pour l’heure, à quelques exceptions près, au secteur des médias.

Côté adtech : vers de nouveaux ID ?

Du côté de l’adtech, les regards se tournent vers des ID (identifiants) alternatifs aux cookies tiers. C’est le sens du projet Unified ID 2.0 initié par Trade Desk et qui a su convaincre des acteurs comme Liveramp, Criteo ou encore Nielsen. Unified ID 2.0 entend s’appuyer sur les emails que les visiteurs acceptent de communiquer pour déployer une mécanique de type SSO. Le dispositif prévoit un portail sur lequel les utilisateurs peuvent gérer leurs préférences. Limite du projet : il suppose une adoption large pour devenir un standard de fait et éviter une fragmentation du marché entre différents ID publicitaires – ce qui nécessiterait des réconciliations complexes et coûteuses.

La tentation du retour aux sources

Pour certains, la solution – une partie en tout cas – passe par un retour aux sources : laisser de côté l’audience planning pour revenir à du médiaplanning. Concrètement, il s’agit de mettre en œuvre du ciblage sémantique : analyser le contenu et sa tonalité pour évaluer son éligibilité à une campagne donnée. Il est vrai que, sur ce terrain, les technologies ont mûri et les ciblages se sont affinés. Et avec ce procédé, plus de problème d’identifiants susceptibles de limiter le reach. Les éditeurs y gagnent la possibilité de commercialiser tout leur inventaire, mais les annonceurs, eux, doivent se satisfaire de données très limitées.

La revue des alternatives aux cookies le monte clairement : aucune solution ne semble pour l’heure en mesure de fédérer l’écosystème aussi bien que les cookies tiers. Pour les marques, une voie pragmatique s’impose : travailler la data first party et réduire la dépendance aux cookies tiers (via la migration vers le server-to-server) tout en restant à l’affût des nouvelles initiatives. Le monde cookieless cherche encore son étoile polaire.

Se préparer à un monde sans cookies : téléchargez le playbook

Pourquoi une refonte du Dashboard de Consent Analytics de TrustCommander, 2 ans après l’entrée en vigueur du RGPD ?

Le marché avait besoin de statistiques mais la maturité manquait. Nous avons voulu simplifier et adopter une approche plus « métier » dans la sélection et la présentation des principales métriques dans TrustCommander.

Et puis les dernières directives de la CNIL, qui ne s’appliquent qu’au marché français à date, ont rendu obsolètes ou moins importantes certaines métriques. Mesurer le consentement implicite n’a plus de sens puisqu’il est non conforme en France. Nous avons donc repriorisé certaines informations et facilité les comparaisons inter-CMP. Ce point n’est pas le moins important car rien de plus déstabilisant pour un directeur e-commerce de voir derrière le même nom « taux de consentement » 2 choses aussi différentes que le taux de consentement au sens Commanders Act et la part de consentement. En expliquant ces différences, on permet à tout un chacun de se comparer et de progresser.

Le dernier enjeu important était de rendre lisible et compréhensible par tous cette réalité du « consentement ». Effectivement, la jeunesse du domaine du consentement fait qu’il existe encore peu de spécialistes du consentement; les équipes avec lesquelles nous travaillons sont souvent pluridisciplinaires mélangeant web analyst, spécialiste de l’activation, juridique, DPO, …chacun disposant de son propre vocabulaire et représentation des choses. Il fallait donc éviter tout jargon rendant la compréhension encore plus complexe. On a choisi un fil rouge simple, par exemple :

  • Comment les utilisateurs interagissent avec la CMP ?
  • Comment interagissent-ils avec le centre de préférences?

Associé à cette refonte « Consent Analytics », on en a profité pour permettre des exports programmables ainsi qu’une API GET statistics permettant à une équipe de rapatrier ces statistiques pour nourrir des environnements de Data Visualisation (Power BI, Tableau Software, Qlik Sense, Google Data Studio,…).

Enfin, l’enrichissement en temps réel est également possible via API permettant de nourrir en temps réel une solution d’analytics exemptée.

La valeur du consentement offrira un trigger à l’éditeur web analytics lui permettant d’orienter le traitement des données collectées soit vers sa solution standard, soit vers sa solution exemptée CNIL. Nous l’avons réalisé avec des clients AT Internet qui offre aujourd’hui une solution exemptée et nous l’avons mis en place avec des clients Google Analytics ayant fait le choix de continuer à le déclencher sans consentement (ce qui à date du 13 juillet n’est pas encore validé par la CNIL).

Dans quel sens le sujet du « Consent Analytics » va-t-il évoluer ?

Nous voyons des évolutions dans certaines dimensions. Pour avancer dans la compréhension de ce qui fait varier le taux de consentement, nous avons besoin de monitorer les variations des différents indicateurs, de pouvoir les remettre en contexte et de les segmenter davantage.

On fera apparaître par la suite :

  • Plus de possibilité de segmenter les dashboards en fonction de critères comme le navigateur, la taille d’écran, la source de trafic,… Autant de dimensions qui peuvent permettre de comprendre plus finement la valeur de ces métriques ;
  • L’ajout de graphiques pour aider à la lecture et à la compréhension des tendances ;
  • Des rapports dédiés à l’analyse des tests AB plutôt que d’aller lire dans Excel le résultat des tests ?

TrustCommander vous permet d’avoir le même Dashboard pour les applications et le web avec une implémentation basée sur l’API.

Pour aller plus loin sur le sujet du consentement, vous pouvez consulter nos contenus :

Pourquoi le server-side (full ou hybride) est plus accessible que vous ne pensez ?

Le tag management dit « server-side » est souvent considéré comme délicat à mettre en œuvre. Sauf qu’il existe deux façons de le déployer…

La croissance des adblockers, puis la fin annoncée (même si reportée) des cookies tiers… L’actualité a poussé sur le devant de la scène le tag management « server-side », aussi appelé « server to server » ou encore « tagless ». Le principe est simple – déplacer du navigateur au serveur la charge de travail que représentent les échanges d’informations avec les partenaires – mais la mise en place est souvent considérée comme très technique et délicate. Bonne nouvelle : ce que l’on nomme « server-side » renvoie dans la pratique à deux types de mises en œuvre, et l’une d’elles s’avère plus accessible…

Full server-side ou server-side hybride ?

« Full server-side ». Cette appellation désigne une mise en œuvre intégrale du Tag management « server-side ». Dans ce modèle, dès qu’un utilisateur s’active (arrivée sur une page, clic sur une vidéo…), un « hit serveur » est envoyé vers le TMS (Tag Management Server) qui traite les informations et alimente les partenaires concernés, de serveur (celui du TMS) à serveur (celui du partenaire). Dans ce cas de figure, on ne trouve même plus de datalayer dans le navigateur.

 

 

« Server-side hybride ». C’est sous ce nom que l’on commence à désigner l’autre manière de déployer le « server-side ». Un nom qui peut porter à confusion car, dans la réalité, ce déploiement « hybride » correspond à une modalité courante que beaucoup appliquent d’ailleurs sans la qualifier ainsi.

Seule différence : le datalayer

Principale différence entre les deux approches : dans le modèle dit « hybride » un datalayer est conservé. Mais aucun tag partenaire n’est activé depuis le navigateur. Les informations du datalayer sont utilisées par un tag unique qui envoie ces informations côté serveur où le TMS, comme dans le modèle précédent, traite l’information avant de la distribuer aux partenaires de serveur à serveur.

Quel est l’intérêt de cette approche hybride ? Son pragmatisme et son accessibilité technique. De fait, de nombreux partenaires n’ont pas repensé leurs solutions pour fonctionner dans un mode « full server-side » et ont donc encore besoin des informations du datalayer. Que perd-on avec le « server-side hybride » ? La seule différence étant le maintien du datalayer, celui-ci reste donc visible dans le navigateur. Si les informations qu’il contient posent des problèmes de confidentialité, alors la migration en mode « full server-side » peut se justifier. Ce point mis à part, le « server-side hybride » offre tous les avantages du « full server-side ».

 

Des avantages maintenus

Et ces avantages du « server-side » sont nombreux. La réduction drastique du nombre de tags impacte (positivement) les temps de chargement des pages tandis que les plans de marquage sont plus simples à maintenir. Des gains opérationnels appréciés de tous. Mais le « server-side » c’est aussi – avant tout ? – un meilleur contrôle des données. Là où, avec le « client side », les informations partent directement aux partenaires, avec le « server-side » les informations sont traitées et triées. Les partenaires ne reçoivent que les données dont ils ont besoin. Fini les risques, par exemple de « piggybacking », quand un tag en appelle d’autres pour distribuer des informations à des partenaires de partenaires…

Ce traitement côté serveur permet aussi d’enrichir les informations, avec d’autres sources, pour rendre les traitements plus pertinents. Intéressant dans de nombreux contextes, comme celui de l’A/B Testing où cette ouverture autorise des tests plus poussés – par exemple, mesurer l’impact de recommandations d’achats sur le chiffre d’affaires.

Et le consentement ?

Question légitime (et de fait souvent posée). Le « server-side » permet-il d’être exempté du consentement ? Réponse rapide : qu’il soit full ou hybride, le « server-side » n’exempte pas de consentement. Ce n’est qu’un véhicule, une modalité technique. Le « server-side » peut être exempté de consentement dans un seul cas de figure : quand la solution qu’il porte est elle-même… exemptée.

 

Pour ne rien manquer des dernières actualités de Commanders Act, abonnez-vous à notre newsletter !  

© Commanders Act. Tous droits réservés
Powered by CREAATION.