[譯] 一文教你預測 app 將來的變現狀況

• 原文地址：Predicting your app’s monetization future
• 原文做者：Ignacio Monereo
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：PTHFLY
• 校對者：Wangalan30、realYukiko

一文教你預測 app 將來的變現狀況

預測分析法介紹以及用戶生命週期價值計算

咱們都想要一個魔幻水晶球，能夠揭示咱們的 app 在將來的表現：會吸引多少用戶以及會產生多少收入。遺憾的是，並不存在這種水晶球。可是好消息是，咱們有技術手段可使你有效的洞察你的APP將來的表現，同時幫助你創建一個合理有效的收入策略。

這是我關於探尋生命週期價值( LTV, lifetime value )兩篇文章中的第一篇。在這篇文章中，我將會介紹預測分析法，指出一個計算 LTV 的簡單公式，並闡述如何得到一個可用做計劃的數值。

在下一篇博文中，我將會探尋這個公式如何應用於五個時下流行的 app 的變現策略中，同時也會提供一些從開發者那得來的關於如何優化這些變現策略的看法。

預測分析法

若是你想了解你的 APP 的將來走勢，你能夠經過觀察從用戶那裏收集來的數據進行預測。應用各類統計學技術，從這些數據中提取信息，是預測分析法的主要內容。

預測模型被應用到了許多商業領域中，它們能夠幫忙解答許多關鍵性的商業管理問題：明年咱們將有多少付費用戶？明年的指望交易數額是多少？用戶何時會從咱們的服務中流失？

這些模型在線下被普遍研究。感謝數字革命，在改良的收集、整合和歸類用戶數據的能力的推進下，咱們得以見證它們正在變得愈來愈普及。

在移動應用的世界，遊戲開發者是這些技術的高級用戶，他們的使用對他們應用的變現有着積極的影響。

從經驗主義到數學模型的方法

預測會有多少用戶以及在將來他們的付費狀況的方法會很是不一樣。其中最特別的兩種是：

• 基於專業經驗或者標杆管理的簡單模型。例如一個公司僱傭了外部顧問，根據顧問的市場和行業知識，向他諮詢和預測下一年銷售狀況。
• 複雜數學模型，像是 Pareto/NBD 模型（能夠看 David C. Schmittlein，Donald G. Morrison，和 Richard Colombo 的 Counting Your Customers: Who Are They and What Will They Do Next?）。這些模型將多重變量歸入考慮範圍，包括近因（最近購買）以及給定時間內的頻次或者訂單數量，來計算客戶復購的可能性。

對於數學建模方法，有一些網上資源能夠幫助計算，例如這個由 Bruce G. S. Hardie 在 Implementing the BG/NBD Model for Customer Base Analysis in Excel中描述的方法。

分析所需的數據和工具

預測分析技術發展的主要驅動力之一是分析工具使用量的增長。強大的分析工具可使咱們更加高效地收集、整理和整合數據，同時迅速地將它與關鍵的利益相關者和決策者分享。

一些最重要的 app 特徵數據：Some of the most important app metrics are:

• 用戶得到數據: 安裝數量，卸載數量和來量渠道。
• 留存數據: 用戶留存（下載後第一、七、2八、90、180和365天）。
• 變現數據: 付費用戶數量，最近購買，交易頻次，購買總量，流失率以及新的重複購買用戶。

這些變量的重要性依託於其計算權重和如下這些因素：

• 應用環境: 不一樣種類的 app 的激活和使用狀況會有巨大的不一樣。
• 商業模式: 根據不一樣的商業模式選擇，某個關鍵數據會有巨大的影響。好比訂閱商業模式一般十分關心訂閱者的續期時刻。
• 使用手段: 一些方法將會要求某些數據來創建將來預測。例如使用 BG/NBD 要求頻次和最近購買數據。

需重點強調的是，一個強大的分析工具，如用於應用內分析的 Google Analytics for Firebase 或是用於變現的 Google Play Console ，不只須要可以準確及時地收集這些信息，同時也要可以快速處理和分享這些信息。這是在如數字生態系統這樣的動態環境中迅速作出反應的關鍵。

背景

預測分析法嚴重依賴於用戶和購買者的歷史數據。雖然這是一個好的起點，可是不要忽視可能影響將來預測的外部信息。這可能包括公司發展階段，科技趨勢和宏觀經濟環境。

尤爲是當分析 app 的生命週期價值的時候，根據環境因素，如交易環境和合同責任調整某些關鍵點，調整一些關鍵點是頗有用的。例如，一個零售 app 可能須要在激活一個月內的購買者和一年內的購買者之間作選擇。

有一些不一樣的框架能夠幫助識別這些背景因素。在這之中，我發現 Peter S. Fader and Bruce G. S. Hardie 的文章 Probability Models for Customer-Base Analysis 中指出的一個框架頗有用。

Fader 和 Hardie 的模型根據用戶是否與公司締結合同以及交易是連續仍是離散的來將用戶行爲作了區分。來看一個關於這個模型的例子：

左上角的是沒有與用戶締結契約關係來造成持續交易流的公司。一個實際的例子是電商應用，消費者反覆交易可是又能夠隨時離開和流失。

在右下方是個恰好相反的例子：公司與用戶締結合約，交易只在特定時間發生。一個實際例子是消費者每每在某個特定的時間點（好比他們找到第一份工做的時候）購買人壽保險單，這份保險單將在保險費的持續時間內保持有效。

生命週期價值

最後歡迎的預測分析法標誌之一是用戶生命週期價值（ LTV ），是最受歡迎的預測分析指標之一，它是用戶在一輩子中對其商業領域經濟價值的估算。這個指標在線下十分知名，被普遍應用到了 app 和遊戲產業中。

由於提供了每一個用戶帶來的潛在收益估計，LTV 十分有用，由於它能夠提供對每一個客戶潛在收益的解讀。相應的，這也能夠幫助決定用戶獲取費用，分析哪一個渠道、平臺、用戶分佈是最划算的。

然而，在討論計算問題以前，有一些常見的 LTV 陷阱須要規避。所以，請不要：

• 將 LTV 做爲目標使用而且花費資源來優化和放大它。僅僅把 LTV 當作一個工具，它會隨着其餘指標（如契約、留存和變現）的增加而提升。
• 創造過於樂觀的 LTV。例如，一個初創公司可能太高地估計了每一個用戶的收入，結果致使 LTV 膨脹，從而可能要在獲取用戶上花費更高的成本。
• 容許用戶獲取成本（CAC，the Cost of acquiring a customer）超過 LTV。儘管要考慮的因素（公司的階段：初創或是成熟；關係類型：是否締結合約）不少，但一個工業領域的經驗法則告訴咱們：用戶獲取成本不可以超過應用的淨 LTV。然而許多公司規定 LTV 與 CAC 的比爲3：1（CAC 將永遠不會超過淨 LTV 的33%）。
• 將高 LTV 看做是一個競爭優點。在快速變化的行業，好比科技行業，很容易找到一個變現能力很強，LTV 很高可是快速失去市場份額的例子，由於技術被淘汰，用戶轉移到更新、更有吸引力的應用上去了。

計算 LTV

有幾種方法能夠計算應用和遊戲的 LTV。這些方法根據商業模式的複雜度，可用數據以及精確度要求的不一樣而不一樣。

在一開始，讓咱們使用下面簡單的公式：

LTV (給定階段的) = 生命週期 x ARPU（每一個用戶平均收益）

如今，讓咱們仔細檢查下個變量：

a. LTV 時間長度

大多數開發者以 180 天，一年，二年或者五年計算 LTV。決定 LTV 時間長度的因素可能包括平均用戶生命週期或者基於商業模式的選擇。

例如，想象一個使用內購模式的開發者，平均一個用戶使用週期是15個月。在這種狀況下，兩年的 LTV 會比一年的更高。然而，一年的 LTV 是更保守的選擇由於平均生命週期（15個月）比選擇的週期更長（12個月）。

選擇 LTV 時間長度須要考慮：

• 商業環境， 例如，對於某些變現模型（尤爲是訂閱類）來講，收益可能會更高，並且，若是對變現的激勵得當，將在很長的一段時間內持續增加，這一點能夠爲長期 LTV 正名。舉例來說，電信公司一直遵循傳統，在用戶獲取方面大量投資，甚至會對硬件方面進行補貼，以期待較長的生命週期。
• 商業模式， 例如，對於某些變現模式（尤爲是訂閱）收益可能會更高而且會長期增加若是變現激勵很恰當（流失爲負），使用長期 LTV 是有道理的。好比電信公司在用戶獲取上傳統地會投資巨大，甚至會補貼硬件，須要超長生命週期。
• 公司階段， 好比早期對比成熟期。由於依靠技術進步或者沒有歷史數據，早期公司會常常選擇更長更樂觀的時期來計算 LTV。另外一方面，一個技術落伍的成熟公司可能想選擇更短的 LTV 計算時間。

b. 生命週期

生命週期與激活和留存直接相關。相應的，這兩個概念會幫助增長用戶留存，增長他們促進變現的可能性。應用開發者一般根據應用留存計算生命週期。

咱們能夠用一個簡單的方法來估算用戶滯留，咱們把用戶在過去的一個月內沒有打開過應用的狀況稱爲一個用戶在應用內的「流失」時刻。這樣，從用戶中止使用 APP 起至少一個月的平均流失時長就能夠計算出來了。

一個更精準計算生命週期的方法是使用生存曲線模型：一個根據歷史使用數據（每一個用戶或用戶羣一條曲線）的降低方程。每一個部分的總體或者平均留存就能夠被計算了，某個時期的方程也能夠被解出。

看下面的例子，在計算全部用戶的集合以後，一個用戶在180天后保持活躍的機率僅僅是 23%。所以，每180用戶平均生命週期會是 180 x 23%，將近 41 天。

這裏有個重點須要提示，生命週期老是和 LTV 時間段使用同一單位。例如 180 天的 LTV 會基於 41 天的指望生命週期，而不是月或是年。

c. ARPU 或者 每一個用戶的平均收益

計算 ARPU 的難度會根據商業模式的不一樣而不一樣。一個 SaaS 模式會更簡單而一個混合模式會更復雜（混合不一樣的商業模式，好比訂閱和廣告）。

一個計算 ARPU 的方法將會是將一段時間內的整體收益根據那段時間活躍用戶進行分割。例如，平均每日收益 10000 美金被 25000 日活用戶分割，ARPU 會是 0.4 美金/天。

我如今能夠爲這個應用計算 LTV 了。180天內的生命週期爲 41 天（ 23% ）而且 ARPU 0.4 美金/天。所以：

180 天的 LTV = 41 天 x 0.4 美金/天 = 16.4 美金/每用戶

優化 LTV 計算

有幾種技術能夠與這個簡單的 LTV 方程結合，以提高可用性，它們包括：

• Discount Revenue cash flows。當生命週期超過一年，經過將通貨膨脹速率（r）或者資金成本（好比計算平均資本成本率 —— 衡量平均資本成本）歸入考慮範圍來考慮給將來信息流打折。例如，假設生命週期是 n 年，折扣公式表現爲下面方式：

LTV = Revs Year 1 + Revs Year 2 x 1/ (1+ r) + … + Revs Year n x 1 / (1+ r )^(n-1)

• 計算淨 LTV. 經過計算每一個用戶的平都可變利潤(VC)並在公式中替換 ARPU，淨利潤可以被計算出來。爲了估計 VC，須要從總收入中扣除總可變成本。可變成本在每一個新用戶加入 app 時產生（例如分配到每一個用戶頭上的市場費用）。新的公式會像下面這樣：

淨 LTV = 生命週期 x VC

據此:

VC = 一段時間內的(總收入 — 總可變成本) / 一段時間內的平均用戶

還有一件重要的事情是：精明的開發者會一般根據 VC 水平區分用戶，而且爲不一樣用戶羣計算 LTV。 在許多商業活動中一般就是這樣，應用開發者會觀察到一小羣用戶會帶來最多的收入和利潤。

由於可變成本傾向於下降佔收入的比例，在用戶生命週期中 VC 會常常變化。舉個例子，拿一個最近訂購了一個軟件服務並在使用期間須要更多客服的新用戶與一個有經驗、再也不須要支持客戶做比較。

結論

預測分析法提供了一個可操做的方法來預測你的應用將來表現：它的用戶和收入。在這些預測分析的方法中，生命週期價值（ LTV ）多是最近在 APP 開發者中大受歡迎的一個指標了。它很是簡單而且提供了一個能夠應用於獲客規劃的有用方法。

如今你對 LTV 已經有了一些瞭解，在第二篇博文中我將會檢驗 LTV 公式如何使用於五個流行應用的變現策略。同時，我也會提供一些從開發者那得來的，關於如何優化這些變現策略的看法。

---

你怎麼想?

你有關於關於預測分析法和 LTV 的問題或者想法嗎？在下面評論區繼續討論或者經過井號標籤 #AskPlayDev 通知咱們，咱們會在 @GooglePlayDev （咱們會按期分享在上面就如何在Google Play成功的話題分享新聞和小貼士）上回復。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。