Licenciamiento basado en uso (medido) para software

Un fundador al que asesoré construyó una herramienta de procesamiento de documentos con IA y le puso precio de la forma obvia: 99 $ por puesto al mes. Entonces sus clientes se dividieron en dos bandos. Un bufete de abogados pasaba 40.000 documentos al mes por tres puestos y pensaba que la herramienta era la ganga del siglo. Una consultoría compró diez puestos, pasó 200 documentos y se fue porque “apenas la usamos”. El precio no tenía nada que ver con el valor entregado, así que era a la vez demasiado barato para el usuario intensivo y demasiado caro para el ligero. El arreglo no era un precio nuevo — era un modelo de precios nuevo: cobrar por documentos procesados, no por puestos poseídos.

Eso es el licenciamiento basado en uso. Este artículo cubre cómo funciona de verdad: créditos frente a facturación medida, cómo medir una unidad correctamente, bloques de créditos prepago, política de exceso y — la parte que la mayoría de las guías se saltan — reconciliar el uso en clientes que no siempre están en línea.

Idea clave: el licenciamiento basado en uso cobra por el consumo de una unidad bien definida en lugar de una tarifa plana. Alinea el coste con el valor, pero vive o muere por tres detalles: elegir una unidad inequívoca, contarla de forma idempotente e imponer el saldo fallando de forma segura. Los créditos prepago te dan efectivo por adelantado y al cliente un techo rígido; los bloques de créditos firmados permiten que incluso las máquinas sin conexión participen.

Dónde encaja la medición entre los modelos de licenciamiento

Los precios basados en uso no son un sustituto de la maquinaria de licenciamiento que ya conoces — son una dimensión que añades por encima de ella. Sigues emitiendo una licencia firmada, sigues controlando funciones con derechos y niveles (como en cómo licenciar tu software), y sigues bloqueando por equipo y contando puestos donde importa. La medición añade una cuarta cosa que la licencia lleva: un saldo consumible.

Piensa en los derechos como tres sabores que la licencia expresa a la vez:

• Indicadores de funciones — ¿está activado export? (IsEnabled("export"))
• Límites numéricos — ¿cuántos proyectos? (GetLimit("max-projects"))
• Créditos medidos — ¿cuántas unidades quedan, y qué pasa a cero?

Los dos primeros son estáticos durante la vida de la licencia; el tercero va descontando a medida que el cliente trabaja. Acertar con esa cuenta atrás es todo el juego.

Elegir la unidad — la decisión de la que todo depende

Antes de una línea de código, decide qué estás midiendo. Una buena unidad facturable es:

• Inequívoca — todos están de acuerdo en qué es “uno”. “Un documento procesado” es limpio; “una llamada a la API” necesita una definición (¿cuenta una llamada fallida? ¿un reintento?).
• Correlacionada con tu coste y el valor del cliente — quieres que el medidor avance a grandes rasgos cuando el cliente obtiene valor y cuando tú incurres en coste, para que los precios se mantengan sanos en ambos extremos.
• Contable en un único punto de estrangulamiento — un lugar en tu código donde la unidad se consume de forma inconfundible, para que la midas una vez y solo una.

Unidades comunes: llamadas a la API, elementos procesados (documentos, imágenes, transacciones), minutos renderizados/de cómputo, o incluso puestos activos medidos por día. Elige una unidad primaria. Medir tres cosas a la vez es una pesadilla de soporte de facturación y un problema de confianza del cliente.

Medir una unidad correctamente

Una vez elegida la unidad, la mecánica es: cuéntala en el punto de estrangulamiento, descuenta de la asignación e impón el cero.

// At the single point where a billable unit is consumed.
var draw = await license.MeterAsync(unit: "document", amount: 1, idempotencyKey: docId);

if (!draw.Allowed)
{
    // Balance exhausted — fail closed. Don't process, don't silently allow.
    ShowMessage(draw.Message); // e.g. "Credit balance exhausted. Top up to continue."
    return;
}

ProcessDocument(doc); // only runs when a unit was successfully metered

Tres cosas hacen que esto sea correcto en lugar de simplemente funcionar:

1. Idempotencia. Pasa una clave estable (aquí, el identificador del documento) para que un reintento de red no cobre la misma unidad dos veces. La doble facturación es la forma más rápida de perder la confianza de un cliente, y los reintentos son inevitables.
2. Fallar de forma segura. Cuando el saldo está vacío o el servidor es inalcanzable y no hay asignación en caché, el resultado seguro — no consumir — es el predeterminado. Un medidor que falla de forma abierta es un medidor que un atacante (o un error) convierte en uso gratuito rompiendo la llamada. Es la misma disciplina que gobierna toda comprobación de licencia; consulta la validación de licencias sin conexión explicada.
3. Medir después de imponer, antes de entregar. Descuenta de la asignación antes de entregar el valor, no después, para que un fallo a mitad de operación no pueda entregar una unidad que nunca cobraste.

Créditos prepago frente a facturación medida

Dos formas de convertir unidades medidas en dinero, con economías genuinamente distintas:

Bloques de créditos prepago. El cliente compra un bloque de unidades por adelantado — digamos 10.000 documentos. El consumo descuenta el saldo; a cero, el acceso se detiene o empieza el exceso. Esta es mi recomendación predeterminada para la mayoría de los proveedores, porque:

• Obtienes efectivo por adelantado en lugar de perseguir facturas.
• El cliente tiene un techo rígido y predecible — sin facturas de pesadilla a fin de mes.
• La imposición es sencilla: un saldo que descuentas y rechazas a cero.

Facturación medida (pospago). El uso se acumula durante un periodo y facturas el total al final. Menos fricción para empezar — sin decisión de compra antes del primer uso — pero conlleva riesgo de factura sorpresa: un cliente que multiplica por 10 su uso sin querer recibe una factura 10× y la disputa. Si vas a pospago, añade topes de gasto y alertas de uso por defecto, no como una petición de función.

Muchos productos los combinan: una cuota mensual de unidades incluidas (medidas, reiniciadas cada periodo) más bloques de créditos prepago para lo que supere eso. Eso da ingresos base predecibles y una vía de venta adicional limpia.

Exceso: decide antes de publicar

En el momento en que un cliente alcanza su límite, tu código tiene que hacer algo, y “no lo habíamos decidido” no es una opción — saldrá a la luz en el peor momento. Las políticas estándar:

• Parada en seco. A cero, rechaza más unidades. La más limpia y segura; el riesgo es interrumpir a un cliente a mitad de tarea, así que combínala con avisos de saldo bajo mucho antes de llegar a vacío.
• Facturación del exceso. Deja que el uso continúe más allá del límite y factura el exceso a una tarifa definida. Amable con el cliente, pero es exactamente aquí donde vive la factura sorpresa — ponle tope.
• Margen de gracia. Permite un pequeño exceso (digamos un 10 %) antes de imponer, para que a un cliente no lo detengan en seco por cruzar la línea por una unidad, y luego pídele que recargue.

Elijas lo que elijas, avisa pronto (“has usado el 80 % de tus créditos”) — una sorpresa es un ticket de soporte y una factura sorpresa es un contracargo.

Reconciliar el uso — incluso sin conexión

La medición parece exigir una conexión en vivo: ¿cómo descuentas de un saldo central desde una máquina que está sin conexión? La respuesta son los bloques de créditos firmados.

El servidor emite una asignación firmada criptográficamente — “esta licencia tiene 5.000 créditos de documento” — que el cliente verifica contra su clave pública incrustada, igual que una licencia firmada, y luego descuenta localmente sin ninguna llamada de red. El cliente mantiene un recuento continuo resistente a la manipulación, y la próxima vez que se reconecta reconcilia: informa de lo que consumió, el servidor ajusta el saldo y emite un bloque firmado nuevo. Una implementación aislada (air-gapped) o conectada de forma intermitente puede participar plenamente en los precios basados en uso de esta manera.

No es en tiempo real — una máquina sin conexión puede, en principio, sobrepasar un bloque obsoleto antes de reconciliar — así que dimensiona los bloques según tu tolerancia al riesgo y reconcilia tan a menudo como la conectividad lo permita. Pero significa que “basado en uso” y “sin conexión” no son mutuamente excluyentes, lo que para clientes de empresa y on-prem es a menudo la diferencia entre un acuerdo y ningún acuerdo.

Un límite honesto

La medición se ejecuta, en parte, en la máquina del cliente, así que — como cualquier comprobación del lado del cliente — un atacante decidido con un decompilador puede intentar parchear el medidor o falsificar un recuento. Esto lo reduces de la misma forma que proteges toda comprobación de licenciamiento: mantén el saldo autoritativo en un servidor que el atacante no controla, reconcilia los bloques firmados contra él y haz que el cliente sea difícil de parchear con ofuscación (más sobre eso aquí). La medición sin conexión es una extensión controlada de la confianza, no una garantía — trátala en consecuencia, especialmente para unidades de alto valor.

Hacer esto con Keyright

Keyright trata la medición como un derecho de primera clase junto con los puestos y los indicadores de funciones. Defines una unidad y un precio, vendes bloques de créditos prepago o cuotas mensuales con una política de exceso, y el SDK (.NET, Node, Python, Java) mide e impone el saldo — fallando de forma segura a cero. Para implementaciones desconectadas emite bloques de créditos firmados que miden plenamente sin conexión y reconcilian cuando la máquina se reconecta, de modo que los clientes aislados (air-gapped) y on-prem no quedan excluidos de los precios basados en uso. Es el mismo sistema que también gestiona tus pruebas, puestos y revocación, así que la medición no es un apaño de facturación añadido — es parte de la licencia.

El plan gratuito te permite modelar un producto medido y montarlo de principio a fin antes de pagar un céntimo — empieza gratis, o lee la documentación de Keyright para ver la superficie de medición exacta. Si los precios basados en uso son centrales para tu producto, el resumen de funciones repasa en profundidad los créditos, las cuotas y el exceso.