Problém dvojitého bannera

Mnohé aplikácie sú sčasti natívne a sčasti webové. Hra zobrazuje svoj obchod, správy alebo stránky pomocníka vo WebView; utilitná aplikácia vykresľuje články zo svojho webu; hybridná aplikácia zabaľuje väčšinu svojho rozhrania do webového obsahu. Každá strana má vlastný mechanizmus súhlasu: natívna aplikácia používa CMP alebo SDK v aplikácii a webové stránky načítavajú webový CMP. Ak nie sú prepojené, používateľ sa pýta dvakrát, voľby urobené na jednom mieste sa na druhom ignorujú a reklamné požiadavky zvnútra WebView odchádzajú s nesprávnymi signálmi.

Tento sprievodca pokrýva, ako docieliť, aby sa natívny a webový súhlas zhodovali, takže používatelia odpovedajú raz a každá reklamná požiadavka nesie rovnaké rozhodnutie.

Kde každá strana ukladá súhlas

Natívna

IAB TCF určuje, ako CMP v aplikácii ukladá súhlas: v NSUserDefaults na iOS a v SharedPreferences na Androide, pomocou štandardných kľúčov ako IABTCF_TCString, IABTCF_gdprApplies a IABTCF_PurposeConsents. Reklamné SDK tieto kľúče čítajú priamo. IAB GPP definuje podobné kľúče s predponou IABGPP_, napríklad IABGPP_HDR_GppString.

Webová

Webový CMP zvyčajne ukladá svoje rozhodnutie do cookies prvej strany alebo lokálneho úložiska pre doménu webu a sprístupňuje ho cez JavaScriptové funkcie __tcfapi a __gpp. Reklamné tagy na stránke volajú tieto funkcie, nie natívne úložisko.

Medzera

WebViewy majú vlastný priestor pre cookies a úložisko, oddelený od prehliadača zariadenia aj od natívnych predvolieb aplikácie. Na iOS WKWebView používajúci nepersistentné úložisko údajov po zatvorení všetko zabudne. Medzi oboma stranami nič netečie, pokiaľ to nezostavíte.

Vyberte jediný zdroj pravdy

Prvým rozhodnutím je, ktorá strana súhlas vlastní. Pre väčšinu aplikácií je odpoveďou natívny CMP, pretože:

• Beží ako prvý, ešte pred otvorením akéhokoľvek WebView.
• Natívne reklamné SDK, ktoré zvyčajne zarábajú väčšinu príjmov, čítajú natívne úložisko.
• Na iOS ho možno koordinovať s výzvou App Tracking Transparency.

Web-first môže dávať zmysel pri hybridných aplikáciách, ktorých celé rozhranie je webový obsah, ale potom musíte rozhodnutie zapisovať späť do natívneho úložiska pre natívne SDK.

Odovzdanie natívneho súhlasu do WebView

Ak je zdrojom pravdy natívna strana, WebView musí vidieť rovnaké rozhodnutie. Bežné vzory:

1. Vložte implementáciu __tcfapi. Skôr než sa spustia skripty stránky, vložte malý skript, ktorý definuje __tcfapi (a podľa potreby __gpp) a odpovedá na volania pomocou TC stringu a hodnôt prečítaných z natívneho úložiska. Reklamné tagy na stránke potom dostanú natívne rozhodnutie cez štandardné API.
2. Potlačte webový banner. Nakonfigurujte webový CMP tak, aby ostal skrytý, keď sa stránka načíta vo vašej aplikácii, napríklad na základe parametra dotazu alebo vlastného tokenu user agenta, ktorý kontrolujete. Inak používateľ uvidí druhý banner.
3. Odovzdajte reťazec pri načítaní. Niektoré webové CMP dokážu pri inicializácii prijať existujúci reťazec súhlasu a prevziať ho. Podporované metódy nájdete v dokumentácii svojho webového CMP.

Ktorýkoľvek vzor použijete, uistite sa, že sa vložené hodnoty aktualizujú, keď používateľ zmení voľbu na natívnej obrazovke nastavení, nielen pri ďalšom spustení aplikácie.

Odovzdanie webového súhlasu späť natívnej strane

Ak môžu používatelia meniť súhlas vo WebView, napríklad cez stránku nastavení súkromia, aplikácia sa o tom musí dozvedieť. Použite JavaScriptový most: obsluhu správ na iOS alebo JavaScriptové rozhranie na Androide. Webová strana počúva cez __tcfapi('addEventListener', ...) a posiela nový reťazec natívnemu kódu, ktorý zapíše štandardné kľúče. Vstup z WebView pred zápisom overte; prijímajte iba správy z vlastného obsahu.

Reklamy vo WebViewoch

Reklamy vykresľované vo WebView sú webové reklamy. Súhlas čítajú zo stránky, nie z natívneho úložiska, pokiaľ SDK reklamy neposkytuje spôsob, ako obe prepojiť. Napríklad Google Mobile Ads SDK ponúka API na registráciu WebViewov, aby reklamy v nich mohli využívať signály z aplikácie; aktuálnu dokumentáciu pre svoje SDK si overte. V každom prípade testom potvrďte, že reklamné požiadavky z WebView nesú rovnaký reťazec TC alebo GPP ako natívne reklamné požiadavky.

Kontrolný zoznam testovania

• Nová inštalácia: jedna výzva na súhlas, nie dve.
• Odmietnite všetko v natívnom CMP, otvorte WebView, preskúmajte reklamné požiadavky: reťazec by mal odrážať odmietnutie.
• Zmeňte súhlas v natívnych nastaveniach, vráťte sa do otvoreného WebView: stránka by mala vidieť nové rozhodnutie.
• Ak existujú webové nastavenia, zmeňte súhlas tam a overte, že sa natívne kľúče aktualizujú.
• Ukončite a znova spustite aplikáciu: rozhodnutia pretrvajú na oboch stranách.
• Testujte na iOS aj Androide, pretože úložisko WebView sa na každom správa inak.

Kľúčové poznatky

• Natívny súhlas a súhlas vo WebView žijú v samostatných úložiskách a predvolene sa nesynchronizujú.
• Vyberte jediný zdroj pravdy; pre väčšinu aplikácií je to natívny CMP.
• Sprístupnite natívny súhlas webovému obsahu cez vložené __tcfapi alebo __gpp a skryte webový banner.
• Zmeny z webu posielajte späť do natívneho úložiska cez JavaScriptový most.
• Overte, že reklamné požiadavky z WebViewov nesú rovnaký reťazec súhlasu ako natívne.