搭建数据监控体系，首先需要明确以下几个问题
为什么要进行数据监控
即需要解决什么问题监控哪些数据指标
问题中涉及哪些关键指标监控之后怎么预警
监控自然是为了做预警，不预警就没有监控的必要了预警后结果是什么
预警自然是为了推动问题得到解决
案例一
某电商网站，因为经常出现系统故障，而且往往故障较长时间才能发现，现在需要对建立数据监控预警体系
为什么要进行数据监控
及时发现系统故障，快速响应解决故障监控哪些数据指标
需要总结一套与实际业务相符的数据指标及维度，尽量能覆盖更多的实际问题。可以根据业务实际问题定义一些关键数据指标，通过监控数据指标的波动，判断是否存在故障，这里随便列举几个购物流程中的关键行为及对应的指标
页面是否可以访问–页面加载时长
是否可以正常下单–下单转化率
是否可以正常支付–支付成功率
除此之外，还需要各种维度，比如不同支付方式的支付成功率（支付宝、微信等）。因为监控系统故障，一般是实时监控，具体是否需要到分钟级监控，则需要根据业务量来判断。监控之后怎么预警
需要明确预警逻辑、预警方式及预警对象。预警逻辑，即关键指标符合条件时触发预警，比如页面加载时长，可以根据历史数据设定一个阈值，当然也可以与上一个时段对比下降20%等等。预警逻辑很重要，不正确的预警逻辑会预警出很多错误信息，造成骚扰。
预警方式，比如邮件预警/短信预警/电话预警，根据严重性判断需要的预警方式
预警对象，出现问题需要及时给到指定的责任人预警之后的结果
需要确定预警结束的逻辑方案。预警信息是否正常，问题解决后指标是否恢复正常水平。
案例二
某电商网站制定GMV的KPI，为了保证目标完成，需要建立一套数据监控体系。
为什么要进行数据监控
为了保障GMV的目标完成监控哪些数据指标
最核心指标当然是GMV，但是只监控GMV那就不能称为数据监控体系了。需要将GMV拆解到更详细的指标，比如GMV=用户量下单转化率支付成功率（1-退款率）客单价*购买频次
当然还可以继续细分，比如用户量=老用户+新用户，或者会员+非会员
当然也可以根据业务需要，拆分为每个城市、每个类目的GMV情况。总之数据指标体系需要与实际业务有很强关联性，动作指向要非常明确。比如北京的GMV不及预期，就应该给相应的负责北京GMV的部门/团队预警。如果该电商网站还在起步阶段，业务本身还没有划分到城市级别，你却将指标拆为城市级别，该给谁预警呢？
监控之后怎么预警
业务的预警逻辑会相对比较复杂，单纯用阈值或者下降/上升幅度，可能会出现较大偏差。具体的预警逻辑需要结合考虑业务实际情况。比如电商双11会是一个高峰，那么在GMV预警是需要考虑这点。但是业务预警对预警数据的精确性并没有太高要求，并不需要十分精确的预估接下来GMV走势，更重要的是引起重视，快速解决问题达成目标。比如预测数据的精确性，推动力和行动力更重要。预警方式，一般是邮件/会议形式。
预警对象，一般是业务核心负责人，引起重视才可以快速推动问题解决或改善。
预警后结果是什么
预警是否被业务方接受？
接受后是否有所行动？
行动结果是否解决问题或改善现状？
是否需要持续预警？
最后补充一下
数据监控体系核心在于监控，监控是用来发现问题的，并不是来解决问题。
不需要胡乱硬塞很多指标/维度。发现的问题必须有对应的责任人，没有责任人的指标/维度的预警都是多余的。硬塞很多指标进去，就不是监控体系了，是分析指标体系。
必须要跟进预警的结果，只有能解决实际问题，才能体现数据监控体系的价值。