Мобильные29 окт. 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 несут ту же строку согласия, что и нативные.