Cara Menghitung Compute-adjusted LTV (LTV yang Memperhitungkan Biaya Komputasi)

• Saat produk AI mengenakan biaya langganan yang sama tetapi setiap pelanggan mengonsumsi biaya inferensi yang sangat berbeda, asumsi LTV tradisional bahwa margin kotor di seluruh basis pelanggan stabil pun runtuh
• Intinya adalah Compute-Adjusted LTV, yang mengukur profitabilitas per pelanggan pada produk AI yang menggabungkan pendapatan langganan tetap/semi-tetap dengan biaya komputasi yang sangat bervariasi
• Dua pelanggan dapat membayar harga yang sama, tetapi satu menghabiskan biaya inferensi $110, sementara yang lain $15, sehingga struktur margin kotor aktualnya benar-benar berbeda
• Jika hanya melihat margin kotor rata-rata perusahaan, fakta bahwa sebagian segmen hanya berada di titik impas atau bahkan merugi akan tertutupi, sehingga muncul jebakan nilai rata-rata
• Perusahaan yang memiliki pendapatan AI tetap sekaligus biaya komputasi variabel wajib memahami margin kotor per segmen agar dapat mengurangi kesalahan dalam penetapan harga, forecasting, dan ekspansi

---

Masalah baru pada LTV perangkat lunak tradisional

• Dalam SaaS tradisional, perbedaan biaya untuk melayani satu pelanggan serupa tambahan tidak besar, sehingga margin kotor langganan bisa langsung diterapkan ke LTV
  • LTV dasar = Cohort ARPA / Revenue Churn Rate
  • Versi dengan margin kotor = Cohort ARPA × Gross Margin / Revenue Churn Rate
• Pada produk AI, setiap panggilan inferensi, completion, eksekusi workflow, tugas agent, dan output generatif menimbulkan biaya langsung yang bervariasi, dan biaya serta volumenya berbeda untuk tiap pelanggan
• Mengutip laporan State of AI Januari 2026 dari ICONIQ Capital
  • Pada perusahaan AI B2B tahap scale-up, inferensi model menyumbang rata-rata 23% dari total pendapatan
  • Margin kotor rata-rata produk AI diproyeksikan naik dari 41% pada 2024 menjadi sekitar 52% pada 2026, tetapi tetap belum menyamai SaaS tradisional

Biaya langganan sama, ekonomi pelanggan berbeda

• Pada contoh produk workflow AI seharga $200 per bulan, power user (pelanggan A) menghabiskan biaya inferensi $110, sementara light user (pelanggan B) $15, tetapi dalam LTV tradisional keduanya dihitung sama
• Penggunaan tinggi itu sendiri tidak buruk; heavy user bisa memiliki sticky yang tinggi, berekspansi lebih cepat, dan menjadi pendukung produk
  • Namun, jika model harga tidak memulihkan biaya komputasi, penggunaan tinggi dapat diam-diam menekan atau merusak margin kotor
• Mengutip analisis April 2026 dari Jellyfish (penggunaan token Q1 2026 di 12.000 developer dan 200 perusahaan)
  • Biaya per 1 PR yang di-merge berkisar dari $0.28 pada kelompok penggunaan terendah hingga $89.32 pada kelompok tertinggi, atau selisih 319x
• Penggunaan margin kotor rata-rata dapat menyesatkan pada produk AI berbasis langganan; satu segmen bisa sangat menguntungkan sementara segmen lain hanya berada di titik impas

Pendapatan yang masuk ke rumus Compute-adjusted LTV

• Pendapatan AI dibagi menjadi tiga kategori

  • Direct AI Revenue

    • Input paling bersih berupa pembayaran langsung untuk fitur AI, seperti AI SKU, AI add-on, AI seat, lisensi pengguna AI, paket penggunaan AI, bundel kredit AI, dan pendapatan overage AI

  • AI-Attributed Revenue

    • Jika paket standar $200 dan paket AI $275, maka selisih $75 dapat diperlakukan sebagai pendapatan yang diatribusikan ke AI jika AI adalah pembeda utama, tetapi metodologinya perlu didokumentasikan
    • Perusahaan teknologi publik sudah cukup baik dalam melakukan tagging pendapatan AI, dan hal ini penting di pasar publik

  • AI-Influenced Revenue

    • Ini adalah sinyal komersial bahwa AI mendorong renewal, deal, atau ekspansi, tetapi jika dampak pendapatannya tidak bisa dipisahkan, maka tidak cocok digunakan sebagai pembilang dalam rumus unit economics dan harus dilacak terpisah
• Aturannya: gunakan Direct AI Revenue jika memungkinkan, gunakan AI-Attributed Revenue jika dapat dipertahankan secara metodologis, dan lacak AI-Influenced Revenue secara terpisah

Rumus 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
• Biaya dihitung pada level margin kotor secara fully burdened; sekadar mengurangi biaya inferensi dari pendapatan akan menghasilkan angka terlalu rendah jika tidak hanya ada biaya LLM
• Customer Success hanya dimasukkan ke COGS jika fokus pada onboarding dan retensi, serta tidak memegang kuota

Contoh Compute-adjusted LTV: Acme SaaS

• Produk workflow AI seharga $200 per bulan dijual dalam bentuk langganan, bukan murni berdasarkan penggunaan; pendapatan tetap tetapi konsumsi komputasi variabel

• Rata-rata perusahaan

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

• Heavy user

  • Inferensi $110, infrastruktur AI/DevOps $15, support $15, CS $10
  • Gross Profit = $200 − $110 − $15 − $15 − $10 = $50, LTV = $50 / 2% = $2,500

• Light user

  • Inferensi $15, infrastruktur AI/DevOps $8, support $10, CS $7
  • Gross Profit = $200 − $15 − $8 − $10 − $7 = $160, LTV = $160 / 2% = $8,000

• Interpretasi

  • Kedua segmen diasumsikan memiliki CAC sebesar $1,200
  • Jika biaya AI per pelanggan diperhitungkan, heavy user turun di bawah benchmark umum 3:1 LTV:CAC
  • Ini bukan berarti heavy user adalah pelanggan buruk, melainkan sinyal bahwa operator perlu mengajukan pertanyaan yang lebih baik dan meninjau ulang rasio antara harga dan distribusi biaya
  • Yang perlu diperiksa antara lain masa retensi heavy user, kecepatan ekspansi, perpindahan paket, fair-use threshold, routing model berbiaya rendah untuk workflow sederhana, kredit penggunaan/biaya overage, serta jumlah heavy user

Kapan menggunakan Compute-adjusted LTV

• Gunakan saat AI dijual dalam model langganan atau mirip langganan, dan biaya komputasi sangat berbeda antar pelanggan
  • Sangat berguna terutama ketika biaya inferensi melebihi 10% dari pendapatan, penggunaan sangat bervariasi antar segmen, dan keputusan harga, anggaran CAC, serta akuisisi pelanggan didasarkan pada LTV:CAC
• Jika biaya inferensi kecil atau seragam, tidak perlu membuat dashboard menjadi rumit
  • Jika komputasi AI kurang dari 5% dari pendapatan dan variabilitas per pelanggan rendah, LTV tradisional berbasis margin kotor sudah cukup
• Produk dengan pricing murni berbasis penggunaan perlu fokus pada metrik lain, sementara model hybrid (langganan platform + penggunaan) memerlukan kedua sudut pandang

Analisis minimum yang layak dijalankan (Minimum Viable Analysis)

• Data yang sempurna tidak diperlukan, tetapi data penggunaan per pelanggan dibutuhkan untuk analisis distribusi
• Unit pelanggan ideal, tetapi unit segmen juga merupakan titik awal yang baik
  • Mulailah dengan memisahkan light, core, dan power user, lalu tambahkan SMB, mid-market, enterprise, tipe paket, dan channel akuisisi
• Tujuannya bukan kesempurnaan akuntansi pada hari pertama, melainkan memastikan apakah LTV rata-rata menutupi customer economics yang lemah dan menemukan data yang belum tercatat

Kesimpulan praktis CFO

• Playbook SaaS lama hampir selalu memandang penggunaan tinggi sebagai hal positif, tetapi dalam AI SaaS hal itu hanya berlaku jika model harga dan struktur biaya mendukung
• Compute-Adjusted LTV membantu memahami apakah produk AI berbasis langganan benar-benar menciptakan hubungan pelanggan yang menguntungkan setelah memperhitungkan komputasi dan COGS terkait
  • Metrik ini tidak menggantikan CAC Payback, GRR, NRR, margin kotor, atau LTV:CAC, melainkan memperluas unit economics untuk AI-native dan AI-enabled SaaS
• Tidak perlu panik jika margin kotor AI lebih rendah daripada SaaS tradisional, tetapi perhitungannya tidak boleh dihindari; perusahaan yang memahami ekonomi AI per pelanggan akan mencapai penetapan harga, forecasting, dan ekspansi yang lebih baik