Мобилни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) бисквитки или локално хранилище за домейна на сайта и го предоставя чрез JavaScript функциите __tcfapi и __gpp. Рекламните тагове в страницата извикват тези функции, а не нативното хранилище.

Пропастта

WebView има собствено пространство за бисквитки и хранилище, отделно от браузъра на устройството и от нативните предпочитания на приложението. На 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 не предоставя начин да се свържат двете. Mobile Ads SDK на Google например предлага API за регистриране на WebView, така че рекламите в тях да могат да използват сигнали от приложението; проверете текущата документация за вашия SDK. Във всички случаи потвърдете с тест, че рекламните заявки от WebView носят същия TC или GPP низ като нативните рекламни заявки.

Контролен списък за тестване

Нова инсталация: една подкана за съгласие, не две.
Откажете всичко в нативния CMP, отворете WebView, прегледайте рекламните заявки: низът трябва да отразява отказа.
Променете съгласието в нативните настройки, върнете се в отворен WebView: страницата трябва да види новото решение.
Ако има уеб настройки, променете съгласието там и потвърдете, че нативните ключове се обновяват.
Принудително затворете и стартирайте отново приложението: решенията се запазват и от двете страни.
Тествайте и на iOS, и на Android, тъй като хранилището на WebView се държи различно на всяка.

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

Нативното съгласие и съгласието във WebView живеят в отделни хранилища и по подразбиране не се синхронизират.
Изберете един източник на истина; за повечето приложения това е нативният CMP.
Предоставете нативното съгласие на уеб съдържанието чрез инжектиран __tcfapi или __gpp и скрийте уеб банера.
Използвайте JavaScript мост, за да връщате уеб промените към нативното хранилище.
Проверете дали рекламните заявки от WebView носят същия низ за съгласие като нативните.