酷应用

滴滴数据科学家分享：数据如何驱动业务增长

百家作者：数据分析 2021-06-29 10:01:16

分析师的商业价值

直觉驱动的困境我是统计科班出身，对数据较为亲近，毕业后便在互联网开始从事机器学习与数据分析工作。几年观察下来，发现许多业务虽然都会引入算法工程与分析师等这些数据职能，但是大部分的决策还是基于直觉来拍。

当然，有些时候直觉是唯一的选择，例如产品从零到一的设计或者算法早期预测和排序目标的选择会更多参考行业内的成熟做法。但是当数据积累到一定规模，业务也已经过了早期高速增长的阶段的时候，如果业务还在保留「直觉驱动」的惯性，就会浪费掉许多增长机会点：你们身边的业务是否不经过 AB 实验就去判断一个策略是否应该上线？是否有算法团队半年以上一直在围绕有限几个指标来预测和排序，但是未曾用数据证明过这些指标对业务和用户体验的实际价值？又是否发现每个项目的数据看起来都不错，但是公司全局却没有增长？

当身边的业务出现以上现象，就很可能没有利用好分析的资源来催化自身业务的增长。无论对错，当下许多互联网企业是采用 OKR 体系做自上而下的目标拆解的。一个业务线的 OKR 里面的的「O」通常就是业务的 KPI，在这个体系下，不论是算法、运营、产品、还是分析，日常的项目都可以概括成「通过策略来提升 KPI」的过程。

同时，策略的制定来源于直觉与客观事实（数据）两个方面，只有轻重多寡之分，「直觉驱动」更依赖经验判断，「数据驱动」更多基于客观事实反推决策。因此，一个业务当下的策略应该更多依赖直觉还是数据就需要看清过往一段时间「直觉驱动」与「数据驱动」策略哪个提升 KPI 的成功率是最高的。

业务开展早期，「直觉驱动」成功率更高，可能也是仅有的方案。但是随着业务发展，好的直觉会被逐渐穷尽，业务增长进入瓶颈期的时候，「数据驱动」的价值就会越来越大。分析师是谁？做什么？产出的价值？

从个体的角度, 这也意味着我们看待 DS 并不是看这个人的学术专业, 而是看这个人的动机和意愿。公司里跟数据有关的职能是多样的, 有些是把数据作为拿到业务结果的抓手, 要对业务结果负责, 这些是数据运营. 有些是把数据作为研发的对象, 对跟数据相关的这些产品负责, 这些是工程研发。

有些是基于数据做实时地在线实现, 这些是算法工程师的工作. 这些都是我们的合作伙伴, 但是我们又有我们自己的定位, 跟这些都不同. 我们应该为我们工作的中立性和科学性负责. 我们需要有业务的思想, 但是我们并不是要做业务本身, 我们希望做业务发展的催化剂。」我非常认同世君老师上面这段话对分析师的定义。

分析师需要兼备定量能力和业务思维，在保证科学性与中立性的前提下，通过定量手段（数据驱动）来补足直觉驱动的短板。「直觉驱动」的短板可以分为以下四类：

看不清自己的用户是谁、有什么行为，体验如何「= 拿不准用户」；
将顶层 KPI 拆解成若干抓手和子目标的时候，并不明确这些抓手和目标事实上是否可以提升 KPI，或者哪些抓手与目标更加有效「= 打法不清晰」；
难以评估策略对用户与 KPI 的影响「= 算不准影响」；
不知道业务健康度如何以及当下要采取的行动「= 看不清现状」。

补足短板的具体解决过程体现了分析师日常在做的事情以及数据分析的价值：「拿不准用户」：当直觉不能很好契合用户诉求的时候，对用户画像细分、行为轨迹分析、流程转化等分析可以帮助业务更了解用户：他们是谁，喜欢什么，什么环节体验不好，什么诉求尚未满足；

「打法不清晰」：通常业务完成某个 KPI 可以用到的抓手非常多，比如，内容平台的终极目标之一是用户留存，同时提升留存的抓手有很多，例如 CTR、赞读比、访问时长、公域私域相互导流等。直觉并没有办法有效判断这些抓手哪个在当下最可能把留存提升上去，这时候，基于数据的观测性研究可以估算抓手与 KPI 之间的关系强弱，辅助业务排布各个项目优先级。

「算不准影响」：直觉无法策略一个策略对用户的影响，实验分析是高效评估策略影响的解决方案，AB 测试可以帮助业务看清每个策略对各个细分人群体验的影响并持续小步向前迭代；

「看不清现状」：当大盘指标异常波动的时候，异动归因分析相比直觉是更加科学高效的方法来定位指标波动原因并提出解决方案。业务不同阶段下数据分析的发力点与交付良性的业务发展通常要经历从直觉驱动到数据驱动的过程，本节进一步展开这个过程并讨论不同发展阶段的业务特点与痛点，以及这个阶段数据驱动业务的打法。这里采用 Noriaki Kano 的 KANO 需求模型将数据分析需求分成三类：

基本型需求：分析师必须具备的能力与交付，是分析师做事情的行为底线。基本型需求完成不好的时候，再多的锦上添花也是徒劳，也会直接失去业务方的信任；
期望型需求：一般业务与分析师正式拉会所讨论的项目与预期就在期望型需求的范围，这部分需求完成的越及时或者越多，业务方对数据分析的评价也会越高；
惊喜型需求：主动分析，跳出业务的思考框架，数据分析产生的洞见帮助业务解决困惑，发现战略机遇，或者数据所提供的策略帮助业务完成难以达成的目标，就是惊喜性需求。惊喜性需求没有被满足业务不会不满，一旦被满足的时候业务的满意度是非常高的；

第一阶段：从零到一，直觉驱动业务野蛮生长业务开展早期通常可以通过学习头部竞品的成功经验快速获得大规模的业务增长，同时，产品运营同学也很容易在业务早期的雏形中凭直觉找到增长抓手。

虽然从 0 到 1 的开展业务是非常辛苦的，但是单从获得业务增长而言，这却是最轻松的第一阶段，第一阶段的典型特点就是：

从零到一，直觉以较高的成功率驱动业务早期的野蛮生长。数据分析在这个阶段会跑在后面紧跟，业务在第一阶段对数据的需求就是 T+1 准确反映业务 OKR 指标表现，分析师及时做好 BI 角色支持，不要在业务需要临时看数据的时候连现成的 sql 都没有备好。

基本型需求：埋点、OKR 指标口径与常用 sql、数仓明细表；期望型需求：业务日报（OSM），每天早上盯住关键指标并及时报备异常波动；用户生命旅程数据刻画（UJM）惊喜型需求：通过描述性统计帮助产品找到发力点：用户属性、行为研究帮助产品看清各个模块与内容上面的用户密度；

产品漏斗转化率分析帮助业务看清产品各环节表现，找到转化瓶颈并重点改善体验。比对分析竞品该业务早期的关键指标数据，大致判断目前的增长速度是否足够快，空间还有多大。

第二阶段：增长放缓，实验评估助力业务小步迭代第一阶段临界终点的时候，直觉依然可以找到大量改进措施，但是从大盘指标上可以看出业务增长放缓甚至横盘。这时业务就进入了第二阶段，这个时期显著影响大盘指标的策略会越来越少，很难通过上线前后大盘数据对比来判定业务动作的好坏：

投石问路的过程中业务最怕的是听不清石头落地的声音，因此分析师在这个阶段为业务提供的关键价值就是引入实验机制，以 AB 测试为典型的统计方法可以精确、科学的度量每个实验的微弱效应，帮助业务在投石问路过程中「听到」方向。

实验机制是业务第二阶段的高效解决方案的另外一个原因是，实验可以对线上同时运行的多个策略带来的影响分别进行准确估算，因此实验机制在速度和精度上都全面超越原始的事前事后对比法。在这个阶段，分析师需要充分发挥统计专业能力，做好实验方法咨询的角色并积极推进技术、业务部门之间协作打通实验平台。

基本型需求：实验分析支持为业务方提供统计专业咨询，e.g. 实验设计，AB 数据含义，统计指标的计算口径期望型需求：联动业务、后端、前端开发、BI 协同搭建实验平台平台可以并行线上实验同时可以自动化处理实验分流不均、检验指标显著性向业务普及 AB 方法与对业务的价值，出具实验分析白皮书强化业务对实验的信任

惊喜型需求：将实验分析报告模板化，赋能业务在脱离分析师资源的情况下自主完成实验设计与分析报告维护业务上下线的实验明细日志，包含实验 ID、业务策略、影响、上下线时间、上下线理由，季度性提供给业务去复盘总结

第三阶段：增长遇到瓶颈，数据驱动业务找到新目标体系与增长发力点

与第二阶段不同，在第三阶段开始的时候，策略的成功率与影响程度都大幅降低。这个阶段，产品和运营侧好的直觉基本被穷尽，算法侧已经把特征体系和技术选型迭代到了相对完备复杂的水平，再想提升预测精度是非常困难的，便开始频繁出现实验结果不显著或者负向的业务策略，业务增长正式进入横盘阶段。在业务缺少方向感的时候，数据驱动业务方向的选择就越来越被重视。分析师的话语权也开始变大，毕竟到了第三个阶段产品运营与算法团队初步具备了一定规模，不增长的后果是很难想象的。

因此，分析师一定在这个阶段有业务主人翁的意识，开始深度思考业务问题并主动提出需要数据分析的问题。有必要强调的是，分析师在这个阶段要主动思考和分析，不能被动响应业务需求；不要妄想去证实业务这个阶段的直觉是不是对的，而要站在更加全局的层面去思考业务发展的关键问题是什么；不要再沉浸在实验方法的优化上面，而要开始频繁旁听业务讨论会，重点体会业务高层在会上提出来的问题以及流露出来的困惑点。

这些对于分析师找到需要分析的关键问题是非常重要的，也是分析师在这个阶段产生影响的第一步。对于增长而言，第三阶段也许最为重要的指标就是用户留存率。用户增量 = 新用户+沉默召回用户+活跃用户*留存率，业务早期的增长可以通过业务之间导流与拉新来完成，当业务成熟后，提升存量活跃用户的留存是最为经济的手段。

不过实际上，每个业务策略、项目、或者算法模型的目标与留存提升之间通常是靠直觉强行连接起来的，不够，目标是否有可能错了？能够有效提升留存的目标应该是什么？这就是分析师要在第三阶段试图用数据来回答的关键问题。当初笔者刚接触一个做社区内容平台的业务时，该业务快半年内的所有算法和业务策略都没有任何提升用户留存的迹象，分析团队在梳理这块业务时候发现业务和算法都在用 CTR、赞读比、收藏读比等有限几个指标来衡量用户的阅读体验并做排序。

分析师基于 DID 建模分析发现当时大盘用户里面留存提升的群体通常伴随着上一期深度阅读量与 CTR 的显著提升，而赞读比、收藏读比与留存的相关性并不高。问题是，业务过高估计了赞读比、收藏读比的价值，并在排序的时候没有考虑内容被深度阅读的概率高低。

团队后续推进了一系列的策略建议：我们首先大幅提高了 CTR 的排序权重，这个简单的策略就打破了长达半年来业务留存率无法提升的困境；团队进一步在排序目标里面引入深度阅读概率、平均阅读速度等与留存关联性最强的指标，并设计了多目标融合的公式，这个新目标（公式）成为了算法、产品运营的新业务目标，并带来了新一轮的留存增长，业务顺利走过了第三个阶段的增长瓶颈期。

平台的终极目标是流量、利润，这个顶层目标会在 OKR 体系下被拆解成二级指标，三级指标等子目标。无论是业务策略还是具体算法，它们都在直接影响一个子目标（e.g. 价格，CTR，时效性），无论他们在完成这个子目标的时候多么数据驱动，通常都在基于直觉假设他们的子目标与公司的终极目标是直接挂钩的。

问题是，直觉是会犯错的，因此才存在业务第三阶段的瓶颈期，这时也就体现了数据驱动的价值。基本型需求：通过历史策略和数据开展观测性研究，通过数据估算策略当下每个子目标对公司顶层指标的影响，联动业务制定并落地新的目标和增长方案；期望型需求：积极主动创新，寻找更具增长潜力的新指标，纳入当前业务的子目标体系，提供子目标整合成统一一个目标的方案；惊喜型需求：观测性研究方法工具化，赋能业务在脱离分析师资源的情况下自主完成目标优化。

第四阶段：数据持续驱动细分人群的差异化策略迭代

数据在第三阶段驱动业务增长的同时，业务也因此在每次评估策略影响的时候要兼顾更多的用户体验指标。在此基础上，业务增长到一定规模之后就要开始承担更多全局责任，开始承担孵化新业务的角色，这会进一步扩展业务的指标体系。

走到这个阶段的业务通常是寸步难行的，因为每走一步都要经过互斥、此消彼长的层层指标关卡。在第四个阶段，通常是每个策略迭代都伴随留存不显著波动但是二级指标互有涨跌的现象。

糟糕的是，当留存等顶层指标不变但二级指标互有涨跌的时候，数据不能给出明确策略上下线的建议，业务便又退回到了基于直觉来决策的原始形态。在这个阶段，不够克制、盲目上新的产品会变得臃肿，给用户带来产品功能复杂冗余的不良体验。

在这个阶段，数据评估层面需要做系统改善来保障决策的科学性。实际上很大概率成立的一个事实是：把所有用户当做一个大盘整体来评估用户体验是低效且失真的，策略在大盘层面的「表象影响」是细分用户群体层面的「实际影响」的累加，而「实际影响」在不同用户群体之间可能存在显著差异。下图内容平台的实验数据就是一个典型：大盘（左）数据表现出来的留存不显著+二级指标互涨跌实际上是细分用户群体后指标普涨、普跌、互涨跌。

分析师在这个阶段需要在细分用户群体粒度整合阶段二的实验能力和阶段三的观测性研究能力，打通数据驱动细分策略迭代的流程：

Step1：基于细分实验分析，策略在指标普涨用户群体上线，普跌群体下线；

Step2：产品运营与分析师联动展开用户调研与观测性研究，针对体验不良的用户群体探索新的增长发力点；

Step3：循环在此基础上，分析师需要在这个阶段打磨到细分用户群体的异动归因分析能力，帮助业务及时发现问题和增长点。

分析师的工具

分析本质上是在做什么？分析本质上就是在「比较」。好的分析就是一个「数据比较 -> 洞见 -> 业务优化」的过程。洞见离不开「比较」：无论是我们看指标走势，AB 差异，同比环比，或是回归分析模型中的参数，这些都是我们「比较」的不同形式。具体来说，数据比较来源于三种分析场景：

实验分析；
异动归因：日报周报解读，突发指标异动分析；
观测研究：增长抓手分析，未经实验全量上线的策略评估，长期战略规划。

AB 实验是在 AB 两组之间进行比较，异动分析是两个时间段之间的比较，观测研究实际上是在分析一个指标变化相比不变化对业务的潜在影响。比较有两个要素：1. 研究群体和参照群体（Benchmark），2. 评估指标。比较时所选择的 Benchmark 好坏直接影响分析结论的可信度。举个例子：「产品转化率是 5%，还有提升的空间」就是一种很常见的分析结论，但是这个结论本身毫无逻辑，为什么 5% 是较低的水平？提升转化率的抓手又是什么？这类分析的问题就是没有找到好的 benchmark。

相比而言，「产品转化率是 5%，我们竞品的转化率是 8%，我们和竞品的主要差异是 xx，所以转化率还有提升空间，建议优化 xx」的可信度就更强，因为分析找到了参照，并且用 xx 作为辅助评估的指标。比较背后的思考体系和 AB 实验很类似，新业务策略的思考也是个比较的过程，只不过前者基于数据，后者则是在直觉中比较。

工作中我们最频繁的基于直觉比较是在制定 OKR（Objective ~ Key results）的时候，对于每个 KR，我们都在比较：有相比没有这个 KR 对于 O 而言是好是坏。依照这个逻辑来讲，分析的价值在于分析可以提供直觉所欠缺的 O 与 KR 之间的「定量关系」。我自己的经验是，把业务的诉求翻译成 OKR 的框架里面可以帮助我快速找到分析思路。

一方面业务一般都是在面向一个具体的目标谈有待数据验证的策略思路，带入 OKR 框架成功率较高，另一方面解 O 与 KR 之间的「定量关系」的统计方法已经有一套完整的体系，这个后面我会再提及。总结下，在对接一个业务需求的时候，分析师一定要搞清楚：1. 这个需求围绕的业务目标（O）是什么，什么指标去量化 O？2. 业务聊的核心用户群体是谁，什么维度可以量化这些细分用户群体？3. 潜在的抓手（KR）有什么，业务提到了哪些，我们又可以举一反三出来哪些？在这些问题搞清楚之前，先不要动 SQL 或者建模方法。不难看出，分析的一个核心基础能力就是一套健全的画像、指标体系。

基础：维度、指标体系无论是哪种场景，「比较」都要具象化到实际业务场景才能提出可落地的业务洞见，而具象化的分析依赖一个关键工具：画像体系与业务指标体系。这个体系对业务的还原度越高，分析质量也越高，因此分析师团队要不断去「养」自己业务的画像指标体系。最直接「养」画像与指标体系的机制就是不断去用，每次应用所发现的问题持续小步迭代解决。

指标、画像体系建设的责任要落实到个人，整合团队业务分析师的画像与指标口径，持续优化体系的完备性可用性，并推动工作成果在业务分析、实验平台、业务运营平台上落地应用。

互联网业务通常属于多边平台模式，完备的多边平台画像需要包含供需+场景的刻画：需求画像：用户 demographic，诉求归类（产品 = 诉求），用户行为、兴趣分类；供给画像：供给形态、来源、品类、时效；场景画像：时空，供求关系，竞争，大盘等外生因素刻画。多边平台的业务指标体系在描述业务健康度，平台增长要么是拉动供需规模要么是增加匹配效率，因此业务指标体系包含以下三类：供需结构指标：按照需求 + 供给画像细分后的用户数、供给分发规模；

匹配效率指标：供给分发转化率 e.g. CTR、ETA、成交率、交互率...；

体验结果指标：用户留存，人均消费与浏览时长；画像与业务指标设计最考验分析师的业务理解程度，平时多留意资深一些的业务如何讨论用户和供给，会启发分析师优化口径的设计。在知乎遇见过一些糟糕的画像，例如一个刻画用户频次的维度竟然聚类出来六层，然而每一层都没有明确的业务含义；

另一个维度直接按照高频、中低频、新、沉默召回来切割用户，简单、业务意义清晰，业务方自然会去用后者来看数据。或许在知乎见识过的最棒的用户画像，先将用户需求抽象成「看热闹」「长见识」「找解答」「来创作」四个大类，然后基于用户的行为链条来往这四类里面归，理解业务先于制定口径与技术选型，画像的应用价值与空间自然更加宽广，统计方法产生的价值也越大。

未来分析师所处环境

几年前我还是一名算法工程师，跳到阿里刚开始的时候很不习惯，因为许多日常人肉要做的工作都被数据和算法平台解决了，不夸张的讲，那时许多产品运营同学训练部署机器学习模型的速度都比我要快。

AI + 数据的平台在逐渐释放那些高度重复的数据工作，那时候我意识到，如果一个 RD 脱离业务，时间精力花在调包换模型调参数这类事情上的话，ta 早晚被淘汰掉。

对于分析师来说，我们不得不思考的问题是自己每天的「分析」工作中有多大比例并没有在分析？目前来看，数据查询平台还没智能到通过拖拽形式来完成多数的取数需求，一些公司内不健全的埋点平台还有数仓还需要大量分析师花精力排坑填坑。

也正是因为平台能力尚未成熟，产品运营自己分析一次数据的成本过高，就会有大量取数的需求提到了分析师团队，导致每个业务下都有一些分析师做了「数据的揉面工，业务的按摩师」。

最近还留意到两款明星数据产品，Chartio 和 SQLFlow，前者是拖拽式 SQL 与可视化的一站式平台，后者是在模型解释上做了一些增量工作的机器学习训练与部署平台。虽然还没有大规模商用，但是已经能看出趋势：SQL、数据可视化、训练与部署模型、模型解释相关工作的门槛会越来越低，数据感觉不错的业务同学可以直接通过这些工具来快速完成取数分析师大量的「分析」工作，还省去了不少沟通成本。

所以未来一定会淘汰掉一些分析师，留下有业务思辨能力和定量专业能力的精英。未来分析的工作还是离不开画像指标体系、实验评估、异动归因和观测研究，但是会更加关注这套体系的科学性与落地上面，也因此可能会分化出来两拨分析师：

业务导向的分析师优化业务与数据的连接，挖掘业务表象的跟因与战略机遇，并将洞见以画像与业务指标的形式做落地，指标与画像的工作直接优化了业务的分析质量和运营效率；模型导向的分析师优化基于数据做评估、归因、推断的科学性，并落地易用的数据产品，在此基础上，发现业务决策过程中不科学的环节，推动数据分析工具在这些环节的应用。

因此我建议分析师在懂 SQL，基本的统计方法基础之上，增强自己的业务属性和数据科学属性：学习商业、经济学原理，理解基本的因果推断与计量方法，强化构建模型内核的 scripting 能力。

转自：songzi2016；