Dans de nombreux cas, une application mobile se compose d'une partie native (par exemple, écrite en Java, Kotlin ou C++, etc.) et d'une partie web (généralement réalisée en intégrant une vue web dans l'application). Afin d'optimiser l'expérience utilisateur, il existe certaines recommandations et stratégies de mise en œuvre que vous pouvez utiliser.

Configuration de base

En général, nous recommandons d'utiliser notre SDK pour iOS ou Android afin d'intégrer le CMP dans votre application (partie native). Le CMP se déclenche généralement au démarrage de l'application, affiche la fenêtre de consentement et laisse l'utilisateur faire ses choix. Une fois que l'utilisateur a fait ses choix, le SDK supprime la fenêtre de consentement et l'application continue.

Dans les cas où l'application inclut une vue Web, le contenu de cette vue Web (par exemple, une page Web contenant de la publicité) devra également savoir si le consentement a été donné et la prise en charge d'API telles que l'IAB TCF ou l'IAB GPP pourrait être nécessaire. Par conséquent, la page web chargée dans la webview doit également inclure le code CMP (implémentation HTML du code).

Échange d'informations relatives au consentement

Avec la configuration de base ci-dessus, le problème est qu'un utilisateur sera interrogé deux fois : une fois au démarrage de l'application et une fois à chaque ouverture d'une (nouvelle) vue Web. Pour éviter cela, les informations de consentement peuvent être échangées entre le SDK et la vue Web. Pour ce faire, il suffit d'exporter les données de consentement depuis le SDK et de les joindre à l'URL chargée dans la vue Web.

Exemple :

// 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 fonction existe pour les deux SDK, iOS et Android.

Une fois la vue Web chargée, le code CMP dans la vue Web s'exécutera et trouvera le hachage (#cmpimport=.....) dans l’URL. Le CMP importera automatiquement ces données de consentement et n’utilisera plus les données issues des cookies ou du stockage local. Étant donné que les données de consentement ont été importées dans le CMP, la couche de consentement ne devrait normalement pas s’afficher (à nouveau) car le consentement de l’utilisateur existe déjà.

Mise au point

Pour finir, vous souhaiterez peut-être apporter quelques ajustements.

D'une part, le code CMP intégré à la vue Web ne doit pas afficher l'icône du centre de préférences (généralement située en bas à gauche de la fenêtre du navigateur, permettant aux visiteurs de mettre à jour leurs choix). Pour désactiver cette icône, veuillez vous rendre dans Menu > Paramètres juridiques > RGPD/CCPA/… > Afficher l'icône des préférences.

D'autre part, même avec le #cmpimport=... dans l'URL, il peut encore y avoir des cas où le CMP décide d'afficher la couche de consentement dans la vue Web. Afin d'éviter cela, nous recommandons d'ajouter une variable de configuration côté client à toutes les pages affichées dans la vue Web :

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

Cela empêchera l'affichage de la fenêtre de consentement.

FAQ

Puis-je utiliser le même CMP dans le SDK et dans la vue Web ?

Oui. Pour le système, peu importe que le même CMP ou un CMP différent soit utilisé dans le SDK, votre webview et/ou votre site web standard. Vous pouvez utiliser le même CMP ou différents CMP dans tous les environnements, et tous les CMP peuvent importer les données de consentement les uns des autres.

Cependant, comme dans la plupart des cas, l'application a des besoins différents en matière de comportement et de conception, il est généralement préférable de séparer les CMP pour applications et les CMP pour le Web. Il en va de même pour les designs : en général, le même design peut être utilisé dans tous les environnements, mais dans de nombreux cas, il est judicieux d'avoir un design distinct pour l'environnement de l'application.

Quels sont les avantages et les inconvénients d'utiliser la même plateforme de gestion de contenu (CMP) ou une autre ?

Voici quelques avantages à utiliser la même plateforme de gestion de contenu (CMP) dans tous vos environnements :

• Gestion plus facile des listes de fournisseurs, des finalités et des cookies, car tous les environnements utilisent la même configuration
• Aucune friction lors du transfert des données de consentement d'un environnement à un autre

Voici les inconvénients liés à l'utilisation du même CMP dans tous vos environnements :

• La liste des fournisseurs est potentiellement plus longue que lorsque les CMP sont séparés (car une liste combinée doit inclure tous les fournisseurs de tous les environnements)
• Impossible de distinguer certains paramètres généraux (par exemple, les paramètres généraux tels que l'URL de la politique de confidentialité, l'URL des conditions générales, ou les paramètres juridiques tels que la prise en charge du RGPD, du CCPA et autres)
• La tâche est plus compliquée lorsqu'il faut utiliser des designs différents (le ciblage peut s'avérer nécessaire).

Que se passe-t-il lorsque deux CMP différents sont utilisés ?

Si la plateforme de gestion du consentement (CMP) utilisée dans la partie native de l'application est différente de celle de la vue Web, les informations de consentement provenant du SDK natif sont importées dans la CMP de la vue Web. En cas de différence entre la liste des finalités et/ou la liste des fournisseurs des deux CMP, le CMP importateur (celui de la vue Web) traitera toutes les finalités et tous les fournisseurs manquants comme « sans consentement » / « désactivés ». Pour illustrer cela, prenons l'exemple de la configuration suivante :

CMP dans la partie native de l'application :
Objectifs : A, B, C
Fournisseurs : 1, 2, 3

CMP dans la vue Web :
Objectifs : C, D, E
Fournisseurs : 3, 4, 5

Si l'utilisateur accepte la partie en langue locale, le résultat sera :

CMP dans la partie native de l'application :
Objectifs : A = accepté, B = accepté, C = accepté
Fournisseurs : 1 = accepté, 2 = accepté, 3 = accepté

CMP dans la vue Web :
Objectifs : C = accepté, D = rejeté, E = rejeté
Fournisseurs : 3 = accepté, 4 = rejeté, 5 = rejeté

Si l'utilisateur rejette la partie en langue source, le résultat sera :

CMP dans la partie native de l'application :
Objectifs : A = rejeté, B = rejeté, C = rejeté
Fournisseurs : 1 = rejeté, 2 = rejeté, 3 = rejeté

CMP dans la vue Web :
Objectifs : C = rejeté, D = rejeté, E = rejeté
Fournisseurs : 3 = rejeté, 4 = rejeté, 5 = rejeté