不同階段計算LTV的方法和模型大整理
什麽是LTV LTV(Life Time Value)-用戶生命價值:即用戶的終身價值,是指用戶在生命周期中貢獻的總毛利潤的平均估計值。
第一件事情是要問明白計算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天
輸出:
LTV
優勢:
更新的遊戲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模型非常困難,尤其是在不了解用戶行為、數據不充分的情況下。本文推薦了幾種不同計算方法,開發者們可以根據自身具體情況做出合適的選擇。