Chaque champ supplémentaire sur une page de paiement coûte à un commerçant un certain pourcentage d'acheteurs qui abandonnent leur panier plutôt que de le remplir. Un sélecteur de pays est un petit champ, mais c'est une décision de plus exactement au moment de l'achat où l'acheteur est le plus susceptible de partir, et un e-commerçant qui vend dans une douzaine de pays a décidé de le supprimer complètement.
Il l'a remplacé par une recherche côté serveur exécutée avant l'affichage de la page de paiement. /v1/ip prend l'adresse IP du visiteur et renvoie le pays, la région, la ville, le code postal et les coordonnées, le tout lu à partir de la requête qui amène déjà l'acheteur sur le site. Le commerçant utilisait le champ du pays pour présélectionner le pays de livraison, ajuster les moyens de paiement proposés et changer la langue affichée lorsque plusieurs langues étaient disponibles pour ce marché. Un acheteur venant d'un pays où la boutique ne livrait pas voyait immédiatement un message à ce sujet, au lieu de remplir tout un formulaire pour se retrouver bloqué à l'étape du paiement.
Rien de tout cela n'enfermait l'acheteur. Le pays présélectionné restait modifiable, car la géolocalisation IP reflète le réseau d'où provient une requête et pas toujours l'adresse de facturation qu'une personne souhaite utiliser, notamment pour quelqu'un en voyage ou sur un réseau d'entreprise qui fait transiter le trafic par un autre pays. Traiter le pays détecté comme une valeur par défaut raisonnable plutôt que comme un fait évitait la frustration d'une page de paiement qui refuse de croire où le client habite réellement.
Le commerçant a ajouté la tarification par-dessus cette même détection. Certains marchés bénéficiaient de prix ajustés au pouvoir d'achat local et aux frais de livraison, décidés à l'avance par l'équipe merchandising et simplement appliqués selon le pays renvoyé par la recherche. Il s'agit d'une décision commerciale que la boutique prend avec son propre moteur de tarification, et non de quelque chose que l'appel de géolocalisation décide de lui-même, mais elle avait besoin d'un signal de pays fiable pour fonctionner. Le lire côté serveur garantissait que le prix affiché à l'acheteur correspondait au prix réellement facturé au paiement, contrairement à un script côté client qui pourrait être manipulé ou tout simplement ne pas se charger.
Comme la recherche s'exécute une fois par session de paiement plutôt qu'à chaque page vue, le volume est resté modeste même pendant un mois de fortes ventes, et il est resté dans le quota gratuit quotidien inclus avec la clé du commerçant pendant la majeure partie de l'année. Lors d'un pic saisonnier, le compte est brièvement passé au crédit prépayé à 0,0001 € par requête, un coût si faible qu'il n'a jamais mérité d'être discuté comme poste de dépense.
L'ensemble du changement a supprimé un champ d'un formulaire et l'a remplacé par une recherche que personne ne voit se produire. Les acheteurs ont seulement remarqué que le site semblait déjà savoir où ils se trouvaient, ce qui est tout l'objectif de ce type de personnalisation : elle doit donner l'impression de moins de friction, pas d'une nouvelle fonctionnalité. Le détail des champs et les formats disponibles sont documentés sur /docs/ipv4-lookup/ et /docs/ipv6-lookup/.
Un code postal et une ville qui ne correspondent pas sur un bon de commande ressemblent à une petite faute de frappe, jusqu'à ce qu'ils se transforment en une livraison envoyée à l'autre bout du pays.
Une entreprise de logistique voulait une simple alerte dès qu'un camion de livraison entrait sur le site d'un client donné ou en sortait, sans développer ni acheter la licence d'une plateforme complète de suivi de flotte.
Un outil de collaboration voulait que les membres d'une équipe voient d'un coup d'œil où se trouvait un collègue et à peu près quelle heure il était pour lui, sans que personne ait à le saisir dans son profil.