Problém dvojitého banneru

Mnoho aplikací je částečně nativních a částečně webových. Hra zobrazuje svůj obchod, novinky nebo stránky nápovědy ve WebView; utilitní aplikace vykresluje články ze svého webu; hybridní aplikace obaluje většinu rozhraní webovým obsahem. Každá strana má vlastní mechanismus souhlasu: nativní aplikace používá CMP nebo SDK v aplikaci a webové stránky načítají webový CMP. Pokud nejsou propojeny, uživatel je dotázán dvakrát, volby učiněné na jednom místě se na druhém ignorují a reklamní požadavky z WebView odcházejí s nesprávnými signály.

Tento průvodce se věnuje tomu, jak zajistit shodu nativního a webového souhlasu, aby uživatelé odpověděli jednou a každý reklamní požadavek nesl totéž rozhodnutí.

Kde která strana ukládá souhlas

Nativně

IAB TCF stanoví, jak CMP v aplikaci ukládá souhlas: v NSUserDefaults na iOS a SharedPreferences na Androidu, pomocí standardních klíčů, například IABTCF_TCString, IABTCF_gdprApplies a IABTCF_PurposeConsents. Reklamní SDK tyto klíče čtou přímo. IAB GPP definuje podobné klíče s předponou IABGPP_, například IABGPP_HDR_GppString.

Web

Webový CMP obvykle ukládá své rozhodnutí do cookies první strany nebo lokálního úložiště pro doménu webu a zpřístupňuje ho prostřednictvím funkcí JavaScriptu __tcfapi a __gpp. Reklamní tagy na stránce volají tyto funkce, nikoli nativní úložiště.

Mezera

WebView mají vlastní prostor pro cookies a úložiště, oddělený od prohlížeče v zařízení i od nativních předvoleb aplikace. Na iOS WKWebView používající nepersistentní úložiště dat po zavření všechno zapomene. Mezi oběma stranami nic neproudí, pokud to nevybudujete.

Vyberte jediný zdroj pravdy

První rozhodnutí je, která strana souhlas vlastní. Pro většinu aplikací je odpovědí nativní CMP, protože:

• Běží jako první, ještě než se otevře jakékoli WebView.
• Nativní reklamní SDK, která obvykle vydělávají většinu příjmů, čtou nativní úložiště.
• Na iOS ho lze koordinovat s výzvou App Tracking Transparency.

Přístup „web na prvním místě“ může dávat smysl u hybridních aplikací, jejichž celé rozhraní tvoří webový obsah, ale pak musíte rozhodnutí zapisovat zpět do nativního úložiště pro nativní SDK.

Předání nativního souhlasu do WebView

Pokud je zdrojem pravdy nativní strana, musí WebView vidět totéž rozhodnutí. Běžné vzory:

1. Vložte implementaci __tcfapi. Dříve než se spustí skripty stránky, vložte malý skript, který definuje __tcfapi (a případně __gpp) a na volání odpovídá TC stringem a hodnotami přečtenými z nativního úložiště. Reklamní tagy na stránce pak získají nativní rozhodnutí prostřednictvím standardního API.
2. Potlačte webový banner. Nastavte webový CMP tak, aby zůstal skrytý, když se stránka načítá uvnitř vaší aplikace, například na základě parametru dotazu nebo vlastního tokenu v user agentu, který kontrolujete. Jinak uživatel uvidí druhý banner.
3. Předejte string při načtení. Některé webové CMP dokážou při inicializaci přijmout existující string souhlasu a převzít ho. Podporované metody najdete v dokumentaci svého webového CMP.

Ať použijete jakýkoli vzor, zajistěte, aby se vložené hodnoty aktualizovaly, když uživatel změní volbu na nativní obrazovce nastavení, nejen při příštím spuštění aplikace.

Předání webového souhlasu zpět do nativní části

Pokud mohou uživatelé měnit souhlas uvnitř WebView, například přes stránku nastavení soukromí, musí se o tom aplikace dozvědět. Použijte most JavaScriptu: message handler na iOS nebo rozhraní JavaScriptu na Androidu. Webová strana naslouchá pomocí __tcfapi('addEventListener', ...) a nový string odešle nativnímu kódu, který zapíše standardní klíče. Vstup z WebView před zápisem ověřte; přijímejte pouze zprávy z vlastního obsahu.

Reklamy uvnitř WebView

Reklamy vykreslené ve WebView jsou webové reklamy. Souhlas čtou ze stránky, nikoli z nativního úložiště, pokud reklamní SDK nenabízí způsob, jak obojí propojit. Google Mobile Ads SDK například nabízí API pro registraci WebView, aby reklamy v nich mohly používat signály z aplikace; aktuální dokumentaci pro svůj SDK si ověřte. V každém případě testem potvrďte, že reklamní požadavky z WebView nesou stejný TC nebo GPP string jako nativní reklamní požadavky.

Kontrolní seznam testování

• Čerstvá instalace: jedna výzva k souhlasu, ne dvě.
• Odmítněte vše v nativním CMP, otevřete WebView, prozkoumejte reklamní požadavky: string by měl odrážet odmítnutí.
• Změňte souhlas v nativním nastavení, vraťte se do otevřeného WebView: stránka by měla vidět nové rozhodnutí.
• Pokud existuje webové nastavení, změňte souhlas tam a ověřte, že se nativní klíče aktualizují.
• Ukončete a znovu spusťte aplikaci: rozhodnutí přetrvají na obou stranách.
• Testujte na iOS i Androidu, protože úložiště WebView se na každém chová jinak.

Hlavní poznatky

• Nativní souhlas a souhlas ve WebView žijí v oddělených úložištích a ve výchozím stavu se nesynchronizují.
• Vyberte jediný zdroj pravdy; pro většinu aplikací je to nativní CMP.
• Nativní souhlas zpřístupněte webovému obsahu prostřednictvím vloženého __tcfapi nebo __gpp a skryjte webový banner.
• K odesílání webových změn zpět do nativního úložiště použijte most JavaScriptu.
• Ověřte, že reklamní požadavky z WebView nesou stejný string souhlasu jako nativní.