运营指标设计的奥妙：左眼是数据；右眼是用研！

来源：数据工匠俱乐部

编辑：谈数据

就像人走路的时候需要看到前方的道路，产品和运营在做决策前也需要睁开“双眼”。左眼，是数据；右眼，是用研（指用户研究）。（哎，别问我为什么不是左眼用研，右眼数据……）

通过线上数据反馈，我们可以准确地发现问题，找到规律，求证猜想，平息主观之争，为产品改进和运营优化的制定和实施提供明确的方向。

01 互联网公司数据职能设置

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

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

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

b. BI，负责根据业务需求在数据库中抓取对应数据项，编写SQL代码，生成各类报表。（注：传统的数据库管理员（DBA）的职能更类似于数据工程师 + BI – 埋点）

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

我在实践中的体会是：两种组织架构方式各有明显的利弊，优缺点截然相反。

当数据人员集中在一个部门时，数据库管理和报表定制均十分专业高效。但因为离业务部门较远，业务理解受到影响，在数据定义和解读上相对偏薄弱。

数据职能分散在各个业务线时，正好相反。并有较严重的数据重复拉取，人力浪费不说，还因口径定义上的差异，导致同一数据在不同部门各不相同。例如转化率=订单数／访客数，有的部门在访客数中去除“疑似机器人”部分，有的部门则统一访客数为“二跳访客”，带来转化率数据的明显差异。

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

02 数据使用方式

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

1、常规数据报表

常规数据报表主要用于需要长期持续观察的核心数据。例如：

• 流量漏斗监控，可分为首页跳失率、商详页到达率（分为浏览-商详、搜索-商详两大分支）、加车率、结算率、结算完成率等核心环节漏斗数据。
• 用户渠道来源情况，如各渠道来源的用户数、新客数、订单占比、转化情况等等。
• 品类转化率波动，如各品类的流量、订单、SKU销售数量等。
• 流量分发效率，如各频道／栏目的CTR、商详页到达、转化、复访率等。

当常规监控的核心数据项发生超阈值波动或趋势性波动时，通常会触发专题分析，并根据分析结果采取相应对策，以推动数据回到常规范围。

常规数据报表建议通过公司的BI系统定制在线报表，按监控频度进行观察分析。

2、专题分析

专题数据分析通常按专题的主要影响因素确定数据项，拆分观察维度，抓取多维度数据，对某个专题目标进行分析，找到影响因素所在的数据维度，得出结论，指导后续动作。例如：

• 针对某个重大事件的状况或效果分析，如双11大促后的数据总结盘点。
• 核心数据出现重大波动，如Web平台转化率持续提升的原因分析。
• 出现趋势性状况，如某付费渠道来源的用户数量持续下降。
• 某个专题研究，如95后导购特征和消费特征分析。

3、AB测试

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

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

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

这里要特别注意两点：

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

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

4、个性化

这是个大数据的时代，差异巨大的用户群体面对海量的商品和选择，“千人一面”带来的糟糕体验已不再适用。

每个用户在系统中都会留下自己的线索和足迹，体现自己在商品品类、价格段、品牌偏好等方面的阶段性需求。系统可以通过数据有效发现当前用户的当前需求，进行有效的推荐，而用户也会感受到系统“懂我”，产生良好的购物体验。

亚马逊早年的“Everything Store”理念，在当前时代下，也逐渐转化为“Everyone Store”，也就是我们常说的“千人千面”。

数据是千人千面的基础，通过机器学习和算法设计，让系统在各个模块中进行智能化推荐，自动组装匹配当前用户的场景，是数据使用的最重要方式之一。这部分我会在后续文章中结合实际案例重点展开。

03 常规性数据报表的定制及数据监控

为了最优使用BI资源并突出自身专注点，在定制常规性数据报表时，切勿大而全。需要完全考虑清楚的主要有两点：北极星指标、指标监控频度。

1、北极星指标

任何一个业务要能不断优化和提升，做出更好的效果，都需要正确设立核心指标，持续监控，并根据实际数据与阶段性预期进展之间的差距进行分析，触发相应的调整动作，以使得业务的发展和计划保持一致。

这套思路在项目管理理论中被总结为PDCA ，即计划（Plan）、执行（Do）、校验（Check）、响应（Act），在项目管理和持续质量改善中也被称为戴明循环。该体系是业务目标管理的核心方法，感兴趣的同学可以查阅项目管理理论，本文不进行赘述。

从PDCA概念中可以看到，目标的制定、执行成效的判断以及纠偏动作的效果，都需要好的数据指标进行衡量，并作为最终目标达成与否的判断依据。这个可度量的指标，与目标呈直接的正相关关系，该指标被称为北极星指标。

北极星指标体系通常分为多级，每一级指标的设立选取，都是为了更好的支持上一级指标的达成，以最终共同实现公司顶层战略（公司级的北极星指标）。

在这里举个实际例子。一个电商公司的经营规模往往通过公司的年营业额（GMV）来衡量，也即GMV是整个公司的北极星指标之一。营业额有多种拆分计算方式，在此列出常见的一种简化计算方式：

GMV = AC * Freq * Conversion * AOS

• AC：活跃顾客数
• Freq：顾客平均访问频度
• Conversion：转化率
• AOS：平均单均价

上面四个核心指标，则为第二级核心指标，通常可下达到各个部门分别负责。

例如，市场部负责流量和用户数及其活跃度，产品和运营负责转化率指标，类目线负责单均价指标。于是这些指标成为各个部门的北极星指标。如果一个指标的核心影响因素分散在多个部门，也由同一个部门牵头负责。

为了达到上述各个二级指标，还可以进一步拆分。以活跃顾客数为例：

AC = RC + NC – EC

• RC：留存顾客数
• NC：新客数
• EC：流失顾客数

于是这些指标又可以进一步分配到负责拉新和留存的职能团队，成为这些团队的北极星指标，由这些团队各自牵头负责。

负责拉新的团队，又可以进一步把拉新指标拆分到渠道，如付费渠道、免费渠道等，进行下一级的核心指标定义和目标制定。

同样地，下一级负责付费渠道的职能团队或人员，则可以进一步拆分到具体渠道，如网盟、SEM、应用商店等，进一步制定各个渠道的具体目标。如此层层往下，直到直接可控的最下一层。

以此类推，产品和运营负责的转化率指标，则可以沿转化漏斗拆分为首页到商详、搜索到商详、商详加车率、购物车结算率、支付成功率等，通过逐层递进的拆分具体到各个团队进行分解，成为各自的北极星指标。

对于各个职能部门／团队来说，自己所负责的这一级指标以及下一级指标情况，应当成为常规数据报表的监控内容，由此制定报表格式，向BI部门提出数据需求。

站在宏观维度来看，三级指标的达成可以确保二级指标的达成，二级指标的达成可以确保顶层指标的达成，从而为业务目标提供保障。因此，指标体系的合理拆分和严密监控纠偏对公司目标实现至关重要。

2、指标监控频度

常规数据报表的周期通常为日报、周报、月报、季报。实时数据监控通常为应急响应需要（如故障宕机、突发事件处理），而半年报、年报则大多为业务结果的统计，周期过长，发现的问题及响应过慢，通常不在常规数据报表的范围。

每个业务单元都具有各不相同的特点，需要进行有针对性的数据统计频度设定。下面以产品和运营层面对转化率的监控为例：

• 实时监控

在大促期间观察活动效果，流量变化迅速，高峰此起彼伏，爆品库存时有告罄，此时数据观察应当精确到最小颗粒度甚至实时监控数据曲线，对数据体现的问题（如售罄、宕机、技术故障、黄金资源位单品滞销、页面陈列错误、价格设置错误导致的波动等）迅速响应，优化促销品及资源位，并使用赛马机制，调整会场流量分发，以把大促效果推到极致。

• 日报表

对于日常促销活动，可以以天为单位，对促销品类和促销方式在整体转化漏斗中的表现进行观察，定位问题点并迅速进行针对性优化；如换品，换促销规则，更新活动页／活动栏目，配置促销标签等，以达到最佳活动效果。

• 周报表

运营方面，例如首页或频道运营，可以以周或月为单位，通过各板块CTR、停留时间、商详到达率、加车率、转化率、复访频度等维度观察栏目用户的兴趣指数，对于薄弱环节通过数据进行深入分析（如用户动线跟踪、区域点击热度分析、跳失分析等），并适当结合用研的定性定量深访对频道入口交互设计、页面信息架构设计、频道子栏目铺设、信息展示、营销文案等进行优化，以达到最佳效果。

• 月／季报表

移动时代受到移动端发包频度的限制（大多为每两周到一个月发一个包），高度依赖技术功能的核心指标往往以月或季为单位进行统计。

例如，对于核心转化漏斗模块的功能迭代和新产品模块的效率效果，可以以月或季为单位（与技术发版周期和新栏目用户教育养成周期有关），结合季节性因素，纵向对比同比和环比相应数据的波动，找到可以发力优化提升的环节。

运营动作一般带来较快速的数据响应，侧重于日报、周报对运营的指导；而产品动作一般受技术发版影响，数据响应周期适中，更偏重月或季为周期的报表，但都谋求发现问题后迅速响应。

年报总体来说可能更适用于公司战略和业务线的财务考量，除了成果和得失总结，产品和运营侧的使用相对较少。

上述是针对转化率的举例。

如果是用户运营和增长，同样可以根据频度对用户的渠道来源和激活情况、传播效果（短周期，如天或周）、活跃度、品类渗透率、交易情况、人均价值（中周期，如月）、留存率、流失返回率、生命周期情况（长周期，如季或半年／年）进相应的数据报表制定和监控，并触发响应的调整动作。

最后，在报表制定时，建议不要把太多级别的数据放在同一个报表上，造成数据的汪洋大海，表格过度复杂，也会迷失专注点。通常一个报表含两级指标为最佳。

例如，一级指标的报表只含一、二级指标数据，对于一级指标的波动从二级指标进行观察，找到波动原因。如果需要继续深入，建议另外定制二级指标报表，含二、三级指标数据。以此类推。

04 专题分析

工作中常会碰到一些突发异常情况，例如某阶段用户转化率大幅波动、交易金额飙升或锐减、某栏目CTR暴跌等，再或者观察到某些趋势性的变化（如消费者导购偏好演变、品牌消费趋势变化）。此时通常会进行专题性分析，以明确下一步解决问题的思路。

1、专题分析触发原因

专题分析主要由如下情况触发：

a. 在数据报表中，我们常常看到一些核心数据指标产生波动，当波动范围超过一个预定义的警戒阈值时，就应该触发分析（无论正向的还是负向的波动），以理解波动背后的原因，并采取相应的对策。

多大幅度的波动值得触发分析因指标本身特性对应的业务敏感度而定。阈值设置没有固定规则，大家可以根据影响的承受力来设定。这里有一个常见错误，就是对正常的小幅波动太过敏感，触发频繁的分析，最终却没有有价值的发现，属于自然波动，浪费了人力。

什么是正常幅度的波动，可以对一个大时间段的同一指标进行同比环比的统计后判断。

例如，上图是我们在某五周期间观察到到流量按时间段到分布情况。大家仔细看下有什么异常？

猜对了，0点出现大流量！9点，14点，19点的流量峰值符合移动端用户在早晨通勤时间、下午回到座位、傍晚通勤时间的访问规律。但0点出现如此之大的流量，十分异常，就应当触发专题分析。

b. 在数据报表中，数据体现出某个同趋势性的连续变化，例如，连续7次正向或负向的增长。此时，即使还没有达到预设的异常警戒阈值，都应当进行分析，以理解趋势背后的原因。

可能有同学会问，为什么是7次呢？

其实这不是绝对的，当一个连续趋势出现时，同向的数据点越多，表明背后有某种非偶然因素的可能性越大。从统计学角度，如果是偶然因素导致连续7个点往同一个方向发展，可能性只有1/128，大约为8%。因此，7点同趋势变化背后存在非偶然因素的置信度已经足够高了。如果是特别关键的指标，连续5个点同向发展（97%的确定性）也许就该进行分析了。想要深入了解的同学可以搜索“7点原则”，查阅PMP或者统计学有关的理论知识。

当然，背后应当去除已经理解的影响因素，例如越来越靠近春节时流量持续下滑，或者接近换季时新一季的服装销售持续上升，都是正常现象，除非波动过大严重脱离同比情况，否则这样的趋势并不值得浪费人力进行分析。

c. 对某个数据背后的原因感兴趣，需要分析和理解该数据背后蕴含的信息。这个和数据的波动本身没有关系，只是深入去理解数据背后的原因或因素。

例如，分析为什么在平台上第三方商家的流量达到48%，以制定更平衡的流量分发策略来扶持自营或第三方业务；分析为什么付费渠道来源的用户占比偏低或单客成本过高，以做更精准更高性价比的流量采买投放。

2、专题分析常用方法

简单概括，专题性分析的主要做法是，按多个维度全面对波动数据指标的下层构成进行拆分，观察对比各个下层数据，找到在哪个细分维度出现异常波动，并锁定该维度，层层递进，深入分解，直到最终找到答案。

在拆分到下层维度过程中，需要考虑从多个角度出发，反复对比。例如，如果某一周发现转化率产生异常波动，可以按如下维度进行拆分观察：

维度一：商品品类

拆分到各个品类，观察是否由某个品类的转化率大幅波动带动了整体转化率的波动。

案例1：

某一周我们发现全站转化率飙升近2%，通过二级报表对各品类转化率进行观察后发现，转化率波动主要出现在美妆品类。进一步对美妆品类各SKU的销售进行观察，发现洁面仪、水牙线、和某款面膜等三个商品短时间销量巨大。这三个单品的上线价格远比京东和天猫更为低价，并与市场部确认，市场部有在“什么值得买”网站进行投放，导致大量用户涌入，销量激增，通过这三个热销爆款的销售推动了全站转化率的波动。

案例2：

有一次服装线的采销对某品牌服装在设置促销券时忘记设置互斥，导致用户可以反复领券和叠加用券。而该技术漏洞被人在乌云平台所披露，导致大规模的用户和黄牛涌入抢购，零元购买，极短的时间里卖出数千件，造成转化率瞬时飙升。因为人工设置价格和促销时错误难以绝对避免，此类问题在各个电商平台时有发生。

维度二：用户群体

拆分到各个用户群体，观察是否由于某个用户群体的购买情况变化造成了转化率的波动。注意用户本身就可以按很多个维度拆分：

• 性别

• 地域：省、地区

• 消费价格段：高、中、低价格段

• 消费风格类型：例如时尚人群，母婴人群，数码控，阅读爱好者，家庭主妇……

案例3：

某一周的数据观察中我们发现全站转化率的飙升，通过地域和品类的分析，发现是由于华东地区高温，导致空调风扇等商品在华东的销售飙升，推高全站转化率。北京地区雾霾爆表也曾导致净化器、口罩等商品在北京地区销售猛增。

维度三：渠道来源

拆分到各个用户来源渠道，按渠道对应的销售情况进行观察。

例如，有时转化率大幅提升，分析发现是因为市场部在某些导购网站的黄金资源位进行了爆款投放，从该渠道产生了巨大的流量和销售进而推高了整体转化率。当然部分渠道的刷单现象也常常会引起整体转化率波动。

维度四：转化漏斗

观察首页到商详，商详到购物车，购物车到结算，结算到支付等转化漏斗环节的细分转化率的变化情况。

案例4：

有一周转化率低于警戒值，通过漏斗分析发现支付环节成功率大幅下滑。对支付渠道进行分解后发现某银行渠道的支付成功率下降到零。与该银行沟通后确认，该银行对支付接口进行了升级，升级版本存在问题，导致该支付渠道支付失败，导致整体转化率产生波动。

案例5：

有一次技术团队上线新版本后，发现转化率下跌，通过漏斗分析发现，在新用户注册环节有较大的注册成功率下降。进一步通过注册流程的分析，看到产品功能上增加了一步强制实名认证，导致部分用户在这一步由于各种考虑而放弃了注册。在与产品经理沟通后把实名认证改为可跳过，改为在后续阶段进行引导认证。这一步改变使注册成功率得以恢复，问题解决。

维度五：设备平台

观察iOS，Android，PC，Web等各个平台以及各个app版本的转化率情况。例如，我们有时发现，新发的Android包存在技术故障，导致用户大规模登录失败，进而影响整体转化率。

维度六：销售渠道

很多平台会对接下一级分销渠道，各个渠道的销售情况变化也会带来整体转化率波动。有时某个渠道进行了效果极佳广告投放，会重大促进该渠道的销售，进而影响整体转化率。

维度七：流量或销售时段分布

拆分到各个用户来源渠道，按渠道对应的销售情况进行观察。

例如，有时转化率大幅提升，分析发现是因为市场部在“什么值得买”的黄金资源位进行了爆款投放，从该渠道产生了巨大的流量和销售进而推高了整体转化率。当然部分渠道的刷单现象也常常会引起整体转化率波动。

案例6：

有一次转化率下降报警，数据分析表明销售情况在用户、渠道、品类等方面都分布均匀。最后产品经理与BA联合排查，发现在0点到7点之间有大流量出现，并且流量集中在整点刚到时爆发，由此基本可以推测这些流量并非真实顾客，而是某种程序脚本整点触发导致。最后与技术团队跟进分析，确认是某搜索引擎爬虫开始集中爬取平台商品、价格信息。

维度八：用户账号或商户

有时某个商户，或某些用户，出现异常大规模订单，导致整体转化率、单均价等出现巨大波动（此类现象往往是刷单导致）。通过按商户或用户账号的销售情况拆分，可以发现此类问题。

写在最后

实际的分析中，在我和数据团队所做过的以上八种维度都经常发现问题。并不排除还有更多维度，大家可以按自己的业务特性进行类推。

以上只是对转化率进行分解分析的一个例子。任何一种指标通常都可以向下拆解，直到最后发现问题所在，而上面列举的八个维度，通用于绝大部分的线上状况分析。

具体的做法是：按各个维度对指标拆分到下一级后，观察下级各维度指标是否均匀体现该波动。如果是，则基本可以排除是该维度的因素所导致。对同级的各个维度逐一拆分观察，通常会发现某个维度下的某个次级指标剧烈波动，锁定该指标，再次对其下层指标进行分解观察，层层递进，最终可以找到结论。

<END>