Bloquer le trafic interne avec Google Tag Manager

Vous avez probablement rencontré un certain nombre de guides ou de publications expliquant pourquoi il est nécessaire de bloquer les soi-disant trafic interne à partir de vos rapports d’analyse Web. Les raisons sont assez solides : le trafic interne n’imite pas le comportement normal des visiteurs, il contribue rarement aux conversions (ce qui fausse votre taux de conversion), il gonfle les pages vues et il fait des ravages sur vos données granulaires, page par page.

Le trafic interne est vaguement décrit comme « vos employés », « des personnes très proches de votre marque », « votre service marketing », « vos rédacteurs Web », etc. Fondamentalement, ce devrait être un terme qui couvre trafic qui ne représente pas de manière adéquate le comportement tendance des visiteurs sur votre site. Le plus souvent, c’est « interne », c’est-à-dire qu’il s’agit du trafic des personnes qui génèrent le contenu. Il peut également s’agir de vos relecteurs (épouses, maris, meilleurs amis), des bêta-testeurs (épouses, maris, meilleurs amis), des spécialistes du marketing de proximité (épouses, maris… vous comprenez ma dérive).

Dans cet article, je présenterai deux méthodes pour annoter ce type de trafic interne en utilisant (principalement) Google Tag Manager. Le principe sous-jacent est que votre trafic interne provient d’un nombre de sources si diversifié qu’il est impossible de le filtrer à l’aide des propres filtres de Google Analytics. Une autre possibilité est que vous ayez décidé d’anonymiser les données IP envoyées aux serveurs de Google Analytics, ce qui signifie que même si vous n’aviez qu’une certaine plage d’IP, vous ne pourriez pas utiliser les filtres de Google Analytics, puisque le dernier octet a été censuré (plus à ce sujet plus tard).

Au fait, j’utilise le terme annoter à la place de bloquer (sauf dans le titre convivial pour les moteurs de recherche, COUPABLE !), car si vous voulez ou non bloquer les données ou simplement les segmenter, c’est à vous de décider. Vous pouvez également suivre l’excellent guide de Bounteous pour empêcher les données d’être envoyées à Google Analytics en premier lieu, mais je voulais suivre une voie plus conciliante, vous offrant un moyen de continuer à intégrer le trafic interne dans vos rapports, si vous le souhaitez. choisir. Et cet itinéraire est, bien sûr, un dimension personnalisée.

La prémisse

Je présenterai deux méthodes : 1) Visite d’URL et 2) Extraction IP. Ils ont tous deux leur pour et contre.

Si les personnes que vous souhaitez inclure dans votre trafic interne sont constamment en déplacement, utilisent une variété d’appareils sur la route ou sont difficiles à identifier simplement en utilisant une plage d’adresses IP, vous devez utiliser la première méthode. De cette façon, vous laisserez également ces personnes à l’écart. Vous voyez, parfois vos employés sont aussi vos clients ou les visiteurs normaux du site, ce qui signifie que leur comportement doit être inclus dans vos rapports de trafic réels.

L’extraction IP nécessite que vous ayez à l’esprit des plages d’adresses IP spécifiques que vous souhaitez bloquer. C’est mieux pour le trafic qui provient de lieux fixes, comme les immeubles de bureaux ou les réseaux de bureaux.

Quel que soit votre choix, vous devrez configurer un dimension personnalisée d’abord, qui stockera vos données. C’est vraiment simple, et Google a un excellent guide sur la façon de commencer.

Si vous souhaitez fournir une sortie à votre trafic interne, vous devez créer un session-portée dimension personnalisée. De cette façon, le trafic interne est annoté séparément d’une session à l’autre.

Si, toutefois, vous souhaitez que l’annotation reste « à vie », vous devez créer un portée utilisateur dimension personnalisée (utilisateur est le même que appareil). De cette façon, l’annotation persistera d’une session à l’autre, même si l’extraction IP échoue ou si l’utilisateur ne visite pas votre URL de « trafic interne » désignée.

Méthode 1 : visite de l’URL

J’aime beaucoup cette méthode, car elle est entièrement côté client, elle ne nécessite aucune fonction personnalisée ni appel d’API externe pour récupérer l’adresse IP, et elle fournit une sortie à vos employés ou utilisateurs, s’ils souhaitent être traités comme externes Circulation.

Cependant, une chose qu’il faut, c’est que votre trafic interne se souvienne d’utiliser l’URL chaque fois qu’il visite votre site (à moins qu’il ne veuille pas être traité séparément). Étant donné que vous utilisez ici une dimension de portée de session, ce n’est pas grave si l’URL du trafic interne n’est pas la page de destination de la visite. Un hit de dimension personnalisée de portée de session est appliqué rétroactivement à tous les hits de la session, de sorte que tant que la dimension personnalisée est envoyée avec un seul hit pendant la session, il suffira d’annoter tous les hits de la session.

Je préfère utiliser un Paramètre de requête d’URL comme déclencheur qui marque le visiteur comme trafic interne. Cela signifie que:

1. Vous devez vous assurer que votre serveur accepte les paramètres de requête dans les adresses URL

2. Vous devez canoniser toutes les pages vers la version sans paramètre, afin que les moteurs de recherche n’indexent pas votre page de trafic interne par accident (utilisez <link rel="canonical" href="http://url-of-page-without-query-parameters"/>)

3. Vous devez configurer votre vue Google Analytics afin que ce paramètre de requête soit supprimé des rapports (car il n’ajoute aucune valeur au niveau du contenu)

Pour cet exemple, j’ai choisi la requête interne=vrai comme déclencheur. Donc, si vous accédez à la page d’accueil, vous devez utiliser http://www.mydomain.com/?internal=true être étiqueté comme trafic interne.

Voici comment utiliser le paramètre de requête comme dimension personnalisée dans vos balises.

1. Créez une nouvelle macro (Nom de la macro : URL interneType de macro : URLType de composant : Requete)

2. Sur le terrain Clé de requêteajouter interne

Lorsqu’elle est appelée, cette macro regarde votre URL, essaie de trouver le paramètre de requête “interne”, et si c’est le cas, elle renvoie sa valeur (“true”). Si aucun paramètre n’est trouvé, il renvoie un indéfini qui nous convient parfaitement.

Ensuite, vous devrez l’envoyer avec votre balise de vue de page.

1. Ouvrir la balise de suivi de votre page

2. Aller à Plus de réglages » Dimensions personnalisées

3. Ajoutez le numéro d’index de votre dimension personnalisée dans l’emplacement approprié

4. Ajouter {{URL interne}} dans le Dimension domaine

Et c’est ça! La beauté des macros Google Tag Manager est que vous n’avez pas besoin d’une balise de vue de page distincte pour les dimensions personnalisées non définies. Vous pouvez simplement utiliser cette macro. Si le paramètre de requête « interne » est trouvé, sa valeur (« true ») est envoyée en tant que dimension personnalisée avec votre accès à la page vue. Cependant, si aucun paramètre de ce type n’est trouvé, aucune dimension personnalisée n’est envoyéevous n’avez donc pas à vous soucier d’écraser vos données avec une dimension personnalisée vide ou autre.

Enfin, vérifiez avec un débogueur comme WASP que votre dimension personnalisée est bien envoyée.

Conseil de pro, utilisez une réécriture d’URL

Si vous ou les utilisateurs de votre trafic interne trouvez que l’utilisation d’un paramètre de requête d’URL est fastidieuse, vous devez configurer une redirection 301 côté serveur et utiliser une URL personnalisée ou un sous-domaine pour gérer la redirection. Donc si http://www.mydomain.com/?internal=true est tout simplement trop difficile à gérer, faites en sorte que http://www.mydomain.com/office ou alors office.mydomain.com rediriger l’utilisateur vers la page d’accueil avec le paramètre de requête en place (ou les deux !). Si vous avez un serveur Apache, vous pouvez essayer quelque chose comme ça pour la redirection du sous-domaine (vérifiez d’abord avec le service informatique !) :

RewriteEngine on RewriteCond %{HTTP_HOST} ^office\.mydomain\.com$ RewriteRule ^$ http://www.mydomain.com/?internal=true [R=301,L]

Méthode 2 : Extraction IP

Un moyen courant de séparer le trafic interne du trafic externe consiste à utiliser l’adresse IP du client. La méthode la plus courante consiste à utiliser les fonctionnalités standard de Google Analytics pour filtrer toutes les adresses IP qui se trouvent dans une plage spécifiée. Parce que c’est tellement “standard”, je n’entrerai pas dans les détails (vous pouvez lire les mots officiels ici).

Ce guide est pour annoter trafic interne, pas pour le filtrer, vous vérifierez donc l’adresse IP du client par rapport à une plage spécifiée, et s’il y a une correspondance, vous enverrez ces informations via une dimension personnalisée.

(Conseil de pro: Ceci est particulièrement utile si vous avez Anonymisation IP installer. Dans Google Analytics, l’anonymisation IP censure le dernier octet de l’IP du client (111.222.333.xxx) et le met à 0 (111.222.333.0). C’est ce qui est envoyé aux serveurs de Google Analytics, assurant un niveau de sécurité plus élevé, si vous ne voulez pas que les geeks de Mountain View regardent les adresses IP de vos visiteurs.)

Pour extraire l’adresse IP du client, vous avez plusieurs choix. La précision sera très variable, car si le visiteur utilise un proxy par exemple, ce n’est pas vraiment son IP qui est récupérée mais celle du proxy. Dans ce guide, je vais vous présenter une simple récupération de valeur PHP, et aussi comment récupérer l’IP avec JavaScript en utilisant un appel d’API externe.

Récupérer et traiter l’IP avec PHP

C’est une façon de le faire, et cela devrait fonctionner si vous avez un site qui est analysé avec PHP (WordPress, Drupal, etc.). Dans votre modèle de page, avant votre extrait de conteneur, vous créez l’objet dataLayer avec window.dataLayer = fenêtre.dataLayer || [];. Utilisez-le pour entrer l’adresse IP du client dans l’objet dataLayer lors de sa création. De cette façon, il sera prêt lorsque le conteneur sera configuré et que vos pages vues seront envoyées :

  window.dataLayer = window.dataLayer || [];   window.dataLayer.push({     "ipaddress": "<?php echo $IPADDRESS ?>"   }); 

Cela récupérera l’adresse IP à l’aide de la variable PHP désignée et la stockera dans la variable de couche de données. adresse IP.

C’est un excellent moyen d’extraire l’adresse IP, car vous n’avez pas à attendre qu’une API externe résolve l’adresse. Voici un guide plus complet sur la récupération de l’adresse IP avec un appel PHP.

Ensuite, créez une macro variable de couche de données à travers laquelle vous pouvez traiter l’IP :

1. Créer une nouvelle macro (Nom de la macro : Récupérer l’IPType de macro : Variable de couche de données)

2. Ensemble adresse IP comme nom de variable de la couche de données

3. Ensemble rien comme valeur par défaut

(Pourquoi la valeur par défaut, demandez-vous? Eh bien, j’aime traiter avec des entités déclarées, de sorte que je n’aurai pas à vérifier indéfini chaque fois que je veux traiter une variable.)

Ensuite, vous aurez besoin d’une balise HTML personnalisée dans laquelle vous traiterez l’adresse IP. L’objectif est de pousser une variable de couche de données “interne”: “true”, si l’IP correspond à une adresse ou à une plage donnée.

• Créer une nouvelle balise HTML personnalisée

• Ajoutez le code suivant dans :

<script>   var ipaddress = {{Retrieve IP}}; // Retrieves the IP from the data layer    // Comment following three lines if you want to use the IP range method   if (ipaddress == "111.222.333.444") {     dataLayer.push({"internal": "true"});   }    // To use the following IP range check, comment the previous three lines   // of code and uncomment the following lines   //   //  var ipRange = ipaddress.split(".");   //  var lastOctet = parseInt(ipRange.pop());   //  if(lastOctet >= 1 && lastOctet <= 100) {   //    dataLayer.push({"internal": "true"});   //  }      dataLayer.push({"event": "ipComplete"}); </script>

• Ajouter une règle de déclenchement au tag : {{event}} est égal à gtm.js

Vous avez deux choix dans le code ci-dessus. Soit vous effectuez une correspondance exacte (si votre bureau n’a qu’une seule adresse IP), soit vous comparez une plage. Dans le contrôle de plage, je vérifie si le dernier octet (111.222.333.xxx) est compris entre 1 et 100, n’oubliez donc pas de le modifier pour qu’il corresponde à la plage que vous souhaitez vérifier. Et si vous avez plusieurs adresses IP que vous souhaitez inclure dans la vérification, modifiez simplement la clause if à votre guise. Vous pouvez (et devriez) également utiliser la correspondance de modèles d’expression régulière, si les variations se diversifient.

Quoi que vous fassiez, cela devrait pousser la variable de couche de données “interne”: “true” si l’adresse IP correspond à un modèle donné. Enfin, vous poussez un événement déclencheur “ipComplete”, qui déclenchera votre balise de vue de page, avec laquelle la dimension personnalisée est également transmise.

La règle de tir ici est {{event}} est égal à gtm.js pour s’assurer que le code est exécuté le plus tôt possible, pour éviter de retarder l’appel de la vue de la page plus que nécessaire.

Récupérer et traiter l’IP avec JavaScript

Si vous ne pouvez pas utiliser PHP ou les scripts côté serveur, vous pouvez utiliser JavaScript. Eh bien, vous ne pouvez pas techniquement résolvez l’adresse IP du client en utilisant uniquement JavaScript. Vous devez demander l’IP à partir d’une ressource externe telle que Hostip.info ou GeoPlugin. Cela signifie que cette approche est un peu plus suspecte, car vous devez faire confiance au point de terminaison de la demande pour vous fournir les données correctes à chaque fois. Néanmoins, si vous ne pouvez pas récupérer l’IP côté serveur, c’est ce que vous devriez essayer.

J’utilise Hostip.info dans mon exemple, mais il existe un certain nombre d’API que vous pouvez utiliser. Je vous propose de trouver une API qui permette de récupérer les données avec une requête AJAX asynchrone (vous pouvez aussi utiliser un XMLHttpRequest), et qui renvoie les données sous la forme d’un objet JSON que vous pourrez ensuite parser. De cette façon, votre engin ne s’enflammera pas, emportant la majeure partie de votre site Web dans son carnaval de destruction, si le terminal choisit de changer la façon dont il distribue.

J’ai ajouté l’appel AJAX à la balise HTML personnalisée où je ferai également la correspondance des modèles.

REMARQUE! Ce script nécessite que vous ayez chargé jQuery avant que ce script ne soit exécuté. Assurez-vous donc que la bibliothèque est chargée en premier.

• Créer une nouvelle balise HTML personnalisée

• Ajoutez le code suivant dans le tag :

<script>   function matchIP(ipaddress) {     // Comment following three lines if you want to use the IP range method     if (ipaddress == "111.222.333.444") {       dataLayer.push({"internal": "true"});     }      // To use the following IP range check, comment the previous three lines     // of code and uncomment the following lines     //     //  var ipRange = ipaddress.split(".");     //  var lastOctet = parseInt(ipRange.pop());     //  if(lastOctet >= 1 && lastOctet <= 100) {     //    dataLayer.push({"internal": "true"});     //  }   }      var ipaddress = "";   try {     jQuery.ajax({       type : "GET",       dataType : "json",       url : "http://api.hostip.info/get_json.php",       async : true,       success : function(data) {         ipaddress = data.ip;             },error : function(errorData) {         ipaddress = "none";       },complete : function() {         matchIP(ipaddress);       }     });   } catch(e) {     console.log("Oops, something went wrong: " + e.message);   }   dataLayer.push({"event": "ipComplete"}); </script>

• Définir la règle de déclenchement pour la balise {{event}} est égal à gtm.js

Phew!

Dans cette balise, vous envoyez une requête HTTP POST asynchrone au point de terminaison sur hostip.info. La demande renvoie un script JSON, que vous analysez pour le nœud “ip”. La valeur stockée dans ce nœud est ensuite stockée dans la variable de couche de données adresse IP. Enfin, dès que la requête est terminée, vous appelez une fonction appelée matchIP()où l’analyse proprement dite a lieu.

L’analyse est identique à ce que nous avons fait dans le script de récupération IP PHP, vous pouvez donc évaluer une correspondance exacte ou une plage d’adresses IP. Avec de petites modifications, vous pouvez vérifier par rapport à plusieurs adresses et plages, si vous le souhaitez.

Encore une fois, le résultat final souhaité est une nouvelle variable de couche de données “interne”, qui devrait avoir la valeur “vrai”, si le trafic est interne. Il doit rester indéfini si le trafic n’est pas interne ou si une erreur survient dans votre requête AJAX.

Et encore une fois, il y a l’événement déclencheur “ipComplete”, qui est la règle de déclenchement pour votre vue de page, qui sera le vaisseau de votre dimension personnalisée.

La règle de déclenchement pour cette balise HTML personnalisée est {{event}} est égal à gtm.jscar vous voulez vous assurer que le script est exécuté le plus tôt possible pour éviter de retarder votre appel de vue de page plus que nécessaire.

Envoyer une dimension personnalisée avec la balise de vue de page

Et, enfin, nous sommes sur le point d’atteindre la fin de ce voyage ardu. Il est temps de modifier votre balise de vue de page, afin qu’elle inclue des informations sur le type de trafic dans une dimension personnalisée.

Tout d’abord, créez une macro variable de couche de données pour votre trafic interne.

• Nom de la macro : IP interne

• Type de macro : Variable de couche de données

• Nom de la variable de la couche de données : interne

Nous sommes maintenant prêts à modifier la balise de vue de page.

1. Ouvrez votre balise de vue de page

2. Aller à Plus de réglages » Dimensions personnalisées

3. Ajoutez une nouvelle dimension personnalisée et attribuez-lui le bon numéro d’index

4. Dans le Dimension slot, ajoutez votre nouvelle macro variable de couche de données ({{IP interne}})

5. Ajouter une règle de tir : {{event}} est égal à ipComplete

C’est ça! Votre balise de vue de page attend docilement la fin de la vérification IP. Une fois la vérification effectuée, si le trafic était interne, la valeur “true” est envoyée en tant que dimension personnalisée avec la balise de vue de page.

REMARQUE! Faire attendre votre balise de vue de page pour tous les scripts (en particulier les appels d’API externes) est un peu dangereux, car s’il y a un temps de chargement considérablement long, votre vue de page peut ne pas être envoyée du tout. Vous pouvez laisser votre balise de vue de page telle quelle et envoyer la dimension personnalisée avec un événement sans interaction à la place.

conclusion

Je n’avais pas l’intention que ce message soit un résumé de tous les guides d’exclusion du trafic interne sur le Web, donc je ne comprends pas pourquoi cela a fini par être un si long message.

Indépendamment de ma verbosité, j’espère que cet article a servi à mettre en évidence une partie de l’incroyable polyvalence de Google Tag Manager. La combinaison de macros, de balises et de dimensions personnalisées définies/indéfinies crée des possibilités de balisage vraiment complexes avec une configuration très simple.

Avec l’aide de cet article, vous pouvez désormais segmenter (ou filtrer) votre trafic interne dans Google Analytics en recherchant “vrai” dans votre dimension personnalisée Trafic interne.

Quels autres moyens avez-vous découverts pour identifier le trafic interne (avec ou sans GTM) ? J’aimerais ajouter une troisième méthode à ce tutoriel, même si cela sera vraiment être un guide gonflé.