时间: 2021-07-30 10:59:13 人气: 8 评论: 0
如何才能构建一个完整的产品数据运营体系？Blues根据自己在YY工作的经验进行了梳理和总结，整个过程可以分为如下的11步，供大家参考。
本文内容将**从作者在**、YY的实战案例中详细讲解“11步构建产品数据运营体系”，如下：
在Blues十多年的互联网行业工作生涯中，很大一部分时间的工作是数据运营，从**秀到YY语音，再到迅雷，都经历了产品数据运营的流程优化、平台构建、分析应用等过程，亲历了数据在产品中的重要地位。
不少人对数据运营的理解，局限于数字统计、原因分析等，其实这些只是数据运营工作的一小部分，数据最终是为产品服务的，数据运营，重点在运营，数据只是工具。
数据运营是做什么的？个人的理解是：
制订产品目标，创建数据上报通道和规则流程，观测产品数据，做好数据预警，分析数据变化原因，根据分析结果优化产品和运营，并对未来数据走势做出预测，为产品决策提供依据，在产品策划与运营中融入数据应用。
通俗点说，数据运营搞清楚以下5个问题：
如何才能构建一个完整的产品数据运营体系？Blues根据自己在YY工作的经验进行了梳理和总结，整个过程可以分为如下的11步，供大家参考。
这是数据运营的起点，也是产品上线运营后进行评估的标准，以此形成闭环。制订目标绝不能拍脑袋，可以根据业务发展、行业发展、竞品分析、往年产品发展走势、产品转化规律等综合计算得出。制订目标常用SMART原则来衡量。
指工作指标要具体可评，不能笼统。例如我们制定YY语音基础体验的产品目标，如果是提升产品体验，则不够具体，每个人的理解不一致，当时我们的基础产品目标则是提升新用户次日留存，则非常具体。
指绩效指标是数量化或者行为化的，验证这些绩效指标的数据或者信息是可以获得的；提升新用户次日留存率，则需要给出具体的数值。
指绩效指标在付出努力的情况下可以实现，避免设立过高或过低的目标；新注册用户的次日留存率，也不是拍脑袋得出的，当时我们基于YY新用户次日留存率的历史数据和游戏用户的新注册用户留存率的行业参考数值，制订了一个相对有挑战性的目标，从新注册用户次日留存率从25%提升到35%。
是与工作的其它目标是相关联的；绩效指标是与本职工作相关联的；新用户的次日留存率，和用户行为息息相关，例如用户对语音工具的认可程度，用户对YY平台的内容喜好程度等，所以新用户的次日留存和产品的性能、内容受欢迎程有较强的相关性。
注重完成目标的特定期限。
产品目标可以这样制订：在2013年12月31日前，将YY语音新注册用户的次日留存率从25%提升到35%。
新用户次日留存率的提升，意味着更多用户的活跃转化，带动整个用户活跃数量的增长。
产品数据指标是反应产品健康发展的具体的数值，我们需要对数据指标给出明确定义，例如数据上报方法、计算公式等。
例如上文的次日留存率，可以定义为：次日留存率是一个比率，分母是当天新注册并在当天登录YY客户端的YY帐户数，分子是分母当中在第二天再次登录YY客户端的YY帐户数。
注意这里的细节，第一天和第二天，需要有明确的时间点，例如0点到24点，计算为一天；问题来了，一个新用户在第一天的23点注册并登录YY客户端，到第二天的凌晨1点下线；按照上面的定义，这个用户或许将不**被记录为次日留存用户，因为这里没有定义清楚数据上报细节。
定义是第二天再次登录YY客户端，上面案例的用户在第二天是没有登录行为的，但他确实是连续两天都在登录状态的用户。
所以针对这个定义，需要补充细节：用户登录状态，如果是5分钟进行一次心跳包的上报，那么这位新用户就可以被上报为第二天的登录状态用户，如果在0点5分之前下线之后，持续到第二天的24点，仍未有登录状态，那么将不被记录为留存用户。
我们根据产品目标来选择数据指标，例如网页产品，经常用PV、UV、崩失率、人均PV、停留时长等数据进行产品度量。定义产品指标体系，需要产品、开发等各个团队达成共识，数据指标的定义是清晰的，并且有据可查，不**引起数据解读的理解差异。
在数据指标提出的基础上，我们按照产品逻辑进行指标的归纳整理，使之条理化。
新用户的次日留存率是我们订制的一个核心目标，但实际上，只看次日留存率还是不够的，还需要综合考察影响用户留存率的多种因素，才能更准确的了解产品的健康发展。如图1所示，是常用的一种指标体系，包含：用户新增、用户活跃、付费、其他数据。
图1 互联网产品常用数据指标体系
在我们做YY语音客户端产品的时候，**用到下面的指标体系，包括：账号体系、关系链数据、状态感知数据、沟通能力等四大方面。具体指标有：好友的个数分布、观看频道节目的时长、IM聊天时长、个人状态的切换与时长等，如图2所示：
图2 IM即时通讯产品数据指标体系
产品指标体系的建立不是一蹴而就的，产品经理根据产品发展的不同阶段，有所侧重的进行数据需求的提出，一般的公司都**有产品需求文档的模板，方便产品和数据上报开发、数据平台等部门同事沟通，进行数据建设。创业型中小企业，产品数据的需求提出到上报或许就是1-2人的事情，但同样建议做好数据文档的建设，例如数据指标的定义，数据计算逻辑等。
图3 YY事业部基础产品数据需求实现流程图（施行）
常见的数据上报需求，有两类：
表1 标准协议上报数据需求范例模板
表2 自定义协议上报数据需求范例模板
报名名称：YY事业部——基础产品组——游戏直播运营日报
这个步骤就是开发根据产品经理的数据需求，按照数据上报规范，完成上报开发，将数据上报到数据服务器。上报数据的关键是数据上报通道的建设，原来在**工作时候，没有体**到这个环节的艰辛，因为数据平台部门已经做了完备的数据通道搭建，开发按照一定规则，使用统一的数据SDK进行数据上报就可以了。后来在YY，属于发展型公司，则是从上报通道开始进行建设，也让我得到更多锻炼提升的机**。其中很关键的一个环节，就是数据上报测试，曾经因为该环节的测试资源没到位，造成不必要的麻烦。
很多创业公司没有自己的数据平台，可以利用第三方的数据平台：网页产品，可以使用百度统计（tongji.baidu.com）；移动端产品，可以使用友盟(www.umeng.com)、TalkingData(www.talkingdata.com)等平台。
例如下表，就是页面流量数据上报的发送函数send_web_pv，源于迅雷哈勃数据平台规范。
表3 页面流量数据上报的发送函数send_web_pv
下表是某直播做APP数据上报的埋点范例。（数据埋点，就是在功能逻辑中添加统计逻辑）
表4 某直播APP数据上报范例
ETL，是英文 Extract-Transform-Load 的缩写，用来描述将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程。
ETL一词较常用在数据仓库，但其对象并不限于数据仓库。ETL是构建数据仓库的重要一环，用户从数据源抽取出所需的数据，经过数据清洗，最终按照预先定义好的数据仓库模型，将数据加载到数据仓库中去。
下图是产品数据体系的一个常见流程图，数据采集、存储、运算，通常就在图中的数据中心完成。
图4 数据体系流程
确认完数据上报之后，接下来几个事情就比较偏技术化了。首先需要上报的数据通过什么样的方式采集和存储到我们的数据中心。
（1）数据采集分为两步
第一步从业务系统上报到服务器，这部分主要是通过cgi或者后台server，通过统一的logAPI调用之后，汇总在logServer中进行原始流水数据的存储。当这部分数据量大了之后，需要考虑用分布式的文件存储来做，外部常用的分布式文件存储主要是HDFS。这里就不细展开。
图5 原始数据上报存储到文件的架构图
数据存储到文件之后，第二步就进入到ETL的环节，ETL就是指通过抽取（extract）、转换（transform）、加载（load）把日志从文本中，基于分析的需求和数据纬度进行清洗，然后存储在数据仓库中。
（2）以**为例子
**大数据平台现在主要从离线和实时两个方向支撑海量数据接入和处理，核心的系统包括TDW、TRC和TDbank。
图6 **数据平台系统
在**内部，数据的数据收集、分发、预处理和管理工作，都是通过一个TDBank的平台来实现的。整个平台主要解决在大数据量下面数据收集和处理的量大、实时、多样的问题。通过数据接入层、处理层和存储层这样的三层架构来统一解决接入和存储的问题。
（1）接入层
接入层可以支持各种格式的业务数据和数据源，包括不同的DB、文件格式、消息数据等。数据接入层**将收集到的各种数据统一成一种内部的数据协议，方便后续数据处理系统使用。
（2）处理层
接下来处理层用插件化的形式来支持多种形式的数据预处理过程。对于离线系统来说，一个重要的功能是将实时采集到的数据进行分类存储，需要按照某些维度（比如某个key值+时间等维度）进行分类存储；同时存储文件的粒度（大小/时间）也是需要定制的，使离线系统能以指定的的粒度来进行离线计算。对于在线系统来说，常见的预处理过程如数据过滤、数据采样和数据转换等。
（3）数据存储层
处理后的数据，使用HDFS作为离线文件的存储载体。保证数据存储整体上是可靠的，然后最终把这部分处理后的数据，入库到**内部的分布式数据仓库TDW。
图7 TDW架构图
TDBank是从业务数据源端实时采集数据，进行预处理和分布式消息缓存后，按照消息订阅的方式，分发给后端的离线和在线处理系统。
图8 TDBank数据采集与接入系统
TDBank构建数据源和数据处理系统间的桥梁，将数据处理系统同数据源解耦，为离线计算TDW和在线计算TRC平台提供数据支持。目前通过不断的改进，将以前Linux+HDFS的模式，转变为集群+分布式消息队列的模式，将以前一天才能处理的消息量缩短到2秒钟！
从实际应用来看，产品在考虑数据采集和接入的时候，主要要关心几个纬度的问题：
完成数据上报和采集和接入之后，数据就进入存储的环节，继续以**为例。
在**内部，有个分布式的数据仓库用来存储数据，内部代号叫做TDW，它支持百PB级数据的离线存储和计算，为业务提供海量、高效、稳定的大数据平台支撑和决策支持。基于开源软件Hadoop和Hive进行构建，并且根据公司数据量大、计算复杂等特定情况进行了大量优化和改造。
从对外公布的资料来看，TDW基于开源软件hadoop和hive进行了大量优化和改造，已成为**最大的离线数据处理平台，集群各类机器总数5000台，总存储突破20PB，日均计算量**过500TB，覆盖**公司90%以上的业务产品，包含广点通推荐，用户画像，数据挖掘和各类业务报表等，都是通过这个平台来提供基础能力。
图8，**TDW分布式数据仓库
图9 TDW业务示意图
从实际应用来看，数据存储这部分主要考虑几个问题：
就是产品经理，数据分析人员从数据系统获得数据的过程，常见的方式是数据报表和数据提取。
报表的格式，一般**在数据需求阶段明确，尤其是有积累的公司，通常**有报表模板，照着填入指标就好了。强大一些的数据平台，则可以根据分析需要，自助的选择字段（表头）进行自助报表的配置和计算生成。
下面是做数据报表设计的几个原则：
（1）报表要提供查询的起始时间，可以查看指定时间范围内的数据。忌讳只有一个时间点，无法看数据的趋势。
（2）对一段时间范围内的数据能够分段或汇总，能够对不同阶段进行比较。
（1）有多少个维度，就提供多少个对应的查询条件。尽量满足每个维度都能分析。
（2）查询条件要提供开、合，以及具体值的过滤功能。既能看总体，又能看明细，还要能看单一。
（3）查询条件的顺序，尽量与维度的顺序对应，最好按从大到小的层次。
（1）图表显示的趋势，要与相应的数据一致，避免数据有异议；
（2）有图就必须有数据，但是，有数据可以没有图；
（3）图表内的指标不要太多，并且指标间的差距不要太大。
（1）一张报表，只做一份分析功能，多个功能尽量拆到不同的表报中；
（2）在报表中尽量不要有跳转；
（3）报表只提供查询功能。
看几张常用报表，WEB产品的流量报表，来自百度，关注PV、UV、新访客比率、跳出率、平均访问时长等。
专门说一下跳出率，这个数据反应了用户进入网站的着陆页（不一定是首页）价值，是否可以吸引用户进行一次点击，如果用户达到着陆页，没有任何点击，则跳出率增大。
图10 百度统计的网页数据报表
再看友盟数据平台提供的产品留存率数据报表，通常关注的留存率有：1天后留存、7天后留存、30天后留存。
图11 友盟的留存数据报表
数据提取，在做产品运营中，是很常见的需求，例如提取某一批销量较好的商品及其相关字段，提取某一批指定条件的用户等。同样，功能比较完备的数据平台，**有数据自助提取系统，不能满足自助需求，则需要数据开发写脚本进行数据提取。
图12所示，**内部的数据门户，承担了诸多产品的数据报表、数据提取、数据报告的功能。
图12 **数据门户首页
这里主要是数据变化的监控和统计分析，通常我们**对数据进行自动化的日报表输出，并标识异动数据，数据的可视化输出很重要。
常用的软件是EXCEL和SPSS，可以说是进行数据分析的基本技能，以后再分享个人在实际工作中对这两款软件的使用方法和技巧。需要注意的是，在进行数据分析之前，先进行数据准确性的校验，判断这些数据是否是你想要的，例如从数据定义到上报逻辑，是否严格按照需求文档进行，数据的上报通道是否**有数据丢包的可能，建议进行原始数据的提取抽样分析判断数据准确性。
数据解读在这个环节至关重要，同一份数据，由于产品熟悉度和分析经验的差异，解读结果也大不一样，因此产品分析人员，必须对产品和用户相当了解。
绝对数值通常难以进行数据解读，通常都是通过比较，才更能表达数据含义。
例如某产品上线后的第一周，日均新增注册10万人，看起来数据不错，但是如果这款产品是YY语音推出的新产品，并且通过YY弹窗消息进行用户触达，每天千万次的用户曝光，仅仅带来10万新增，则算不上是较好的产品数据。
图13 通过比较更清晰表达数据含义
这是数据运营闭环的终点，同时也是新的起点，数据报表绝不是摆设，也不是应付领导的提问，而是切实的为产品优化和运营的开展服务，正如产品人员的绩效，不仅仅是看产品项目是否按时完成，按时发布，更是要持续进行产品数据的观测分析，评估产品健康度，同时将积累的数据应用到产品设计和运营环节。
数据产品应用，大致可以分为以下几类：
推荐周期短，实时性要求高；用户短期兴趣和即时行为影响力大；投放场景上下文和访问人群特性。
产品案例：谷歌、Facebook、微信朋友圈。
长期兴趣的累积影响力大；时段和热点事件；多维度内容相关性很重要。
产品案例：Youtube
长期+短期兴趣+即时行为综合；最贴近现实，季节与用户生活信息很关键；追求下单与成交，支付相关。
产品案例：亚马逊、淘宝、京东。
最后，一张图小结数据运营11步：
作者：兰军，梅沙科技创始人，人人都是产品经理专栏作家
本文由 @运营直升机 整理发布于人人都是产品经理。未经许可，禁止转载。
