Защо проблемите с 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 (низа и идентификаторите на приложимите секции). Проверете дали:

1. двата параметъра присъстват в заявките от посетители от САЩ;
2. низът съвпада с този, върнат от ping в момента на заявката;
3. след отказ следващите заявки носят новия низ, а не кеширан.

Ако използвате Prebid.js, уверете се, че модулът му за управление на съгласието е конфигуриран за GPP, и прегледайте както bid заявките, напускащи обвивката, така и крайното извикване към рекламния сървър.

Чести модели на повреди

• Stub се зарежда след рекламните тагове — партньорите изобщо не виждат CMP.
• Грешна секция за региона — секцията за ЕС се изпраща за трафик от САЩ или няма секция изобщо.
• Интерфейсът и сигналът не са синхронизирани — превключвателят се променя, низът не.
• GPC е игнориран — сигналът на браузъра никога не става отказ.
• Остарели низове в заявките — обвивката кешира първата стойност, която е видяла.

Основни изводи

• Започнете с ping: версията, статусът, приложимите секции и низът разказват по-голямата част от историята.
• Използвайте getSection, за да четете полетата за отказ; 1 означава отказ, 2 — няма отказ.
• Тествайте връзката за отказ и GPC поотделно и се уверете, че и двете променят сигнала.
• Слушайте събитията и изчакайте сигнал „ready“, преди рекламните заявки да четат низа.
• Проверете gpp и gpp_sid в реални мрежови заявки преди и след отказ.