Адладка радка IAB GPP у кансолі браўзера: пакрокавая інструкцыя
Чаму праблемы з GPP цяжка заўважыць
Калі наведвальнік з ЗША адмаўляецца ад продажу або перадачы сваіх даных, гэты выбар павінен дайсці да кожнага рэкламнага партнёра на старонцы. У IAB Global Privacy Platform (GPP) ён перадаецца ў выглядзе кампактнага радка і спісу ідэнтыфікатараў раздзелаў. Калі нешта з гэтага няправільнае — адсутнічае, састарэла або ўтрымлівае не той раздзел, — знешне нічога не ламаецца. Рэклама, як і раней, загружаецца, банер, як і раней, выглядае нармальна, а праблема праяўляецца пазней: партнёры ігнаруюць адмовы або робяць меншыя стаўкі на ваш інвентар.
Добрая навіна ў тым, што амаль усё можна праверыць з кансолі браўзера. У гэтай інструкцыі праверкі ідуць у тым парадку, у якім мы выконвалі б іх на жывой старонцы.
Крок 1: пераканайцеся, што API існуе і гатовы
CMP, сумяшчальная з GPP, прадастаўляе глабальную функцыю __gpp. Адкрыйце DevTools на сваёй старонцы і выканайце каманду ping:
__gpp('ping', function (data) { console.log(data); });
Вернуты аб’ект шмат распавядае з першага погляду:
- gppVersion — для актуальных рэалізацый павінна быць 1.1.
- cmpStatus — ці загрузілася CMP, ці ўзнікла памылка.
- cmpDisplayStatus — ці бачны банер, схаваны або адключаны для гэтага наведвальніка.
- signalStatus — «ready», калі CMP вызначылася са станам згоды, і «not ready», пакуль яна яшчэ вырашае.
- supportedAPIs — раздзелы, якія CMP можа фармаваць.
- applicableSections — ідэнтыфікатары раздзелаў, якія прыдатныя да гэтага наведвальніка проста зараз.
- gppString — сам закадаваны радок.
Калі __gpp не вызначана, stub CMP адсутнічае або загружаецца занадта позна. Stub павінен быць на месцы да любога рэкламнага скрыпта, які яго чакае, інакш такія скрыпты не ўбачаць CMP і альбо будуць чакаць, альбо працягнуць працу без сігналу.
Крок 2: праверце прыдатны раздзел
Кожная рамка канфідэнцыйнасці ў GPP мае лікавы ідэнтыфікатар раздзела. Часцей за ўсё выдаўцы сутыкаюцца з 2 (EU TCF v2), 5 (канадскі TCF), 7 (US National, «usnat») і 8 і далей для асобных раздзелаў штатаў, такіх як Каліфорнія, Вірджынія, Каларада, Юта і Канэктыкут. Наведвальнік са штата ЗША звычайна павінен бачыць у applicableSections альбо нацыянальны раздзел, альбо адпаведны раздзел штата, але не раздзел ЕС.
Тэстуйце з розных лакацый. Тыповая памылка — CMP, якая правільна вызначае геаграфію для банера, але запісвае ў радок раздзел па змаўчанні незалежна ад яе, або наадварот. З дапамогай VPN або інструментаў папярэдняга прагляду вашай CMP параўнайце тое, што паказвае банер, з тым, што паведамляе applicableSections.
Крок 3: прачытайце даныя раздзела
Замест таго каб дэкадаваць радок уручную, папрасіце ў CMP разабраны раздзел:
__gpp('getSection', function (data, success) { console.log(data, success); }, 'usnat');
У раздзеле US National палі адмовы выкарыстоўваюць простае пагадненне: 0 азначае «непрыдатна», 1 — карыстальнік адмовіўся, а 2 — карыстальнік не адмаўляўся. Спачатку звярніце ўвагу на гэтыя палі:
- SaleOptOut і SharingOptOut
- TargetedAdvertisingOptOut
- Адпаведныя палі notice, у якіх фіксуецца, ці было наведвальніку паказана паведамленне пра кожную практыку
Цяпер выканайце адмову на старонцы — націсніце спасылку «Не прадаваць і не перадаваць мае даныя» або пераключыце налады ў цэнтры пераваг — і зноў запусціце getSection. Палі адмовы павінны змяніцца з 2 на 1. Калі гэтага не здарылася, інтэрфейс і сігнал рассінхранізаваны.
Крок 4: праверце шлях Global Privacy Control
Некалькі законаў штатаў патрабуюць ад кампаній лічыць сігнал Global Privacy Control адмовай. Уключыце GPC у браўзеры або пашырэнні, што яго падтрымлівае, пераканайцеся, што navigator.globalPrivacyControl вяртае true у кансолі, потым загрузіце старонку ў новай сесіі. Адпаведныя палі адмовы ўжо павінны змяшчаць 1, хоць наведвальнік не краўся банера. У некаторых раздзелах ёсць таксама поле, якое паказвае, што выбар паступіў з сігналу GPC.
Крок 5: сачыце за падзеямі, а не толькі за здымкамі
Рэкламныя скрыпты не павінны счытваць радок адзін раз пры загрузцы старонкі і забываць пра яго. Зарэгіструйце listener, каб убачыць тое, што бачаць партнёры:
__gpp('addEventListener', function (evt) { console.log(evt.eventName, evt.pingData); });
Вы павінны ўбачыць такія падзеі, як listenerRegistered, signalStatus і sectionChange. Калі наведвальнік мяняе выбар, услед павінна прыйсці падзея sectionChange з абноўленым радком. Калі ваша абгортка header bidding або інтэграцыя з рэкламным серверам чытае радок толькі да таго, як signalStatus стане «ready», яна можа адправіць пустое або састарэлае значэнне.
Крок 6: прасачыце радок да рэкламных запытаў
Нарэшце, адкрыйце ўкладку Network і адфільтруйце свае рэкламныя запыты. Многія рэкламныя эндпойнты прымаюць параметры gpp і gpp_sid (радок і прыдатныя ідэнтыфікатары раздзелаў). Праверце, што:
- абодва параметры прысутнічаюць у запытах ад наведвальнікаў з ЗША;
- радок супадае з тым, які вярнуў ping на момант запыту;
- пасля адмовы наступныя запыты ўтрымліваюць новы радок, а не закэшаваны.
Калі вы выкарыстоўваеце Prebid.js, пераканайцеся, што яго модуль кіравання згодай наладжаны на GPP, і праверце як bid-запыты, што ідуць з абгорткі, так і выніковы выклік рэкламнага сервера.
Тыповыя сцэнарыі збояў
- Stub загружаецца пасля рэкламных тэгаў — партнёры наогул не бачаць CMP.
- Няправільны раздзел для рэгіёна — раздзел ЕС адпраўляецца для трафіку з ЗША або раздзела няма зусім.
- Інтэрфейс і сігнал рассінхранізаваны — пераключальнік мяняецца, а радок не.
- GPC ігнаруецца — сігнал браўзера ніколі не становіцца адмовай.
- Састарэлыя радкі ў запытах — абгортка кэшуе першае ўбачанае значэнне.
Ключавыя высновы
- Пачніце з ping: версія, статус, прыдатныя раздзелы і радок раскажуць большую частку гісторыі.
- Выкарыстоўвайце getSection для чытання палёў адмовы; 1 азначае адмову, 2 — адмовы няма.
- Правярайце спасылку для адмовы і GPC паасобку і пераканайцеся, што абодва мяняюць сігнал.
- Слухайце падзеі і дачакайцеся сігналу «ready», перш чым рэкламныя запыты будуць чытаць радок.
- Праверце gpp і gpp_sid у рэальных сеткавых запытах да і пасля адмовы.