X

#GTMTips : Obtenez une véritable anonymisation IP avec le balisage côté serveur


Depuis la sortie du balisage côté serveur dans Google Tag Manager, j’ai sauté sur chaque occasion pour célébrer les outils qu’il fournit pour améliorer la confidentialité des utilisateurs finaux et la sécurité des données.

L’un des principaux avantages est l’obscurcissement par défaut. Étant donné que tous les appels sont transmis via le proxy côté serveur, la vue par défaut pour tout outil tiers (tel que Google Analytics) est celle du serveur dans Google Cloud plutôt que le navigateur et l’appareil avec lesquels l’utilisateur naviguait sur le site. .

En d’autres termes, en utilisant le conteneur Serveur comme proxy, vous “masquez” l’utilisateur réel, car tous les hits semblent provenir de la machine virtuelle plutôt que du navigateur de l’utilisateur.

Cependant, le Analytique universelle balise dans le conteneur du serveur copies l’adresse IP et l’agent utilisateur de l’utilisateur dans la demande de protocole de mesure sortante à l’aide de &uip et &ua paramètres. Cela signifie que même si la requête HTTP sortante vers Google Analytics provient de la machine virtuelle dans Google Cloud, la charge utile des données Google Analytics est mise à jour pour référencer l’appareil et l’adresse IP réels de l’utilisateur.

Dans cet article, je vais vous montrer comment remplacer ce comportement et prévenir Universal Analytics de faire cette opération de copier-coller.

Merci à Adam Halbardier de l’équipe Google travaillant sur le balisage côté serveur pour cette astuce !


X


La newsletter Mijoter

Abonnez-vous à la newsletter Simmer pour recevoir les dernières nouvelles et le contenu de Simo Ahava dans votre boîte de réception !

C’est très facile à réaliser. Dans la balise Universal Analytics qui se déclenche dans le conteneur Server, vous devez effectuer les opérations suivantes.

Tout d’abord, vérifiez Activer les paramètres de remplacement dans cette balise. Cela vous permet de définir des champs individuels dans la balise qui remplacent ceux définis par le client.

Ensuite, développez Remplacer les champs à définiret ajoutez les deux champs suivants sans aucune valeur (laissez les champs de valeur vides).

user_agent
ip_override

NOTE! Ces champs sont pas identiques aux champs analytics.js. Ce sont des champs établis dans le modèle d’événement utilisé dans le balisage côté serveur. Il manque encore une documentation exhaustive sur les champs disponibles, mais creuser dans le mode débogage dans le conteneur du serveur et explorer l’onglet Données d’événement vous mènera loin.

En définissant les champs vides, vous empêchez essentiellement la balise de définir ces champs avec les valeurs de la requête entrante, c’est-à-dire le navigateur et l’appareil réels de l’utilisateur.

Cela suffit pour empêcher le remplacement, et vous pouvez garantir que l’adresse IP de l’utilisateur réel et la chaîne de l’agent utilisateur ne sont pas transmises à Google Analytics sous quelque forme ou taille que ce soit.

Mais qu’en est-il si vous voulez variable comportement. Empêcher le remplacement dans certains cas, mais l’autoriser dans d’autres ?

Eh bien, pendant que nous attendons un Tableau de recherche type de variable à ajouter au conteneur Serveur, il n’y a aucun moyen de définir des valeurs de variable pour ces champs en fonction, par exemple, de l’existence du &aip (Anonymiser IP).

Alors si tu voulais permettre le transfert IP et User Agent sauf lorsque les données d’événement ont anonymize_ip mis à true (c’est ce que &aip paramètre est transformé en dans l’objet événement), vous auriez besoin deux Mots clés.

L’un envoie les données à Google Analytics sans les remplacements (c’est-à-dire le comportement par défaut de la balise Universal Analytics sans aucun paramètre remplacé) et se déclenche lorsqu’un Données d’événement variable définie pour la clé anonymize_ip est pas true.

L’autre balise envoie les données à Google Analytics en suivant les instructions de cet article. Il doit avoir le ip_override et user_agent champs définis sur des valeurs vides. Le déclencheur est l’inverse de celui de l’autre balise, vous devez donc vérifier si anonymize_ip est en fait true.

Oui, une variable de table de consultation rendrait cela beaucoup plus fluide car vous n’auriez besoin que d’une balise et d’un déclencheur et définissez la valeur de ip_override et user_agent vider ou valeurs par défaut selon que l’adresse IP doit être anonymisée ou non.

J’espère que vous trouverez cette astuce utile. À tout le moins, cela devrait renforcer l’idée que le balisage côté serveur de Google Tag Manager peut être utilisé pour améliorer les perspectives d’anonymisation des utilisateurs et d’obscurcissement des données personnelles.