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 ?
- La procédure de transfert de la chaîne AC via la chaîne de publicité digitale
- Ressources associées
Ce document concerne le Consentement supplémentaire de Google, une spécification technique destinée à être utilisée uniquement avec la version 2 du Transparency & Consent Framework (TCF) de l'IAB Europe. Elle permet d'envoyer des signaux de transparence et/ou de consentement aux fournisseurs qui ne sont pas encore inscrits 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 partenaires de technologie publicitaire de Google.
Composants du consentement supplémentaire
Le Consentement supplémentaire se compose d'une chaîne addtl_consent simple (chaîne AC), qui contient une liste de partenaires de technologie publicitaire de Google autorisés et/ou divulgués, et qui ne sont pas enregistrés auprès de la liste globale des fournisseurs (LGF) de l'IAB.
Générer une chaîne "Consentement supplémentaire" version 2 (ACv2)
Quelles sont les informations stockées dans une chaîne AC ?
Une chaîne AC contient les composants suivants :
-
Partie 1 : numéro de version de la spécification. La version actuelle est "
2". -
Partie 2 : un symbole de séparation "
~". -
Partie 3 : une liste d'ID de partenaires 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 partenaires 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.
Exemples de chaînes AC
Si les partenaires de technologie publicitaire associés aux ID 1, 2, 3, 4 et 10 sont divulgués à l'utilisateur :
- … et que l'utilisateur a vu le message de la CMP divulguant ces fournisseurs, mais n'a pas encore décidé s'il allait donner son consentement, la chaîne ACv2 correspondante serait
2~~dv.1.2.3.4.10. -
… et que l'utilisateur a donné son consentement à tous les fournisseurs, la chaîne ACv2 correspondante serait
2~1.2.3.4.10~dv.. Notez que le "." après dv est facultatif dans ce cas uniquement. Par conséquent,2~1.2.3.4.10~dvest également une chaîne ACv2 prise en charge. - … et que l'utilisateur a refusé le consentement pour tous les fournisseurs, la chaîne ACv2 correspondante doit indiquer que tous les fournisseurs ont été divulgués, mais qu'aucun n'a obtenu le consentement. La chaîne ACv2 correspondante serait
2~~dv.1.2.3.4.10. - … et que l'utilisateur a donné son consentement pour les fournisseurs
1et10, mais l'a refusé pour tous les autres, la chaîne ACv2 correspondante serait2~1.10~dv.2.3.4.
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 partenaires de technologie publicitaire de Google ?
Google tient à jour une liste des partenaires 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 permettre à un ATP de personnaliser les annonces, 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 ATP. Ils doivent, entre autres, inclure un lien vers leurs règles de confidentialité, telles que fournies dans la liste des ATP 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é des ATP de Google (fournisseurs ne figurant pas sur la LGF). Lorsque Google reçoit une chaîne TC (Transparency & Consent), 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.
Les chaînes de consentement supplémentaire générées selon la version 1 sont-elles toujours prises en charge ?
La version 2 du Consentement supplémentaire est la version standard depuis décembre 2023. Les chaînes de consentement supplémentaire générées selon la version 1 de la spécification continueront d'être prises en charge. Toutefois, ces chaînes ne peuvent pas indiquer si la transparence est établie pour un partenaire de technologie publicitaire. Pour pouvoir prendre en charge les cas d'utilisation qui ne nécessitent pas de consentement, les CMP doivent migrer vers la version 2 de la spécification.
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
Les CMP qui prennent en charge le Consentement supplémentaire doivent renvoyer la chaîne de consentement supplémentaire dans les objets JSON TCData et InAppTCData de l'API CMP JavaScript TCF v2 existante.
TCData = {
tcString: 'base64url-encoded TC string with segments',
...
addtlConsent: ‘AC string with spec version and consented/disclosed Ad Tech Provider IDs’
}
InAppTCData = {
tcString: 'base64url-encoded TC string with segments',
...
addtlConsent: ‘AC string with spec version and consented/disclosed Ad Tech Provider IDs’
}
Comment stocker une chaîne AC ?
Web
La CMP détermine le mécanisme de stockage.
Dans l'application
NSUserDefaults (iOS) ou SharedPreferences (Android) sont utilisés pour stocker la chaîne AC générée par un SDK de CMP, de la même manière que l'API intégrée pour TCFv2. Grâce à ce mécanisme :
-
les fournisseurs peuvent facilement accéder à la chaîne AC ;
-
la chaîne AC peut être conservée pour plusieurs sessions d'application ;
-
la portabilité de la chaîne AC est préservée si un éditeur change de CMP.
Remarque : 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 partenaires de technologie publicitaire autorisés |
La procédure de transfert de la chaîne AC via la chaîne de publicité digitale
Demandes d'enchères
Les demandes d'enchères utiliseront 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 {
// Set of IDs corresponding to providers for whom the publisher has told
// Google that its EEA users have given legally valid consent to: 1) the use of cookies or other local
// storage where legally required; and 2) the collection, sharing, and use of personal data for
// personalization of ads by an ATP in accordance with Google’s EU User Consent Policy.
// A mapping of provider ID to provider name is posted at 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> peuvent 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 : 2~1.35.41.101~dv.
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=2~1.35.41.101~dv.