== 前言 ==

大家好，我是大Fei，九日论道的常驻笔者，又给论主献花了。前两次给大家分享了一些AB Test实战方面的心得，收到不少的反馈，笔者会不断吸收大家的建议并继续改善，欢迎各位道友前来指教。 

在决定分享这个话题之前，笔者思考了很久，“数据思维”是笔者在团队不断去努力建设的一个目标，也是笔者不断在学习和探索的一个思维模式，这对于团队的增长文化，是个即基础又核心的关键因素，因此抱着学习的心态想要抛出来与大家一起探讨。

同时，也希望借此机会，分享笔者对数据思维的理解，以及在这方面的经历和看法，希望能让更多的人重视数据思维的培养，让更多团队充分利用数据创造价值，关注数据到商业的价值，这个是笔者所理解的数据思维的核心。

适合阅读对象：思考数据驱动增长的团队Leader，产品，运营人员

== 正文 ==

一、团队数据驱动可能存在什么问题？

可能我们都曾面临过这类情况：

• 数据搭建好了，但业务方（产品/运营等）没有充分利用，没有看数据的习惯

• 数据利用起来了，但看不懂，不会分析

• 数据分析了，但不知如何驱动业务增长，创造价值

• 等等..

在与很多朋友交流过程当中，确实能够感受到很多负责业务的朋友仅对业务/商业敏感，但对数据的敏感程度还不够，而做数据的朋友大多数只对数据比较关注，缺少真正能驱动业务的能力。 

我们曾在公司团队内部给业务的同事做过一些分析/实战方面的培训，负责业务的同事虽说掌握了一些分析能力和技巧，可以取数和观察数据，但确实少了点什么，最直观的感受就是没有多少人是对数据敏感的，主要体现在无法就业务深入讨论数据问题，进而，就很难深入到数据驱动业务的层面，更对数据创造商业价值无从入手。

而对于负责业务的同事，一个现实就是大部分人本身就是对数据不敏感，而想要对数据敏感，需首要解决的是让个人具备相关的数据思维，这也是团队要实现数据驱动增长所必须具备的团队基因。

笔者认为数据思维应当包括：

• 关注自己业务数据，对数据变化异常敏感

• 能够利用数据思考和决策，驱动业务增长

• 能够利用数据发现业务问题

• 经常能基于数据做出假设和预测

• 能够将业务问题，定义成数据可分析问题

  
  

业务人员天生具备的优势就是熟悉业务问题，但将业务问题变成一个数据可分析问题，进而用于指导自己或其他数据人员分析问题，是比较困难的，但如果具备了一定的数据思维，这个将不再是问题。

二、团队具备数据驱动增长的基因吗？

1、重新审视我们对业务数据的认知

无论你在团队担任什么角色，我想建议大家分别用5~10秒钟的时间回答下面每个问题 

你团队的核心产品/业务（如App/网站）：

• 日活（DAU） /月活（MAU）分别是多少？

• 激活（install）到注册（sign up）转化率是多少？

• 激活到付费页面的触达率是多少？

• 付费页面付费转化率是多少？

• 激活的次日留存率是多少？

• 激活用户的ARPU是多少？

• 激活用户有%几在激活当天付费？


也许你看出来了，上面几个问题基本都是AARRR 指标体系里面的相关数据，对于做增长的每个人来说都不陌生，但在这些看似简单基础的数据问题，你是否能熟悉并回答出一个大概的数据范围呢？

假如问题不符合你的场景，你可以举一反三，例如你的部门仅负责某个功能或业务线，那么激活就等同于功能的首次访问，次日留存就是首次访问该业务或功能且次日留存的比例，每个细分的业务也会有自己的AARRR模型，相信大家都懂，不再重复赘述。 

大家可以自己评估一下，自己对业务数据的熟悉程度到底如何，同时也可以放在团队内部，去调查一下团队对相关业务指标的熟悉程度。

你可以直接使用上面的几个问题，也可以结合自己的业务设定不同的问题，主要目的在于了解自己团队的现状，如果答对的比例整体偏低，建议团队leader要好好反思，为何团队对自己负责业务的基础数据认知会怎么差？ 

当然，个人也应该反思，假如连基础的业务数据你都无法准确掌握，数据驱动增长，从何而来，给你再多的增长技巧，你确定能正常运转吗？

2、团队的数据思维如何体现

如果大家有印象就会留意到，我们招聘时经常提到一个对数据敏感，虽然比较抽象，但这就已经表明我们很清楚知道，对数据敏感的重要性，笔者认为数据敏感度是数据思维的其中一种比较直观体现。

关于数据敏感，笔者合作过程中接触过很多数据敏感的大佬，我们公司的老大就是一个数据敏感的人，笔者发现这类人都有这些个特点：

- 能提出清晰的数据需求，且对自己每提到的数据指标都有深入的理解

能明确知道自己需要观察什么数据，且能够结合业务寻找到非常关键的分析维度，用于观察和解读数据，笔者也经常从这些人**掌握到很多关键的业务数据洞察信息，受益匪浅；

笔者虽说能具备一定的业务能力，但自认无法与做业务的人相提并论，而对负责业务且对数据敏感的人，往往其对业务数据的洞察要更深入，这点笔者深有体会；

- 没有一天不认真观察数据

每天都认真看数据，且总能提出报表的调整建议，因为数据敏感的人总有自己观察数据的方法和基于业务的解读方式，且反过来会经常指导报表的调整和输出，以提高他们对数据观察的效率；

- 经常能够发现数据异常

数据敏感的人，在对自己业务数据充分理解的情况下，更能够及时察觉到数据的异常，举个简单的例子就是，当你们上线某个活动时，这个时候，有数据思维的人就有形成对数据走势的预判，但数据过高或过低都会引起他们的警惕，进而分析和找到问题所在。

如果团队对数据不敏感，往往会造成总让数据部门的人滞后发现异常，因为数据部门有时候相对于一线业务人员活动信息是滞后的，收集信息和响应就会更慢，而影响已经造成了。

笔者建议大家对比自己，能否做到这样？假如团队的每个人（尤其是业务方），都能这样来关注业务数据，你觉得团队的数据思维会差吗？笔者觉得答案是肯定的，当我们都具备这样的数据思维和相关意识，实际上我们就掌握了对业务数据分析的基础，而恰恰是这种基础的思维方式才是最重要的，比任何技巧都重要。

3、个人数据思维到团队数据思维仍然艰难

即使我们团队有了数据敏感的人，有数据人员做支撑，或者数据平台、培训、报表都有了；但在笔者看来，想要达到一个合格的数据驱动团队，还需从个人到整个团队，一步一步去转变，突显数据的作用，并影响到团队的每个人，这需要不断的去宣传数据驱动的文化，训练团队成员的数据思维；

但笔者相信，当更多数据驱动的成功案例出现，这一步并非那么遥远，数据思维，也将成为每个从业者必备的思维能力。

三、我们的协作流程能够支持数据驱动吗？

这里列了两个流程对比，大家可以看一下自己的团队更符合那种协作流程

流程1：产品/运营需求协作流程

流程2：产品/运营+数据需求协作流程

笔者的团队更多的是【流程2】所示的协作流程，我们经常在内部强调业务方的需求要加上数据需求，但实际上，我们仍然会出现【流程1】的情况，还是会存在运营和产品在出需求或上线的时候，没有充分考虑过数据需求。

例如，已经上线了某个活动，最后跑来问数据团队，有没有数据评估一下效果，这个就是问题所在，但大家还真不能把这个当做个例来看，这反而是一个团队可能面临的问题，一个缺少数据思维的体现。

另外还有一个亲身经历，且让笔者印象深刻的就是，有个朋友改动了他们产品的付费页面，询问了笔者一些数据上的建议，当时建议要上AB Test，但最后对方并没有采纳AB Test 的建议，而是坚信了自己的新方案会比旧方案好，之后事实证明了，数据并非一直增长下去，且导致数据增长的因素非常的多、也时间的波动性等等，当数据不是长期保持提升的时候，就会容易受到他人对方案的质疑，甚至，你连方案是好是坏都区分不了，提升多少也不知道。

所以当我们的流程存在问题的时候，即没有充分考虑数据在整个过程的角色定位时，数据运用起来就会非常的不顺畅，容易会出现遗漏，从而导致数据缺失或项目效果无法评估的状况。

四、打造团队的数据思维

1、业务方基本数据素养

1.1 学会提数据需求

很多基础的数据基本由开发或数据人员提前收集到了，但这个过程还远远达不到应用层面，就如前面第一节提到的，大部分数据采集上来后，基本没有用到，这个实际上也在浪费企业资源；

从笔者接触到的几个项目来看，确认这类问题频频出现，有了数据但不知道如何使用起来，所以这也是笔者本次希望探讨这个问题的主要原因。

作为业务方，就应当清晰定义你所需要的数据，从写需求的角度来说，不要单纯提一个数据，而建议把目前和用途写清楚，这样有助于数据人员理解你的需求和商业价值，而对于没有的数据，交由开发埋点即可。

并且，业务方更需要掌握如何运用数据，不要过于期望数据人员告诉你怎么使用数据，而是通过学习行业内的用法，例如如何做精准运营、如何分析用户画像、用户标签运用等等，这些只有当业务方找到运用场景，数据人员才能更好的发挥其专业的作用，否则让数据人员帮你找应用场景，这个本身就不是他们特别擅长的事，有可能直接搞错了方向，例如用户标签就极有可能给你整出一大堆用不上的标签。

在出产品或运营需求的时候，有意识的加上数据分析需求，让数据人员评估当前的埋点是否符合最终的分析需求，若不则需要重新设计埋点。

1.2 数据自助分析工具投入

数据分析工具是必要的投入，当分析需求越来越多（随着业务增长，这个需求量只会增不会减），你不能等分析人员老半天才出一个数据结果，甚至在初期没有数据人员时，你就得依赖开发资源，自助分析工具可以让业务人员快速上手，自行获取关键数据和展开基础分析，有利于整体效率的提高；

对于期初团队人员少，项目用户规模不大的情况下建议考虑免费的分析工具，如Firebase + BigQuery，这样可以减少初期的投入，同时能保证一些数据的采集和分析工作，BigQuery建议开启付费，不贵，避免早期数据丢失（保留60天的数据）。

而对于稍微有一点用户规模和收入的团队，则比较建议付费的数据分析工具，分析的效率较高，功能则要丰富很多，例如神策这类工具，国内可以多家对比；

重要提示：无论接入了啥分析工具，作为业务方，都要熟读一下官方的操作教学文档或视频，了解每个工具和指标的具体含义和用途，这是非常的关键，决定着你是否能正确使用这些分析工具和正确解读数据；笔者见过很多接入工具但没有充分利用的案例，白白浪费有效资源。

1.3 每日观察数据

建议团队内部，尤其是作为业务方，需要天天盯住自己业务相关的数据，无论是团队的日报，还是在分析工具中，每日看数据的习惯是培养数据思维的重要过程；

每个你所关心的业务指标，都可以反应出一个真实的用户使用场景，同样的场景下，这个指标的表现如何，相比业界做的更好吗？哪些维度不够好，你需要在每天都思考这样的问题。

神策有个功能，可以观察每个后台账号的活跃天数，通过每个账号的活跃程度，就可以看出每个人对数据的应用深度，这个是一个比较有效衡量团队数据运用表现的方式；当然，笔者不建议这个指标用于评估个人表现，而是作为对团队每个人数据意识和数据应用层面的观察和把握，从而思考应该如何提升团队每个人的数据思维，结合每个人实际工作情况，做进一步调研和沟通，解决问题。

1.4 数据素养和技能培训

为团队内部业务人员提供相关基础数据分析能力的培训，也是进一步提高团队整体数据思维和重要措施。

2、数据增长文化的植入

2.1 有一次显著成功的实验

熟悉增长黑客的朋友会知道，增长的文化是需要对内部宣讲的，但更为重要的就是实打实完成一场数据有明显增长的实验，用数据的胜利结果对内部做宣讲。

具体如何开展，这个部分其实没有太多可以说的，方法论网上有很多内容可以直接参考，但笔者比较建议寻求同领域内有增长经验的专家帮忙，或者找到增长负责人，如果没有把握的情况下，多认真研究数据，寻找增长突破点，再做相关实验，笔者最早接触增长黑客时，我们的增长小组有几次失败的实验，就是因为前期各方面均没有经验，导致实验很少有成功的，从而打击了团队士气，第一次启航失败。

设计和评估方法也可以参考笔者前两篇文章：

【硬核】从设计到归因 - AB Test 实战心得

【硬核2】从思路到工具 - 增长实验数据归因分析

2.2、无处不在的 AB Test

这是笔者很喜欢的一个概念，当我们要开展任何工作时，多用AB Test 的思维方式来思考，例如发送一条消息、营销页面时，多准备几个备选文案，发送时用AB Test分发；可以测试发与不发的区别，测试发什么内容的区别，你可以一次性做到几种验证，高效而便捷；运营工具可以选择支持AB Test的，如Firebase的 in app message功能； 

另外就是当大家在有些方案意见出现分歧时，那就可以直接分两个方案上去测试，用数据结果说话；若没有分歧，笔者仍然建议在资源允许的情况下，多测试一些小改动，如文案、UI配色等，这样可能提高实验效率，高效获取更多经验，沉淀下来。

3 让数据参与到各个协作的环节中

3.1 邀请数据人员参加需求评审

数据人员被邀请参与到所有的需求评审过程，已经成为笔者团队里面的常规工作了，这个是数据和业务深入沟通和参与的过程，整个评审的过程中，可以有助于让数据人员深入理解业务目标，从而更好的支撑项目的需要；

试想一下，有的团队可能还没有接入增长的文化，甚至都还存在部门壁垒，这样时候，一个需求沟通不到位的可能性非常大，因此，把所有可能的干系人拉在一块，是比较高效的做法；

同时笔者想说，这些收获都是我们团队实际在践行【流程2】过程中能够感受的改变。 

3.2 任何需求用数据说话

无论是产品还是运营的需求，笔者始终坚持，无论你要做任何事，只要有数据的，就得先拿出来，而不是干讲需求，并且要对方案的预期数据提升有一个预测，最后验证这个预测。

这个时候，你的需求靠谱程度会提升，大家也能基于数据讨论方案和给出针对性优化建议，假如你的方案牵扯到很多开发资源，但功能的受众非常有限，且明显感知到数据提升有限，这样的方案，往往也能在评审中及时被发现，从而减少没有必要的资源浪费，即使团队没有数据人员也建议这么做，参会人员可以基于数据审视整个方案。（这个方法笔者只能说，屡试不爽，经常可以由其他成员提出更多建设性建议）

3.3 数据复盘

无论方案的最终结果如何，你都要有一个明确的结论告诉参与项目的人，这个方案是成功还是失败，成功是提升了多少，项目质量如何；这些数据都是对团队成员一段时间的努力的反馈；

在我们团队，有几个地方笔者觉得是有利用了数据来复盘：

•  我们每个版本都会有单独的数据仪表盘追踪版本的数据表现，团队的每个人都可以看到

•  例如版本开发中，我们会记录需求量和bug量，beta版本包个数等

•  每个版本都会及时追踪质量指标，如崩溃率，网络质量，ANR等

•  相关负责人会总结数据和同步所有人，结果衡量方案的效果 

3.4 让数据人员为业务方案设计提供数据支持

经常在方案思考时，多与数据人员探讨实际业务问题，从而获得数据人员在数据角度提出优化建议，这是让数据人员深度参与业务的好处，笔者经过多次这类团队合作，在团队内得到业务部门的充分信任，因此导致后来不少业务方直接想笔者询问方案的建议，当然，协作过程中，笔者或团队数据人员一般会基于该业务所涉及到的每个关键数据进行分析，给到相关建议。

3.5 多定义数据可分析问题

笔者最开始经常接到一些取数需求，如想要一个注册转化率数据，但笔者经常会要求写清楚目的和用途，理由就是避免需求沟通偏差，并且能够基于需求的目的给到合适的数据和建议，从而主动参与到业务中去，假如业务方的目的是希望提高注册转化率而做一些产品改动，这个时候你还能主动发掘每个步骤的流失，分析流失原因，主动提供建议。

而这个例子反过来对于业务方的意义呢？还记得我们前面提到的将业务问题定义为数据可分析问题吗？你同样可以在要求获取数据的时候，提出分析需求，如希望分析每个注册步骤的流失原因，并提供你的假设，如哪些原因可能造成流失，让数据人员用数据来分析和验证。

数据可分析问题定义公式：Y 希望分析的数据结果 + X 多个可能的影响因素

例如：

业务问题描述：

1、希望分析用户注册失败的原因

2、看到注册失败的用户注册过程遇到网络错误、遇到某个操作无法执行、遇到无法注册、遇到账号已注册等多个情况，需帮忙验证这些因素是否有影响

数据可分析问题：分析和预测X对Y的影响

【 希望分析的数据结果 Y 】：用户是否注册失败

【 多个可能的影响因素 X 】：注册过程遇到网络错误次数 / 遇到某个操作无法执行的次数 / 遇到无法注册次数 / 提示账号已注册 / … 

当我们把问题定义清楚，剩下就是交给专业的数据人员分析即可，分析人员即可基于业务人员的假设而分析出每个因素对最终结果是否有影响。

当你掌握不了如何定义数据可分析问题时，建议把业务问题和假设描述清楚，与数据人员充分沟通。

最后，再次重点推荐业务人员或数据人员多基于业务尝试做数据假设，并仔细用数据做验证，这个是培养业务洞察和数据思维的有效手段。