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 le destination GA4 vous permet d'anonymiser les données avant de les envoyer à Google.
Lorsqu'il est activé, le 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 offrent un moyen convivial 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 permette pas de ré-identifier la personne (par exemple, en utilisant une maille géographique garantissant 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 garantir une pseudonymisation effective, l'algorithme effectuant le remplacement doit assurer un niveau de collision suffisant (c.-à-d. une probabilité suffisante que deux identifiants différents donnent un résultat identique après un hash) et inclure une composante variable dans le temps (ajout d'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 heures 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 référent externe du site ; Solution : Vous pouvez choisir de le supprimer ou de ne conserver que les domaines internes.\
la suppression de tous les paramètres contenus dans les URLs 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, ne conserver que des paramètres spécifiques et/ou conserver les UTMs dans certains cas\
le retraitement des informations pouvant servir à générer une empreinte (fingerprint), telles que les user-agents, pour supprimer les configurations les plus rares qui peuvent conduire à la ré-identification ; Solution : Choisir de supprimer complètement le user-agent semble être la meilleure option.\
l'absence de collecte d'identifiants inter-sites ou durables (CRM ID, unique ID) ; Solution : Utilisez la Properties Transformation fonctionnalité ou la Data Cleansing fonctionnalité à traiter au cas par cas en supprimant/hashed/transformant vos propriétés (voir Manage custom PII data ci-dessous) Il est souvent plus simple 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 Data Cleansing fonctionnalité à traiter au cas par cas en supprimant/hashed/transformant vos propriétés (voir Manage custom PII data ci‑dessous)
2. Gérer les données PII personnalisées
En plus du mode proxy GA4, vous pouvez également utiliser sur chaque destination, la Properties Transformation fonctionnalité ou la Data Cleansing 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 de l'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 entraîner 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 la pseudonymisation avant l'envoi de l'ID. Aucun impact.
Suppression des informations de référent externe (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 constitue 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 inutile ou presque) 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 URLs collectées
Il est légitime de supprimer les paramètres d'URL contenant des informations personnelles, mais peut-être pas des informations générales comme les utm_campaigns.
Supprimer les paramètres d'URL au cas par cas s'ils contiennent des données permettant d'identifier une personne. 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 inutile ou presque, tandis que si notre recommandation est suivie, il y aura peu d'impact. En cas de suppression du gclid, il faudra utiliser des utms pour taguer les campagnes Google Ads.
Retraitement des informations pouvant contribuer à générer une empreinte (fingerprint)
Cette demande est légitime et courante et sera mise en œuvre dans les navigateurs à l'avenir.
Supprimer les informations inutiles du user agent afin de minimiser la perte d'informations granulaires comme le modèle de téléphone. Choisir de supprimer complètement le user-agent semble être l'option la plus simple. Impact : pas négligeable. L'application de cette mesure ne distingue plus le type d'appareil (device_category)
Absence de toute collecte d'identifiant inter-sites ou déterministe (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 Properties transformation)
Configuration rapide
1. Mettez à jour votre gtag côté client
Comme pour les configurations GA4 server-side classiques, vous devez configurer un seul tag Gtag initial côté client 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 altérer l'URL du 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 GA natif : transport_url (Exemple de code fourni ci-dessous).
The transport_url doit être défini sur votre url de tracking.
Votre domaine de tracking est soit :
votre sous-domaine First party défini dans domain management Dans ce cas le
transpor_urldoit être défini sur :https://YOUR_1ST_TRACKING_DOMAIN.com/cdp/events?tc_s=YOURSITEID&token=YOURSOURCEKEY&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=YOURSITEID&token=YOURSOURCEKEY&event_name=ga_session_start&ga_url_param=
Par conséquent, ce premier hit n'est plus envoyé à Google, mais au serveur de Commanders Act, qui le transforme en é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 côté client, 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 arriveront é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 souhaitez appliquer. - Si nécessaire, hashez vos PII personnalisées via le smart mapping, Properties transformation ou Data Cleansing
3. ((Optionnel) Vérifiez que toutes les données PII envoyées sont correctement pseudonymisées
Parcourez Event Inspector et inspectez les événements sortants.
Mis à jour
Ce contenu vous a-t-il été utile ?