本文作者曾將一個「非電商類產品」的整體轉化率提升了1倍以上，本片文章總結了作者當時所實踐的方法，B、C端產品通用，與大家分享。（電商產品在這方面也可以看作是一種特例，也可以應用此方法）。

關于轉化率的重要性，這里不再贅述了，相信點開文章的你一定了然于胸。

提到轉化率提升，自然少不了用戶細分、漏斗分析。

雖然網上也有不少關于漏斗轉化分析的討論，但較多的是討論如何做漏斗分析，對于如何去落地實踐落地，尋找提升轉化的方法，目前討論的還相對較少。

同時，多數討論集中于電商產品，非電商類產品討論相對較少。

電商類產品由于其自身屬性的特殊性，其頁面訪問漏斗和用戶決策漏斗整體上匹配度比較高，優化起來方向也相對比較明確些。

但對于非電商類產品，使用一般的頁面訪問漏斗來分析優化產品，可能就沒有那么輕松了，下文會具體闡述。

本篇以非電商類產品為例，著重于討論如何結合「用戶決策模型」，通過系統化的方法，高效的去提升產品的轉化率，重點闡述實踐落地的方法。

整個方法可以拆解為以下4步，本篇將側重于第2、3步的介紹：

1. 尋找北極星指標
2. 關注用戶決策漏斗
3. 關注用戶決策模型
4. 灰度發布 + A/B Test 驗證方案有效性

01 尋找北極星指標

北極星指標也叫唯一關鍵指標（OMTM，One metric that matters），是產品現階段最關鍵的指標。

它應該是與業務高度相關、且能直接衡量產品價值的大小，也就是可以衡量產品策略的優劣。

類似于GMV，人均毛利率等這種指標。北極星指標不一定是一個，但不宜過多。

關于北極星指標的選取，網上討論文章很多，這里不再重復造輪子了。

我們需要結合自身的業務，選取符合自身業務的北極星指標，用于評估我們的產品改進是否正向。

北極星指標也就是我們最終需要去提升的轉化率指標。

02?關注用戶決策漏斗

所謂用戶決策漏斗，即是用戶在你的產品上完成最終目標之前，需要依次做出的子決策漏斗。

關注用戶的決策流程漏斗，能幫助我們更好的找到方向。

其與傳統頁面訪問漏斗的主要區別在于，頁面訪問漏斗的關注點在產品自身，而用戶決策漏斗的關注點在用戶。

哪個更加有效，不言而喻。

這里我們以房產租賃類平臺來舉例說明，這類平臺一般線上不涉及到具體交易，大多終止于電話咨詢環節。

1. 我先來看看傳統的「頁面訪問漏斗」，大致是這樣的

這個漏斗的缺陷至少有以下兩點：

1）當我們過度關注頁面訪問漏斗時，容易陷入到對當前漏斗各個環節的優化，忽視了對漏斗自身進行優化。

有時候產品流程本身設計的是有問題，或者存在更加高效的流程。如果專注于當前的頁面流程漏斗，將很難發現此類問題。

2）如果只關注漏斗內個別環節轉化率的提升，容易按下葫蘆起了瓢——顧此失彼。甚至有可能帶來負面效果，導致整體轉化率的下降。

比如第3步到第4步的轉化率提升，

或許是用戶更難找到自己滿意的房源了，所以只能去更多的查看房源；

又或許是用戶在列表頁看不到一些關鍵信息，只能點到房源詳情頁里去看，點進去之后發現不滿意，又關掉了。

上述兩種情況，都提升了用戶的決策成本，肯定是有損轉化的。

所以，以這種漏斗導向來改進產品，容易將產品帶進死胡同。

畢竟為了完成目標，產品經理容易各式各樣的方法都去嘗試，也許有不少能提升當前環節的轉化率，但其中真正能提升漏斗整體轉化率的很可能沒有那么多。

剩下的那些無效調整，反而會增加用戶的決策成本。

2. 我們再來看看「用戶決策漏斗」，大致是這樣的

這個漏斗的優勢至少有以下三點：

1）用戶決策漏斗是按照用戶的決策流程來搭建的，因此，提升每個環節的效率都可以直接帶來整體效率的提升，為整體轉化率帶來正向影響。

2）頁面流程漏斗是依托于用戶決策漏斗而設計的。

為了匹配用戶決策漏斗，可以設計出很多種不同的頁面流程，當前線上的頁面流程可以理解為只是所有備選方案中的一個，顯然當前這個流程可能不是最優的。

因此，關注用戶決策漏斗是一個相對更優的選擇。

3）當我們聚焦于用戶的決策漏斗時，我們能站在用戶的角度去思考，可以從更加本質的層面去思考如何去提升轉化。

用戶決策漏斗中的一個決策環節，可能會對應著頁面漏斗中的多個頁面流程。

比如「找到平臺后訪問著陸」這個決策環節，

用戶有可能決策在任何頁面，而不一定是我們預想流程中的首頁或者列表頁。也可能在樓盤頁、房源詳情頁、專題頁等等。

再比如「尋找合適的房源」這個決策環節，

用戶有可能通過搜索、列表頁篩選來尋找房源，也能通過樓盤頁面來找特定樓盤的房源，還能通過詳情頁推薦/列表頁推薦來尋找算法推薦的房源等等。

有沒有發現當聚焦于決策流程后，思路會開闊和清晰很多？

我們需要關注的核心點就是用戶在這個決策環節的轉化率。

一切能有助于提升用戶在這個環節的決策轉化率的都可以去做。

也許是對現有模塊的優化，也許是打造一個新的模塊，對現有頁面流程做全新調整，只要能提升用戶在相應決策環節上的轉化率，都可以去做。

03?關注用戶決策模型

對于第2點中提到的用戶的每一個決策環節，思考這個問題：

用戶在該環節的決策模型是什么？

可以通過下面4個問題來大概評估用戶的決策模型：

1. 用戶在當前環節，最重要的目標是什么？
2. 用戶為了完成其目標，需要完成的最重要的任務是什么？
3. 哪些可能是激勵用戶「完成當前環節并進入下一環節」的主要因素？找出最重要的三個。
4. 哪些可能是導致用戶「放棄當前環節并離開」的主要因素？找出最重要的三個。

以上4個問題，可以結合自身對業務的理解，再結合業務調研、用戶調研的方式來收集結論。

完成上述幾個問題，一般就能有產品改進的方向了。

我們再以「尋找合適的房源」這個環節為例：

1. 用戶在這個環節最重要的目標是找到匹配自身需求的房源（以下簡稱合意房源）；
2. 最重要的任務是，在篩選/搜索房源，查看房源信息；
3. 較為容易的找到合意的房源、有較多合意的房源可供選擇、能較為輕松的判斷房源是否合意、房源都是真實且在租的，這些可能都是激勵用戶完成當前環節，進入下一環節的重要因素；
4. 篩選流程復雜、搜索召回結果差、信息架構混亂，這些可能都是導致用戶放棄當前環節并離開的重要因素。

我們再結合自身理解和調研情況，對各個因素設立影響權重，綜合下來便是用戶在該環節的決策模型。綜合用戶在各個環節的決策模型，就是用戶在你的產品上的整體決策模型。

接下來就是到具體的產品方案層面了。

我們結合用戶的決策模型，加強決策模型中的正向激勵部分的正面效應，減少決策模型中負面因素帶來的負面影響。

按照這個大的方向來開展，最終用戶的決策轉化自然能提升。

比如，針對「較為容易的找到合意的房源」這個因素，我們可以做千人千面，個性化推薦；針對「有較多合意的房源可供選擇」這個因素，我們可以去驅動業務團隊將更多的房源收錄到平臺類等等。

04 灰度發布 + A/B Test 驗證方案有效性

在第3步中，針對用戶的某個決策環節，我們評估出了用戶決策模型，并找到產品改進的方向。

進而我們可能會研究出幾套方案，并決定上線其中一套方案。

但究竟我們的方案有沒有效果？多個方案中哪個方案更優呢？

很多時候我們很難明確一個方案上線后是否真的有效、或者多個方案里到底哪個更優。

這時就需要祭出我們的神器「灰度發布」和「A/B Test」了。

1. 灰度發布，就是只對產品的一部分用戶上線新方案

灰度發布可以避免新的產品方案在被驗證有效前，對太多用戶造成影響。

微信就經常采用灰度發布來實驗新功能，比如近期的視頻號，剛開始就是灰度發布的。

如果我們只有一個備選方案，采用灰度發布，也就相當于對新方案和當前線上版本進行了「A/B Test」。

2. 「A/B Test」就是對多個產品方案同時發布上線，然后根據數據反饋確定最終方案

也就是讓用戶來投票選擇。

它可以很大程度上避免我們的拍腦門決策。

網上對「A/B Test」的介紹已經很多了，這里就也不再重復造輪子了。

需要注意的是「A/B Test」設計之初一定要考慮好后續的歸因，也就是能知道哪個地方的調整也可能帶來正向效果。

所以，方案有效性的驗證方法就是，結合灰度發布和「A/B Test」，再依據我們的北極星指標來評估判斷。

哪個方案能給北極星指標帶來更多的增長，哪個方案就是優勢方案。

在評估出優勢方案后，也能進一步驗證究竟哪些是用戶在決策過程中更關注的因素，我們再去想辦法持續的加強它即可。

如果我們的所有方案數據都不太理想，那就要考慮下是否是我們評估出來的「用戶決策模型」有問題，或者是產品方案沒有解決用戶真正關注的因素。

05?寫在最后

以上我們以房產租賃類平臺為例，介紹了提升轉化率的系統方法。

最后，我們再來總結下，整體上可以分為4大步：

1. 尋找北極星指標
2. 關注用戶決策漏斗
3. 關注用戶決策模型
4. 灰度發布 + A/B Test 驗證方案有效性

其中第1、3步的難度相對大些，第2步次之，前三步完成了，第4步一般可以水到渠成。

核心是要找對方向，找到用戶的決策漏斗和決策模型，以上兩點找準后，產品方案自然就可以有效的設計出來了，再搭配灰度發布和A/B Test，產品轉化率的提升自然更加高效。

在實踐中，有時可能需要對用戶進行細分，因為不同的用戶群體，其決策漏斗可能會有些差異。

這里為了闡述方便忽略了這一部分。

實際應用中，我們在確定用戶細分規則后，針對每個細分用戶群體，分別開展上述2、3、4步即可。

這套方法對于B、C端產品是通用的，B、C端只是客戶/用戶的決策漏斗和決策模型有所差異，本質相通。

作者：候機搏發? 公眾號：候機搏發（ID：houji2bofa）。

本文由@候機搏發 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。