Header Ads Widget

Ticker

6/recent/ticker-posts

Operación de una API del mundo real, de cero a 3 millones de llamadas

 Contribución de un invitado que cubre un impresionante viaje API automotriz. Siga el auge de la API de registro de automóviles de nicho  f pivote mercado rom, al precio de ajuste, a la ampliación de las ventas a nivel internacional.

Es inusual que una API se convierta en la principal fuente de ingresos de una empresa. A menudo, una API se desarrolla como una ocurrencia tardía, generalmente por una de dos razones principales;

  • Para ayudar a facilitar las ventas de productos y servicios de terceros afiliados o revendedores al facilitarles el acceso a los datos de productos o servicios, o administrar de forma remota los servicios que usted brinda.
  • Fomentar un ecosistema de servicios de valor agregado por parte de terceros, para aumentar sus ofertas y brindar más valor a los clientes finales.

En ambos casos, el producto o servicio es preexistente, y la API 'abre' los datos correspondientes a esas ofertas a terceros para fomentar más ventas indirectas.

Pero, en casos excepcionales, una API puede cobrar vida propia, lo que hace que el servicio subyacente sea mucho más atractivo para las personas adecuadas que se vuelve mucho más valioso que el servicio original. Esta es la historia de fondo de una de esas API.

Día cero.

En 2015, al reservar una prueba de vehículo de rutina, apareció una característica pequeña pero interesante en el formulario de reserva de un sitio web. Al ingresar la matrícula de un automóvil, los detalles del automóvil aparecerían en la página siguiente. Esto habría sido de poco interés para la mayoría de los usuarios del sitio web, pero para nosotros, fue la génesis de un negocio de API muy exitoso .

En ese momento, las aplicaciones móviles parecían ser la respuesta a todo. Los desarrolladores se estaban enriqueciendo con “ Flappy bird ” e “ iFart ” y parecía que con un mínimo esfuerzo cualquiera podía hacer una fortuna en la tienda de aplicaciones. Por lo tanto, desarrollamos una aplicación que permitía a las personas ingresar números de registro de automóviles en el Reino Unido y ver los detalles del automóvil una vez que se recuperaron de DVLA o DVLNI (agencias gubernamentales en el Reino Unido que administran estos datos).

La aplicación fue un fracaso lamentable. Era de tan poca utilidad para un comprador de automóvil personal que solo un puñado de personas lo compró. Muchos se sintieron decepcionados y las ventas colapsaron. Los únicos usuarios habituales eran un puñado de talleres y vendedores de coches que trataban con muchos vehículos diferentes de forma regular.

Entonces se hizo evidente que el mercado de este servicio no era B2C, sino B2B . Solo las empresas que se ocupan de cientos o miles de vehículos necesitarían este servicio. La opción entonces era elegir una vertical específica y desarrollar software para ese tipo específico de negocio, o desarrollar una API que sería integrada por terceros en un software que cumpliera con los requisitos de esas verticales; se eligió la última opción.

El propio móvil se ejecutó con una API, aunque privada. Para hacerlo público, necesitaba tener un mecanismo de autenticación , un sistema de crédito, documentación y ejemplos de código . También necesitaba un portal de desarrolladores para anunciar su disponibilidad. Inicialmente, ni siquiera existía un sistema de pago; se manejó manualmente actualizando los créditos en una base de datos.

Relacionado: 5 consejos para comenzar su viaje de API pública

Selección del modelo de precios.

Después de que se creó la API, se incluyó en algunos sitios web, sobre todo ProgrammableWeb , y en algunas respuestas de elección en StackOverflow . Esto proporcionó prácticamente todos los visitantes necesarios para comenzar. Tuvo un comienzo lento, con solo una o dos empresas que lo aceptaron, y quedó claro que el modelo de precios era incorrecto. Casi todos los clientes potenciales se quejaron del precio y la aceptación fue demasiado lenta.

Por lo tanto, se redujeron los precios y la cantidad de clientes aumentó drásticamente. Fijar el precio de una API es una tarea difícil, ya que a menudo el costo subyacente es muy bajo. Sin embargo, en los negocios no es prudente ponerse un precio justo por encima del precio de costo. A menos que la competencia sea extremadamente alta y usted esté vendiendo un producto básico, es mejor fijar el precio a un nivel justo por debajo del nivel en el que el cliente dejaría de obtener una ganancia significativa con la venta superior.

Imagina que estás suministrando silicio a Intel. No valoraría su producto justo por encima del precio de la arena, sino a un nivel por debajo del precio de reventa de los procesadores de computadora Intel.

Muchas API, como las API de redes sociales , se ofrecen de forma gratuita ya que ayudan en la venta de un producto o servicio proporcionado por el desarrollador de API. Sin embargo, los servicios de API de procesamiento empresarial deben tener un precio de acuerdo con el valor que brindan a los consumidores.

Con el precio ajustado en consecuencia y una estructura de descuento por volumen para alentar a los peces más grandes, la API comenzó a despegar, al menos en el Reino Unido. Varias empresas empezaron a utilizarlo y empezaron a llegar pagos.

Pero como ocurre con todo lo que hay en Internet, el costo de exportación es cercano a cero y las oportunidades de mercado son enormes. El costo de oportunidad de no mirar más allá de sus propias fronteras nacionales es enorme.

Más sobre modelos de precios: la guía definitiva para fijar el precio de su API

Ampliar.

Entonces, el siguiente paso fue buscar en el extranjero para ver qué otros gobiernos ofrecían datos de registro de automóviles disponibles para el público a través de una iniciativa de datos abiertos . Descubrimos que los países nórdicos (Finlandia, Suecia, Noruega y Dinamarca) ofrecían estos datos con bastante facilidad y, a través de un cierto nivel de burocracia, fue posible expandir la API de una sola vez para cubrir millones de nuevos clientes potenciales.

Con los datos agregados vino la localización requerida , que en la práctica significó tanto traducción como soporte para múltiples monedas , como NOK, SEK, DKK y EUR. Para la segmentación geográfica, se crearon varias páginas de destino para cada país específico (ver Finlandia , Dinamarca , Noruega , Suecia ). Esto resultó ser una gran ganancia de marketing, ya que dio un impulso al SEO y enfocó el mensaje mucho más en el cliente individual, lo que agilizó en gran medida el proceso de incorporación .

Otra ganancia rápida incluyó la automatización del proceso de pago  para que las personas pudieran pagar sin tener que intercambiar correos electrónicos primero. Una cuenta freemium fue un gran beneficio; el pequeño costo de ofrecer un pequeño acceso de forma gratuita se vio superado en gran medida por el aumento de la confianza y el proceso de incorporación más rápido.

Ofrecer una prueba gratuita demostró ser muy importante como estrategia de marketing, especialmente porque personas de varios puestos de trabajo a menudo participan en el proceso de validación de API. El probador de API tendía a ser un desarrollador que, aunque era técnicamente capaz, no tenía medios ni deseos de pagar. Sin embargo, el evaluador necesitaba dar el visto bueno antes de que el gerente sacara la tarjeta de crédito de la empresa.

Proporcionar herramientas de generación de informes , como gráficos , informes descargables y advertencias de saldo bajo, ayudó a mantener contentos a los clientes existentes y redujo la carga de trabajo diaria de responder preguntas para los clientes que podrían manejarse a través del autoservicio. Aunque estas herramientas no conducen a nuevos clientes, mantienen ventas recurrentes y reducen los costos laborales.

Una vez que una base de clientes establecida comenzó a usar la API con regularidad, quedó cada vez más claro que el problema más importante era la confiabilidad . Cualquier interrupción en la API resultó en la pérdida de clientes para ellos y, en casos extremos, en una falla del sitio web. Por lo tanto, se emplearon recursos para configurar pruebas de rutina para garantizar que la API estuviera operativa constantemente.

Estas pruebas eran efectivamente un simple conjunto de ejecutables como una tarea programada en el servidor que se ejecutaba todas las noches, y enviaban a los desarrolladores por correo electrónico el resultado de todas las pruebas. Se realizaron más pruebas básicas cada hora, lo que garantizaba que se pudieran detectar averías graves en una hora y que se pudieran detectar problemas menos graves en un día. La mayor confiabilidad llevó a una mayor satisfacción del cliente y aumentos en sus niveles de uso.

A medida que el negocio se expandió a más países, específicamente a EE. UU., La carga en la API y en el servidor se convirtió en un problema importante, ya que un solo servidor dedicado comenzó a degradar el rendimiento a medida que aumentaban los accesos a la API. Normalmente, en este punto, la mayoría de los desarrolladores recomendarían soluciones de computación en la nube , sin embargo, dado que la carga aumentaba gradualmente, en lugar de aumentar, era posible descargar gradualmente ciertas funciones auxiliares fuera del servidor principal y en servidores secundarios más baratos.

Últimas palabras de consejo.

Muchos desarrolladores de API se ponen al día con la implementación de la API, el formato JSON , la pila de tecnología y la escalabilidad antes de que el primer cliente lo haya probado. La mayoría de los desarrolladores pueden manejar cualquier cosa que les arroje , ya sea XML, JSON o YAML, y las extrañas peculiaridades se perdonan rápidamente. La seguridad es una gran preocupación, por lo que el alojamiento en HTTPS es imprescindible y ofrecer un bloqueo por IP es realmente útil. Pero, lo más importante es que estas funciones se pueden agregar cuando se soliciten, y no necesariamente se cargan al frente como un requisito previo para el lanzamiento.

El control de versiones no fue algo que se consideró en el diseño inicial de la API, por lo que a medida que se encuentran disponibles nuevos datos o se hace evidente una forma más inteligente de representar los datos, no es tan fácil de cambiar. Una API activa puede tener cientos de aplicaciones cliente desarrolladas por sus clientes que dependen de una estructura formal fija del formato de respuesta de su API. Un pequeño cambio, quizás insignificante para usted, puede romper la aplicación de un cliente. Las API más establecidas, como Facebook, Twitter , Stripe, etc., usan un número de versión en la URL para administrar esto y un período de expiración muy público para las versiones anteriores.

Esta API en particular fue desarrollada usando C # .NET en un servidor Windows con una base de datos de servidor SQL. Durante meses, el código se refactorizó gradualmente y se ordenó en una estructura modular y lógica. Esto facilita un mantenimiento más fácil y rápido, lo que reduce el tiempo de inactividad. Sin embargo, la refactorización es normalmente la prioridad más baja de todas las tareas.

Tal como está el negocio en el momento de redactar este artículo, más de 3.000 clientes en todo el mundo están utilizando la API de registro de automóviles , manejando más de 3 millones de consultas , y ha despertado el interés de empresas como Uber, Tesla, IBM, Bosch y muchos más.

Publicar un comentario

0 Comentarios