Le problème des clés d'API qui n'expirent jamais
Une clé émise il y a des années, jamais renouvelée et toujours valide aujourd'hui n'est pas une commodité. C'est un risque que personne n'a vraiment examiné depuis des années.
Ce que la facturation par produit comprend mal à l'usage réel des API
Ouvrez le journal des requêtes de presque n'importe quelle application qui utilise des données de localisation et vous n'y trouverez pas un seul type de recherche fonctionnant isolément. Un formulaire d'inscription géocode une adresse, vérifie l'IP pour obtenir une correspondance réseau approximative et associe un fuseau horaire à l'enregistrement, le tout en quelques centaines de millisecondes. Ce ne sont pas trois cas d'usage distincts qui partagent par hasard un fournisseur d'API. C'est un seul flux de travail qui touche trois types de données.
La facturation par produit prétend le contraire. Elle facture le géocodage selon une grille, les recherches d'IP selon une autre, et les données de fuseau horaire ou d'altitude comme des options avec leurs propres frais, comme si une entreprise qui a besoin de l'un de ces services avait peu de chances d'avoir besoin des autres. En pratique, c'est l'inverse : avoir besoin de l'un est généralement le signe que vous en avez besoin d'au moins un autre. Un parcours de paiement e-commerce qui géocode une adresse de livraison veut très probablement aussi savoir dans quel fuseau horaire planifier un créneau de livraison. Une vérification anti-fraude qui examine une adresse IP veut généralement la recouper avec une adresse enregistrée.
Nous avons conçu la tarification de My Geocode comme un seul produit avec un seul tarif. Chaque endpoint, géocodage, recherche d'IP, fuseau horaire, altitude, code postal, ainsi que chaque hôte de compatibilité, coûte exactement le même prix par requête. Il n'y a pas de grille tarifaire distincte à rapprocher, ni d'offre qui ajoute les données de fuseau horaire seulement après que vous avez déjà payé une offre de géocodage. Une requête est une requête, quel que soit l'endpoint qu'elle atteint.
Ce n'est pas seulement un confort pour le client. Cela reflète la façon dont le travail sous-jacent se fait réellement. Une recherche sur un endpoint n'a pas un coût de traitement radicalement différent d'une recherche sur un autre, à l'échelle à laquelle fonctionnent la plupart des applications. Les séparer en produits distincts avec des prix distincts ne reflète pas une différence réelle dans le coût de réponse à la requête. Cela reflète le nombre de lignes distinctes qu'un fournisseur peut faire figurer sur une facture.
La facturation par produit rend aussi plus difficile l'analyse de votre propre usage. Si le géocodage est facturé d'une façon et les recherches d'IP d'une autre, estimer la facture du mois prochain implique de suivre deux compteurs selon deux structures tarifaires et d'espérer que la répartition des appels ne change pas d'une manière qui modifie le total de façon imprévisible. Un tarif unique et uniforme ramène cette estimation à un seul calcul : le nombre total de requêtes multiplié par un seul prix. Quiconque établit un budget pour son intégration peut faire ce calcul sur un coin de table.
La tarification par produit repose sur une hypothèse plus profonde que nous jugeons tout simplement fausse : que différents types de données de localisation servent différents clients. D'après notre expérience, ils servent le même client, à différents moments de la même requête. Une plateforme logistique, un parcours d'inscription et un système anti-fraude assemblent tous des données de géocodage, d'IP et de fuseau horaire pour prendre une seule décision. Une tarification qui prétend qu'il s'agit de marchés distincts oblige les clients soit à payer trop cher un bouquet qu'ils utilisent de façon inégale, soit à jongler avec plusieurs fournisseurs pour l'éviter. Un seul tarif, une seule liste d'endpoints : c'est la réponse la plus simple et la plus honnête.