A dupla banner problémája

Sok alkalmazás részben natív, részben webes. Egy játék WebView-ban mutatja az áruházat, a híreket vagy a súgóoldalakat; egy segédalkalmazás a weboldaláról rendereli a cikkeket; egy hibrid alkalmazás a felülete nagy részét webes tartalomba csomagolja. Mindkét oldalnak saját beleegyezési mechanizmusa van: a natív alkalmazás alkalmazáson belüli CMP-t vagy SDK-t használ, a weboldalak pedig webes CMP-t töltenek be. Ha nincsenek összekötve, a felhasználót kétszer kérdezik, az egyik helyen hozott döntéseket a másik helyen figyelmen kívül hagyják, a WebView-n belüli hirdetéskérések pedig rossz jelekkel mennek ki.

Ez az útmutató bemutatja, hogyan egyeztetheti a natív és a webes beleegyezést, hogy a felhasználók egyszer válaszoljanak, és minden hirdetéskérés ugyanazt a döntést vigye.

Hol tárolja a beleegyezést az egyes oldalak

Natív

Az IAB TCF meghatározza, hogyan tárolja a beleegyezést az alkalmazáson belüli CMP: iOS-en NSUserDefaults-ban, Androidon SharedPreferences-ben, szabványos kulcsokkal, például IABTCF_TCString, IABTCF_gdprApplies és IABTCF_PurposeConsents. A hirdetési SDK-k közvetlenül ezeket a kulcsokat olvassák. Az IAB GPP hasonló kulcsokat definiál IABGPP_ előtaggal, például IABGPP_HDR_GppString.

Webes

A webes CMP a döntését jellemzően az első féltől származó cookie-kban vagy a webhely domainjének helyi tárolójában őrzi, és a __tcfapi és __gpp JavaScript-függvényeken keresztül teszi elérhetővé. Az oldalon lévő hirdetési tagek ezeket a függvényeket hívják, nem a natív tárolót.

A rés

A WebView-knak saját cookie- és tárhelyük van, elkülönítve az eszköz böngészőjétől és az alkalmazás natív beállításaitól. iOS-en a nem tartós adattárat használó WKWebView bezáráskor mindent elfelejt. A két oldal között semmi nem áramlik, hacsak Ön nem építi meg.

Válasszon egyetlen igazságforrást

Az első döntés az, hogy melyik oldal a beleegyezés gazdája. A legtöbb alkalmazásnál a válasz a natív CMP, mert:

• Elsőként fut, mielőtt bármilyen WebView megnyílna.
• A natív hirdetési SDK-k, amelyek általában a bevétel nagy részét hozzák, a natív tárolót olvassák.
• iOS-en összehangolható az App Tracking Transparency kéréssel.

A web-first értelmes lehet olyan hibrid alkalmazásoknál, amelyeknek az egész felülete webes tartalom, de akkor a döntést vissza kell írnia a natív tárolóba a natív SDK-k számára.

A natív beleegyezés átadása a WebView-nak

Ha a natív az igazságforrás, a WebView-nak ugyanazt a döntést kell látnia. Gyakori minták:

1. Szúrjon be egy __tcfapi-implementációt. Mielőtt az oldal scriptjei lefutnának, szúrjon be egy kis scriptet, amely definiálja a __tcfapi-t (és szükség esetén a __gpp-t), és a hívásokra a natív tárolóból kiolvasott TC stringgel és értékekkel válaszol. Az oldalon lévő hirdetési tagek így a natív döntést a szabványos API-n keresztül kapják.
2. Nyomja el a webes bannert. Állítsa be a webes CMP-t, hogy rejtve maradjon, amikor az oldal az alkalmazásán belül töltődik be, például egy lekérdezési paraméter vagy egy Ön által ellenőrzött egyéni user agent token alapján. Ellenkező esetben a felhasználó második bannert lát.
3. Adja át a stringet betöltéskor. Néhány webes CMP inicializáláskor képes befogadni egy meglévő beleegyezési stringet, és átvenni azt. A támogatott módszereket a webes CMP dokumentációjában találja.

Bármelyik mintát használja is, gondoskodjon róla, hogy a beszúrt értékek frissüljenek, amikor a felhasználó a natív beállítóképernyőn módosítja a választását, ne csak az alkalmazás következő indításakor.

A webes beleegyezés visszaadása a natívnak

Ha a felhasználók a WebView-n belül módosíthatják a beleegyezést, például egy adatvédelmi beállítási oldalon keresztül, az alkalmazásnak tudnia kell erről. Használjon JavaScript-hidat: iOS-en üzenetkezelőt, Androidon JavaScript-interfészt. A webes oldal a __tcfapi('addEventListener', ...)-pal figyel, és elküldi az új stringet a natív kódnak, amely beírja a szabványos kulcsokat. Írás előtt ellenőrizze a WebView-ból érkező bemenetet; csak a saját tartalomból érkező üzeneteket fogadja el.

Hirdetések a WebView-kban

A WebView-ban renderelt hirdetések webes hirdetések. A beleegyezést az oldalról olvassák, nem a natív tárolóból, hacsak a hirdetési SDK nem biztosít módot a kettő összekapcsolására. A Google Mobile Ads SDK például kínál egy API-t a WebView-k regisztrálására, hogy az azokban lévő hirdetések használhassák az alkalmazás jeleit; az SDK aktuális dokumentációját ellenőrizze. Minden esetben teszttel győződjön meg róla, hogy a WebView-ból érkező hirdetéskérések ugyanazt a TC vagy GPP stringet viszik, mint a natív hirdetéskérések.

Tesztelési ellenőrzőlista

• Friss telepítés: egy beleegyezési kérés, nem kettő.
• Mindent elutasít a natív CMP-ben, megnyit egy WebView-t, megvizsgálja a hirdetéskéréseket: a stringnek tükröznie kell az elutasítást.
• Módosítja a beleegyezést a natív beállításokban, visszatér egy megnyitott WebView-hoz: az oldalnak látnia kell az új döntést.
• Ha vannak webes beállítások, ott módosítja a beleegyezést, és megerősíti, hogy a natív kulcsok frissülnek.
• Leállítja és újraindítja az alkalmazást: a döntések mindkét oldalon megmaradnak.
• Tesztelje iOS-en és Androidon is, mert a WebView-tároló mindegyiken másképp viselkedik.

Legfontosabb tanulságok

• A natív és a WebView-beli beleegyezés külön tárolóban él, és alapból nem szinkronizálódik.
• Válasszon egy igazságforrást; a legtöbb alkalmazásnál ez a natív CMP.
• Tegye elérhetővé a natív beleegyezést a webes tartalomnak beszúrt __tcfapi-n vagy __gpp-n keresztül, és rejtse el a webes bannert.
• JavaScript-híddal küldje vissza a webes változásokat a natív tárolóba.
• Ellenőrizze, hogy a WebView-ból érkező hirdetéskérések ugyanazt a beleegyezési stringet viszik, mint a natívak.