對于我們做産品的人來說，最痛苦的點，可能就是産品做出來之後，被客戶噴“使用繁瑣，體驗太差”，被老闆DISS“你的産品切不到痛點”;，誠然一個産品好不好，不能憑産品經理的個人喜好，也不能由于極個别用戶的負面反饋，而對産品進行全盤否定，我們更多需要根據大量的數據反饋，同時結合常識來進行判斷。我們從産品入行的時候，就被行内大咖教育，做産品要做“剛需、高頻、痛點”，但是卻從沒有人去告訴我們，如何通過觀測數據去驗證我們做的東西是否是滿足這三個核心要點，本文旨在幫助産品經理們建立較為完善的數據指标評估體系，更好地幫助産品功能的優化和疊代。

首先請容許我按照自己的理解，重新對“剛需、高頻、痛點”的做些定義：

①剛需是相對于“彈性需求”而言的，從字面意思就可以理解為是硬性，人們需要的東西或者必須要做的事。

②高頻則是指需求欲望在一定周期内産生的頻次。

③痛點則是指用戶在滿足自己需求的過程中，遇到的最大障礙。

那麼評估指标怎麼定？主要就是下面這一句話：

剛需看滲透、高頻看人次、痛點看能耗

一、剛需看滲透

滲透率原本是市場營銷中的一個概念，指企業的實際銷售量在市場潛量中的百分率。但是我們可以将的使用範圍進行衍生，大到行業覆蓋度，小到産品中的某個功能特性：比如互聯網滲透率是指使用互聯網的網民與總人口數之比，用于表達互聯網滲透到普通民衆生活的程度。而對于某個app的産品來說，我們提出一個新的概念叫做“功能滲透率”，是指當前使用該功能的人數占整體使用産品的人數比例，這個指标可以較為客觀的反應出，當前功能對于使用産品的人群的覆蓋度，功能滲透率越高，則說明該功能是用戶當前使用産品的核心功能，也即在當前産品形态下的大部分用戶剛需。

以一款教育app為例，這個産品中主要包括看資訊、聽課程、做題庫等産品特性，相關的産品功能滲透率如下：

從數據中我們就不難發現，10個人來使用該産品，7個人看資訊，2個人聽課程，1個人做題庫，看資訊這個功能點能覆蓋到大部分的用戶。而對于一款教育産品來講，其最終目标是幫助用戶拿證過題考試的，所以這個數據結果其實乍一看是反常識的，我們大部分人會認為結構化的課程才應該是用戶最需要的内容及功能，有些颠覆我們的認知，然而是什麼原因導緻的，我們就需要進一步做些反思了，有可能是功能剛上線，知悉的用戶數量不多，也有可能是上線運營乏力，還有可能是内容不夠給力，又或者是産品交互體驗不行，技術老是出bug等，這些都需要進行具體的下鑽分析。

同時我們還需要注意以下幾點：

①滲透率的數據可以幫助你驗證你設計的需求解決方案，是否被大多數用戶所認可，而不能判定說滲透高的就是剛需，滲透低的就是普通需求，剛需與否還是需要通過産品經理對業務的洞察去判斷，滲透率更多的是以“後驗性”指标而存在的。

②剛需是根據用戶完成的業務目标所達成的任務而定的，離終點越近的越是剛需，我們可以根據用戶的需求層次畫一個同心圓，從裡到外由強變弱。還是以教育類app為例，可以得到以下的圖解：

總之如果數據展示出來，發現理想和現實中有落差，那我們就要不斷找原因，不斷調優，持續逼近理想的最優解。

二、高頻看人次

人次是指用戶在一定時間、一定範圍内重複出現的行為次數。對于我們日常的生活來說，普通人可能一輩子就買一次房，十年去換一部車，他們在人生的尺度上其實是個低頻的，但是在你要買車的前三個月的時候，你選車的需求被激發，每天看各類購車資訊的行為又變成了短時間的高頻需求了，所以這裡必須強調它是一個相對的概念，我們不能脫離場景去說這個。

我們來看一個支付寶的經典案例：

逆襲的工具型産品-支付寶

2003年的時候，支付寶僅僅隻是淘寶的一個子功能，作為網上交易的信用擔保工具；

2004年末，支付寶開始逐步從淘寶體系中分拆，成為了一個的獨立的第三方網絡支付平台；

2008年，支付寶發布移動電子商務戰略，從PC端業務開始往移動端遷移，推出手機支付業務，同年公共事業繳費正式上線，支持水、電、煤、通訊等繳費；

時至今日，支付寶已經不斷的擴寬它的使用場景，支付寶及其本地錢包合作夥伴已經服務超12億的全球用戶，俨然成為我們手機裡面的超級工具app，就算我們不是每天都去淘寶網購物，生活中的線下支付每天也必然會使用到1次或多次支付寶，可能是點外賣，可能是便利店的結算，又或者是公交車刷碼；

支付寶的發展史就是低頻的工具型app最好的逆襲，不斷的滲透到各個可以使用到支付的場景中，網上購物也許是個低頻的場景，但是線上線下的各類交易中的支付就是一個高頻的場景，每天全世界各地都在發生着各種交易，小到在學校門口買2元錢的汽水，大到購買萬元的筆記本電腦，這些一旦全部聚集在一個平台上進行操作，那将是一個非常海量的數字，這其實就是為什麼現在有很多工具型app在瘋狂的疊加場景化的功能，其實目的也就是在于“集低頻為高頻”。

那如何判斷我們做的功能中哪些是低頻哪些是高頻呢？我們還是以剛才的那款教育app為例，需要注意的是不同功能在相同的時間區間裡面，它們的頻次是不一樣的，同樣一個功能在不同的時間區間裡面，按天看、按周看、按月度看，頻次也都是不一樣的，這款app主要提供看資訊、聽課程、做題庫等産品特性，相關數據如下：

所以我們從上面數據中會發現，資訊是個高頻的功能點，而課程和題庫是低頻的，同時還會發現一個有意思的趨勢，一般而言越是高頻的功能點，随着時間跨度變大，它的人均頻次的增幅越快，越是低頻的功能點，它的人均頻次的增幅越慢，當然也有一些特例。所以如果産品中希望把課程和題庫的人次也提高的話，可以考慮把冗長的課程，拆分成一個個小的知識點-短視頻進行播放，把動則百八十道題目的題庫，拆解成每日一題的低門檻任務。

總之如果你的産品切中剛需但低頻的需求話，可以考慮以下2種方案去提供使用人次：

①集低頻場景為高頻場景

②低頻場景前置或拆分轉為高頻場景

三、痛點看能耗

開篇已經提到痛點是指“需求被滿足過程中，行為路徑上的最大阻礙”，而在這條達成任務目标的道路上，我們一般都會付出3樣東西“體力、腦力、心力”，這三者的付出加在一起就是我們完成任務的一個整體能耗了。

①體力一般是指用戶完成目标付出的實際行動，諸如在app中完成注冊操作，要輸入手機号、驗證碼等，做飯時要先洗菜，切菜，炒菜等過程，這些每一步的完成，最後才指向用戶最終完成任務的通路。

②腦力一般是指用戶對達成目标的思考，思考是要花費能量的，思考的時間越長，花費的能量就越多，所以我們可以通過檢測用戶完成任務時在一些頁面的停留時長的合理性來判斷，我們的産品是否給用戶造成了困擾，使他确實是感覺不知所雲了。

③心力一般是指用戶調動和控制情緒的耗費的能力，正向的情緒基本不耗費能量，使人感到輕松，而負面的情緒，則使人感到不适，諸如郁悶、疑惑、焦慮、憤怒等情緒。

所以無論是體力、腦力、心力其實歸于本質來說，都是在消耗我們自身的能量，人的一切動作其實都符合最小作用力原則，也即“能不動手就不動手，能不用腦就不用腦，做人最重要的就是開心囖”，這個是人性所緻。所以如何解決痛點，其實就是讓用戶較小的消耗自身能量。

下面再來說說關于三力的消耗如何用數據去進行評估，我們依然以app為例：

①體力的消耗我們一般可以記錄用戶在app中完成任務的交互步數，跳轉的頁面個數等，如果想做到更加精細化，甚至可以統計用戶點擊任務中每個按鈕之間的鍵程長度以及點擊的次數等，但是這個取決于公司用研的投入産出比了；

舉一個大部分app的通用案例-登錄注冊：

用戶首先進入app之後，跳轉到引導頁，然後注冊頁面，輸入手機号，獲取驗證碼等等，但是其中用戶還會碰到各種問題，比如手機号輸錯，驗證碼獲取延遲，驗證碼輸入錯誤，密碼設置不符合平台規則，手機号被注冊過等等，這些無形都會使得用戶完成任務的步數增加，體驗下滑。操作步數一般是由于産品設計以及業務本身屬性影響的，所以在交互路徑優化時，需要注意在用戶走到彎路的時候，及時給予提示，或者将問題直接化解，比如有些app在注冊時，直接獲取手機的本地手機号，這樣就避免了手機号輸入錯誤的尴尬了。

一般來講，用戶不會全部都按照我們理想化的行為路徑去進行操作，中途會遇到很多用戶的跳失。所以大部分情況下會是下面一個情況：

任務達成的用戶的平均交互深度>平台設計的最短交互路徑深度>流失用戶的平均交互深度

這基本是一個恒定的不等式，我們隻能努力通過産品的優化，讓兩端的大于号都無限趨近于等于号，才能達到較好的用戶體驗。

②腦力的消耗我們通常可以通過完成任務的時長來進行判斷，或者更準确的說是用戶的業務處理時長，這個要把用戶完成操作之後系統的響應時長給排除開。

業務處理時長是因人而異，因事而異的，有些人業務熟練，就能很快達成，有些事較為複雜，就需要花費更多的時間，這種更多被主觀因素的影響，所以我們大部分時候看人均時長，看新老用戶的人均時長，然後再看時長的整體人群分布比，來評估任務整體完成耗時水平的差異，從而想辦法去做進一步的優化。

比如現在市面上的一些app産品進入之後，新手就會看到一層半透明的蒙闆層，去引導你怎麼去玩轉裡面的功能，這個其實就是在幫助用戶快速上手，不會去滿屏幕的找入口，重要的事情說三遍"不要讓用戶想，不要讓用戶想，不要讓用戶想"，讓他跟着你設計的洋流漂洋就好。

③心力的消耗目前我們很難有很直接的定量指标，大部分隻能通過用戶的對每個功能點的定性反饋來評判了，我也很期待未來手機app可以記錄用戶的表情變化，給臉部的表情進行識别和打分，那麼就可以實時同步了情緒變化了，來判斷用戶是否遇到了困難或者不開心了，進而可以定向的去優化，當然未來技術成熟，可能法律法規依舊是不容許的，所以大部分的時候，這一類檢查隻能做一對一的焦點小組訪談了，很難做到大數據的采集分析。

但是我們依然可以通過一些常識性的體驗，找到評判的方法，比如我們使用app時突然的閃退，打開一個頁面時等了10多秒，購買産品付款時提示我餘額不足等，這些都會給我們在完成任務時帶來糟糕的體驗。所以我們可以把這幾個大緻分為3類：

（1）第一類是錯誤類，包括網絡報錯，加載失敗，APP端閃退崩潰等；我們可以把的各類錯誤的影響人數，以及影響次數作為核心指标進行衡量，比如報錯的接口名稱、操作系統、網絡狀态等都是常見的下鑽維度。

（2）第二類則是時效類，比如加載時長，審核時長，後端的接口返回時長等；我們可以把一些關鍵頁面的平均加載時長，重要接口（被頻繁調用）的返回平均時長作為核心指标進行衡量。

（3）第三類則是業務類，比如驗證碼輸入有誤、手機号被注冊、優惠券不能使用等；我們可以把用戶在完成任務中，返回的各類業務提示進行統計分析，來看看通常用戶在走到那一步給卡殼了。

四、最後的結語

産品能不能做起來，取決的因素有很多，戰略方向、競争格局、服務質量、産品體驗、運營活動等都會影響産品的成敗，希望本文能夠幫助各位産品經理大大們建立自己的數據體系，帶上度量标尺，更好前行。

最後如果看完後，啥也不記得，請記住這張表，期待大家能做出讓用戶、公司、自己滿意的三赢産品。

作者： 囧囧有神

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!