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

Mode de consentement Google v2 (avancé)

Google Consent Mode v2 garantit que les fournisseurs Google associés à une réglementation respectent les choix de consentement d’un utilisateur final (appelés types de consentement) défini par Google. Dans cet article, nous verrons comment implémenter Google Consent Mode v2 sur une réglementation utilisant la configuration avancée du mode consentement Google.

Google Consent Mode v2 (Avancé) est disponible pour les organisations qui configurent une réglementation avec un périmètre de collecte des données par fournisseur. Si votre organisation configure une réglementation avec un périmètre de collecte des données par pays/région, veuillez consulter : Google Consent Mode v2 (par pays/région)


Dans la version avancée de Google Consent Mode v2, les balises de produit Google se chargent toujours lorsqu’un utilisateur final accède à votre site web ou à votre 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 cookies.

  • Attendez l'interaction de l'utilisateur final avec le widget et mettez à jour les états de consentement en conséquence. Ce n'est que lorsqu'un utilisateur final accorde son consentement à la collecte de données que les balises Google enverront les données de mesure complètes. En savoir plus sur le comportement des balises.

Produits du mode de consentement Google

Les produits Google suivants intègrent des vérifications de consentement et adapteront leur comportement en fonction de l'état de consentement de l'utilisateur final pour les types de consentement Google :

  • Balise Google

  • 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 depuis 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 votre réglementation. Veuillez consulter les onglets ci-dessous pour la méthode la plus adaptée aux besoins de votre organisation :

Dans cet onglet, nous verrons comment utiliser Google Tag Manager pour implémenter Google Consent Mode v2 (Avancé) pour votre réglementation qui utilise un périmètre de collecte des données par fournisseur.

Accédez à une réglementation qui utilise un périmètre de collecte de données par fournisseur et accédez à la Cadres carte sur la Paramètres globaux page.

Assurez-vous que Mode de consentement Google est activé.

En activant le framework Google Consent Mode pour la réglementation, Didomi ajoutera automatiquement les fournisseurs suivants à la réglementation :

Fournisseur
Description

Produits publicitaires Google

Ajoutera le fournisseur Produits publicitaires Google (ID d'API : google) à la réglementation. 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

Produits Google Analytics

Ajoutera le fournisseur Produits Google Analytics (ID d'API : googleana-4TXnJigR) à la réglementation. Conçu pour englober les produits Google qui nécessitent le analytics_storage de consentement.

Ensuite, accédez à l’ Fournisseurs et finalités onglet et utilisez la matrice fournisseur x finalité fournie pour configurer les règles de traitement, supprimer l’une des finalités, etc. pour les fournisseurs ajoutés. Voir Configurer la réglementation (par fournisseur) pour plus d'informations.

Enfin, accédez à l’ Cadres onglet et développez l’ Google Consent Mode v2 accordéon pour configurer les détails du framework.

Consultez le tableau ci-dessous pour obtenir des informations sur chaque interrupteur de la configuration d’intégration :

Interrupteur
Description

Définir l'état par défaut de Google Consent Mode au chargement de la page

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.

Activer les produits publicitaires Google

Lorsqu’il est activé, indique que le fournisseur Produits publicitaires Google (ID d’API : google) est ajouté à la réglementation. Si le commutateur est désactivé, le fournisseur sera supprimé.

Activer {consent type} avant que l'utilisateur ne donne 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 de produit Google se charge.

Activer les produits Google Analytics

Lorsqu’il est activé, indique que le fournisseur Produits Google Analytics (ID d’API : googleana-4TXnJigR) est ajouté à la réglementation. Si le commutateur est désactivé, le fournisseur sera supprimé.

Activer l’intégration IAB TCF avec Google Consent Mode

Permet à Didomi de définir un indicateur supplémentaire (TCData.enableAdvertiserConsentMode à true) pour les commandes getTCData et addEventListener commandes. Ce drapeau supplémentaire permet à Google d’inférer et d’associer les paramètres de consentement aux types de consentement Google Consent Mode v2 suivants sur la base 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 mapping entre les finalités IAB TCF et les types de consentement Google. L’intégration TCF avec Google Consent Mode ne prend pas en charge les balises de produits Google qui nécessitent le analytics_storage, functionality_storage, personalization_storage, ou security_storage types de consentement.

Pour les produits Google qui nécessitent le type de consentement analytics_storage de consentement, Didomi définira ce type de consentement sur accordé si l'utilisateur final consent globalement (consentement au fournisseur et à toutes ses finalités) pour les Produits Google Analytics (ID d'API : googleana-4TXnJigR).

Nom de la data layer

Par défaut, Didomi utilise dataLayer comme nom de variable pour la dataLayer Google Tag Manager de votre organisation. Si votre organisation a modifié le nom de la variable de votre dataLayer, saisissez alors ce nom de variable dans l'espace prévu.

Suivi des conversions d’application avec Firebase et les partenaires AAP de Google

Cliquez ici pour plus d'informations lors de la configuration de Google Consent Mode v2 (Avancé) pour les SDK mobiles.

Configurer la ou les balises de produit Google

Afin de garantir que les balises de produit Google soient chargées (et que l’état par défaut des types de consentement Google soit exposé), votre organisation doit configurer les balises de 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.

Deux méthodes sont disponibles pour permettre à votre organisation de configurer les balises de produit Google. Choisissez ci-dessous la méthode qui convient le mieux à votre cas d’utilisation :

Modifier la balise Google Tag Manager sur la page

Utilisez Didomi <script> les attributs de balise pour modifier les balises Google Tag Manager de votre site afin d’inclure type="didomi/javascript" . Les balises de 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 de produit Google dans Google Tag Manager

Depuis l'espace de travail Google Tag Manager de votre organisation, accédez à votre balise de produit Google et modifiez le déclencheur.

Utilisez le flux de travail Google Tag Manager pour configurer un nouveau déclencheur pour la balise de 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é) sur votre réglementation avec un périmètre de collecte des données par fournisseur lorsque votre organisation utilise gtag.js des balises pour les produits Google directement sur votre site web.

Accédez à une réglementation qui utilise un périmètre de collecte de données par fournisseur et accédez à la Cadres carte sur la Paramètres globaux page.

Assurez-vous que Mode de consentement Google est activé.

En activant le framework Google Consent Mode pour la réglementation, Didomi ajoutera automatiquement les fournisseurs suivants à la réglementation :

Fournisseur
Description

Produits publicitaires Google

Ajoutera le fournisseur Produits publicitaires Google (ID d'API : google) à la réglementation. 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

Produits Google Analytics

Ajoutera le fournisseur Produits Google Analytics (ID d'API : googleana-4TXnJigR) à la réglementation. Conçu pour englober les produits Google qui nécessitent le analytics_storage de consentement.

Ensuite, accédez à l’ Fournisseurs et finalités onglet et utilisez la matrice fournisseur x finalité fournie pour configurer les règles de traitement, supprimer l’une des finalités, etc. pour les fournisseurs ajoutés. Voir Configurer la réglementation (par fournisseur) pour plus d'informations.

Enfin, accédez à l’ Cadres onglet et développez l’ Google Consent Mode v2 accordéon pour configurer les détails du framework.

Consultez le tableau ci-dessous pour obtenir des informations sur chaque interrupteur de la configuration d’intégration :

Interrupteur
Description

Définir l'état par défaut de Google Consent Mode au chargement de la page

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.

Activer les produits publicitaires Google

Lorsqu’il est activé, indique que le fournisseur Produits publicitaires Google (ID d’API : google) est ajouté à la réglementation. Si le commutateur est désactivé, le fournisseur sera supprimé.

Activer {consent type} avant que l'utilisateur ne donne 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 de produit Google se charge.

Activer les produits Google Analytics

Lorsqu’il est activé, indique que le fournisseur Produits Google Analytics (ID d’API : googleana-4TXnJigR) est ajouté à la réglementation. Si le commutateur est désactivé, le fournisseur sera supprimé.

Activer l’intégration IAB TCF avec Google Consent Mode

Permet à Didomi de définir un indicateur supplémentaire (TCData.enableAdvertiserConsentMode à true) pour les commandes getTCData et addEventListener commandes. Ce drapeau supplémentaire permet à Google d’inférer et d’associer les paramètres de consentement aux types de consentement Google Consent Mode v2 suivants sur la base 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 mapping entre les finalités IAB TCF et les types de consentement Google. L’intégration TCF avec Google Consent Mode ne prend pas en charge les balises de produits Google qui nécessitent le analytics_storage, functionality_storage, personalization_storage, ou security_storage types de consentement.

Pour les produits Google qui nécessitent le type de consentement analytics_storage de consentement, Didomi définira ce type de consentement sur accordé si l'utilisateur final consent globalement (consentement au fournisseur et à toutes ses finalités) pour les Produits Google Analytics (ID d'API : googleana-4TXnJigR).

Nom de la data layer

Par défaut, Didomi utilise dataLayer comme nom de variable pour la dataLayer Google Tag Manager de votre organisation. Si votre organisation a modifié le nom de la variable de votre dataLayer, saisissez alors ce nom de variable dans l'espace prévu.

Suivi des conversions d’application avec Firebase et les partenaires AAP de Google

Cliquez ici pour plus d'informations lors de la configuration de Google Consent Mode v2 (Avancé) pour les SDK mobiles.

Installer les balises de produits Google

Ajoutez à votre site web les balises nécessaires pour vos produits Google sensibles au consentement (par ex. Floodlight, Conversion Linker, etc...).

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 cookies. Ce n’est que lorsqu’un utilisateur final aura donné son consentement que les balises de produit Google enverront l’ensemble des données de mesure.

Afin de garantir que les balises de produit Google soient chargées (et que l’état par défaut des types de consentement Google soit exposé), votre organisation doit configurer chaque balise de 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 de produit Google sur votre site 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 des 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 la setConsent méthode doivent mettre à jour leurs implémentations en suivant les instructions ci-dessous et supprimer setConsent de Google Consent Mode v2 du code de l'application.

Dans 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 final.

Dans cet onglet, nous verrons comment implémenter le cadre Google Consent Mode v2 (Avancé) sur une réglementation pour 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

Accédez à une réglementation qui utilise un périmètre de collecte de données par fournisseur et accédez à la Cadres carte sur la Paramètres globaux page.

Assurez-vous que Mode de consentement Google est activé.

En activant le framework Google Consent Mode pour la réglementation, Didomi ajoutera automatiquement les fournisseurs suivants à la réglementation :

Fournisseur
Description

Produits publicitaires Google

Ajoutera le fournisseur Produits publicitaires Google (ID d'API : google) à la réglementation. 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

Produits Google Analytics

Ajoutera le fournisseur Produits Google Analytics (ID d'API : googleana-4TXnJigR) à la réglementation. Conçu pour englober les produits Google qui nécessitent le analytics_storage de consentement.

Ensuite, accédez à l’ Fournisseurs et finalités onglet et utilisez la matrice fournisseur x finalité fournie pour configurer les règles de traitement, supprimer l’une des finalités, etc. pour les fournisseurs ajoutés. Voir Configurer la réglementation (par fournisseur) pour plus d'informations.

Enfin, accédez à l’ Cadres onglet et développez l’ Google Consent Mode v2 accordéon pour configurer les détails du framework.

Consultez le tableau ci-dessous pour obtenir des informations sur chaque interrupteur de la configuration d’intégration :

Interrupteur
Description

Définir l'état par défaut de Google Consent Mode au chargement de la page

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.

Activer les produits publicitaires Google

Lorsqu’il est activé, indique que le fournisseur Produits publicitaires Google (ID d’API : google) est ajouté à la réglementation. Si le commutateur est désactivé, le fournisseur sera supprimé.

Activer {consent type} avant que l'utilisateur ne donne 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 de produit Google se charge.

Activer les produits Google Analytics

Lorsqu’il est activé, indique que le fournisseur Produits Google Analytics (ID d’API : googleana-4TXnJigR) est ajouté à la réglementation. Si le commutateur est désactivé, le fournisseur sera supprimé.

Activer l’intégration IAB TCF avec Google Consent Mode

Permet à Didomi de définir un indicateur supplémentaire (TCData.enableAdvertiserConsentMode à true) pour les commandes getTCData et addEventListener commandes. Ce drapeau supplémentaire permet à Google d’inférer et d’associer les paramètres de consentement aux types de consentement Google Consent Mode v2 suivants sur la base 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 mapping entre les finalités IAB TCF et les types de consentement Google. L’intégration TCF avec Google Consent Mode ne prend pas en charge les balises de produits Google qui nécessitent le analytics_storage, functionality_storage, personalization_storage, ou security_storage types de consentement.

Pour les produits Google qui nécessitent le type de consentement analytics_storage de consentement, Didomi définira ce type de consentement sur accordé si l'utilisateur final consent globalement (consentement au fournisseur et à toutes ses finalités) pour les Produits Google Analytics (ID d'API : googleana-4TXnJigR).

Nom de la data layer

Par défaut, Didomi utilise dataLayer comme nom de variable pour la dataLayer Google Tag Manager de votre organisation. Si votre organisation a modifié le nom de la variable de votre dataLayer, saisissez alors ce nom de variable dans l'espace prévu.

Firebase

Firebase est le SDK principal pour les applications Google. Une fois activée, l'intégration garantit :

  • un mappage correct des signaux de consentement Didomi vers Firebase

  • une propagation automatique vers les SDK Google pour la mesure et la publicité

  • une conformité simplifiée pour le RGPD et des réglementations similaires

Branch

Partenaires d'attribution d'application (AAP) comme Branch doivent recevoir des signaux de consentement précis pour se conformer aux réglementations sur la confidentialité et transmettent ces signaux à Google.

Lorsque Branch est activé pour la réglementation et que le SDK Branch est présent dans votre application, Didomi gère la propagation du signal Google Consent Mode pour Branch.

Pour les utilisateurs finaux dans les régions réglementées par le RGPD, Didomi indique le contexte de conformité en définissant eea à 1 et applique des valeurs par défaut pour les signaux de consentement en fonction de votre configuration dans la console. Après que l'utilisateur final a fourni 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 Branch à jour en conséquence.

Pour les utilisateurs situés hors des régions RGPD, Didomi définit eea à 0 pour indiquer qu'aucune obligation RGPD ne s'applique.

Kochava

Partenaires d'attribution d'application (AAP) comme Kochava doivent recevoir des signaux de consentement précis pour se conformer aux réglementations sur la confidentialité et transmettent ces signaux à Google.

Lorsque Kochava est activé pour la réglementation, 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 la CMP recueille 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 final 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 fluide 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'application (AAP) comme Airbridge doivent recevoir des signaux de consentement précis pour se conformer aux réglementations sur 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 Google Consent Mode appropriés 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 ces signaux à jour et s'assure qu'Airbridge reflète les préférences réelles de l'utilisateur final.

Pour les utilisateurs finaux hors 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'application (AAP) comme AppsFlyer doivent recevoir des signaux de consentement précis pour se conformer aux réglementations sur 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 du signal Google Consent Mode pour AppsFlyer.

  • Pour les utilisateurs situés dans des régions réglementées par le RGPD, Didomi indique le contexte de conformité en définissant isUserSubjectToGDPR à true et applique des valeurs par défaut pour les 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 AppsFlyer à jour en conséquence.

  • Pour les utilisateurs hors de la juridiction du RGPD, Didomi définira isUserSubjectToGDPR à false .

  • Si vous avez activé l'intégration 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 est correctement et avec succès mise en place, une implémentation Google Consent Mode v2 (avancé) déclenchera les balises de produit Google, mais 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 le widget

Comme mentionné ci-dessus lors de la configuration, Google Consent Mode v2 (avancé) nécessite l’utilisation des fournisseurs suivants : Google Advertising Products (ID 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 au widget afin de refléter les produits Google qui seront déclenchés :

Tester le déclenchement des balises de produit Google

Lors du test de l’implémentation Google Consent Mode v2 (avancé), votre organisation devra confirmer trois actions :

  • Les produits Google se chargent avec les types de consentement définis par défaut sur un état de consentement de refusé sauf configuration contraire

  • Les produits Google se mettent à jour pour afficher des types de consentement définis sur un état de consentement de refusé en raison du choix de l’utilisateur final

  • Les produits Google se mettent à jour pour afficher des types de consentement définis sur un état de consentement de accordé en raison du choix de l’utilisateur final

La manière dont votre organisation teste que la ou les balises de produits Google se déclenchent comme prévu dans une configuration Google Consent Mode v2 (Avancé) dépend de la façon dont vous avez configuré l'implémentation sur la réglementation :

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

  • Sniffeurs 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 le widget Didomi est déployé.

Il est recommandé d'effectuer les tests suivants en utilisant une fenêtre de navigation privée pour votre navigateur.

gcd paramètre

La gcd Le paramètre est inclus dans la charge utile de chaque requête réseau Google AdWords 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é.

La gcd paramètre est une chaîne de caractères composée de plusieurs composants pouvant 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 invariable de la chaîne de caractères. Représenté par un 11 ou 13

Suffixe

Fin invariable 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 du 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 de produit Google se chargent avec les types de consentement définis par défaut sur refusé

Accédez au site web sur lequel vous avez déployé le widget Didomi avec une implémentation Google Consent mode v2 (Avancé) et laissez le widget se charger sur la page. Il est important que vous n'interagissiez pas encore avec le widget.

Ouvrez la console du navigateur et sélectionnez l’ 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 de consentement de chaque type de consentement dans le gcd paramètre correspondent aux paramètres par défaut attendus.

Les balises de produit Google mettent à jour pour afficher des 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é le widget Didomi avec une implémentation Google Consent mode v2 (Avancé) et laissez le widget 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 l’ Réseau onglet. Vérifiez les requêtes de vos produits Google pour vous assurer que la valeur d’état de consentement de chaque type de consentement dans le gcd paramètre est définie sur refusé en raison du choix de l’utilisateur final.

Les balises de produit Google mettent à jour pour afficher des 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é le widget Didomi avec une implémentation Google Consent mode v2 (Avancé) et laissez le widget se charger sur la page. Accordez votre consentement pour tous les fournisseurs et toutes les finalités.

Ouvrez la console du navigateur et sélectionnez l’ Réseau onglet. Vérifiez les requêtes de vos produits Google pour vous assurer que la valeur d’état de consentement de chaque type de consentement dans le gcd paramètre est définie sur accordé en raison du choix de l’utilisateur final.

Dans cet onglet, nous verrons comment tester l’implémentation Google Consent Mode v2 (avancé) de votre organisation via Google Tag Manager.

Il est recommandé d'effectuer les tests suivants en utilisant une fenêtre de navigation privée pour votre navigateur ou de vider 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é Google Consent Mode v2 (Avancé) dans votre compte Google Tag Manager et cliquez Aperçu.

Utilisez le champ fourni pour saisir l’URL de votre site web sur lequel le widget Didomi est implémenté. Cliquez Connecter une fois terminé.

Les balises de produit Google se chargent avec des types de consentement définis par défaut sur la configuration

Laissez l'avis de consentement se charger dans la fenêtre suivante de Tag Assistant. Il est important que vous n'interagissiez pas encore avec le widget.

Assurez-vous que vos balises de produit Google ne se déclenchent pas avant l’ didomi-ready événement.

Tout en affichant toujours l’ didomi-ready événement, cliquez sur l’ Consentement onglet. Assurez-vous que les valeurs de la Défaut sur la page colonne reflètent les états de consentement par défaut configurés par votre organisation pour chaque type de consentement.

Les balises de produit Google mettent à jour pour afficher des types de consentement définis sur refusé en raison du choix de l’utilisateur final

Laissez le widget 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 de consentement dans la colonne de gauche et cliquez sur le Consentement onglet. Assurez-vous que les valeurs de la Mise à jour sur la page colonne sont définies sur Refusé (sauf pour security_storage.

De plus, vos balises de produit Google devraient se déclencher pour tout didomi-ready événement ultérieur.

Les balises de produit Google mettent à jour pour afficher des types de consentement définis sur accordé en raison du choix de l’utilisateur final

Laissez le widget 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 de la Mise à jour sur la page colonne sont définies sur Accordé.

De plus, vos balises de produit 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 comment effectuer les validations que votre organisation doit réaliser 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 intégré avec Firebase, activez Firebase DebugView via :

Android

iOS

Lancer avec -FIRDebugEnabled argument

Critères de test

Analysez les journaux et les charges utiles réseau pour chaque critère pour vous assurer que les résultats attendus sont définis pour le champ approprié.

Bonnes pratiques de test

  • Testez votre application dans plusieurs régions et sous plusieurs réglementations

  • Vérifiez le comportement lors du premier lancement de l'application et après les actions de consentement de l'utilisateur final

  • Utilisez toujours de véritables builds du SDK et non des mocks pour la validation finale

Mis à jour