增长模型下的产品与运营实战 之一：数据体系运用（1）

在产品和运营的实践中，数据是一切动作的依据和指引。作为互联网产品和运营技战术体系的第一篇，首先谈谈我对互联网数据体系的解读和使用。

就像人走路的时候需要看到前方的道路，产品和运营在做决策前也需要睁开“双眼”。左眼，是数据；右眼，是用研。（哎，别问我为什么不是左眼用研，右眼数据。。。）通过线上数据反馈，可以准确地发现问题，找到规律，求证猜想，平息主观之争，为产品改进和运营优化的制定和实施提供明确的方向。

互联网公司普遍十分重视数据，数据部门职能设置却各不相同。大多会设置独立的BI部门（如携程、京东），有些（如亚马逊）也会把数据人员分散在各个团队。

数据职能有三个主要角色：

• 数据工程师，负责搭建底层数据架构，定义数据埋点规范、编写埋点代码（有时也会由开发人员植入埋点代码）、以及建立和管理数据库报表。

• BI，负责根据业务需求在数据库中抓取对应数据项，编写SQL代码，生成各类报表。BI更类似于传统的数据库管理员（DBA）。

• BA，负责对BI生成的报表进行分析，结合业务知识对数据进行透彻解读，输出有明确指导意义的观察和建议。BA人员通常需要有较强的业务背景知识，能够准确地理解数据背后的业务状况和波动原因，并用业务“语言”输出分析结论。

我在实践中的体会是，两种组织架构方式各有明显的利弊，优缺点截然相反。当数据人员集中在一个部门时，数据库管理和报表定制均十分专业高效。但因为离业务部门较远，业务理解受到影响，在数据定义和解读上相对偏薄弱。数据职能分散在各个业务线时则正好相反。并有较严重的数据重复拉取，人力浪费不说，还因口径定义上的差异，导致同一数据在不同部门各不相同。例如转化率=订单数／访客数，有的部门在访客数中去除“疑似机器人”部分，有的部门则统一访客数为“二跳访客”，带来转化率数据的明显差异。

一个比较好的做法是把数据工程师和BI集中在数据部门，在各个业务线分别设置BA人员，两边对接。

互联网需要进行数据观察的领域十分广泛，每个细分领域都有不同的核心KPI，应当根据核心目标拆分背后的影响因素，有针对性地提出数据需求，制定数据报表。

通常数据的使用方式分为如下情况，

产品经理常有的困惑是，当上线了某一个功能或者频道后，目标数据出现了某种变化，然而，变化背后的影响因素非常多，例如时间因素导致的差异（如工作日的转化率高于周末），竞争对手的动作，季节性因素等等。核心数据的波动往往是这些影响因素综合作用的结果，很难准确界定该功能本身带来了多少直接影响。

运营也常有类似的诉求，例如当首页图标做了飘红，或者引导文案做了一些调整，数据出现了波动，但却很难确定多大程度为该特定运营动作的效果。

上述情况下，最好的方法就是做AB测试：取两个数据集，在数据集样本的选取中对各种影响因素做均匀的随机分布（如地域、用户群体特性），并对其中一个数据集实施特定产品功能或运营动作，在同的一时段中，观测目标数据在两个测试集上的差异，从而精确判定待观测功能／动作的准确效果。

这里要特别注意两点：

1，为了确保统计效果的准确性，需要有较大的样本量和统计时长（结果数量=用户量*统计时长，要么用户量足够大，统计周期可以略短；如果用户量较小，则需要更长的统计周期）。

2，如果某一个样本中存在少数对均值影响巨大的样本（例如一个金额巨大的订单），需要予以排除，以减少偶然性带来的偏差。

数据体系运用的后几篇文章中，我会逐一对常规数据报表、专题分析和AB测试，结合实际案例进行逐一阐述，敬请期待。