Google Consent Mode v2 (avancé) - RGPD
Type d'accès: Notices de consentement - Éditeur
Google Consent Mode v2 garantit que les fournisseurs Google associés à un avis de consentement respectent les choix de consentement de l'utilisateur final (appelés types de consentement) définis par Google. Dans cet article, nous verrons comment implémenter Google Consent Mode v2 sur un avis de consentement en utilisant la configuration avancée de Google Consent Mode.
Cliquez ici pour obtenir des informations sur la configuration du mode de consentement Google de base.
Vue d'ensemble de Google Consent Mode v2 (Avancé)
Dans la version avancée de Google Consent Mode v2, les balises produit Google se chargent toujours lorsqu'un utilisateur final accède à votre site Web ou application (contrairement à la version de base). Les balises Google chargeront l'API du mode de consentement et effectueront les actions suivantes :
Définir les états de consentement par défaut pour types de consentement. Par défaut, le consentement peut être
refusé, sauf si votre organisation définit ses propres valeurs par défaut. Lorsque le consentement estrefusé, les balises Google envoient des pings sans cookie.Attendre l'interaction de l'utilisateur final avec l'avis de consentement et mettre à jour les états de consentement en conséquence. Ce n'est que lorsque l'utilisateur final accorde son consentement à la collecte de données que les balises Google enverront l'ensemble des données de mesure. En savoir plus sur le comportement des balises.

Produits du mode de consentement Google
Les produits Google suivants disposent de vérifications de consentement et adapteront leur comportement en fonction de l'état de consentement de l'utilisateur final pour types de consentement:
Google Tag
Google Analytics (inclut le SDK Google Analytics pour Firebase)
Google Ads (inclut le suivi des conversions Google Ads et le remarketing ; la prise en charge des conversions par appel téléphonique est en attente.)
Floodlight
Conversion Linker
Google Consent Mode ne prend en charge que gtag.js . Assurez-vous que votre organisation n'utilise pas de balises héritées pour vos produits Google telles que ga.js, analytics.js, ou conversion.js .
La vérification du consentement varie selon chaque produit Google et peut être consultée en sélectionnant un fournisseur sur la plateforme GTM et en développant l'onglet Paramètres avancés > Paramètres de consentement .

Implémenter Google Consent Mode v2 (Avancé) - RGPD
Didomi propose plusieurs façons pour votre organisation d'implémenter Google Consent Mode v2 (Avancé) pour les avis de consentement RGPD. Veuillez consulter les onglets ci-dessous pour la méthode qui convient le mieux aux besoins de votre organisation :
Dans cet onglet, nous verrons comment utiliser Google Tag Manager pour implémenter Google Consent Mode v2 (Avancé) pour un avis de consentement RGPD.
Configurer Google Consent Mode v2 (Avancé) sur l'avis de consentement
Depuis l'avis de consentement, cliquez sur l'onglet Personnalisation et sélectionnez Intégrations.

Cliquez Modes de consentement et activez le bouton bascule en ligne avec Google Consent Mode v2.

Développez l'accordéon Google Consent Mode v2 pour configurer les détails de l'intégration. Consultez le tableau ci-dessous pour obtenir des informations sur chaque bouton bascule de la configuration de l'intégration :
Remarque: Afin de mettre en œuvre avec succès Google Consent Mode v2 (Avancé) pour le RGPD, votre organisation va devoir activer les produits publicitaires Google et/ou les produits Google Analytics en fonction des produits Google utilisés par votre organisation.
Définir l'état par défaut de Google Consent Mode lorsque la page se charge
La version avancée de Google Consent Mode v2 chargera les balises Google lorsqu'un utilisateur final accède à votre site Web avec un état par défaut pour tous les types de consentement Google. L'état par défaut est refusé sauf configuration contraire ci-dessous.
Activez ce bouton bascule pour vous assurer que cet état par défaut est défini pour la version avancée.
Activer les produits publicitaires Google
Ajoutera le fournisseur Google Advertising Products (ID d'API : google) à l'avis de consentement. Conçu pour englober les produits Google qui utilisent un ou plusieurs des types de consentement suivants :
ad_storagead_user_dataad_personalizationfunctionality_storagepersonalization_storagesecurity_storage
Activer {consent type} avant que l'utilisateur n'accorde son consentement
Pour chaque type de consentement, remplacera l'état par défaut du type de consentement Google et le définira sur accordé dès que la balise produit Google se charge.
Remarque: Consultez le service juridique de votre organisation et votre DPO avant d'activer l'un de ces paramètres.
Activer les produits Google Analytics
Ajoutera le fournisseur Google Analytics Products (ID d'API : googleana-4TXnJigR) à l'avis de consentement. Conçu pour englober les produits Google qui nécessitent le analytics_storage type de consentement.
Activer l'intégration TCF avec Google Consent Mode
Permet à Didomi de définir un indicateur supplémentaire (TCData.enableAdvertiserConsentMode à true) pour les commandes getTCData et addEventListener .
Cet indicateur supplémentaire permet à Google de déduire et de mapper les paramètres de consentement aux types de consentement Google Consent Mode v2 suivants en fonction des finalités IAB TCF :
ad_storagead_user_dataad_personalization
Cliquez ici pour plus d'informations sur la manière dont Google calcule le mappage entre les finalités IAB TCF et les types de consentement Google.
Remarque: L'intégration TCF avec Google Consent Mode ne prend pas en charge les balises produit Google qui nécessitent les analytics_storage, functionality_storage, personalization_storage, ou security_storage types de consentement.
Pour les produits Google qui nécessitent le analytics_storage type de consentement, Didomi définira ce type de consentement sur accordé si l'utilisateur final donne son consentement global (consentement au fournisseur et à toutes ses finalités) pour les produits Google Analytics (ID d'API : googleana-4TXnJigR).
Nom de la couche de données
Par défaut, Didomi utilise dataLayer comme nom de variable pour la couche de données Google Tag Manager de votre organisation. Si votre organisation a modifié le nom de la variable de votre dataLayer, saisissez ce nom de variable dans l'espace prévu.

Publiez et intégrez le SDK Web Didomi sur votre site Web une fois terminé.
Votre organisation peut également utiliser l'objet window.didomiConfig pour configurer Google Consent Mode v2 (Avancé) sur votre avis de consentement. Bien que Didomi recommande d'utiliser la console pour activer la fonctionnalité comme détaillé ci-dessus, la window.didomiConfig méthode peut être utile pour les tests.
Configurer les balises produit Google
Remarque: Cette section suppose que votre organisation a déjà intégré la balise Google Tag Manager sur votre site Web.
Afin de garantir que les balises produit Google sont chargées (et que l'état par défaut des types de consentement Google est exposé), votre organisation doit configurer les balises produit Google pour qu'elles se chargent uniquement une fois que le SDK Didomi est prêt et que Google Consent Mode v2 est défini.
Votre organisation dispose de deux méthodes pour configurer les balises produit Google. Choisissez ci-dessous la méthode qui convient le mieux au cas d'utilisation de votre organisation :
Modifier la balise Google Tag Manager sur la page
Utilisez Didomi <script> les attributs de balise pour modifier les balises Google Tag Manager sur votre site Web afin d'inclure type="didomi/javascript" . Les balises produit Google configurées dans votre Google Tag Manager se chargeront dès que le SDK sera prêt, mais sans lien spécifique vers un fournisseur.
Balises produit Google dans Google Tag Manager
Depuis l'espace de travail Google Tag Manager de votre organisation, accédez à votre balise produit Google et modifiez le déclencheur.

Utilisez le flux de travail Google Tag Manager pour configurer un nouveau déclencheur pour la balise produit Google avec les champs suivants :
Type de déclencheur
Événement personnalisé
Nom de l'événement
Ce déclencheur se déclenche sur
Tous les événements personnalisés

Une fois terminé, enregistrez la configuration du déclencheur et de la balise. Soumettez les modifications de votre conteneur Google Tag Manager conformément aux politiques de votre organisation.
Dans cet onglet, nous verrons comment implémenter Google Consent Mode v2 (Avancé) pour un avis de consentement RGPD si votre organisation utilise gtag.js des balises pour les produits Google directement sur votre site Web.
Configurer Google Consent Mode v2 (Avancé) sur l'avis de consentement
Depuis l'avis de consentement, cliquez sur l'onglet Personnalisation et sélectionnez Intégrations.

Cliquez Modes de consentement et activez le bouton bascule en ligne avec Google Consent Mode v2.

Développez l'accordéon Google Consent Mode v2 pour configurer les détails de l'intégration. Consultez le tableau ci-dessous pour obtenir des informations sur chaque bouton bascule de la configuration de l'intégration :
Remarque: Afin de mettre en œuvre avec succès Google Consent Mode v2 (Avancé) pour le RGPD, votre organisation va devoir activer les produits publicitaires Google et/ou les produits Google Analytics en fonction des produits Google utilisés par votre organisation.
Définir l'état par défaut de Google Consent Mode lorsque la page se charge
La version avancée de Google Consent Mode v2 chargera les balises Google lorsqu'un utilisateur final accède à votre site Web avec un état par défaut pour tous les types de consentement Google. L'état par défaut est refusé sauf configuration contraire ci-dessous.
Activez ce bouton bascule pour vous assurer que cet état par défaut est défini pour la version avancée.
Activer les produits publicitaires Google
Ajoutera le fournisseur Google Advertising Products (ID d'API : google) à l'avis de consentement. Conçu pour englober les produits Google qui utilisent un ou plusieurs des types de consentement suivants :
ad_storagead_user_dataad_personalizationfunctionality_storagepersonalization_storagesecurity_storage
Activer {consent type} avant que l'utilisateur n'accorde son consentement
Pour chaque type de consentement, remplacera l'état par défaut du type de consentement Google et le définira sur accordé dès que la balise produit Google se charge.
Remarque: Consultez le service juridique de votre organisation et votre DPO avant d'activer l'un de ces paramètres.
Activer les produits Google Analytics
Ajoutera le fournisseur Google Analytics Products (ID d'API : googleana-4TXnJigR) à l'avis de consentement. Conçu pour englober les produits Google qui nécessitent le analytics_storage type de consentement.
Activer l'intégration TCF avec Google Consent Mode
Permet à Didomi de définir un indicateur supplémentaire (TCData.enableAdvertiserConsentMode à true) pour les commandes getTCData et addEventListener .
Cet indicateur supplémentaire permet à Google de déduire et de mapper les paramètres de consentement aux types de consentement Google Consent Mode v2 suivants en fonction des finalités IAB TCF :
ad_storagead_user_dataad_personalization
Cliquez ici pour plus d'informations sur la manière dont Google calcule le mappage entre les finalités IAB TCF et les types de consentement Google.
Remarque: L'intégration TCF avec Google Consent Mode ne prend pas en charge les balises produit Google qui nécessitent les analytics_storage, functionality_storage, personalization_storage, ou security_storage types de consentement.
Pour les produits Google qui nécessitent le analytics_storage type de consentement, Didomi définira ce type de consentement sur accordé si l'utilisateur final donne son consentement global (consentement au fournisseur et à toutes ses finalités) pour les produits Google Analytics (ID d'API : googleana-4TXnJigR).
Nom de la couche de données
Par défaut, Didomi utilise dataLayer comme nom de variable pour la couche de données Google Tag Manager de votre organisation. Si votre organisation a modifié le nom de la variable de votre dataLayer, saisissez ce nom de variable dans l'espace prévu.

Publiez et intégrez le SDK Web Didomi sur votre site Web une fois terminé.
Votre organisation peut également utiliser l'objet window.didomiConfig pour configurer Google Consent Mode v2 (Avancé) sur votre avis de consentement. Bien que Didomi recommande d'utiliser la console pour activer la fonctionnalité comme détaillé ci-dessus, la window.didomiConfig méthode peut être utile pour les tests.
Installer les balises produit Google
Ajoutez les balises nécessaires pour vos produits Google prenant en compte le consentement (par ex. Floodlight, Conversion Linker, etc...) à votre site Web.
Conformément à une configuration Google Consent Mode v2 (Avancé), ces produits Google se chargeront toujours lorsqu'un utilisateur final accède au site Web. Par défaut, l'état de consentement pour tous les types de consentement Google sera refusé sauf configuration contraire, et ces balises n'enverront que des pings sans cookie. Ce n'est que lorsqu'un utilisateur final aura accordé son consentement que les balises produit Google enverront des données de mesure complètes.
Afin de garantir que les balises produit Google sont chargées (et que l'état par défaut des types de consentement Google est exposé), votre organisation doit configurer chaque balise produit Google pour qu'elle se charge uniquement une fois que le SDK Didomi est prêt et que Google Consent Mode v2 est défini.
Utilisez Didomi <script> les attributs de balise pour modifier les balises produit Google sur votre site Web afin d'inclure type="didomi/javascript" .
Ne activez pas le bouton bascule Google Consent Mode v2 dans la console Didomi lorsque vous utilisez le modèle GTM comme méthode d'implémentation de Google Consent Mode v2 (Avancé).

Vous trouverez ci-dessous des informations sur l'implémentation de Google Consent Mode v2 (Avancé) via le modèle GTM Didomi :
Didomi a mis à jour sa prise en charge depuis la sortie de Google Custom Mode v2 avec des intégrations natives simplifiées avec Firebase et les partenaires d'applications avancés (AAP) comme Airbridge, ApplyFlyer, etc...
Les organisations qui ont implémenté la solution précédente Google Consent Mode v2 via setConsent la méthode doivent mettre à jour leurs implémentations à l'aide des instructions ci-dessous et supprimer setConsent de Google Consent Mode v2 dans le code de l'application.
Sur les applications mobiles, Google Consent Mode v2 fonctionne via des SDK tels que Firebase et les SDK Google Ads. Ces SDK s'appuient sur des signaux de consentement fournis par programmation à l'exécution. Les signaux de consentement doivent être transmis tôt dans le cycle de vie de l'application afin de garantir que les SDK Google respectent les choix de l'utilisateur.
Dans cet onglet, nous verrons comment implémenter Google Consent Mode v2 (Avancé) pour un avis de consentement RGPD destiné à une application mobile.
Exigences
Consultez le tableau ci-dessous pour plus d'informations sur la version minimale requise du SDK mobile Didomi utilisé dans votre application et prenant en charge le SDK Firebase et le SDK Google Ads :
iOS/tvOS
> v2.27.0
Android
> v2.27.0
Configurer Google Consent Mode v2 (Avancé) sur l'avis de consentement
Depuis l'avis de consentement, cliquez sur l'onglet Personnalisation et sélectionnez Intégrations.

Cliquez Modes de consentement et activez le bouton bascule en ligne avec Google Consent Mode v2.

Développez l'accordéon Google Consent Mode v2 pour configurer les détails de l'intégration. Consultez le tableau ci-dessous pour obtenir des informations sur chaque bouton bascule de la configuration de l'intégration :
Remarque: Afin de mettre en œuvre avec succès Google Consent Mode v2 (Avancé) pour le RGPD, votre organisation va devoir activer les produits publicitaires Google et/ou les produits Google Analytics en fonction des produits Google utilisés par votre organisation.
Définir l'état par défaut de Google Consent Mode lorsque la page se charge
La version avancée de Google Consent Mode v2 chargera les balises Google lorsqu'un utilisateur final accède à votre site Web avec un état par défaut pour tous les types de consentement Google. L'état par défaut est refusé sauf configuration contraire ci-dessous.
Activez ce bouton bascule pour vous assurer que cet état par défaut est défini pour la version avancée.
Activer les produits publicitaires Google
Ajoutera le fournisseur Google Advertising Products (ID d'API : google) à l'avis de consentement. Conçu pour englober les produits Google qui utilisent un ou plusieurs des types de consentement suivants :
ad_storagead_user_dataad_personalizationfunctionality_storagepersonalization_storagesecurity_storage
Activer {consent type} avant que l'utilisateur n'accorde son consentement
Pour chaque type de consentement, remplacera l'état par défaut du type de consentement Google et le définira sur accordé dès que la balise produit Google se charge.
Remarque: Consultez le service juridique de votre organisation et votre DPO avant d'activer l'un de ces paramètres.
Activer les produits Google Analytics
Ajoutera le fournisseur Google Analytics Products (ID d'API : googleana-4TXnJigR) à l'avis de consentement. Conçu pour englober les produits Google qui nécessitent le analytics_storage type de consentement.
Activer l'intégration TCF avec Google Consent Mode
Permet à Didomi de définir un indicateur supplémentaire (TCData.enableAdvertiserConsentMode à true) pour les commandes getTCData et addEventListener .
Cet indicateur supplémentaire permet à Google de déduire et de mapper les paramètres de consentement aux types de consentement Google Consent Mode v2 suivants en fonction des finalités IAB TCF :
ad_storagead_user_dataad_personalization
Cliquez ici pour plus d'informations sur la manière dont Google calcule le mappage entre les finalités IAB TCF et les types de consentement Google.
Remarque: L'intégration TCF avec Google Consent Mode ne prend pas en charge les balises produit Google qui nécessitent les analytics_storage, functionality_storage, personalization_storage, ou security_storage types de consentement.
Pour les produits Google qui nécessitent le analytics_storage type de consentement, Didomi définira ce type de consentement sur accordé si l'utilisateur final donne son consentement global (consentement au fournisseur et à toutes ses finalités) pour les produits Google Analytics (ID d'API : googleana-4TXnJigR).
Firebase
Firebase est le SDK principal pour les applications Google. Une fois activée, l'intégration garantit :
le mappage correct des signaux de consentement Didomi vers Firebase
la propagation automatique vers les SDK Google pour la mesure et la publicité
une conformité simplifiée avec le RGPD et les réglementations similaires
Branch
Partenaires d'attribution d'applications (AAP) comme Branch doivent recevoir des signaux de consentement précis pour se conformer aux réglementations relatives à la confidentialité et transmettent ces signaux à Google.
Lorsque Branch est activé dans la console et que le SDK Branch est présent dans votre application, Didomi gère la propagation des signaux Google Consent Mode pour Branch.
Pour les utilisateurs finaux situés dans des régions régies par le RGPD, Didomi indique le contexte de conformité en définissant eea à 1 et applique des valeurs par défaut aux signaux de consentement en fonction de votre configuration dans la console. Après que l'utilisateur final a donné son consentement, Didomi recalcule l'état de ces signaux à l'aide du consentement de l'utilisateur final pour les produits publicitaires Google et les produits Google Analytics, puis met à jour Branch en conséquence.
Pour les utilisateurs situés en dehors des régions RGPD, Didomi définit eea à 0 pour indiquer qu'aucune obligation RGPD ne s'applique.
Kochava
Partenaires d'attribution d'applications (AAP) comme Kochava doivent recevoir des signaux de consentement précis pour se conformer aux réglementations relatives à la confidentialité et transmettent ces signaux à Google.
Lorsque Kochava est activé dans la console, Didomi s'assure que Kochava reçoit la chaîne de consentement nécessaire pour renseigner les signaux de consentement de Google. Kochava utilise ces informations de consentement lors des transmissions d'installation et d'événements.
Lorsque le CMP collecte le consentement de l'utilisateur final, la chaîne de consentement est partagée avec Kochava via Didomi, à condition que le SDK soit configuré pour envoyer les installations ou les événements après que l'utilisateur a donné son consentement.
Kochava analyse la chaîne de consentement TCF et l'applique pour générer les signaux requis par Google. Ce processus fonctionne de manière transparente avec les CMP qui prennent en charge l'IAB Transparency & Consent Framework (TCF) v2.3 ou l'API Global Privacy Platform v1.1.
Airbridge
Partenaires d'attribution d'applications (AAP) comme Airbridge doivent recevoir des signaux de consentement précis pour se conformer aux réglementations relatives à la confidentialité et transmettent ces signaux à Google.
Lorsque Airbridge est activé dans la console et que le SDK Airbridge est détecté dans l'application, Didomi calcule les signaux appropriés de Google Consent Mode et les partage avec Airbridge.
Pour les utilisateurs finaux situés dans l'EEE (Espace économique européen) et donc soumis au RGPD, Didomi informe Airbridge que l'utilisateur se trouve dans une région réglementée en définissant eeaRegion à true. En même temps, Airbridge reçoit les valeurs par défaut des signaux de consentement en fonction de votre configuration dans le SDK Didomi. Une fois que l'utilisateur final a donné son consentement via le CMP, Didomi met à jour ces signaux et s'assure qu'Airbridge reflète les préférences réelles de l'utilisateur final.
Pour les utilisateurs finaux en dehors de l'EEE, Didomi signale que l'utilisateur final ne se trouve pas dans une région réglementée par le RGPD en définissant eeaRegion à false.
AppsFlyer
Partenaires d'attribution d'applications (AAP) comme AppsFlyer doivent recevoir des signaux de consentement précis pour se conformer aux réglementations relatives à la confidentialité et transmettent ces signaux à Google.
Lorsque AppsFlyer est activé dans la console et que le SDK AppsFlyer est présent dans votre application, Didomi gère la propagation des signaux Google Consent Mode pour AppsFlyer.
Pour les utilisateurs situés dans des régions régies par le RGPD, Didomi indique le contexte de conformité en définissant
isUserSubjectToGDPRàtrueet applique des valeurs par défaut aux signaux de consentement en fonction de votre configuration dans la console. Après que l'utilisateur final a donné son consentement, Didomi recalcule l'état de ces signaux à l'aide du consentement de l'utilisateur final pour les produits publicitaires Google et les produits Google Analytics et met à jour AppsFlyer en conséquence.Pour les utilisateurs en dehors de la juridiction du RGPD, Didomi définira
isUserSubjectToGDPRàfalse.Si vous avez activé l'intégration IAB TCF avec Google Consent Mode, Didomi demandera automatiquement à AppsFlyer d'utiliser la chaîne TC en définissant
enableTCFDataCollection(true). En conséquence, AppsFlyer peut obtenir directement le consentement de l'utilisateur à partir de la chaîne TC dansSharedPreferences
Tester Google Consent Mode v2 (Avancé) - RGPD
Lorsqu'une configuration correcte est en place, une implémentation Google Consent Mode v2 (Avancé) déclenchera les balises produit Google avec l'état de consentement des types de consentement Google défini par défaut sur refusé sauf configuration contraire. Dans cette section, nous verrons comment tester si votre configuration Google Consent Mode v2 (Avancé) fonctionne comme prévu.
Si vous avez besoin d'une assistance supplémentaire ou si vous avez remarqué quelque chose d'inhabituel, n'hésitez pas à contacter google-support@didomi.io.
Confirmer les fournisseurs de produits Google sur l'avis de consentement
Comme mentionné ci-dessus lors de la configuration, Google Consent Mode v2 (Avancé) nécessite l'utilisation des fournisseurs suivants : produits publicitaires Google (ID d'API : google) et/ou produits Google Analytics (ID d'API : googleana-4TXnJigR) selon les produits Google utilisés par votre organisation.
Avant de continuer, assurez-vous que les bons fournisseurs sont ajoutés à l'avis de consentement pour refléter les produits Google qui seront déclenchés :

Tester le déclenchement des produits Google
Lors du test de l'implémentation Google Consent Mode v2 (Avancé), votre organisation voudra confirmer trois actions :
Les produits Google se chargent avec des types de consentement dont l'état de consentement est défini par défaut sur
refusésauf configuration contraireLes produits Google se mettent à jour pour afficher des types de consentement définis avec un état de consentement
refuséen raison du choix de l'utilisateur finalLes produits Google se mettent à jour pour afficher des types de consentement définis avec un état de consentement
accordéen raison du choix de l'utilisateur final
La manière dont votre organisation teste que les balises produit Google se déclenchent comme prévu dans une configuration Google Consent Mode v2 (Avancé) dépend de la manière dont vous avez configuré l'implémentation sur l'avis de consentement :
Google Tag Manager
Google Tag Manager
Site Web
gtag.js
Site Web
Modèle GTM
Google Tag Manager
Site Web
SDK mobile
Journaux du SDK Didomi
Firebase DebugView
ADB (Android) ou console Xcode (iOS) pour les journaux d'exécution
Analyseurs réseau (par ex. Charles Proxy) pour vérifier les charges utiles des événements
Dans cet onglet, nous verrons comment tester l'implémentation Google Consent Mode v2 (Avancé) de votre organisation via le site Web sur lequel l'avis de consentement Didomi est déployé.
Il est recommandé d'effectuer les tests suivants dans une fenêtre de navigation privée de votre navigateur.
gcd paramètre
Le gcd paramètre est inclus dans la charge utile de chaque requête réseau Google Ads et Google Analytics lorsque Google Consent Mode v2 est activé. Le paramètre reflète l'état des types de consentement de Google Consent Mode v2 et assure à Google que le mode de consentement est activé et que le consentement est collecté.
Remarque: Bien que le gcd paramètre ne soit pas documenté publiquement par Google, il est disponible dans plusieurs articles.
Le gcd paramètre est une chaîne de caractères composée de plusieurs composants qui peuvent avoir plusieurs valeurs. Le format de la chaîne de caractères est le suivant :
gcd=13<ad_storage>3<analytics_storage>3<ad_user_data>3<ad_personalization>5
Préfixe
Début inchangé de la chaîne de caractères. Représenté par un 11 ou 13
Suffixe
Fin inchangée de la chaîne de caractères. Représentée par un 5 ou 7
Séparateur
Sépare les valeurs d'état de consentement pour les différents types de consentement (ad_storage, analytics_storage, etc...). Représenté par un 1 ou 3
État du consentement
L'état de consentement pour chacun des types de consentement représentés (ad_storage, analytics_storage, ad_user_data, ad_personalization) suit la structure ci-dessous :
p- Valeur par défaut refuséet- Valeur par défaut accordéeq,m,u- Refusé après le choix de l'utilisateur finale,r,n,v- Accordé après le choix de l'utilisateur final1- Indéfini
Exemple:
13t3p3p3p5
ad_storageest accordé par défautanalytics_storageest refusé par défautad_user_dataest refusé par défautad_user_personalizationest refusé par défaut
Les balises produit Google se chargent avec des types de consentement dont l'état par défaut est défini sur refusé
Accédez au site Web sur lequel vous avez déployé l'avis de consentement Didomi avec une implémentation Google Consent mode v2 (Avancé) et laissez l'avis de consentement se charger sur la page. Il est important que vous n'interagissiez pas encore avec l'avis de consentement.
Ouvrez la console du navigateur et sélectionnez le Réseau onglet. Utilisez le filtre de recherche fourni pour vérifier les requêtes qui contiennent ce qui suit pour le gcd paramètre :
analytics.js
gtag
collect

Assurez-vous que les valeurs d’état du consentement pour chaque type de consentement dans le gcd paramètre correspondent aux paramètres par défaut attendus.
Les balises des produits Google se mettent à jour pour afficher les types de consentement définis sur refusé en raison du choix de l'utilisateur final
Accédez au site web sur lequel vous avez déployé la bannière de consentement Didomi avec une implémentation Google Consent mode v2 (Advanced), puis laissez la bannière se charger sur la page. Refusez le consentement pour tous les fournisseurs et toutes les finalités.
Ouvrez la console du navigateur et sélectionnez le Réseau onglet. Vérifiez les requêtes de vos produits Google afin de vous assurer que la valeur d’état du consentement pour chaque type de consentement dans le gcd paramètre est défini sur refusé en raison du choix de l’utilisateur final.

Les balises des produits Google se mettent à jour pour afficher les types de consentement définis sur accordé en raison du choix de l'utilisateur final
Accédez au site web sur lequel vous avez déployé la bannière de consentement Didomi avec une implémentation Google Consent mode v2 (Advanced), puis laissez la bannière se charger sur la page. Accordez le consentement pour tous les fournisseurs et toutes les finalités.
Ouvrez la console du navigateur et sélectionnez le Réseau onglet. Vérifiez les requêtes de vos produits Google afin de vous assurer que la valeur d’état du consentement pour chaque type de consentement dans le gcd paramètre est défini sur accordé en raison du choix de l’utilisateur final.

Dans cet onglet, nous verrons comment tester l’implémentation Google Consent Mode v2 (Advanced) de votre organisation via Google Tag Manager.
Il est recommandé d’effectuer les tests suivants dans une fenêtre de navigation privée de votre navigateur ou de supprimer les cookies et le stockage local de votre site web dans votre navigateur préféré.
Accédez au conteneur dans lequel vous avez configuré et publié votre Google Consent Mode v2 (Advanced) dans votre compte Google Tag Manager et cliquez sur Aperçu.

Utilisez le champ fourni pour saisir l’URL de votre site web sur lequel la bannière de consentement Didomi est implémentée. Cliquez sur Connecter une fois terminé.

Les balises produit Google se chargent avec des types de consentement dont l'état par défaut est défini sur refusé
Laissez la bannière de consentement se charger dans la fenêtre suivante de Tag Assistant. Il est important que vous n’interagissiez pas encore avec la bannière de consentement.
Assurez-vous que les balises de vos produits Google ne se déclenchent pas avant l’ didomi-ready événement.

Tout en consultant encore l’ didomi-ready événement, cliquez sur le Consentement onglet. Assurez-vous que les valeurs dans la Par défaut sur la page colonne reflètent les paramètres d’état de consentement par défaut configurés par votre organisation pour chaque type de consentement.

Les balises des produits Google se mettent à jour pour afficher les types de consentement définis sur refusé en raison du choix de l'utilisateur final
Laissez la bannière de consentement se charger dans la fenêtre suivante de Tag Assistant. Refusez le consentement pour tous les fournisseurs et toutes les finalités.
Sélectionnez les événements liés à l’action de refus du consentement dans la colonne de gauche et cliquez sur le Consentement onglet. Assurez-vous que les valeurs dans la Mise à jour sur la page colonne sont définies sur Refusé (sauf pour security_storage.

De plus, les balises de vos produits Google devraient se déclencher pour tout didomi-ready événement ultérieur.
Les balises des produits Google se mettent à jour pour afficher les types de consentement définis sur accordé en raison du choix de l'utilisateur final
Laissez la bannière de consentement se charger dans la fenêtre suivante de Tag Assistant. Accordez le consentement pour tous les fournisseurs et toutes les finalités.
Sélectionnez les événements liés à l’action d’acceptation du consentement dans la colonne de gauche et cliquez sur le Consentement onglet. Assurez-vous que les valeurs dans la Mise à jour sur la page colonne sont définies sur Accordé.

De plus, les balises de vos produits Google devraient se déclencher pour tout didomi-ready événement ultérieur.
La manière dont votre organisation effectue les tests dépend des intégrations configurées et des outils disponibles pour votre application mobile. Dans cet onglet, nous verrons quelles validations votre organisation doit effectuer afin de vérifier que les signaux par défaut et mis à jour sont correctement définis et envoyés.
Activer les journaux de débogage
Activez la journalisation verbeuse dans le SDK Didomi via :
Android
iOS
Si vous êtes intégré à Firebase, activez Firebase DebugView via :
Android
iOS
Lancez avec -FIRDebugEnabled argument
Critères de test
Analysez les journaux et les charges utiles réseau pour chaque critère afin de vous assurer que les résultats attendus sont définis pour le champ approprié.
Meilleures pratiques de test
Testez votre application dans plusieurs régions et selon plusieurs réglementations
Vérifiez le comportement au premier lancement de l’application et après les actions de consentement de l’utilisateur final
Utilisez toujours de vraies versions du SDK et non des mocks pour la validation finale
Mis à jour