顾青：我们在谈增长试验和洞察时，其实在谈什么？

本文4000字左右，作者顾青，DTALK创始人

人类的优势不在于海量数据中寻找模式，还是去做创新的探索，这其实是今后几十年我们继续发展的前提。所以我们在谈增长试验的时候，其实关键问题还是回到数据质量。

本周末将给一批企业线上讲授数据洞察和产品驱动的增长，所以想到几个来自我指导过的的比较有代表性的企业案例，供读者们思考，你可以给出你的分析和答案，也可以给我留言，直接报名可以文章末尾点击阅读原文。

案例一：在线教育企业：如何让业务方理解机器学习的业务价值？

在线教育领域独角兽的互联网教育企业，非技术驱动型企业，业务的扩展导致客户退费退单需求越来越多，业务方的目的是从数据角度降低退费退单的人数。

数据团队做了用户退费预测模型，有300多个因子，找到可以退费退款用户，准确率在90%以上。但是与业务人员沟通的存在障碍，业务方需要的是知道用户为什么要退款，而不是找到这批用户。这其中有一点没有达成共识，大数据是找到相关关系而不是因果关系。

但大数据的出现改变了这种在科学界普遍追求的因果关系的检验系。

在传统的统计分析中，一个重要的因素是因果关系的可靠性，在有限的样本下，科学家在假设检验中往往用各种专业统计软件进行假设检验，根据概率P值(P-Value, Probability)进行检验决策。

为此找了统计模型，从300多个因子降到10多个因子，从90%多的准确率降到50%的准确率，可以像业务解释说明。出现这个问题跟公司文化有关，技术人员解释给业务人员是一件比较难事情。业务人员与技术人员有鸿沟。

如果是你负责这件事，你如何让业务方理解机器学习的业务价值？

案例二：汽车互联网平台：如何推动公司管理层和业务方改变决策流程？

汽车电商互联网平台。背景：用户分为两类一类是知道自己要什么另一类是不懂车。因为UED从专业角度认为保养手册很重要，但是业务方不认同。通过AB测试之后得到保养手册漏斗图转换率高于洗车转换率，说明保养手册非常有价值的。

如果是你负责公司的产品和设计负责人，如何推动公司管理层和业务方改变决策流程？

案例三：国有大型银行的用户画像到底如何体现价值？

国有大型银行，旗下有多个不同的互联网业务板块，涉及保险、旅游、医疗、房产等。背景：产品线很多，没有全局数据，内部数据没有打通，用户画像非常难，导致并不能完全从数据角度来做产品决策。由于数据量很大，如何给管理层展示有效数据是个挑战？

如果你是产品团队负责人，你如何通过这件事推进公司对用户画像体系建设的正确方向？

这些问题的终极答案其实都是为了让企业在增长决策中的能力得到极大提升。

所以，我们需要优秀的决策流程和工具，对吗？

一些源自SXSW大会的意见

2012年SXSW大会上，Joshua Porter（原HubSpot的产品设计总监）曾有过一个很重要的演讲，这个演讲的核心思想：

数据和指标是唯一客观用于衡量产品设计对于业务价值的手段；

数据分析、AB测试、技术驱动能力对于产品设计决策的巨大作用；

直觉驱动的设计需要及其大胆的勇气、多年的实战经验、经得起考验的设计模式和异于常人的远见（比如iPhone的触摸式交互），同时也伴随极高的风险；

数据驱动的设计需要及其冷静的理性思考、基于数据做决策、风险可控、安全的试错流程、鼓励试验的机制和文化；

流程转化的优化永远是主题，需要企业有能力提供无限细分和用户画像的工具给产品设计团队；

好的产品设计可以解决商业问题并创造商业价值。

试验的价值

Google 每个月都会做几百个测试，其实有一些给 Google带来了很多的营收增长，也有很多是很失败的项目。Google在几百个里面，可能最后有10几个成功了，这些产品经理他们可能很骄傲，自己的产品能够给全世界所有的用户用，还为公司带来了2%营收的增长，仅仅通过 AB 测试的方式 Google 就可以达到华尔街的要求。

有一些东西真的只有测试过才知道，就是产品经理、运营人员、技术人员，没有办法理解的，比如说 Google 的广告位，如果你左移一个像素你就会赚钱，左移两个像素你就会亏钱，没有任何人知道为什么，但是 AB 测试可以告诉你。所有的改动都需要提前经过测试之后才可以上线。

Facebook 更是这样，他们的移动端尤其如此，会把所有的新功能都集成到代码里面去，然后再把未来6个月要做的试验都集成进去，不断地去测。除了 Facebook 的产品得到提升之外，它还得到一个特别好的口碑叫没有 bug，可以想象 Facebook 几十亿的下载，它没有 bug 是多么的可怕。

国内的百度、美团、知乎这些企业，他们也都会做自己的AB测试，当然他们做的也都很好。

试验的8条原则

实战中的AB测试的8条原则（来自微软的科学家Ronny Kohavi）：

经验一. 效果惊人，某些很微小的改动，就可能造成对你 KPI 巨大的影响。

经验二. 大多数改动都不会大幅度提升 KPI，所以你需要耐心。

经验三. Twyman 法则，凡是看上去很出人意料的图表，通常都是因为数据统计错了。

经验四. 各个产品几乎都不一样，你复制他人的经验，往往都没有什么效果。

经验五. 任何能加速用户响应时间的改动，都会带来 KPI 的正向提升。

经验六. 点击率是很容易提高的，但是流失率是很难改进的，千万不要把精力放在优化某个页面点击率上。（其实要提高点击率非常简单，你只要在这个页面上加一个大美女就可以了，但是它并不能带来你真正实际上的增长。）

经验七. 尽量不要做很复杂的大量改动的实验，而是要做很简单的小的迭代。

经验八. 几千上万的用户就可以展开高效的 AB 测试。

证据 V.S 观点

增长试验和洞察的理论依据可以参考一个经典的方法论就是“证据层级（英语：hierarchy of evidence ）”。

这是是一种用来对科学研究结果的相对强度进行排序的启发式方法。

由学者及研究专家Guyatt和Sackett在1995年首次提出，具体见：https://jamanetwork.com/journals/jama/article-abstract/392650

这个方法其实就是通过不同层次评估医学证据（如单个患者的病例报告或盲法随机对照试验）和分析洞察的终点（如生存期或生活质量）影响证据的强度。

大家要意识到，任何一种新药的研发就等于是一个没有任何疗效证明的创新。

所以，无论是新药研发，还是新功能设计，新的商业模式的推广，只要是可以按照研究证据和目标结果之间影响强度的方式，就能规避这些“非证据”，也就是具备最高强度偏见的因素。

自从有了互联网以来的商业实践中，这些都是典型的偏见来源：

• 商业故事/名人传说
• 公司创始人/高管的经验
• 本能
• 无法证伪的大量在线视频
• 论坛的讨论
• 竞争对手的APP/网站
• 社交媒体

下图就是一个典型迁移到互联网项目/数字化转型项目中的“证据层级”方法论。我将具体在5月21日大课中具体讲案例和如何落地。

在C端产品上对证据层级实践很好的企业有谷歌、微软、字节、携程等。

在SAAS产品上，比如Slack和Linkedin都是很好的例子。

数据质量是试验和洞察的基础

越来越多的互联网项目团队开始重视数据驱动、数据挖掘和AB测试的价值。

在培训过上百个互联网团队后，我并不对大多数企业的现状表示乐观。理想中的基于算法的自动化的业务流程可能就是一个看起来很美好，执行起来都是”坑“的事情。

比如一个大型连锁酒店集团有自己的APP、H5、小程序等各业务端，同时还有来自PMS（酒店房间预定系统）的大量历史累计交易数据。

该企业都希望建立一个样本集：基本上是基于将过去的那些被用户影响的行为连接于预测因素的值（那些观察结果-比如一个从某年就成为某连锁酒店集团公司的金卡客户，在上两个月有过订房，并通过积分购买过金额在某个数值以上的商品）。

这个酒店的团队或许期望通过选择一种使用样本集，并且通过分析每次观察结果来确定用户目标行为与关系（这个叫做模型）的算法。这个模型可以是线性算法，就像线性回归与逻辑回归，或者非线性（就像树状算法，神经网络等等）。这个算法的选择当然需要基于数据分析团队对这种行为与预测关系的主观判断，需要团队对业务逻辑非常熟悉，并且可以通过自己内部建立的数据平台满足他们理想中的“数据和AI驱动运营”。

我们理解他们是希望通过算法和数据集的不断调优，通过CRM结合标签体系来 ：

1. 降低营销成本
2. 降低客户流失（比如通过OTA预定而非该酒店官方平台）的可能性
3. 提高营销活动的ROI和用户体验

但是首先要做的第一步，反而是要确保该酒店的数据平台可以做好数据采集这件事。

数据采集是最核心的问题，需要支持全端数据采集，包括iOS、Android、JS、JAVA等多个平台。

换句话说：只有当你获得了高质量的数据，人工智能（AI）才能有机会帮助你提高自动化的水平。

当然，大多数企业的现状是，这种AI和数据共生关系已经存在，但很少可以做到完全有效的运行。

经常出现的问题可能有：

• 数据采集的方案由没有业务经验的纯技术人员负责，数据价值不被业务部分认可
• 团队缺乏数据采集的规划、缺乏业务策略知识、产品观念差
• 公司管理层对数据仓库的建设缺乏远见，被短期目标和成本约束了手脚，陷入“技术价值总是短期被高估，长期被低估”的怪圈。
• 公司没有长期培养数据运营的整体观念

从本质上讲，如果在规模化增长项目上发现推进困难，可以通过这样的方式去剖析：

1. 是否增长团队的洞察和决策能力不足？
2. 出现能力不足，无法满足需求，是否是职能缺失？
3. 出现职能问题，事情无法推动，是否是企业文化缺失了一些重要元素（比如重视证据，而不是观点）？

我补充一下自己对所有希望做到产品驱动增长团队的建议，大家请避免这些问题：

1. 指标定义一堆，有价值的指标不多
2. 数据采集和数据整合没有做好，无法实现相关性分析挖掘。
3. 非常表面地去理解流行的概念，比如什么：AHA时刻、AARRR模型、增长黑客（新时代的成功学），缺乏对真实业务数据的敏感，没有有效管理好数据的质量，没有建设企业内部可以对复杂问题系统化抽象理解的数据字典
4. 为了收集数据而收集，缺乏数据处理的策略和规划
5. 单纯追求用户的活跃，没有发掘用户行为和业务指标之间的实际关系
6. 为了做用户画像而做用户画像，缺乏基本的标签体系设计

如果大家在实战方面有具体的问题，欢迎来我的线上增长课堂讨论。