Google Analytics 4 - Proxy Mode
Anonymiser les données avant de les envoyer à Google
1. Utiliser les options de proxy dans les paramètres de destination
L'option mode proxy dans la destination GA4 vous permet d'anonymiser les données avant de les envoyer à Google.
Lorsqu'elle est activée, la mode proxy vous donne accès à un certain nombre d'options qui vous permettent de choisir de manière granulaire comment chaque paramètre doit être anonymisé.
Vous trouverez ci-dessous la recommandation de la CNIL, et pour chaque paramètre le mode proxy vous donne une façon conviviale de gérer l’anonymisation :
l'absence de transfert de l'adresse IP vers les serveurs de l'outil d'analytics. Si une localisation est transmise aux serveurs de l'outil de mesure, elle doit être effectuée par le serveur proxy et le niveau de précision doit garantir que cette information ne permet pas de ré-identifier la personne (par exemple, en utilisant une grille géographique assurant un nombre minimum d'internautes par cellule); Solution : Vous pouvez choisir d'obfusquer l'IP (le dernier octet (la dernière portion) de l'adresse IP est remplacé par 0) ou de la supprimer complètement. L'obfuscation est souvent préférée car elle permet de supprimer le caractère identifiant de l'IP tout en conservant les fonctionnalités de géolocalisation du pays\
le remplacement de l'identifiant utilisateur par le serveur proxy. Pour assurer une pseudonymisation effective, l'algorithme effectuant le remplacement devrait garantir un niveau suffisant de collision (c’est-à-dire une probabilité suffisante que deux identifiants différents donnent un résultat identique après un hash) et inclure un composant variable dans le temps (ajouter une valeur aux données hashées qui évolue dans le temps afin que le résultat du hash ne soit pas toujours le même pour le même identifiant) ; Solution : Vous pouvez choisir de pseudonymiser le client id (cid) et le user id (uid). Cette option de pseudonymisation consiste à remplacer l'id par un hash de l'id plus un salt. L'id sera d'abord concaténé avec un salt qui change toutes les ~3 h puis sera hashé en utilisant SHA256. Cela permet de créer des ids anonymes qui sont identiques au sein d'une session mais différents d'une session à l'autre. Cela empêchera GA4 de suivre un utilisateur dans le temps.\
la suppression des informations de referrer externes de le site ; Solution : Vous pouvez choisir de le supprimer ou de ne garder que les domaines internes.\
la suppression de tous les paramètres contenus dans les URL collectées (par ex. les UTMs, mais aussi les paramètres d'URL permettant le routage interne du site) ; Solution : Vous pouvez choisir de supprimer tous les paramètres d'URL, de ne garder que des paramètres spécifiques et/ou de conserver les UTMs dans certains cas\
le retraitraitement des informations pouvant être utilisées pour générer un fingerprint, telles que les user-agents, pour supprimer les configurations les plus rares qui peuvent conduire à une ré-identification ; Solution : Choisir de supprimer complètement le user-agent semble être la meilleure option.\
l'absence de collecte d'identifiants cross-site ou durables (CRM ID, unique ID) ; Solution : Utilisez la Properties Transformation fonctionnalité ou la Nettoyage des données fonctionnalité à traiter au cas par cas en supprimant/hashant/transformant vos propriétés (voir Gérer les PII personnalisées ci-dessous) Il est souvent plus facile de supprimer complètement le user id.\
la suppression de toute autre donnée pouvant conduire à une ré-identification. Solution : Utilisez la Properties Transformation fonctionnalité ou la Nettoyage des données fonctionnalité à traiter au cas par cas en supprimant/hashant/transformant vos propriétés (voir Gérer les PII personnalisées ci-dessous)
2. Gérer les PII personnalisées
En plus du mode proxy GA4, vous pouvez également utiliser sur chaque destination, la Properties Transformation fonctionnalité ou la Nettoyage des données fonctionnalité pour transformer/supprimer/hasher toute propriété d'événement avant de l'envoyer au partenaire.
2.1. Transformation des propriétés sur une destination spécifique
2.2. Data Cleansing pour toutes les destinations
3. Analyse d'impact et suggestions ouvertes
Absence de transfert d'adresse IP vers les serveurs de l'outil de mesure
Ce point est normal et standard.
Anonymiser les IPs en supprimant les 3 derniers caractères. Impact : Cela peut se traduire par une perte de précision de localisation, passant d'une mesure au niveau de la ville à celle de la région.
Remplacement de l'identifiant utilisateur par le serveur proxy
La CNIL doute que Google n'utilise pas ces données conjointement avec d'autres données tierces.
Ajouter une pseudonymisation avant l'envoi de l'ID. Aucun impact.
Suppression des informations de referrer externes (ou « referrer ») du site
La suppression complète du referrer est une proposition surprenante, alors que le réduire au nom de domaine est courant dans d'autres outils (Safari, Adblockers, ...)
Réduire le referrer au nom de domaine, ce qui est une mesure statistique simple d'audience. Si cette suggestion est suivie, il n'y aura aucun impact. (Si la recommandation de la CNIL est suivie, l'outil deviendra inutilisable ou presque inutilisable) Vous pouvez aussi choisir d'autoriser uniquement les domaines internes, dans ce cas l'impact peut être important, notamment sur les rapports de trafic source.
Suppression de tous les paramètres contenus dans les URL collectées
Il est légitime de supprimer les paramètres d'URL contenant des informations personnelles, mais peut-être pas les informations générales comme les utm_campaigns.
Supprimer les paramètres d'URL au cas par cas s'ils contiennent des données personnellement identifiables. Les utm_campaigns peuvent être conservés s'ils sont correctement gérés, mais la question se pose pour les identifiants de clics publicitaires tels que fbclid et gclid. Si la recommandation de la CNIL est suivie, l'outil deviendra inutilisable ou presque inutilisable, tandis que si notre recommandation est suivie, il y aura peu d'impact. En cas de suppression du gclid, les utms devront être utilisés pour taguer les campagnes Google Ads.
Retraitement des informations qui pourraient contribuer à générer un fingerprint
Cette demande est légitime et courante et sera mise en œuvre dans les navigateurs à l'avenir.
Supprimer les informations non nécessaires du user agent pour minimiser la perte d'informations granulaires telles que le modèle de téléphone. Choisir de supprimer complètement le user-agent semble être l'option la plus simple. Impact : pas si faible. L'application de cette mesure ne distingue plus le type d'appareil (device_category)
Absence de toute collecte d'identifiants cross-site ou déterministes (CRM, unique ID)
Cette demande est considérée comme non pertinente tant que le consentement est obtenu. Ces IDs ne peuvent pas être utilisés par Google pour d'autres recoupements de données.
Il est recommandé de demander le consentement pour l'utilisation de ces IDs et de les traiter de manière sécurisée si le consentement est donné. Mais vous pouvez souhaiter hasher tous ces ids avant de les envoyer à Google (dans ce cas vous pouvez utiliser la transformation de propriétés)
Configuration rapide
1. Mettez à jour votre gtag côté client
Comme pour les configurations classiques GA4 server-side, vous devez configurer un unique tag client-side Gtag initial qui ne sera déclenché qu'une seule fois par visite et enverra un événement d'initialisation vide. Ceci est nécessaire en raison des limitations du protocole de Google.\
Ensuite la particularité avec le mode proxy est que vous devez modifier l'URL de hit GA4, en remplaçant google-analytics.com par l'URL de collecte server-side de Commanders Act. Cela se fait via le paramètre natif GA : transport_url (Exemple de code fourni ci-dessous).
La transport_url doit être défini sur votre URL de tracking.
Votre domaine de tracking est soit :
votre sous-domaine 1st party défini dans gestion de domaine Dans ce cas le
transpor_urldoit être défini sur :https://VOTRE_DOMAINE_DE_SUIVI_1ST.com/cdp/events?tc_s=VOTREIDDESITE&token=VOTRECLEFDESOURCE&event_name=ga_session_start&ga_url_param=ou notre domaine de collecte third party
collect.commander1.comDans ce cas letranspor_urldoit être défini sur :https://collect.commander1.com/events?tc_s=VOTREIDDESITE&token=VOTRECLEFDESOURCE&event_name=ga_session_start&ga_url_param=
En conséquence, ce premier hit n'est plus envoyé à Google, mais au serveur de Commanders Act, qui le transforme en un événement CA. Cet événement sera ensuite envoyé à votre destination GA4 où il sera traité (pseudonymisé, etc. selon les paramètres choisis) avant d'être renvoyé à Google.
À part ce premier hit client-side, tous les autres événements du site web doivent être envoyés depuis n'importe quelle source, par exemple via notre fonction cact('trigger', 'myEventName', ...). Ces événements atteindront également, bien sûr, votre destination GA4 où les données seront pseudonymisées selon les paramètres de la destination.
2. Configurez votre destination GA4
- Dans l'onglet des paramètres, cochez l'option « Enable proxy mode » et choisissez quelle pseudonymisation/traitement vous voulez appliquer. - Si nécessaire, hashez vos PII personnalisées via le smart mapping, la transformation de propriétés ou Nettoyage des données
3. (Optionnel) Vérifiez que toutes les données PII envoyées sont correctement pseudonymisées
Parcourez onglet Event Inspector et inspectez les événements sortants.
Mis à jour
Ce contenu vous a-t-il été utile ?