Au sommaire de cet article
- Composants du consentement supplémentaire
- Le format de la chaîne "Consentement supplémentaire" (AC)
- CMP compatibles avec le consentement supplémentaire
- Extension vers l'API CMP
- Comment stocker une chaîne AC ?
- Procédure de transfert de la chaîne AC via la chaîne de publicité digitale
- Ressources associées
Ce document définit une spécification technique (appelée "Consentement supplémentaire") destinée uniquement à être utilisée avec la version 2 du Transparency & Consent Framework (TCF) de l'IAB Europe. Elle vous permettra d'envoyer des signaux de transparence et/ou de consentement aux fournisseurs qui ne figurent pas encore sur la liste globale des fournisseurs (LGF) de l'IAB Europe. Grâce à cette spécification, les éditeurs, les plates-formes de gestion du consentement (CMP) et les partenaires peuvent obtenir le consentement supplémentaire des utilisateurs, et le transférer (en plus de leur implémentation du TCF) aux entreprises qui ne figurent pas encore sur la liste globale des fournisseurs de l'IAB Europe, mais qui sont présentes sur la liste des fournisseurs de technologie publicitaire de Google.
Composants du consentement supplémentaire
Dans ce mode, nous acceptons les éléments suivants :
- La chaîne Transparency & Consent (chaîne TC) telle que définie dans les spécifications de la version 2.2 du TCF de l'IAB, qui contient les informations de transparence et de consentement établies pour les fournisseurs figurant sur la LGF de l'IAB
- Une chaîne
addtl_consentsimple (chaîne AC), contenant une liste de fournisseurs de technologie publicitaire de Google autorisés et/ou publiés, et qui ne sont pas enregistrés auprès de l'IAB
Cette spécification définit les éléments suivants :
-
Le format de la chaîne AC
-
L'extension de l'API CMP pour la version 2.2 du TCF compatible avec la chaîne AC et les commandes requises lorsque le TCF et le mode Consentement de l'annonceur sont présents.
-
Les modalités de stockage d'une chaîne AC
-
La procédure de transfert de la chaîne AC via la chaîne de publicité digitale
Le format de la chaîne "Consentement supplémentaire" (AC)
Quelles sont les informations stockées dans une chaîne AC ?
Une chaîne AC contient les composants suivants :
-
Partie 1 : un numéro de version de la spécification tel que "
2" -
Partie 2 : un symbole de séparation "
~" -
Partie 3 : une liste d'ID de fournisseurs de technologie publicitaire de Google pour lesquels l'utilisateur a donné son consentement, séparés par un point (exemple : "
1.35.41.101") -
Partie 4 : un symbole de séparation "
~" -
Partie 5 : "dv." suivi d'une liste d'ID de fournisseurs de technologie publicitaire de Google, séparés par un point (exemple : "
dv.9.21.81")Les fournisseurs inclus dans la partie 3 ne doivent pas être inclus dans la partie 5 afin de réduire la longueur des chaînes.
Exemple de chaîne AC
La chaîne AC 2~1.35.41.101~dv.9.21.81 signifie que l'utilisateur a donné son consentement aux fournisseurs de technologie publicitaire associés aux ID 1, 35, 41 et 101. Les fournisseurs de technologie publicitaire associés aux ID 9, 21 et 81 ont été divulgués à l'utilisateur. La chaîne est alors créée dans le format défini dans la version 2 de la spécification.
Qui doit créer une chaîne AC ?
Seule une CMP enregistrée auprès d'un TCF de l'IAB Europe peut créer une chaîne AC en utilisant l'ID qui lui a été attribué, conformément aux Règles de l'IAB. Les fournisseurs ou autres fournisseurs de services tiers ne doivent pas créer de chaînes AC eux-mêmes.
Où sera publiée la liste des fournisseurs de technologie publicitaire de Google ?
Google publiera la liste des fournisseurs de technologie publicitaire qui ne sont pas enregistrés auprès de l'IAB ainsi que leur ID à l'adresse suivante :
https://storage.googleapis.com/tcfac/additional-consent-providers.csv
Quand créer une chaîne AC ?
Une chaîne AC ne peut être créée que si l'éditeur respecte les Règles de Google relatives au consentement de l'utilisateur dans l'UE.
Les fournisseurs autorisés ne doivent être inclus que si l'utilisateur a donné son consentement légalement valable pour :
-
l'utilisation de cookies ou de toute autre méthode de stockage en local, lorsque la législation l'impose ; et
-
la collecte, le partage et l'utilisation de données à caractère personnel pour la personnalisation des annonces par un fournisseur de technologie publicitaire, ainsi que pour respecter toutes les autres conditions des règles de Google relatives au consentement de l'utilisateur dans l'UE.
Les fournisseurs divulgués ne doivent être inclus que s'ils font preuve de transparence auprès des utilisateurs concernant l'identité de chaque fournisseur de technologie publicitaire. Ils doivent entre autres fournir un lien vers les règles de confidentialité de ces fournisseurs, telles que fournies dans la liste des fournisseurs de technologie publicitaire de Google. Les fournisseurs inclus dans la liste des fournisseurs autorisés ne doivent pas nécessairement figurer dans la liste des fournisseurs divulgués.
Une chaîne AC ne doit être créée que comme chaîne complémentaire à la chaîne TC, et non à la place de celle-ci. Google ne traitera pas la demande et supprimera la chaîne AC d'une demande reçue par Google si aucune chaîne TC n'est disponible pour la demande concernée.
Les CMP qui utilisent cette spécification doivent s'assurer que la chaîne AC qu'ils créent contient uniquement les ID du fichier publié de fournisseurs de technologie publicitaire de Google (fournisseurs ne figurant pas sur la LGF). Lorsque Google reçoit une chaîne TC, il vérifie la version de la LGF qui y est indiquée. Si un fournisseur figure dans cette version de la LGF, les vérifications de la chaîne TC ainsi que toutes les entrées de chaîne AC sont ignorées pour ce fournisseur. Dans ce cas, Google se réserve le droit de supprimer les entrées "en double" de la chaîne AC et de transmettre la chaîne AC modifiée avec la chaîne TC. Les fournisseurs autres que Google ne peuvent pas modifier la chaîne AC.
Modifications apportées à la version 2 de la spécification sur le consentement supplémentaire
Depuis décembre 2023, Google accepte la version 2 de la spécification sur le consentement supplémentaire. Voici les principales modifications apportées :
- Modification de la chaîne de consentement supplémentaire (AC), pour prendre en charge les fournisseurs indiqués dans la CMP.
- Modification de l'API CMP afin de permettre l'interopérabilité des CMP qui acceptent à la fois le TCF et le mode Consentement des annonceurs.
CMP certifiées prenant en charge le Consentement supplémentaire
Cette liste inclut les plates-formes de gestion du consentement (CMP, Consent Management Platform) certifiées qui prennent en charge la spécification technique de Google "Consentement supplémentaire", en plus de la version de consentement supplémentaire qu'elles prennent en charge.
Si vous êtes une CMP qui prend en charge le Consentement supplémentaire et que (1) vous ne figurez pas dans cette liste ou que (2) la version du Consentement supplémentaire indiquée n'est pas la bonne, veuillez accéder au formulaire d'inscription pour les CMP et sélectionner le type de demande "Je souhaite poser une question ou modifier mon état". Nous ferons tout notre possible pour mettre à jour la liste afin qu'elle reflète votre état dans les plus brefs délais.
Guide des termes de cette liste
Cette liste comprend les informations suivantes pour chaque CMP certifiée :
- CMP certifiée : nom de la CMP certifiée.
- ID de la CMP conforme au TCF : identifiant unique attribué par l'IAB à une CMP conforme au TCF.
- Consentement supplémentaire : version du Consentement supplémentaire prise en charge par la CMP.
Liste des CMP certifiées prenant en charge le Consentement supplémentaire
Extension vers l'API CMP
Nous proposons d'étendre l'API CMP JavaScript existante pour la version 2.2 du TCF afin de permettre de renvoyer la chaîne AC. Plus spécifiquement, nous proposons d'étendre les objets JSON TCData et InAppTCData pour transmettre ces données.
TCData = {
tcString: 'base64url-encoded TC string with segments',
...
addtlConsent: ‘AC string with spec version and consented Ad Tech Provider IDs’
}
InAppTCData = {
tcString: 'base64url-encoded TC string with segments',
...
addtlConsent: ‘AC string with spec version and consented Ad Tech Provider IDs’
}
Comment stocker une chaîne AC ?
Web
La CMP détermine le mécanisme de stockage.
Dans l'application
Le SDK d'une CMP doit utiliser NSUserDefaults (iOS) ou SharedPreferences (Android) pour stocker la chaîne AC. De cette manière :
-
Les fournisseurs peuvent facilement accéder à la chaîne AC.
-
La chaîne AC peut être conservée pour plusieurs sessions d'application.
-
La chaîne AC peut être transférée d'une CMP à l'autre, ce qui permet à un éditeur de passer d'un SDK de CMP à un autre.
Si un éditeur décide de supprimer un SDK de CMP de son application, il doit effacer les valeurs AddtlConsent pour les utilisateurs, de sorte que les fournisseurs ne continuent pas à utiliser la chaîne AC incluse.
| Clé de recherche et de stockage dans NSUserDefaults et SharedPreferences | Valeur |
IABTCF_AddtlConsent |
Chaîne : chaîne AC avec la version de la spécification et les ID des fournisseurs de technologie publicitaire autorisés |
Procédure de transfert de la chaîne AC via la chaîne de publicité digitale
Demande d'enchère
Nous allons réutiliser ConsentedProvidersSettings pour transférer les fournisseurs ne figurant pas sur la LGF en aval.
- Dans le protocole des extensions OpenRTB
- Dans l'ancienne version de Protobuf
message ConsentedProvidersSettings {
// Ensemble d'ID correspondant aux fournisseurs pour lesquels l'éditeur a informé
// Google que les utilisateurs situés dans l'EEE ont donné un consentement légalement valable pour : 1) l'utilisation de cookies ou de toute autre méthode de stockage
// en local (lorsqu'il s'agit d'une obligation légale) ; et 2) la collecte, le partage et l'utilisation de données à caractère personnel pour
// la personnalisation des annonces par un fournisseur de technologie publicitaire, conformément aux Règles de Google relatives au consentement de l'utilisateur dans l'UE.
// Une mise en correspondance de l'ID et du nom du fournisseur est publiée dans providers.csv.
repeated int64 consented_providers = 2 [packed = true];
}
// Informations concernant les fournisseurs pour lesquels l'éditeur a informé Google
// que les utilisateurs situés dans l'EEE ont consenti à l'utilisation de leurs données à caractère personnel pour
// la personnalisation des annonces conformément aux règles de Google relatives au consentement de l'utilisateur dans l'UE.
// Ce champ n'est renseigné que si regs_gdpr est défini sur "true".
optional ConsentedProvidersSettings consented_providers_settings = 42;
Services basés sur des URL
Lorsqu'une création est affichée, les balises <img> sont susceptibles de contenir un certain nombre de pixels. Par exemple, <img src="http://vendor-a.com/key1=val1&key2=val2">, qui envoie une requête HTTP GET depuis le navigateur vers le domaine du fournisseur.
Étant donné que le pixel se trouve dans une balise <img> incapable d'exécuter du code JavaScript, il n'est pas possible d'utiliser l'API CMP pour obtenir la chaîne TC. Comme pour la prise en charge de la chaîne TC, nous fournissons un paramètre d'URL standard et une macro dans les URL de pixel où la chaîne AC doit être insérée.
| Paramètre d'URL | Macro correspondante | Représentation dans l'URL |
addtl_consent |
ADDTL_CONSENT |
&addtl_consent=${ADDTL_CONSENT} |
Exemple 1
Pour qu'un fournisseur A reçoive une chaîne AC, l'URL d'une image doit inclure une paire clé-valeur avec le paramètre d'URL et la macro &addtl_consent=${ADDTL_CONSENT}. L'URL obtenue est la suivante :
http://vendor-a.com/key1=val1&key2=val2&addtl_consent=${ADDTL_CONSENT}
Exemple 2
Dans une demande spécifique, si la chaîne AC est : 1~1.35.41.101
L'appelant ou le moteur de rendu de la création remplacent la macro dans l'URL par la véritable chaîne AC, de sorte que le pixel d'origine contenant la macro soit modifié comme suit lors de l'appel vers le serveur spécifié :
http://vendor-a.com/key1=val1&key2=val2&addtl_consent=1~1.35.41.101