LTV（Customer Lifetime Value）をプロダクトに実装したい、もしくは社内ダッシュボードに組み込みたい開発者向けに、5つの計算方法とそれぞれの実装観点を整理します。
TL;DR
- LTV計算式は5パターン (シンプル / 粗利 / コホート / LTV/CAC / DCF)。事業フェーズと商材で選ぶ
- データ基盤の前提条件: AOV と購入頻度の安定計測
- 実装順序: AOV → RPS → LTV の3階層で組み立てると無理が出ない
- LTV/CAC比 = 3:1 は SaaS 由来の基準で EC にも応用可能だが、業界・チャネル別に分解して見る必要あり
想定スキーマ前提
本記事のSQL/Python例は次の table スキーマを想定しています。
| table | 主要カラム |
|---|---|
customers |
id (PK) / first_touch_channel / first_order_at / ltv_value
|
orders |
id (PK) / customer_id (FK) / revenue / gross_margin / created_at
|
ad_spend |
channel / month / spend
|
first_touch_channel はトラッキングスクリプト or GA4 Measurement Protocol で landing_page_referrer 経由で customers 取得時に保存するパターンを想定しています。
1. 5つの計算式と実装上の判断軸
1.1 シンプルLTV
-- 立ち上げ期EC向け
LTV = AVG(order_amount) * AVG(orders_per_year) * AVG(active_years)
実装は最も簡単。Shopify公式ドキュメントもこの式を基本式として紹介しています。粗利率や顧客IDの紐付けが整っていない初期段階では、この式で十分です。注意点: 売上ベースなので利益率の差異は反映されない。
1.2 粗利LTV
-- 拡大期EC向け
LTV_gross = AVG(order_amount * gross_margin_rate) * AVG(orders) * AVG(years)
広告予算を本格投下するフェーズで必須。粗利率データを持っていない場合は、商品マスタに gross_margin_rate カラムを追加する必要があります。Shopify Plus なら GraphQL で cost フィールド経由で取得可。
1.3 コホートLTV
-- リピート率重視・実測値ベース
SELECT
cohort_month,
SUM(revenue) / COUNT(DISTINCT customer_id) AS ltv
FROM orders o
JOIN customers c ON o.customer_id = c.id
WHERE c.first_order_month = cohort_month
GROUP BY cohort_month
顧客IDの紐付けが必須。BigQuery / Snowflake / Postgres などの分析DBで集計するパターンが一般的です。Bain & Company の研究は、継続率の改善が利益に大きな影響を与えると指摘しており、コホート別にリピート率を追える状態は事業の継続改善に直結します。
1.4 LTV/CAC逆算
1.4 はLTVを「算出する」式ではなく、LTVとCACの「比率を見る」投資判断軸です。LTV算出式は 1.1-1.3 + 1.5 の4方法。
ltv_cac_ratio = ltv / cac # 基準: 3.0 以上が健全
CAC（Customer Acquisition Cost）はチャネル別に配賦が必要です。広告費 + 人件費 + ツール費 ÷ 新規獲得顧客数。SaaS業界の「3:1」基準はECにも応用できますが、業界・商材で妥当な比率は変動するので、自社実測値を基準にするのが安全です。
1.5 DCF型LTV
def dcf_ltv(annual_cf_list, discount_rate=0.07):
return sum(cf / (1 + discount_rate)**n for n, cf in enumerate(annual_cf_list, 1))
# 例: 5年間 [10000, 8000, 6000, 4000, 2000] 円, 割引率7%
ltv = dcf_ltv([10000, 8000, 6000, 4000, 2000], 0.07)
サブスクEC（D2Cの定期便など）や高単価商材で、3-5年スパンの投資判断をする際に採用。割引率の置き方で結果が大きく変わるので、前提条件のドキュメント化が必須です。
2. AOV → RPS → LTV の3階層フレーム
5つの計算方法すべてに共通するのは、AOVと購入頻度（または継続期間）が安定計測できている前提です。実装順序として、上流から組み立てるとデータパイプラインに無理が出ません。
| 階層 | 単位 | 集計クエリ例 |
|---|---|---|
| AOV | 1注文 | SUM(revenue) / COUNT(DISTINCT order_id) |
| RPS | 1セッション | SUM(revenue) / COUNT(DISTINCT session_id) |
| LTV | 1顧客 |
SUM(revenue) / COUNT(DISTINCT customer_id) (期間絞り) |
集計単位が違うので、ダッシュボードの fact table を分けて持つか、ビュー層で sum / count distinct を切り替える設計が現実的です。
実務運用では、AOVとRPSを月次で安定計測できる状態を作ったうえで、LTVは四半期に1回算出するのが現実的です。LTVを毎日見る必要はないけど、AOVとRPSは毎日見られる体制が前提になります。
3. LTV/CAC比のチャネル別配賦
LTV/CAC比は全体平均では判断を誤ります。Paidチャネルが0.8でOrganicが5.0という構成だった場合、Paidの新規獲得を停止する判断が正解になります。
-- チャネル別 LTV/CAC 比
SELECT
c.first_touch_channel,
AVG(c.ltv_value) AS ltv,
SUM(ad.spend) / COUNT(DISTINCT c.id) AS cac,
AVG(c.ltv_value) / (SUM(ad.spend) / COUNT(DISTINCT c.id)) AS ltv_cac_ratio
FROM customers c
JOIN ad_spend ad ON c.first_touch_channel = ad.channel
AND DATE_TRUNC('month', c.first_order_at) = ad.month
GROUP BY c.first_touch_channel
first_touch_channel の取得には UTM パラメータの保存が前提。トラッキングスクリプト or GA4 Measurement Protocol で landing_page_referrer を customers テーブルに保存しておく実装が一般的です。
4. 計測実装の落とし穴4つ
# (1) リピートゼロ顧客の扱い
# NG: 全顧客の平均
avg_ltv = customers.aggregate(Avg('ltv'))
# OK: 「初回購入のみ」と「リピート発生」を分けて算出
first_only = customers.filter(order_count=1).aggregate(Avg('ltv'))
repeat = customers.filter(order_count__gt=1).aggregate(Avg('ltv'))
# (2) 計測期間の固定
# NG: 全顧客で「3年で固定」 を仮定
ltv = aov * frequency * 3
# OK: コホート別に実測継続月数を採用
ltv = aov * frequency * cohort.actual_active_months
# (3) 割引適用前後の混在
# NG: gross sales ベース
aov = SUM(gross_sales) / COUNT(orders)
# OK: 割引適用後 (net sales) ベース
aov = SUM(gross_sales - discounts) / COUNT(orders)
# (4) チャネル別配賦
# NG: 全顧客平均で LTV を算出
ltv = SUM(revenue) / COUNT(customers)
# OK: 初回流入チャネル別にコホート分割
ltv_by_channel = customers.values('first_touch_channel').annotate(
ltv=Sum('revenue') / Count('id')
)
5. まとめ
- 5つのLTV計算式は事業フェーズと商材で使い分け
- LTV単独では投資判断ができない・LTV/CAC比で見る
- AOV → RPS → LTV の3階層で実装・前段が安定してから上位に進む
- LTV/CAC比はチャネル別・コホート別に分解しないと判断を誤る
LP本体に5方法の比較表とAOV→RPS→LTVの3階層フレーム図を置いてあります。実装観点の詳細は本記事に書きましたが、概念整理は LP 側のほうが図解付きで読みやすいかもしれません。