El problema del doble bàner

Moltes aplicacions són en part natives i en part web. Un joc mostra la botiga, les notícies o les pàgines d'ajuda en un WebView; una aplicació d'utilitats mostra articles del seu lloc web; una aplicació híbrida embolcalla la major part de la seva interfície en contingut web. Cada banda té el seu propi mecanisme de consentiment: l'aplicació nativa fa servir un CMP o SDK dins l'aplicació, i les pàgines web carreguen un CMP web. Si no estan connectats, es demana dues vegades a l'usuari, les eleccions fetes en un lloc s'ignoren a l'altre, i les sol·licituds d'anuncis des de dins del WebView surten amb els senyals equivocats.

Aquesta guia explica com fer que el consentiment natiu i el web coincideixin, perquè els usuaris responguin una sola vegada i cada sol·licitud d'anunci porti la mateixa decisió.

On emmagatzema el consentiment cada banda

Natiu

L'IAB TCF especifica com emmagatzema el consentiment un CMP dins l'aplicació: a NSUserDefaults a iOS i a SharedPreferences a Android, amb claus estàndard com IABTCF_TCString, IABTCF_gdprApplies i IABTCF_PurposeConsents. Els SDK d'anuncis llegeixen aquestes claus directament. L'IAB GPP defineix claus similars amb el prefix IABGPP_, com IABGPP_HDR_GppString.

Web

Un CMP web sol emmagatzemar la seva decisió en cookies pròpies o en l'emmagatzematge local del domini del lloc, i l'exposa mitjançant les funcions JavaScript __tcfapi i __gpp. Les etiquetes d'anuncis de la pàgina criden aquestes funcions, no l'emmagatzematge natiu.

La bretxa

Els WebViews tenen el seu propi espai de cookies i d'emmagatzematge, separat del navegador del dispositiu i separat de les preferències natives de l'aplicació. A iOS, un WKWebView que fa servir un magatzem de dades no persistent oblida tot en tancar-se. Res no flueix entre les dues bandes tret que ho construeixis.

Tria una única font de veritat

La primera decisió és quina banda és propietària del consentiment. Per a la majoria d'aplicacions la resposta és el CMP natiu, perquè:

• S'executa primer, abans que s'obri cap WebView.
• Els SDK d'anuncis natius, que solen generar la major part dels ingressos, llegeixen l'emmagatzematge natiu.
• A iOS, es pot coordinar amb la sol·licitud d'App Tracking Transparency.

Començar pel web pot tenir sentit per a aplicacions híbrides la interfície completa de les quals és contingut web, però llavors has d'escriure la decisió de tornada a l'emmagatzematge natiu per als SDK natius.

Passar el consentiment natiu al WebView

Amb el natiu com a font de veritat, el WebView ha de veure la mateixa decisió. Patrons habituals:

1. Injectar una implementació de __tcfapi. Abans que s'executin els scripts de la pàgina, injecta un petit script que defineixi __tcfapi (i __gpp si cal) i respongui les crides amb la TC string i els valors llegits de l'emmagatzematge natiu. Les etiquetes d'anuncis de la pàgina obtenen llavors la decisió nativa mitjançant l'API estàndard.
2. Suprimir el bàner web. Configura el CMP web perquè es mantingui amagat quan la pàgina es carrega dins la teva aplicació, per exemple segons un paràmetre de consulta o un testimoni d'agent d'usuari personalitzat que controlis. Si no, l'usuari veu un segon bàner.
3. Passar la cadena en carregar. Alguns CMP web poden acceptar una cadena de consentiment existent en inicialitzar-se i adoptar-la. Consulta la documentació del teu CMP web per veure els mètodes admesos.

Sigui quin sigui el patró que facis servir, assegura't que els valors injectats s'actualitzin quan l'usuari canviï la seva elecció a la pantalla de configuració nativa, no només en el pròxim inici de l'aplicació.

Tornar el consentiment web al natiu

Si els usuaris poden canviar el consentiment dins del WebView, per exemple mitjançant una pàgina de configuració de privacitat, l'aplicació ho ha de saber. Fes servir un pont JavaScript: un gestor de missatges a iOS o una interfície JavaScript a Android. La banda web escolta amb __tcfapi('addEventListener', ...) i envia la cadena nova al codi natiu, que escriu les claus estàndard. Valida l'entrada del WebView abans d'escriure-la; accepta només missatges del teu propi contingut.

Anuncis dins dels WebViews

Els anuncis renderitzats en un WebView són anuncis web. Llegeixen el consentiment de la pàgina, no de l'emmagatzematge natiu, tret que el SDK d'anuncis ofereixi una manera de vincular-los. El Mobile Ads SDK de Google, per exemple, ofereix una API per registrar WebViews de manera que els anuncis que hi ha dins puguin fer servir senyals de l'aplicació; consulta la documentació actual del teu SDK. En qualsevol cas, confirma amb una prova que les sol·licituds d'anuncis des del WebView porten la mateixa TC string o GPP string que les sol·licituds natives.

Llista de verificació de proves

• Instal·lació nova: una sola petició de consentiment, no dues.
• Rebutja-ho tot al CMP natiu, obre un WebView, inspecciona les sol·licituds d'anuncis: la cadena ha de reflectir el rebuig.
• Canvia el consentiment a la configuració nativa, torna a un WebView obert: la pàgina ha de veure la decisió nova.
• Si existeix una configuració web, canvia-hi el consentiment i confirma que les claus natives s'actualitzen.
• Tanca l'aplicació de manera forçada i torna-la a llançar: les decisions persisteixen a totes dues bandes.
• Prova-ho tant a iOS com a Android, ja que l'emmagatzematge dels WebViews es comporta de manera diferent a cadascun.

Idees clau

• El consentiment natiu i el del WebView viuen en magatzems separats i no se sincronitzen per defecte.
• Tria una única font de veritat; per a la majoria d'aplicacions és el CMP natiu.
• Exposa el consentiment natiu al contingut web mitjançant un __tcfapi o __gpp injectat i amaga el bàner web.
• Fes servir un pont JavaScript per enviar els canvis web de tornada a l'emmagatzematge natiu.
• Comprova que les sol·licituds d'anuncis des dels WebViews portin la mateixa cadena de consentiment que les natives.