史上最全！不同階段計算LTV的方法和模型！

02-03

第一件事情是要問明白計算LTV的目的是什麼。如果你有一款基於免費模式的手游，那麼毫無疑問用戶終身價值就是該款遊戲的主要KPI。以下是原因：

在設計階段，先要做Benchmark分析，你需要估算跟你遊戲類似的LTV及他們的CPI，以確保項目能有足夠的投入預算。換言之，你需要先保證項目最後能賺錢。
當進入試運營（soft launch)階段，你需要測算並不斷優化LTV，以確保它能超過預期的CPI。
在市場推廣階段，你需要定位到CPI＜LTV的目標用戶群體，只要這個條件一直滿足，就應該不斷往裡面增加投入。

設計階段的「原始」LTV計算

遊戲發布之前是沒有真實數據的，只要一些假設數據即可。因此，你需要使用「原始」的計算方法，即簡單地將ARPDAU乘以單個用戶的預期生命時間即可。

舉例：ARPDAU * Lifespan = 0.05 * 26 = 1.3

分析

輸入：

ARPDAU
預期的用戶生命周期：用戶有可能使用APP的時間長度。可以基於其他app進行估算，或者追蹤用戶直到他不再出現在遊戲里

輸出：

預計每用戶的LTV

優勢：

簡單
有利於了解用戶LTV

劣勢：

方法太過簡單，且只假設所有用戶在同一時間內均留存
無法提前得知用戶會留存多久

試運營階段需要建造用戶留存模型

在試運營階段，你需要一個不同的方式。此階段的情況已經變了，因為你已經有了關於遊戲留存率和付費情況的數據。具體需要ARPDAU和至少下列的留存率數據：次日、7日、14日和30日。建造留存率模型是一個複雜的數學測試，它需要用到統計回歸、對數函數和積分運算。

計算方式

假設留存函數是 y=a*x^b的冪函數，其中x為使用天數，a和b是模型的係數。首先預估的是180天內的留存率。它使用了第2天、7天、14天、30天和180天的加權係數，加權值為：2.5、7、12、57.5、100（順序對應）。基於LTV公式的加權係數比在冪函數求積分更簡單，對於精確度的影響也沒有那麼大。當用戶生命周期計算好後，用ARPDAU乘以生命周期即可輕鬆計算出LTV值。

舉例：ARPDAU * lifespan = 0.155 * 9.02 = 1.40

分析

輸入：

次日、7天、14天、30天的留存
ARPDAU（前30天）

輸出：

用戶預期的生命周期：所有用戶的留存總和（用戶數 * 天數）
180天的LTV

優勢：

簡單
幾乎與更複雜的模型一樣準確

劣勢：

30天的留存率加權過重
以ARPDAU不變為前提進行的假設

市場推廣階段的細分LTV計算

當你的遊戲準備問世時，你將會對於終身價值的計算有新的需求。此階段與廣告投放和用戶獲取有關，目標就是讓LTV高於CPI。但並不是所有用戶都要滿足這個條件，只要找到某些指定的細分用戶滿足即可。當你找到這些細分，就可以「有的放矢」地加大投放力度。之前的LTV計算方法都是基於一個全新產品的假設，歷史數據是有限的。當來到市場投放的階段，產品數據應該在其中一個細分群體積累了6個月（一般指自然量）。基於現有細分群體的數據，就可以預估新的細分的LTV值。這個對於新用戶的計算方法需要對比前7天的新用戶和現存用戶基礎，然後將同樣的比率應用於現有的LTV。

計算方式

假設A項與B項7天的收益比率會反映其在LTV的比率。舉例，假如你有一個新的流量來源在前7天有0.5美元的ARPU，正常來說你能在前7天看到1美元，那麼新的流量來源就是你正常LTV的一半。這非常直觀，實際上改預測方法也被許多先進的模型支持。該計算方式有兩步：

算出7天內收益數據間的比率
將同樣的比率用到LTV中

舉例：7天內收益比率 * LTV = 0.95 * 2.5 = 2.38

分析

輸入：

現有部分的訓練數據（主要用來訓練LTV計算模型）
現有細分用戶的ARPU：第1天到第7天
現有細分用戶的LTV: 180天
新細分數據
新細分用戶的ARPU：第1天到第7天

輸出：

新細分用戶的LTV

優勢：

簡單
最準確的模式之一

劣勢：

需要現有細分的180天數據

高級LTV細分計算

第三種計算方式假設有180天的數據，而這有時候是不可能的。這時從現有細分的90天數據來建立現有細分的180天LTV模型，然後利用相同的比率方法來計算新細分的LTV。

這個計算方法的數據來自現有細分（如自然流量）來調整最初90天的模型，並利用模型功能來預估第90天到第180天的生命值。

計算方式

該模型有2個步驟

步驟1：估算180天的LTV

把最初90天的已知ARPU與91-180天的預估ARPU相結合即可得到。這個估算是用90天的ARPDAU乘以90天到180天的用戶預期生命時間。

步驟2：應用比例

當我們有預估的現有細分180天LTV數據，就可以用一個簡單的比例來估算新細分的LTV：

用新細分的7天ARPU除以現有細分的7天ARPU
將相同比例應用到現有細分的180天LTV
所得結果即是新細分的180天LTV

分析

輸入：

現有細分的訓練數據

現有細分的用戶ARPU：第1天至第7天
現有細分的用戶ARPU：第1天至第90天
現有細分的7天留存率
現有細分的90天留存率
現有細分的ARPDAU：第75天到90天

細分數據

新細分用戶的ARPU：第1天至第7天

輸出：

優勢：

更新的遊戲app也可以使用該計算方法
非常精確

劣勢：

有點複雜

如果你有新細分超過7天的數據，那你實際上可以使用任何日期的數據，只要你能將其應用到7天的現有細分和新細分數據里。

在現有細分的7天ARPU中輸入第N天的現有細分ARPU
在新細分的7天ARPY中輸入第N天的新細分ARPU

總結：

1.計算LTV的「原始」方法

ARPDAU * Lifespan。

2.生命周期計算模型（簡化版）

「原始」方法的缺點是不能算出預期的生命周期長度。計算的方法會有點複雜。你需要收集用戶在APP的留存數據，用上面的冪函數公式求積分算出來。當然，更簡單的方法是通過加權平均的方法進行估算（參考上面「試運營」的例子），而且結果的精準度並不會相差太遠。

3.類推法則：用現有的細分歷史數據類推新的細分用戶LTV

這個是很多遊戲公司採取的方法。它計算出現有180天的LTV，用新細分的7天ARPU除以現有細分的7天ARPU，得出來的比例應用到現有細分的180天LTV中，結果即是新細分的180天LTV。這樣，即使沒有180天的數據，也能通過現有細分的數據計算LTV。

這個計算方式融合了前兩種的技巧。即使沒有180天的數據，也可以利用現有細分的數據。這個計算方式使用了現有細分的部分數據來計算新細分的LTV。

等待至少90天的ARPDAU數據
使用該數據建立每日每平均用戶財務積累Master Chart圖表
計算90天內的流失率，將該比率應用到90日天之後的數據，得到180天的LTV，以此推算90天之後的Master Chart圖表走向
用現有LTV來估算新細分：用前7日新細分收益與Master Chart內的數據作對比

4.用數據表計算留存率模型、收益函數模型

此方法假設留存率是一個冪函數（y=a*x^b)，並且ARPDAU是恆定的。以下是關於該數據表的更多細節。

它假設收益函數是對數函數。表格示例圖如下：

手游開發者面臨的最大難題之一就是計算app的LTV。在網上搜索能查到很多答案，但大多數晦澀難懂。原因就在於建立LTV模型非常困難，尤其是在不了解用戶行為、數據不充分的情況下。本文推薦了幾種不同計算方法，開發者們可以根據自身具體情況做出合適的選擇。

關注「牛牛的社區」，回復關鍵字「LTV」，可以獲取文中的Excel表格源文件，了解具體的公式設置。

原文作者：YANIV NIZAN

本文由牛牛的社區編譯，轉載請註明

歡迎關注

微信：牛牛的社區

微博：北美牛牛社區

為您提供最前沿、最優質的北美移動互聯網資訊！