時隔三年，還想回來寫寫關于用戶成長體系的一些心得和經(jīng)驗。想想上一篇文章（傳送門：關于用戶成長體系，一份不能錯過的筆記）也是三年前的五六月寫的，看來五六月真是我產(chǎn)出文章的旺季呀…Orz…

上篇文章是在筆者還沒有深入致力于相關產(chǎn)品工作前整理的學習筆記，偏基礎入門。經(jīng)過歲月的磨礪和洗禮后，不敢說筆者已經(jīng)站在行業(yè)之巔（請大佬們繞過此路，不要停留，不要噴噴），但也有些更深入的思考和經(jīng)驗了，在此分享給大家。

文章主要包含幾個最常見也是最容易“誤入歧途”的問題：

1. 市面上這么多種成長體系的產(chǎn)品形態(tài)應該怎么選？
2. 用戶感知不到我設計的成長體系怎么辦？如何讓用戶從0到1？
3. 用戶成長體系就是為了活躍提留存的嗎？怎么判斷體系做得好不好？

市面上這么多種成長體系的產(chǎn)品形態(tài)應該怎么選？

上篇文章筆者指出，成長形式有13種，但看過《游戲化思維》這本書，加上筆者在職場上學習的金字塔原理（此處感嘆，MECE原則真的太重要了，建議大家都學習下）之后，發(fā)現(xiàn)自己啪啪打臉了。

實際上，成長體系應該只分為積分、等級、勛章這三種，其他成長值、經(jīng)驗值、身份認證、粉絲量等等都是以前面四種形態(tài)為本質(zhì)，或作為某種形態(tài)中的其中一部分存在的。這三種成長體系各有特點，適用的用戶類型也不一樣。

舉例，Keep就同時擁有以上三種成長體系。每種運動類型均有一個獨立等級幫助用戶記錄垂直領域的成長歷程，KG等級記錄整體運動情況并可以解鎖對應權益，專門針對認真運動希望完成“自我實現(xiàn)”的用戶。勛章主要是階段性的榮譽獎勵和趣味活動獎勵加強用戶成就感，本質(zhì)上降低了獲得成就的門檻和時間成本，適合新進用戶提高運動黏性。

卡路里幣作為Keep的積分通過運動或做基礎任務獲得，最終可以做商城里購物使用，主要促進消費交易，但目前該體系已經(jīng)在20年1月暫停發(fā)放，估計是要對積分體系的進銷做調(diào)整或者因為運營策略問題下線該體系了。

用戶感知不到我設計的成長體系怎么辦？如何讓用戶從0到1？

這里先補充一個知識點。用戶成長體系通常分為兩種：

• 一種是輔助型成長體系，即用戶做核心行為的同時順便升級；
• 另一種是產(chǎn)品型成長體系，用戶是為了升級榮譽而做核心行為的，有明確目的性，通常只有游戲產(chǎn)品能做成這種體系。

我們經(jīng)常喊苦覺得成長體系很難做，其實絕大多數(shù)都是在做前者的成長體系。因為用戶不是為了成長而使用產(chǎn)品甚至留存在這里的，所以無論是感知認可還是任務轉(zhuǎn)化都無法做得太強暴直接，太軟綿隱晦用戶又抓不到你的點。

筆者在做用戶等級的過程中也遇到過這個問題，花了九牛二虎之力做各種觸達能力和權益BD，最后發(fā)現(xiàn)新用戶和低等級用戶依然不知道等級是什么，而高等級用戶則早早就把該薅的羊毛都薅光了，只把我們當成綿羊圈。

經(jīng)過復盤和沉淀，筆者整理了幾個經(jīng)驗分享出來。

（1）自己先明確體系里最高分層的用戶是誰是怎樣的，把這個期望明確告訴用戶，并讓典型的模范用戶成為我們的發(fā)聲者。

道理很簡單，自己都不知道成長體系的終極形態(tài)是怎樣的，用戶就更不會知道了；自己知道了之后，還要告訴你的用戶們，讓他們知道目標是什么，產(chǎn)品期望的體系與真實實現(xiàn)的體系與用戶理解到的體系之間都可能存在偏差，所以不斷傳達產(chǎn)品理念很重要。而且這樣也更方便用戶理解中間的任務為什么是這么設計的，更好的情況還能讓他們給你揪揪BUG，告訴你這里有規(guī)則漏洞要優(yōu)化一下。

而已經(jīng)成為典型模范的用戶，則要加強他們的歸屬感和責任感，讓他們發(fā)揮作用，在某些平臺自己也無法客觀表態(tài)的時候讓他們代表發(fā)聲，在需要維持產(chǎn)品生態(tài)的時候讓他們幫忙糾錯糾壞人，在需要拉新促活搞活動的時候讓他們幫忙傳播搞氣氛。這些典范用戶一半是用戶角色，一半也是平臺伙伴角色，經(jīng)常能在中間起調(diào)劑和促進作用。

（2）糾正觸達所有用戶的錯誤心態(tài)，只在合適的時機觸達有效的用戶。

在下文中其實會講到，其實用戶成長體系并非覆蓋越多用戶越好。這就好像拉新一樣，拉新用戶增多了，整體留存質(zhì)量必然會有所下降，因為濫竽充數(shù)的人也進來了。

所以最關鍵的，還是找到你的潛在目標用戶（能力符合），在合適的時機（觸發(fā)器恰當），用合適的動機誘餌（動機充足）引導或者教育他們。而且盡可能在體系頻道外完成觸達引導，因為用戶并不會主動進入你的成長體系頻道頁。

筆者在工作中也整理了比較完整的全鏈路觸達交互場景，干貨來了，見圖。

一個產(chǎn)品最終是否需要用戶成長體系，除了看業(yè)務特征之外，也需要考慮用戶成長體系本身可提供的作用是什么。而且用戶成長體系之間并非非此即彼，當產(chǎn)品相對復雜，用戶群體大且多樣時，它們也有可能是同時存在的，于是形成了矩陣。

（3）降低門檻，加強成長榮譽感，讓新用戶和低級用戶盡快享受權益。

最后一點，如何讓新用戶和低級用戶快速了解成長體系并開始成長。這里需要排掉一個雷坑，很多同學會認為讓用戶認可成長體系的價值就是讓成就門檻變得更高，用戶得不到就會覺得這樣東西越有價值，于是設計了很高的等級門檻，或者拉長領取積分的鏈路來達到這一目的。但實際上這樣做是錯的。成長體系的價值是通過用戶享受體系本身帶來的榮譽或權益體現(xiàn)的，提高門檻只會讓用戶望而卻步。

所以這里可以看看游戲產(chǎn)品的做法，新用戶通常注冊賬號后先有一個入駐成功的成就勛章，或者以一個非常低的門檻，馬上就能達到第一等級，同時會使用酷炫的動畫效果或者有感染力的文字渲染榮譽感，讓用戶立即達到興奮點。

在用戶沒有預期的情況下，再給予一些能體現(xiàn)產(chǎn)品價值的權益，既能提高用戶滿意度，又能自然地引導到產(chǎn)品功能的使用。當然了，權益本身最好還是圍繞體系的目標去設計，能讓用戶快樂的同時多做一次任務就更高級了。

用戶成長體系就是為了活躍提留存嗎？怎么判斷體系做得好？

筆者在之前的文章里提到，設計成長體系前需要先確定運營目標到底是拉新、留存、活躍還是流失挽回?，F(xiàn)在回頭一看，感覺筆者的說法太流氓了。請問哪個運營狗不是在為這幾個目標而獻出稀疏的頭毛的？這不廢話嗎？而且這個目標即使選出來后也太空大虛了，無法指導策略落地（譬如你的任務設計、權益設計）。

正經(jīng)回來，真正賽高的用戶成長體系都一定是圍繞某個業(yè)務目標而設計和存在的，譬如B站是優(yōu)秀創(chuàng)作者的數(shù)量和優(yōu)秀內(nèi)容的數(shù)量，譬如微淘是直播帶貨GMV，譬如動物之森是游戲玩家的生命周期長度（這些都是筆者亂編的，別當真）。基于這個再去設計體系模型、任務和權益的時候就清晰得多了，也不容易跑偏。

不同類型的產(chǎn)品或一個產(chǎn)品的不同發(fā)展階段，他們的核心業(yè)務目標都有可能不一樣的。也就是說，一個用戶成長體系的運營目標也并沒有標準答案，甚至還是變化的（所以過個一年半載老板要求改版換目標的請擺正心態(tài)）。所以請大家在設計之前一定想好這個問題的答案，再動手設計，這和上文提到明確高分層用戶到底是誰其實是一脈相連的。

確定好運營目標后，衡量體系做得好不好的方法也就不言而喻了，分別三個步驟：

1. 體系好壞首先還是看對業(yè)務目標的達成情況，即產(chǎn)品或業(yè)務的北極星指標。北極星指標通常有“反應產(chǎn)品核心價值”、“反應長期商業(yè)目標”、“反應用戶活躍程度”、“簡單直觀”、“先導不滯后”的幾個特點。
2. 如果發(fā)現(xiàn)單一指標不能體現(xiàn)全面的運營情況，可以加入一個反向指標作為“制衡指標”，譬如電商可以看退貨率、公眾號可以看原創(chuàng)率等。
3. 除了業(yè)務終極目標外，一定不能忽視成長體系本身的健康度情況。通常兩個原則，“易于上手，難于精通”以及“可持續(xù)發(fā)展”。對應到數(shù)據(jù)指標上，則是體系里用戶分層的分布占比（積分指不同的積分擁有消耗情況，等級指用戶等級，勛章指擁有不同勛章數(shù)量的用戶分層）、各分層的流動情況以及最高層的活躍度等等。這里展開再說一說。

雖然升級速度、擁有勛章人數(shù)等這些表象數(shù)據(jù)不能作為體系的北極星指標，但他們依然重要。因為體系一旦出現(xiàn)健康問題，會比其他一切運營難題更難解決。

一方面，為了調(diào)整健康度改變舊規(guī)則很容易讓老用戶感覺不公平，引起民憤四散而逃；另一方面，即使成功調(diào)整舊規(guī)則，老用戶已經(jīng)擁有的成就也無法收回，諸如“高等級不再活躍”、“勛章泛濫”的問題要很長一段時間才能逐漸緩解，這時候你的產(chǎn)品價值早就被稀釋成白開水了，用戶不買賬，金主爸爸也不買賬。

所以體系的健康度情況一定要保持周期復盤，及時發(fā)現(xiàn)變壞的苗頭，及時止損。筆者自己踩過這樣的坑，成長體系過于簡單和過于困難的極端都走過，希望前車之鑒，大家別追。

作者：豆丁，努力成長的野生產(chǎn)品經(jīng)理。歡迎關注和私信，筆者會努力回復的。

本文由 @豆丁 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自unsplash，基于CC0協(xié)議