Чому проблеми з 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 у реальних мережевих запитах до та після відмови.