从0到1搭建业务指标追踪平台
一、为什么要做
数据指标的异常波动分析是数据同学经常会碰到的case，也是业务同学经常会提的分析需求。数据指标的异常追踪，特别是核心关键北极星指标，关系到高层策略方向制定，业务日常的运营，可以说在时效性和准确性上非常关键。
业务指标的监控需要业务同学和数据同学紧密配合，但在日常的数据运营过程中，业务变化是直接导致数据异动的重要原因，经常会发现业务变化对数据同事来说存在滞后，不对称的情况，导致数据排查异常耗费较长时间。
业务指标监控，如果没有一个体系化的流程和监控机制，会让参与各方都会感觉“人在囧途”，具体情况，基于互联网金融业务场景，我们来逐个分析下：
1. 产品运营团队
新上线了个优化的小版本，数据同学却抱怨没提前通知他们，数据出了异常排查时间长。
这周做了个拉新活动，原本以为新注册用户数会大增，没想到带来了一大批垃圾注册用户。
流量太大，放款资金承接不住，我要经常修改流控开关，一动数据就会异常报警，也不知道到底是什么原因。
2. 风控团队
入催率升高了，到底是用户质量变差了，还是用户还款还不进来了，每次排查都要一两天。
三方征信源 数据认证天天报警，也不知道对我风控通过率到底有没影响，怎么快速排查？
3. 支付和财务团队
还款失败率升高了，找技术排查还是找数据排查，谁能最快给我定位原因？
是支付渠道出问题，还是资方那边出问题？
问题定位到了，都过了一两天了，对外沟通还要时间，用户投诉不断……
4. 数据团队
指标动不动就预警，业务到底发生了什么？
为什么我总是最后一个知道真相？
数据异常，是数据问题还是业务问题？
能不能配合的默契点啊，数据业务多互通有无啊… 你们做了啥怎么不提前知会数据部？
真是人在囧途，每个团队都觉得自己人在囧途！
二、做什么
那到底是人出了问题，还是流程问题、工具问题？
基于以上异动定位的场景，根本原因还是流程和工具建设不到位，导致效率低下，相互抱怨。
这里面本质上的问题是 信息不对称，没有将常见的异常归因流程沉淀下来。单单从流程上来说，业务根本没有义务将日常的产品迭代和业务活动及运营策略都提前告诉数据团队，那是否就证明数据团队只能被动的从数据上了解真相呢？
这里我们先不讨论流程问题，更多的去讨论如何利用数据去提前发现真相，及时帮助业务归因复盘。
那该如何优化？
三、怎么做
先，我们要梳理下信贷业务的指标体系。
信贷业务主流程链路节点和核心指标构建如下：
其次，根据业务方关注的细化流程来看。
具体到业务部门，比如产品部门最关注的就是节点转化率。
前端环节涉及到的节点：注册——实名——计算额度——发起申请——审核通过——放款。
对于各个节点的转化率，漏斗情况，是产品同学每天都要关注的数据。
再次，抽象出一些通用的异常归因指标体系，可下钻定位。
比如，像风控好产品团队都会关注的入催率指标，在风控平稳期（没有大规模上线优化策略时期），当入催率指标下降时，我们发现大部分原因是由于用户还款通道出问题，导致用户想还却还不进来，进一步下探，我们就需要下钻到还款失败率，再到进一步定位失败原因，我们需要下探到还款失败原因（按资方和按渠道维度），到此，我们大概率能看出是哪个资方的哪条还款渠道出了问题，接下来给到支付团队去紧急修复或者去做外部沟通。
关键指标我们梳理出来了，那采用何种方法去监控异常？
首先，我们要考虑的是 如何定义异常。有对比才会有异常，如何定义对比的基线？
一般来说，有如下几种比较方法：
1. 同比环比法
计算同比与环比，就是一种与自己的过去比较的方式。
通过和过去的自己比较，可以明确的知道，当前的指标处于什么样的水平上。并且能知道这个指标变化的趋势是向好的，还是向差的。
结合实际的业务场景，指标上升、下降、持续保持波动没有变化或大幅波动等，都能够称之为某种程度上的问题。常见的比如 日环比，周同比等。
同比和环比法要指明时间周期，是日/周/月/季度/年，一般会几个周期节点都看。可参考如下设计：
2. 拟合预测法
拟合预测法是对历史数据进行拟合（线性，非线性）后，对于指标的趋势变化进行刻画，来判断后续的数据点和拟合曲线的偏离程度。如果偏离程度超过某个预定阈值，则可以判断为异常，常见的拟合方法有线性拟合、对数拟合等，如下是线性拟合的例子：
3. 标准差法
可以采用比较变化幅度与历史数据标准差的方式，对于指标的变化幅度进行更为精准的刻画，来设计预警机制。当我们谈论到离散程度、变异性时，可以理解为数据的波动大小。
标准差（Standard Deviation） ，是离均差平方的算术平均数的算术平方根，用σ表示，衡量数据的波动大小。
可以参考著名的6-Sigma管理法，6σ管理法是一种统计评估法,核心是追求零缺陷生产，“σ”是希腊文的一个字母，在统计学上用来表示标准偏差值，用以描述总体中的个体离均值的偏离程度。阈值的设定为σ，2σ，3σ，可以根据具体业务场景来考虑使用。
4. 移动平均法
移动平均是一种分析时间序列的常用工具，它可过滤高频噪声和检测异常点。根据计算方法的不同，常用的移动平均算法包括简单移动平均、加权移动平均、指数移动平均。假设移动平均的时间窗口为T，有一个时间序列：
有了实时指标监控的数据产品，只能帮我们快速发现异常，有些场景还是需要人工接入定位异常原因并做跟进解决，同时还需要同步给相关干系人。
这一块流程，我们还是采用线下的文档跟踪方式，需要定位到 时间，责任人，异常分类，异常描述，数据建议，业务反馈，是否关闭，截图。具体形式可以举例如下：
实时业务指标跟踪平台上线后 效果如何呢？ 我们选取了其中一个 异常归因的case，在上线前和上线后，定位时效提升了数倍，举例如下：
四、优化方向
以上是笔者在互金领域的实践总结，但是数据指标监控体系的建立的一般方法论却是适用于各行各业。笔者思考后，依然觉得有四点可以优化的方向，具体总结如下：
1. 接入更多业务归因分析场景
比如客服和催收团队特别关注的 接通率，平均接通时长等。
2. 业务自助选择需要的指标来监控
这需要建立一个全面的指标体系，同时提供给业务自助监控的工具，业务自主选择指标，判断逻辑，阈值，发送人等。
3. 智能化的阈值预警
现在的阈值更多的是靠人工来调整，是否可以探索出一种方法，能自动学习历史经验来调整阈值。这是个长期的过程，还是需要人工不断的反哺，前期采用人工+机器结合的方式。
4. 指标异常定位追踪全线上流程记录
目前的追踪方式 是数据产品同学人工记录整个case追踪流程，采取邮件形式跟踪问题解决进度。是否可以形成一个追踪的闭环，比如异常case发送后，由指标负责人自己跟踪并将结果线上反馈到系统，同时能自动通知所有干系人，包括关闭后也能通知。
理想的是如下闭环流程全部实现线上化：
指标选择 —— 异常定义 —— 阈值调整 —— 异常预警 —— 告知干系人 —— 异常排查 —— 结果跟踪 —— Case 关闭。
实现以上流程的闭环，则代表数据驱动从 人找数据思维转变到 数据找人的思维。
本文作者 @乘风随行 。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
