Google Analytics 4 - Proxy Mode

Anonymiser les données avant de les envoyer à Google

La protection de la vie privée des utilisateurs est devenue une nécessité avec la mise en œuvre du RGPD. Conformément à ce règlement, vous devez supprimer toute information personnelle identifiante des données utilisateur avant de les transférer à un outil appartenant à une entité américaine, en raison de l'invalidation du Privacy Shield.

La méthode La CNIL a recommandé le 7 juin 2022 que la proxification soit mise en œuvre ainsi que d'autres mesures spécifiques pour garantir la validité de l'utilisation de GA4.

1. Utiliser les options de proxy dans les paramètres de la 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é.

Quelques options du mode proxy

Vous trouverez ci-dessous la recommandation de la CNIL, et pour chaque paramètre le mode proxy vous donnent un moyen convivial de gérer l'anonymisation :

1. l'absence de transfert de l'adresse IP vers les serveurs de l'outil d'analyse. 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 la ré-identification de la personne (par exemple, en utilisant une maille géographique assurant un nombre minimum d'internautes par cellule) ; Solution : Vous pouvez choisir d'obfusquer l'IP (le dernier octet 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.

2. 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 collisions (c.-à-d. une probabilité suffisante que deux identifiants différents donnent un résultat identique après un hash) et inclure un composant variant dans le temps (ajout d'une valeur aux données haché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 l'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 environ puis sera haché en utilisant SHA256. Cela permet de créer des ids anonymes 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.

3. la suppression des informations de référent externe depuis le site ; Solution : Vous pouvez choisir de le supprimer ou de ne conserver que les domaines internes.

4. la suppression de tout paramètre contenu dans les URL collectées (par ex. 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

5. le retraitement des informations pouvant servir à générer un fingerprint, telles que les user-agents, pour supprimer les configurations les plus rares pouvant conduire à une ré-identification ; Solution : Choisir de supprimer complètement le user-agent semble être la meilleure option.

6. l'absence de collecte d'identifiants cross-site ou durables (CRM ID, ID unique) ; Solution : Utilisez la commande Properties Transformation fonctionnalité ou le Data Cleansing fonction à traiter au cas par cas en supprimant/hachant/transformant vos propriétés (voir Gérer les données PII personnalisées ci-dessous) Il est souvent plus simple de supprimer complètement l'user id.

7. la suppression de toute autre donnée pouvant conduire à une ré-identification. Solution : Utilisez la commande Properties Transformation fonctionnalité ou le Data Cleansing fonction à traiter au cas par cas en supprimant/hachant/transformant vos propriétés (voir Gérer les données PII personnalisées below)

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 le Data Cleansing fonction pour transformer/supprimer/hacher toute propriété d'événement avant de l'envoyer au partenaire.

2.1. Transformation des propriétés sur une destination spécifique

Section transformation des propriétés à l'étape des paramètres de chaque destination

2.2. Nettoyage des données pour toutes les destinations

fonction Data Cleansing

3. Analyse d'impact et suggestions ouvertes

Recommandation de la CNIL	Analyse	Suggestion/Impact
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 une pseudonymisation avant l'envoi de l'ID. Aucun impact.
Suppression des informations de référent externe (ou "referrer") depuis le site	La suppression complète du referrer est une proposition surprenante, alors que le fait de 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 inutile ou presque inutile) 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 tout paramètre contenu dans les URL 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 utm_campaigns.	Supprimer les paramètres d'URL au cas par cas s'ils contiennent des données personnellement identifiantes. Utm_campaigns peut être conservé s'il est correctement géré, 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 inutile, tandis que si notre recommandation est suivie, l'impact sera limité. 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 un 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 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'identifiant cross-site ou déterministe (CRM, ID unique)	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 hacher 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 initial client-side Gtag 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. Ceci se fait via le paramètre natif GA : transport_url (Exemple de code fourni ci-dessous). La méthode transport_url doit être défini sur votre URL de suivi. Votre domaine de suivi est soit :

• votre sous-domaine First party défini dans gestion de domaine Dans ce cas le transpor_url doit être défini sur : https://VOTRE_1ST_TRACKING_DOMAIN.com/cdp/events?tc_s=VOTREIDDEDOMAINE&token=VOTRECLEFDESOURCE&event_name=ga_session_start&ga_url_param=

• ou notre domaine de collecte third party collect.commander1.com Dans ce cas le transpor_url doit être défini sur : https://collect.commander1.com/events?tc_s=VOTREIDDEDOMAINE&token=VOTRECLEFDESOURCE&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 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 souhaitez appliquer. - Si nécessaire, hachez 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.