当前位置:主页 > 技术方案 >

如何搭建大数据化运营平台

发布时间:2021-02-02 14:32   浏览次数:次   作者:admin
编辑指南:企业每天都会产生大量的数据,这些数据只有经过分析才能为企业和运营产生价值。大数据平台是为了满足企业的各种数据需求而创建的。如何搭建大数据平台,取决于数据化程度和企业面临的数据问题。本文将从产品设计的角度,阐述设计一个最小可行的数据化运营平台的思维过程,供大家参考和学习。
上一篇文章讲的是如何为基础信息能力相对完善但数据能力不足的在线教育公司搭建大数据平台。有兴趣的同学可以参考《在线教育大数据营销平台实战(一):大数据平台建设实战》。
大数据平台的建设是为了从底层解决业务面临的数据问题,而且必须要有一个时间段,所以对业务的贡献不会马上显现,业务也不会意识到数据的赋权,必然会影响老板对数据团队的资源投入。这个无限循环怎么解?
在本文中,我将根据自己的实践经验,说明如何在数据能力建设的初始阶段,利用第三方数据系统(厕神公司)和内部数据仓库的结合,构建支持数据运营平台的MVP方案。作者将重点介绍三个部分,即初始用户数据分析痛点的解决方案、掩埋痛点的实践经验、数据仓库与策略分析的集成方案。
一、初始痛点及解决方案。
通过对业务人员的初步访谈和调查,发现用户数据的使用存在三个主要痛点:用户行为数据缺乏、无法分析用户渠道效应的全过程、需要对不同运营角色进行个性化分析。下面我将分析这三个痛点,并给出选择厕神sa的理由。
1.缺少过程数据。
当时公司的现状是,在管理决策层,老板和各部门负责人只能得到结果数据,比如注册用户信息和交易数据。熟悉运营工作的读者都知道,用户运营必须是闭环的,在特定的业务场景中有一系列的运营环节。例如,在线教育的常见营销场景中,交易所需的一般链接是“注册-加入团体-开设营地-课程体验-课程注册”。再比如,App运营用户交易的最短路径是“打开App-首页-考试频道页面-课程详情页面-立即购买-支付订单”如果决策者桌上只有结果数据而没有过程数据,那么问题的定位和分析必然是不完整的,必然会陷入盲人摸象的困境。
厕神数据提供了一套完整的数据嵌入解决方案,包括:全嵌入点、前后码嵌入点、可视化全嵌入点等。,其SDK也做出了开源的贡献,嵌入点技术的成熟得到了业界的认可。采用智能策略分析,有利于实现不同业务场景下流程数据埋点的全覆盖。
2.很难全方位追踪通道效应。
公司外部渠道有30多种渠道,细分渠道4000多个。用户登陆页面在不同外部引流渠道的分布以及后续环节跳转留存的分析缺失。Web,App10+,applet30+,多个内部应用的不同推广板块的跳转关系是多样化的,因此迫切需要内部渠道跟踪分析工具。
厕神sa提供了一套渠道管理分析解决方案,相关功能如下图所示:
3.不同运营角色的分析需求是多样化的。
项目运营、平台运营、销售运营等多种运营角色对数据分析的需求不同。项目运营重点是不同考试对应的课程产品的销售策略分析和收益表现分析;平台运营侧重于针对App、applets等应用的用户流程优化分析和用户生命周期分析;销售运营主要集中在渠道分析、销售线索分配、销售跟进、绩效实现等环节。为了满足多样化的数据分析需求,需要一个灵活定制的分析工具或平台。
厕神分析支持多种分析模型,如事件分析、漏斗分析、保留分析、分布分析、区间分析、用户路径、网页热图、属性分析、属性分析等。事件分析灵活,支持虚拟事件、自定义事件等。,以及自定义概述和常规邮件发送功能。
此外,考虑到民营化部署、技术成熟度、嵌入能力、功能灵活性和可扩展性、自建人工成本和高机会成本,我们最终选择引入厕神分析系统。
二是埋点的设计、管理和标定。
厕神分析部署后,需要快速填写过程数据,大量的掩埋工作必不可少。作者结合以往埋设工作的实践经验,总结了以下埋设设计、管理和验证方法。
1.埋点设计思路。
(1)理解事件-用户模型中的事件。
厕神的底层数据模型是Event+User的事件模型,所以在厕神分析中埋点被称为“事件”。每个用户实体对应一个真实的用户,这个用户由distinct_id标识,描述用户的长期属性,用户可以与他所从事的行为相关联,即Event。
为了最简单的理解事件实体,可以借鉴中学语文老师写的记叙文的五行,即人+时间+地点+方式+事物,即谁、何时、何地、如何、什么。
(2)事件设计应该恢复到业务场景。
没有场景的埋没设计,必然会被商科学生吐槽,因为很可能没有。
比如在线教育业务场景中,常见事件“浏览课程详情页面”,操作学生可能会说“我想看看一个课程页面被浏览的次数”。如果只埋了课程详情页面的基本信息,则不会还原到业务场景,或者还原不完整。
我们把用户浏览课程详情页面的行为向前推两步,可以看到下面的行为顺序。这时你会发现,课程详情页中有很多之前的页面,比如:频道页面-课程列表、首页-横幅推荐位、直播详情页-课程推荐模块、App闪屏等。如果埋的时候不带上上一页的名字和所属的模块,那么行为信息就没了。总有一天,运营生会给你另一个需求:“如何看到用户跳转到课程详情页面的什么地方?”
(3)埋点设计文件。
嵌入文档应包括版本号管理、事件页面位置、触发时间、事件的中英文名称、变量名、SDK描述等。
2.掩埋点管理的思想。
(1)埋点管理流程。
埋点管理流程的主要环节包括:需求分析、埋点方案设计、需求评审、开发调度、埋点测试、在线回归、需求迭代闭环等。具体每个环节需要做什么,请参考埋点管理流程图。
(2)需求梳理和接受。
在需求梳理过程中,需要结合业务场景对需求进行分析和分解。拆解因素主要包括需求提交时间、业务部门、业务背景、需求场景描述、指标、指标定义、维度、用户行为、优先级、频次、接受标准。文档格式见下图。
需求验收主要是指需求评审后需要确认R&D和测试是否通过的原因,主要包括相关分析功能、相关事件、测试是否通过等。
(3)埋点进度管理文件。
埋藏点进度管理文档是埋藏点开发里程碑节点的Check工具,文档格式如下图所示。
(4)开发过程优化迭代。
经过几次迭代,发现总是不顺利,或者上线会延迟,或者会耗费大量的通信能量。该公司的R&D资源根据产品线进行分配。网站、应用程序、小程序和服务器都是R&D独有的资源。如果我每次都埋站点,会有两个问题:
负责掩埋现场的产品要处理公司80%的研发,这是对个人精力的极大消耗;
各端R&D人员的日常工作节奏,是对应端产品经理最熟悉的,便于控制版本节奏。
发现问题后,我优化了埋点的开发流程,没有在每一端直接和R&D联系,而是把埋点的需求拆解给每一端的产品经理,让他们按照自己的产品版本进度推进。当然也会有各端上线不统一的问题。经过逐步优化和迭代,形成了较好的埋点开发流程。
3.埋点数据的验证。
(1)为什么要查埋点?
埋点标定的必要性主要包括两点:
数据不准确导致数据权威丧失,“用数据说话”可能成为笑话。
一旦用户对系统产生怀疑,就会种下一颗邪恶的种子,恢复成本会大大增加。
(2)如何检查埋点。
数据验证是一项费力的体力活动,建议各位朋友在数据验证前调整好自己的善意。