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 обично чува своју одлуку у колачићима првог лица или локалном складишту за домен сајта и излаже је преко 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 мост: message handler на 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-ова носе исти стринг сагласности као нативни.