So berechnet man Compute-adjusted LTV (LTV unter Berücksichtigung von Rechenkosten)

• Da AI-Produkte trotz gleicher Abogebühr je nach Kunde sehr unterschiedliche Inference-Kosten verursachen, bricht die Annahme des traditionellen LTV zusammen, dass die Bruttomarge über den gesamten Kundenstamm hinweg stabil ist
• Der Kern ist Compute-Adjusted LTV, das die Rentabilität auf Kundenebene von AI-Produkten misst, bei denen feste oder halbfixe Abo-Umsätze mit stark variablen Rechenkosten zusammenkommen
• Selbst wenn zwei Kunden denselben Preis zahlen, kann der eine Inference-Kosten von $110 verursachen und der andere nur $15, wodurch sich eine völlig andere tatsächliche Bruttogewinnstruktur ergibt
• Betrachtet man nur die durchschnittliche Bruttomarge des Unternehmens, bleibt verborgen, dass manche Segmente nur auf Break-even-Niveau liegen oder Verluste machen — eine Falle des Durchschnittswerts
• Unternehmen mit fixen AI-Abo-Umsätzen und zugleich variablen Rechenkosten müssen die Bruttomarge pro Segment unbedingt verstehen, um Fehler bei Preisgestaltung, Forecasting und Skalierung zu vermeiden

---

Das neue Problem des traditionellen Software-LTV

• In traditionellem SaaS unterscheiden sich die Kosten, einen weiteren ähnlichen Kunden zu bedienen, kaum, sodass sich die Abo-Bruttomarge direkt auf den LTV anwenden lässt
  • Basis-LTV = Cohort ARPA / Revenue Churn Rate
  • Variante mit Bruttomarge = Cohort ARPA × Gross Margin / Revenue Churn Rate
• Bei AI-Produkten entstehen für jeden Inference-Call, jede Completion, jede Workflow-Ausführung, jede Agent-Aufgabe und jede generierte Ausgabe direkte und variable Kosten, und sowohl Kosten als auch Nutzung unterscheiden sich je nach Kunde
• Zitat aus dem State-of-AI-Report von ICONIQ Capital vom Januar 2026
  • Bei AI-B2B-Unternehmen in der Skalierungsphase macht Model Inference im Schnitt 23% des Gesamtumsatzes aus
  • Die durchschnittliche Bruttomarge von AI-Produkten soll von 41% im Jahr 2024 auf rund 52% im Jahr 2026 steigen, bleibt damit aber weiter unter klassischem SaaS-Niveau

Gleiche Abogebühr, unterschiedliche Kundenökonomik

• Im Beispiel eines AI-Workflow-Produkts für $200 pro Monat verursacht der Power User (Kunde A) Inference-Kosten von $110, der Light User (Kunde B) dagegen nur $15 — im traditionellen LTV werden beide dennoch gleich behandelt
• Hohe Nutzung ist nicht per se schlecht; Heavy User haben oft eine höhere Bindung (sticky), expandieren schneller und können zu Produktbotschaftern werden
  • Wenn das Preismodell die Rechenkosten jedoch nicht auffängt, kann hohe Nutzung die Bruttomarge unbemerkt unter Druck setzen oder zerstören
• Zitat aus der Analyse von Jellyfish vom April 2026 (Token-Nutzung im 1. Quartal 2026 bei 12.000 Entwicklern und 200 Unternehmen)
  • Die Kosten pro gemergtem PR reichen vom niedrigsten Nutzungsbereich mit $0.28 bis zum höchsten mit $89.32, eine 319-fache Differenz
• Die Verwendung einer durchschnittlichen Bruttomarge führt bei abonnementbasierten AI-Produkten leicht in die Irre; ein Segment kann hochprofitabel sein, während ein anderes nur auf Break-even-Niveau liegt

Welche Umsätze in die Formel für Compute-adjusted LTV eingehen

• AI-Umsätze werden in drei Kategorien aufgeteilt

  • Direct AI Revenue

    • Der sauberste Input-Wert: direkte Zahlungen für AI-Funktionen wie AI SKU, AI-Add-on, AI Seat, AI-User-Lizenz, AI-Nutzungspaket, AI-Credit-Bundle oder AI-Overage-Umsatz

  • AI-Attributed Revenue

    • Wenn ein Standardplan $200 und ein AI-Plan $275 kostet, kann die Differenz von $75 als AI-zurechenbarer Umsatz behandelt werden, sofern AI der wesentliche Unterschied ist — die Methodik sollte jedoch dokumentiert werden
    • Börsennotierte Tech-Unternehmen taggen AI-Umsätze bereits gut, und am öffentlichen Markt ist das essenziell

  • AI-Influenced Revenue

    • Ein kommerzielles Signal, dass Verlängerung, Abschluss oder Expansion wegen AI zustande kam; wenn sich der Umsatzeffekt aber nicht isolieren lässt, ist er als Zähler in Formeln zur Unit Economics ungeeignet und sollte separat verfolgt werden
• Regel: Wenn möglich Direct AI Revenue verwenden, bei belastbarer Argumentation AI-Attributed Revenue nutzen und AI-Influenced Revenue separat tracken

Formel für Compute-Adjusted LTV

• 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
• Kosten sollten auf Bruttomargenebene voll belastet (fully burdened) berechnet werden; einfach nur die Inference-Kosten vom Umsatz abzuziehen ist zu niedrig angesetzt, sofern nicht ausschließlich LLM-Kosten anfallen
• Customer Success wird nur dann den COGS zugerechnet, wenn der Fokus auf Einführung und Bindung liegt und keine Vertriebsquote erfüllt werden muss

Beispiel für Compute-adjusted LTV: Acme SaaS

• Ein AI-Workflow-Produkt für $200 pro Monat wird als Abo-Modell statt als reine Usage-Pricing-Lösung verkauft; der Umsatz ist fix, der Compute-Verbrauch variabel

• Unternehmensdurchschnitt

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

• Heavy User

  • Inference $110, AI-Infrastruktur/DevOps $15, Support $15, CS $10
  • Gross Profit = $200 − $110 − $15 − $15 − $10 = $50, LTV = $50 / 2% = $2,500

• Light User

  • Inference $15, AI-Infrastruktur/DevOps $8, Support $10, CS $7
  • Gross Profit = $200 − $15 − $8 − $10 − $7 = $160, LTV = $160 / 2% = $8,000

• Einordnung

  • Für beide Segmente wird ein CAC von $1,200 angenommen
  • Wenn AI-Kosten auf Kundenebene berücksichtigt werden, fällt der Heavy User unter den üblichen 3:1-LTV:CAC-Benchmark
  • Das bedeutet nicht, dass Heavy User schlechte Kunden sind, sondern signalisiert, dass Betreiber bessere Fragen stellen und die Relation zwischen Preis und Kostenverteilung neu prüfen sollten
  • Zu prüfen sind die Bindungsdauer von Heavy Usern, ihre Expansionsgeschwindigkeit, Planwechsel, Fair-Use-Schwellen (fair-use threshold), kostengünstigeres Model Routing für einfache Workflows, Usage Credits und Overage-Abrechnung sowie die Anzahl der Heavy User

Wann man Compute-adjusted LTV einsetzen sollte

• Wenn AI in einem Abo- oder Abo-ähnlichen Modell verkauft wird und die Rechenkosten je Kunde stark variieren
  • Besonders nützlich, wenn die Inference-Kosten mehr als 10% des Umsatzes ausmachen, die Nutzung segmentweise stark schwankt und LTV:CAC für Preisgestaltung, CAC-Budgets und Kundenakquise genutzt wird
• Sind die Inference-Kosten gering oder weitgehend gleichmäßig, muss das Dashboard nicht unnötig komplex gemacht werden
  • Wenn AI-Compute unter 5% des Umsatzes liegt und die Varianz auf Kundenebene niedrig ist, reicht der bestehende LTV mit Bruttomargenberücksichtigung aus
• Bei Produkten mit rein nutzungsabhängiger Bepreisung sollten andere Metriken im Fokus stehen; hybride Modelle (Plattform-Abo + nutzungsabhängige Gebühren) brauchen beide Perspektiven

Minimum Viable Analysis

• Perfekte Daten sind nicht nötig, aber für Verteilungsanalysen werden Nutzungsdaten auf Kundenebene benötigt
• Ideal ist die Kundenebene, aber auch Segmentebene ist ein guter Startpunkt
  • Zunächst in Light-, Core- und Power User unterteilen, später SMB, Mid-Market, Enterprise, Plantyp und Akquisekanal ergänzen
• Das Ziel ist nicht buchhalterische Perfektion am ersten Tag, sondern zu prüfen, ob der durchschnittliche LTV schwache Kundenökonomik verdeckt, und fehlende Daten aufzudecken

Fazit aus CFO-Perspektive

• Das frühere SaaS-Playbook bewertete hohe Nutzung fast immer positiv, doch bei AI SaaS gilt das nur, wenn Preismodell und Kostenstruktur dazu passen
• Compute-Adjusted LTV hilft zu verstehen, ob abonnementbasierte AI-Produkte nach Berücksichtigung von Compute und den zugehörigen COGS profitable Kundenbeziehungen schaffen
  • Die Kennzahl ersetzt nicht CAC Payback, GRR, NRR, Bruttomarge oder LTV:CAC, sondern erweitert die Unit Economics von AI-native- und AI-enabled-SaaS
• Auch wenn die AI-Bruttomarge unter traditionellem SaaS liegt, besteht kein Grund zur Panik — aber man darf die Berechnung nicht vermeiden; Unternehmen, die die AI-Ökonomik pro Kunde verstehen, erreichen bessere Preisgestaltung, besseres Forecasting und bessere Skalierung