Paziņojums

Lūdzu, ņemiet vērā, ka klientu atbalsta komanda nenodrošina problēmu novēršanas pakalpojumus jūsu pašreizējā attēlojuma valodā. Lai sazinātos ar atbalsta komandas darbiniekiem, lūdzu, vispirms pārslēdzieties uz angļu valodu vai kādu citu atbalstīto valodu (spāņu, portugāļu vai japāņu).

Google papildu piekrišanas tehniskā specifikācija

Izdevējiem, kuri vēlas sadarboties ar reklāmu tehnoloģiju pakalpojumu sniedzējiem, kas nav PPI, ir tieši jāsadarbojas ar savām PPP.

Šajā dokumentā ir definēta tehniskā specifikācija (dēvēta par “papildu piekrišanu”), kas paredzēta tikai izmantošanai kopā ar IAB Europe pārredzamības un piekrišanas ietvara (PPI) 2. versiju, lai sūtītu pārredzamības un/vai piekrišanas signālus pakalpojumu sniedzējiem, kuri vēl nav reģistrēti IAB Europe globālo pakalpojumu sniedzēju sarakstā (GPSS). Šī specifikācija ļauj izdevējiem, piekrišanas pārvaldības platformām (PPP) un partneriem iegūt un ieviest papildu piekrišanu (papildus PPI ieviešanai) tiem uzņēmumiem, kuri vēl nav reģistrēti IAB Europe globālo pakalpojumu sniedzēju sarakstā, taču ir iekļauti Google reklāmu tehnoloģiju pakalpojumu sniedzēju (RTPS) sarakstā.

Papildu piekrišanas izmaiņas (2. versija)

Kopš 2023. gada decembra Google atbalsta papildu piekrišanas specifikācijas 2. versiju. Tālāk ir norādītas svarīgākās izmaiņas.

  • Atjauniniet uz papildu piekrišanas (PP) virkni, lai atbalstītu pakalpojumu sniedzējus, kas norādīti PPP.
  • Atjauniniet uz PPP API, lai nodrošinātu sadarbspēju PPP, kas atbalsta gan PPI, gan reklāmdevēju piekrišanu.
PP virknes, kas ģenerētas, pamatojoties uz 1. versijas specifikāciju, joprojām tiks atbalstītas.

Papildu piekrišanas komponenti

“Papildu piekrišanā” tiek atbalstīti abi šie virknes veidi:

  • pārredzamības un piekrišanas virkne (PP virkne), kā noteikts IAB PPI versijas 2.2 specifikācijā, kas ietver IAB globālo pakalpojumu sniedzēju sarakstā (GPSS) iekļautajiem pakalpojumu sniedzējiem noteikto pārredzamību un piekrišanu UN
  • īsa addtl_consent virkne (PP virkne), kurā ir ietverts to Google reklāmu tehnoloģiju pakalpojumu sniedzēju saraksts, kuri ir snieguši piekrišanu un/vai atklātu informāciju, bet nav reģistrēti IAB sistēmā.

Šī specifikācija definē tālāk norādīto.

  1. PP virknes formātu.

  2. PPI versijas 2.2 PPP API paplašinājumu, lai atbalstītu PP virkni un vadīklas gadījumiem, kad ir pieejams gan PPI, gan reklāmdevēja piekrišanas režīms.

  3. PP virknes glabāšanu.

  4. PP virknes nodošana digitālās reklamēšanas ķēdē.

“Papildu piekrišanas” (PP) virknes formāts

Kāda informācija tiek glabāta PP virknē?

PP virkne ietver tālāk norādītos komponentus.

  • 1. daļa: specifikācijas versijas numurs, piemēram, “2

  • 2. daļa: atdalītāja simbols “~

  • 3. daļa: ar punktiem atdalīts saraksts ar Google reklāmu tehnoloģiju pakalpojumu sniedzējiem (RTPS), kuri saņēmuši lietotāju piekrišanu. Piemērs: “1.35.41.101

  • 4. daļa: atdalītāja simbols “~

  • 5. daļa: “dv”. un ar punktiem atdalīts saraksts ar atklātajiem Google reklāmu tehnoloģiju pakalpojumu sniedzēju (RTPS) ID. Piemērs: “dv.9.21.81

    Lai samazinātu virknes garumu, 3. daļā iekļautos pakalpojumu sniedzējus nedrīkst iekļaut 5. daļā.

PP virknes piemērs

PP virkne 2~1.35.41.101~dv.9.21.81 nozīmē, ka lietotājs ir sniedzis piekrišanu reklāmu tehnoloģiju pakalpojumu sniedzējiem ar identifikatoriem 1, 35, 41 un 101, RTPS ar identifikatoriem 9, 21 un 81 ir atklāta informācija un virkne tiek izveidota, izmantojot 2. versijas specifikācijā noteikto formātu.

Kam ieteicams izveidot PP virkni?

PP virkni var izveidot tikai IAB Europe pārredzamības un piekrišanas ietvarā reģistrēts piekrišanas pārvaldības pakalpojumu sniedzējs, izmantojot tam piešķirto PPP ID numuru atbilstoši IAB politikām. Pakalpojumu sniedzēji vai citi trešās puses pakalpojumu sniedzēji nedrīkst paši veidot PP virknes.

Kur tiks publicēti Google reklāmu tehnoloģiju pakalpojumu sniedzēji?

Google publicēs sarakstu ar tiem reklāmu tehnoloģiju pakalpojumu sniedzējiem, kuri nav reģistrēti IAB, un to ID šādā atrašanās vietā:

https://storage.googleapis.com/tcfac/additional-consent-providers.csv

Kad jāizveido PP virkne?

Visos gadījumos PP virkni var izveidot tikai tad, ja izdevējs atbilst Google ES lietotāju piekrišanas politikai.

Pakalpojumu sniedzēji, kas ieguvuši piekrišanu, ir jāiekļauj tikai tad, ja lietotājs ir sniedzis juridiski derīgu piekrišanu:

  1. sīkfailu vai citas lokālās krātuves izmantošanai, kur to nosaka juridiskās prasības;

  2. personas datu vākšanai, kopīgošanai un izmantošanai reklāmu personalizēšanai, ko veic RTPS, kā arī par atbilstību visiem pārējiem Google ES lietotāju piekrišanas politikas noteikumiem.

Atklātie pakalpojumu sniedzēji, kuri nav saņēmuši piekrišanu:

  1. sīkfailu vai citas lokālās krātuves izmantošanai, kur to nosaka juridiskās prasības;

  2. personas datu vākšanai, kopīgošanai un izmantošanai reklāmu personalizēšanai, ir jāiekļauj tikai tad, ja lietotājiem tiek nodrošināta atbilstoša pārskatāmība par katra RTPS identitāti, tostarp ir saite uz RTPS konfidencialitātes politiku, kā norādīta Google RTPS sarakstā.

PP virkne ir jāizveido tikai kā papildu virkne pārredzamības un piekrišanas virknei, nevis tās vietā. Google neapstrādās pieprasījumu un atmetīs PP virkni Google pieprasījumam, ja tam pašam pieprasījumam nebūs pieejama pārredzamības un piekrišanas virkne.

Piekrišanas pārvaldības pakalpojumu sniedzējiem, kuri ievieš šo specifikāciju, ir jāgādā, lai izveidotajā papildu piekrišanas virknē būtu ietverti tikai publicētajā Google RTPS failā (t.i., pakalpojumu sniedzēji, kas nav iekļauti GPSS) norādītie ID. Kad Google saņems pārredzamības un piekrišanas virkni, tiks pārbaudīta šajā virknē norādītā GPSS versija. Ja attiecīgajā GPSS versijā ir reģistrēts pakalpojumu sniedzējs, tiks ignorētas šī pakalpojumu sniedzēja pārredzamības un piekrišanas virknes vadīklas un visi PP virknes ieraksti. Šādā gadījumā Google patur tiesības noņemt šādus ierakstu “dublikātus” no PP virknes un nodot pārveidoto PP virkni kopā ar pārredzamības un piekrišanas virkni. Pakalpojumu sniedzēji (izņemot Google) nedrīkst veikt izmaiņas PP virknē.

Saistītie resursi

PPP API paplašinājums

Iesakām pagarināt esošo PPI versijas 2.2 PPP JavaScript API, lai varētu atgriezt papildu piekrišanas virkni. Ieteicams paplašināt TCData un InAppTCData JSON objektus, lai tiktu atgriezti šie dati.

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’
}

Kā glabāt PP virkni?

Tīmeklī

Glabāšanas mehānisms ir atkarīgs no PPP izvēles.

Lietotnē

Lai glabātu PP virkni, PPP SDK ir jāizmanto NSUserDefaults (iOS) vai SharedPreferences (Android). Tas ļauj veikt tālāk norādītās darbības.

  • Pakalpojumu sniedzēji var vienkārši piekļūt PP virknei.

  • PP virkne tiek saglabāta visās lietotņu sesijās.

  • PP virkni ir iespējams pārnest starp PPP, lai izdevējam nodrošinātu elastību mainīt vienu PPP SDK uz citu.

Ja izdevējs izvēlas no savas lietotnes noņemt PPP SDK, viņš ir atbildīgs par lietotāju vērtību AddtlConsent notīrīšanu, lai pakalpojumu sniedzēji neturpinātu izmantot iekļauto PP virkni.

Glabāšanas un uzmeklēšanas atslēga saskarnē “NSUserDefaults” un objektā “SharedPreferences” Vērtība
IABTCF_AddtlConsent

Virkne: PP virkne ar specifikācijas versijas numuru un to reklāmu tehnoloģiju pakalpojumu sniedzēju ID, kuri saņēmuši lietotāja piekrišanu.

PP virknes nodošana digitālās reklamēšanas ķēdē

Cenas pieprasījums

Mēs atkārtoti izmantosim ConsentedProvidersSettings, lai izplatītu pakārtotos pakalpojumu sniedzējus, kas nav iekļauti GPSS.

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];
}

 // Information about the providers for whom the publisher has told Google
 // that its EEA users have consented to the use of their personal data for
 // ads personalization in accordance with Google's EU User Consent Policy.
 // This field will only be populated when regs_gdpr is true.
 optional ConsentedProvidersSettings consented_providers_settings = 42;

Ar vietrādi URL saistīti pakalpojumi

Kad reklāmas materiāli tiek atveidoti, tie var ietvert vairākus pikseļus zem tagiem <img>. Piemēram, <img src="http://vendor-a.com/key1=val1&key2=val2">, kas nosūta HTTP GET pieprasījumu no pārlūkprogrammas uz pakalpojumu sniedzēja domēnu.

Tā kā pikselis ir tagā <img> bez iespējas izpildīt JavaScript, PPP API nevar izmantot, lai iegūtu pārredzamības un piekrišanas virkni. Līdzīgi kā papildu piekrišanas virknes atbalstam, mēs piedāvājam standarta URL parametru un makro pikseļu vietrāžos URL, kuros ir jāievieto PP virkne.

URL parametrs Atbilstošais makro Attēlojums vietrādī URL
addtl_consent ADDTL_CONSENT &addtl_consent=${ADDTL_CONSENT}

1. piemērs

Lai pakalpojumu sniedzējs A saņemtu PP virkni, attēla vietrādī URL ir jāiekļauj atslēgas/vērtības pāris ar URL parametru un makro &addtl_consent=${ADDTL_CONSENT}. Iegūtais vietrādis URL ir šāds:

http://vendor-a.com/key1=val1&key2=val2&addtl_consent=${ADDTL_CONSENT}

 

2. piemērs

Ja PP virkne konkrētajā pieprasījumā ir: 1~1.35.41.101.

Izsaucējs vai reklāmas materiālu renderētājs aizstāj vietrādī URL esošo makro ar faktisko PP virkni, lai sākotnēji izvietotais pikselis, kas satur makro, tiktu mainīts tālāk norādītajā veidā, kad tiek veikts izsaukums uz norādīto serveri.

http://vendor-a.com/key1=val1&key2=val2&addtl_consent=1~1.35.41.101

Vai tas bija noderīgs?

Kā varam to uzlabot?
Meklēšana
Notīrīt meklēšanu
Aizvērt meklēšanas lodziņu
Galvenā izvēlne
8094669244581829996
true
Meklēšanas palīdzības centrs
true
true
true
true
true
69621
false
false