La plupart des plateformes d'analytique répondent à la question « d'où viennent mes visiteurs » en chargeant un script dans le navigateur du visiteur et en remontant tout ce qu'il peut collecter. Un éditeur soucieux de garder des pages rapides et peu de scripts voulait la même réponse sans ajouter un morceau de code côté client de plus, qui devrait se charger, s'exécuter et remonter ses données avant que le chiffre n'apparaisse dans un tableau de bord.
L'alternative se trouvait déjà dans la requête que le serveur de l'éditeur traitait à chaque page vue : l'adresse IP du visiteur. Transmise à /v1/ip, cette adresse donne le pays, la région, la ville, le code postal, les coordonnées, le fuseau horaire, l'ASN et l'organisation, sans que le navigateur du visiteur ait quoi que ce soit à faire. Le serveur de l'éditeur enregistrait les champs pays et région à côté de chaque page vue qu'il consignait déjà, et la segmentation du trafic par pays est devenue un rapport généré à partir de données que le serveur possédait déjà, plutôt qu'une source de données à ajouter.
C'est une approche nettement différente d'un pixel ou d'une balise. Rien n'était envoyé depuis le navigateur du visiteur vers un tiers, et rien ne dépendait de la survie d'un script face à un bloqueur de publicités ou à un réglage de confidentialité qui écarte silencieusement les traceurs tiers, ce qui représente une part réelle et croissante du trafic sur la plupart des sites. La recherche s'exécutait entièrement côté serveur, au moment où la requête était déjà traitée, et le résultat était enregistré directement au lieu d'être extrapolé à partir de la fraction de navigateurs qui acceptaient de coopérer avec un script.
L'éditeur a utilisé les données par pays obtenues pour deux choses dès le départ. La rédaction pouvait voir, pour la première fois avec une réelle assurance, quels pays lisaient quelles rubriques, puisque le champ pays était associé à chaque page vue et non au seul sous-ensemble qu'un outil basé sur JavaScript parvenait à capter. La régie publicitaire pouvait présenter la portée géographique aux annonceurs à partir des mêmes chiffres que ceux consultés par la rédaction, au lieu d'entretenir deux systèmes d'analytique distincts et parfois contradictoires.
Rien de tout cela n'a exigé de stocker des données particulièrement sensibles. Le niveau de détail pays et région est grossier par nature, utile pour des rapports agrégés plutôt que pour identifier un visiteur individuel, et la politique de conservation de ces données suivait les mêmes règles que celles que l'éditeur appliquait déjà à ses journaux de serveur en général.
Le volume suivait directement les pages vues, ce qui, pour un éditeur d'une certaine taille, fera assez vite dépasser le quota gratuit quotidien et passer au crédit prépayé, à 0,0001 € la requête, ou fera d'une clé Unlimited à 50 € par mois l'option la plus simple une fois le volume élevé et prévisible. Dans les deux cas, le calcul était simple à faire face au coût d'une plateforme d'analytique tierce facturant la même ventilation par pays, souvent pour des données moins fiables en raison de tout ce qu'une approche par script laisse échapper.
Le changement le plus important était autant philosophique que technique : la localisation utilisée pour l'analytique n'a pas besoin de venir d'un élément exécuté dans le navigateur du visiteur. Elle peut venir du serveur qui traite déjà la requête, à partir de données que ce serveur voit déjà. La documentation de l'endpoint se trouve sur /docs/ipv4-lookup/ et /docs/ipv6-lookup/.