Aquest document defineix una especificació tècnica (anomenada "Consentiment addicional") destinada a utilitzar-se només juntament amb la versió 2 del TCF de l'Interactive Advertising Bureau (IAB) Europe per enviar senyals de transparència o consentiment als proveïdors que encara no estan registrats a la llista global de proveïdors (GVL) de l'IAB Europe. Aquesta especificació permet als editors, a les CMP i als partners recollir i propagar el consentiment addicional (juntament amb la seva implementació del TCF) en el cas de les empreses que encara no estan registrades a la GVL de l'IAB Europe, però que sí estan incloses a la llista d'ATP de Google.
Canvis a la versió 2 de Consentiment addicional
Des del desembre de 2023, Google admet la versió 2 de l'especificació Consentiment addicional. Els canvis principals són:
- Actualització de la cadena de Consentiment addicional (CA) per admetre els proveïdors que es comuniquen a la CMP.
- Actualització de l'API Consent Management Platform a fi de permetre la interoperabilitat per a les CMP que admeten tant el TCF com el mode de consentiment de l'anunciant.
Components de Consentiment addicional
A "Consentiment addicional" s'admet:
- La cadena de transparència i consentiment (cadena de TC) tal com es defineix a les especificacions de la versió 2.2 del TCF de l'IAB, que conté la transparència i el consentiment establerts per als proveïdors de la GVL de l'IAB.
- Una cadena lleugera
addtl_consent(cadena de CA), que conté una llista dels ATP de Google que es comuniquen o que han obtingut el consentiment però no estan registrats a l'IAB.
Aquesta especificació defineix el següent:
-
El format de la cadena de CA.
-
L'ampliació de l'API Consent Management Platform de la versió 2.2 del TCF per admetre la cadena de CA i els controls per als casos en què estan presents tant el TCF com el mode de consentiment de l'anunciant.
-
Com s'ha d'emmagatzemar una cadena de CA.
-
Com es pot transferir la cadena de CA a través de la cadena de publicitat digital.
Format de la cadena de Consentiment addicional (CA)
Quina informació s'emmagatzema en una cadena de CA?
Una cadena de CA conté aquests components:
-
Part 1: el número de versió de l'especificació, com ara
2. -
Part 2: un símbol de separació "
~". -
Part 3: una llista dels identificadors, separats per punts, dels ATP de Google que han obtingut el consentiment dels usuaris. Exemple: "
1.35.41.101". -
Part 4: un símbol de separació "
~". -
Part 5: "dv." seguit d'una llista separada per punts dels identificadors d'ATP de Google comunicats. Exemple: "
dv.9.21.81".Els proveïdors inclosos a la part 3 no s'inclouen a la part 5 per tal de reduir la longitud de la cadena.
Exemple de cadena de CA
La cadena de CA 2~1.35.41.101~dv.9.21.81 significa que l'usuari ha donat el consentiment als ATP amb els identificadors 1, 35, 41 i 101, que s'han comunicat a l'usuari els ATP amb els identificadors 9, 21 i 81, i que la cadena es crea mitjançant el format definit a la versió 2 de l'especificació.
Qui ha de crear una cadena de CA?
Una cadena de CA només la pot crear una CMP registrada a través del TCF de l'IAB Europe mitjançant el número d'identificació de la CMP que tingui assignat, d'acord amb les polítiques de l'IAB. Els proveïdors, inclosos els de serveis externs, no han de crear cadenes de CA.
On es publicaran els ATP de Google?
Google publicarà la llista dels ATP que no estiguin registrats a l'IAB, juntament amb els seus identificadors, a la ubicació següent:
https://storage.googleapis.com/tcfac/additional-consent-providers.csv
Quan s'ha de crear una cadena de CA?
En tots els casos, només es pot crear una cadena de CA si l'editor compleix la política de consentiment dels usuaris de la UE de Google.
Els proveïdors amb consentiment només s'han d'incloure quan l'usuari hagi donat un consentiment legalment vàlid per:
-
Utilitzar galetes o altres mecanismes d'emmagatzematge local sempre que ho exigeixi la llei; i
-
Recollir, compartir i utilitzar dades personals per a la personalització d'anuncis per part d'un ATP, sempre que es compleixin totes les altres condicions de la política de consentiment dels usuaris de la UE de Google.
Els proveïdors que es comuniquen i no tenen el consentiment per:
-
Utilitzar galetes o altres mecanismes d'emmagatzematge local sempre que ho exigeixi la llei; i
-
Recollir, compartir i utilitzar dades personals per a la personalització d'anuncis, només s'han d'incloure quan es proporcioni als usuaris la transparència adequada sobre la identitat de cada ATP, inclòs l'enllaç a la política de privadesa de l'ATP, tal com figura a la llista d'ATP de Google.
La cadena de CA només s'ha de crear com a cadena complementària de la cadena de TC, no per substituir-la. Google no processarà les sol·licituds que rebi, i en descartarà la cadena de CA, si no hi ha una cadena de TC disponible per a la mateixa sol·licitud.
Les CMP que implementin aquesta especificació han d'assegurar-se que la cadena de CA que creïn contingui només els identificadors del fitxer d'ATP de Google publicat (és a dir, els proveïdors que no consten a la GVL). Quan Google rebi una cadena de TC, comprovarà la versió de la GVL que s'hi enumeri. Si en aquesta versió de la GVL hi ha registrat un proveïdor, s'ignoraran els controls de la cadena de TC i qualsevol entrada de la cadena de CA corresponents a aquest proveïdor. En aquest cas, Google es reserva el dret de treure aquestes entrades "duplicades" de la cadena de CA i de transferir la cadena de CA modificada juntament amb la cadena de TC. Cap proveïdor, tret de Google, no pot modificar la cadena de CA.
Recursos relacionats
Ampliació de l'API Consent Management Platform
Proposem ampliar l'API Consent Management Platform de JavaScript de la versió 2.2 del TCF per permetre que torni la cadena de CA. Més concretament, proposem ampliar els objectes JSON TCData i InAppTCData perquè tornin aquestes dades.
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’
}
Com s'ha d'emmagatzemar una cadena de CA?
Web
El mecanisme d'emmagatzematge el tria la CMP.
Dins l'aplicació
S'ha d'utilitzar NSUserDefaults (iOS) o SharedPreferences (Android) per emmagatzemar la cadena de CA mitjançant un paquet de desenvolupament de programari (SDK) de la CMP. Això permet que:
-
Els proveïdors puguin accedir fàcilment a la cadena de CA.
-
La cadena de CA es mantingui en les diferents sessions d'aplicació.
-
La cadena de CA sigui portable entre diferents CMP a fi que els editors tinguin la flexibilitat d'intercanviar un SDK de la CMP per un altre.
Si un editor decideix treure un SDK de la CMP de la seva aplicació, és responsable d'esborrar els valors AddtlConsent dels usuaris perquè els proveïdors no continuïn utilitzant la cadena de CA que s'hi inclou.
| Clau d'emmagatzematge i de cerca a NSUserDefaults i SharedPreferences | Valor |
IABTCF_AddtlConsent |
Cadena: cadena de CA amb la versió de l'especificació i els identificadors dels ATP que han obtingut el consentiment. |
Com es pot transferir la cadena de CA a través de la cadena de publicitat digital
Sol·licitud d'oferta
Reutilitzarem ConsentedProvidersSettings per propagar posteriorment els proveïdors que no consten a la GVL.
- Protocol d'extensions d'OpenRTB
- Versió Protobuf heretada
message ConsentedProvidersSettings {
// Conjunt d'identificadors corresponents als proveïdors que, segons ha indicat l'editor
// a Google, han obtingut el consentiment legalment vàlid dels seus usuaris de l'EEE per: 1) utilitzar galetes o altres mecanismes d'emmagatzematge local
// sempre que ho exigeixi la llei, i 2) recollir, compartir i utilitzar dades personals a fi de
// personalitzar els anuncis mitjançant un ATP, d'acord amb la política de consentiment dels usuaris de la UE de Google.
// Es publica el mapatge entre els identificadors i els noms de proveïdor a providers.csv.
repeated int64 consented_providers = 2 [packed = true];
}
// Informació sobre els proveïdors que, segons ha indicat l'editor a Google,
// han obtingut el consentiment dels seus usuaris de l'EEE per utilitzar les seves dades personals a fi de
// personalitzar els anuncis d'acord amb la política de consentiment dels usuaris de la UE de Google.
// Aquest camp només s'emplenarà quan regs_gdpr sigui true.
optional ConsentedProvidersSettings consented_providers_settings = 42;
Serveis basats en URL
Quan una creativitat es renderitza, pot ser que contingui diversos píxels en etiquetes <img>. Per exemple, <img src="http://vendor-a.com/key1=val1&key2=val2">, que envia una sol·licitud HTTP GET des del navegador al domini del proveïdor.
Com que el píxel es troba en una etiqueta <img> sense capacitat per executar JavaScript, no es pot utilitzar l'API Consent Management Platform per obtenir la cadena de TC. De manera semblant a la compatibilitat amb la cadena de TC, proporcionem un paràmetre d'URL estàndard i una macro als URL de píxels en què s'ha d'inserir la cadena de CA.
| Paràmetre d'URL | Macro corresponent | Representació a l'URL |
addtl_consent |
ADDTL_CONSENT |
&addtl_consent=${ADDTL_CONSENT} |
Exemple 1
Per tal que el proveïdor A rebi una cadena de CA, un URL d'imatge ha d'incloure un parell clau-valor amb el paràmetre d'URL i la macro &addtl_consent=${ADDTL_CONSENT}. L'URL resultant és:
http://vendor-a.com/key1=val1&key2=val2&addtl_consent=${ADDTL_CONSENT}
Exemple 2
En una sol·licitud determinada, suposem que la cadena de CA és: 1~1.35.41.101.
En aquest cas, el mètode de crida o el renderitzador de la creativitat substitueix la macro de l'URL per la cadena de CA real, de manera que el píxel que es va col·locar originalment i que conté la macro es modifiqui de la manera següent quan es fa la crida al servidor especificat:
http://vendor-a.com/key1=val1&key2=val2&addtl_consent=1~1.35.41.101
