Présentation et conseils du RGPD

Résoudre les problèmes liés à l'implémentation de la version 2.2 du TCF de l'IAB Europe

L'IAB a annoncé la version 2.2 de son TCF le 16 mai 2023. Depuis le 11 juillet 2023, Google (en tant que fournisseur) accepte les chaînes Transparency & Consent (TC) utilisant la version 2.2 du TCF. Toute demande incluant des chaînes de la version 2.2 du TCF envoyées avant cette date peut entraîner des erreurs.
  • Version 2.1 du TCF : nous continuerons à accepter les chaînes de la version 2.1 du TCF. Toutefois, nous encourageons les plates-formes de gestion du consentement (CMP, Consent Management Platform) à suivre les conseils de l'IAB sur les étapes d'implémentation à respecter lors de la transition vers la version 2.2 du TCF.
  • Solutions de gestion du consentement de Google : ces solutions, qui sont disponibles dans l'onglet "Confidentialité et messages" d'Ad Manager, d'AdSense et d'AdMob, devraient être compatibles avec la version 2.2 du TCF pour les messages de consentement sur le RGPD d'ici début novembre, conformément à la nouvelle date limite d'implémentation de l'IAB pour les CMP fixée au 20 novembre 2023.

L'IAB Europe a finalisé la version 2.0 de son Transparency and Consent Framework (TCF, Cadre de transparence et de consentement), développé conjointement avec l'IAB Tech Lab et des entreprises membres. Google est désormais entièrement compatible avec la version 2.0 du TCF.

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 de l'IAB Europe, Google leur fournira un rapport sur les erreurs détectées et leur accordera un délai de grâce de 150 jours pour résoudre les erreurs.


Cet article vous explique comment résoudre les erreurs d'implémentation de la version 2.2 du TCF :

 


Nouvelles consignes

Changements

  • Rappel concernant l'obligation d'obtenir le consentement tous les 13 mois conformément au TCF : 

    Conformément au Règlement du TCF de l'IAB, vous devez rappeler aux utilisateurs leurs choix de consentement au moins une fois tous les 13 mois (390 jours). Si la décision liée au consentement remonte à plus de 13 mois, la chaîne TC (Transparency & Consent) ne sera plus considérée comme valide par Google, et Google ne diffusera pas d'annonces auprès de cet utilisateur. Nous vous conseillons de contacter la personne chargée de votre PGC (plate-forme de gestion du consentement) afin de rappeler aux utilisateurs leurs choix de consentement avant que le délai de 13 mois soit écoulé.

  • Le type d'erreur 3.2 a été supprimé. Les chaînes Transparency & Consent (chaînes TC) mises à jour au cours des 13 derniers mois resteront valides.

Correction des erreurs courantes

Voici comment résoudre certaines des erreurs les plus courantes dans Ad Manager, AdSense et AdMob :

Redemandez le consentement des utilisateurs avec les chaînes TC non associées à la monétisation
(Erreurs 1.1, 3.1, 4.1, 5.1, 5.2 et 6.1)

Erreur(s) associée(s)

Erreur 1.1. Cette consigne peut également s'appliquer aux erreurs 3.1, 4.1, 5.1, 5.2 et 6.1.

Nouvelle consigne

Vous pouvez redemander le consentement des utilisateurs.

Explication

Les éditeurs peuvent redemander le consentement s'ils utilisaient précédemment des chaînes associées à un champ d'application externe ou global, des ID de plates-formes de gestion du consentement (CMP, Consent Management Platform) non valides (issus des tests), des ID de liste globale des fournisseurs (LGF) non valides (issus des tests), ou si les éditeurs ont omis Google comme fournisseur avec le consentement approprié au cours de l'implémentation.

Erreurs 1.1, 1.2, 1.3 : Il est important de vérifier si ces erreurs concernent un volume de trafic élevé. Si c'est le cas, il s'agit peut-être d'un problème au niveau de la CMP. De plus, assurez-vous que le consentement est accordé à Google pour les motifs nécessaires, et que Google est déclaré comme fournisseur pour le consentement ET l'intérêt légitime (ID de fournisseur : 755).

Spécification de l'IAB

Conformément aux spécifications de l'IAB, les CMP peuvent mettre en cache les chaînes de consentement pendant 13 mois.

Certaines CMP ont conservé la date du premier consentement et l'ont prolongé, ce qui n'est pas accepté. La date de consentement doit toujours correspondre à la dernière date d'une chaîne de consentement donnée.
Suggestion : Demandez à votre CMP de renvoyer les appels de AddEventHandler dans un délai de 500 ms
(Erreurs 2.1a, 2.1b, 2.0a, 2.0b et 2.0c)

Erreur(s) associée(s)

Erreur 2.1a. Cette consigne peut également s'appliquer aux erreurs 2.1b, 2.0a, 2.0b et 2.0c.

Nouvelle consigne

Même si nous n'imposons plus de délai avant expiration, nous conseillons aux CMP d'examiner attentivement leurs implémentations pour s'assurer qu'elles renvoient immédiatement les appels à AddEventListener getTCData.

Si une CMP ne répond pas, la demande risque de ne pas être monétisée.

Explication

Google respecte la spécification de l'IAB stipulant qu'une CMP doit répondre immédiatement à la fonction AddEventListener. Si une CMP ne répond pas immédiatement, la demande risque de ne pas être monétisée.

En outre, les réponses de la CMP font partie de la chaîne d'événements qui ont une incidence sur le délai requis avant d'effectuer une demande d'annonce. Si le délai entre le chargement de la page et les demandes d'annonces diminue, l'éditeur perd moins d'impressions.

Spécification de l'IAB

Spécification de l'IAB applicable : spécification AddEventListener (sur GitHub)

Le rappel AddEventListener doit être appelé immédiatement après l'enregistrement avec les données TC actuelles, même si l'état de la CMP indique loading (chargement) et si la CMP comporte des données TC incomplètes. Cela permet au script appelant d'accéder à son listenerId enregistré. De plus, le rappel doit être appelé lors de chaque modification d'une chaîne TC, sauf s'il est supprimé avec RemoveEventListener.

Centre d'informations sur les règles

Le Centre d'informations sur les règles avertit les éditeurs si une application ou un site ne respecte pas les exigences de Google concernant la gestion du consentement.

Rapport d'erreurs

Nous informerons les éditeurs dans l'interface utilisateur du produit si nous détectons un problème au niveau de la chaîne TC associée à un ou plusieurs de leurs sites ou applications. Sur la page "Consentement de l'utilisateur dans l'UE" de leur compte, les éditeurs ayant reçu des erreurs peuvent cliquer sur Télécharger le rapport d'erreurs du TCF afin de télécharger un rapport détaillé sur les erreurs détectées au cours des sept derniers jours.

Ce rapport n'est disponible que si des erreurs ont été détectées au cours des sept derniers jours.
Pour accéder à la page "Consentement de l'utilisateur dans l'UE" et au rapport d'erreurs du TCF : 
  • Ad Manager : cliquez sur Admin puis Consentement de l'utilisateur dans l'UE.
  • AdMob et AdSense : cliquez sur Paramètres de blocage puis Consentement de l'utilisateur dans l'UE.

Le rapport contiendra les informations suivantes pour chaque erreur détectée : 

  • Domaine/MobileAppID : site ou application mobile dont la configuration est incorrecte.
  • Chemin d'accès du bloc d'annonces : bloc d'annonces associé à l'erreur.
  • Code d'erreur : code attribué à l'erreur.
  • Nombre d'erreurs : nombre de requêtes contenant l'erreur détectées la semaine précédente.
  • Date de la dernière détection : date à laquelle l'erreur a été détectée pour la dernière fois. 

Les codes d'erreur répertoriés dans le rapport permettent aux éditeurs de rechercher les actions suggérées dans les tableaux de dépannage suivants et de corriger les erreurs.

Dépannage

Afin d'aider les éditeurs à résoudre les problèmes liés à une mauvaise configuration des intégrations de la version 2.2 du TCF de l'IAB, nous avons créé les tableaux suivants comprenant les erreurs de chaîne TC les plus courantes, ainsi que les recommandations de dépannage correspondantes.

Utilisez ces tableaux pour comprendre les problèmes qui se produisent au niveau des demandes d'annonces ainsi que le comportement système correspondant.

Scénarios de consentement limité

Ces trois scénarios prévalent toujours sur les erreurs de configuration, même si une demande donnée en comporte plusieurs.

Scénario Description Action suggérée
1.1 Google, en tant que fournisseur, n'est pas autorisé dans le cadre du consentement ou de l'intérêt légitime. Vérifiez si l'utilisateur a refusé intentionnellement Google en tant que fournisseur, si des erreurs d'implémentation de la CMP se sont produites ou s'il existe des restrictions applicables aux éditeurs.
1.2 Aucun consentement pour la première finalité pour les pays de l'EEE et le Royaume-Uni.

Vérifiez si l'utilisateur a refusé la première finalité intentionnellement ou si le problème est dû à des erreurs d'implémentation de la CMP.

Les éditeurs suisses doivent s'assurer de définir correctement les champs PublisherCC et PurposeOneTreatment s'ils ne demandent pas le consentement des utilisateurs. 
 

À compter de décembre 2021, nous ne vérifierons plus le champ SubjectOneTreatment dans les demandes d'annonces en provenance d'Allemagne, conformément à la loi allemande sur la protection des données des télécommunications et des télémédias.

1.3 Consentement obtenu pour la première finalité, mais absence de bases juridiques pour les annonces de base.

Vérifiez si l'utilisateur a refusé intentionnellement les intérêts légitimes pour les autres finalités ou si le problème est dû à des erreurs d'implémentation de la CMP.

Erreurs de configuration

Les demandes d'annonces ne sont pas satisfaites tant qu'il existe des erreurs de configuration.

Erreur Description Action suggérée
2.1a Le tag ou le SDK ne reçoit pas de chaîne TC, car l'état de la CMP correspond à stub, loading ou error.

Si vous appelez manuellement la fonction pour demander des annonces, assurez-vous que la réponse est la suivante : getTCData TCData.eventStatus = 'tcloaded' OU 'cmpuishown' + 'useractioncomplete'. Ces valeurs indiquent que la CMP est prête à proposer à l'utilisateur plusieurs options de consentement.

Si vous n'appelez pas manuellement la fonction pour demander des annonces, assurez-vous que votre CMP prend en charge la commande getTCData en renvoyant TCData.eventStatus = 'tcloaded' OU 'cmpuishown' + 'useractioncomplete' pour indiquer que le consentement de l'utilisateur est prêt à être utilisé via l'API.

2.1b

Les deux conditions suivantes sont remplies :

  • Les CMP ont défini &gdpr=1.
  • La demande contient &gdpr_consent=, mais la chaîne TC est vide.
Demandez à votre CMP de s'assurer que ses API sont correctement implémentées selon les spécifications techniques du TCF de l'IAB.
2.0a

Impossible d'analyser la chaîne TC, car elle n'est pas encodée au format base64.

Exemple : “2”

Les CMP (ou les éditeurs) ne doivent envoyer que des données encodées au format base64 dans les paramètres gdpr_consent=.
2.0b

Impossible d'analyser la chaîne TC en raison d'une erreur de décodage.

Exemple : la chaîne inclut un nombre incorrect d'octets

La CMP doit résoudre les erreurs d'implémentation de la chaîne TC.
2.0c

Impossible d'analyser la chaîne TC en raison d'une erreur liée aux données.

Exemple : codes temporels incorrects, l'ID du fournisseur est trop long
 

La CMP doit résoudre les erreurs d'implémentation de la chaîne TC.

Problèmes liés à la chaîne TC

La chaîne TC associée à une demande d'annonce pose problème. Les demandes d'annonces sont refusées et non satisfaites.

Erreur Description Action suggérée
3.1 L'ID de la CMP n'est pas valide.

Vérifiez qu'une CMP validée par l'IAB est utilisée et que son ID est correctement défini dans les chaînes TC.

Si une CMP était valide au moment où une chaîne TC a été générée, mais qu'elle a par la suite été supprimée par l'IAB, vous devez de nouveau obtenir le consentement des utilisateurs à l'aide d'une CMP valide.

3.2 Ce scénario n'est plus utilisé. Aucune. Signification précédente : la chaîne TC a été créée il y a plus de 13 mois.

Vous devez de nouveau obtenir le consentement

Vous devez obtenir le consentement de l'utilisateur. Si vous avez obtenu le consentement d'un utilisateur il y a plus de 13 mois ou que vous utilisez une version de la LGF dans laquelle Google ne figurait pas encore, vous devez l'obtenir de nouveau. Dans le cas contraire, les demandes d'annonces seront refusées et non satisfaites.

Erreur Description Action suggérée
3.3 La chaîne TC a été mise à jour il y a plus de 13 mois.

La CMP doit supprimer l'ancienne chaîne TC et obtenir de nouveau le consentement de l'utilisateur.

Un faible nombre de ces erreurs sont susceptibles de se produire si les demandes d'annonces sont envoyées avec une chaîne TC expirée avant que la CMP ne l'ait invalidée et obtenu à nouveau le consentement de l'utilisateur.

Si vous utilisez les solutions de gestion du consentement Google et le SDK UMP dans votre application, vérifiez que le SDK UMP a été correctement implémenté et que requestConsentInfoUpdate est appelé à chaque démarrage de l'application.

4.1 La chaîne TC a été générée à l'aide d'une version de la LGF dans laquelle Google ne figurait pas encore. Obtenez de nouveau le consentement à l'aide d'une version actuelle de la LGF.

Champ d'application global et externe

Il s'agit des problèmes liés au champ d'application global et externe (Ad Manager, AdMob, AdSense). Les annonces ne seront pas diffusées si la chaîne TC indique "Externe" ou "Champ d'application global".

Erreur Description Action suggérée
5.1 La chaîne TC autorise le consentement externe. Demandez à votre CMP de supprimer les signaux externes des chaînes TC.
5.2 La chaîne TC est associée à un champ d'application global. Demandez à votre CMP de mettre à jour les chaînes TC de sorte qu'elles soient spécifiques aux services.

Diffusion limitée des annonces

Des annonces limitées seront diffusées.

Erreur Description Action suggérée
6.1 La version de la chaîne TC correspond à la version 1 ou 1.1 (chaîne de la version 1.0). La CMP doit envoyer des chaînes correspondant à la version 2.2 du TCF.

Google traitera les problèmes

Lorsque de tels problèmes se produisent, Google applique lui-même un correctif si nécessaire et continue de gérer le TCF normalement.

Erreur Description Action suggérée
7.1 L'option gdprApplies n'est pas définie, ou est définie sur une valeur non valide ou indéchiffrable, mais une chaîne TC valide est présente. N/A
7.2 La chaîne TC a été générée avec une version de la LGF plus récente que celle actuellement utilisée par la technologie de diffusion d'annonces de Google. N/A
7.3 Certaines finalités, certaines fonctionnalités et/ou certains fournisseurs sont hors de portée (inconnus). N/A
7.4 La version tcf_policy_version associée à la chaîne TC est plus ancienne que celle associée à la LGF. La CMP doit supprimer la chaîne TC plus ancienne et de nouveau obtenir le consentement des utilisateurs à l'aide de la dernière version de la LGF.
7.5

Une demande comporte l'option &gdpr=1, mais pas le paramètre &gdpr_consent dans l'URL de demande.

N/A
7.6 Le code pays de l'éditeur n'est pas valide, mais le consentement pour la première finalité a été obtenu.  La CMP doit résoudre les erreurs d'implémentation de la chaîne TC.
7.7 Le code de langue n'est pas valide. La CMP doit résoudre les erreurs d'implémentation de la chaîne TC.
7.8 Le champ correspondant à la version de la chaîne TC n'est défini ni sur 1, ni sur 2.

La CMP doit résoudre les erreurs d'implémentation de la chaîne TC en demandant un nouveau consentement si une chaîne TC non valide est détectée.

Si vous utilisez les solutions de gestion du consentement Google et le SDK UMP dans votre application, vérifiez que le SDK UMP a été correctement implémenté et que requestConsentInfoUpdate est appelé à chaque démarrage de l'application.

7.9 La version de la chaîne AC n'est définie ni sur 1, ni sur 2. La CMP doit définir la version de la chaîne AC sur 1 ou 2.

Problèmes liés à la chaîne AC

Lorsque ces types de problèmes se produisent, Google traite la chaîne de consentement supplémentaire (AC) comme non valide, et aucun fournisseur supplémentaire n'est considéré au-delà de la chaîne TC.

Erreur Description Action suggérée
8.1 La chaîne AC n'utilise pas le séparateur de version (~). La CMP doit utiliser le signe "~" comme deuxième caractère de la chaîne AC pour séparer le numéro de version de la liste des fournisseurs autorisés.
8.2 La chaîne AC contient une liste de fournisseurs qui ne respecte pas le format attendu (liste composée de valeurs de type int64 séparées par "."). La CMP doit résoudre les erreurs liées à la chaîne AC.

 

Ces informations vous-ont elles été utiles ?

Comment pouvons-nous l'améliorer ?
true
Notes de version

Découvrez les dernières fonctionnalités d'Ad Manager et les mises à jour du centre d'aide.

Nouveautés

Recherche
Effacer la recherche
Fermer le champ de recherche
Menu principal
10192768202267749021
true
Rechercher dans le centre d'aide
true
true
true
true
true
148
false
false