For the complete documentation index, see llms.txt. This page is also available as Markdown.

Google Consent Mode v2 (avancé) - RGPD

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.


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 est refusé, 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 .

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.

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 :

Bouton bascule
Description

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_storage

  • ad_user_data

  • ad_personalization

  • functionality_storage

  • personalization_storage

  • security_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_storage

  • ad_user_data

  • ad_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

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 :

Champ
Valeur

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.

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 :

Bouton bascule
Description

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_storage

  • ad_user_data

  • ad_personalization

  • functionality_storage

  • personalization_storage

  • security_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_storage

  • ad_user_data

  • ad_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" .

Vous trouverez ci-dessous des informations sur l'implémentation de Google Consent Mode v2 (Avancé) via le modèle GTM Didomi :

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 :

SDK mobile
Version minimale

iOS/tvOS

> v2.27.0

Android

> v2.27.0

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 :

Bouton bascule
Description

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_storage

  • ad_user_data

  • ad_personalization

  • functionality_storage

  • personalization_storage

  • security_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_storage

  • ad_user_data

  • ad_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 à true 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 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 dans SharedPreferences

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 contraire

  • Les 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 final

  • Les 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 :

Méthode d'implémentation
Tests disponibles

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é.

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

Composant
Description

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ée

  • t - Valeur par défaut accordée

  • q, m, u - Refusé après le choix de l'utilisateur final

  • e, r, n, v - Accordé après le choix de l'utilisateur final

  • 1 - Indéfini

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