产品经理日常数据分析工作

产品经理作为产品功能的发起者，在众多需求中挑选出来可做需求时，心中就会有初步的构想，新功能能够帮助产品覆盖哪些增量用户，新功能又能带来哪些指标的提升，提升幅度大约是多少？然而当产品功能上线后，用户使用产生用户行为数据，产品和运营同学经常会提出类似这样的问题：这次的功能迭代优化，是否达到了预期的效果，具体的提升效果是什么样子？这时候就引入了功能上线后的一个很重要的步骤——“评估”。

其实“评估”，就是将业务问题转化为数据问题的过程。通过效果评估，我们可以确定上线功能与预期效果之间的真实差异。如果效果好于预期，则评估的结果可以作为运营同学功能推广的支撑点；当效果明显未达预期时，则需要基于用户行为进一步分析未达预期的原因，为功能的优化或改版提供建议。因此“评估”是新功能上线后必做的一步。

要进行功能效果评估，完整的数据和对行业及产品充分的理解是必不可少的两个部分。接下来就分别介绍一下我们在数据采集、具体产品功能评估方面所做的工作。

数据采集：准确的业务数据和用户行为数据，缺一不可

• 卷入测试同学校验埋点数据的准确性及完整性，避免需求上线后返工

用户行为数据对深入理解用户使用习惯起到至关重要的作用。目前用户行为数据上报多采用埋点形式，上报内容越多，对性能的影响越大。因此这就导致数据同学在和开发同学评审需求的时候常出现的一段对话：

数据同学： 我要上报这个数据，对分析很重要！

开发同学： 这个上报会影响页面性能，不能做！

其实大家的目标都是为了产品更好。所以数据同学在提埋点需求的时候，可以多思考需求是否是必须的，是否有其他的数据可以近似替代？在与开发同学对齐需求时，也可以多交流下，是否有对性能影响小一点的实现方式？

此外，经常会遇到埋点上线后才发现数据上报有问题的情况。这里选了3个经常遇到的挺具有代表性的示例：

例子1-数据不全： 我们的产品是服务于广告主的落地页产品，广告的投放就会涉及多个流量渠道，而不同的渠道对于数据上报时间节点的限制不同的，像这类情况就可能导致某些渠道数据上报不全；

例子2-数据不准确： 我们的落地页整体形式，头部是商品首图，接下来是商品详情页，最后是购买所需填写的表单内容。在这种页面结构下，我们希望能够获取用户最后跳出页面的位置。但当我们统计上报的数据后，发现90%的用户在完成表单填写后上报的页面浏览位置小于整体页面长度的10%。这明显与常规理解不符；

例子3-数据上报链路存在异常： 后台同学说埋点需求已经发布上线了，可以用了。但数据同学打开数据库，发现里面空空如也。然后开始拉着开发同学排查数据没到库的原因，是数据压根没采集？还是采集了没上报到服务器？服务器收到了没有推送到数据库？全部验证一遍之后，可能发现只是其中某一个环节的问题导致，但整个排查耗费了大量的人力。

踩的坑多了，我们就在想，是否埋点需求也可以像功能需求一样，在上线之前让测试同学帮忙把关呢？答案是可行的，而且还很高效！！！因此我们梳理细化了埋点数据上报测试全流程规范，将埋点数据问题暴露在上线发布之前。这里也对我们这个规范做一个简单的介绍：

• 全流程覆盖： 从数据上报 -> 服务器接收数据 -> 数据入库，测试同学需要校验每个流程中数据流的准确及完整性；
  
• 多维度测试用例： 考虑到落地页流量渠道的复杂性，规范要求测试同学根据渠道等特性编写多渠道测试用例，关注不同渠道数据上报情况；
  
• 多用户测试用例： 为了避免只使用一个用户进行模拟点击的行为，规范要求测试同学要批量的模拟不同用户的点击行为并关注每一个模拟用户的数据上报；
  

有了这个规范，测试同学的火眼金睛就可以帮助我们在上线前发现很多隐藏的数据问题，这也间接节省了数据同学校验数据、开发同学返工的大量时间。

• 数据同学应该参与到业务数据沉淀的需求讨论

通常理解下，业务数据更多的是前端和后台开发同学，为了保证功能完整运行所需要存储的数据。若数据同学没有在需求阶段和开发同学对齐，可能就导致数据关注的部分字段被开发同学忽略的情况的发生。当启动评估的时候，发现数据维度不够，再推动研发落地对应字段后启动评估，整个评估的时间周期明显被拉长了。

关于业务数据沉淀，举个亲身经历的小例子：新功能调用了算法提供的异常帐号鉴别的接口，当时开发同学只对帐号标识了label（0：正常1：异常）。而当数据同学评估整个接口效果的时候，发现需要统计算法接口打分分布情况。这个时候发现，开发同学存储的数据缺失了打分字段。这就是因为前期数据同学没有和开发充分沟通的结果。这也是数据分析同学需要参与到业务数据沉淀需求讨论中的原因。

产品分析： 搭建合适的产品分析框架，实现分析指标的可视化监控

产品功能的每次迭代优化，都期望能够对核心指标产生积极影响。这就要求数据和业务形成有机结合，相互促进的良好局面。好的数据量化不仅是业务增长的前提，也是抓手。随着增长理论的深入，很多产品都设立了自己的北极星指标，作为衡量产品一个战略周期的关键成果指标。但由于关键指标过于宏观，可能对于业务策略制定和执行的指导性不强。

因此，我们需要拆解出可以影响关键指标的因素，并将这些因素对应到具体的、可落地、可度量的行为上，从而保证执行计划没有脱离大方向。

这里介绍一下我们最常使用产品分析框架——OSM模型（Objective、Strategy、Measurement）三个词的缩写，其中：

• Objective（业务目标）： 明确业务要提升的目标是什么
  
• Strategy（实现策略）： 为了提升目标所需要采取的策略是什么
  
• Measurement（评估指标）： 尽可能使用数据语言描述策略是否达到了提升目标
  

利用OSM模型梳理自己产品的数据框架，不同产品的数据体系差异也主要体现在这里。比如游戏行业，可能更多的关注用户留存率；而针对电商平台，可能更多的关注转化率。

还是拿我们自己的产品作为例子，枫页作为腾讯电商类广告的落地页服务，为广告主提供便捷的落地页创建服务的同时，又承载C端用户下单转化流程。我们关注广告主在枫页上的广告消耗，抛开广告前置链路的影响，在落地页层面真正影响广告主消耗的是C端用户在落地页的转化率，转化率越高，广告主也就更愿意在平台上投放更多的广告。因此，我们最终将 转化率提升 作为我们的核心指标，并将这一目标利用OSM模型进行拆解。

通过OSM模型的拆解，我们就确定了一个可以数字化执行计划，每一个评估指标的波动，都可以评估其对核心指标的影响，继而，我们也可以知道每次的功能迭代优化具体产生的效果。

数据反哺：数据来源于产品，应用于产品

效果评估之后还有一个重要的一个环节，那就是推动分析结果的落地，没有落地的分析结果都是无用的分析。

上面也提到，如果评估出来功能效果满足预期，我们可以推动运营同学对功能包装并对外推广。但是，如果当我们发现新上线的功能效果远低于预期，这个时候难道仅仅是把这个效果同步出去就完事了吗？关于这里提到的这两种不同的情况，还是拿我们近期新上线的功能来做例子。

• 功能未达预期的功能时，数据分析是产品同学的后盾，数据将反哺产品优化迭代

朋友圈原生页广告，用户需要通过二跳才能到达枫页落地页（微信广告的限制）。但中间一跳页面会留给用户更多的思考时间，导致到达落地页的用户远低于其他流量渠道。因此，产品同学希望能够通过技术手段，将广告外层素材与落地页直接进行拼接，从而使得用户点击外层广告素材后可以直达落地页，进而提升转化率。如图：

但当功能上线后，我们发现使用拼接的广告，其转化率远低于大盘。至于为什么和预想的效果差异这么大，就是数据分析要做的事情了。

那针对以上的可能原因，我们逐步进行定位分析，最终发现，虽然原生页拼接可以提升用户的到达率，但是对于拼接后用户在移动端首屏所看到的信息极为有限，难以感知是与购物相关的信息（如上图）。为了进一步验证猜测，我们统计了用户在原生页拼接和非拼接页面中平均浏览时长及跳出位置的差异。最终发现，相较于非拼接页面，原生页拼接页面用户平均页面停留时间及跳出位置都比非拼接页面要差。