Il problema del doppio banner

Molte app sono in parte native e in parte web. Un gioco mostra il suo negozio, le notizie o le pagine di aiuto in una WebView; un’app di utilità visualizza articoli dal proprio sito web; un’app ibrida avvolge gran parte della sua interfaccia in contenuti web. Ciascun lato ha il proprio meccanismo di consenso: l’app nativa usa un CMP o un SDK integrato e le pagine web caricano un CMP web. Se non sono collegati, l’utente viene interpellato due volte, le scelte fatte in un punto vengono ignorate nell’altro e le richieste pubblicitarie dall’interno della WebView partono con i segnali sbagliati.

Questa guida spiega come far concordare consenso nativo e web, così che gli utenti rispondano una sola volta e ogni richiesta pubblicitaria porti la stessa decisione.

Dove ciascun lato archivia il consenso

Nativo

L’IAB TCF specifica come un CMP in-app archivia il consenso: in NSUserDefaults su iOS e in SharedPreferences su Android, usando chiavi standard come IABTCF_TCString, IABTCF_gdprApplies e IABTCF_PurposeConsents. Gli SDK pubblicitari leggono direttamente queste chiavi. L’IAB GPP definisce chiavi simili con il prefisso IABGPP_, come IABGPP_HDR_GppString.

Web

Un CMP web di solito archivia la propria decisione in cookie di prima parte o nel local storage per il dominio del sito e la espone tramite le funzioni JavaScript __tcfapi e __gpp. I tag pubblicitari nella pagina chiamano quelle funzioni, non l’archiviazione nativa.

Il divario

Le WebView hanno un proprio spazio per cookie e archiviazione, separato dal browser del dispositivo e dalle preferenze native dell’app. Su iOS, una WKWebView che usa un data store non persistente dimentica tutto quando si chiude. Nulla passa tra i due lati se non lo costruisci tu.

Scegli un’unica fonte di verità

La prima decisione è quale lato possiede il consenso. Per la maggior parte delle app la risposta è il CMP nativo, perché:

• Viene eseguito per primo, prima che qualsiasi WebView venga aperta.
• Gli SDK pubblicitari nativi, che di solito generano la maggior parte dei ricavi, leggono l’archiviazione nativa.
• Su iOS può essere coordinato con la richiesta di App Tracking Transparency.

Partire dal web può avere senso per le app ibride la cui intera interfaccia è contenuto web, ma allora devi riscrivere la decisione nell’archiviazione nativa per gli SDK nativi.

Passare il consenso nativo alla WebView

Con il nativo come fonte di verità, la WebView deve vedere la stessa decisione. Schemi comuni:

1. Iniettare un’implementazione di __tcfapi. Prima che gli script della pagina vengano eseguiti, inietta un piccolo script che definisce __tcfapi (e __gpp se serve) e risponde alle chiamate con la stringa TC e i valori letti dall’archiviazione nativa. I tag pubblicitari nella pagina ottengono così la decisione nativa tramite l’API standard.
2. Sopprimere il banner web. Configura il CMP web perché resti nascosto quando la pagina viene caricata dentro la tua app, per esempio in base a un parametro di query o a un token di user agent personalizzato che controlli. Altrimenti l’utente vede un secondo banner.
3. Passare la stringa al caricamento. Alcuni CMP web possono accettare una stringa di consenso esistente all’inizializzazione e adottarla. Consulta la documentazione del tuo CMP web per i metodi supportati.

Qualunque schema usi, assicurati che i valori iniettati si aggiornino quando l’utente cambia la scelta nella schermata delle impostazioni native, e non solo al successivo avvio dell’app.

Riportare il consenso web al nativo

Se gli utenti possono modificare il consenso all’interno della WebView, per esempio tramite una pagina di impostazioni sulla privacy, l’app deve saperlo. Usa un bridge JavaScript: un gestore di messaggi su iOS o un’interfaccia JavaScript su Android. Il lato web ascolta con __tcfapi('addEventListener', ...) e invia la nuova stringa al codice nativo, che scrive le chiavi standard. Convalida l’input proveniente dalla WebView prima di scriverlo; accetta solo messaggi provenienti dai tuoi contenuti.

Gli annunci nelle WebView

Gli annunci visualizzati in una WebView sono annunci web. Leggono il consenso dalla pagina, non dall’archiviazione nativa, a meno che l’SDK pubblicitario non offra un modo per collegare i due. Il Mobile Ads SDK di Google, per esempio, offre un’API per registrare le WebView così che gli annunci al loro interno possano usare i segnali dell’app; consulta la documentazione attuale del tuo SDK. In ogni caso, conferma con un test che le richieste pubblicitarie dalla WebView portino la stessa stringa TC o GPP delle richieste pubblicitarie native.

Checklist di test

• Installazione pulita: una sola richiesta di consenso, non due.
• Rifiuta tutto nel CMP nativo, apri una WebView, ispeziona le richieste pubblicitarie: la stringa deve riflettere il rifiuto.
• Cambia il consenso nelle impostazioni native, torna a una WebView aperta: la pagina deve vedere la nuova decisione.
• Se esistono impostazioni web, cambia lì il consenso e conferma che le chiavi native si aggiornino.
• Termina e riavvia l’app: le decisioni persistono su entrambi i lati.
• Testa sia su iOS sia su Android, perché l’archiviazione delle WebView si comporta in modo diverso su ciascuno.

Punti chiave

• Il consenso nativo e quello della WebView risiedono in archivi separati e non si sincronizzano per impostazione predefinita.
• Scegli un’unica fonte di verità; per la maggior parte delle app è il CMP nativo.
• Esponi il consenso nativo ai contenuti web tramite un __tcfapi o __gpp iniettato e nascondi il banner web.
• Usa un bridge JavaScript per riportare all’archiviazione nativa le modifiche fatte sul web.
• Verifica che le richieste pubblicitarie dalle WebView portino la stessa stringa di consenso di quelle native.