聲明：本文來自于微信公眾號見實(ID：jianshishijie)，作者：見實，授權轉載發布。
今年 8 月，見實曾做過一次小范圍的調研，問題很簡單：作為管理者，下半年最關注什么?
大部分人的回復也很簡單：賺錢。但賺錢背后，永遠都繞不開另外兩個字：增長。
不少公司經常都把各種增長模型掛在嘴上，但真正去實操時，才發現這些理論實踐起來很難達到實際效果。
這不僅是由于理論到實踐的鴻溝不易跨越，還存在很多業務人員無法直接解決的技術難題。
正如火山引擎數據智能解決方案總監孫超赟所講，用戶增長就像一座輝煌的宮殿立在山巔，等著我們去朝圣，去進軍。但在去往宮殿的路上，并不是一片坦途。這一路上會有很多坑，坑里還有水，水里還有釘，總是趟不完。
因此， 9 月 8 號的見實大會上，見實將孫超赟請到了大會現場，他的分享簡單干脆，直截了當地說清楚了，火山引擎如何幫業務人員解決其數據運營過程中遇到的各種坑。
現在借助文字實錄，我們不妨回到大會現場，聽聽孫超赟講到的運營痛點和具體解決方案。如下，Enjoy：
大家好，我今天分享的主題是《技術驅動下的品牌業績增長》。
理論很簡單，現實很骨感
我個人是技術出身，在學技術的時候，很多專業書籍的名字都叫《深入淺出xxx》。今天也用深入淺出的方式，跟大家分享一下數據驅動下的用戶增長。
我先舉個大家都比較熟悉的增長模型。當我們提到“用戶增長”時，腦子里會蹦出很多概念，最先出現的可能是上圖中的AARRR漏斗模型，通過這個模型可以評估出用戶不同的生命周期和階段。
step1. 引流是用戶增長的源頭活水，我們會注重高效投放，精準引流;
step2.轉化是用戶增長的核心，要讓用戶快速領略產品核心價值;
step3. 留存是用戶增長的堅實基礎，不斷在流量池中沉淀用戶的企業才能做大。我認為用戶留存始于價值，久于習慣;
step4. 變現是用戶增長的業務目的，很多時候可以嘗試在小程序內變現，除了用戶本身以外，不要忽略廣告流量也可以變現;
step5. 自傳播是用戶增長的持久動力，不能一味靠自己拉新，還要充分利用用戶的社交屬性來實現自增長。
比如，疫情期間，ZOOM就將用戶的社交屬性用到了極致，因為大家一旦開會就會自主下載ZOOM軟件，并且不斷的影響更多的用戶使用ZOOM。
上圖也是一個可落地實操的方法論，可用在用戶的生命周期里的任何階段。
內環是我們的行為，外環是我們的收獲。
通過分析可以得到業務和用戶的洞察，通過決策可以得到業務發展的策略，通過做A/B測試、觸達和精準運營，并將評估結果產品化。
我舉一個具體的案例，大家可能更容易理解。下圖是我們的一個社交類產品的客戶，用戶注冊的路徑為：下載APP-啟動APP-選擇注冊方式-手機驗證-填寫個人信息-注冊成功。
在分析階段，我們發現從選擇注冊方式到注冊成功的關鍵路徑中，漏斗突然變窄，這意味著用戶在這一階段大量流失。
為什么?因為軟件默認首選的登錄方式是微信登錄，但使用微信登錄后仍需要強制用戶綁定手機號，這讓用戶有種被忽悠的感覺。他們會認為，該軟件先獲取了自己的微信信息，還想繼續獲取自己的手機號信息。
接下來，我們的決策為：是否可以直接用手機號來登錄?通過對A/B實驗的對照組評估，發現其轉化率遠高于之前。因此，我們開始將實驗組的結果推廣到所有產品上，做全流量鋪開。
這么講，好像用戶增長還還挺簡單，用戶增長就像一座輝煌的宮殿立在山巔，等著我們去朝圣，去進軍。
但對不起，在這里我要給大家潑一盆冷水，因為真正去落地的時候，大家會發現，在去往宮殿的路上，并不是一片坦途。這一路上會有很多坑，坑里還有水，水里還有釘，總是趟不完。
用戶增長之路上的那些大坑
現在，讓我幫大家回顧一下，我們經常使用的各種平臺工具，都有哪些痛點?
第一，先看一下用戶分析工具。
其業務目的是通過數據還原事實真相。比如用戶的行為路徑或流失原因等。而最大的痛點就是做埋點，因為業務方和技術方在這里會有一個天然的矛盾。
業務方如果想深度分析各個細節點，埋點就一定要精細;但對技術部門來說，精細埋點就意味著要耗費大量的人力，這會嚴重影響到其他的工作進度。
但如果不投入技術人員，做全埋點或無埋點，就會使得業務人員非常痛苦，他們需要通過各種抽絲剝繭的方式，尋找一些自己需要的業務數據。
第二是A/B測試。
曲卉老師的書里會提到，如果要做增長，一定要做大量快速迭代的A/B測試，其中，A/B測試是前提條件。其業務目的是什么呢?主要是通過小流量的先驗，來保證決策的正確性或找出最優解。在這種情況下，面臨三個痛點：
01.分流。因為分流姿勢不對，全部努力白費。比如，有的企業通過用戶ID尾號奇偶性做分流。從極限理論上看，奇數和偶數占比各一半，仿佛是沒有問題的。
但是一方面有多少企業的數據已經積累到了這極限的邊界;另一方面，用這么多數據來做A/B 實驗，那就更談不上小流量先驗了。我們還遇到過一些看似“高級”的分組方式，其實都不太嚴謹。
那么大家一定想知道，我該如何判斷自己的分流是否科學?給大家提供一個最簡單的方式：不要做A/B實驗，而是做A/A試驗。如果分流科學，那么A/A實驗的結果是幾乎沒有偏差的，可以用來做自驗。
02.置信度。可以簡單理解為，如果把這個事情再重復做一遍，有多大概率能拿到同樣的結果?我們做A/B實驗，置信度就是讓我們把結果推向全部產品的保證。
比如，我們看到在置信度95%的前提下，實驗組比對照組的提升是(10%-20%)。怎么理解呢?就是我們把這個實驗再重新做 100 次，那么有 95 次的結果，實驗組對比對照組的提升會落在(10%-20%)這個區間之內。
03.發布。現實中，我們可能會遇到直接發布產品后，才發現技術或體驗上的問題，不得不回滾到舊版本的情況。
但如果App 是在蘋果商店發布的，就需要等7- 10 個工作日，最后的結果是引起用戶負面體驗，包括用戶的流失。
最理想的狀態是逐漸迭代發布，按照10%、30%、50%的節奏，做小流量的分布。
第三是智能運營平臺，業務目的就是“四個正確”。
即在正確的時間，通過正確的渠道，把正確的內容，發送給正確的目標用戶。進而來保證用戶體驗，促進用戶增長。這里也有三個痛點：
01.多觸達通道管理混亂。比如，觸達通道包括站內信、APP push、短信和公眾號等。這么多通道哪個更好?即使只做APP push，仍不知道哪個第三方工具或平臺更合適。
02.觸達時機，重口難調。有的企業會優先選擇早上推push，但有的用戶是做公共交通，還有的用戶是開車，遇到堵車完全沒心情看任何信息。如果解決不了觸達效果，就會遇到運營的“三多兩少”問題，即投入多，觸達多，用戶負面反饋多，但召回和轉化都很少，運營效果不顯著。
第四是用戶數據平臺，就是所謂的CDP，現在很多企業都嘗試在做。
CDP的業務目的是一切分析和精細化運營的業務邏輯基礎。什么是業務邏輯基礎?里面的用戶分群是從業務視角創建的，使用過程中不是簡單看一下用戶分群有哪些。需求會非常多變，會需要實時調整。
如果沒有一個好的工具在這里做支撐，底層的數據準備，也就是跑數據的需求，會非常困難。
通常，跑數的需求會提交給技術部門的兄弟，對方的回復可能是，這項工作排期要到一周后才能拿到結果。過程中如果需要小的調整，又需要再等一周。
這就暴露出業務人員的一個痛點：嚴重依賴技術部門，跟技術部門溝通起來很復雜，還要被他們的工作排期所制約。技術部門同樣痛苦，因為這也會增長他們的工作負擔，影響其他工作內容的推進。
以上，是業務人員在做用戶增長過程中，可能會遇到的各種困難。做用戶增長，就像是看到一座輝煌的宮殿，但要到達宮殿就需要經歷九九八十一難。
是不是要絕望了?悲觀的人往往正確，樂觀的人往往成功。大家千萬不要氣餒，接下里，我會分享一下火山引擎是怎么幫助客戶克服這些困難的。
火山引擎怎么做用戶增長?
首先，我們會將企業團隊使用的相關產品進行底層拉通，在企業內形成多個工具相互協作的解決方案，你中有我，我中有你，最終實現1+1> 2 的效果。
第一，底層架構的一致性。有什么好處?
很多公司內部做用戶增長會遇到“混布”的問題。簡單的講，就是多個工具之間底層結構和版本不兼容，但又不想準備兩個集群，那么就要把這些平臺強行部署在一個集群上。其部署成本和運維成本都不可控。
火山引擎的底層是拉通的，所有工具類平臺都可以和諧地搭載于一個集群上，運維環境單一，硬件成本和運維成本都顯著降低。
第二，多平臺的整合性。
怎么理解?舉個例子，比如一個新家剛裝修完，有人買家具時會選一個大品牌，把所有柜子、床都買全，追求品牌整合。
01.在火山引擎的所有功能中，產研側會以功能區分，從功能角度拆解，不會出現功能冗余和“三不管”的情況，每個功能都只有一個，且都能找到可對接的團隊，完全滿足MECE原則。
02.業務側從場景出發，保證場景的完整性。比如，用不同版本文案做觸達時，怎么選?我給大家一個簡單的辦法，對業務人員來說，在觸達場景里嵌入A/B測試功能，就能保證場景的完整性。
03.用戶權限統一管理。比如，一些大公司總部下面有很多大區和加盟商，他們對數據的可見性要求極高。
當我們所有工具類底層拉通，從組織架構出發，就能對所有的數據指標和運營活動進行靈活設置，保證業務數據的可見性且相互隔離。
第三，數據統一性。
首先多場景的數據聯動，可以解決“數據孤島”的問題。“數據孤島”方面，我用一個商品的廣告語來總結：“通則不痛，痛則不通”。如果業務人員使用的數據是割裂的，就會很痛苦。
在火山引擎中，我們辛苦建立的數據指標，技術同學辛苦采集上來的業務數據，可以不再只應用于一個場景。比如，不僅可以做用戶行為分析，還可以用于A/B測試、智能觸達、智能推薦等，讓所有上層應用都使用起來。
打個比方，你的業務就像是一座新建起來的房子，用戶增長平臺就是整個房子的硬裝，而在用戶增長過程中所使用的各種策略和方法論，就是整個房子的軟裝。底層有好的硬裝，才能保證上層的軟裝發揮更好的作用。
火山引擎的整體架構
這張圖，是火山引擎的整體架構。前面提到，底層數據是可拉通的，所有數據在底層都可以統一管理。
往上一層有各種工具類，可以做數據分析、優化、A/B測試和用戶管理等，最上層是內部增長團隊可提供的咨詢類服務，屬于更為高階一些玩法。
以上就是我的分享內容，現場分享時間有限，一些深度內容可能無法展開，我們可以在會后進行更為深度的溝通和探索。
