Combiner le contenu natif et Web dans une application
Dans de nombreux cas, une application mobile se compose d'une partie native (par exemple écrite en Java ou Kotlin ou C++, etc.) et d'une partie Web (généralement obtenue en insérant une vue Web dans l'application). Afin d'optimiser l'expérience utilisateur, vous pouvez utiliser certaines recommandations et stratégies de mise en œuvre.
Configuration de base
En général, nous recommandons d'utiliser notre SDK pour iOS or Android afin d'intégrer la CMP dans votre application (partie native). Le CMP sera généralement déclenché au démarrage de l'application, affichera la couche de consentement et laissera l'utilisateur faire ses choix. Une fois que l'utilisateur a fait ses choix, le SDK supprimera la couche de consentement et l'application continuera.
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 vue Web doit également inclure le code CMP (Implémentation HTML du code).
Échange d'informations de consentement
Avec la configuration de base ci-dessus, le problème est qu'un utilisateur sera invité deux fois : une fois au démarrage de l'application et une fois à chaque fois qu'une (nouvelle) vue Web s'ouvre. Afin d'éviter cela, les informations de consentement peuvent être échangées entre SDK et WebView. Cela se fait en exportant les données de consentement du SDK et en les joignant à l'URL qui est chargée dans la vue Web.
Mise en situation :
consentData = CMPStorageConsentManager.exportCMPData(this);
myWebView.loadURL("https://mywebsite.com/....#cmpimport=" + consentData);(Une fonction d'exportation existe pour les deux SDK, l'exemple ci-dessus est tiré des exemples iOS)
Une fois la vue Web chargée, le code CMP de 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 des cookies ou du stockage local. Étant donné que les données de consentement ont été importées dans la CMP, la couche de consentement ne devrait normalement pas apparaître (à nouveau) car le consentement de l'utilisateur existe déjà.
Notez que, que les informations de consentement ne peuvent être partagées que du SDK vers la vue Web et non dans le sens inverse.
Réglage fin
Comme dernière étape, il y aura peut-être quelques ajustements que vous aimerez faire.
D'une part, le code CMP qui est intégré à la webview ne doit pas afficher l'icône du centre de préférences (généralement sur le côté inférieur gauche de la fenêtre du navigateur, permettant aux visiteurs de mettre à jour leurs choix). Pour désactiver l'icône, rendez-vous sur Menu > Paramètres juridiques > RGPD/CCPA/... > Afficher l'icône Préférences.
D'autre part, même avec le #cmpimport=... sur l'URL, il peut toujours y avoir des cas où le CMP décide d'afficher la couche de consentement dans la vue Web. Afin d'éviter cela, nous vous recommandons d'ajouter un configuration côté client variable à 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 couche de consentement.
QFP
Puis-je utiliser le même CMP dans le SDK et le webview ?
Oui. Pour le système, peu importe que le même CMP ou un CMP différent soit utilisé dans le SDK, votre vue Web et/ou votre site Web normal. 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, étant donné que dans la plupart des cas, l'application a des besoins différents en termes de comportement et de conception, il est généralement préférable de séparer les app-CMP et les web-CMP. Il en va de même pour les conceptions : en général, la même conception peut être utilisée dans tous les environnements, mais dans de nombreux cas, il est logique d'avoir une conception distincte pour l'environnement de l'application.
Recommandation: Si vous utilisez différents CMP dans votre application et sur votre site Web, nous vous recommandons d'utiliser le même CMP, qui est utilisé dans la partie native de votre application, pour l'utiliser également dans les vues Web de votre application.
Quels sont les avantages et les inconvénients d'utiliser le même/un CMP différent ?
Voici quelques avantages à utiliser la même CMP dans tous vos environnements :
- une gestion plus facile des listes de fournisseurs, des finalités et des cookies puisque tous les environnements utilisent la même configuration
- aucune friction lorsque les données de consentement sont transférées d'un environnement à un autre
Voici les inconvénients de l'utilisation de la même CMP dans tous vos environnements :
- la liste des fournisseurs est potentiellement plus longue que lorsque les CMP sont séparés (puisqu'une liste de fournisseurs combinée doit inclure tous les fournisseurs de tous les environnements)
- aucune possibilité de distinguer certains paramètres généraux (par exemple, les paramètres généraux tels que l'URL de confidentialité, l'URL T&C ou les paramètres juridiques tels que la prise en charge de GDPR, CCPA et autres)
- plus compliqué lorsque différents designs doivent être utilisés (l'utilisation de ciblages peut être nécessaire)
Que se passe-t-il lorsque deux CMP différents sont utilisés ?
Dans le cas où le CMP utilisé dans la partie native de l'application est un CMP différent de celui de la vue Web, les informations de consentement du SDK natif sont importées dans la CMP de la vue Web. Dans les cas où il y a une différence entre la liste d'objectifs et/ou la liste de fournisseurs des deux CMP, le CMP importateur (celui de la vue Web) traitera tous les objectifs et fournisseurs manquants comme "sans consentement" / "exclu". Pour illustrer cela, supposons la configuration suivante :
CMP dans la partie native de l'application :
Objectifs : A, B, C
Vendeurs : 1, 2, 3
CMP dans la vue Web :
Objectifs : C, D, E
Vendeurs : 3, 4, 5
Au cas où l'utilisateur accepte dans la partie native, le résultat sera :
CMP dans la partie native de l'application :
Objectifs : A=accepté, B=accepté, C=accepté
Vendeurs : 1=accepté, 2 =accepté, 3 =accepté
CMP dans la vue Web :
Objectifs : C=accepté, D=rejeté, E=rejeté
Vendeurs : 3=accepté, 4 =rejeté, 5 =rejeté
Au cas où l'utilisateur rejette dans la partie native, le résultat sera :
CMP dans la partie native de l'application :
Objectifs : A=rejeté, B=rejeté, C=rejeté
Vendeurs : 1=rejeté, 2 =rejeté, 3 =rejeté
CMP dans la vue Web :
Objectifs : C=rejeté, D=rejeté, E=rejeté
Vendeurs : 3=rejeté, 4 =rejeté, 5 =rejeté
Notez que que son comportement est indépendant de l'affectation des vendeurs à des fins. Cela signifie que le résultat sera le même que celui décrit ci-dessus, même si tous les fournisseurs sont affectés à l'objectif C.
Notez que que son comportement est également indépendant des bases juridiques utilisées de chaque fournisseur/objectif et indépendant de la juridiction dans laquelle se trouve l'utilisateur.
