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

Mode de consentement Google v2 (par pays/région)

Type d’accès : Gestionnaire des réglementations - Éditeur

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éfinie par Google. Dans cet article, nous verrons comment implémenter Google Consent Mode v2 sur une réglementation qui utilise le pays/la région comme périmètre de collecte de données et qui est spécifiée pour les réglementations américaines (par ex. CPRA, NJDPA, etc...)

Google Consent Mode v2 (par pays/région)

Pour une réglementation qui utilise le pays/la région comme périmètre de collecte de données et qui est spécifiée pour les réglementations américaines, les balises produit Google se chargeront lorsqu’un utilisateur final accède à votre site web ou à votre application, chargeront l’API consent mode et effectueront les actions suivantes :

  • Définissez les états de consentement par défaut pour les types de consentement. Afin de se conformer aux réglementations américaines en matière de confidentialité, les valeurs par défaut seront définies sur accordé

  • Les états de consentement pour les types de consentement seront mis à jour en fonction des sélections de l’utilisateur final concernant les finalités et/ou les fournisseurs pour la réglementation.

  • Si le Contrôle mondial de la confidentialité (GPC) signal est ajouté aux cadres de la réglementation et que l’utilisateur final utilise le Global Privacy Control (GPC) dans son navigateur, alors les types de consentement seront immédiatement définis sur refusé

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 .

Implémenter Google Consent Mode v2 (par pays/région)

Didomi propose plusieurs façons pour votre organisation d’implémenter Google Consent Mode v2 pour une réglementation qui utilise le pays/la région comme périmètre de collecte de données et qui est spécifiée pour les réglementations américaines. Veuillez consulter les onglets ci-dessous pour la méthode la mieux adaptée aux besoins de votre organisation :

Dans cet onglet, nous verrons comment utiliser Google Tag Manager pour implémenter Google Consent Mode v2 pour une réglementation qui utilise le pays/la région comme périmètre de collecte de données et qui est spécifiée pour les réglementations américaines

Configurer GCM v2 sur la réglementation (par pays/région)

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

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

Configurer la ou les balises de produit Google

Remarque: Cette section suppose que votre organisation a déjà intégré les balises Google Tag Manager sur votre site web.

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 :

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

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

didomi-ready

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 pour une réglementation qui utilise le pays/la région comme périmètre de collecte de données et qui est spécifiée pour les réglementations américaines si votre organisation utilise gtag.js des balises pour les produits Google directement sur votre site web.

Configurer GCM v2 sur la réglementation (par pays/région)

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

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

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 pour les réglementations américaines, ces produits Google se chargeront lorsqu’un utilisateur final accède au site web avec des types de consentement Google définis par défaut sur accordé.

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

Ne activez le bouton de 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 lors de sa configuration pour une réglementation qui utilise le pays/la région comme périmètre de collecte de données et qui est spécifiée pour les réglementations américaines.

Vous trouverez ci-dessous des informations sur l’implémentation de Google Consent Mode v2 via le modèle GTM de 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 Google Consent Mode v2 sur une application mobile pour une réglementation qui utilise le pays/la région comme périmètre de collecte de données et qui est spécifiée pour les réglementations américaines.

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

Configurer Google Consent Mode v2 sur la réglementation (par pays/région)

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

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

fghfg

Tester Google Consent Mode v2 (par pays/région)

Lorsqu’elle est configurée correctement et avec succès, une implémentation Google Consent Mode v2 pour une réglementation qui utilise le pays/la région comme périmètre de collecte de données et qui est spécifiée pour les réglementations américaines déclenchera les balises produit Google, mais avec l’état de consentement des types de consentement Google défini par défaut sur accordé. Dans cette section, nous verrons comment tester si votre implémentation de Google Consent Mode v2 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.

Votre organisation devra confirmer trois actions lors des tests :

  • Les produits Google se chargent avec les types de consentement définis par défaut sur un état de consentement de accordé

  • 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 les balises produit Google se déclenchent comme prévu dans le cadre d’une implémentation Google Consent Mode v2 spécifiée pour les réglementations américaines dépend de la manière dont vous avez configuré l’implémentation.

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 de votre organisation pour une réglementation qui utilise le pays/la région comme périmètre de collecte de données et qui est spécifiée pour les réglementations américaines 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é.

Remarque: Bien que le gcd paramètre ne soit pas documenté publiquement par Google, il apparaît dans plusieurs articles.

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

Exemple:

13t3p3p3p5

  • ad_storage est accordé par défaut

  • analytics_storage est refusé par défaut

  • ad_user_data est refusé par défaut

  • ad_user_personalization est refusé par défaut

Les balises de produit Google se chargent avec les types de consentement définis par défaut sur accordé

Accédez au site web sur lequel vous avez déployé le widget Didomi avec une implémentation Google Consent Mode v2 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 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 - États-Unis et laissez le widget 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 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 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é votre conteneur Google Consent Mode v2 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 le widget Didomi est implémenté. Cliquez Connecter une fois terminé.

Les balises de produit Google se chargent avec les types de consentement définis par défaut sur accordé

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

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 sont définies sur accordé.

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.

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

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 afin de 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