编辑导读：企业每天生产众多的数据，这些数据要经过分析才能对业务、运营等产生价值。而大数据平台就是了满足企业对于数据的各种要求而产生的。如何构建一个大数据平台，取决于企业的数据化程度和面临的数据问题。本文将从产品方案设计角度，说明一个最小可行的数据化运营平台方案设计的思考过程，供大家一同参考学习。

　　上篇文章讲了对于信息化基础能力较为完善，但数据化能力不足的在线教育公司如何构建大数据平台的方案，感兴趣的同学可以查阅《在线教育大数据营销平台实战（一）：大数据平台构建实战》。

　　大数据平台的构建是从底层解决业务面临的数据问题，一定是需要一个时间周期的，因此其对业务的贡献不会立刻显现，而业务感知不到数据的赋能势必会影响老板对数据团队的资源投入，怎么解决这个死循环？

　　本篇我会以自身的实践经验为依据，阐述数据化能力构建初期，如何利用第三方数据系统（神策sa）和内部数仓的结合来构建支撑数据化运营平台的MVP方案。笔者将会重点从初期用户数据分析痛点的解决、埋点实践经验、数仓与神策分析融合方案三个部分进行阐述。

　　通过初期对业务人员的访谈调研，发现在用户数据的使用层面主要存在三个痛点：用户行为数据缺失、用户渠道效果无法全流程分析、不同运营角色个性化分析需求较多。下面我会对这三个痛点进行分析以及给出选择神策sa的原因。

　　当时公司的现状是，在管理决策层面老板和各部门老大只能拿到结果数据，比如注册用户信息、交易数据等。熟悉运营工作的读者都清楚，用户运营一定是在特定的业务场景下以一系列运营环节的达成为闭环的，比如在线教育常见的营销场景下交易的达成需要的大致环节有“报名-入群-开营-课程体验-课程报名”，再比如，对于App运营用户交易达成的最短路径为“打开App-首页-考试频道页-课程详情页-立即购买-支付订单”。如果在决策者的案头上只有结果性数据而缺乏过程数据，对问题的定位和分析一定是不全面的，难免会陷入盲人摸象的困局。

　　神策数据提供了一整套数据埋点解决方案，包括：全埋点、前后端代码埋点、可视化全埋点等，并且其SDK也做了开源贡献，埋点技术成熟度得到业界认可。采用神策分析，有利于实现不同业务场景下的过程数据埋点全覆盖。

　　公司外部渠道有30多种渠道大类，细分渠道有4000+，不同外部引流渠道用户落地页分布及后续各环节跳转留存情况分析缺失。web、App 10+、小程序 30+，内部多个应用的不同推广板块跳转关系多样化，急需内部渠道追踪分析工具。

　　神策sa提供了一套渠道管理分析解决方案，相关功能如下图拆解所示：

　　项目运营、平台运营、销售运营等多运营角色，不同角色的数据分析诉求不同。项目运营侧重对不同考试对应课程产品的售卖策略分析、营收业绩达成分析等；平台运营侧重对App、小程序等应用进行用户流程优化分析、用户全生命周期分析等；销售运营侧重对用户线索的渠道分析、线索派发、销售跟进、业绩达成等环节的分析。为了满足多样化的数据分析需求，需要一个可灵活自定义的分析工具或平台。

　　神策分析支持事件分析、漏斗分析、留存分析、分布分析、间隔分析、用户路径、网页热力图、归因分析、属性分析等多个分析模型，事件分析较为灵活，支持虚拟事件、自定义事件等，也支持自定义概览及邮件定时发送功能。

　　另外再综合考虑到私有化部署、技术成熟度、埋点能力、功能灵活性和扩展性、自建人力成本及机会成本太高等原因最终选择引进神策分析系统。

　　神策分析部署完之后，需要快速补全过程数据，大量的埋点工作是比不可少的，笔者结合前期的埋点工作的实践经验，总结出如下的埋点设计、管理、校验方法。

　　（1）理解Event-User模型中的Event

　　神策的底层数据模型是 Event + User 的事件模型，因此埋点在神策分析里被称之为“事件”。 每个 User 实体对应一个真实的用户，用 distinct_id 进行标识，描述用户的长期属性，并且该用户可与其所从事的行为，也即 Event 进行关联。

　　为了用最简单的方式理解Event实体，我们可以借鉴中学语文老师讲的叙事文的五要素，即：人+时间+地点+方式+事情，也就是who、when、where、how、what。

　　（2）事件设计要还原到业务场景

　　离开了场景的埋点设计一定会遭到业务同学吐槽的，因为很可能是不可用的。

　　比如在线教育业务场景下常见的事件“浏览课程详情页”事件，运营同学给你提需求时可能会说：“我想看下某个课程页面的被浏览次数”，如果你只把课程详情页的基本信息进行了埋点，那就是没有还原到业务场景中，或者是还原的还不完全。

　　我们将用户浏览课程详情页的行为向前捣两步，可以看到如下的行为序列。这时你会发现，课程详情页的前项页面是很多的，比如有：频道页-课程列表、首页-banner推荐位、直播详情页-课程推荐模块、App闪屏等，如果我们埋点时候不把前项页面名称和所属模块带上，那么行为信息是缺失的，总有一天运营同学还会给你提另一个需求：“怎么查看用户是从哪儿跳转到课程详情页的”。

　　（3）埋点设计文档

　　埋点文档要包括版本号管理、事件页面位置、触发时机、事件中英文名称、变量名称、SDK说明等。

　　（1）埋点管理流程

　　埋点管理流程主要环节有：需求分析、埋点方案设计、需求评审、开发排期、埋点测试、上线回归、需求迭代闭环等环节，每个环节具体需要做什么，参见埋点管理流程图。

　　（2）需求梳理与验收

　　需求梳理环节要结合业务场景，对需求进行分析和拆解。拆解因素主要包括需求提交时间、业务部门、业务背景、需求场景描述、指标、指标定义、维度、用户行为、优先级、频次、验收标准，文档格式参见下图。

　　需求验收主要是需求评审后需要确认研发、测试是否通过或者未通过的原因，主要包括相关分析功能、相关事件、测试是否通过、不通过的原因等。

　　（3）埋点进度管理文档

　　埋点进度管理文档是埋点开发里程碑节点Check工具，文档格式见下图。

　　（4）开发流程优化迭代

　　通过几次埋点迭代的推动之后，发现总是不太顺畅，要不然上线延期、要不然会耗费巨大沟通精力。公司的研发资源分布是按产品线进行布局的，web端、App、小程序、服务端都是专属对口的研发资源，如果我每次埋点都直接和对应研发对接会存在两个问题：

　　负责埋点的产品要和公司80%的研发都打交道，对个人精力是极大消耗；各端研发人员日常工作节奏最熟悉的是期对应端的产品经理，方便把控版本节奏。发现问题后，我对埋点开发流程进行了优化，不再直接和各端研发对接，而是把埋点需求拆解到各端产品经理，让其基于自身的产品版本进度穿插推进，当然这里还会面临各端上线不统一问题，经过逐步优化迭代后形成了较优的埋点开发流程，需要埋点相关文档的同学可以添加我微信获取：tigerhu614899

　　（1）为什么要进行埋点校验

　　埋点校验的必要性主要有两点：

　　数据不准确造成数据权威性丧失，“用数据说话”可能就变成了一句笑话用户一但对系统产生怀疑，会种下一颗邪恶的种子，挽回成本大增（2）怎么进行埋点校验

　　数据校验是个磨人的体力活，因此笔者建议各位小伙伴在进行数据校验前先调整好心态，选定靠谱用户试用，通过他们的经验能快速发现问题，比较分析-与业务系统数据、第三方平台（百度统计、友盟、GA）做对比发现问题，优先排查主数据（订单、用户数据等），常见的埋点校验思路如下：

　　先排除是统计口径问题造成的数据误差对数据链路（采集à上报à入库）进行校验；校验上报的事件及属性是否符合埋点设计文档；统计排查事件属性是否存在大量未知情况

　　神策分析在事件分析上的短板个人认为主要的有两个：

　　模型支持自定义事件，能够解决一些常用的复合指标问题，但是多事件的join后并group by并对结果进行可视化展示就显得有些复杂神策的原始数据是埋点数据，埋点数据更多是对事务事实的表现，讲求特定空间某一时刻的发生事实；当然可以通过对某个时间段埋点事件的聚合完成对周期快照事实的分析，但是针对累积快照事实的分析就显得有些不足了。而以上不足恰恰是数仓的优势，数仓可以将复杂报表提前处理。

　　下面举例本人操作过的经典小案例：

　　在对订单事件进行分析的真实场景中，项目运营人员对事件维度需求可能需要商品信息、用户基本信息、渠道信息、成单销售信息，时间维度可能需要下单时间、支付时间、转正时间、退款时间，对金额的类型要求可能包括售卖金额、应付金额、撤销金额、微信支付金额、支付宝支付金额等，可见其复杂度已经超越的通过埋点解决的ROI承受界限，硬要通过埋点解决显得有点不太聪明了。但是通过数仓的维度建模，我们可以很快给出如下的建模方案：

　　在数仓进行周期性建模在DWD层维护订单累计详情宽表，T+1同步到神策生成对应的订单宽表事件。

　　（1）数据流转链路

　　神策分析和数仓打通的数据流转链路如下图所示，神策分析采集埋点数据并同步一份到数仓，数仓利用其维度建模优势生成方便业务查询使用的宽表事件并同步到神策分析，最终在神策分析系统完成数据的应用展示。

　　（2）神策埋点数据通过订阅分发机制同步数仓

　　神策分析的架构设计是开放式的，可以通过订阅实时数据来满足更多使用场景。服务端接到一条 SDK 发来的数据后，会对数据做一些预处理并将数据写入到消息队列 Kafka 供下游各类计算模块使用。

　　订阅数据要求如下：

　　启动订阅的机器需与部署神策分析的机器在同一个内网，且必须可以解析神策分析服务器的 host；Kafka 客户端版本要选择与部署的神策分析兼容版本；只有私有部署版支持通过 Kafka 订阅数据；订阅参数：

　　（3）数仓加工处理后数据定时导入神策

　　神策架构的优势就是其开放性，当然也提供了多种数据导入工具下，各导入工具对比分析可以参见下表。

　　我司的数据同步方案如下：

　　T+1处理机制，一般是在凌晨进行数据加工处理，并导入神策系统为了保证内部Data pipline工具的统一化，我们基于spark重构了FormatImporter方法同步操作脚本自动化，加入统一workflow进行管理和监控

　　致此本篇文章已接近尾声，以上是笔者实践过的快速构建数据化运营平台的MVP方案。所有的数据产品（平台）都会存在一个困局，业务同学不会用或者用不起来，总有各种问题找上门，这就是产品实施环节缺失造成的，下篇文章笔者将会给出曾操盘过的数据产品实施推广方案，阿尔法行动呼之欲出！

　　本文由 @Tigerhu 原创发布于人人都是产品经理，未经作者许可，禁止转载。

　　题图来自Unsplash，基于CC0协议。