Cobrar el mismo precio en todas partes ignora lo mucho que varían el poder adquisitivo y la competencia de un mercado a otro. Una empresa de software que vendía un producto por suscripción quería ponerle un precio más bajo en algunos mercados y mantenerlo en otros, una estrategia bastante habitual, pero hacerlo requería saber en qué mercado estaba realmente un visitante antes de que el precio llegara a mostrarse en la página.
Preguntarlo directamente fue la primera idea, y la equivocada. Un selector de país en una página de precios se interpreta como una invitación a buscar la opción más barata mintiendo sobre la ubicación, y añade una decisión a una página cuyo único cometido es llevar al visitante hasta el botón de pago con la menor fricción posible. La empresa quería que el precio correcto apareciera sin más.
La solución se ejecutaba en el servidor, antes de devolver la página de precios. /v1/ip tomaba la dirección IP del visitante y devolvía, entre otros, un campo de país, que la página de precios usaba para elegir qué tabla de precios mostrar. Un visitante de un mercado con el precio estándar veía el precio estándar. Un visitante de un mercado en el que la empresa había fijado una tarifa regional veía esa tarifa, sin selector, sin clic adicional y sin ninguna señal visible de que se hubiera detectado nada.
La empresa trataba el país detectado como un punto de partida y no como un hecho inamovible, ya que un visitante conectado a una VPN corporativa o de viaje en el extranjero podía quedar asignado a un mercado equivocado para los precios que realmente le correspondían. En lugar de bloquear a nadie, el proceso de pago permitía que soporte hiciera una excepción en el raro caso de que el país de facturación real de un cliente no coincidiera con lo que sugería la IP, gestionado como una excepción y no integrado en el flujo principal, ya que introducir una duda constante en la página de precios por un caso excepcional que afectaba a una pequeña fracción de los visitantes habría deshecho la sencillez que se buscaba con todo el cambio.
Hubo un detalle lo bastante importante como para señalárselo directamente al equipo de finanzas: My Geocode factura en EUR en todos los lugares donde opera, sin precios regionales propios más allá de la cuota gratuita estándar, el crédito prepago y la clave Unlimited. Esa es una cuestión distinta de si una empresa que usa la API quiere aplicar precios regionales a su propio producto, una decisión que depende por completo del negocio construido sobre ella. La consulta solo aporta la señal del país. Lo que una empresa hace con esa señal, y cómo fija sus precios en función de ella, sigue siendo decisión suya.
El volumen de solicitudes seguía a las visitas a la página de precios, normalmente una pequeña fracción del tráfico total del sitio, ya que la mayoría de los visitantes del sitio de una empresa de software no están consultando activamente el precio del producto en una visita concreta. Eso mantuvo el uso muy dentro de la cuota diaria gratuita durante la mayor parte del año, y solo pasó a crédito prepago en periodos de tráfico inusualmente alto en la página de precios, como en torno al lanzamiento de un producto.
Unos precios regionales bien hechos deberían ser invisibles como mecanismo y evidentes como resultado: el precio correcto, desde la primera carga, sin pasos adicionales. La documentación del endpoint está en /docs/ipv4-lookup/ y /docs/ipv6-lookup/, y los detalles de precios de la propia API están en /pricing/.