Depuis que Google Analytics a publié les premières fonctionnalités du mode consentement, j’attends avec impatience des nouvelles concernant une intégration plus étroite avec la solution d’implémentation préférée de Google : Google Tag Manager.

Dans une version récente, Google a publié une véritable corne d’abondance de nouvelles fonctionnalités qui devraient aider à déterminer et à mettre en œuvre le consentement non seulement pour les balises Google, mais quelconque balises exécutées dans le conteneur.

Les nouvelles fonctionnalités sont :

• Nouveau types de consentement (en plus de ad_storage et analytics_storage qui ont été introduits avec le mode de consentement).
• Paramètres de consentement spécifiques aux balises avec les deux intégré contrôles de consentement (si leur comportement est modifié par l’état de consentement) et Additionnel vérifications de consentement, où vous pouvez déterminer si une balise nécessite des types de consentement spécifiques pour être autorisée à se déclencher en général.
• Un nouveau Aperçu du consentement écran, où vous pouvez rapidement vérifier quelles balises ont déjà été configurées pour des paramètres de consentement supplémentaires et lesquelles attendent toujours d’être mises à jour.
• Nouveaux types de déclencheurs, avec à la fois un Initialisation du consentement déclencheur (se déclenche avant toute autre chose dans le conteneur) et un Initialisation déclencheur (se déclenche avant tout sauf le déclencheur d’initialisation du consentement) ajouté au mélange.
• Nouvelles API de sandbox de modèles personnalisés pour créer des modèles de plate-forme de gestion du consentement (et pourquoi pas d’autres également) conscient du consentement.

Ces fonctionnalités sont disponibles dans les conteneurs GTM 360 et GTM standard (gratuits).

Examinons de plus près tout cela.

Nouveaux types de consentement

Tout d’abord, en plus de ad_storage et analytics_storagequi ont été introduits avec le mode de consentement, il y a Trois types de consentement supplémentaires que Google recommande d’utiliser avec ces API. Voici la liste complète (source):

Note! Les trois nouveaux types de consentement sont seul pour les balises autres que Google. Les balises Google (par exemple, Analytics, Ads et Floodlight) ne sont sensibles qu’à ad_storage et analytics_storage.

C’est un peu étrange de voir functionality_storage et security_storage ici, comme au moins dans l’Union européenne, ils sont généralement considérés comme strictement nécessaire stockage et ne nécessiterait donc pas du tout de consentement. D’un autre côté, avoir plus d’options de configuration est rarement une mauvaise chose.

Vous pouvez effectivement ajouter tous les types de consentement que vous aimez dans les appels d’API et les paramètres de balise respectifs. Les trois nouveaux types de consentement sont les recommandations de Google, mais ils ne constituent pas une liste exhaustive.

Paramètres de consentement dans les balises

Si vous ouvrez une balise, quelconque tag, et faites défiler jusqu’à son Réglages avancésvous trouverez une section intitulée Paramètres de consentement.

Il y a deux sections ici (bien que vous puissiez en voir une seule dans certains cas).

Vérifications de consentement intégrées

Vérifications de consentement intégrées signifie que la balise (ou, plus précisément, le modèle exécutant la balise) est conscient du consentement. Cela signifie que la balise fait quelque chose avec l’état de consentement, même si ce n’est pas vraiment expliqué Quel il est.

Dans la capture d’écran ci-dessus, par exemple, vous pouvez voir ad_storage et functionality_storage répertoriés dans la section Vérifications de consentement intégrées. Cela signifie que ce modèle de balise particulier a défini dans ses autorisations qu’il a besoin d’un accès en lecture et/ou en écriture à ces types de consentement particuliers.

C’est une bonne chose à savoir, au cas où vous vous demanderiez pourquoi la balise ne se comporte pas comme vous vous y attendiez.

Les balises Google (Analytics, Ads et Floodlight) ont des contrôles intégrés pour analytics_storage et ad_storage, et leur comportement est documenté. D’autres balises peuvent afficher d’autres types de consentement ici, et il appartient à la documentation de ces balises d’expliquer comment elles accèdent à l’état de consentement.

Note! Les vérifications de consentement intégrées ne sont visibles que si le modèle accède à l’état de consentement dans son code. Si cela n’a rien à voir avec les API de consentement, vous ne verrez pas les vérifications de consentement intégrées sous ces paramètres.

Vérifications de consentement supplémentaires

Les autre la rubrique s’appelle Vérifications de consentement supplémentaireset…

Cette. Est. Vraiment. Frais.

Avec ce paramètre, vous pouvez essentiellement gérer les vérifications de consentement sans avoir à appliquer les conditions de vérification du consentement aux balises déclencheurs!

Il y a trois options ici :

• Pas encore défini – l’option par défaut. Utilisez ceci pour indiquer que cette balise n’a pas été correctement examinée pour savoir si son déclenchement doit être conditionné au consentement ou non.
• Aucun consentement supplémentaire requis – Définissez ceci si le déclenchement de la balise doit ne pas être limitée sur la base du consentement.
• Exiger un consentement supplémentaire pour cette balise – Définissez ceci si la balise ne doit se déclencher que si le consentement a été accordé à un ou plusieurs types de consentement. Lorsque vous cochez cette option, un petit tableau apparaît et vous pouvez ajouter l’un des cinq types de consentement dans le tableau. La balise sera seul feu si tous les types de consentement répertoriés ont le granted Etat.

La balise avec les paramètres ci-dessus ne se déclenchera que si security_storage, functionality_storageet analytics_storage a été accordé consentement.

Aperçu du consentement

Pour activer l’écran d’aperçu du consentement, accédez d’abord à Administrateur et alors Paramètres du conteneur.

Cochez la case à côté de Activer l’aperçu du consentement.

Maintenant, quand tu vas à Mots clésvous pouvez cliquer sur le Aperçu du consentement icône dans la barre d’actions.

La vue d’ensemble du consentement répertorie toutes vos balises dans deux sections.

Consentement non configuré signifie que le Vérifications de consentement supplémentaires le paramètre pour ces balises est la valeur par défaut Pas encore défini.

Consentement configuré signifie que la balise a été configurée pour des contrôles de consentement supplémentaires (soit Aucun ou un ou plusieurs types de consentement qui doivent être accordés pour que la balise se déclenche).

Vous pouvez modifier en masse les paramètres de vérification du consentement pour les balises en les sélectionnant, puis en cliquant sur le bouton Modifier les paramètres de consentement dans la barre d’action.

Utilisez religieusement l’écran d’aperçu du consentement, surtout si vous intégrez Google Tag Manager à une plateforme de gestion du consentement (CMP). C’est un excellent moyen de voir rapidement comment et si vos balises ont été configurées pour fonctionner avec les paramètres de consentement définis par votre CMP.

Nouveaux types de déclencheurs

Il y a deux nouveaux types de déclencheurs dans Google Tag Manager. Les deux sont également automatiquement ajoutés à chaque conteneur en tant que déclencheurs intégrés, et les deux apparaissent en mode Aperçu en tant que nouveaux événements déclencheurs.

Note! Ces déclencheurs ne peuvent pas vraiment gérer les requêtes asynchrones. Si vous avez un appel asynchrone pour récupérer l’état de consentement, par exemple, il est possible que même lors du déclenchement de la balise avec le Initialisation du consentement déclencheur, il ne se termine qu’après que d’autres balises ont déjà commencé à se déclencher sur des déclencheurs ultérieurs.

Initialisation du consentement

Initialisation du consentement est un déclencheur qui se déclenche avant tout autre déclencheur dans le conteneur. Il est généré par programme pour être le tout premier déclencheur qui peut se déclencher sur une page donnée.

Cela signifie qu’il est bon pour, comme son nom l’indique, établir le état de consentement par défaut des nouveaux types de consentement, par exemple (voir ci-dessous).

En d’autres termes, si vous utilisez une plate-forme de gestion du consentement et que vous souhaitez exécuter du code (peut-être leur propre modèle personnalisé) qui établit l’état de consentement par défaut pour les cinq types de consentement différents, cette est le bon type de déclencheur à utiliser.

Le déclencheur intégré qui est automatiquement disponible dans tous les conteneurs s’appelle Initialisation du consentement – Toutes les pages.

Les dataLayer l’événement pour ce type de déclencheur est gtm.init_consent (bien que vous ne le trouviez pas réellement dans le dataLayer tableau), et en mode Aperçu, il apparaît comme Initialisation du consentement.

Initialisation

L’autre nouveau type de déclencheur est Initialisation. Cela tire après Initialisation du consentement mais avant les premiers événements déclencheurs qui ont été poussés dans dataLayer.

C’est là que vous établiriez des dépendances non liées au consentement pour le reste du conteneur à utiliser.

Comme il se déclenche avant tout ce qui est poussé dans dataLayeril garantit que l’exécution des balises commence avant tout déclencheur basé sur les données réelles dataLayer les événements ont une chance de se déclencher. Notez simplement la mise en garde concernant les balises asynchrones ci-dessus !

Le déclencheur intégré est appelé Initialisation – Toutes les pages.

Les dataLayer l’événement pour ce type de déclencheur est gtm.initet en mode Aperçu, il apparaît comme Initialisation.

Nouvelles API de modèles

Si vous ne cherchez pas à créer des modèles personnalisés, vous pouvez passer au chapitre suivant.

Si vous créez un modèle personnalisé pour une plate-forme de gestion du consentement (ou tout autre script qui devrait définir le statut du consentement), de nouvelles API de modèle sont disponibles pour vous.

Il y a également certaines nouvelles API disponibles pour rendre les modèles généralement sensibles à l’état de consentement sur le site.

Définir l’état de consentement par défaut

État de consentement par défaut est quelque chose qui s’applique dès que la balise se déclenche (de préférence sur le Initialisation du consentement déclencheur). Cela établit une base de référence pour les paramètres de consentement. Ses valeurs peuvent être dérivées de cookies spécifiques à CMP ou de quelque chose dans le dataLayerpar exemple.

L’API s’appelle setDefaultConsentState, et il prend un objet avec cinq propriétés, chacune correspondant à un type de consentement répertorié dans le tableau ci-dessus. Vous pouvez également fournir une option region paramètre pour que les paramètres établis dans l’appel d’API s’appliquent aux visiteurs de régions spécifiques. Les régions (et sous-régions) sont fournies au format ISO 3166-2.

Les paramètres par défaut sont appliqués jusqu’à ce que l’état de consentement soit mis à jour.

Dans l’exemple ci-dessous, le modèle CMP établit un état par défaut de denied dans tous les domaines, sauf aux États-Unis, où tous sauf ad_storage est réglé sur granted Etat.

const setDefaultConsentState = require('setDefaultConsentState');  setDefaultConsentState({   ad_storage: 'denied',   analytics_storage: 'denied',   functionality_storage: 'denied',   personalization_storage: 'denied',   security_storage: 'denied' });  setDefaultConsentState({   analytics_storage: 'granted',   functionality_storage: 'granted',   personalization_storage: 'granted',   security_storage: 'granted',   region: ['US'] }); 

Naturellement, vous souhaiterez rendre les valeurs dynamiques en fonction, par exemple, des cookies de consentement existants ou des paramètres dans le dataLayer.

Mettre à jour l’état du consentement

Si l’utilisateur interagit ensuite avec la plateforme de gestion du consentement et modifie ses préférences, vous pouvez demander au modèle d’appeler le updateConsentState API avec une structure similaire à celle ci-dessus.

Noter que region n’est pas disponible dans updateConsentState. En effet, lorsque vous devez invoquer cette API, vous devez déjà savoir quel doit être l’état de l’appel de consentement, quel que soit l’endroit où se trouve l’utilisateur.

const updateConsentState = require('updateConsentState');  updateConsentState({   ad_storage: data.ad_storage,   analytics_storage: data.analytics_storage,   functionality_storage: 'granted',   personalization_storage: data.personalization_storage,   security_storage: 'granted' }); 

Dans l’exemple ci-dessus, la fonctionnalité et le stockage de sécurité sont codés en dur pour grantedet tous les autres états de consentement sont extraits des champs de modèle, très probablement configurés pour répondre au choix de l’utilisateur.

Vérifier l’état du consentement

Si vous souhaitez qu’un modèle modifie son comportement en fonction de l’état de consentement actuel, vous pouvez utiliser le isConsentGranted API.

Cela prend un seul paramètre – l’un des cinq types de consentement – et renvoie true ou alors falseen fonction de l’état du consentement pour le type de consentement donné.

Par exemple, pour définir un cookie uniquement si analytics_storage le consentement a été accordé, vous pouvez exécuter ce code :

const isConsentGranted = require('isConsentGranted');  if (isConsentGranted('analytics_storage')) {   // Custom method that handles setting the cookie   setCustomAnalyticsCookie(); } 

Écoutez les changements d’état de consentement

Parfois, il est super maladroit d’ajouter simplement des déclencheurs à une balise pour lui faire réévaluer sa fonctionnalité en fonction des paramètres de consentement, par exemple. C’est pourquoi il y a une nouvelle API, addConsentListenerqui peut être utilisé pour exécuter un rappel dans un modèle une fois que l’état de consentement pour un type de consentement donné a changé.

const addConsentListener = require('addConsentListener');  const consentCallback = (consentType, granted) => {   if (consentType === 'analytics_storage' && granted) {     setCustomAnalyticsCookie();   } };  addConsentListener('analytics_storage', consentCallback); 

Le rappel reçoit le type de consentement et indique si le consentement a été accordé ou non (true / false) comme arguments.

C’est une solution assez astucieuse, car elle laisse la logique de traitement par lots et de répartition à la balise elle-même. Vous n’avez pas besoin de surconcevoir la balise avec des déclencheurs personnalisés qui détectent le changement d’état de consentement – le modèle s’en chargera pour vous.

Le modèle écoutera simplement les modifications apportées à l’état de consentement et enverra automatiquement le hit qui a été bloqué en raison d’un manque de consentement avant la mise à jour de l’état.

Nouvelle autorisation : Accéder à l’état de consentement

Il y a aussi le nouveau Accède à l’état de consentement autorisation, qui contrôle les états de consentement que le modèle est autorisé à lire/écrire.

Voici les autorisations requises par toutes les API répertoriées ci-dessus :

Chaque type de consentement que vos API veulent lire et/ou écrire doit être répertorié séparément dans le tableau des autorisations (il peut donc avoir un maximum de cinq lignes).

Tous les types de consentement que vous ajoutez à ce tableau des autorisations seront répertoriés dans le Vérifications de consentement intégrées section de la balise.

Travailler avec les plateformes de gestion du consentement

Ce n’est un secret pour personne que ces nouveaux paramètres de consentement ont été créés Plus précisément avec les CMP à l’esprit.

Cependant, pour qu’il y ait un réel bénéfices Pour utiliser une CMP avec ces nouveaux paramètres, quelques éléments doivent être en place :

1. Le CMP doit créer un modèle personnalisé qui utilise les nouveaux types de consentement et des API de statut de consentement par défaut et de mise à jour.
2. Idéalement, les balises que vous exécutez dans le conteneur devraient modifier leur comportement basé sur l’état de consentement. Ils peuvent le faire avec les nouvelles API de modèles qui permettent aux modèles de réagir à l’état de consentement (et aux modifications).
3. À tout le moins, vous devriez passer en revue chaque étiquette du conteneur et vérifier son Réglages avancés pour voir si le statut de consentement devrait bloc la balise si elle n’est pas accordée.

Les plus gros goulots d’étranglement sont évidemment (1) et (2). À en juger par la liste fournie par Google, il ne semble pas que les CMP les plus populaires sautent exactement sur l’opportunité d’intégrer soit GTM, soit le mode consentement. Eh bien, ce sont encore des fonctionnalités assez nouvelles (et en version bêta), alors espérons que la situation s’améliorera bientôt.

Espérons que les modèles de balises en général seront conçus pour être conscients du consentement si nécessaire. Cela a beaucoup de sens pour les modèles qui pouvez fonctionnent sans stockage pour bloquer conditionnellement la configuration des cookies s’il n’y a pas de consentement approprié disponible.

De même, les fournisseurs qui faire disposer d’un point de terminaison distinct pour la collecte de données « respectueux de la vie privée » (par exemple, pas de cookies tiers) devrait décider quel point de terminaison utiliser en fonction de l’état du consentement pertinent.

Comme précédemment, la configuration de la gestion des consentements est beaucoup de travail. C’est par conception, car le consentement doit être délibérément intégré et conçu, car il y a des conséquences juridiques à ignorer la granularité de ce qu’est réellement le choix de l’utilisateur.

Avec ces nouveaux paramètres de consentement dans GTM, heureusement, ce n’est plus l’administrateur de Google Tag Manager qui doit faire le gros du travail, mais les fournisseurs sont également tenus de participer et de coopérer.

Résumé

Chaque fois que Google Tag Manager fait un effort conscient pour faciliter la vie de ses administrateurs et utilisateurs, cela me rend heureux.

L’intégration des plates-formes de gestion des consentements avec Google Tag Manager a toujours été un véritable casse-tête. Les nouvelles fonctionnalités de consentement ne suppriment pas toutes les frictions, mais elles facilitent la gestion de la collaboration avec les CMP pour s’assurer que le conteneur GTM est câblé pour les options de consentement.

De même, les fournisseurs de services disposent désormais de nouvelles API de modèles qui leur permettent d’ajouter plus de granularité à leurs balises que de simplement bloquer ou déclencher en fonction du choix du consentement. J’espère vraiment, vraiment que les fournisseurs utiliseront ces fonctionnalités.

Les nouvelles fonctionnalités de l’interface utilisateur facilitent l’audit rapide d’un conteneur pour la prise en charge du consentement, mais je me suis retrouvé à vouloir encore plus de transparence à partir des paramètres de balise directement. Il est bon de savoir quels sont les choix de consentement intégrés, par exemple, mais il serait encore plus utile de savoir comment la balise repose en fait sur le consentement sans avoir à creuser dans le code du modèle lui-même.

D’autres choses qui, selon moi, devraient être améliorées incluent :

• Incitez à l’aide des nouveaux types de déclencheurs d’initialisation du consentement et d’initialisation. Faites-les fonctionner également avec des requêtes asynchrones (c’est-à-dire ne passez pas à l’événement déclencheur suivant tant qu’un signal de réussite n’a pas été envoyé).
• Ajoutez également la prise en charge du consentement pour Google Tag Manager côté serveur. Les gcs Le paramètre dans l’URL de la demande (des balises Google) pourrait être utilisé pour transmettre les cinq types de consentement, et l’environnement de balisage côté serveur pourrait alors déchiffrer le consentement de l’utilisateur à partir de ce paramètre, en utilisant des API spécialement conçues dans les modèles.
• Permettre également d’accorder / de refuser le consentement fournisseur par fournisseur.
• Rendre possible l’ajout de types d’objectifs personnalisés au lieu des cinq types de consentement désormais disponibles (bien que ce soit bien mieux que les deux (ad_storage et analytics_storage) nous avions!).
• Exposez également l’état de consentement à l’extérieur de Google Tag Manager, car il est possible que toutes les balises ne soient pas exécutées via Google Tag Manager.

En général, le consentement est fondé sur transparence. Plus GTM peut améliorer la transparence de l’état du consentement, mieux c’est pour toutes les parties concernées.

Que pensez-vous de l’état actuel de la gestion du consentement dans Google Tag Manager ?