Kāpēc GPP problēmas ir grūti pamanīt

Kad ASV apmeklētājs atsakās no savu datu pārdošanas vai kopīgošanas, šai izvēlei jānonāk pie katra reklāmas partnera lapā. Izmantojot IAB Global Privacy Platform (GPP), tā ceļo kā kompakta virkne un sadaļu ID saraksts. Ja kāds no tiem ir nepareizs — trūkst, ir novecojis vai satur nepareizu sadaļu — nekas redzami nesabojājas. Reklāmas joprojām ielādējas, baneris joprojām izskatās kārtībā, un problēma atklājas tikai vēlāk, kad partneri ignorē atteikšanās izvēles vai solījumi par jūsu inventāru kļūst zemāki.

Labā ziņa ir tā, ka gandrīz visu var pārbaudīt pārlūka konsolē. Šī apmācība iziet pārbaudes tādā secībā, kādā mēs tās veiktu darbojošā lapā.

1. solis: pārliecinieties, ka API pastāv un ir gatavs

GPP saderīgs CMP nodrošina globālu funkciju __gpp. Atveriet DevTools savā lapā un izpildiet komandu ping:

__gpp('ping', function (data) { console.log(data); });

Atgrieztais objekts uzreiz daudz pasaka:

• gppVersion — pašreizējām implementācijām jābūt 1.1.
• cmpStatus — vai CMP ir ielādējies vai radusies kļūda.
• cmpDisplayStatus — vai baneris šim apmeklētājam ir redzams, paslēpts vai atspējots.
• signalStatus — “ready”, kad CMP ir noteicis piekrišanas stāvokli, “not ready”, kamēr tas vēl lemj.
• supportedAPIs — sadaļas, ko CMP var izveidot.
• applicableSections — sadaļu ID, kas šobrīd attiecas uz šo apmeklētāju.
• gppString — pati kodētā virkne.

Ja __gpp ir undefined, CMP stub trūkst vai ielādējas pārāk vēlu. Stub jānovieto pirms jebkura reklāmas skripta, kas to gaida, citādi šie skripti neredzēs CMP un vai nu gaidīs, vai turpinās bez signāla.

2. solis: pārbaudiet piemērojamo sadaļu

Katrai GPP privātuma sistēmai ir skaitlisks sadaļas ID. Izdevēji visbiežāk sastopas ar 2 (ES TCF v2), 5 (Kanādas TCF), 7 (ASV nacionālā, “usnat”) un 8 un tālāk atsevišķu štatu sadaļām, piemēram, Kalifornijai, Virdžīnijai, Kolorādo, Jūtai un Konektikutai. ASV štata apmeklētājam applicableSections parasti jāredz vai nu nacionālā sadaļa, vai attiecīgā štata sadaļa, nevis ES sadaļa.

Testējiet no vairākām atrašanās vietām. Biežāka kļūda ir CMP, kas ģeogrāfiju banerim nosaka pareizi, bet virknē ieraksta noklusējuma sadaļu neatkarīgi no tā, vai arī otrādi. Izmantojot VPN vai sava CMP priekšskatījuma rīkus, salīdziniet, ko rāda baneris, ar to, ko ziņo applicableSections.

3. solis: nolasiet sadaļas datus

Tā vietā, lai virkni atkodētu ar roku, palūdziet CMP parsēto sadaļu:

__gpp('getSection', function (data, success) { console.log(data, success); }, 'usnat');

ASV nacionālajā sadaļā atteikšanās lauki izmanto vienkāršu konvenciju: 0 nozīmē nav piemērojams, 1 nozīmē, ka lietotājs atteicās, un 2 nozīmē, ka lietotājs neatteicās. Vispirms pievērsiet uzmanību šiem laukiem:

• SaleOptOut un SharingOptOut
• TargetedAdvertisingOptOut
• Atbilstošie notice lauki, kas reģistrē, vai apmeklētājam par katru praksi tika sniegts paziņojums

Tagad lapā veiciet atteikšanos — noklikšķiniet uz savas saites “Do Not Sell or Share” vai pārslēdziet iestatījumu preferenču centrā — un vēlreiz izpildiet getSection. Atteikšanās laukiem jāmainās no 2 uz 1. Ja tā nenotiek, lietotāja saskarne un signāls nav sinhronizēti.

4. solis: pārbaudiet Global Privacy Control ceļu

Vairāki štatu likumi pieprasa uzņēmumiem uzskatīt Global Privacy Control signālu par atteikšanos. Iespējojiet GPC pārlūkā vai paplašinājumā, kas to atbalsta, pārliecinieties, ka navigator.globalPrivacyControl konsolē atgriež true, un tad ielādējiet lapu jaunā sesijā. Attiecīgajiem atteikšanās laukiem jau jābūt 1, apmeklētājam pat neaizskarot baneri. Dažas sadaļas ietver arī lauku, kas norāda, ka izvēle nāca no GPC signāla.

5. solis: vērojiet notikumus, ne tikai momentuzņēmumus

Reklāmu skriptiem nevajadzētu nolasīt virkni vienreiz lapas ielādes brīdī un to aizmirst. Reģistrējiet listener, lai redzētu to, ko redz partneri:

__gpp('addEventListener', function (evt) { console.log(evt.eventName, evt.pingData); });

Jums jāredz tādi notikumi kā listenerRegistered, signalStatus un sectionChange. Kad apmeklētājs maina izvēli, jāseko notikumam sectionChange ar atjauninātu virkni. Ja jūsu header bidding wrapper vai reklāmu servera integrācija nolasa virkni tikai pirms signalStatus kļūst “ready”, tā var nosūtīt tukšu vai novecojušu vērtību.

6. solis: sekojiet virknei reklāmu pieprasījumos

Visbeidzot atveriet cilni Network un filtrējiet savus reklāmu pieprasījumus. Daudzi reklāmu galapunkti pieņem parametrus gpp un gpp_sid (virkne un piemērojamie sadaļu ID). Pārbaudiet, ka:

1. abi parametri ir klāt ASV apmeklētāju pieprasījumos;
2. virkne atbilst tai, ko ping atgrieza pieprasījuma brīdī;
3. pēc atteikšanās turpmākie pieprasījumi nes jauno virkni, nevis kešotu.

Ja izmantojat Prebid.js, pārliecinieties, ka tā piekrišanas pārvaldības modulis ir konfigurēts GPP, un pārbaudiet gan pieprasījumus, kas atstāj wrapper, gan galīgo reklāmu servera izsaukumu.

Biežākie kļūmju modeļi

• Stub ielādējas pēc reklāmu tagiem — partneri neredz CMP vispār.
• Nepareiza sadaļa reģionam — ES sadaļa nosūtīta ASV trafikam vai nav nevienas sadaļas.
• Saskarne un signāls nav sinhronizēti — slēdzis mainās, virkne ne.
• GPC ignorēts — pārlūka signāls nekad nekļūst par atteikšanos.
• Novecojušas virknes pieprasījumos — wrapper kešo pirmo redzēto vērtību.

Galvenie secinājumi

• Sāciet ar ping: versija, statuss, piemērojamās sadaļas un virkne pastāsta lielāko daļu.
• Izmantojiet getSection, lai nolasītu atteikšanās laukus; 1 nozīmē atteicies, 2 nozīmē neatteicies.
• Testējiet atteikšanās saiti un GPC atsevišķi un pārliecinieties, ka abi maina signālu.
• Klausieties notikumus un gaidiet “ready” signālu, pirms reklāmu pieprasījumi nolasa virkni.
• Pārbaudiet gpp un gpp_sid reālos tīkla pieprasījumos pirms un pēc atteikšanās.