正如前篇所述，运营监控数据体系是需要跟数据打交道，让数据发挥价值的平台，之后才是数据使用的系统，并为不同的End-User提供使用的入口。所以我们可以简单认为其就是大数据的一个投放场景。

大型航司基本都有自己的大数据系统，平台，或体系，乃至应用架构了。但是如何适应航司电商“运营监控数据体系”的要求。则必须将对其以后体系进行梳理，且明确需求的前提下合理构建数据使用的流向和处理体系。

常见的数据运营分析工作

不管最终用户是谁，其全部最终用户的需求无外乎如下。当然建设的时候会需要分阶段建设，但是设计的时候则需要全局需求总览之下，进行推进：

a) 用户行为分析，用A/B测试进行产品优化。（Leo：对用户行为进行分析，通过不同的呈现方式得出不同的点击量来决策我们应该使用哪一种方案。）

b) 运用漏洞模型进行用户触达分析，如TIPS、广告等曝光到活动的转化。（Leo：从开始到最后用户流失的一个情况，以此来评价我们做的方案决策是否合适。）

Leo：例如一个这样的结构，加入购物车1000人，进入购物车准备支付780人，支付操作540人，完成交易480人。其中25人在支付之前流失，且直接退出。其中120人在加入购物车后没有直接继续操作，而是又继续添加了一些其他产品等等。

c) 收入效果监控与分析，包括付费转化率、渠道效果数据等。（Leo：检测投入产出比，钱是否花到位了。）

d) 业务长期健康度分析，例如从用户流动模型、产品生命周期分析产品成长性和健康度。（Leo：从用户流动模型、产品生命周期分析产品成长性和健康性。）

e) 营销推广活动的实时反馈。（Leo：促销活动的实时数据统计到一般洞察，注册量，转换量等。）

f) 等等。

数据运营分析的方法

事前分析/Being-Smart

a) 预测各类数据（Leo：用户，点击，收入，交易统计类型的绩效指标等）

b) 建立考核指标（Leo：活动，功能，流量等）

c) 决策支持（Leo：这个暂时还比较难实现或很具体）

d) 精细化运营（Leo：数据挖掘的基础上，精准触达。而非简单统计，需要对特定目标群体，功能点等等的细化分析）

事中分析/In-Fly

a) 实时监控统计类型的绩效指标（Leo：埋点/锚点效果反馈，用户行为跟踪）

b) 实时产看流量（Leo：网络，运行等环境状况）

c) 实时分析活动效果（Leo：比较难通用化，需要个性化开发）

事后分析/Being-Doormat

a) 定位产品问题和问题位置（Leo：例如关键绩效指标是否正常，渠道是否畅通，流程是否顺畅等。）

b) 活动效果

c) 功能效果

d) 后续工作规划（Leo：决策型的都比较难）

例如：一个新改版的功能上线，单纯对于用户量数字，事先要有一个大概的预估。事中需要做到的是采集哪些数据，收集数据。比如检测一个点击按钮，用户点击了多少次，有多少用户点击了。如果检测的点多了就要用到用户的行为分析，通过用户点击的一系类的点，我们大概猜出来用户要实现什么样的功能。事后在收集的数据之上进行分析。用户在什么时候点击了多少次，消耗了多少的流量。通过分析有没有得到什么结论，包括用户是不是健康，数据是否安全，流程是否好的。

一个应用场景-AB测试

例如上面那个比较粗糙的例子：“加入购物车1000人，进入购物车准备支付780人，支付操作540人，完成交易480人。其中25人在支付之前流失，且直接退出。其中120人在加入购物车后没有直接继续操作，而是又继续添加了一些其他产品等等。”

可以设想这样一个结构：

a) 入口类别有哪几个（老入口功能，新入口功能，其他渠道跳转），各自占比多少。

b) 跟踪各自的漏洞行为流程（加入购物车，支付，购买等几个漏洞节点），即特定页面转化率等。

一个应用场景-用户运营模型

通过数据分析，来细分客户对于功能的粘度，而非对应用或整体平台的粘度。从中洞察用户性质和特征：忠实，普通，活跃但低价值，潜在高价值等。

建设蓝图

人

a) 专职专业的产品人员，能够流程化和标准化业务，并且沉淀和萃取经验。

b) 专职专业的开发人员，能够进行数据上报，BI开发，数据库及大数据相关工作。

数据湖泊

a) 记录和持久化产品个性化的数据。

b) 数据互通，数据接口化，共享数据源。

可视化

a) 逻辑清晰的全面思考及规划，将常用数据优先固化和基础化。

b) 专业BI展示。

c) 逐步迭代叠加。

规范

a) 萃取数据开发及使用流程

b) 工具化，模板化（Leo：异常错误怎么处理，例外怎么处理等等）

业界参考

腾讯：广点通、信鸽

阿里：数据魔方、淘宝情报、淘宝指数、在云端

百度：百度预测、百度统计、百度指数、百度司南、百度精算