La gestion du consentement des utilisateurs est plus importante que jamais, en particulier avec les lois sur la protection de la vie privée comme le RGPD et la CCPA. Il est essentiel de s’assurer que la collecte et l’utilisation des données sont effectuées en fonction de ce que les utilisateurs ont accepté. La gestion du consentement côté serveur vous aide à cette fin de manière plus sûre et avec une meilleure précision du suivi.
Didomi est une plateforme de gestion du consentement qui aide les entreprises à se conformer aux réglementations en matière de confidentialité des données. Didomi et Stape s’engagent à respecter la sécurité et la confidentialité des données. C’est dans cette optique que nous avons rédigé cet article afin de simplifier le processus de configuration de la gestion du consentement côté serveur et à garantir que votre entreprise soit toujours en conformité compte tenu de l’évolution des normes en vigueur en matière de protection de confidentialité.
Dans cet article, nous allons vous montrer comment configurer une gestion du consentement côté serveur avec Google Tag Manager (GTM) et Didomi. À la fin de l’article, vous saurez comment collecter et gérer sans difficulté le consentement des utilisateurs et comment maintenir vos pratiques en matière de données claires et conformes aux réglementations.
Nombreux sont ceux qui croient à tort que la gestion du consentement est facultative avec le balisage côté serveur. Malheureusement, ce n’est pas vrai. Tout comme pour le suivi sur le Web, la gestion du consentement est essentielle pour le balisage côté serveur.
Voici comment fonctionne le consentement dans le conteneur de serveur GTM:
La configuration de la gestion du consentement offre plusieurs avantages clés, ce qui en fait une solution de plus en plus populaire pour les entreprises qui gèrent les données des utilisateurs sur les sites web et les applications mobiles. Voici les principaux avantages:
| Avantage | Description |
| 1. Amélioration du respect de la confidentialité des données | - Contrôle renforcé: Gestion du consentement au niveau du serveur pour se conformer à des réglementations telles que le RGPD, le CCPA et l’ePrivacy, en s’assurant à ce qu’aucune donnée personnelle ne soit collectée sans le consentement explicite de l’utilisateur.- Moins de fuites de données: Réduction de l’accès non autorisé de tiers aux données, ce qui renforce la sécurité et protège les informations des utilisateurs. |
| 2. Sécurité accrue des données | - Traitement des données côté serveur: Le traitement des données dans un environnement de serveur sécurisé minimise les risques de falsification ou d’interception par comparaison au suivi côté client.- Exposition réduite aux bloqueurs de publicité: Les bloqueurs de publicité sont contournés, ce qui garantit les fonctions essentielles de suivi et d’analyse sans compromettre la confidentialité de l’utilisateur. |
| 3. Consentement unifié sur toutes les plateformes | - Cohérence entre les plateformes: Application du consentement de l’utilisateur sur plusieurs plateformes (sites web, applications mobiles), en s’assurant du traitement uniforme des données et en évitant les divergences.- Gestion centralisée du consentement: Simplification de la gestion du consentement en appliquant les mêmes paramètres à différents outils et plateformes. |
| 4. Meilleure performance du site | - Charge réduite sur le navigateur: Le transfert du suivi au serveur réduit la charge sur le navigateur du client, ce qui améliore le temps de chargement des pages et l’expérience de l’utilisateur.- Exécution plus rapide des balises: Les balises côté serveur s’exécutent indépendamment du navigateur de l’utilisateur, ce qui améliore la fiabilité et la rapidité de la collecte des données. |
| 5. Une collecte de données plus précise | - Minimisation des pertes de données: Risques réduits que la collecte de données soit bloquée ou perturbée par des restrictions du navigateur ou des mesures de protection contre le pistage, ce qui favorise une plus grande précision.- Suivi anonyme en cas de non-consentement: Collecte anonyme des données en mode de consentement avancé, ce qui permet l’apprentissage automatique et la prise de décisions éclairées sur la base de données agrégées. |
Pour gérer efficacement le consentement dans le cadre de GTM côté serveur, vous devez disposer de plusieurs éléments:
Il existe deux modes de consentement dans Google Tags, chacun avec un impact différent sur la configuration du consentement côté serveur:
| Comportement de consentement | Description | Impact sur l’implémentation |
| Mode de consentement de base | Le chargement des balises Google est bloqué jusqu’à ce que l’utilisateur donne son accord. Aucun ping n’est envoyé à Google, ce qui signifie que ssGA4 ne peut pas transmettre le statut du consentement de l’utilisateur. | - |
| Mode de consentement avancé | Les balises Google envoient des pings anonymes, même sans le consentement de l’utilisateur, ce qui permet à Google d’utiliser l’apprentissage automatique pour modéliser le comportement de l’utilisateur sans son consentement. | Les pings GA4 peuvent être utilisés pour suivre le statut du consentement sur le serveur et Google utilisera les données de consentement pour modéliser le comportement des utilisateurs non consentants. |
Voici une liste de nos articles sur le consentement, car nous avons déjà largement abordé ce sujet par le passé:
1.1. Activer l’intégration de Didomi dans GTM
Activez l’intégration dans GTM dans l’onglet Intégrations de votre notification de consentement en sélectionnant cette option:
Par défaut, Didomi utilise le nom «dataLayer» comme nom de variable pour votre couche de données GTM.
Si vous utilisez un autre nom pour votre couche de données, vous pouvez demander à Didomi d’utiliser ce nom à la place, en le saisissant dans le champ «DATA LAYER NAME».
Si vous configurez Didomi via la console, vous pouvez passer à l’étape suivante (1.2 - Configurer les variables dans GTM).
Intégration du SDK Didomi dans GTM.
Nous recommandons de ne pas intégrer le SDK Didomi dans GTM. Directement présent dans vos pages, le SDK Didomi peut se charger plus rapidement et cela garantit également que les vendors IAB peuvent détecter un CMP sur la page dès que possible.
L’intégration du SDK Didomi dans GTM permettra de réduire le nombre de consentements transmis aux vendors et d’abaisser le taux de consentement de leur perspective.
1.2. Configurer les variables dans GTM
Le SDK Didomi enverra à GTM automatiquement des variables et des événements qui contiennent le statut du consentement de l’utilisateur. Vous pouvez ensuite utiliser ces variables et événements personnalisés pour décider quand charger une balise vendor sur votre site web.
Tout d’abord, vous devez configurer une variable de couche de données qui correspond à la variable didomiVendorsEnabled, par exemple, qui sera poussée par le SDK dans la couche de données.
1. Allez dans la section «Dossiers» de votre espace de travail Google Tag Manager.
2. Créez un nouveau dossier nommé «Didomi».
3. Cliquez sur «Ajouter une nouvelle variable».
4. Créez de nouvelles variables définies par l’utilisateur avec les paramètres suivants:
Vous pouvez lire cette documentation pour la liste de toutes les variables qui sont poussées vers GTM par le SDK Didomi.
1.3. Configurer les déclencheurs
Vous devez créer des déclencheurs qui seront utilisés pour décider quand charger chaque balise dans Google Tag Manager.
Pour chaque balise de vendor que vous devez contrôler, dans la section «Dossiers» du gestionnaire, ajoutez un nouveau déclencheur au dossier Didomi:
Utilisez la configuration suivante:
Lorsque les vendors sont associés par des identifiants dans les variables, utilisez l’identifiant complet du vendor avec une virgule supplémentaire (,) à la fin pour éviter que les identifiants ne soient mélangés et associés. Par exemple: Utilisez «google» pour associer le vendor avec l’identifiant «google» et non le vendor avec l’identifiant «googleana-4TXnJigR».
Répétez ce processus pour chaque vendor non-IAB. Vous devez créer un déclencheur par vendor non-IAB.
Ensuite, si votre déclencheur actuel est un déclencheur personnalisé, vous devrez créer un groupe de déclencheurs, de sorte que la balise se déclenche lorsque la condition 1 (condition déjà existante) et la condition 2 (liée au consentement) sont toutes deux satisfaites.
Sinon, si vous ajoutez un autre déclencheur lié au consentement à une balise avec une condition déjà existante, la balise se déclenchera lorsque la condition 1 OU la condition 2 sera satisfaite. Mais pas nécessairement les deux en même temps et cela ne sera pas conforme.
Dans la section «Dossiers» du gestionnaire, ajoutez un nouveau déclencheur au dossier Didomi avec la configuration suivante:
| Remarque : Veuillez noter que les groupes de déclencheurs sont déclenchés une seule fois par page, ce qui peut poser problème lors de l’utilisation de sites web dynamiques. Dans ce cas, vous pouvez utiliser nos fonctionnalités et événements. En outre, dans le contexte spécifique d’un SPA, vous pouvez vous référer à notre page GitHub dédiée. |
Pour trouver l’identifiant de votre vendor, dans votre compte Didomi, allez à Consent notices → Open your notice → Regulation → Edit vendors and Purposes: copiez l’identifiant de l’API. Pour en savoir plus sur les variables, consultez cette documentation.
Ce déclencheur (ou groupe de déclencheurs) peut désormais être utilisé pour définir des balises qui ne se déclenchent que lorsque l’utilisateur a donné son consentement pour ce vendor.
Si vous suivez ces instructions tout en activant Google Consent Mode, vous aurez un impact négatif sur la fonctionnalité Consent Mode en empêchant les balises Google de se déclencher tant que le consentement n’a pas été accordé.
Si vous activez Google Consent Mode via notre intégration directe GCM, assurez-vous qu’aucune balise relative au consentement n’est configurée pour les balises Google (vendors google, googleana-4TXnJigR).
Pour vous assurer que Google Consent Mode est actif, vous devez supprimer tout événement relatif au consentement et n’utiliser que l’événement didomi-ready.
1.4. Catégoriser les balises
Vous devez maintenant catégoriser vos balises et définir ce pour quoi le consentement de l’utilisateur est requis pour le déclenchement de chaque balise. Cette dernière étape est très importante.
Dans la section «Balises» de votre Google Tag Manager, modifiez chacune de vos balises existantes concernant les vendors non-IAB et ajoutez le déclencheur ou le groupe de déclencheurs (créé à l’étape 1.3) correspondant au vendor qui détient la balise à la place de ce qui était utilisé précédemment.
N’oubliez pas de conditionner les balises de tous vos conteneurs.
À l’avenir, chaque fois que vous ajoutez une nouvelle balise qui n’implémente pas la spécification de l’IAB et qui nécessite le consentement selon le RGPD, vous devez la catégoriser en ajoutant le déclencheur adéquat.
Si vous souhaitez configurer un mode de consentement avancé, choisissez de préférence une des options suivantes: la console ou le modèle GTM de Didomi.
Pour en savoir plus sur la configuration de Google Consent Mode avec Didomi, consultez leur documentation officielle.
Cochez l’option «Définir le statut par défaut» afin de pouvoir faire un choix spécifique pour chacune des sous-options associées. Les sous-options cochées indiquent que le statut sera défini comme accordé lors du chargement initial de la page.
Par exemple, si vous activez l’option «Activer ad_storage avant que l’utilisateur ne donne son consentement» dans votre site web, le chargement initial de la page pour ad_storage sera défini comme étant accordé.
Suivez ces instructions pour configurer GCM avec le modèle GTM de Didomi.
Définissez le statut par défaut comme accordé à GCM pour la (les) permission(s) souhaitée(s).
Les balises Google (Ad Words, Analytics, Conversion Linker et Floodlight) doivent être chargées dès que le SDK est prêt.
Les balises enverront alors des données basées sur le statut par défaut.
En mode avancé, il est donc important de définir le statut par défaut que vous souhaitez voir exposé par Didomi.
Pour configurer le mode avancé avec Google Tag Manager, utilisez l’événement didomi-ready pour vous assurer que les balises Google sont chargées une fois que le SDK de Didomi est prêt et que Consent Mode est activé (ou un groupe de déclencheurs si nécessaire).
Vous pouvez vous référer à cette documentation.
Si vous ne disposez pas d’un conteneur de serveur, consultez notre guide sur la manière de le configurer avec le serveur Google Tag Manager.
3.1. Configurer un domaine personnalisé pour votre conteneur GTM du serveur avec Stape. Après l’ajout du domaine personnalisé, vous devez configurer les paramètres DNS que vous voyez à l’écran. La vérification du domaine peut nécessiter jusqu’à 72 heures.
| Dans notre blog, vous trouverez un guide détaillé sur la façon d’ajouter un domaine personnalisé au conteneur de serveur de Google Tag Manager. |
3.2. Allez dans les paramètres du conteneur de serveur Google Tag Manager et ajoutez un domaine personnalisé ou l’URL du serveur de balisage par défaut (non recommandé) dans le serveur GTM.
3.3. Actualisez le script web GTM de votre site web avec Custom Loader.
Deux options sont possibles:
4.1.1. Ajoutez l’URL de votre conteneur de serveur aux paramètres de Google Tag. Dans les paramètres de configuration, ajoutez le paramètre de configuration server_container_url et ajoutez l’URL de votre serveur de balisage comme valeur.
4.1.2. Configurer le client Google Analytics 4 dans le conteneur GTM du serveur. Pour cela, ouvrez la section des clients → Créer un Nouveau client → Sélectionnez le type de client Google Analytics: GA4 (Web) → Ajoutez le nom du client et cliquez sur Enregistrer.
4.1.3. Dans le conteneur GTM du serveur, créez une nouvelle balise avec le type de balise Google Analytics: GA4.
4.1.4. Ajouter l’identifiant de la mesure et le nom de l’événement.
Identifiant de la mesure: Suivez ce guide pour trouver l’identifiant de GA4. Vous pouvez l’ajouter en tant que variable ou, si l’événement provient d’une balise web GA4, vous pouvez laisser ce champ vide pour hériter de l’identifiant de mesure de l’événement.
Nom de l’événement: Le nom de l’événement à envoyer à Google. Consultez les événements recommandés pour plus d’informations. Si ce champ est vide, la valeur du paramètre event_name sera envoyée.
4.1.5. Cliquez sur Déclenchement et configurez un déclencheur de type personnalisé qui se déclenchera à chaque fois que le nom du client sera GA4 (ou au nom du client GA4 que vous avez spécifié à l’étape 2.b) → Cliquez sur Enregistrer.
4.2.1. Dans le conteneur web, configurez une nouvelle balise de type Google Tag. Ajoutez votre identifiant de balise Google.
Ajoutez un déclencheur à la balise GA4.
Vous pouvez également créer une variable « Balise Google : paramètres de configuration » qui prédéfinira les paramètres de la balise Google si vous devez utiliser plusieurs balises Google sur votre site web et que vous ne souhaitez pas ajouter manuellement des paramètres pour chaque balise.
Ces paramètres peuvent, par exemple, définir si vous souhaitez envoyer un événement de consultation de page à chaque fois qu’une balise Google se déclenche, définir des paramètres UTM, définir l’identifiant du client, etc. Il existe une liste des paramètres de configuration standard des balises Google.
4.2.2. Pour configurer le suivi de l’événement GA4, allez dans la section des balises et créez une nouvelle balise avec le type de balise Google Analytics : événement GA4. Ajoutez votre identifiant GA4 et le nom de l’événement. Il existe une liste de noms d’événements standard.
4.2.3. Allez dans votre conteneur de serveur Google Tag Manager. Cliquez sur Clients et sur Nouveau.
4.2.4. Choisissez Google Analytics : GA4 (Web) et cliquez sur Enregistrer.
4.2.5. Allez dans Balises et cliquez sur Nouvelle.
4.2.6. Choisissez Google Analytics: GA4.
4.2.7. Ajoutez l’identifiant de la mesure et le nom de l’événement.
Identifiant de la mesure: suivez ce guide pour trouver l’identifiant GA4. Vous pouvez l’ajouter en tant que variable ou, si l’événement provient d’une balise web GA4, vous pouvez laisser ce champ vide pour hériter de l’identifiant de mesure de l’événement.
Nom de l’événement: le nom de l’événement à envoyer à Google. Consultez les événements recommandés pour plus d’informations. Si ce champ est vide, la valeur du paramètre event_name sera envoyée.
4.2.8. Cliquez sur Déclenchement.
4.2.9. Créez des déclencheurs pour la balise. Le nom du client doit être GA4.
4.2.10. Ouvrez les débogueurs web et serveur de GTM, et testez la configuration.
Ouvrez le mode aperçu du conteneur de serveur et vérifiez que vous voyez les requêtes GA4. Publiez les mises à jour dans les conteneurs de serveur et web de Google Tag Manager.
GTM fonctionne avec des plateformes de gestion du consentement comme Didomi pour modifier le comportement des balises en fonction du consentement de l’utilisateur. Les balises Google, telles que GA4, s’ajustent automatiquement aux paramètres de consentement de l’utilisateur configurés dans le conteneur web GTM.
En cas de consentement avancé, GA4 continuera à envoyer des pings anonymes même si les utilisateurs ne donnent pas leur consentement pour les cookies analytiques. Pour activer cette option, actualisez les paramètres de consentement dans le conteneur web GTM avec la valeur «Aucun consentement supplémentaire requis». Aucune configuration supplémentaire n’est nécessaire dans le conteneur de serveur GTM pour le consentement avancé.
Pour limiter toute collecte de données par GA4 sans consentement explicite, définissez les paramètres de consentement sur «Demander un consentement supplémentaire» dans le conteneur web GTM. GA4 côté serveur se conformera aux règles de consentement définies dans le conteneur web GTM.
En mode de consentement avancé, les requêtes GA4 anonymes sont envoyées au serveur GTM. Les déclencheurs de l’API Conversions de Facebook sont basés sur la valeur du paramètre GCS. La balise CAPI ne doit se déclencher que lorsque les cookies ad_storage sont autorisés (lorsque les GCS sont 110 ou 111).
6.1.1. Créez une variable GCS
Dans le serveur GTM, créez une nouvelle variable pour lire le paramètre GCS depuis la requête GA4. Utilisez le type de variable Données d’événement et saisissez x-ga-gcs comme chemin d’accès.
6.1.2. Actualisez la balise CAPI de Facebook
Actualisez la balise API Conversions de Facebook pour qu’elle se déclenche uniquement lorsque la variable x-ga-gcs est égale à 110 ou 111.
Avec le mode de consentement de base, GA4 n’envoie pas de pings anonymes au conteneur du serveur. Vous aurez donc besoin d’un autre moyen pour transmettre le statut du consentement des utilisateurs à sGTM. Dans cet exemple, nous utiliserons une balise de données et un client de données pour transmettre le consentement de l’utilisateur à sGTM.
6.2.1. Ajoutez une balise de données dans le conteneur web GTM
Ajoutez la balise de données depuis la galerie de modèles de communautés. Définissez le nom de l’événement, l’URL de transport (à partir de l’étape 2.3) et faites défiler jusqu’aux paramètres de consentement. Sélectionnez « Demander un consentement supplémentaire pour le déclenchement de la balise » et choisissez ad_storage.
6.2.2. Déclenchez la balise de données à la mise à jour du consentement
Veiller à ce que la balise de données soit déclenchée par l’événement personnalisé didomi-consent.
6.2.3. Ajoutez un modèle de client de données dans le serveur GTM
Téléchargez le modèle de client de données et ajoutez-le à votre conteneur de serveur GTM. Allez dans la section des modèles, cliquez sur Nouveau, puis sur les trois points dans le coin supérieur droit et sélectionnez Importer.
6.2.4. Configurez le client de données
Créez un nouveau client de données dans la section client de votre conteneur de serveur GTM. Ce client récupérera les informations de consentement envoyées par la balise de données.
6.2.5. Actualisez le déclencheur CAPI de Facebook
Actualisez le déclencheur de la balise CAPI de Facebook afin qu’elle se déclenche lorsque le client de données est requis et que le nom de l’événement est marketing_consent.
L’implémentation de la gestion du consentement côté serveur avec GTM et Didomi fournit une base solide pour la conformité en matière de protection de la confidentialité tout en maintenant l’exactitude des données.
Cette configuration garantit une collecte correcte du consentement avant tout traitement des données, prend en charge les implémentations de base et avancées pour Google Consent Mode et permet un contrôle granulaire des autorisations des vendors.
En suivant les étapes d’implémentation énumérées dans cet article, les organisations peuvent réaliser une synchronisation transparente des consentements entre les environnements client et serveur, renforcer la sécurité des données et améliorer les performances du site, tout en favorisant la confiance des utilisateurs et satisfaire aux normes réglementaires.
N'oubliez pas de tester régulièrement votre configuration, de surveiller l’analyse des consentements et de vous tenir informé(e) de l’évolution des exigences en matière de protection de la confidentialité pour des résultats optimaux.
Si vous avez besoin de conseils pour optimiser l’implémentation de votre gestion du consentement, notre équipe est là pour vous aider. Si vous avez des questions, n’hésitez pas à nous contacter.
Stape has lots of tags for server GTM! Click on Essai gratuit to register and check them all.
