精選文章|

不同階段計算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模型非常困難,尤其是在不了解用戶行為、數據不充分的情況下。本文推薦了幾種不同計算方法,開發者們可以根據自身具體情況做出合適的選擇。

Leave a Reply

Your email address will not be published. Required fields are marked *

Close Search Window