数据洞察之我见

在数据分析这个行业里，大家经常会谈论未来是大数据的时代，未来的竞争就是数据的竞争。

而麦肯锡的一项对700+家企业的调查显示，许多公司、尤其是传统公司还没有从大数据项目获得预期的结果，或者还没有获得相当高的投资回报率。大数据项目投入后收入平均仅增加了6%。我想一个很大的原因是传统企业大多是业务流程驱动，数据更多是作为一个报表使用。他们很少挖掘数据价值对企业流程的驱动，而是依靠个人经验进行决策。即使在使用数据分析的公司也多是停留在验证假设、监控效果的层面，通过数据分析获得洞察的很少，用分析直接指导行动的案例更是少之又少。Forrester的一项调研报告显示，有74%的公司希望通过数据驱动，但是只有29%把分析结论和运营动作建立了联系。

要从数据中得到价值，首先得弄清楚数据分析和洞察的区别。有很多作者讨论过这个话题，包括刚才上面贴的那篇forbes上面的文章，简言之，数据是没有经过过多的处理的原始信息，数据分析是从这些信息中发现的规律、趋势等，而数据洞察则是通过数据分析得出的价值，包括决策运营、预测机会等。

ConnectedInsight项目由来

作为客户服务及权益保障事业部智能运营中心的数据运营团队，我们的职责是支撑各服务线、智能调度中心及互联网渠道的数据分析。

虽然每条线都有几名数据分析同学做支持，但是由于数据分析需求往往都是由一个或小部分场景出发而提出，并未全局考虑数据和分析结果在整个业务线运营链路中的作用以及能为运营决策带来的影响，导致需求往往零散、冗杂且重复。同学们在不成体系的需求下熬夜跑代码、做报表、写分析报告也很艰难。

车品觉的《决战大数据》一书中写到：“大数据的力量来自触类旁通的关联。我们以前总是用数据来证明或企图说服工作上的盲点，而如今的数据不再是一加一的依据，而是具备了预测和开创新机的能力”。

书中还提到，“把分析的理念和框架变成数据产品，本质上是一个数据泛化的过程。这个过程非常重要，因为数据报告的需求会越来越多，如果没有泛化数据给使用数据的人，分析团队将永远被冗杂和重复的工作所困”。

由此智能运营中心的数据运营团队和平台系统团队一起提出了ConnectedInsight项目，目的是为了从业务描述，业务诊断，业务预测，决策支持等方面，一步步完成从散点数据走到数据洞察。

基于此，我们和CTO 线人工智能部的AI运营团队以及CTO 线数据平台部DeepInsight产品团队做了共建，我们提供业务指标框架和分析思路，产品由AI运营团队主导开发，由DeepInsight提供后台能力，最终呈现在新客服数智产品上。

任重而道远，为了避免闭门造车，写下这篇分享，想吸引更多有相同想法的同学或者团队一起来探讨更好的解决方案。

ConnectedInsight项目“洞察”了什么

下面分别讲讲ConnectedInsight这个数据分析产品的四部分分别实现了或者将要实现的价值：

业务描述：描述业务上发生了什么。

服务线要了解自己的服务做得好不好，首先是需要看描述性的数据，过去我们是靠一张张报表实现这种描述功能的。但是单个的KPI报表是散的，比如我们分别看了一条服务线服务流程各个点上的数据报表，并不能直观的拼成一条链路图来了解整个业务流程的运营情况。基于此，我们开发了可定制化的业务数据流程图和异常高亮及预警功能，让用户能对业务现状一目了然，实现了从“点”延伸到“线面体”。

业务诊断：诊断为什么发生。

服务线看到数据流程图描述出来的某些环节做得不太好，就需要了解原因或者能改善的点。在此需求背景下，我们的产品开发了单指标多维度拆解和多指标相关贡献度拆解，实现了诊断指标异常定位原因，让运营同学能更高效的找到运营点。

业务预测：预测将要发生什么。

服务线要部署人工服务方案，必须提前知道服务量，我们通过预测产品化的方式让运营同学能高效的使用预测功能，合理的分配服务人力资源，同时也大大提升了分析同学预测产出时效。

决策支持：决策要做什么。

目前服务线运营同学在决定下个周期的派单部署方案时仍需靠人工重复、机械的统计历史数据和预测数据进行局部优化的方案选择，而我们的产品将实现用相关因子自动计算出全局最优的派单部署方案，大幅提高运营效率和准确率。

1、业务描述

业务背景

业务描述就像汽车仪表盘，实时告诉你发生了什么，并适时警报提示等。分析师要做的事情就是搭建指标体系，进行各种维度的统计分析。我们过往的大量工作就是做这个，目前市面上很多BI产品也都能够满足这个层次的数据运营需求。

拿客户服务及权益保障事业部的国际线来举例，以往业务线运营同学看到的是拿老版Alisis搭建的各KPI的图表，如下图（图表数据非真实数据，仅用于展示），给出的是业务监控体系里散的“点”，并没有从业务全链路的角度给出用户能一眼看出业务整体有什么异常的大图。

痛点

这么搭建业务监控的结果是什么呢？有没有发现业务看完数据后，经常会基于此提出额外的数据需求？

一般来讲，想看数据的人潜意识里是要成“体”的数据的，只是沟通过程中变成了“点”的需求，因为“点”简单容易讲明白，但是，这次给不了“体”的数据，下次还会围绕“体”的数据提各种“点”的需求，这个时候我们需要延伸一下，提前想需求方之所想，就不用来回往复了。

解决方案

AI运营团队开发了流程图、树图、星环图等个性化分析组件，分析师使用这些组件完成产品内容搭建，并在我们的产品平台上配置各服务线的分析页面。

拿国际服务线举例，服务流程上用户可以拨打95188或者淘海外电话等进入热线人工服务，需要升级的提交工单，用户也可以进入支付宝钱包，英文钱包或PC端自助服务，未解决问题可以接入在线人工服务，需要升级的提交工单。

以往运营同学看的是各个环节的数据点报表，在我们构建的分析产品中，业务同学看到的是随业务流程变化的全链路图，整个链路图可定制、指标节点可设置预警高亮，从用户使用自助服务，到拨打热线电话，进入智能派单环节，再到人工客服接起，转入转出，升级提交工单，整个链路上哪一个节点出现异常一目了然。

一个节点可以配置多个指标，主指标和相关指标。鼠标悬浮于节点可展示主指标及相关指标的趋势图，如果想进一步分析，可点击详情分析进入指标的下钻分析页面。

节点也可以配置堆积柱状图，这种配置在想展示业务占比等场景的时候非常好用。

2、业务诊断

数据之间是存在因果联系的，这些联系有些容易通过业务来解释，而有些恰恰是业务无法直接看到，需要通过数据发现联系。在这个层面，需要数据分析师从整个业务链路和数据之间的联系出发，通过关联分析，波动分析，平衡计分卡等方法，找到数据变动的原因。

痛点

过去我们提供给业务同学报表，用于日常指标的监控和原因分析。但通过报表找原因会存在两方面的问题：

沟通成本高、原因获取效率低：业务同学使用报表在众多指标中寻找原因，过程不熟练，分析师需要花时间和业务同学一起解读数据和寻找原因。

数据的落地性差：业务同学在面对需要立即解决问题的压力与大部分数据具有滞后性矛盾的背景下，往往是选择在没有数据分析结果时，先根据过往的运营经验采取措施，导致数据对实际指导的价值不高。

解决方案

在ConnectedInsight的业务诊断里，我们进行了分析思路产品化。把分析师常用的分析思路和过程沉淀下来，用产品化的形式呈现，避免重复劳动，改善原因定位的时效性；业务同学不需要了解背后复杂的计算逻辑，直接看到分析结果，并且可以指派给专人负责。

在初版产品中包含两种类型的业务诊断分析：单指标多维度型和多指标相关型。

单指标多维度型的业务诊断，我们要找出的是在一个指标能拆分成的多层树状结构中，具体是哪一层的哪一个节点的波动对这个指标的波动贡献度最大。

以服务线FCR（First Call Resolution，首次呼叫解决率，衡量客户服务及权益保障事业部解决客户问题能力的重要指标，一般为24小时内未重复来访的服务量占比）这个指标为例，通过下图所示的树状结构梳理安全服务线的服务量和FCR，拆解成一级业务，二级业务，三级业务的服务量和FCR的波动对整体FCR波动的贡献度，找出导致FCR波动的最主要的业务。如本例中限权咨询业务对当日FCR下降的贡献度为96.3%，运营同学应该着重关注该业务。

（*以下截图为demo，数据也非真实，最终版正在开发。)

多指标相关型的业务诊断，我们要找出的是在一个指标有多个影响它的指标时，具体是哪一个指标的波动对这个指标的波动贡献度最大。这里多指标之间的不是简单的加减关系，而是转换为复杂的影响因子，通过影响因子量化指标之间的贡献度。

比如对热线接通率进行业务诊断，接通率分母是热线流入量，流入量是客户需求通过自助、转人工等，直到流转到热线处理环节的咨询量，因此流入量相关的影响因素有：产品、自助、智能派单、转接等；接通率的分子为热线应答量，应答量和通话时长、排班人数（人员）、现场运营效率（产能）等有关。通过下图把指标之间的关系环状表达出来，当选中某一指标后，该指标相关的影响指标也会高亮。而后台计算出的分析结果会给出指标波动的影响因子和各因子的贡献度。

（*以下截图为demo展示。)

3、业务预测

业务背景

服务线的小二对接了蚂蚁所有业务线的服务量，随着业务不断拓展和复杂度的叠加，需要的咨询和审核小二人数不断增加，此时服务量如果可预测，就能基于现有资源做好排兵布阵，为业务线人员排班、人员招聘、和预算提供决策参考，在保证接通率、工单处理时效、进而提升用户体验的前提下，最大化人力资源利用，降低人力成本。

服务量包括：

咨询服务量，比如话务量，支付宝使用中电话咨询客服小二。

审核服务量，比如工单审核量，账户被冻结要上传身份证、人工审核。

痛点

我们业务线分析师在过去对服务量的人工预测流程如下，需要3个分析师每周20+小时的工作，才能按时的完成预测工作。

以上流程存在一些问题：

效率低：每条业务线的预测都要重复以上流程，这些因素涉及到多团队多部门协同，效率低下。随着公司业务的拓展及业务复杂性的增加，预测的工作量越来越大，铺人的方式解决不了根本问题。

预测标准不统一：预测分析师人肉做出预测，诸多零散个人经验贯穿其中，不同分析师预测结果会有偏差，不利于形成统一的方法和标准。

人工干预信息无法统一沉淀、不利于总结经验：各环节的线下沟通信息无统一沉淀，不利于事后评估产品事件影响、渠道调控，无法为后续预测调优提供指导。

解决方案

我们的ConnectedInsight中的预测功能，把预测融合模型（简单理解，既多个预测模型自动寻优）产品化，通过傻瓜式的点击按钮，让运营的同学可以自己做预测，把分析师的时间解放出来进一步优化模型。这个产品不仅大大的提升了预测产出时效（从1周到5分钟），更提高了预测的稳定性和准确率。

预测模型特征分解和产品框架如下图：

最终的预测产品如下，运营可以选择自己所在的小组（技能组）、和预测时间窗口（常规锁定预测、排班修正预测）。

即可出现如下所示的话务量趋势图，并且可以根据自己掌握的信息对模型结果进行修正，修正后备注原因，便于模型的学习和调优，让后续预测结果更加精准。

4、决策支持

无论是上面讲的业务诊断还是业务预测，都是通过数据，对业务运营做决策支持。在这个环节，我们关注的从洞察到行动的过程，将数据洞察的结论提炼出来，告诉运营同学如何去行动是when、where、who and whom，指导业务的行动方向。例如，在我们通过多指标相关性分析发现影响接通率变化的因素有1. 业务量变化；2. 预测准确率；3.排班准确率。这三个因素都是insights，但是只有第2个和第3个因素是Actionable insights，而第一个因素，业务量的变化，这个更多是受业务发展的影响，并不是我们客户服务及权益保障事业部能够采取行动而改变的。在运营方根据我们的分析结果，做出实际运营动作之后，我们的产品会通过数据回流，进行action前后效果对比，从而形成数据化运营的闭环。

更进一步的决策支持和决策自动化我们已经在规划，细节期待有共同发展方向的团队一起协作探讨。

心得和鸣谢

最后，说一点这些年做数据分析的感悟。数据分析师每天都会被大量的业务需求压得喘不过起来，如果不能做到真正的数据驱动运营，分析师们慢慢的会对手头的工作疲惫而倦怠。而做好数据运营的关�...

大数据是一个非常好的发展方向。科学的数据统计与分析上至国家、企业，下至个人，都能提供出莫大的帮助，“不怕乱如麻，只怕不调查”数据是反馈一个集体或者个人以往表现最有力的证明。沧桑话巨变，数据铸辉煌。数据能力的强弱也能决定发展方向是否客观真实，决定了未来的可能成就。本文主要讲述数据分析等级是根据哪些方面划分的以及数据分析的日常工作。

1、数据分析师的日常工作内容是什么？

数据分析师这个职位，不同的公司，不同的行业，对于它的理解和工作内容都有所不同。在有些传统行业，数据分析师工作重点是做行业报告等；在阿里巴巴等大型互联网公司，职位区分比较明确，数据分析师大部分时间只做产品和运营的分析工作，至于基础数据处理、搭建数据产品等等不涉及;在创业公司等相对小型公司，数据分析师要干的活可能要不仅仅是产品和运营分析，基础数据采集和处理，数据产品搭建都属于数据分析师的工作范围。

明确了数据分析师的工作范围，大概也就清楚了每天要做些什么，比如：

产品和运营的数据提供(正常分析师工作)

基础数据采集和处理(类似ETL工作)

数据产品的思考和搭建(类似数据产品经理工作)

数据价值的挖掘(类似数据挖掘工程师工作)

2、数据分析师需要会什么？

①、数据分析理论要求及对数字的敏感性，包括统计学知识、市场研究、模型原理等。

②、工具使用，包括挖掘工具、数据库、常用办公软件（excel、PPT、VBA、word、脑图）等。

③、业务理解能力和对商业的敏感性。对商业及产品要有深刻的理解，因为数据分析的出发点就是要解决商业的问题，只有理解了商业问题，才能转换成数据分析的问题，从而满足部门的要求。

④、汇报和图表展现能力。这是临门一脚，做得再好的分析模型，如果不能很好地展示给领导和客户，成效就大打折扣，也会影响到数据分析师的职业晋升。

3、数据分析师的成长阶段

①第一阶段（一般岗位叫数据专员）

基本学会excel（VBA最好学会；会做透视表；熟练用筛选、排序、公式），做好PPT。这样很多传统公司的数据专员已经可以做了

②第二阶段

这一阶段要会SQL，懂业务，加上第一阶段的那些东西。大多数传统公司和互联网小运营、产品团队够用了。

③第三阶段（数据分析师）

统计学熟练（回归、假设检验、时间序列、简单蒙特卡罗），可视化，PPT和excel一定要溜。这些技术就够了，能应付大多数传统公司业务和互联网业务。

④第四阶段（分裂）

数据分析师（数据科学家）、BI等：这部分一般是精进统计学，熟悉业务，机器学习会使用（调参+选模型+优化），取数、ETL、可视化啥的都是基本姿态。

4.数据分析师就业方向

数据分析师 – 偏向商业化的数据分析，运营广告等活动效果分析，销售额或利润预测，用户特征描述等，需要较好的统计知识，需要懂1-2门数据分析工具如SAS、R等；

咨询顾问 – 面向客户，为客户提供数据抓取、数据分析、出数据报表、改进建议落实等咨询服务，需要有较好的沟通能力，需要懂1-2门数据分析工具如SAS、R等（咨询顾问其实也分技术和非技术，技术类的主要是为客户搭建数据平台）

数据产品经理 – 一般是互联网公司独有，数据量大的公司会有自己的数据产品，如阿里巴巴的数据魔方等，主要是针对数据产品从产品立项、提开发需求、跟进产品开发、测试一直到产品上线等工作（相对来说并不需要对从业者要求很高的数据分析或统计能力，属于目前市场上为数不多但高工资的职位）

数据平台的建设可以当做一个产品来设计。从广义上来讲，所有以数据驱动为核心的都可以称为数据产品（如数据报表平台，DMP，BI平台），从狭义上来讲，就是公司内部的数据平台。今天我们要讨论的，主要是在公司内部搭建数据平台。

公司的内部数据平台，主要是给各业务提供数据处理、分析、展示，供内部所有部门人员使用的，涉及数据的收集（填报）、数据的整合、业务报表制作、业务员数据分析以及可视化数据展示，目的是让公司内部的所有业务都能通过数据来驱动和辅助决策。简单点讲就是通过数据平台来驱动公司内部的数据化运营。

那么如何设计符合企业实情并能解决实际问题的数据平台呢？

1. 平台建设主导人需要对每一块业务需求有深刻的了解，知道每个业务部门想要看什么样的数据，需要什么样的分析报表；这些数据是否现在就可以获取到，是否需要收集；业务部门通过这些数据分析，是如何推进和改善业务，是否有提升的价值意义。

2. 平台的设计需要根据业务的要求设计符合使用者需要的内容，产品要有层级和结构。如果设计的一张数据报表既要满足管理层的需求又要满足一线业务人员的需要，那么这样的数据产品体验很大可能是比较差的。因为领导和业务人员的关注点不一样，看数据的视角也不一样。领导往往需要一些能帮助把握大方向的关键指标，并且希望知道这些指标之后的问题是什么？原因是什么？所以给领导设计的报表需要直观易懂，并且能够基于这些指标的一场定位到问题。而业务人员更在乎业务的执行，关注的数据往往粒度很细，需要知道各项指标的明细。

领导关注的报表（FineReport制作）

销售领导关注的指标明细（FineReport制作）

3. 数据平台一定要注意数据质量、规范、统一。因为数据平台是面向所有业务的，怎么保证公司的所有部门人员对于数据的理解是一致的，这点特别难。（比如服装行业的“断码”，从领导层来讲，公司仓储的服装全部尺码如果不完整就是断码；从仓库的仓管员角度来讲，仓库内的服装尺码不全就是断码；从门店的业务员角度来讲，客户需要的尺码当前门店无货就是断码）。公司的业务系统各有不同，数据口径不一，数据孤岛问题，导致数据的质量和结构也千差万别，越是这样，数据仓库的数据建设就显得尤为重要。平台的数据质量依赖于数据仓库底层的数据模型，所以一个好的数据仓库很大程度上决定了数据平台的数据质量。

4. 工具选型上，有报表平台、BI。报表平台适合构建基础的规范化的数据平台，从明细报表（表格类）的，项目档案，文件报备，数据填报，数据报表，业务主题分析，文中的所有demo就是用FineReport制作，侧重于展示和报表管理。BI侧重于分析，拿到数据可以自己拖拽维度来分析，不同于报表受模板框架的限制，涵盖简单的明细报表、分析报表和主题分析，制作要简单很多，大数据量的处理性能也强劲很多，代表：FineBI、Tableau.

下面我们就从实战的角度来加以阐述。

某公司是一家电商公司，那么该公司的各部门需要看哪些数据呢？首先收集日常常用的数据指标，哪些是经常要查询的，哪些是要日常填报的，这些在过往的经营中都有备案，好收集。这就构成了日常的基础查询类报表，这类报表最占大头。

其次，我们可以观察一下各部门的KPI是什么？下放到团队以及个人的KPI是什么？是否能以具体的数字来量化？如果对负责支持的部门的KPI不了解，就去寻求部门领导帮助（使用者最懂要什么），不落实指标如何能设计出好的数据报表？通常粗略的，例如采购部门的KPI基本就是销售额、订单数、销售毛利润、采购成本；运营部门的KPI就是新老用户述、留存率、复购率、用户流失、转化率，市场部门的KPI就是PV/UV、新客数，这就构成了各部门日常管理的报表。

那么知道各个部门的核心KPI后，下一步就是针对一些特定场景的主题报表。主题报表往往是记录某一事件，其中的指标都是相互关联的。

比如，我希望知道这个月我的绩效完成的怎么样？在团队内排名是提升还是下降？每个人的绩效结果明细是怎样的？——这就构成了日常考核报表。

又比如在分析产品时，需要重点关注某些产品的相对市场份额和市场增长率，则要建立波士顿矩阵分析，以便让资源有效地分配到合理的产品结构中（当然还有其他分析角度）——这就是品类分析。

产品分析（FineReport制作）

再从业务分析和使用场景入手，拿采购部门的小王来说，他是怎样看数据的呢？

每天早上，我希望知道昨天的销售情况怎么样？所以这时候应该设计一张基础查询报表给到他，这张数据报表应该具有以下功能和内容：

1.能够查看昨天以及过去各时段的数据；能够按照产品、地域来统计；能够与过往的平均值做比较，看看是不是某区域某产品的趋势上有大的变化，是不是广告投放，活动推广带来的，影响大不大。其次，每个月，每季度的数据是多少，能够选定时间段自动展示。

请点击此处输入图片描述

2. 指标越丰富越好，如果销售额下降了，看看是不是订单数下降了，订单数没变是不是客单价的问题，是由于商品结构的原因还是活动门槛调整导致的。

3. 数据分析的能够下达的粒度越细越好。比如数据粒度可以从全国下钻到省份，从省份下钻到城市，这样交易额下降了就能知道是哪个省哪个城市出了问题？就能针对性的解决。

请点击此处输入图片描述

经过以上几个步骤，即可形成平台雏形，形成规划文档。但一个数据平台，无论前期规划得多么丰富，也不可能一蹴而就。公司的业务在不断变化，分析的内容也越来越丰富，在这过程中总需要不断磨合和调整，只有不断完善之后，才能形成一个更加量身定制的实用平台。

以前曾经听到有人这么说，“万事具备，就差一个程序员了”听这话的意思，程序员是有多渺小，我想程序员听到这话一定会很生气吧，心里肯定是无数个反驳的说辞，其中我能想到的一段反驳就是：这话的意思不就是所有事情都想好了，就差执行了，可是想与做还差10万8千里呢，不过从这句话中可以看出一些运营人员心目中的程序员，那么接下来咱们再来说说程序员心目中的运营又是什么样子的。

近期，某互联网公司的一名产品运营师说，一名程序员小哥哥对她说：运营每天都是吃吃水果唠唠嗑、数据表都被程序员做好了，她们就下载现成的，看看环比升降 写写原因，感觉这样的工作真是清闲无比。我想这名产品运营师听了之后感觉一肚子委屈吧，不过她并没有为此反驳，而是把这样的事实分享出来，然后她这样的分享引来了一波网友们前来回复，其中运营的网友居多，我们看看他们都是怎么说的吧。

知乎产品运营：「运营就是打杂的」为了扭转这种误解，我要奋斗终身

上世是朵花：从这样的话，看出这名运营同学有很多委屈了。

某公司运营主管：哪里那么简单……老板发火劈头盖脸骂

上世是朵花：能想象到画面，运营同学也真是不容易了。

麦客电子运营专员：看来他很羡慕运营

上世是朵花：普遍现象，每个工种都是能看到其他工种的清闲，却看不到他们的辛苦。

脉脉内容运营专员：技术小哥哥曾经跟我说：搞成自动化功能后你们不就失业了么，我是为了你好

上世是朵花：没错，经常听到有程序员同事半开玩笑的说这种话，其实自动化一点只能说让运营同学省出一些工作量，去做更重要的事情，失业还是不可能的。

58集团产品运营师：运营说：为了你们在工作上有所突破、请务必搞成自动化

上世是朵花：这是运营同学们的心声啊，运营同学希望程序员们搞成自动化，他们并不担心自动化后自己会失业，因为他们深知运营还有其他好多事情要做的，是程序无法替代的。

腾讯科技内容运营：不少人都认识不到运营真正干嘛的 我觉得以后运营肯定会和产品一样成立一个体系

上世是朵花：是的，每个领域都有它的深度，外行看来只是表面的东西，所以就不免觉得简单。

南京汇龙科技有限公司运营经理：………现在这运营不好弄 哪种都要知道点……尤其是和产品沟通的时候还要懂点交互

上世是朵花：能够理解，特别最后一句，体会颇深。

蜗牛学堂运营总监：最开始就没有产品和运营，只有市场和技术。后来才有了运营和产品。

上世是朵花：每个工种都是根据市场演化的产物，存在就有存在的道理，都是其他工种无法替代的。

从评论的内容就可以看出，运营同学们也是有一套很强大的体系，他们也有很多的艰辛，不只是看看报表那么简单，报表只是他们研究策略的数据基础，这只是他们工作的开始，基于数据做出策略后，他们要制定不同的方案，各种策划活动，并且都是非常灵活的，目前的技术还是远远不能替代运营同学所做的事情的，程序员的看法是片面了一点，我想不只是这位程序员小哥哥是这么看的，有相当一部分程序员朋友都会有类似的看法，这就是行业领域视野角度问题造成的，大多数人看问题都是站在自身的那个角度去看问题，而不是跳出来站在更高的角度去看，同样，其他行业，其他工种的人看待程序员也存在类似的现象，不是么？

以上所有图片均来之互联网 大家好，我是“上世是朵花”。如果你有什么好的看法或者观点可以在评论区展现你的才华，互动交流，如果想进一步了解我，那就关注我吧！

文/老鬼

发布于56分钟前

阅读165

评论0

喜欢1

标签：

产品经理

产品历经了研发测试，终于可以如期的上线了，但请不要松懈，后续的活动才是重点。并且随着网站一起上线的还有我们的数据分析系统，作为产品运营及后续改进的支撑点，数据分析系统是我们的眼睛和耳朵，是我们感知产品的触角。所以下面着重说一下怎么做数据分析，需要做些什么。

一、网站分析原则

可行动：明确的目标及着力点，不要为了分析而分析，明白分析的最终目的是促进网站的改进，很多时候，产品经理都会陷入为分析而分析的怪圈，可能是为了给出一份看起来十分完美的数据报表已应付领导的检查，也可能只是闲着无聊就随意的去分析数据。

但朋友，作为产品人员，我们主要是目的是为了推进产品的发展，已达到更好的服务用户，解决用户痛点的目标，而不需要一堆无用的数据。

以用户为中心：分析的目的在于改进网站，而改进的目的在于更好服务当前用户及吸引潜在用户，以用户为中心的本质在于分析用户需求点，这些需求点是否被满足，没被满足的原因在哪里。

二、什么时候做？

可能有有部分产品人员会认为：我的网站还不够成熟，没必要那么早的投入精力做分析。但其实，数据分析是贯穿产品的整个生命周期的，作为一个产品人，我们时刻坚信，用户是会说谎，但数据不会。而且正如伟人所说，教育要从娃娃抓起，我们总不能因为孩子还小就不关注他们的教育活动。

其实对于产品经理而已，产品就是我们的小孩，我们不仅需要关注其最终的结果，还需要时刻监控他，分析他，找出不完善的地方，改进他。俗话说的好“磨刀不误砍柴工”，网站分析并不是一件投入很大的事情，缺能带来极高的产出，何乐而不为呢。

三、怎么做？

明确产品是需要进行数据分析，剩下来的就是我们应该分析什么，怎么分析。对于产品人员来说，数据分析是一个产品成本极低的工作，我们可通过页面标记或日志分析获取到所需的数据，所说的页面标记就是通过在合适的点插入一定数量的脚步去分析用户的行为。

而日志分析法，正如其名所表述的一样，通过分析产品的日志，监控产品的运行情况，幸运的是现在市面上，提供各种高效且专业的工具，为我们的数据分析提供支持，例如：Google Analytics， 百度统计，Flurry，友盟，有需要的小伙伴可以去其官网查看。

四、达到什么目标？

建立并维护业务数据模型：将网站的数据变化与用户的行为关联起来，这种联系建立起来后，一旦网站的数据发生了变化，就可以快速的定位到对应的用户行为

比如，常用日流量数据模型为：日流量=日访问用户数+平均浏览网页数，但日流量这一重要数据发生变化话，就可以通过对应的业务数据模型定位相对应的日访问用户数和平均用户浏览网页数等具体的用户行为，通过进一步分析用户的行为，去发现具体的问题，并给出对应的解决方案。

对产品更新、营销活动等进行专项验证，评估效果，总结经验：跟进设计与验证并行的原则，在产品新需求提出的时候，需要配合测试用户，用来检验产品需求最终是否被正确的实现。同样，我们在制定产品更新计划和营销计划的时候，也需要给出这些计划预计达到的数据指标和验证方法。针对营销效果，可以进行来源分析分析法，分析对应的用户的来源，已实现最优化的投产。

监护产品的健康情况，确保产品完成KPI（关键绩效指标）：对产品的关键指标进行预测，为商业计划提供数据支持。产品年度商业计划作为产品经理的一下重要的阶段性活动。不仅是产品经理对于产品的总结与预测，更为重要是产品经理和老板对话的重要桥梁，作为老板他们不希望手下的产品是个黑盒子，投入产出比无法预测。但年度商业计划中的收入预期和成本需求（人力，服务器，带宽）不是拍脑袋就能拍出来的，是靠业务数据模型和历史数据推测出来的。

五、其他方法

细分：将对应的数据、任务，细分为可被衡量及执行的部分，比如PV。对于产品经理而言，每天盯着PV并不能将PV盯上去，我们需要做的是细分的分析影响PV的各种因素，然后逐一解决，只有完美的解决了个点中的数据，才能把整体的数据给提升上去。比如投放了一个引导页面，用户到达了这个页面却不能被引导到对应的网站，我们就知道引导页面一定出现了问题，导致用户不会进入下一步操作，这个时候，就要赶紧疏通，细化问题，逐一解决。

对比：历史数据，竞争对手数据：孤立的单独看一份数据是没有意义的，对于产品经理，数据应该是在一定的维度上分析，可以是结合历史数据看趋势，也可以结合竞争对手的手机看表现，数据只有经过对比，才会有其独特的意义。

前言：时光匆匆，新的一年我们打算招一个正式的数据产品经理，去整理、规划和设计一些数据产品需求，而我的重心还是在于洞察数据中的玄机，就这样，最近两周我已经参加了五场面试，但是效果和预期的差距很大。

说明：这篇文章是去年写的，最近有不少朋友又提到这事，所以再重温旧文一下。

一、面试所带来的思考

最近两周，我参加了一些面试，也认识了些朋友，他们都是来应聘数据产品经理的。

我喜欢和应聘者聊天，了解他们的背景、专业知识和学习情况。换个角度去思考和发现问题，也许能够找到一些曾被忽视的细节。

考虑到数据产品经理这个岗位也是近年才火热起来的，有相关实战经验的相对来说比较稀有，市场空白的确大，又是一个高薪岗位。所以我们把面试门槛也设置低了些，转型从业者，也给予机会去评估考虑。

所以最近来应聘的朋友，都是从各个岗位转型过来做尝试。有业务分析员、产品经理和开发人员。针对目前来应聘的朋友，我都统一考察这三个方面，业务能力、产品能力和数据能力。

看起来比较笼统，但已经囊括了这个岗位所需要的综合能力，所以才说是一个门槛比较高的一个岗位。而对于具体细节，主要测评了这几个点：

数据素养。数据产品的认识和理解。互金领域业务流程和业务运营的分析能力，用数据说话，寻找业务痛点。推动产品从需求到落地，和产品运营的经验，以及这过程中的沟通、协调资源和进度把控能力。对大数据生态圈技术的熟悉，了解产品底层的数据处理流程和数据挖掘扮演的角色性。

上面这些是我当初评估的一个参考，能力阶段从上而下。或许和你们想象中的数据产品经理存在一定的差异性，完全可以理解，准备不充分也可以系统性学习。

但从目前的面试效果来看，不是很满意，所有来面试的朋友多多少少会存在一些严重的问题，每个人的侧重点也有所差异，主要会体现在这些方面：

数据素养缺乏，对数据不够敏感，没有学会用数据说话。对业务分析不够透彻，缺少从业务运营中发现痛点问题，转化为数据产品的可能性。对产品经理的认识停留在视觉、原型和交互上，没有一个完整产品推动落地的过程。对大数据生态圈的一切浑然不知，对大数据产品的认识停留在业务报表阶段。

大部分来应聘的朋友都在一面时候就结束了，事后我也会和他们聊别的内容，以及如何更好的去融入数据产品经理这个岗位？私下可以做哪些准备？（有个别的朋友还互留了微信）

"毕竟这个岗位市场空白还很大，只要有这个心和努力，有大把机会等着每一个想成为数据产品经理的朋友，而我也很欣慰能够看到这么多人想投身于大数据圈子里。" 这是当时我和每一个朋友都说的一句话。

初春来了，喝些鸡汤暖暖胃也还是不错。

所以，反思了最近的一些面试，我还特意网上搜了一些数据产品相关的资源来看看，的确十分匮乏和不全面。

本来这个岗位就稀少，对新人而言更遥不可及。各种约束，注定会造成这个现象的恶性循环。所以我想写这篇文章的初衷，主要有这两点：

揭开它的神秘性，只有清楚它在做什么事，需要哪些综合能力，才能针对性去准备。希望大家能够一起努力，去彰显数据产品的重要性，提升大数据的价值，提升自己的价值。

二、你怎么理解数据产品？

在聊完数据产品经理这个岗位的要求以后，不可避免的需要去聊聊数据产品。

到底何为数据产品呢？

一种知乎体回复

难道白猫黑猫，都是猫？产品和数据产品，都是产品？

上面这层理解，看起来没错，但是未免太过于肤浅了，仔细琢磨缺乏可参考性。如果真要细分产品和数据产品的区别，我觉得可以参考这三个点的差异性：

解决的痛点问题前者，增长平台的用户体量，提高交易额和用户粘度。后者，更细，去挖掘用户的潜在需求、生命周期和异常风险，服务于前者。产品的目标人群前者，服务于公司外的用户群体，去满足他们的常规需求。后者，服务于公司内的业务团队，甚至是第三方公司，去辅助他们更好的运营。面对的业务场景前者，适用于平台运营过程中的战略调整。后者，适用于突破平台运营遇到的瓶颈问题。

对于产品本质而言，都是在解决目前痛点问题和引导用户的未来需求。

很多朋友对于数据产品最直观的印象只是停留在数据报表，比如阿里指数和谷歌分析等等，其实这是很基础的数据需求。真正的数据产品是建立在大数据场景下数据挖掘得以价值体现后的产品化，最后再融合进业务产品流程中去做辅助业务和风险干预。

除了通过数据去发现问题，运营人员和老板最更关心的是去解决痛点问题，这才是大数据价值的提现，而不仅仅是整合数据，数据展示。

这也是为什么目前市面上缺乏难以有分量的数据产品的原因。在当下，大数据谈的火热，更多给人忽悠，不切合实际的感觉，能够挖掘出大数据的价值已经很不错了，更别提数据产品化。

三、我和数据产品的哪些事

我和数据产品结缘有很长一段时间了。

在以前的文章里也提到过，我读书时，参加了很多数学挖掘相关的比赛，也取得了不错的成绩。

可后面觉得这种形式去探索数据的价值，研究氛围大于实用性，所以接下来就索性放弃任何相关的比赛。

我迷糊了一段时间...

后面偶然的一次机会，我接触到了大数据，看到了一本书，当时作者就对数据产品有了一定的理解。

虽然当时很多概念还停留在数据展示上，但是书中已经告诉了读者，这个岗位未来具有很大的机遇，还是一张白纸。

这对于寻找数据价值的我来说，似乎找到了一个正确的方向，就这样默默坚持到现在。

但是这一路也并非顺利。

实习那年，我校招去应聘阿里的数据产品经理，那是个菊花开放的高潮。

我整整花了半个月的时间，对阿里平台目前的所有数据产品做了一个调研，整理了一份数据产品经理的素养，以及构思了一款数据产品的雏形。

当时给我印象最深的一句话。

“21世纪的核心竞争就是数据的竞争，谁拥有数据，谁就拥有未来。”：马云

可毕竟门槛很高，由于缺乏实践，过多的理论、概念和情怀难以感动面试官，我到了二面就结束了。（不过据说当时招进去的朋友也都是转成数据分析师了）

我并没有放弃，为了这个情怀，曲线救国做了很多准备。

由于有三年的比赛经历，我接触数据挖掘的经验会比较多，所以一开始我没选择从事数据挖掘这个岗位。

我选择先去了解大数据生态圈的底层数据源和数据加工，知晓数据的流向。在那段时间里，我独立维护了一款类阿里指数的数据产品，对数据和业务指标的理解提升得很快。

后面换了工作以后，主要也是做数据产品的乙方公司。我把重心放在业务层面上，经常和运营人员、甲方公司老板和阿里的数据产品人员打交道，那段时间对业务痛点和数据产品的认识提高不少，发现了数据产品原来有更大潜力。

远远还没结束，大数据挖掘和传统的模式有很多差异性，不管是数据量级，实现形式上，还是服务的业务场景上。

所以围绕着大数据挖掘，我学习了大数据生态圈中的相关技术，就像知晓的MapRedcue和Spark等等。

除了做一个理论者，我们更多的是需要不断去实践，将我们的想法落地。

长路漫漫，可有心的人耐得住寂寞，不到黄河心不死。

在最近半年的时间里，我也写了目前围绕着数据产品在做的事，分了上、中和下三篇。

这款数据产品是涉及互金行业的羊毛党反欺诈监控，已经上线稳定了三个多月，接下来是用心运营的阶段。

而这不代表什么，它却是我默默努力的一个反馈。不为了别的名和利，就一个欣慰就足够我很感动了。

说到这里，数据产品这条路，还有很多值得我们去探索的方向，我也还需要更努力，去做一个默默的先驱者。而你们呢？

真心期待未来去应聘数据产品经理的朋友们，用心准备，这个岗位可没你想象中的如此容易。

2017 年马云在某次年会演讲中提到一件让他惊讶的事情。

在西湖边上他曾看到乞丐在用支付宝收款码进行乞讨，从界面操作上看该乞丐还能熟练应用支付宝提供的「生意通」功能，研究本周的乞讨收入趋势以及单位小时的乞讨金额，从而为自己制定更加高效的的乞讨策略。

图片来源于网络

乞丐都在用数据分析来武装自己了，身为互联网从业者，你还敢落后？为了让你感知到数据分析对工作效率提升价值，我们来看一个真实的运营案例。

你为什么要学习数据分析

运营研究社在 2018 年以前，公众号图文的推送时间是不固定的，在早上、中午、下班时间、深夜都有过推送，所以相应的阅读量的波动也非常大。

在今年年初我提出了一个假设“如果把推送时间固定的话，会不会对图文打开率（阅读量）的提升有促进作用”。

为了检验这一设想，当时我需要解决的第一个问题是：

“运营研究社的公众号黄金推送时间在哪？”

我导出了运营研究社过去 1 年里的图文数据，并拿推送时间、打开率、标题 3 个数据字段来构建散点图。

运营研究社过去半年图文数据

从过去 1 年的推送时间和打开率的散点分布图来看，高打开率的图文主要集中在中午 12 点、13 点两个个时间段，于是我把将这两个时间点定义成运营研究社图文推送的黄金时间。

在实践中也证明了“在固定时间推送内容有利用提升打开率”假设是正确的，从阅读数据上的反馈就是我们的阅读量在 3 个月时间里提升了 200%。

无论是在生活还是工作，数据分析已是一项必备技能。

我在招聘网站上研究了近 100 个运营岗位的职责要求，用户运营、内容运营、产品运营、社群运营、渠道运营，它们几乎都会在靠前的位置写上这样一行文字：

“通过有效的数据分析（点击率，访问，转化率等），研究分析用户的需求制定运营策略”。

为了让你能够掌握最实用的数据分析技能，本篇文章将带你了解数据分析字段与产品指标、熟知数据驱动运营的底层方法。

“竟巧妇难为无米之炊”，为了让小伙伴们赢在起跑线，下面将开始系统讲解数据分析里的底层元素——数据字段。

你的基础数据字段足够全嘛？

2015 年我在百度贴吧在内容运营，当时的我们核心 KPI 是将次日留存率提升至 45%，于是我就想研究用户首次登入的内容消费量与次日留存的关系，以期通过优化内容推荐系统来提升次日留存。

想法很好，现实却很悲剧，我在给技术同学提数据分析需求时，他们很佛性的回了句：

“抱歉，我们没有统计用户的内容消费数据”。

由于缺乏用户的内容消费数据，我当时只能搁置这套数据分析方案了（在补充统计用户消费字段的 1 个月后才最终落地执行）。

跟大家分享这个案例，主要是希望大家能够理解，数据分析的底层关键支撑是基础数据字段，没有基础数据字段你的任何数据分析方案都执行不了，没有基础数据字段，你再老司机也无法用数据驱动运营。

所以，为了能够做好数据分析，你需要尽可能全面的提出你的数据字段需求，具体来说包括如下 2 类基础数据字段：

1）用户信息数据字段

它指的是用户的社会信息数据，比如姓名、性别、出生年月、籍贯、婚姻、学历，手机、邮箱等字段

对于电商和母婴类产品来说，还需要基于「用户行为数据」推导家庭类型、家庭人数、家庭小孩标签、工作岗位、所处行业等高级用户信息数据字段。

2）用户行为数据字段

用户行为数据字段在记录时的格式通常是User id（哪个用户）+Active（哪种操作）+Time（何时产生）。

比如今天上午，我在贴吧客户端首页看了一篇与 China Joy 有关的的贴子，并且还对妹子们的颜值留进行了评轮。那么贴吧官方会将我的看贴行为数据，以如下格式被统计下来。

用户行为数据字段是每一位用户在产品上操作行为的数据记录，不同产品类型需要的需要记录的用户行为是不一样的。

阅读内容、点赞、评论、分享是社区产品的关键用户行为字段，点击产品、添加购物车、下单、付费、评价是电商产品的关键用户行为字段……

相比于用户信息数据而言，用户行为数据是数据分析的重中之重，可以基于用户行为数据的处理加工，分析出每天产品的登入用户总量（DAU）、新用户留存以及评论用户总量等产品数据指标。

促进数据增长指标都有那些?

有两位内容运营的同学，有一天领导问他们最近的产品情况怎么样。

其中一位运营说产品表现很不错，每天都有很多人互动和称赞，另外一位运营回答说产品有问题，用户都不怎么会将内容分享出去。

如果你作为老板，你应该相信谁？

我想这两位同学你应该都不会相信，甚至还会很生气，因为你的员工没有一点点的数据分析意识。

现代管理学之父彼得·德鲁克说过一句很经典的话：

如果你不能衡量它，那么你就不能有效增长它。

为了能够让数据驱动业务增长，我们需要制定业务的衡量标准，用统一的衡量标准来定义和评价业务，这个统一的标准在数据分析中叫做指标。

案例中的两位内容运营如果能够以互动率和点赞率、分享率这 3 个产品数据指标来向领导汇报自己的运营工作的话，或许就能够在领导心中留个好印象了。

了解和使用指标是数据分析思维的第二步，我们需要基于具体的业务需求设定能够驱动产品增长的指标。（Ps：数据指标是由用户基础数据字段处理加工而成）

按照比较受大家认可的 AARRR 产品增长模型，我们可以将指标分为五大类：拉新指标、活跃指标、留存指标、转化指标、传播指标。

5个产品的拉新指标

运营通过渠道投放让“用户”接触到产品，当“用户”觉得产品不错就会去下载它，打开产品发现里边的内容蛮适合自己，“用户”就会注册产品，最终成为产品真正的用户。

以上是绝大部分运营都会经历的拉新过程，如果你想监控整个过程，并且评估拉新的执行效果，那么你就需要设置如下数据指标。

1）浏览量

俗称曝光量，指的是产品的推广信息在朋友圈、搜索引擎、应用商店等渠道渠道中被多少用户看到。与浏览量相对应的是点击量，它们俩的比例在业内有一个专业词汇 CTR（CTR=点击量/浏览量），很多广告平台会用 CTR 来评估广告质量。

2）下载量

指的是 App 的安装次数，是衡量拉新效果的结果指标。不过，App 下载其实是一个中间态，为了让产品从曝光到下载有一个高转化，你需要注意应用大小、介绍文案的打磨。

比如游戏类 App，为了避免怕漫长的下载时间造成玩家流失，会选择让用户下载后以补丁形式完成全部素材的加载。

3）新增用户

下载并不是意味着就是用户，如果某个“用户”只下载了并没有注册，那它就是一个无效的用户。对于用户的界定，每个产品是不一样的，大部分的产品是用户注册了 App，就被定义为用户了，比如知乎、微博、小红书、百度贴吧。

4）获取成本

用户获取必然涉及成本，而这是运营新手最容易忽略的。目前常见的成本的计算方式有 CPM（千次曝光成本）、CPC（单次点击成本）、CPA（单次获客成本）。

5个产品的活跃指标

相比于下载量和用户量而言，在人口红利消失后，大家开始更关注实实在在的东西了——你到底有多少活跃用户。

用户活跃作为运营的核心工作，不论移动端、网页端或者微信端，都有相关指标可以衡量。

1）活跃用户数

DAU 指的是日活跃用户数量，指的是在 24 小时内活跃用户的总量。把时间周期拉长的还有周活跃 WAU 和月活跃 MAU。（MAU 指的是一个月时间周期里去重后的活跃用户总和）

Ps：与活跃用户相对应的还有流失用户、忠实用户、回流用户，其中流失用户是长期不活跃，忠诚用户是长期活跃，回流用户是曾经不活跃或流失，后来又再次打开产品的活跃用户。

2）活跃率

活跃用户数衡量的是产品的市场体量，活跃率看的则是产品的健康。

比如说某款产品的 DAU 是 100 万，可能你觉得还不错，但是我跟你说它的总注册用户是 1 亿，活跃率仅为 1%，你的感受可能就是这款产品很不错了。

3）在线时长

现在数据分析也越来越注重用户行为了，为了深入研究一款 App 的活跃健康度就需要去研究在线时长（它是视频类网站的核心数据指标）。

不同产品类型的访问时长不同，社交肯定长于工具类产品，内容平台肯定长于金融理财，如果你是做内容的产品的，发现大部分用户访问时长只有几十秒，那么最好分析一下原因。

4）启动次数

它体现的是用户的使用频率，用户的日均启动次数越多，说明用户对产品的依赖性越高，活跃度也就越好。

社交产品的人均启动次数会在 3-5 次之间，是通互联网中在启动次数指标中数值最高的。

5）页面浏览量

PV（PageView）是页面浏览量，UV（Unique Visitor）是一定时间内访问网页的人数，用户在网页的一次访问请求可以看作一个 PV，用户看了十个网页，则 PV 为 10。

PV 是互联网早期 Web 站点时代的活跃指标，也可以理解为网页版活跃。

5个产品的留存指标

如果说活跃数和活跃率是产品的市场大小和健康程度的话，那么用户留存衡量产品是否产品能够可持续发展，如果你是早期产品就更应该关注是留存指标了。

1）用户留存率

留存率 = 留存用户 / 当初的总用户量

用户在某段时间使用产品，过了一段时间后，仍旧继续使用的用户，被称为留存用户。

假设产品某天在某渠道新增了用户 1000 个，第二天仍旧登入产品的用户有 350 个，第 7 天仍旧登入产品的有 100 人，那么这个渠道获取来的用户次日留存率有 35%，那么称七日留存率为 10%。

Facebook 有一个著名的 40-20-10 法则，即新用户次日留存率为 40%，七日留存率为 20%，三十日留存率为 10%，有此表现的产品属于数据比较好的。

2）用户流失率

用户流失率和留存率恰好相反，如果某产品新用户的次日留存为 30%，那么反过来说明有 70% 的用户流失了。

流失率在一定程度能预测产品的发展，如果产品某阶段有用户 10 万，月流失率为 20%，简单推测，5 个月后产品将失去所有的用户。

Ps：这里可以引出一个公式，生命周期 = （1 / 流失率）*流失率的时间维度。比如产品的周流失率为 50%，那么平均用户生命周期为 14 天。

15个产品的转化指标

运营而言，拉新和活跃、留存都只是手段，最终衡量你工作业绩的是你手上掌握了多少有价值的用户。

运营就像用户成长路上的指引者，指引者产品里的用户成为能够产生价值的超级用户，即回归商业的本质。

交易类产品转化指标

1）GMV

它是一个虚荣指标，只要用户下单，生成订单号，便可以算在 GMV 里，不管用户是否真的购买了，京东在双十一对外发布的战报是 GMV。

2）成交额

成交金额指的是用户付款的实际流水，是用户购买后的消费金额，天猫在双十一对外发布的战报是成交额。

3）销售收入

它指的是成交金额减去退款后剩余的金额，属于内部机密数据了。

如果把上述的三个指标看作用户支付的动态环节，则能再产生两个新指标。

成交金额与 GMV 的比率，实际能换算成订单支付率，它体现的支付的流畅度；销售收入和成交金额，也涉及到了退款率，它体现的是产品质量。

4）付费用户量

在产品里边产生过交易行为的用户总量，同活跃用户一样，交易用户也可以区分为首单用户（第一次消费），忠诚消费用户（持续购买的用户），流失消费用户（流失后又回来的用户）等。

同时，为了研究用户的付费潜力，你还可以研究下产品的付费用户比例：

付费用户比例 = 付费用户 ÷ 总注册用户

5）ARPU

在单个促销活动中，它指的是每一笔用户订单的收入，总收入/订单数。而在整个产品生命周期中，我们更关注用户平均付费，总收入/用户数。

ARPU 可以再一步细分，当普通用户占比太多，往往还会采用每付费用户平均收入：ARPPU = 总收入÷ 收费用户数

6）复购率

和新增用户一样，获得一个新付费用户的成本已经高于维护熟客的成本。复购率更多用在整体的重复购买次数统计：单位时间内，消费两次以上的用户数占购买总用户数。

比如运营研究社的技能训练营在第一季度有 1789 个付费用户，购买次数在两次以上的有 657 人，那么我们季度复购率是 36%。

社区型产品转化指标

社区型产品的首要目的是将用户聚集在一起，并且引入用户生成内容，它的核心关键在于培养一个能够生成内容的活跃用户社区。

1）内容生成者

参与内容生存的用户�...

对一家互联网公司来说，如果没有设置单独的数据运营岗，那么用户运营是和数据最贴近，也必须是最了解用户的。

用户运营核心的方法论就三个：拉新，促活和留存。拉新可以作为渠道推广单独讨论，而促活和留存则相辅相成。

非运营岗，或者其他类型的运营，通常只会注重一个活跃数据的果，而不会注意活跃数据的因。我们在这里就抽丝剥茧，教大家比较快速地了解活跃体系。

互联网公司对活跃用户的定义大同小异，主要以用户打开APP一次记为一个活跃用户。

按此基础可以在时间维度引申出周活跃用户，月活跃用户。即在一个自然周内打开一次APP，则本周为周活跃用户。月活跃用户同理。

我们假设有一款新产品，这是它四个月内的活跃数据。嗯，看来不错。

产品专注的市场领域不同，活跃用户数天差地别。一款小众的垂直领域产品和泛社交类产品，单纯看活跃用户数，你很难界定它们好坏。

好的数据指标，都应该是比例或比率。

我们设定一个新指标，活跃率：某一时间段内活跃用户在总用户量的占比。

按照时间维度引申，有日活跃率DAU，周活跃率WAU，月活跃率等MAU。

例：月活跃，本月活跃用户在截止月末的总注册用户中占比。

一般而言：活跃用户数，看的是产品的市场体量。活跃率，看的是产品的健康度。

实际得承认，不同产品，用户需求（高频或低频）不同，活跃率也有差异。用户运营更多的职责是监控活跃率的变化，并且提升它。

看，我们的活跃用户数上升，活跃率下降，这对新产品来说很正常。你不能要求每一个用户都使用我们产品不是？

别急，我还没补刀呢。

我们统计了注册用户数，那么我们也可以统计出本月新增用户数，很简单，两个月相减。

是不是看出来什么了？

要知道，按照活跃的定义，新注册的用户肯定是打开APP的用户，他也一定是活跃的用户。

所以，我们拿每月的注册总用户数减去新增用户数，计算老用户数。并且将新老用户的活跃率独立出来。

指标拆分后，我们发现老用户的活跃率比预期低。实际在产品早期、渠道投入资源推广、或一次成功的病毒营销后，因为新增用户数量的暴涨，总是会带动活跃数的上升。

A产品打算在五月份做大投入，在APP上进行活动，希望用户大力参与，同时在B渠道进行推广。在常规的统计指标中，发现活跃数据上升。事后分析发现活跃为新增活跃，老用户的活跃数据没有显著上升。配合其他活动数据，证实活动效果较差。

C产品获得投资后，通过大规模的烧钱推广，获得一个正向的活跃数据反馈。此时活跃有不小可能是由新增用户撑起的。产品自身的打磨若不好，老用户活跃率不会提高，这也是我们常说的留存概念。导致钱白白浪费不少。

产品进入稳定期后，有了一定用户规模，新增活跃一般对活跃数据就不会有大的影响了。那么以新老用户区分活跃统计就够了？我们简单定义三个场景：

用户A下载产品后，把玩了一段时间，发现这是他想要的功能，爱不释手，成为发烧用户；

用户B下载产品后，看了几眼就不再使用。产品2.0发布后，觉得有个新特性不错，于是回来继续使用，逐渐成为活跃份子；

用户C从网上看到随便下载的，用了产品觉得一般，吐槽几句并且卸载，不再使用；

用户包含各种类型，反应了不同群体的特征和想法。在使用整个产品的周期中，我们应定义更全面的指标：

流失用户：

有一段时间没有再打开产品，那么我们就视为流失用户，根据产品的属性，可以按30天，60天，90天等划分。

不活跃用户：

有一段时间没有打开产品，为了和流失区分开来，需要选择无交集的时间范围。比如流失用户是60天以上没打开产品，那么不活跃则是0～60天没打开。

回流用户：

有一段时间没用产品，之后突然回来再次使用，则称为回流用户。回流用户是活跃用户，且是由流失用户或不活跃用户唤回而来。

活跃用户：

一段时间内打开过产品。

忠诚用户：

也可以叫超级活跃用户，长期持续使用产品，比如连续四周，或者一个月内15天等。

现在我们发现，不论是活跃用户还是不活跃用户的维度，都一下子丰富了起来。

通俗的理解一下用户活跃的变化

上文ABC的三位用户活跃路径为：

A：新增—活跃—忠诚

B：新增－不活跃－回流－活跃－忠诚

C：新增－不活跃－流失

回到一开始那款产品的数据，我们将分解后的新指标统计出来。（定义忠诚用户一个月内有15天活跃；流失用户为两个月没打开过）

（以上数据以月末当天的统计为准）

你看，指标开始变得复杂了。产品有长期使用的忠实用户，也有流失用户。有用户回来继续使用，也有用户不怎么爱用产品。

数据是为了方便讲解随手编的。实际的情况可能会更复杂，可以根据情况灵活应对。

用户活跃可以简化为一个最简单的公式：新增用户的数量要大于流失用户的增加量。可以想成一个水池，运营会一直往里灌水，但是水池也会漏水，如果漏水速度太大，那么水池就干了。一款产品可能因为市场竞争、拉新乏力导致新增用户数下降，也可能因为产品改动，运营策略失误造成后续流失用户变多。

将数据制作图表：

(活跃用户和不活跃用户可以拆分出来，周活跃同理)

用户运营们可以按照日、周、月维度维护三张报表，监控活跃数据的变化（建议花更多精力在周报表上）。

如果是一个好的用户运营，他会继续思考：每天有多少活跃用户变得不活跃？有多少忠诚用户变得不活跃？又有多少流失用户被我们唤回来等，并且分别是什么原因引起的。

怎么样更详细的监控活跃数据的变化呢？我们引入桑基（Sankey）图的概念。

这时，活跃数据比单纯的表格清晰多了，而且我们也能够显著观察到不同活跃层的变化。万千变化，存乎一图。 有了数据和趋势，我们应该聚焦更多精力到怎么去应用在运营和业务上。

观察忠诚用户，发现他们有什么特征，为什么爱用我们产品。同样的道理，我们也能观察流失用户；

忠诚或流失用户是否在推广渠道上有显著差异（配合新增留存数据）。

某一段时间回流用户增加，是产品更新，市场推广，还是活动营销？

本周，变成不活跃的用户比以前多，要不要做一次用户访谈看下原因？

活跃的用户用Push营销，流失的用户用短信营销，这是不是一个好方法？

以上种种，皆是用户运营需要考虑，也是要和各部门协同解决，贯彻整个产品一生的运营方向。

活跃类指标有一个显著特点需要明白，它们都是后见性的指标，也就是事情发生后我们才能观察到。比如我们发现某一段时间流失数据（假定两个月没打开APP为流失）上升，往前倒推两个月，发现当时刚好展开一次活动，那么我们有理由相信活动造成了一批用户卸载，可惜运营此时已经无能无力。先见性预防比后见性观察对运营更重要。

根据不同的用户活跃状态，依据产品的特性能采取很多运营手段。这是精准化运营的第一步。接下来则是划分用户层次等，进行更精准的运营，不过那是另外的话题了。

产品运营三大核心指标：拉新、活跃、留存。相信每一个小伙伴都不陌生。

不同的产品阶段可能运营策略重心会有所不同，但肯定对于各种拉新活动并不陌生，例如H5活动、广告投放、软文扩散、渠道换量等。

每一轮的投放活动都需要衡量投入产出比ROI，每一次活动结束都需要进行复盘讨论，每一轮迭代投放都可能在验证一些猜想。

我们的目标是：用合理的投入成本，通过各类途径优化，最大化效果产出。

但实际的运营投放中，往往会遇到各式各样的投放方式：

这个渠道说，我们不能实现不了直接跳转下载；

那个渠道又说，我们是做品牌的，高曝光才是我们的优势，转化不关我事；

还有的时候，一个渠道上，就有3个不同的位置x3种素材x3种跳转方式，跳转应用市场之后到底下载了木有，打开APP了木有，效果怎么衡量，头有点晕……

但其实，我们关心的是以下几个方向：合理投入、优化路径、最大化产出。简而言之，我们关心的是：投入产出比。

（在不同的渠道进行拉新）

如何找到最大化的投入产出比，这是每一个负责拉新业务的小伙伴都曾经或者正在头疼的事情。

从上图的流程上看，我们可以优化的就是几个环节：产品是否吸引人、渠道是否优质、投放的方式是否高效、效果是否符合预期。

这里暂时不讨论产品定位，我们只讨论丰富多彩的渠道投放的效果优化。

我有100种投放姿势，就问你敢不敢试~

这里，我们虽然是以APP拉新为例，讨论的是一种多渠道效果数据分析体系，但其实适用于每一个就算不是APP产品，或者你的拉新不是以增加APP用户为核心，都可以复用这套数据分析框架。

设定预期目标

首先，对于任何一次投放活动，我们都必须界定它的目标产出。只有在清晰的效果衡量体系下，渠道数据的对比才有意义，多渠道的ROI才有可比性。

对于APP拉新的投放活动来说，常见的预期效果可能是：

提高对APP的认知（以传播广泛为目的）

成为APP用户（APP下载并激活）

在APP内完成特定行为（如购买、身份验证或者领取礼包）

我们以常见的拉新——“APP下载并激活”为例，先搭建一个数据漏斗，看看我们效果环节上需要观察哪些数据。

如果我们希望监控的是上述内容中③的效果数据，我们就在激活之后继续添加下一层级的漏斗，统计例如加入购物车、确认下单、付款这样的流程。

在这样的漏斗流程之上，我们可以搭建监控指标，有时候监控的数据可能无法实现理想的统计指标，我们可能会需要补充其他监控指标，有时候也无需如此精确的数据粒度。

我们最后监控的数据指标如下（表1）：

而效果数据部分，则可以通过MTA的新增报表——安装来源分析实现。

为什么这里增加了“下载所用网络占比”？

原因是在下载完成到安装，这两个事件属于APP应用市场的原生事件，开发者无法主动采集，但我们依然关心这其中的转化步骤，主要是担心用户如果处于较差网络环境下，下载行为可能会被终止，因此这里用了“所用网络占比”这样的辅助字段数据。

这里的辅助字段数据主要是为了优化转化效果所做的准备。确定了目标，我们第二步就可以做投放过程的数据记录了。

投放过程记录

做这一部分的数据记录，主要的目的，一是为了复盘的时候方便做分析对比，二是为了优化迭代的时候更有方向。

根据埃里克·莱斯的《精益创业》中的观点：每一次的实验迭代，其实都是为了得到一个经证实的认知。

应用在推广投放体系下，每一次投放策略的设计，都是为了验证一个投放策略的有效性，是为了提升效果产出。

这个环节是一个多路分支，我们需要做一些版本记录，以便更好的定位问题。过程图大致如下：

记录过程表2为：

（表2 广告投放策略记录）

*根据投放方式的不同，可能记录的方式也会略有不同

**具体的策略信息可以在详表中展开记录

然后把表1的效果数据映射在表2之后，得到一条投放活动的完整记录。然后就可以通过数据来验证具体的投放策略的有效性了。

验证目标是怎样的投放策略，这一点需要在投放开始前就规划好，这样数据分析的时候才能得到有效的结论。

分析与优化效果

对于搜集到的众多详细数据，我们接下来就可以做一些数据上的结果分析了。

首先，我们可能想验证的是投放素材对渠道1的banner-1的影响，那么，我们把表2中渠道1单独拿出来，可以得到如下表格：

（表3.投放素材对渠道1的banner-1的影响）

如果我们想比较渠道1上Banner和Feeds流的差别，我们可以得到：

我们也可以针对人群定向投放效果、不同的投放时间，乃至渠道效果质量对比等多个维度进行数据分析，通过数据来验证我们的策略，优化投入产出比。

所以，虽然说投放的姿势有千千万，但效果路径总是相似的。

如果你有丰富多彩的投放策略，不用急，不要慌，把路径理出来，控制策略的版本，采用A/B TEST等加快验证迭代速度，最终得到有效的投放策略与最大化的ROI效果。

以上是关于投放效果上的数据指标体系分享，相似的分析思路可以复用在不同需求的投放方案中，包括一些线上、线下的运营活动，其实也可以复用这个框架。

来源：pm28

20世纪30年代，宝 洁诞生了第一位产品经理，全权负责一款肥皂的生产、销售以及全流程的成功。

80多年后，随着互联网的蓬勃发展，出现了越来越多的产品以及和产品相关的各种岗位。；围绕产品的思维与工作方式被越来越多的人所认可，产品成功的思维模型被搬上了课堂。

数据报表，作为一个链接IT部门和业务的中间件，承担着信息沟通的作用：数据展示业务信息，为业务决策提供依据；业务产生数据，最终以数据报表的方式呈现。

同样，我们也可以用产品工作的方式来复盘一下搭建报表系统的整个流程，并且和产品的上线流程做一个对比。

产品的上线流程

市场分析——>竞争分析用户分析——>需求（场景）分析——>功能设计——>开发——>发布——>运营——>迭代

互联网产品初期，在初次面向市场的时候，产品往往是一个MVP（最小可用单元），通过种子用户的反馈，分析使用数据，验证产品的可用性，快速迭代，逐渐修正与完善。

报表系统的上线流程

同行业报表项目参考（行业咨询）——>业务部门需求采集分析——>报表设计——>上线——>end

绝大多数的企业在报表上线之后，都忽视了一个关键动作——运营，以致于IT部门陷入了一个怪圈，疲于应付业务人员的需求，天天加班工作却得不到认可。实际上，系统上线不等于终点，被大量使用与认可才是成功的第一步！

产品如何做运营

1、冷启动

冷启动是什么？冷启动是一个产品刚诞生的一个阶段，此阶段的产品面临着以下问题：

缺少用户及相关资源。产品模式未成熟，能否满足用户，迎合市场趋势仍是未知数

因此，在此阶段的主要目标的作用有：

根据数据分析，验证产品是否满足用户需求验证是否能符合市场趋势验证商业模式是否成立

互联网产品怎么做？

种子用户，聚拢一批符合产品目标人群的用户，获取真实的使用数据MVP（最小可用单元）验证，判断产品是否满足了目标用户的最小可用需求存失分析，依据用户的真实使用数据，分析留存的原因（建立产品优势），放弃部分的流失用户，修正产品的定位。

2、高增长

高增长是指在产品通过市场验证，处于快速发展的阶段，通过运营实现产品用户与价值的持续增长

互联网产品怎么做？

持续推广与曝光精细化运营，针对人群、场景、流程做差异化细分运营的运营策略，提升运营动作的效率最大化基于用户数据分析的产品不断迭代优化

报表系统如何运营

帆软的一家互联网行业客户告诉我们，为了让报表系统被业务部门认可，IT部门在上线报表系统的初期以及推广期主要做了4件事：

1、冷启动阶段

a.寻找种子用户

优先挑选了营运部门的管理层作为种子用户，依据需求为其定制了PC、移动端两张营运报表，报表上线后不断关注其访问量趋势，发现移动端模板的活跃度更高，并且用户对模板的评价非常好，随着口碑的传播，分公司的营运部门也提出了类似的需求，IT部门开始重新考量整个营运部门的需求，为其系统化的搭建报表应用

b.简单的用户数据分析

这个阶段的用户数量和模板数量都还处于一个比较小的数量级，只需要通过用户的访问数据，验证报表是否满足种子用户的需求

2、高增长阶段

a.从三个维度和两类应用场景分析用户的使用数据，关注性能与用户体验，促使报表系统不断优化

三个维度：

1、报表系统的整体访问趋势

——把控报表系统的整体运营状态，研究用户的访问习惯，合理分配资源

2、每一位业务人员的访问趋势

——充分掌握哪些业务人员的数据诉求更为强烈，那他们的数据需求被响应的优先级将会更高；那些一个劲提需求，却没有访问量的部门，我们需要重新核算成本，降低他们的需

求优先级

3、每一张报表的访问趋势与性能体验

——每一张报表都是一个产品，同样也有完整的生命周期，不被需求的报表要及时的淘汰，降低运维成本；访问量火热的报表要纳入优化迭代，提升用户访问感知，深挖需求，扩充业务场景

两类应用场景：

数据大屏/移动端报表

——什么样的数据分析场景更加在哪类终端上访问量更高？我们是否需要为其专门打造一张移动端的模板，更美观的样式，更人性化的交互效果？

b.主动推送与推广

——内容推广

伴随着报表系统的不断迭代，每一次为业务人员扩充的应用场景需要通过渠道来推广与宣传，促进用户的使用率，这个渠道可以是企业内部的宣发平台，也可以通过C端市场中的新媒体渠道（微信公众号等）

——报表推送

业务人员常用的报表可以通过帆软提供的推送功能直接触达最终用户，培养其对报表的使用粘性

帆软能提供哪些帮助

1、固化的用户行为数据分析

FS平台为用户提供了常用的运营数据统计功能

访问量数据：包含平台访问次数、模板访问次数、用户数等内容模板热度：不同模板在周期时间内的访问总数用户行为：不同用户在周期时间内的访问总数，并且区分统计出查询、导出、打印等不同的用户行为性能监控：不同模板的平均响应时间、平均内存等内容

注：模板热度、用户行为、性能监控数据统计需要安装“高级系统监控”插件

借助于常用的运营数据统计，我们可以对报表系统做一个整体的评估，对整体的访问量、模板热度、模板性能做到心中有数

2、深入的用户行为数据分析

作为数据分析的先锋，只要有数据源，没有IT做不了的运营数据分析。FR会将用户的访问数据存储至logdb数据库当中，可以直接通过设计器链接数据库定制运营所需分析模板

我们需要关注logdb数据库中的两张表与一个字段

表：PUBLIC.FR_EXERECORD

该数据表是报表正确执行日志表，即如果报表执行成功，将会在该表中添加一条记录，并在相应字段中填写其对应的信息记录

表：PUBLIC.FR_FSRECORD

该数据表是为了统计一段时间内，系统的使用情况，用于管理员查看在线用户数及用户系统使用情况，因此用户登录决策系统时，将登录信息保存入库，将会在该表中添加一条记录，并在相应字段中填写其对应的信息记录

字段：BROWZER

该字段记录了客户端访问报表所用的浏览器版本以及移动端信息terminal：包含终端类型、app还是h5等信息。例如：“terminal”：{"OS"："app"，"type"："mobile"}

借助于以上内容，我们就可以定制出自己所需的数据分析报表，重新把控报表系统的运营情况，为后续的迭代提供指引

3、主动推送与推广

帆软为每一种报表使用方式与场景都提供了消息推送的服务，包括了：平台消息推送、微信/钉钉消息推送、APP推送、邮件推送等