Il n’y a pas si longtemps, Google a annoncé un nouveau mode de consentement pour les balises Google. Il vous permet de créer un mécanisme dans lequel les balises de Google analysent, réagissent et répondent au statut de consentement des visiteurs de votre site.

En bref, le mode consentement est un bêta fonctionnalité, qui vous permet de déterminer si les balises publicitaires de Google (Ads et Floodlight) et les balises d’analyse (Universal Analytics, App + Web) peuvent ou non utiliser le stockage du navigateur lors de l’envoi de pings aux serveurs de Google.

Ceci est (un peu) conforme, par exemple, au règlement général sur la protection des données (RGPD) et à la directive ePrivacy (ePD) dans l’Union européenne, qui limitent le stockage et le traitement des données personnelles (RGPD) et le stockage d’autres données (ePD) à l’égard des personnes concernées.

Une grande partie de ce guide tourne autour de la façon de configurer cela dans Google Tag Manager, mais la présentation de la fonctionnalité s’applique également à la mise en œuvre à l’aide du Global Site Tag (gtag.js).

Clause de non-responsabilité : cet article est un aperçu technique du fonctionnement du mode de consentement. Vous devez aligner la mise en œuvre sur les lois et réglementations applicables à votre organisation et aux utilisateurs qui visitent votre ou vos sites.

Assurez-vous de lire la documentation de support officielle ainsi que le guide du développeur pour vous mettre au courant.

Comment fonctionne le mode consentement

D’abord, mode de consentement n’est pas un plateforme de gestion du consentement. Pour que le mode consentement soit efficace, vous devez déjà disposer d’un système ou d’une solution de collecte et de résolution du consentement de l’utilisateur concernant les données collectées sur votre site.

Le mode de consentement a deux variantes. Il y a les défaut paramètres que la page utilisera en attendant que le statut de consentement de l’utilisateur soit résolu. Ensuite il y a les actualisé paramètres qui sont envoyés dès que le consentement a été résolu.

Les paramètres par défaut doivent être établis le plus tôt possible dans le chargement de la page. Idéalement, vous ajouteriez un nouveau gtag extrait en haut du modèle de page et établissez les paramètres de consentement par défaut dans cet extrait.

Note! Vous faites ne pas il faut utiliser gtag.js pour déployer le mode consentement. L’API se trouve être le global gtag() méthode, mais cela fonctionne bien avec les balises de Google Tag Manager.

Lorsque les balises de Google se déclenchent, elles vérifient l’état du consentement à partir des paramètres par défaut et agissent en conséquence.

Une fois que vous avez établi le consentement de l’utilisateur, vous pouvez appeler le update commande. Cela vous permet de modifier (ou de conserver) le statut de stockage publicitaire et de stockage analytique.

L’appel gtag()

Comme mentionné ci-dessus, le mode de consentement utilise le gtag() API. Les balises Google déclenchées sur le site liront automatiquement l’état de consentement de cette API lorsqu’elles détermineront s’il faut lire ou écrire des cookies et comment compiler la demande de réseau aux serveurs de Google.

Voici ce que le défaut extrait ressemblerait. Rappelez-vous, idéalement, cela devrait être placé en haut de la page. Vous pouvez également le déclencher via Google Tag Manager à l’aide d’une balise HTML personnalisée ou d’un modèle personnalisé, mais dans ce cas, vous devez vous assurer qu’il se déclenche avant le déclenchement de toute balise Google.

window.dataLayer = window.dataLayer || []; function gtag() { window.dataLayer.push(arguments); } gtag('consent', 'default', {   ad_storage: 'denied',   analytics_storage: 'denied',   wait_for_update: 500,   region: ['US-CA', 'FI'] }); 

Les gtag() La commande ci-dessus définit les paramètres de consentement par défaut pour les visiteurs de Californie (US-CA) et la Finlande (FI) pour refuser l’accès au stockage de publicités et d’analyses. Pour ces utilisateurs, seuls les pings sans cookie seront envoyés aux serveurs de Google. Il y a aussi un temps d’attente de 500 millisecondes avant que les balises Google ne soient autorisées à se déclencher, pour laisser le temps au update commande à invoquer.

Les region paramètre n’est pertinent que dans le default commande, comme au moment où vous exécutez update vous devez savoir s’il faut activer ou désactiver le stockage pour l’utilisateur actuel, quelle que soit sa provenance.

Une fois que vous avez établi les choix de consentement de l’utilisateur, vous pouvez exécuter le update commande. Dans l’exemple suivant, l’utilisateur a accordé l’accès au stockage pour les balises d’analyse, mais a refusé l’accès au stockage pour les scripts publicitaires.

gtag('consent', 'update', {   ad_storage: 'denied',   analytics_storage: 'granted' }); 

Vous n’avez pas à fournir ad_storage encore une fois, comme c’était déjà le cas denied dans les paramètres par défaut. Cependant, je recommande de les inclure explicitement dans le update commande également pour s’assurer que les erreurs n’entraînent pas l’utilisation du stockage lorsque l’utilisateur n’a pas opté pour une telle chose.

Restreindre le stockage publicitaire

Pour limiter le stockage publicitaire, vous devez appeler le default ou alors update commande et définissez la valeur de ad_storage pour 'denied' dans l’objet de consentement.

Lorsque l’espace de stockage publicitaire est limité, voici ce qui se passe :

• Aucun nouveau cookie publicitaire n’est écrit. Cela signifie que si l’URL a le gclid à partir d’un clic sur une annonce de recherche Google, par exemple, il ne sera pas écrit dans un cookie propriétaire.
• Aucun cookie publicitaire existant ne peut être lu. S’il existait déjà un cookie avec un identifiant de clic, celui-ci ne serait pas utilisé ni envoyé avec les balises.
• Les cookies tiers sont uniquement utilisés pour la détection des spams et des fraudes. S’il y a déjà des cookies écrits, par exemple, doubleclick.netils seraient inclus dans la demande (en supposant que le navigateur ne bloque pas les cookies tiers), mais Google indique qu’il ne les utilisera que pour la détection des spams et des fraudes.
• Google Analytics ne lira ni n’écrira de cookies publicitaires, ni ne les utilisera pour Google Signals.
• Les adresses IP sont utilisées uniquement pour la géolocalisation. Ils ne sont pas collectés par Google Ads ou les balises Floodlight. Google Analytics Est-ce que les collecter, mais vous pouvez opter pour l’anonymisation IP.
• L’URL complète de la page est collectée avec d’éventuels identifiants de clic. Si l’URL de la page actuelle comporte des identifiants de clic, ils sont envoyés aux plateformes de publicité et d’analyse avec l’URL de la page actuelle.

Caviarder les données publicitaires

Vous pouvez augmenter la fidélité des restrictions de stockage publicitaire en appelant en outre les éléments suivants gtag() API :

gtag('set', 'ads_data_redaction', true); 

Cette seul fonctionne lorsque vous définissez ad_storage pour denied.

Dans ce cas, les restrictions supplémentaires suivantes s’appliqueront :

• Les appels publicitaires seront acheminés via un nouveau domaine sans cookie. Au lieu de les acheminer vers doubleclick.net ou alors google.comles demandes sont envoyées à googleadsyndication.comqui n’aurait aucun cookie (lié à la publicité) défini par Google.
• Les identifiants de clic sur les annonces seront supprimés des demandes de publicité et des pings de consentement.
• Les URL de page avec des identifiants de clic seront masqués. Notez que Google Analytics collectera toujours l’URL complète de la page avec les identifiants de clic en place.

Restreindre le stockage des analyses

Si vous choisissez de limiter le stockage des analyses en définissant la valeur de analytics_storage pour denied dans l’objet de consentement, Google Analytics ne sera pas en mesure de lire ou d’écrire des cookies propriétaires.

Cela signifie que tous les succès qui tirent avant l’utilisateur recharge ou navigue vers une autre page aura le même identifiant client (car il est stocké dans une variable globale). Cependant, dès que l’utilisateur navigue hors de la page en cours ou recharge la page, un nouvel identifiant client sera envoyé avec les hits sur ce nouveau chargement de page.

En d’autres termes, Google Analytics ne lira ni n’écrira les _ga cookie (même s’il existe déjà). Au lieu de cela, il utilisera un identifiant éphémère qui existe uniquement pour la durée du chargement de la page en cours.

Surtout, la restriction du STOCKAGE analytique n’empêchera pas l’envoi des appels vers Google Analytics. Le paramètre de mode de consentement empêche uniquement Google Analytics de stocker ou de lire des données à partir de cookies de navigateur (ou d’un autre stockage).

Cependant, ces résultats sans cookie sont envoyés à Google Analytics avec un nouveau gcs paramètre, qui inclut le statut de consentement du hit. Les hits sans cookie sont ainsi identifiés par Google Analytics et pour l’instant ne sont pas du tout collectées ou exposées dans les rapports.

Très probablement, Google créera également à un moment donné des données exploitables à partir de l’ensemble de données sans cookie, peut-être après avoir appliqué une modélisation approfondie pour l’aligner sur les données qui ont été collectées avec le consentement au stockage.

Que se passe-t-il lorsque le consentement est mis à jour ?

Si vous envoyez le update commande, vous pourrez soit Nier ou alors subvention accès au stockage publicitaire et analytique à toutes les balises Google, quelle que soit la région.

Si vous Nier l’accès au stockage, puis toutes les balises qui se déclenchent après le update l’appel sera limité comme décrit dans les chapitres précédents.

Si vous subvention l’accès au stockage, les balises auront alors un accès complet au stockage. Si vous accordez l’accès au stockage publicitaire, les suppressions de données publicitaires que vous auriez pu établir ne s’appliqueront plus.

En plus de cela – dès que vous exécutez le update commande et grant accès au stockage publicitaire, tous les pings publicitaires qui ont peut-être déjà été déclenchés sans pour autant l’accès au stockage se déclenchera à nouveau. Ainsi, les cookies seront écrits et lus, et les demandes seront acheminées via des domaines qui peuvent également contenir des cookies tiers.

Passerelle d’URL

Si vous utilisez gtag.jsvous pouvez basculer Passerelle d’URL au. Il vérifie l’URL de la page actuelle pour les paramètres publicitaires (gclid, dclid, gclsrc, _gl) et les ajoute à toutes les URL de liens internes sur lesquelles l’utilisateur est susceptible de cliquer.

C’est une fonctionnalité utile au cas où le consentement est accordé en dehors de la page de destination, mais cela entraîne une pollution des URL et peut perturber les sites où la fonctionnalité est basée sur un ensemble strict de paramètres d’URL (en particulier au-delà des pages de destination évidentes).

La commande ressemble à ceci :

gtag('set', 'url_passthrough', true); 

Pour que cela fonctionne, le site devoir charger un gtag.js bibliothèque, donc juste en utilisant le gtag() L’API ne fonctionnera pas.

Si vous utilisez Google Tag Manager, vous pouvez obtenir la même fonctionnalité en utilisant les fonctionnalités de liaison entre domaines de la balise Conversion Linker.

Prise en charge de Google Tag Manager

Comme vous l’avez peut-être deviné, pour l’instant, la prise en charge du mode consentement par Google Tag Manager est un peu floue. Obligé d’utiliser le gtag() L’API est un peu en arrière, étant donné que nous avons déjà une file d’attente de messages globale nommée dataLayer à notre disposition.

Je suis absolument certain qu’une intégration plus étroite avec GTM est en cours. J’espère particulièrement voir certaines ou toutes les fonctionnalités suivantes :

• Statut de consentement exposé dans dataLayer. En ce moment le gtag() les commandes de consentement ne sont pas disponibles dans dataLayerce qui rend impossible la vérification de l’état de stockage des publicités et des analyses au cas où l’on souhaiterait également les appliquer à d’autres balises autres que Google.
• Déclencheur de précharge. C’est quelque chose que je voulais voir depuis des années. Il serait tellement utile d’avoir un événement déclencheur pour lequel tous les autres événements Google Tag Manager doivent attendre d’être terminés avant d’être initialisés. Ce serait l’endroit idéal pour une balise en mode consentement, car toutes les autres balises du conteneur ne pourraient pas se déclencher tant que l’événement de préchargement n’est pas terminé.
• Sensibilisation au consentement de première classe. Avec cela, je veux dire qu’il devrait être possible d’avoir des balises conscientes du consentement sans pour autant avoir à créer des configurations de déclenchement élaborées. L’une des choses les plus difficiles à mettre en place lors de l’utilisation de GTM avec une plateforme de gestion du consentement est le déclenchement conditionnel des balises en fonction du statut du consentement.
• API conscientes du consentement pour les modèles. Une extension logique du mode de consentement est qu’il devrait également s’appliquer aux balises autres que Google. Un endroit parfait pour cela serait dans les modèles personnalisés, où le statut du mode de consentement pourrait également être appliqué aux API et aux demandes de réseau générées par les modèles personnalisés.

Résumé

Tout d’abord, rappelez-vous que mode de consentement est un bêta caractéristique. Il est susceptible de changer avant qu’il ne soit officiellement sorti de la version bêta (à ce moment-là, je mettrai à jour cet article en conséquence).

En plus d’une meilleure intégration de Google Tag Manager, j’attends également avec impatience davantage d’options de consentement, car limiter uniquement le “stockage publicitaire” et le “stockage analytique” ne suffit pas vraiment en ce qui concerne la granularité de la façon dont les utilisateurs devraient être en mesure de décider de la manière dont leurs données sont collectées et traitées.

Néanmoins, le mode consentement vous offre un moyen agréable de contrôler le stockage, en particulier avec les balises publicitaires. Vous avez déjà pu contrôler le stockage de Google Analytics avec le storage paramètre de suivi, mais maintenant il est également configurable via ce gtag() API.

La principale différence entre le mode de consentement et l’utilisation du storage champ pour empêcher les balises d’analyse d’avoir accès au stockage est que le mode de consentement n’affichera pas les données dans les rapports lors de la configuration storage pour none sera.

Il est important de noter que le mode de consentement s’applique principalement à stockage accès et ne bloque en fait aucune demande. Je suis certain qu’il y aura un débat pour savoir si c’est suffisant ou non. Cependant, en particulier dans l’Union européenne, les lois semblent être assez claires que tant que rien n’est stocké (ou lu à partir du stockage), et tant que seuls des identifiants éphémères qui ne peuvent en aucun cas être liés à une personne physique sont utilisés , cette approche devrait suffire.

Vous devrez faire confiance à Google sur le ad_storage peu, cependant. Google promet de ne pas utiliser de cookies tiers à d’autres fins que la détection de spam et de fraude, mais cela est difficile à vérifier.

De même, le mode consentement ne couvre que les identifiants que nous connaissons. Il peut y avoir des fuites de données, intentionnelles et non intentionnelles, dans les demandes adressées à Google qui autorisent beaucoup plus d’options de contrôle des données que celles que l’utilisateur a choisies.

Néanmoins, je pense que tout effort entrepris par Google pour améliorer la sécurité et le contrôle de la confidentialité de ses services est le bienvenu. Il est juste important que cela ne conduise pas à la complaisance, cependant. Ce n’est pas parce que Google l’offre nativement que vous pouvez abandonner la diligence raisonnable pour vous assurer que le consentement (et toute autre fin légitime) est observé et audité périodiquement.