Au fil des années, le nombre de déclencheurs intégrés nativement au sein des outils de gestion des balises Web n'a cessé de croître. Les leaders du marché proposent ainsi de suivre automatiquement les clics, l'envoi de formulaires, le scroll et parfois même la visibilité d'un élément. Aux abonnés absents pour l'heure : la possibilité de déclencher des codes de façon automatique en fonction de l'adresse IP d'un visiteur. Comment expliquer un tel manque ? Est-il possible de le dépasser via un paramétrage "personnalisé", comme cela était le cas par le passé pour d'autres méthodes de déclenchement devenues depuis lors "natives". Faut-il s'attendre à ce qu'une telle option de ciblage soit proposée à l'avenir de façon native ?
Les causes d'un manque
Récupérer l'adresse IP d'un utilisateur, via le seul recours au langage JavaScript est impossible. C'est pour cette raison que contrairement à d'autres déclencheurs, comme les écouteurs de clics, la récupération de l'adresse IP ne figure pas parmi les options natives offertes aux utilisateurs d'un conteneur. En effet, obtenir cette donnée nécessite qu'un script, exécuté côté serveur, renvoie au système de gestion des balises, situé côté client, les informations relatives à la localisation du visiteur.
Plusieurs modalités de mise en oeuvre
A date, conditionner le déclenchement de codes sur la base de l'emplacement d'un visiteur demeure parfaitement possible, mais nécessite des paramétrages et/ou développement spécifiques. Deux principales approches, chacune comportant des avantages et inconvénients peuvent être distinguées afin de répondre à ce besoin.
La première consiste à inclure l'adresse IP du visiteur et/ou d'autres informations liées à ses coordonnées géographiques, tels que le pays dans lequel il se trouve ou encore la ville depuis laquelle s'effectue la connexion, directement au sein de la couche de données définie par les équipes techniques préalablement à l'inclusion du conteneur. Cette méthode a pour avantage de permettre une exploitation immédiate des coordonnées de l'utilisateur, dès le chargement de la première page visitée. Cependant, elle nécessite un développement et expose au sein de la couche de données, de façon normalisée, des informations sensibles, potentiellement accessibles aux autres éditeurs dont les codes sont déployés via le système de gestion des balises.
Afin de répondre aux limites en terme de confidentialité, et d'agilité liées à la mise en oeuvre de cette première approche, les utilisateurs de systèmes de gestion des balises peuvent opter pour l'appel d'un script hébergé en propre ou d'un Web service spécialisé afin d'obtenir les informations désirées. Concrètement, l'appel d'une ressource conduit à obtenir en réponse l'adresse IP de l'utilisateur et/ou des données relatives à sa localisation découlant de son "décodage". Avec une telle méthode, il ne s'avère pas nécessaire de solliciter les équipes techniques pour rendre opérationnelle une mécanique de déclenchement basée sur l'emplacement du visiteur. Dans l'hypothèse ou le script serait hébergé en propre, le rôle du département informatique se limiterait tout au plus à ajouter un fichier sur un ftp, les codes en son sein pouvant avoir été rédigés directement par un utilisateur technique de l'outil de gestion des balises.
Malheureusement, une fois de plus, la méthode présente des lacunes. En effet, comme tout appel émis depuis un outil de gestion des balises, celui visant à récupérer l'adresse IP est effectué de façon asynchrone. Par conséquent, la récupération des coordonnées géographiques du visiteur peut intervenir bien après le chargement de l'ensemble des ressources déployées par le conteneur. Le ciblage par adresse IP ne devient donc pleinement opérationnel qu'à compter de la deuxième page visitée par l'utilisateur au cours de sa session, à condition que la valeur récupérée initialement ait été stockée. En outre, le déclenchement des balises peut être retardé, tant que la récupération de l'adresse IP n'aura pas été menée à bien. Un tel mécanisme présente pour principal inconvénient un retard de déclenchement des balises liées et par conséquent entraine une diminution du volume total de données collectées par leur intermédiaire.
En conclusion
Il n'existe pour l'heure aucune méthode exempte de défauts permettant de déclencher un code, déployé par un système de gestion des balises, sur la base de l'emplacement géographique d'un visiteur. Les éditeurs logiciels hébergeant en propre les conteneurs de leurs clients pourraient, en rendant dynamique une partie du code constituant le conteneur, inclure automatiquement cette information en son sein, afin de dépasser les limites des différentes approches actuelles. Cependant, une telle évolution est peu probable étant donné le caractère sensible des informations traitées et des surcoûts qu'induirait un tel système chez l'éditeur logiciel du fait de la puissance de calcul supplémentaire à mobiliser côté serveur.