Los cobros y pagos basados en uso fallan en silencio.
No en el proceso de pago. No en la página de precios. No cuando se crea el plan.
Fallan cuando la actividad del producto y la actividad cobrable se desalinean.
Un evento se manda dos veces. El nombre de una métrica deja de coincidir con el modelo de cobros. Una cola reintenta sin idempotencia. Un desarrollador cree que está registrando "uso" cuando en realidad solo está capturando datos de analítica de producto.
Así es como los equipos terminan con sistemas de cobros y pagos en los que no confían.
En Commet, el registro de uso está construido alrededor de una regla más simple:
Registrá el evento de producto que debería generar consumo cobrable, y hacé ese mapeo explícito.
Los eventos de cobros no son eventos de analítica
Esta distinción importa más de lo que la mayoría de los equipos creen.
Los eventos de analítica responden preguntas como:
- ¿qué funcionalidad es popular?
- ¿dónde abandonan los usuarios?
- ¿qué tocó el usuario?
Los eventos de cobros responden una pregunta diferente:
¿Qué pasó que debería afectar lo que este cliente debe o consumió?
No son sistemas intercambiables.
Si tu lógica de cobros y pagos depende de flujos de eventos estilo analítica con nombres vagos y semántica inconsistente, vas a generar trabajo de reconciliación después.
El modelo de Commet: código de evento de funcionalidad -> evento de uso -> cobro
En Commet, cada funcionalidad medida tiene un código de evento.
Ese código es el contrato entre tu producto y tu modelo de cobros y pagos.
Ejemplos:
api_callsstorage_gbemails_sentcompute_minutes
Cuando tu aplicación registra uso contra ese código, Commet lo agrega para los cobros del período de suscripción.
Eso te da un camino directo desde la acción del producto hasta el uso cobrable sin inventar una segunda capa de traducción.
Registrá un solo evento cuando pasa la acción del producto
Si una acción de usuario mapea limpiamente a un evento cobrable, lo más simple suele ser lo correcto.
await commet.usage.track({
externalId: "user_123",
feature: "api_calls",
value: 1,
idempotencyKey: "req_abc123",
})Esta es la idea central:
- identificá al cliente
- identificá la funcionalidad cobrable
- mandá la cantidad consumida
- hacé que los reintentos sean seguros
Eso es suficiente para mantener el modelo de cobros explícito e inspeccionable.
Procesamiento por lotes cuando el volumen importa
Cuando el volumen sube, no querés que el registro de eventos se convierta en un cuello de botella.
Commet soporta el registro por lotes por la misma razón que los equipos de producto agrupan otras operaciones de escritura pesada: mejor eficiencia, menos sobrecarga, flujos de captura más simples.
await commet.usage.trackBatch({
events: [
{ externalId: "user_123", feature: "api_calls", value: 1 },
{ externalId: "user_456", feature: "api_calls", value: 3 },
{ externalId: "user_123", feature: "storage_gb", value: 0.5 },
],
})Si tu producto genera consumo en ráfagas, o estás sincronizando desde tareas internas en vez de solicitudes directas del usuario, el procesamiento por lotes suele ser la decisión operativa correcta.
La idempotencia no es opcional
Si te vas a acordar de una sola cosa sobre el registro de uso, que sea esta:
Los reintentos son normales. Los cobros duplicados no.
Las redes fallan. Los procesos reintentan. Las colas re-entregan. Las tareas en segundo plano se reanudan.
Sin idempotencia, cada uno de esos comportamientos normales del sistema puede convertirse en un defecto de cobros.
Por eso Commet soporta idempotencyKey en el registro de uso.
await commet.usage.track({
externalId: "user_123",
feature: "api_calls",
value: 1,
idempotencyKey: "job_7845_event_12",
})Esto te da una forma confiable de decirle al sistema de cobros y pagos: "Si este evento exacto ya llegó, no lo cuentes dos veces."
Esa es la diferencia entre un sistema que esperás que sea correcto y un sistema que podés operar con confianza.
Los nombres de eventos son diseño de producto
Nombres malos de eventos suelen indicar un diseño malo de cobros.
Estos son útiles:
api_callsstorage_gbemails_sentcompute_minutes
Estos no:
metricusagefeature1event_x
Los códigos de evento viven en el código y en tu modelo de cobros y pagos. Si son vagos, cada sistema que depende de ellos se vuelve más difícil de razonar.
Un buen nombre de evento hace dos cosas:
- hace la implementación más fácil para los desarrolladores
- hace que el modelo de cobros sea más fácil de auditar después
Un buen sistema de registro elimina trabajo de reconciliación
El objetivo del seguimiento de uso no es solo capturar datos.
Es evitar el costo operativo de preguntarte:
- ¿estamos registrando lo correcto?
- ¿lo registramos una sola vez?
- ¿el modelo de precios todavía coincide con el producto?
- ¿por qué la factura no coincide con lo que ve soporte?
Cuando el contrato de eventos es explícito, esas preguntas se vuelven más fáciles.
Por eso Commet mantiene el modelo acotado:
- las funcionalidades cobrables tienen códigos de evento
- tu aplicación reporta consumo contra esos códigos
- Commet agrega el uso para los cobros
Sin abstracciones falsas. Sin capas de traducción ocultas. Sin necesidad de reconstruir la lógica de cobros y pagos dentro de tu plataforma de analítica.
El estándar práctico
Si estás construyendo un producto basado en uso, tu configuración de registro debería cumplir un estándar simple:
- los eventos cobrables tienen nombres claros
- los reintentos son idempotentes
- el procesamiento por lotes existe cuando lo necesitás
- el mapeo de clientes es explícito
- el modelo de cobros coincide con el comportamiento del producto
Eso debería ser infraestructura normal, no arqueología de cobros y pagos hecha a medida.
Leé la documentación de Registro de Uso, revisá los Modelos de Consumo, explorá el plantilla de uso, o probá Commet en sandbox.