Header Ads Widget

Ticker

6/recent/ticker-posts

¿Qué es una API como producto?


API-as-a-Product es un concepto creciente en la esfera del desarrollo de software. Como tal, merece una mayor definición y aclaración. Entonces, ¿qué es API como producto? ¿De qué formas podemos monetizar este enfoque? ¿Y hacia dónde se dirige esta tendencia?

¿Qué es API como producto?

Una API como producto es un tipo de software como servicio que monetiza la funcionalidad de un nicho, generalmente servida a través de HTTP. Las empresas de tecnología con productos API a menudo adoptan un modelo freemium y utilizan estrategias como la limitación de tasas para habilitar niveles de suscripción.

Una API puede existir junto con una oferta principal o como un producto por derecho propio. Por ejemplo, si una empresa se desarrolla primero como un producto físico o una oferta de empresa a empresa (B2B), la API puede ser una extensión premium. Para un número creciente de nuevas empresas , la lógica API-empresarial es, en cambio, la oferta principal en sí misma.

Esta relación ha dado lugar a un nuevo paradigma de pensamiento y diseño de API: API como producto. Este modelo implica que una API es fundamental para la lógica empresarial, que impulsa la mayor parte del valor empresarial. Para API-as-a-Products, la API no es solo el modo de entrega; es el producto en sí.

API-as-a-Product es aproximadamente sinónimo de una oferta de software como servicio (SaaS) impulsada por API, en la que la API impulsa el SaaS en sí y la lógica empresarial que lo rodea. API-as-a-Product es la evolución natural del panorama B2B , pero en lugar de crear ofertas a medida para instancias específicas, API-as-a-Product básicamente dice: "Esto es lo que podemos hacer: la forma en que se integra depende de usted . "

Algunos buenos ejemplos de este tipo de oferta de productos son los siguientes:

  • Stripe : una plataforma de comercio electrónico y procesamiento de pagos, Stripe ofrece una API para facilitar las interacciones comerciales en línea. Esta API no es una tienda comercial en sí misma; no hay una "Tienda Stripe" donde pueda vender y comprar productos como Amazon. En cambio, Stripe habilita este comercio a través de ofertas de plataforma diseñadas para aliviar los gastos generales.
  • Twilio : Twilio es, en esencia, una plataforma de facilitación de comunicaciones. Diseñado para permitir que los agentes y los clientes se comuniquen en una amplia variedad de plataformas, Twilio no es en sí mismo una plataforma de chat, sino una plataforma de conexión. Este producto central ofrece beneficios de comunicación a las empresas que no desean crear sus propios canales y métodos de comunicación, pero que desean integrar canales probados en su infraestructura existente.
  • Mailchimp : Mailchimp es una solución de automatización de marketing que ofrece una solución productiva para los esfuerzos de marketing unificados en diferentes canales. Este es un excelente ejemplo de un producto que "nivela" los esfuerzos existentes al tiempo que abre nuevas vías para la creación; si bien pueden existir campañas de marketing en la entidad que utiliza Mailchimp, no obstante, ofrece una mejora lo suficientemente significativa en estos esfuerzos que es mejor considerarlo un producto distinto. .

Modelos de monetización y consumo de API como producto

La API como producto se puede monetizar de varias formas. Hemos hablado de esto antes , pero vale la pena repetirlo. La monetización depende en gran medida del tipo específico de oferta de producto API en cuestión; por ejemplo, los productos API técnicos pueden cobrar por integración o por una cierta cantidad de transferencia de datos, mientras que las API comerciales o de pago pueden cobrar como una parte de los ingresos o mediante modelos de suscripción. . El tipo y modelo de monetización son variables y, como tal, los desarrolladores de API tienen un rango relativamente libre para elegir el mejor modelo de monetización para su caso de uso específico.

Freemium / Monetización por niveles

Un modelo predominante en el espacio de las API es el freemium o la estrategia de monetización por niveles. En este modelo, los desarrolladores ofrecen funciones API básicas de forma gratuita con algún tipo de limitación. Las limitaciones pueden incluir pruebas gratuitas por tiempo limitado, una cierta cantidad de llamadas permitidas (similar a la limitación de velocidad) o incluso una opción completamente gratuita para usuarios no empresariales subsidiados por clientes empresariales.

En última instancia, este modelo se basa en el concepto de costo acelerado para uso acelerado. Se debe emplear una cierta cantidad de equilibrio en este modelo para garantizar que lo que se proporciona en la oferta gratuita no reduzca la demanda de la oferta premium, al tiempo que se garantiza que realmente valga la pena interactuar con la opción gratuita.

Modelo de costo a granel

Este modelo tiene varios nombres dependiendo de cómo se generen los ingresos del proceso de costos masivos. Pay as you Go es un modelo de costo masivo en el que la cantidad de llamadas a la API realizadas tiene un costo asociado que luego se transfiere a la entidad solicitante. Este costo puede ser para llamadas individuales (generalmente se les asigna un costo adicional) o llamadas masivas (generalmente con un descuento relacionado con el costo de la llamada individual). Por ejemplo, un modelo de monetización de costos masivos podría decir "cada llamada cuesta 99 centavos" y "1000 llamadas cuestan 500 dólares".

Si bien este modelo permite al cliente controlar sus costos de manera muy granular, también puede ocultar el costo final si el cliente no presta suficiente atención o no modela sus costos con precisión. Esto se puede mitigar parcialmente mediante técnicas de modelado adecuadas o estimaciones del proveedor, así como aclaraciones sobre cómo se monetiza cada llamada (por ejemplo, si las repeticiones son parte de la API, ¿esto cuenta como una nueva llamada o una repetición de una llamada ya pagada?).

Modelos de suscripción

Un modelo de suscripción es una versión con límite de costo del modelo Pay as you Go y, por lo general, tiene un período de tiempo en el que la suscripción está activa (por ejemplo, las suscripciones pueden ser semanales, mensuales o anuales). Estos modelos a menudo tienen un nivel de uso de nivel superior (por ejemplo, 100 dólares por semana y hasta 1,000 llamadas) y, por lo general, también ofrecen costos con descuento para cualquier excedente fuera del nivel de suscripción.

Costeo unitario

Este modelo utiliza unidades definidas discretamente para cobrar la utilización. Un proveedor de API puede cobrar por unidad de uso de infraestructura (p. Ej., Cantidad de GB utilizados, cantidad de ciclos de procesador discretos empleados, etc., algo común en soluciones como AWS), pero también puede cobrar por "unidad" de proceso (generalmente llamada "Instancia"), por ejemplo, "5 instancias de Docker" o "3 usuarios de la API".

Existe una versión de este modelo de costo unitario llamado modelo "por asiento" en el que cada usuario tiene un número máximo establecido de llamadas que puede emplear y un período de acceso limitado en el tiempo; en esencia, usted está comprando un asiento en la mesa. por la solución.

Participación en los ingresos

En este modelo, los proveedores de API reclaman una parte de los ingresos generados por el uso de la API. En un sentido de producto, esto es similar a algo así como los sistemas de publicidad de Google, en los que un sitio puede integrar anuncios que pueden reclamar un cierto porcentaje de los ingresos, pero no los ingresos en su totalidad.

Para algo como una aplicación de comercio, esto puede venir como un cargo premium además del costo o producto base del artículo. La integración de una solución de comercio electrónico puede significar que cada producto vendido por 10 dólares da como resultado 10 centavos en ingresos compartidos con la empresa API, lo que, a escala, puede sumar significativamente, incluso si no hay un "costo directo" para la empresa que implementa la API . En realidad, esta puede ser una implementación significativamente mejor para muchas empresas, ya que el costo pagado es parte de los ingresos generados, lo que elimina principalmente el "costo inactivo", donde se paga por una suscripción que no genera ningún valor.

El futuro de las API como producto

A medida que la web se ha movido hacia el paradigma de microservicios , los pensamientos sobre el desarrollo de API se han alejado de la creación de una solución única y general para todos los casos de uso para desarrollar marcos extensibles que permitan la creación de soluciones. La idea es simple: ¿por qué intentar resolver todos los casos de uso cuando puede crear un conjunto de herramientas de bajo nivel para que el propietario del problema cree su propia solución? El resultado final suele estar más adaptado al resultado deseado.

Con este movimiento hacia soluciones marco, la idea de un negocio centrado en API se ha vuelto cada vez más crítica como lógica empresarial central. API se crean para el consumo masivo, y como tal, el nuevo patrón de pensamiento paradigma ha cambiado de “qué problema no resuelve que esto” hacia “qué problemas puede este marco permitirá soluciones para.”

Por supuesto, este movimiento ha generado mayores expectativas para los productos API . Las API ya no pueden proporcionar una función simple: requieren una excelente experiencia de desarrollador, seguridad y confiabilidad. Para una metáfora del mundo real, los principales fabricantes de automóviles del mundo no solo fabrican automóviles que van de A a B, sino que fabrican automóviles que lo hacen al tiempo que ofrecen características y cualidades de primera línea que los hacen más atractivos. . Lo mismo ocurre con las API como productos.

Publicar un comentario

0 Comentarios