Cómo calcular el LTV ajustado por cómputo

• A medida que los productos de IA cobran la misma suscripción pero consumen costos de inferencia muy distintos según el cliente, se rompe el supuesto del LTV tradicional de que el margen bruto de toda la base de clientes es estable
• La clave es el LTV ajustado por cómputo, que mide la rentabilidad por cliente en productos de IA donde se combinan ingresos de suscripción fijos o semifijos con costos de cómputo muy variables
• Aunque dos clientes paguen el mismo precio, uno puede consumir $110 en costos de inferencia y otro $15, por lo que la estructura de margen bruto real es completamente distinta
• Si solo se observa el margen bruto promedio de la empresa, queda oculto que algunos segmentos apenas están en punto de equilibrio o incluso generan pérdidas, lo que crea la trampa del promedio
• Las empresas con ingresos fijos por suscripción de IA y costos de cómputo variables deben entender sí o sí el margen bruto por segmento para reducir errores en precios, pronósticos y expansión

---

El nuevo problema del LTV tradicional en software

• En el SaaS tradicional, la diferencia de costo de atender a un cliente similar adicional no suele ser grande, así que es posible aplicar directamente el margen bruto de suscripción al LTV
  • LTV básico = Cohort ARPA / Revenue Churn Rate
  • Versión con margen bruto = Cohort ARPA × Gross Margin / Revenue Churn Rate
• En los productos de IA, cada llamada de inferencia, completion, ejecución de workflow, tarea de agente o salida generada implica un costo directo y variable, y ese costo y volumen de uso cambian según el cliente
• Cita del informe State of AI de enero de 2026 de ICONIQ Capital
  • En empresas B2B de IA en etapa de expansión, la inferencia de modelos representa en promedio 23% de los ingresos brutos
  • Se proyecta que el margen bruto promedio de los productos de IA suba de 41% en 2024 a cerca de 52% en 2026, aunque todavía por debajo del SaaS tradicional

La misma suscripción, distinta economía por cliente

• En el ejemplo de un producto mensual de workflows de IA de $200, un power user (cliente A) consume $110 en costos de inferencia y un usuario liviano (cliente B) $15, pero en el LTV tradicional ambos se calculan igual
• Un alto uso no es malo por sí mismo; los heavy users suelen tener mayor stickiness, expandirse más rápido y convertirse en promotores del producto
  • Pero si el modelo de precios no recupera el costo de cómputo, el alto uso presiona o destruye silenciosamente el margen bruto
• Cita del análisis de abril de 2026 de Jellyfish (uso de tokens en el 1er trimestre de 2026 de 12,000 desarrolladores y 200 empresas)
  • El costo por cada PR fusionado va desde $0.28 en el tramo de menor uso hasta $89.32 en el de mayor uso, una brecha de 319x
• Usar el margen bruto promedio puede llevar a interpretaciones erróneas en productos de IA por suscripción: un segmento puede ser muy rentable y otro apenas estar en punto de equilibrio

Qué ingresos entran en la fórmula de LTV ajustado por cómputo

• Los ingresos de IA se dividen en tres categorías

  • Direct AI Revenue

    • El insumo más limpio: lo que se paga directamente por funciones de IA, como AI SKU, AI add-on, AI seat, licencias de usuario de IA, paquetes de uso de IA, bundles de créditos de IA e ingresos por sobreuso de IA

  • AI-Attributed Revenue

    • Si el plan estándar cuesta $200 y el plan con IA $275, la diferencia de $75 puede tratarse como ingreso atribuido a IA si la IA es la principal diferencia, aunque la metodología debe documentarse
    • Las empresas tecnológicas públicas ya hacen buen etiquetado de ingresos de IA, y eso es esencial en mercados públicos

  • AI-Influenced Revenue

    • Es una señal comercial de que la IA impulsó una renovación, cierre o expansión, pero si no se puede aislar su impacto en ingresos, no sirve como numerador de una fórmula de unit economics y debe rastrearse por separado
• Regla: usar Direct AI Revenue siempre que sea posible; usar AI-Attributed Revenue si es defendible; rastrear AI-Influenced Revenue por separado

Fórmula del LTV ajustado por cómputo

• Compute-Adjusted LTV = Compute-adjusted Gross Profit per Customer / Revenue Churn Rate
  • Compute-adjusted Gross Profit per Customer = AI Revenue per Customer − Fully Burdened AI COGS per Customer
  • Fully Burdened AI COGS = Inference Costs + AI Infrastructure Costs + Support Costs + Customer Success Costs + DevOps
• Los costos deben calcularse a nivel de margen bruto con carga fully burdened; simplemente restar costos de inferencia a los ingresos subestima los costos salvo que solo existan costos de LLM
• Customer Success solo debe incluirse en COGS cuando se enfoca en implementación y retención y no tiene cuota comercial

Ejemplo de LTV ajustado por cómputo: Acme SaaS

• Un producto mensual de workflows de IA de $200 se vende como suscripción, no como uso puro; los ingresos son fijos, pero el consumo de cómputo es variable

• Promedio de la empresa

  • Compute-adjusted Gross Profit = $200 − $55 − $11 − $12 − $8 = $114
  • Compute-Adjusted LTV = $114 / 2% = $5,700
  • LTV tradicional = ($200 − $7 − $12 − $8) / 2% = $8,650

• Heavy users

  • Inferencia $110, infraestructura de IA/DevOps $15, soporte $15, CS $10
  • Gross Profit = $200 − $110 − $15 − $15 − $10 = $50, LTV = $50 / 2% = $2,500

• Usuarios livianos

  • Inferencia $15, infraestructura de IA/DevOps $8, soporte $10, CS $7
  • Gross Profit = $200 − $15 − $8 − $10 − $7 = $160, LTV = $160 / 2% = $8,000

• Interpretación

  • Se asume un CAC de $1,200 en ambos segmentos
  • Al reflejar el costo de IA por cliente, los heavy users quedan por debajo del benchmark típico de 3:1 LTV:CAC
  • Eso no significa que sean malos clientes, sino una señal de que el operador debe hacer mejores preguntas y revisar la relación entre precios y distribución de costos
  • Conviene revisar la duración de retención de heavy users, velocidad de expansión, cambios de plan, fair-use threshold, enrutamiento a modelos de menor costo para workflows simples, créditos de uso, cobro por sobreuso y cantidad de heavy users

Cuándo usar LTV ajustado por cómputo

• Debe usarse cuando la IA se vende bajo un modelo de suscripción o similar, y los costos de cómputo varían mucho entre clientes
  • Es especialmente útil si los costos de inferencia superan 10% de los ingresos, el uso cambia mucho entre segmentos y se usa LTV:CAC para decidir precios, presupuesto de CAC y adquisición de clientes
• Si los costos de inferencia son pequeños o uniformes, no hace falta complicar el dashboard
  • Si el cómputo de IA representa menos de 5% de los ingresos y la variabilidad por cliente es baja, basta con el LTV tradicional con margen bruto
• Los productos de pricing puramente por uso deben enfocarse en otras métricas; los modelos híbridos (suscripción de plataforma + uso) necesitan ambas perspectivas

Análisis mínimo viable (Minimum Viable Analysis)

• No hace falta tener datos perfectos, pero sí datos de uso por cliente para analizar la distribución
• El nivel por cliente es ideal, aunque empezar por segmento también sirve
  • Primero separar usuarios livianos, core y power users; después agregar SMB, mid-market, enterprise, tipo de plan y canal de adquisición
• El objetivo no es la perfección contable desde el día uno, sino verificar si el LTV promedio está ocultando una economía de clientes débil y detectar datos faltantes

Conclusión práctica para CFOs

• El playbook histórico del SaaS casi siempre veía el alto uso como algo positivo, pero en AI SaaS eso solo funciona si el modelo de precios y la estructura de costos lo sostienen
• El Compute-Adjusted LTV ayuda a entender si un producto de IA por suscripción está creando relaciones rentables con clientes después de considerar el cómputo y los COGS relacionados
  • No reemplaza CAC Payback, GRR, NRR, margen bruto ni LTV:CAC; es una métrica que extiende los unit economics de AI-native y AI-enabled SaaS
• No hay que entrar en pánico si el margen bruto de IA es más bajo que el del SaaS tradicional, pero tampoco se debe evitar el cálculo; las empresas que entienden la economía de IA por cliente logran mejores decisiones de pricing, pronóstico y expansión