In molti casi un'app mobile è composta da una parte nativa (ad esempio scritta in Java, Kotlin o C++ e così via) e da una parte web (di solito realizzata inserendo una webview nell'app). Per ottimizzare l'esperienza utente, ci sono alcune raccomandazioni e strategie di implementazione che puoi utilizzare.

Configurazione di base

In generale, consigliamo di utilizzare il nostro SDK per iOS o Android per integrare il CMP nella tua app (parte nativa). Il CMP verrà solitamente attivato all'avvio dell'app, visualizzerà il layer di consenso e consentirà all'utente di effettuare le proprie scelte. Una volta che l'utente avrà effettuato le scelte, l'SDK rimuoverà il layer di consenso e l'app proseguirà.

Nei casi in cui l'app includa una webview, anche il contenuto di questa webview (ad es. una pagina web che contiene pubblicità) dovrà sapere se è stato dato il consenso e potrebbe essere necessario il supporto per API come IAB TCF o IAB GPP. Pertanto, la pagina web caricata all'interno della webview dovrebbe includere anche il codice CMP (implementazione HTML del codice).

Scambio di informazioni sul consenso

Con la configurazione di base sopra descritta, il problema è che all'utente verrà chiesto il consenso due volte: una volta all'avvio dell'app e una volta ogni volta che si apre una (nuova) webview. Per evitare ciò, le informazioni sul consenso possono essere scambiate tra l'SDK e la webview. Ciò avviene esportando i dati relativi al consenso dall'SDK e allegandoli all'URL caricato all'interno della webview.

Esempio:

// Swift version
let consentData = cmpManager.exportCMPString()
if let url = URL(string: "https://mywebsite.com/....#cmpimport=" + consentData) {
    myWebView.load(URLRequest(url: url))
}

// Kotlin version
val consentData = cmpManager.exportCMPString()
myWebView.loadUrl("https://mywebsite.com/....#cmpimport=" + consentData)

 

La exportCMPInfo funzione è disponibile per entrambi gli SDK, iOS e Android.

Una volta caricata la webview, il codice CMP al suo interno verrà eseguito e individuerà l'hash (#cmpimport=.....) nell'URL. Il CMP importerà automaticamente questi dati di consenso e non utilizzerà più i dati provenienti dai cookie o dalla memoria locale. Poiché i dati di consenso sono stati importati nel CMP, il layer di consenso normalmente non dovrebbe apparire (di nuovo) poiché il consenso dell'utente esiste già.

Messa a punto

Come ultimo passaggio potresti voler apportare qualche ritocco.

Da un lato, il codice CMP integrato nella webview non dovrebbe mostrare l'icona del centro preferenze (di solito nella parte inferiore sinistra della finestra del browser, che consente ai visitatori di aggiornare le proprie scelte). Per disabilitare l'icona, vai su Menu > Impostazioni legali > GDPR/CCPA/… > Mostra icona preferenze.

D'altra parte, anche con il #cmpimport=... nell'URL, possono comunque esserci casi in cui il CMP decide di mostrare il layer di consenso nella webview. Per evitarlo, consigliamo di aggiungere una variabile di configurazione lato client a tutte le pagine visualizzate all'interno della webview:

<script>
 window.cmp_noscreen = true;
</script>
... your CMP-Code ...

Questo impedirà la visualizzazione del popup di consenso.

Domande frequenti

Posso utilizzare lo stesso CMP nell'SDK e nella webview?

Sì. Per il sistema non ha importanza se nell'SDK, nella tua webview e/o nel tuo sito web normale venga utilizzato lo stesso CMP o un CMP diverso. Puoi utilizzare lo stesso CMP o CMP diversi in tutti gli ambienti e tutti i CMP possono importare i dati di consenso l'uno dall'altro.

Tuttavia, poiché nella maggior parte dei casi l'app ha esigenze diverse in termini di comportamento e design, di solito è meglio separare le CMP per app e quelle per il web. Lo stesso vale per il design: in generale è possibile utilizzare lo stesso design in tutti gli ambienti, ma in molti casi ha senso avere un design separato per l'ambiente dell'app.

Quali sono i pro e i contro dell'utilizzo dello stesso CMP o di uno diverso?

Ecco alcuni vantaggi dell'utilizzo dello stesso CMP in tutti i tuoi ambienti:

• gestione più semplice di elenchi di fornitori, finalità e cookie poiché tutti gli ambienti utilizzano la stessa configurazione
• nessun intoppo quando i dati relativi al consenso vengono trasferiti da un ambiente all'altro

Questi sono gli svantaggi dell'utilizzo dello stesso CMP in tutti i tuoi ambienti:

• L'elenco dei fornitori è potenzialmente più lungo rispetto a quando i CMP sono separati (poiché un elenco combinato deve includere tutti i fornitori di tutti gli ambienti)
• non è possibile distinguere alcune impostazioni generali (ad es. impostazioni generali come l'URL della privacy, l'URL dei T&C, o impostazioni legali come il supporto per GDPR, CCPA e altre)
• La situazione si complica quando è necessario utilizzare design diversi (potrebbe essere necessario ricorrere al targeting)

Cosa succede quando si utilizzano due CMP diversi?

Nel caso in cui il CMP utilizzato nella parte nativa dell'app sia diverso da quello nella webview, le informazioni sul consenso provenienti dall'SDK nativo vengono importate nel CMP della webview. Nei casi in cui vi sia una differenza tra l'elenco delle finalità e/o l'elenco dei fornitori dei due CMP, il CMP di importazione (quello nella webview) tratterà tutte le finalità e i fornitori mancanti come "nessun consenso" / "opt-out". Per illustrare questo concetto, ipotizziamo la seguente configurazione:

CMP nella parte nativa dell'app:
Finalità: A, B, C
Fornitori: 1, 2, 3

CMP nella webview:
Finalità: C, D, E
Fornitori: 3, 4, 5

Nel caso in cui l'utente accetti nella parte in lingua locale, il risultato sarà:

CMP nella parte nativa dell'app:
Finalità: A=accettata, B=accettata, C=accettata
Fornitori: 1=accettato, 2=accettato, 3=accettato

CMP nella webview:
Finalità: C=accettato, D=rifiutato, E=rifiutato
Fornitori: 3=accettato, 4=rifiutato, 5=rifiutato

Nel caso in cui l'utente rifiuti la parte in lingua originale, il risultato sarà:

CMP nella parte nativa dell'app:
Finalità: A=rifiutato, B=rifiutato, C=rifiutato
Fornitori: 1=rifiutato, 2=rifiutato, 3=rifiutato

CMP nella visualizzazione web:
Finalità: C=rifiutato, D=rifiutato, E=rifiutato
Fornitori: 3=rifiutato, 4=rifiutato, 5=rifiutato