本文作者曾将一个「非电商类产品」的整体转化率提升了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协议。