Problema dublului banner

Multe aplicații sunt parțial native și parțial web. Un joc își afișează magazinul, știrile sau paginile de ajutor într-un WebView; o aplicație utilitară randează articole de pe site-ul său; o aplicație hibridă își învelește cea mai mare parte a interfeței în conținut web. Fiecare parte are propriul mecanism de consimțământ: aplicația nativă folosește un CMP sau SDK din aplicație, iar paginile web încarcă un CMP web. Dacă nu sunt conectate, utilizatorul este întrebat de două ori, alegerile făcute într-un loc sunt ignorate în celălalt, iar cererile de reclame din interiorul WebView-ului pleacă cu semnalele greșite.

Acest ghid explică cum faci ca consimțământul nativ și cel web să fie în acord, astfel încât utilizatorii să răspundă o singură dată, iar fiecare cerere de reclamă să poarte aceeași decizie.

Unde stochează fiecare parte consimțământul

Nativ

IAB TCF specifică modul în care un CMP din aplicație stochează consimțământul: în NSUserDefaults pe iOS și în SharedPreferences pe Android, folosind chei standard precum IABTCF_TCString, IABTCF_gdprApplies și IABTCF_PurposeConsents. SDK-urile de reclame citesc direct aceste chei. IAB GPP definește chei similare cu prefixul IABGPP_, cum ar fi IABGPP_HDR_GppString.

Web

Un CMP web își stochează de obicei decizia în cookie-uri first-party sau în stocarea locală pentru domeniul site-ului și o expune prin funcțiile JavaScript __tcfapi și __gpp. Tagurile de reclame din pagină apelează aceste funcții, nu stocarea nativă.

Decalajul

WebView-urile au propriul spațiu de cookie-uri și de stocare, separat de browserul dispozitivului și separat de preferințele native ale aplicației. Pe iOS, un WKWebView care folosește un depozit de date nepersistent uită totul când se închide. Nimic nu circulă între cele două părți decât dacă construiești tu acest lucru.

Alege o singură sursă de adevăr

Prima decizie este care parte deține consimțământul. Pentru majoritatea aplicațiilor răspunsul este CMP-ul nativ, deoarece:

• Rulează primul, înainte de deschiderea oricărui WebView.
• SDK-urile de reclame native, care aduc de obicei cea mai mare parte a veniturilor, citesc stocarea nativă.
• Pe iOS, poate fi coordonat cu solicitarea App Tracking Transparency.

Abordarea web-first poate avea sens pentru aplicațiile hibride a căror interfață întreagă este conținut web, dar atunci trebuie să scrii decizia înapoi în stocarea nativă pentru SDK-urile native.

Transmiterea consimțământului nativ către WebView

Cu nativul ca sursă de adevăr, WebView-ul trebuie să vadă aceeași decizie. Modele frecvente:

1. Injectează o implementare __tcfapi. Înainte să ruleze scripturile paginii, injectează un mic script care definește __tcfapi (și __gpp, dacă e nevoie) și răspunde apelurilor cu TC string și cu valorile citite din stocarea nativă. Tagurile de reclame din pagină primesc atunci decizia nativă prin API-ul standard.
2. Suprimă bannerul web. Configurează CMP-ul web să rămână ascuns când pagina este încărcată în aplicația ta, de exemplu pe baza unui parametru de interogare sau a unui token personalizat de user agent pe care îl controlezi. Altfel, utilizatorul vede un al doilea banner.
3. Transmite șirul la încărcare. Unele CMP-uri web pot accepta un șir de consimțământ existent la inițializare și îl adoptă. Verifică în documentația CMP-ului tău web metodele acceptate.

Indiferent de modelul folosit, asigură-te că valorile injectate se actualizează când utilizatorul își schimbă alegerea în ecranul de setări nativ, nu doar la următoarea pornire a aplicației.

Transmiterea consimțământului web înapoi către nativ

Dacă utilizatorii pot schimba consimțământul în interiorul WebView-ului, de exemplu printr-o pagină de setări de confidențialitate, aplicația trebuie să afle. Folosește o punte JavaScript: un handler de mesaje pe iOS sau o interfață JavaScript pe Android. Partea web ascultă cu __tcfapi('addEventListener', ...) și trimite noul șir către codul nativ, care scrie cheile standard. Validează datele primite de la WebView înainte de a le scrie; acceptă doar mesaje din propriul tău conținut.

Reclame în interiorul WebView-urilor

Reclamele randate într-un WebView sunt reclame web. Ele citesc consimțământul din pagină, nu din stocarea nativă, cu excepția cazului în care SDK-ul de reclame oferă o modalitate de a le lega. Mobile Ads SDK de la Google, de exemplu, oferă un API pentru înregistrarea WebView-urilor, astfel încât reclamele din ele să poată folosi semnale din aplicație; verifică documentația curentă a SDK-ului tău. În orice caz, confirmă printr-un test că cererile de reclame din WebView poartă același TC string sau GPP string ca cele native.

Listă de verificare pentru testare

• Instalare nouă: o singură solicitare de consimțământ, nu două.
• Refuză tot în CMP-ul nativ, deschide un WebView, inspectează cererile de reclame: șirul ar trebui să reflecte refuzul.
• Schimbă consimțământul în setările native, revino la un WebView deschis: pagina ar trebui să vadă noua decizie.
• Dacă există setări web, schimbă consimțământul acolo și confirmă că cheile native se actualizează.
• Oprește forțat și repornește aplicația: deciziile persistă pe ambele părți.
• Testează atât pe iOS, cât și pe Android, deoarece stocarea WebView se comportă diferit pe fiecare.

Concluzii-cheie

• Consimțământul nativ și cel din WebView trăiesc în depozite separate și nu se sincronizează implicit.
• Alege o singură sursă de adevăr; pentru majoritatea aplicațiilor este CMP-ul nativ.
• Expune consimțământul nativ conținutului web printr-un __tcfapi sau __gpp injectat și ascunde bannerul web.
• Folosește o punte JavaScript pentru a trimite modificările web înapoi în stocarea nativă.
• Verifică dacă cererile de reclame din WebView-uri poartă același șir de consimțământ ca cele native.