Un prix affiché dans une devise que le visiteur n'utilise pas exige un effort mental supplémentaire avant de signifier quoi que ce soit, et un éditeur de logiciels vendant un produit facturé à l'usage, avec un calculateur sur sa page de tarifs, a constaté que les visiteurs venant d'en dehors de son marché d'origine passaient nettement plus de temps sur la page du calculateur et convertissaient moins, une tendance qui, une fois que l'équipe s'y est penchée, s'expliquait précisément par cette friction supplémentaire.
La solution consistait à afficher le prix calculé dans une devise que le visiteur utilisait réellement au quotidien, à côté de la devise de base de l'éditeur pour ceux qui la préféraient. Pour savoir quelle devise afficher en premier, on partait du pays, déterminé côté serveur à partir de l'adresse IP du visiteur via /v1/ip, avant le rendu de la page du calculateur de prix. L'éditeur tenait à jour sa propre petite table de correspondance entre pays et devise d'affichage, ainsi qu'un taux de conversion approximatif actualisé périodiquement, et utilisait le champ country de la recherche pour choisir la devise affichée par défaut.
Il vaut la peine d'être précis sur ce que cela a changé et ce que cela n'a pas changé. My Geocode fixe ses propres prix et facture en EUR, dans le monde entier, quelle que soit la localisation d'un client qui utilise l'API, un détail sans rapport avec la devise qu'une entreprise construite sur l'API choisit d'afficher à ses propres clients. La décision de l'éditeur d'afficher les prix dans la devise locale du visiteur relevait entièrement de ses propres choix de tarification et de localisation, en utilisant le signal de pays issu de la recherche comme donnée d'entrée ; l'API de localisation n'a rien décidé et n'est intervenue que pour déterminer le pays.
L'éditeur a pris soin d'indiquer clairement que le prix converti était une conversion approximative donnée à titre indicatif, puisque la facturation réelle se faisait toujours dans sa propre devise de base et que les taux de change fluctuent : le montant affiché sur la page de tarifs était donc une estimation utile, et non une garantie ferme de ce que serait un prélèvement donné une fois la conversion effectuée par le prestataire de paiement. Cette distinction comptait assez pour être signalée directement sur la page, dans une petite note près du calculateur, afin d'éviter toute confusion chez les clients sur ce qui leur serait réellement facturé.
Un visiteur pouvait revenir à la devise de base d'un seul clic s'il le préférait, ce qui était utile aux équipes financières évaluant le produit, qui voulaient voir directement la devise de facturation réelle plutôt qu'une estimation convertie, et l'éditeur a laissé ce bouton bien en vue plutôt que d'enfouir l'option, car priver le visiteur de la possibilité de voir la vraie devise de facturation au profit d'un affichage localisé imposé aurait créé sa propre forme de friction, précisément pour les acheteurs les plus susceptibles de comparer soigneusement les budgets.
Le trafic de la page de tarifs représentait une part modeste des visites totales du site de l'éditeur, ce qui maintenait cette fonctionnalité confortablement dans le quota quotidien gratuit la plupart des mois, avec un dépassement occasionnel sur le crédit prépayé lors d'un lancement de produit ou d'une campagne marketing générant un trafic inhabituellement élevé sur la page de tarifs.
La documentation de la recherche sous-jacente se trouve sur /docs/ipv4-lookup/ et /docs/ipv6-lookup/, et les tarifs de My Geocode sont détaillés sur /pricing/.