提出建议：什么才是有价值的建议？

有些同学在学校里就开始学数据分析了，简单一点的会让你求相关系数，复杂一点的会让你找出原因，但学校里却从来没教过数据分析还要提建议。后续这些同学在工作中分析具体的业务问题时，分析到原因就结束了，因为他们认为我都找到原因了，后面怎么做是业务人员自己的事了。

结果他们发现，企业和学校有很大的不同。学校追求真理，但是企业追求效果。在企业里大家关心的不是问题的原因，而是究竟该怎么办。大部分的业务同事是不看分析过程的，拿到分析报告之后他们会直接翻到分析报告中“结论和建议”的那一页。所以如果你不会提出建议，那么你很可能不符合企业里对数据分析的要求。

所以，今天我就来讲一下，如何提出有价值的建议。

建议有哪些类型

我们提出的建议应该是什么样的呢？如果按照建议是否具体可落地的话，可以分成这样三种建议。

1. 给方向

最基础的建议是给方向，建议的方向是提升某个业务指标。

因为同一个业务目标，完成的方式可以有很多种。比如同样是提升销售额，我们既可以提升用户总量，也可以提升转化率或者提高客单价。

这时候如果你分析发现，转化率较低是目前销售额不高的原因，然后建议业务人员优先提升用户的购买转化率。这个建议就是“给方向”。给方向回答了一个最基础的问题，我们应该做什么。

但是“给方向”的建议比较宏观，依然很难落地。我们知道了要提升转化率，但是怎么提升呢？我们可以继续深挖，给出落地的策略。

2. 给策略

“给策略”是在给方向的基础上提供了具体的策略。比如我们给的方向是提升购买转化率，给策略的建议就是：落地页优化、增加优质广告位曝光、开展活动促销等。

“给策略”的建议看起来似乎像是微观层面的“给方向”，核心的区别在于“给策略”的建议都有具体对应的负责人。比如落地页优化，这个工作会有一个具体的业务人员负责，而“给方向”的时候提出的建议“提升转化率”，就没有一个具体的负责人。

给策略相比给方向已经非常落地了，但依然还可以继续深入。

3. 给方案

第三层级的建议是“给方案”，内容是在给策略的基础上提供具体的落地方案。比如我们给出的策略是通过落地页优化来实现购买转化率的提升，那么“给方案”的策略就是：落地页内容重点突出卖点 A、减少文字描述改用图片形式、增加在线咨询按钮，等等。这些方案业务人员拿来就能直接用，真正地体现出了数据分析的价值。

这三种类型的建议，哪个更有价值呢？

其实还是要看具体背景，凡有选择，必有代价。“给方案”的建议固然能直接落地，体现出了分析价值。但要提出这样的建议，需要较好的数据质量和丰富的过往案例做基础，而且会耗费大量的时间和精力。所以我们要根据需求的轻重缓急做一些权衡，对那些不那么重要的需求、新开辟的业务模式、数据采集不全的业务，给出策略或方向就足够了。

如何提出建议

给方向、给策略、给方案，这三种建议是逐步递进的，只有知道了方向，才能给出策略，只有知道了策略，才能给出方案。所以在提出建议的过程中，我们也是依次思考不同层级的建议。

如何“给方向”

首先，我们聊一聊如何提出“给方向”的建议？

在分析问题的流程中，有一步是找出问题的表面原因。表面原因的方法在 10 讲中提到，其中第二步是缩小问题的范围，也就是按照子指标和维度交叉组合分析问题。如果做到了这一步，我们就可以提出“给方向”的建议。

比如，我们分析如何提升拉新渠道的投放 ROI，根据 ROI 的子指标成本和收入，以及渠道维度的交叉组合，发现B 渠道的人均收入较低，导致 B 渠道的 ROI 较低，进而拉低了整体 ROI 水平。

那么给方向就很简单了，要么降低 B 渠道的资源投入，要么提高B渠道的人均收入。这个建议，就把很多其他的假设排除了，比如提升 A 渠道的转化率、提高 C 渠道的客单价等。

如何“给策略”

然后，我们再看如何提出“给策略”的建议。

找到表面原因的第三步是确定具体环节，也就是用过程指标找出存在问题的环节。如果我们的分析做到了这一步，那我们就可以提出“给策略”的建议。

比如我们通过过程指标分析发现，B 渠道人均收入较低的原因，是因为 B 渠道用户的支付转化率较低。那么我们就可以给出策略：提升 B 渠道用户的支付转化率。

这一步相比第一步给方向的建议“提高 B 渠道的人均收入”要具体得多，一般建议提出来，就能对应到具体的执行人。

如果“给方向”的建议是“降低 B 渠道的资源投入，提高 AC 渠道的资源投入”。那么渠道投放的过程指标是曝光、点击、转化等步骤，我们也通过过程指标的分析找出其中的核心环节，给出策略：到底是投入资源提升 AC 渠道的流量曝光，还是投入资源优化引流页面。

总之，“给策略”一般对应的是过程指标的某个具体环节。

如何“给方案”

最后，我们看一下如何提出“给方案”的建议。

在分析出表面原因后，我们会分析一下根本原因。根本原因是基于用户视角找出的原因，找到了这个原因，我们就可以用演绎法推理出落地的方案，提出“给方案”的建议。

比如我们分析发现，B 渠道的支付页转化率低，是因为 B 渠道用户小众机型占比较高，页面适配做得不好。那么我们就可以给出对应的方案：优化某小众机型的页面适配。

再比如我们发现是因为 B 渠道的用户年龄比较大，目前的 App 风格和文案都偏向年轻群体，那么面对这类原因，我们可以用 Fogg 模型，从动力、能力、触发三个方面提出对应的建议。这一部分知识在 06 讲 《懂业务》中已经提到了，这里就不再赘述。

以上是在找到了根本原因的情况下，如何用演绎法推理出落地的方案。

但有些时候因为数据不全或其他原因，我们没办法找出问题的根本原因。这个时候，我们可以通过归纳法，根据同类型问题的历史数据给出方案。

比如，同样是支付页的转化率不高这样一个问题，类似的优化历史上做过几次，分别是：

• 增加付费的方式；

• 去除不必要的文字说明；

• 优化页面的适配，提高加载效率。

我们可以根据这些历史案例，结合当时的优化效果，提出落地的方案。

这里也可以用 Fogg 模型做一个归类，方便业务人员快速理解。这种归纳法的方式没有之前通过根本原因推导出的方案那样精准，但也给了一些方案和参考，也可以节约业务人员的试错成本。

另外，在提出“给方案”类型的建议的时候，相比其他的建议要更详细一些，要按照主谓宾的结构填充完整，至少要说清楚“谁、做、什么事”三个要素。

像是“优化某小众机型的页面适配”这样一个建议，其实还不够完整，缺少主语。完整的建议应该是“建议客户端开发人员，对某小众机型的页面适配进行优化”。因为这样的建议有具体的负责人或团队，就更容易落地，要知道领导是很忙的，他们一般不关心你的分析过程，喜欢直接看建议的部分，所以我们要尽量把建议说得足够具体和完整。

提高建议被执行的概率

提建议还有一个高级的技巧，那就是建议的内容尽量和执行人的 KPI 挂钩，这样推动起来会更简单。要记住，数据分析师是无法独立完成工作的，分析师分析出来的结论是需要其他部门的同事执行的。所以你的执行方案一定要跟他们的利益结合起来，否则你说得再有道理，对方没有执行的动力，那这份报告就执行不下去。没有落地的报告是没有价值的。

比如现在提出的建议是“客户端开发人员对某小众机型的页面适配进行优化”。如果遇到客户端开发团队的资源特别紧张的情况，那么这个建议很可能会进入漫长的排期过程。为了加快这个过程，你可以研究一下开发团队的 KPI，如果有一项考核的内容是“解决的 Bug 数量”，那么你可以看一下这个小众机型有没有其他的适配问题，把几个 Bug 一起打包提给开发，我想研发会很乐意优先做这个需求的。

这种能落地的建议就是有价值的建议。

小结

新人分析师往往觉得提出建议很难，每次都要对着一堆的数据结论思考很久。其实，提出建议并不是在分析结束后才要考虑的事情，正确的做法是在拆解问题、分析原因的阶段，就已经开始为提出建议提供必要的支持。

所以提不出建议，不是你不会提建议，而很有可能是你根本就不会分析问题。只要分析问题的过程做到位，那么提出建议其实完全就是水到渠成的事了。一个分析师能提出好的建议，就说明他懂业务，并且掌握了分析问题的整个流程。所以，能否提出好的建议是检验一个分析师能力的重要标准之一。

本文强调这样几个关键点。

• 企业里不追求真理，追求有效，做分析最重要的是找出究竟该怎么办。

• 建议分为：给方向、给策略、给方案三种类型，三种建议层层递进。

• 提出不同建议的基础是之前找原因找的有多深：

• 缩小了问题范围，可以给方向；

• 确定了问题环节，可以给策略；

• 找出了根本原因，可以给方案。

• 建议要尽量完整，至少要说清楚“谁、做、什么事”三个要素。

• 建议的内容尽量和执行人的 KPI 挂钩。