CAC 與 LTV 怎麼一起看？建立可承受的獲客成本
從完整獲客成本、生命週期貢獻價值與回本期，推算可承受 CAC，並用 cohort 比較不同渠道的新客品質。
先說結論：可承受 CAC 不是 LTV 的同義詞
獲客成本（Customer Acquisition Cost, CAC）是否合理，要看新客未來能帶來多少「扣除變動成本後的貢獻價值」、多久能回收，以及估計有多不確定。 這個長期價值就是 LTV（Customer Lifetime Value，顧客終身價值）：一位顧客從建立關係到停止往來期間，預期能為企業帶來的累積價值。不能只因為 LTV 高於 CAC，就把整筆 LTV 都拿去買新客。
實務上可以用三個問題一起判斷：
若預估一位新客的生命週期貢獻價值是 1,120 元，不代表 CAC 上限就是 1,120 元。你仍要保留維繫顧客的成本、固定成本、目標利潤與預測誤差。比較安全的思路是：
先把 CAC 算完整：分子和分母必須來自同一批新客
OpenStax 將 CAC 說明為特定期間的銷售與行銷成本總和，除以該期間取得的新客數。Google Ads 的新客開發報表則提供較窄的媒體口徑：分配給新客的廣告費除以活動取得的獨立新客。兩者都可以使用，但回答的問題不同。
CAC ＝特定期間用於取得新客的成本 ÷ 同期間取得的新客數
若要判斷整體商業模式能否承受獲客，分子通常不應只有廣告費，還應依一致規則納入：
- 廣告與媒體費。
- 素材製作、代理商、聯盟或創作者費用。
- 專門服務新客開發的銷售與行銷人力。
- 到達頁、名單工具、歸因與行銷軟體的合理分攤。
- B2B 銷售的開發、展示、試用與成交成本。
但不要把所有品牌、人事與營運費用任意塞入 CAC。重點不是得到最大的數字，而是建立可重複、可比較、能解釋的成本規則。若廣告平台只能提供媒體 CAC，報表應直接標成「廣告 CAC」，不要和全公司的 blended CAC 混用。
分母也要守住三件事：只算真正的新客、去除重複身分，並讓成本與新客落在合理的取得期間。長銷售週期業務若把本月成本除以本月成交，可能把三個月前培養的名單錯配到本月；此時應按 lead cohort 或首次商機月份追蹤。
LTV 是什麼？估算一位顧客整段關係能帶來多少價值
LTV 的完整名稱是 Customer Lifetime Value，中文常譯為「顧客終身價值」或「顧客生命週期價值」，也常寫成 CLV。它要回答的不是「這張訂單賣了多少」，而是：取得一位顧客之後，這位顧客在整段往來期間，平均會累積多少營收或貢獻。
這裡的「終身」不是人的自然壽命，而是顧客和企業維持交易關係的期間。訂閱服務可以從註冊計算到取消；電商可以從第一次購買觀察到最後一次購買，或使用固定的 90、180、365 天觀察窗。採用哪一種終點，必須和產業購買週期及資料成熟度一起說明。
例如一位新客第一次購買 1,000 元，只能確定首購營收是 1,000 元，不能立刻說他的 LTV 就是 1,000 元。如果同類新客平均在十二個月內購買 2.8 次，十二個月營收型 LTV 才會估成 2,800 元；若每筆交易扣除變動成本後只留下 400 元，貢獻型 LTV 則是 1,120 元。同一批顧客可以同時有不同口徑的 LTV，所以報表必須把「期間」和「價值口徑」寫出來。
LTV 通常由四個因素共同形成：
| LTV 組成 | 它在回答什麼 | 常見資料 |
|---|---|---|
| 每次交易價值 | 顧客每次平均帶來多少營收或貢獻？ | 平均訂單金額、每月平均收入、每筆貢獻 |
| 購買頻率 | 顧客在觀察期間會交易幾次？ | 回購次數、續約次數、使用月份 |
| 關係長度 | 顧客會維持多久？ | 留存率、流失率、首次到最後交易時間 |
| 成本口徑 | 營收中有多少真的能留下？ | 商品、履約、金流、退款與服務成本 |
還要分清楚已觀察的 LTV和預測 LTV。歷史 LTV 是某一批顧客在既定觀察窗內已經累積的結果；預測 LTV 則會根據留存、頻率或統計模型，推估尚未發生的交易。Stripe 的 CLV 說明也區分歷史資料、cohort 分析與預測模型。預測能協助提早做預算決策，但它不是已經收到的現金，也不是每位顧客都會達到的保證值。
因此，LTV 最適合用來比較一批條件相近的新客，例如相同取得月份、渠道或方案的 cohort，而不是把一個全站平均值直接貼到每個人身上。先確定要觀察哪一批人、多久，以及累積的是營收還是貢獻，後面的 LTV：CAC 才有可比性。
LTV 怎麼算？先選口徑：營收型好算，貢獻型才接近可花預算
知道 LTV 在衡量什麼之後，才進入計算。Stripe 提供的簡化 CLV／LTV 算法，是平均交易價值乘上交易次數，再乘上顧客關係長度：
營收型 LTV ＝平均訂單金額 × 平均購買次數 × 平均顧客壽命
這適合快速描述「一位顧客總共帶來多少營收」，卻不能直接當作獲客預算。售價裡還包含商品成本、物流、金流、退貨、折讓、客服與其他會隨交易增加的成本。Shopify 對電商獲客的說明也將貢獻毛利界定為營收扣除商品、運送、金流與退貨等變動成本後，可用來抵銷 CAC 的部分。
因此，本文用下面的口徑做決策：
每筆訂單貢獻＝淨營收 − 商品／履約／金流／退貨等變動成本
貢獻型 LTV＝顧客生命週期內各期貢獻的總和
這仍不是完整淨利。若客服、成功團隊、忠誠計畫或續約佣金尚未放進每期變動成本，就必須另外保留；固定人事、租金、研發與稅務也不會憑空消失。想把 LTV 用於重大財務決策時，還要考慮未來現金流折現，並和財務團隊確認口徑。
若要先理解營收、成本與廣告效率的差異，可以搭配閱讀ROAS 很高，廣告就一定有賺錢嗎？。
完整案例：從 50.4 萬獲客投入推回 560 元 CAC 上限
以下是虛構教學案例，不是 MKT Notes 或任何品牌的實際營運結果。
假設一個咖啡訂閱品牌在一季內投入：
| 新客開發成本 | 金額 |
|---|---|
| 廣告媒體 | 360,000 元 |
| 素材與代理商 | 72,000 元 |
| 新客行銷人力與工具分攤 | 72,000 元 |
| 合計 | 504,000 元 |
同一取得期間共辨識到 900 位新客，因此：
完整 CAC ＝504,000 ÷ 900 ＝560 元／新客
品牌從歷史 cohort 估計，一位新客在前 12 個月平均完成 2.8 筆訂單。每筆淨營收 1,000 元，商品、履約、金流與平均退貨損失共 600 元，所以每筆訂單貢獻是 400 元。
| 生命週期估計 | 算式 | 每位新客 |
|---|---|---|
| 12 個月營收型 LTV | 1,000 × 2.8 | 2,800 元 |
| 12 個月貢獻型 LTV | 400 × 2.8 | 1,120 元 |
| 貢獻型 LTV：CAC | 1,120 ÷ 560 | 2.0 倍 |
| 扣除 CAC 後剩餘貢獻 | 1,120 − 560 | 560 元 |
若誤用營收型 LTV，會看到 2,800 ÷ 560＝5 倍，感覺預算非常寬鬆；換成貢獻型 LTV 後只有 2 倍。這 560 元剩餘貢獻還要負擔留存活動、固定成本、預測誤差與利潤，並不是已實現的淨利。
團隊若先保留每位顧客 120 元的留存投入、300 元目標利潤，以及 140 元預測緩衝，可承受 CAC 正好是：
1,120 − 120 − 300 − 140 ＝560 元
此時實際 CAC 已經碰到內部上限。若想放大預算，不能只說「LTV 還比 CAC 高」；應先證明新增客群仍能維持回購、貢獻毛利與回本速度。
低 CAC 的渠道，可能帶來更差的顧客
假設兩個渠道的客群與成本口徑都已校正：
| 指標 | 渠道 A | 渠道 B |
|---|---|---|
| CAC | 420 元 | 600 元 |
| 12 個月平均訂單數 | 1.7 | 3.8 |
| 每筆訂單貢獻 | 400 元 | 400 元 |
| 12 個月貢獻型 LTV | 680 元 | 1,520 元 |
| 貢獻型 LTV：CAC | 1.62 倍 | 2.53 倍 |
| 扣除 CAC 後剩餘貢獻 | 260 元 | 920 元 |
渠道 A 的 CAC 比較漂亮，卻可能集中在折扣敏感、只買一次的顧客；渠道 B 取得成本較高，但若後續價值確實由同一取得 cohort 產生，反而留下更多貢獻。
這也不能直接證明「渠道 B 造成顧客更忠誠」。渠道、受眾、商品、優惠、季節與顧客本身可能同時不同。這張表支持的是關聯性預算判斷：不要只依 CAC 刪減渠道；若要判斷增量因果，還要使用合適的實驗或地理／受眾 lift 設計。Google Ads 也明確指出，其生命週期目標報表本身不支援增量測試，需另用 Conversion Lift 等方法。
LTV：CAC 看長期效率，回本期看現金壓力
Stripe 將 CAC 回本期定義為：一位新客產生的累積貢獻，需要多久才能覆蓋取得成本。若每月貢獻相對穩定，可以用簡式：
但電商回購通常不平均，直接除法可能失真。較可靠的做法，是把同一取得月份的新客放在同一 cohort，逐月累加：
| 取得後時間 | 當期平均貢獻 | 累積貢獻 | 是否回收 560 元 CAC |
|---|---|---|---|
| 首購 | 400 元 | 400 元 | 尚未 |
| 第 2 月 | 160 元 | 560 元 | 剛好回本 |
| 第 3 月 | 120 元 | 680 元 | 已回本 |
| 第 6 月 | 180 元 | 860 元 | 已形成緩衝 |
| 第 12 月 | 260 元 | 1,120 元 | 完成觀察窗 |
即使預估 LTV 很高，回本需要兩年，也可能讓快速擴張的企業先遇到現金缺口；相反地，回本快不代表最終 LTV 一定高。前者偏長期單位經濟，後者偏短期資金效率，兩者不能互相取代。
用 cohort 建立 LTV，而不是用全站平均掩蓋差異
Google Analytics 的 User lifetime 探索可以依首次來源、媒介或活動觀察 lifetime revenue，也能查看平均值與分位數；Cohort exploration 則能把相同取得日期的使用者放在一起，觀察後續交易或回訪。這些功能適合建立分析起點，但工具顯示的 lifetime revenue 不會自動變成本文所需的貢獻型 LTV。
一份可用的 cohort 表至少要有：
- 取得月份：顧客何時首次成為新客。
- 取得渠道／活動：使用一致的首次取得規則。
- 新客數與完整獲客成本：保留分子、分母與成本版本。
- 第 0、1、2、3、6、12 月淨營收。
- 同期變動成本與累積貢獻。
- 退款、取消、流失與可辨識率。
比較時要固定觀察窗。剛取得兩個月的 cohort，不應拿「目前累積 LTV」直接和已觀察十二個月的 cohort 比；可以比較相同月齡的累積值，或使用清楚標示假設的預測模型。
身分辨識也會影響結果。GA4 官方文件指出，User-ID 與裝置識別的設定會改變 lifetime 資料；Cohort exploration 本身以裝置資料建立 cohort，並不採用 User-ID。跨裝置、未登入、門市與線上未整合時，同一個人可能被拆成多位顧客，讓 CAC 偏低、LTV 也被切碎。報表必須把這類限制寫在結論旁邊。
五種常見誤判
1. 把 ROAS 或首購 CPA 當成 CAC
ROAS 以平台歸因營收除以廣告費；首購 CPA 通常以廣告費除以平台歸因轉換。完整 CAC 還包含其他取得成本，也必須確認轉換真的是獨立新客。
2. 用營收 LTV 除以完整 CAC
分子是營收、分母是成本，比例看起來會偏高。若要判斷可承受成本，應改用貢獻型 LTV，或至少同時呈現毛利與尚未扣除的項目。
3. 用所有老客的平均值預測今天的新客
多年留下來的顧客本來就比較忠誠，直接拿他們的平均消費預測新客，會產生存活者偏差。應從取得 cohort 開始追蹤，並分開渠道、優惠、產品與客群。
4. 套用通用的「3：1 就健康」
某些資料會以 3：1 作為 SaaS 參考，但它不是所有產業的安全線。高毛利訂閱、低毛利零售、長銷售週期 B2B 與一次性專案的現金流和固定成本完全不同。門檻應由自己的成本、回本要求、資金與風險推回來。
5. 把預測 LTV 當成已經收到的錢
LTV 是估計，不是保證。價格、留存、產品品質、競爭、追蹤與客群組合改變，都會讓舊模型失效。預測值應附上資料截止日、觀察窗、模型版本與保守／基準／樂觀情境。
建立可承受 CAC 的八步流程
- 定義新客：首次付費、首次合格成交，還是首次簽約？排除舊客與重複身分。
- 選定成本口徑：分開媒體 CAC、渠道 CAC 與 blended CAC，寫下納入項目。
- 按取得 cohort 配對：讓成本、新客數與取得期間一致。
- 計算每期淨營收與貢獻：扣除會隨訂單或服務增加的變動成本。
- 固定觀察窗：先建立 30、90、180、365 天累積貢獻，再決定是否外推。
- 同時看 LTV：CAC 與回本期：一個看長期空間，一個看現金回收。
- 預留留存、固定成本、利潤與風險：不要把整筆預測 LTV 交給獲客。
- 用成熟 cohort 回寫模型：每月比較預測與實際，超出誤差範圍就調整出價與預算。
最後，可承受 CAC 不是市場告訴你的固定答案，而是你的顧客價值、成本結構、現金流與不確定性共同形成的邊界。先把成本算完整，再把 LTV 從營收改成貢獻，最後用 cohort 檢查錢何時真的回來；這樣 CAC 才從廣告報表裡的一個數字，變成可以約束成長風險的決策工具。
SOURCE LOG