CHRONIQUE. Fin des cookies tiers, ID bridging, investigation sur le SSP Colossus… Cet article a pour but de décrypter le mécanisme de cookie matching qui est aujourd’hui sous les projecteurs pour de bonnes ou mauvaises raisons.
Le cookie matching (ou cookie syncing) est un mécanisme permettant à des plateformes de réconcilier des cookies afin de créer une correspondance autour d’un device ou d’un profil pour afficher le bon message publicitaire.
En programmatique, SSP et DSP s’accordent lors de la connexion en amont sur des étapes importantes afin que le cookie matching fonctionne pour les deux parties :
- Endpoint: C’est une URL qui permet de déclencher le cookie matching, récupérer la valeur du cookie et l’envoyer au SSP ou DSP.
- Déclenchement du cookie matching: L’endpoint peut être appelé via un code JavaScript, une iFrame ou un pixel placé côté utilisateur.
- Cookie matching table: C’est une base de données permettant de réconcilier la valeur du cookie et de l’ID stocké par la plateforme.
- Choix de l’inventaire entre SSP et DSP:
- L’inventaire d’un éditeur n’obtient pas 100% de cookie matching, pour des raisons techniques, des raisons de capacité ou autre…
- Des DSP peuvent exiger de recevoir un inventaire seulement avec un cookie matching ou tout recevoir (avec ou sans cookie matching). Cela dépend des volumes, de la profitabilité (une bid request a 5 fois plus de valeur avec le cookie matching), de la qualité etc… Note: Si un DSP exige de ne recevoir qu’un inventaire avec cookie matching (simplement pour enchérir sur profil connu et reconnu), le SSP se doit de jouer le jeu pour ne pas se faire bannir. Cependant, un éditeur ou SSP peut « s’amuser » à envoyer des bid requests avec de faux ID ou réutiliser un ID dans des bid requests (par exemple, l’id d’un profil envoyer 10, 30, X fois) afin de tromper le DSP et gonfler des volumes et donc des revenues…
Coté vie privée de l’utilisateur, les plateformes publicitaires doivent respecter le consentement de l’utilisateur via la CMP (consent management platform) et le TCF (Transparency Consent Framework) pour déclencher ou non le cookie matching.
Quel est le problème avec le cookie matching ?
Quand tout est fonctionnel, le cookie matching aide les plateformes à adresser le bon message au bon profil mais il est vrai que le cookie matching ne contient pas un problème mais des problèmes. Récemment, des articles sur l’ID bridging, l’investigation autour du SSP Colossus et autres m’indiquent que la méconnaissance du sujet est bien plus grande que les problèmes cités. On peut facilement le voir en lisant les articles sur un sujet et la multitude de versions qui peuvent se compléter ou contredire. Voici une liste de problèmes qui peuvent arriver autour du cookie matching et qui ne sont pas nouveaux :
- Un SSP peut fausser la valeur de cookies dans la bid request
- Un éditeur peut fausser la valeur de cookies dans l’appel publicitaire vers le SSP
- Un bug technique peut avoir lieu côté SSP ou éditeur
- Un système d’ID bridging (mon article sur le sujet) peut avoir été mis en place
- Le DSP peut acheter des inventaires ayant un mauvais cookie
- Etc…
Au-delà de la méconnaissance technique, le manque de transparence n’aide personne et même les plateformes peuvent en souffrir en termes de revenu et réputation. Il faut rappeler que même si un SSP et un DSP ont effectué une connexion via un protocole strict, au final la bid request ne contient que le cookie dans le champ buyeruid, sans détail sur la méthodologie et qui peut inquiéter éditeur, SSP et DSP en cas de problème…
Comment résoudre ce manque de transparence ?
Récemment, l’IAB Tech Lab a publié une mise à jour de l’OpenRTB 2.6 (OpenRTB version 2.6-202405) pour normaliser les mécanismes d’ID solutions dans la bid request avec le cookie matching. Les champs buyeruid (cookie tiers) et ifa (device id) font peau neuve avec de nouveaux champs (agent type, match methods, source…) pour couvrir des cas comme l’email, id probabiliste etc… L’idée est que l’éditeur avec l’aide du SSP, déclare le mécanisme qui a permis de créer l’ID placé dans la bid request.
C’est une victoire pour le DSP qui obtiendra plus de transparence pour tout ID reçu, mais d’un autre côté c’est clairement beaucoup de travail pour le SSP en raison du contrôle des éditeurs et surtout la déclaration en fonction de la sensibilité de chaque DSP… Cette mise à jour prend aussi en compte l’ID bridging et annonce peut-être la fin des champs historiques buyeruid et ifa de la bid request. Maintenant, entre la sortie finale de cette update et la mise en place des SSP et DSP qui veulent l’utiliser, beaucoup de temps peut s’écouler…
