TCF v2 & Erreurs Google 1.1/2.1a
A qui la faute ?
Edit du 25/09/2020 : nous avons constaté ce jour un changement majeur dans le fonctionnement des tags AdSense : lors de nos tests le chargement de la CMP n’est désormais plus soumis à un timeout qui conduisait à des erreurs 2.1a. Sirdata remercie vivement les équipes Google d’avoir tenu compte de cette demande de correction. Communication officielle
Google prend désormais part au Transparency & Consent Framework v2.0 de l'IAB Europe, la solution d'aide à la conformité à ePrivacy et au RGPD, et annonce respecter ses Règles et spécifications.
Nous en sommes heureux car Google fait partie de nos partenaires privilégiés et que nous faisons nous-mêmes partie du TCF depuis l'origine. Sirdata est enregistrée comme Vendor (ID 53) et comme CMP (ID 92) depuis le lancement du standard.
Google diffuse et transmet la chaîne de TC (TC String) pour toutes les demandes d'annonces depuis la mi-août 2020 et a produit des consignes d'interopérabilité qui visent à satisfaire les exigences actuelles des règles de Google, en particulier celles des Règles de Google relatives au consentement de l'utilisateur dans l'UE et de ses règles interdisant la récupération de l'empreinte numérique à des fins d'identification (par exemple, celles contenues dans ses Conditions requises pour la diffusion d'annonces par des tiers).
Afin de laisser aux éditeurs le temps de gérer les erreurs et les mauvaises configurations liées au lancement du Transparency & Consent Framework v2.0, Google produit des rapports d'erreurs détectées et autorise un délai de grâce de 90 jours pour résoudre les erreurs.
C'est dans ce cadre qu'à notre connaisance, de nombreux éditeurs utilisant une CMP compatible avec le TCF v2 ont reçu des alertes de la part de Google dans leur console AdSense et ou Ad Manager.
Malgré la qualité de nos solutions, nos partenaires n'ont pas été épargnés. Dans la plupart des cas, il s'agit des alertes 1.1 et 2.1a que nous étudions ci-dessous :
I- Erreur 1.1
Selon la documentation Google, les erreurs de classe 1 empêchent toujours la diffusion d'annonces en réponse aux demandes et ne donnent lieu à aucun délai de grâce.
Ces erreurs prévalent toujours sur les autres types d'erreur, même si une requête donnée en comporte plusieurs.
Voici la définition de l'erreur 1.1 et des erreurs proches :
L'"erreur" 1.1 survient lorsque les tags publicitaires de Google sont appelés sans (avant) que l'utilisateur ait donné son consentement pour Google en tant que Vendor (ID 755 dans le TCF).
Cela peut résulter :
- D'une non-présentation de Google comme partenaire de l'éditeur dans la CMP (Vendor)
- D'un choix de l'utilisateur de rejeter le Vendor Google
Lorsqu'un site charge un script AdSense (adsbygoogle.js) sans consentement pour Google (Vendor ID 755 dans le TCF), il contrevient aux Règles de Google relatives au consentement de l'utilisateur dans l'UE, qui imposent le recueil du consentement pour les cookies et pour le traitement de données personnelles par Google et ses partenaires, permettant de servir des publicités personnalisées ou non.
En revanche, il ne s'agit pas d'une erreur d'intégration de la CMP mais d'un problème de conditionnement des tags publicitaires de Google.
Google reconnaît, à propos des CMP, que ce type de "solutions peuvent être configurées de différentes façons..." et qu'"il est important de noter que de telles configurations ne contrôlent pas automatiquement la collecte de données ou les cookies."
Le TCF est architecturé sur le principe de Privacy by Design et permet un conditionnement à toutes les étapes par chaque acteur concerné : un Vendor a la faculté de requêter l'API de la CMP pour déterminer son statut de consentement et doit agir en conséquence. Le conditionnement de chargement des tags est une bonne méthode, mais le conditionnement de fonctionnement de ces mêmes tags par eux-mêmes est beaucoup plus sûr.
C'est pourquoi le TCF n'exige pas d'un éditeur de site (Publisher) qu'il conditionne les appels les tags, mais qu'il mette via sa CMP un signal à la disposition de chaque Vendor pour lui permettre de contrôler ce qu'il peut faire ou non et agisse en conséquence.
Les Policies du TCF précisent en effet :
Le TCF requiert que les éditeurs permettent à chaque Vendor de contrôler son statut grâce à la TC String ("tcString") obtenue auprès de l'API de la CMP ou via un Vendor en amont qui lui-même l'a obtenue auprès de la CMP, et ainsi de suite.
De même, grâce à cette TC String, un Vendor pourra contrôler le statut d'un autre Vendor en aval pour déterminer s'il bénéficie d'un consentement pour les traceurs et d'une base légale établie pour la finalité poursuivie avant de lui transmettre une donnée.
C'est ce que fait Google lorsqu'il décode la TC String pour déterminer à quels partenaires il va transmettre une bid request : il n'enverra par exemple aucune donnée à un partenaire qui ne bénéficie pas du consentement pour les cookies en France.
Nous nous sommes intéressés au fonctionnement des scripts de Google... Afin d'activer AdSense sur son site un éditeur doit charger le script suivant :
Pour intégrer la demande relative au consentement de Google, nous avons, avec nos partenaires, suivi les exemples de code d'annonce de la section de l'aide Google relative à ses Règles relatives au consentement de l'utilisateur dans l'Union européenne :
Nous avons implémenté ces recommandations et lançons automatiquement la commande suivante à l'initialisation de la CMP, pour mettre en pause AdSense avant de finir de charger la CMP et interagir avec l'utilisateur si nécessaire :
Puis, une fois la CMP chargée et les choix de l'utilisateur établis, nous lançons la commande suivante pour permettre à Google de récupérer le signal de consentement conformément aux spécifications du TCF :
Malgré cette mise en pause et sans information de consentement donnée par la CMP, le script adsbygoogle.js va charger d'autres scripts lui permettant d'accéder à ses cookies publicitaires :
Ce dernier script interagit précisément avec la CMP afin de récupérer le statut de choix de l'utilisateur et vérifier que ce dernier a bien donné son consentement au moins à Google (TCF Vendor ID 755) et au moins au dépôt des cookies (Purpose 1 du TCF).
Voici la fonction grâce à laquelle Google utilise l'information récupérée auprès de la CMP :
et où la fonction Gy est définie ainsi :
Comprendre :
- Si tcData n'existe pas (gestion du consentement hors TCF) la publicité est servie
- Si le RGPD ne s'applique pas (utilisateur non localisé en Europe par exemple) la publicité est servie
- Si la TC String est égale à "tcunavailable" la publicité est servie
- Si l'utilisateur a donné son consentement au Vendor 755 ET à la Purpose 1 (OU bien si la Purpose 1 n'est pas obligatoire selon l'éditeur et que ce dernier est en Allemagne) la publicité est servie
Alors l'URL d'appel de la bannière est construite et comporte différentes variables dont potentiellement gdpr (1 ou 0 suivant que l'utilisateur est soumis au RGPD ou non), gdpr_consent (la TC String, si gdpr=1), et tcfe (le code erreur de Google) le cas échéant :
S'il n'y a pas d'erreur et que le test de consentement pour Google et les cookies est positif alors ce script déclenche l'appel publicitaire via une url de ce type :
La réponse comporte alors le code bannière.
Dans cet appel, on retrouve :
- Le paramètre gdpr qui doit être égal à 1 pour un utilisateur localisé en Europe
- Le paramètre gdpr_consent qui est la forme encodée des choix effectués par l'utilisateur. La valeur est appelée la TC String et peut être décodée sur le site https://iabtcf.com/#/decode
S'il n'y a pas d'erreur et que le test de consentement pour Google et les cookies est négatif alors ce script déclenche l'appel publicitaire via une url de ce type :
Cet appel n'obtient pas de code bannière en réponse.
La différence entre les deux appels se situe notamment dans la TC String que Google reçoit dans le paramètre gdpr_consent et qui, une fois décodée, lui indiquera dans le premier cas qu'il a le consentement pour les cookies, mais pas dans le deuxième.
Dans le premier cas, il y aura une réponse :
Mais pas dans le deuxième :
Il convient de noter que, dans les deux cas, l'appel de bannière qui est initié par le script show_ads_impl_fy2019.js donne accès à Google à ses cookies :
A ce titre, Google réalise ce traitement sans justifier d'un consentement préalable pour les cookies dans le TCF, et ne peut s'appuyer sur la Special Purpose 1 (Ensure security, prevent fraud, and debug) pour se prévaloir d'une base légale.
Le script adsbygoogle.js intégré par l'éditeur va donc déclencher l'insertion d'un second script qui va permettre d'opérer les contrôles dans le cadre du TCF : si le test sur son ID (755) ou encore celui sur la Purpose 1 échouent alors ce script de Google détecte l'absence de consentement... Et déclenche malgré tout l'appel d'un troisième tag qui comporte des traceurs et des données personnelles.
Bien que la réponse soit vide, l'appel en lui-même est problématique : même si Google veut se réfugier derrière l'obligation qu'il impose à l'éditeur de recueillir un consentement avant d'intégrer le premier script (adsbygoogle.js), il ne peut ignorer que l'utilisateur n'a pas donné son accord lors de l'exécution du second.
En initiant les appels de cette manière pour a minima loguer et déclarer par la suite des erreurs de classe 1, nous pensons que Google n'a pas correctement mis en place les mesures d'Accountability qui s'imposent.
En déployant une CMP compatible avec le TCF v2 et en travaillant avec des Vendors qui s'engagent à respecter les signaux, les éditeurs font un effort de conditionnement et de conformité.
Le fait que le script de Google ignore l'issue du test côté client et déclenche le dernier appel malgré le signal reçu d'absence de consentement n'est pas conforme aux Policies du TCF selon nous. Google maîtrise pourtant ce type de conditionnement puisqu'il le met en oeuvre dans le cadre de son propre programme Google Consent Mode qu'il a lancé le 3 septembre 2020. Pur hasard de calendrier...
D'un point de vue contractuel, les erreurs 1.1 sont imputables à l'éditeur qui ne conditionnent pas ses tags et appelle Google sans consentement, et ce indépendamment du TCF et de l'implémentation de notre CMP.
En théorie, un tel conditionnement suffit à faire disparaître l'erreur 1.1... Dans la pratique, il existe malheureusement des situations que l'éditeur ne maîtrise pas et qui perturbent le conditionnement des tags adsbygoogle.js ou gpt.js : il suffit qu'un script tiers injecte un de ces deux tags sur la page et cela déclenche les appels de publicité de manière incontrôlée malgré l'effort de l'éditeur.
Pour toutes ces raisons, nous pensons raisonnablement que Google ne respecte pas les Policies du TCF en déclenchant ses tags d'appels bannières alors même que la CMP lui indique qu'il ne bénéficie pas du consentement nécessaire.
Si Google veut logguer les implémentations de ses tags sans consentement, nous suggérons qu'ils ne traitent aucune donnée personnelle dans le même temps et utilisent pour ce faire des tags sur un domaine distinct de ses activités publicitaires et qui n'emporte pas de cookies.
Nous sommes heureux clients et utilisateurs satisfaits de nombreux services de la galaxie Google (moteur de recherche, suite Google Pro, Google Cloud, Marketing Suite...). Dans tous ces domaines et en particulier dans la publicité digitale, Google propose une technologie parmi les meilleures au monde et semble placer l'efficacité au dessus de tout.
Dans nos propres développements, nous priorisons l'intérêt de l'utilisateur. Ce qui nous confère une certaine habileté dans la compréhension et la mise en œuvre des interactions entre technologie et vie privée. Nous aurions apprécié être informés de ces protocoles de tests que nous jugeons mal formulés lorsque nous avons préparé l'arrivée de Google à l'occasion de la transition vers la v2 du TCF.
Nous serions heureux d'aider Google à clarifier la documentation et les messages d'erreur communiqués aux éditeurs pour apporter une plus grande transparence sur les responsabilités de chacun.
En effet, malgré l'effort rédactionnel de Google et la densité d'informations produites sur le consentement, nous pensons donc que les éditeurs n'ont pas pleinement conscience de ce qu'attend Google.
Ils ne semblent pas tous percevoir non plus la portée des changements réglementaires et l'articulation des différentes lois (Informatique et Libertés par exemple), Directives (ePrivacy...) et Réglements (RGPD...).
A défaut de comprendre, le réflexe est en général de reproduire ce que font les leaders de l'Adtech sur leurs propres actifs et c'est ainsi qu'ils peuvent s'inspirer du moteur de recherche de Google qui affiche à un nouvel Internaute une page de résultats de ce type :
En plus des résultats de sa recherche, l'Internaute se voit afficher :
- Un message d'information lui expliquant que Google a recours à des cookies et l'invite à les accepter
- Des publicités ("annonces")
Une rapide consultation de la console permet de constater que des cookies ont été déposés au chargement de la page sans que l'Utilisateur ait cliqué sur le bouton "J'accepte", et en particulier les cookie NID et ANID sur le domaine google.com :
Ces cookies servent, selon les Règles de confidentialité et conditions d'utilisation de Google, notamment à enregistrer les recherches effectuées par les internautes sur le site de Google et leurs visites sur le site Web d'un annonceur afin de leur afficher par la suite des annonces personnalisées sur Google :
D'autres cookies sont déposés, dont l'un est nommé "CONSENT" et prend, au premier chargement de la page (avant les messages de consentement de Google) dans notre test, la valeur suivante :
Puis une fois le consentement donné sa valeur change pour "YES" :
Des cookies publicitaires ou pouvant servir à de la publicité sont déposés sans (avant) que l'utilisateur ait donné son consentement à Google, ce qui correspond selon nous à la définition de l'erreur 1.1.
Nous sommes convaincus que les méthodes et outils de Google sont respectueux de la vie privée et du cadre réglementaire. Mais nous comprenons que des éditeurs à qui Google demande de ne pas procéder de la sorte et à qui ces "erreurs" sont reprochées soient perplexes voire perdus.
Google ne devrait pas, selon nous, se contenter de demander le recueil du consentement préalable à l'utilisation de ses tags publicitaires à ses partenaires éditeurs. Il serait plus prudent d'implémenter intégralement le TCF, et ses méthodes, et ainsi conditionner les appels finaux de bannières en fonction des choix des Internautes, et ce même si les scripts initiaux sont injectés systématiquement, par erreur ou par mimétisme...
II- Erreur 2.1a
Selon la documentation Google les erreurs de classe 2 sont liées au délai de grâce 0 qui s'applique comme suit : Pendant les 30 premiers jours du délai de grâce, les éditeurs pourront résoudre les problèmes de mauvaise configuration sans conséquence sur la monétisation.
Pendant les 60 jours restants du délai de grâce, des annonces non personnalisées seront diffusées, quels que soient les paramètres des annonces personnalisées et non personnalisées existantes.
Une fois le délai de grâce écoulé, aucune annonce ne sera diffusée en réponse aux demandes d'annonces.
Pour comprendre ce code erreur, il faut prendre connaissance du fonctionnement du TCF et en particulier des statuts possibles de la CMP :
Lors d'une séquence de chargement correcte le statut (cmpStatus) de la CMP doit donc débuter à "stub" lorsqu'elle est initiée, passer à "loading" (bientôt déprécié) lorsqu'elle charge, et enfin à "loaded" une fois chargée.
Si pour une raison ou une autre, elle connaît un problème au chargement ou après, alors, cmpStatus sera défini à "error".
Ainsi avec l'erreur 2.1a, Google informe les éditeurs du nombre de fois :
- Où la CMP a été en erreur
- Où la CMP est restée bloquée à l'initialisation
- Où la CMP est restée bloquée lors du chargement
Pour certains éditeurs, le nombre d'erreurs était cependant très élevé, beaucoup plus élevé que les taux d'erreurs ou de blocages mesurés lors de nos tests.
Nous avons donc investigué plus avant et isolé deux problèmes fondamentaux : le premier est lié aux tags de Google et le second à des tags de tiers.
1) Implémentation par Google du TCF
Les tags de Google ont été adaptés comme expliqué ci-dessus afin de décoder les signaux du TCF (prioritaires sur les autres signaux de Google sauf si plus permissifs).
Il ressort de nos investigations que Google a semblé préférer l'efficacité au respect du choix de l'utilisateur en paramétrant un timeout de 500 millisecondes pour le chargement de la CMP parmi tous les scripts de la page : au bout de ce délai, le script mentionné au premier point (adsbygoogle.js) coupe le processus et renvoie l'erreur tcfe=1 et la valeur "tcunavailable" pour le paramètre gdpr_consent.
Ce timeout n'est pas le délai accordé à la CMP seule mais à tous les scripts qui s'exécutent dans la fenêtre accordée de 500 millisecondes, ce qui est trop peu, et chaque chargement de CMP interrompu est comptabilisé comme une erreur 2.1a par Google.
Nous pensons que le timeout est à l'origine de l'essentiel des erreurs qui constituent cette classe et que notre CMP n'est pas en erreur dans la plupart des cas rapportés.
Le problème est que les serveurs de Google qui reçoivent cet appel ne liront pas les signaux de consentement mais l'information "tcunavailable", la réponse peut comporter une publicité.
Lors de nos tests, nous avons vu des bannières qui ont recours à des cookies et de la donnée personnelle :
Un clic sur l'icône d'information ne laisse pas de place au doute : les publicités sont personnalisées.
Cela correspond à l'explication fournie par Google : "durant la période de grâce malgré cette erreur 2.1a des publicités personnalisées seront affichées pendant 30 jours, puis des publicités non personnalisées durant encore 60 jours".
Du point de vue de l'éditeur et pour Google l'effort est louable : les revenus de chacun sont maintenus au moins en grande partie. Mais du point de vue de l'Internaute, c'est plus problématique : lors de nos tests, toutes ces publicités personnalisées ont été affichées alors que nous avions refusé au préalable les cookies et tous les Vendors dont Google.
Des Fournisseurs de technologie publicitaire partenaires de Google sont également susceptibles d'avoir reçu et traité de la donnée personnelle malgré eux.
Le script de Google n'attend pas la fin du chargement et l'eventStatus "tcloaded" à cause de l'atteinte du timeout. Pour cette raison il ne reçoit pas systématiquement le signal de la CMP ni la TC String correspondante mais utilise malgré tout ses traceurs et de la donnée personnelle. Donc potentiellement sans consentement voire malgré un refus comme dans nos tests.
Compte tenu des statistiques habituelles, on peut estimer que 10 à 15% des erreurs 2.1a comptabilisées au global ont masqué des refus et permis de déclencher à tort une publicité ciblée. Compte tenu du poids de Google dans la publicité en ligne (2 millions d'éditeurs adhérents), même si tous n'ont pas encore implémenté une CMP compatible TCF v2, cela représente probablement des centaines de millions voire des milliards d'impressions !
Nous estimons donc qu'en l'état ce timeout peut représenter un danger très important pour le respect de la Vie Privée.
Nous estimons également qu'en interrompant le processus avant le chargement de la CMP et en ne recevant ainsi pas le statut de consentement, Google ne respecte pas les Policies du TCF et en particulier ces articles :
2) Les tags de tiers
Le second problème est lié à des tags tiers sur les pages (ni un tag de l'éditeur, ni la CMP, ni Google) qui perturbent voir corrompent le fonctionnement du TCF. Beaucoup de petites erreurs vont déclencher des latences mais dans certains cas c'est plus grave : l'API de la CMP est écrasée par un API fictive qui vient modifier ou générer des signaux de consentement.
III- Impacts business et évolution
Suggestion aux éditeurs
Beaucoup d'éditeurs échangent entre eux et avec nous au sujet des règles relatives à la vie privée. Non que Google n'a pas informé qu'il est nécessaire de recueillir un consentement pour les cookies et Google préalablement à toute invocation de leurs tags publicitaires, mais plutôt que la façon dont l'information a été rédigée et mise à disposition des éditeurs ne leur a pas permis d'appréhender correctement leurs obligations.
Le marché se trouve actuellement dans une temporalité particulière : de nombreux éditeurs qui ont, à tort ou involontairement, invoqué ces dernières années des publicités personnalisées et basées sur des cookies pour 100% de leur trafic découvrent qu'il faut s'équiper d'outils ou de mesures de conformité et que l'impact économique est très important.
Des baisses de 10% à 50% des revenus nous sont communiquées.
Ainsi de nombreux éditeurs qui n'ont finalement pas le sentiment de devoir impérativement mettre en oeuvre ces dispositifs sont tentés de continuer à invoquer systématiquement les tags publicitaires ciblés, voire de revenir en arrière après avoir déployé une CMP par exemple.
Ce serait une grave erreur, et nous suggérons aux éditeurs qui y songent d'oublier cette idée et d'accepter de perdre une partie de leurs revenus aujourd'hui plutôt que la totalité demain.
En effet avec la publication prochaine par la CNIL de sa nouvelle Recommandation Traceurs nous entrons dans une nouvelle ère de contrôles. Le dépôt de cookies sans consentement est visible dans la console des navigateurs sans aucun logiciel additionnel nécessaire et expose particulièrement les acteurs en cause, c'est-à-dire les Responsables de Traitements.
Dans la relation qui lie Google aux éditeurs, Google semble être la plupart du temps (co-)Responsable de Traitement, ce qui signifie qu'en cas de contrôle CNIL l'éditeur qui permet à Google de déposer des cookies sera inquiété mais Google aussi.
Nous pensons qu'à l'évidence Google ne peut pas prendre un tel risque et va mettre en place des mesures pour éviter un tel scénario. Dans l'information que Google délivre aux Internautes une mention apparaît d'ailleurs :
Google annonce fermer unilatéralement des centaines de milliers de comptes qui, entre autres, utilisent de façon abusive les informations personnelles des Internautes.
Il serait très facile de détecter quels éditeurs ne respectent pas les règles, et les plus exposés selon nous, sont ceux qui utilisent à la fois les outils publicitaires et les outils d'analytics.
Retrouvez l'article de Mind Media à ce sujet :