Mobile29 жовт. 2026 | FlexyConsent

Згода у WebView: як синхронізувати нативну та веб-згоду

Проблема подвійного банера

Багато застосунків частково нативні, частково веб. Гра показує магазин, новини чи довідку у WebView; утиліта відображає статті зі свого сайту; гібридний застосунок обгортає більшу частину інтерфейсу у веб-контент. У кожної сторони свій механізм згоди: нативний застосунок використовує вбудований CMP або SDK, а веб-сторінки завантажують веб-CMP. Якщо вони не пов’язані, користувача питають двічі, вибір в одному місці ігнорується в іншому, а рекламні запити з WebView йдуть із неправильними сигналами.

У цьому посібнику описано, як узгодити нативну та веб-згоду, щоб користувачі відповідали один раз, а кожен рекламний запит ніс те саме рішення.

Де кожна сторона зберігає згоду

Нативний застосунок

IAB TCF визначає, як вбудований CMP зберігає згоду: у NSUserDefaults на iOS і SharedPreferences на Android, із використанням стандартних ключів, таких як IABTCF_TCString, IABTCF_gdprApplies та IABTCF_PurposeConsents. Рекламні SDK читають ці ключі безпосередньо. IAB GPP визначає подібні ключі з префіксом IABGPP_, наприклад IABGPP_HDR_GppString.

Веб

Веб-CMP зазвичай зберігає своє рішення у власних (first-party) cookie чи локальному сховищі для домену сайту та надає його через JavaScript-функції __tcfapi і __gpp. Рекламні теги на сторінці викликають ці функції, а не нативне сховище.

Розрив

У WebView власний простір cookie та сховища, окремий від браузера пристрою й від нативних налаштувань застосунку. На iOS WKWebView з непостійним сховищем даних забуває все під час закриття. Між двома сторонами нічого не передається, якщо ви самі цього не збудуєте.

Оберіть одне джерело істини

Перше рішення — яка сторона володіє згодою. Для більшості застосунків відповідь — нативний CMP, тому що:

Він запускається першим, до відкриття будь-якого WebView.
Нативні рекламні SDK, які зазвичай приносять основний дохід, читають нативне сховище.
На iOS його можна скоординувати із запитом App Tracking Transparency.

Пріоритет веба може мати сенс для гібридних застосунків, увесь інтерфейс яких — веб-контент, але тоді рішення доведеться записувати назад у нативне сховище для нативних SDK.

Передавання нативної згоди у WebView

Якщо джерело істини — нативна сторона, WebView має бачити те саме рішення. Поширені шаблони:

Впровадити реалізацію __tcfapi. До запуску скриптів сторінки впровадьте невеликий скрипт, що визначає __tcfapi (і __gpp, якщо потрібно) та відповідає на виклики TC string і значеннями, прочитаними з нативного сховища. Рекламні теги на сторінці тоді отримують нативне рішення через стандартний API.
Приховати веб-банер. Налаштуйте веб-CMP так, щоб він не показувався, коли сторінку завантажено всередині вашого застосунку, наприклад за параметром запиту чи власним токеном user agent, який ви контролюєте. Інакше користувач побачить другий банер.
Передати рядок під час завантаження. Деякі веб-CMP можуть прийняти наявний рядок згоди під час ініціалізації та використати його. Підтримувані методи шукайте в документації вашого веб-CMP.

Який би шаблон ви не обрали, переконайтеся, що впроваджувані значення оновлюються, коли користувач змінює вибір на нативному екрані налаштувань, а не лише під час наступного запуску застосунку.

Передавання веб-згоди назад у нативний застосунок

Якщо користувачі можуть змінювати згоду всередині WebView, наприклад на сторінці налаштувань приватності, застосунок має про це дізнатися. Використовуйте JavaScript-міст: обробник повідомлень на iOS або JavaScript-інтерфейс на Android. Веб-сторона слухає через __tcfapi('addEventListener', ...) і надсилає новий рядок нативному коду, який записує стандартні ключі. Перевіряйте дані з WebView перед записом; приймайте повідомлення лише від вашого власного контенту.

Реклама всередині WebView

Реклама, що відображається у WebView, є веб-рекламою. Вона читає згоду зі сторінки, а не з нативного сховища, якщо тільки рекламний SDK не надає спосіб пов’язати їх. Наприклад, Google Mobile Ads SDK пропонує API для реєстрації WebView, щоб реклама всередині них могла використовувати сигнали застосунку; актуальну документацію для вашого SDK дивіться окремо. У будь-якому разі тестом переконайтеся, що рекламні запити з WebView несуть той самий рядок TC або GPP, що й нативні рекламні запити.

Чек-лист тестування

Свіже встановлення: один запит згоди, а не два.
Відхиліть усе в нативному CMP, відкрийте WebView, вивчіть рекламні запити: рядок має відображати відмову.
Змініть згоду в нативних налаштуваннях, поверніться у відкритий WebView: сторінка має побачити нове рішення.
Якщо є веб-налаштування, змініть згоду там і переконайтеся, що нативні ключі оновилися.
Примусово закрийте й заново запустіть застосунок: рішення зберігаються з обох сторін.
Тестуйте і на iOS, і на Android, бо сховище WebView поводиться на них по-різному.

Головні висновки

Нативна згода та згода WebView живуть у різних сховищах і за замовчуванням не синхронізуються.
Оберіть одне джерело істини; для більшості застосунків це нативний CMP.
Передайте нативну згоду веб-контенту через впроваджувані __tcfapi чи __gpp і сховайте веб-банер.
Використовуйте JavaScript-міст, щоб надсилати веб-зміни назад у нативне сховище.
Перевірте, що рекламні запити з WebView несуть той самий рядок згоди, що й нативні.