Ang Problema ng Dobleng Banner

Maraming app ang bahagyang native at bahagyang web. Ipinapakita ng isang laro ang store, balita o mga help page nito sa isang WebView; nagre-render ang isang utility app ng mga artikulo mula sa website nito; binabalot ng isang hybrid app ang karamihan sa interface nito sa web content. May sariling mekanismo ng pahintulot ang bawat panig: gumagamit ang native app ng in-app CMP o SDK, at naglo-load ng web CMP ang mga web page. Maliban kung magkakonekta ang dalawa, dalawang beses tinatanong ang user, binabalewala sa isang lugar ang mga pagpiling ginawa sa isa pa, at lumalabas ang mga ad request mula sa loob ng WebView na may maling mga signal.

Sinasaklaw ng gabay na ito kung paano gawing magkaayon ang native at web na pahintulot, para minsan lang sumagot ang mga user at dala ng bawat ad request ang parehong desisyon.

Kung Saan Iniimbak ng Bawat Panig ang Pahintulot

Native

Tinutukoy ng IAB TCF kung paano iniimbak ng in-app CMP ang pahintulot: sa NSUserDefaults sa iOS at SharedPreferences sa Android, gamit ang mga standard na key gaya ng IABTCF_TCString, IABTCF_gdprApplies at IABTCF_PurposeConsents. Direktang binabasa ng mga ad SDK ang mga key na ito. Nagdedefine ang IAB GPP ng mga katulad na key na may prefix na IABGPP_, gaya ng IABGPP_HDR_GppString.

Web

Karaniwang iniimbak ng web CMP ang desisyon nito sa mga first-party na cookie o local storage para sa domain ng site, at inilalantad ito sa pamamagitan ng mga JavaScript function na __tcfapi at __gpp. Ang mga ad tag sa pahina ang tumatawag sa mga function na iyon, hindi ang native storage.

Ang puwang

May sariling espasyo ng cookie at storage ang mga WebView, hiwalay sa browser ng device at hiwalay sa mga native preference ng app. Sa iOS, nakakalimutan ng WKWebView na gumagamit ng non-persistent na data store ang lahat kapag isinara ito. Walang dumadaloy sa pagitan ng dalawang panig maliban kung bubuuin mo ito.

Pumili ng Iisang Source of Truth

Ang unang desisyon ay kung aling panig ang may-ari ng pahintulot. Para sa karamihan ng mga app, ang sagot ay ang native CMP, dahil:

• Ito ang unang tumatakbo, bago magbukas ng anumang WebView.
• Binabasa ng mga native ad SDK, na karaniwang kumikita ng karamihan sa kita, ang native storage.
• Sa iOS, maaari itong i-coordinate sa App Tracking Transparency prompt.

Maaaring may katuturan ang web-first para sa mga hybrid app na ang buong interface ay web content, ngunit kailangan mong isulat pabalik ang desisyon sa native storage para sa mga native SDK.

Pagpapasa ng Native na Pahintulot sa WebView

Kapag native ang source of truth, kailangang makita ng WebView ang parehong desisyon. Mga karaniwang pattern:

1. Mag-inject ng __tcfapi implementation. Bago tumakbo ang mga script ng pahina, mag-inject ng maliit na script na nagdedefine ng __tcfapi (at __gpp kung kinakailangan) at sumasagot sa mga tawag gamit ang TC string at mga halagang binasa mula sa native storage. Kukunin na ng mga ad tag sa pahina ang native na desisyon sa pamamagitan ng standard na API.
2. Itago ang web banner. I-configure ang web CMP na manatiling nakatago kapag nilo-load ang pahina sa loob ng iyong app, halimbawa batay sa query parameter o custom na user agent token na kontrolado mo. Kung hindi, makakakita ang user ng pangalawang banner.
3. Ipasa ang string sa pag-load. May ilang web CMP na tumatanggap ng umiiral nang consent string sa initialisation at ginagamit ito. Tingnan ang dokumentasyon ng iyong web CMP para sa mga sinusuportahang paraan.

Alinmang pattern ang gamitin mo, tiyaking nag-a-update ang mga ini-inject na halaga kapag binago ng user ang kanyang pagpili sa native settings screen, hindi lang sa susunod na paglulunsad ng app.

Pagpapasa ng Web na Pahintulot Pabalik sa Native

Kung makakapagbago ang mga user ng pahintulot sa loob ng WebView, halimbawa sa pamamagitan ng privacy settings page, dapat malaman ito ng app. Gumamit ng JavaScript bridge: isang message handler sa iOS o JavaScript interface sa Android. Nakikinig ang web na panig gamit ang __tcfapi('addEventListener', ...) at ipinapadala ang bagong string sa native code, na nagsusulat ng mga standard na key. I-validate ang input mula sa WebView bago ito isulat; tumanggap lamang ng mga mensahe mula sa sarili mong content.

Mga Ad sa Loob ng mga WebView

Mga web ad ang mga ad na nire-render sa isang WebView. Binabasa nila ang pahintulot mula sa pahina, hindi mula sa native storage, maliban kung may paraan ang ad SDK para i-link ang dalawa. Ang Mobile Ads SDK ng Google, halimbawa, ay nag-aalok ng API para magrehistro ng mga WebView para magamit ng mga ad sa loob nito ang mga signal mula sa app; tingnan ang kasalukuyang dokumentasyon para sa iyong SDK. Sa anumang kaso, kumpirmahin sa pamamagitan ng pagsubok na dala ng mga ad request mula sa WebView ang parehong TC o GPP string gaya ng mga native na ad request.

Checklist sa Pagsubok

• Bagong install: isang consent prompt, hindi dalawa.
• Tanggihan lahat sa native CMP, magbukas ng WebView, siyasatin ang mga ad request: dapat sumalamin ang string sa pagtanggi.
• Baguhin ang pahintulot sa native settings, bumalik sa nakabukas na WebView: dapat makita ng pahina ang bagong desisyon.
• Kung may web settings, baguhin ang pahintulot doon at kumpirmahing nag-a-update ang mga native key.
• I-kill at ilunsad muli ang app: nananatili ang mga desisyon sa magkabilang panig.
• Subukan sa iOS at Android, dahil magkaiba ang kilos ng WebView storage sa bawat isa.

Mga Pangunahing Punto

• Nasa magkahiwalay na store ang native at WebView na pahintulot at hindi nagsi-sync bilang default.
• Pumili ng iisang source of truth; para sa karamihan ng mga app ito ang native CMP.
• Ilantad ang native na pahintulot sa web content sa pamamagitan ng ini-inject na __tcfapi o __gpp at itago ang web banner.
• Gumamit ng JavaScript bridge para ipadala pabalik sa native storage ang mga pagbabago sa web.
• Tiyaking dala ng mga ad request mula sa mga WebView ang parehong consent string gaya ng mga native.