Compute-adjusted LTV (hesaplama maliyetini yansıtan LTV) nasıl hesaplanır

• AI ürünleri aynı abonelik ücretini alırken bile müşteriye göre çıkarım maliyeti çok farklı tüketildiğinden, toplam müşteri kitlesinin brüt kâr marjının istikrarlı olduğu yönündeki geleneksel LTV varsayımı bozuluyor
• Temel kavram Compute-Adjusted LTV; sabit veya yarı sabit abonelik gelirine yüksek değişkenlik gösteren hesaplama maliyetlerinin eşlik ettiği AI ürünlerinde müşteri bazında kârlılığı ölçüyor
• İki müşteri aynı fiyatı ödese bile bir taraf $110 çıkarım maliyeti, diğer taraf $15 tüketebiliyor; bu da gerçek brüt kâr yapısının tamamen farklı olmasına yol açıyor
• Yalnızca şirket ortalaması brüt kâr marjına bakılırsa bazı segmentlerin başa baş noktada kaldığı ya da zarar ettiği gerçeği gizlenebiliyor; bu da ortalama tuzağına neden oluyor
• Sabit AI abonelik geliri ile değişken hesaplama maliyetini birlikte taşıyan şirketlerin, fiyatlama, tahmin ve ölçekleme hatalarını azaltmak için mutlaka segment bazında brüt kârı anlaması gerekiyor

---

Geleneksel yazılım LTV’sinde ortaya çıkan yeni sorun

• Geleneksel SaaS’ta benzer bir müşteriye bir tane daha hizmet vermenin maliyet farkı büyük olmadığından, abonelik brüt kâr marjı doğrudan LTV’ye uygulanabiliyor
  • Temel LTV = Cohort ARPA / Revenue Churn Rate
  • Brüt kârı yansıtan sürüm = Cohort ARPA × Gross Margin / Revenue Churn Rate
• AI ürünlerinde çıkarım çağrıları, completion’lar, workflow çalıştırmaları, agent görevleri ve üretilen her çıktı için doğrudan ve değişken maliyet oluşuyor; bu maliyet ve kullanım miktarı da müşteriden müşteriye değişiyor
• ICONIQ Capital’in Ocak 2026 tarihli State of AI raporundan alıntı
  • Ölçeklenme aşamasındaki AI B2B şirketlerinde model çıkarımı toplam gelirin ortalama %23’ünü oluşturuyor
  • AI ürünlerinde ortalama brüt kâr marjının 2024’te %41’den 2026’da yaklaşık %52’ye yükselmesi bekleniyor; ancak bu oran hâlâ geleneksel SaaS seviyesinin altında

Aynı abonelik ücreti, farklı müşteri ekonomisi

• Aylık $200’lık bir AI workflow ürünü örneğinde, güçlü kullanıcı (müşteri A) $110 çıkarım maliyeti tüketirken hafif kullanıcı (müşteri B) $15 tüketiyor; ancak geleneksel LTV’de ikisi de aynı şekilde hesaplanıyor
• Yüksek kullanım tek başına kötü değildir; heavy user’ların yapışkanlığı (sticky) daha yüksek olabilir, daha hızlı genişleyebilir ve ürün savunucusuna dönüşebilir
  • Ancak fiyatlama modeli hesaplama maliyetini geri kazanamıyorsa, yüksek kullanım brüt kâr marjını sessizce baskılayabilir ya da yok edebilir
• Jellyfish’in Nisan 2026 tarihli analizinden alıntı (12.000 geliştirici ve 200 şirkette 2026’nın 1. çeyreği token kullanımı)
  • Birleştirilmiş PR başına maliyet, en düşük kullanım aralığında $0.28 iken en yüksek aralıkta $89.32’ye çıkıyor; arada 319 kat fark var
• Ortalama brüt kâr marjını kullanmak abonelik tabanlı AI ürünlerinde yanıltıcı olabilir; bir segment çok kârlıyken başka bir segment başa baş seviyesinde olabilir

Compute-adjusted LTV formülündeki gelir

• AI geliri üç kategoriye ayrılıyor

  • Direct AI Revenue

    • AI SKU, AI add-on, AI seat, AI kullanıcı lisansı, AI kullanım paketi, AI kredi paketi, AI aşım geliri gibi AI özellikleri için doğrudan ödeme yapılan kalemler en temiz girdi değeridir

  • AI-Attributed Revenue

    • Standart plan $200, AI planı $275 ise aradaki $75 fark, eğer temel fark AI ise AI’ye atfedilen gelir olarak değerlendirilebilir; ancak yöntemin mutlaka belgelenmesi gerekir
    • Halka açık teknoloji şirketleri AI gelir etiketlemesini iyi yapıyor ve bu durum açık piyasalarda zorunlu hale geliyor

  • AI-Influenced Revenue

    • AI sayesinde yenileme, anlaşma kazanımı veya genişleme yaşandığını gösteren ticari sinyal niteliğindedir; ancak gelir etkisi ayrıştırılamıyorsa birim ekonomi formülünün payında kullanıma uygun değildir, bu nedenle ayrı izlenmelidir
• Kural: Mümkünse Direct AI Revenue kullanın, savunulabiliyorsa AI-Attributed Revenue kullanın, AI-Influenced Revenue’yu ise ayrı takip edin

Compute-Adjusted LTV formülü

• Compute-Adjusted LTV = Müşteri başına hesaplama düzeltilmiş brüt kâr / Revenue Churn Rate
  • Müşteri başına hesaplama düzeltilmiş brüt kâr = Müşteri başına AI geliri − Müşteri başına tam yüklenmiş AI COGS
  • Fully Burdened AI COGS = Inference Costs + AI Infrastructure Costs + Support Costs + Customer Success Costs + DevOps
• Maliyetler brüt kâr seviyesinde tam yüklenmiş (fully burdened) olarak hesaplanmalı; yalnızca gelirden çıkarım maliyetini düşmek, sadece LLM maliyeti olan durumlar dışında eksik hesaplamaya yol açar
• Customer Success, yalnızca onboarding ve elde tutmaya odaklanıyor ve kota taşımıyorsa COGS’e dahil edilir

Compute-adjusted LTV örneği: Acme SaaS

• Aylık $200’lık AI workflow ürünü saf kullanım bazlı değil, abonelik modeli ile satılıyor; gelir sabit ama hesaplama tüketimi değişken

• Şirket ortalaması

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

• Heavy user

  • Çıkarım $110, AI altyapısı/DevOps $15, destek $15, CS $10
  • Gross Profit = $200 − $110 − $15 − $15 − $10 = $50, LTV = $50 / 2% = $2,500

• Hafif kullanıcı

  • Çıkarım $15, AI altyapısı/DevOps $8, destek $10, CS $7
  • Gross Profit = $200 − $15 − $8 − $10 − $7 = $160, LTV = $160 / 2% = $8,000

• Yorum

  • Her iki segment için de CAC’nin $1,200 olduğu varsayılıyor
  • Müşteri bazında AI maliyeti yansıtıldığında heavy user’lar genel kabul gören 3:1 LTV:CAC benchmark’ının altına düşüyor
  • Bu, heavy user’ların kötü müşteri olduğu anlamına gelmiyor; operatörün daha iyi sorular sorması ve fiyatlama ile maliyet dağılım oranını yeniden gözden geçirmesi gerektiğine işaret ediyor
  • Heavy user’ların elde tutma süresi, genişleme hızı, plan geçişi, adil kullanım eşiği (fair-use threshold), basit workflow’lar için düşük maliyetli model yönlendirme, kullanım kredileri ve aşım ücretlendirmesi ile heavy user sayısı kontrol edilmeli

Compute-adjusted LTV ne zaman kullanılmalı

• AI abonelik veya aboneliğe benzer bir modelle satılıyorsa ve hesaplama maliyeti müşteri bazında ciddi farklılık gösteriyorsa kullanılmalı
  • Özellikle çıkarım maliyeti gelirin %10’undan fazlaysa, kullanım segmentler arasında ciddi değişiyorsa ve LTV:CAC fiyatlama, CAC bütçesi ya da müşteri ediniminde karar vermek için kullanılıyorsa faydalıdır
• Çıkarım maliyeti küçük ya da homojense dashboard’u karmaşıklaştırmaya gerek yok
  • AI hesaplama maliyeti gelirin %5’inden azsa ve müşteri bazındaki değişkenlik düşükse, mevcut brüt kârı yansıtan LTV yeterlidir
• Saf kullanım fiyatlamalı ürünlerde başka metriklere odaklanmak gerekir; hibrit (platform aboneliği + kullanım) modellerde ise her iki bakış açısı da gerekir

Minimum uygulanabilir analiz (Minimum Viable Analysis)

• Kusursuz veri şart değil, ancak dağılım analizi için müşteri bazında kullanım verisi gerekli
• Müşteri seviyesi ideal olsa da segment seviyesi de iyi bir başlangıçtır
  • Önce hafif, çekirdek ve güçlü kullanıcı olarak ayırın; ardından SMB, mid-market, enterprise, plan türü ve edinim kanalını ekleyin
• Amaç ilk günde muhasebesel mükemmellik değil; ortalama LTV’nin zayıf müşteri ekonomisini gizleyip gizlemediğini görmek ve eksik verileri tespit etmektir

Uygulamadaki CFO sonucu

• Geçmiş SaaS playbook’ları yüksek kullanımı neredeyse her zaman olumlu görüyordu; ancak AI SaaS’ta bu, ancak fiyatlama modeli ve maliyet yapısı desteklediğinde geçerlidir
• Compute-Adjusted LTV, hesaplama ve ilgili COGS yansıtıldıktan sonra abonelik tabanlı AI ürünlerinin kârlı müşteri ilişkileri oluşturup oluşturmadığını anlamaya yardımcı olur
  • CAC Payback, GRR, NRR, brüt kâr marjı ve LTV:CAC’nin yerini almaz; AI-native ve AI-enabled SaaS’ın birim ekonomisini genişleten bir metriktir
• AI brüt kâr marjı geleneksel SaaS’tan düşük olsa bile paniğe gerek yok; ancak bu hesabı yapmaktan kaçınılmamalı. Müşteri bazında AI ekonomisini anlayan şirketler daha iyi fiyatlama, tahminleme ve ölçekleme başarır