埋点实施的全流程实操与经验分享

2 评论 5439 浏览 20 收藏 16 分钟

编辑导语:埋点实施怎么做?第三方采购的SaaS系统,如何与自家业务对接?本篇文章从实战经验出发,讲解了埋点流程,专注于业务赋能实操,相对完整地展现了全流程,希望能给大家帮助和启发。推荐感兴趣的朋友们阅读。

神策的第一篇为《从甲方角度,拆解神策》,后续要讲解实操经验,为提高阅读体验和连贯性,本篇文章将神策的实施,埋点流程,业务赋能实操,原本后3篇的内容,压缩到一篇来讲解,也能省去一些铺垫,如果有问题探讨,可评论或者私信沟通,我将做到尽量解答。

第三方采购的SaaS系统,如何与自家业务结合,是一个比较头疼的事情。

首先,在接到需求之后,系统间的对接和调整,是一个比较大的工程。

其次,系统对接之后,业务实施需要哪些具体步骤,每个步骤如何行动,也比较难快速明确。

本篇文章尽量将业务实践中遇到的问题,以及每个细节都呈现出来,如果觉得有用,可以收藏,便于日后遇到有需要的时候使用和排查。

站在公司内部产品角度出发,神策这种数据系统,一个相对完整的实施流程会包含有如下环节:

需求确认——指标梳理——事件埋点的梳理设计——事件埋点的开发与校验——系统上线与实施——业务推广与赋能

具体的环节和参与方,可参考这个图

一、需求确认

即采购神策是为了解决什么问题,这一步是企业和神策双方一起讨论,澄清需求和问题。一般情况下企业的参与方必须有业务线的产品负责人,以及对应的产品经理,以及技术的负责人。

业务线产品负责人更偏向务虚,确认业务需求的满足,技术负责人更偏向务实,考虑和确认双方的技术对接,性能限制,接口逻辑等。

二、指标梳理

在需求澄清后,进入到指标的梳理环节,即企业本身需要明确自身的业务发展阶段,确认本业务阶段中需要考察的核心指标,这个指标一般会面向各个业务端口收集。

拿在线教育举例,一般会关注访问相关的指标,活跃相关指标,营收相关指标,学习指标,如果是电销的业务还会关注外呼相关的指标。

此环节会有企业方和神策方一起协作完成,具体问题具体分析,但核心的原则,就是要理清楚自家企业要关注的指标,明确每个指标的描述口径,将有歧义的指标订正,将重复定义的指标去重,将无意义的指标删掉,确保第一期开发可以满足最小范围的业务闭环。

三、事件埋点的梳理设计

此环节为重点环节,在指标梳理清楚之后,就进入到了事件的具体设计工作。

神策的埋点逻辑,是基于用户-事件模型,这个模型的细节再上一篇文章有讲,感兴趣的小伙伴可以查看http://www.woshipm.com/it/4342700.html

事件作为一个完整的行为主体,事件下包含的叫事件属性,如“web页面浏览事件”包含了“页面标题”,“页面地址”等属性。

神策本身会自带预置事件和预置属性,名为“$xxx”的格式,为神策SDK中自行上报,如果这部分事件可以满足部分需求,则无需再开发。

神策没自带的事件,就需要自己设计了,这里有个例子,大家可以感受到两种不同的设计思路,根据自家业务情况灵活权衡。

公司的网页类型有很多,并且会经常随着业务的需求变化增加网页类型,但规律比较容易感知。产品这里可以按照每个类型的页面单独设计一个埋点,如“A类型页面浏览事件”,“B类型页面浏览事件”。

这种设计方式可以清晰的区分两个类型的页面浏览。但如果页面的类型的灵活添加,并且无上限的话,每增加一次就得埋点一次,无限制的增加维护成本。

这种某个属性来区分事件,且属性会无限制增加的场景,建议按照如下的设计模式。

设计“频道页浏览事件”,并且事件中增加属性“频道页类型”,各种类型的页面如A,B,都是频道页类型的一个属性值。

这样,事件不会再增加了,每次增加都是上报了一个属性值,降低了维护成本。

但是,不能一刀切,如果公司要做一个大型的活动,这个活动很重要,且需要单独的关注页面的浏览情况,关注用户行为,则有必要单独设计一个埋点事件了,如“双十一专题活动页浏览事件”,这样就能单独统计指定埋点,减少干扰。

按照此种思路,继续设计剩余埋点,也要把公共属性和自定义属性都在埋点文档顶部标记出来,公共属性是所有埋点事件都会带的(如平台类型,或者机构ID),便于研发识别。

为了提高准确性,我也列了事件埋点环节的检查清单,请大家收藏备用。

检查清单:

  1. 事件英文变量名,大小写检查,重名检查
  2. 属性英文名,大小写检查,重名检查
  3. 属性值类型,逐个属性检查,避免出现同属性名,但类型不同的情况
  4. 埋点的端,要尽量标明
  5. 触发的时机,也要在每个事件上备注清楚

四、事件埋点的开发与校验

确认埋点需求文档无误后,就进入开发环节,推动各端研发评审需求,讨论上报时机和实现机制,可能会出现需求变动,以全局最优方案为准。

如上所述,神策埋点分为自定义埋点和预置埋点,预置的埋点会直接通过sdk的方式上报到神策的数据库中,自定义埋点在我们公司则通过如下技术流上报:

  1. 客户端——redis
  2. 一套自己开发的拉取程序(原理是拉取上报的落盘数据,并使用神策的sdk转成sa日志文件)
  3. logAgent导入到神策数据库

这种架构是为了兼容一些业务属性需要二次处理,比如订单上报后还需要再从CRM系统读取是否为电销成单,所以就把这部分属性传到自己开发的程序中,取数补数等操作,然后再上传。

此处也是给个参考,redis可换成kafka,logagent可换成其他的导入工具,只要能适应公司自身业务就好。

开发环节会遇到各种bug,比如研发不看文档,自己命名,或者不同的研发有按照驼峰命名,有的按照下划线命名,最后上报到系统了,就乱成粥了。

这里也有一个检查清单,有需要的可以收藏备用。

检查清单:

  1. 检查测试环境上报的事件名与文档的事件名,包括大小写
  2. 检查测试环境上报的属性名与文档的属性名,包括大小写
  3. 测试环境上报的事件名与属性的关系,对比文档中的事件属性关系

五、系统上线与实施培训

此环节和正常产品开发没有区别,只是需要提前发布上线邮件,并且组织现场培训,让涉及到的业务方都及时参会,培训埋点的使用场景,如果是第一次对接,这种上线神策方面会提供人员现场培训操作,不再赘述。

六、业务推广与赋能

系统上线了,也培训完了,这个还远远不够,因为业务人员还没接受这个系统,不知道这个系统能提供什么价值,或者说知道了系统的价值却不知道如何获取。

所以造成了产品费了好大劲,以为提高了公司的数据成熟度,最终业务没人用的尴尬。

此时就需要业务推广了,分两个角度来阐述。

1. 培训

培训的目的,就是让业务人员自己动手操作起来,如何培训也是有套路的。

公司内部团体,其实本质就是一个社区,用运营社区的方式去运营公司的内部这些业务分析师团队,按照这个框架去运营效果会好些:

  1. 产品组织培训
  2. 核心KOL的扶持
  3. 组织更多专题培训,逐步增加KOL的曝光
  4. 让KOL获得成就感,主动去分享
  5. 社区活跃自洽

产品这里要全程参与,还是要把控节奏的。

拿我推广智能运营来讲,先公司内部各个项目部逐个约小范围手把手培训,录制简单视频,累计培训了21轮。

然后培育出一些业务的实践案例,对某个top项目特定来源的用户销转提高了5个百分点,把这个案例成果,以及具体的配置方法写成案例,发送全员,让产出成果的人获得成就感,让没产生结果的人产生焦虑感,这个社区的动力就来了!

最后经过了一个月左右,突然有一天,我们的平台运营部主动发了个全员邮件,说要分享下自己的运营规范,让大家参考,这个时候,就已经稳了,大家已经进入了良性循环,互相促进。

2. 传递价值

上述的培训,从某种程度上讲,也是价值的传递,让业务亲身感受到好处,感受到价值。让业务人员直呼“这玩意真好用”。

小案例还是不够刺激,还得来一波大的,公司仍然没用神策组织过大型的公司级活动,正好,双十一来了。

双十一的活动的实施难度很大,相当于全公司的资源都调动了一遍,主办活动的运营同学在数据方面也没啥经验,这个时候,就得产品上了。

其实产品这里也是第一次,但本质上还是项目管理,从项目管理的角度出发,梳理下各个活动环节涉及到的人,物料等因素。最后整理一个全局的文档,让业务人员根据这个文档,可以快速的查看自己的负责范围,以及时间线。

最终,这年双十一的活动在数据的加持和快速反馈下,以及各种其他因素的叠加下,比这上一年度提升了超过100%,很激动。

基于这个第一次的活动,也相当于对公司从零突破把公司级别大型活动的sop梳理了一遍,符合公司层面的实际业务情况,沉淀了价值。

这个活动的sop,包含数据埋点的梳理、活动玩法管理、活动商品的梳理、页面埋点物料的梳理、测试物料、上线预运营、活动看板配置,数据如何追踪标记,节后复盘等流程的细节,并且还在文档中建立了真实的活动经验积累,每次活动都有新增,对后续活动有很强的借鉴和指导意义。

在双十一之后,这个sop又支持了公司的双十二等后续活动,流程顺利。

此环节检查清单:可参照sop的清单来检查,如果公司本身有数据活动的流程,那自然是极好的!

3. 争议的点:产品在实施的过程要做哪些事?

直白的说,能采购第三方服务系统的公司,大概率可以推定公司本身在这个领域不够强,或者更省成本,或者做了效果不够好。

神策的实施,分工上其实是一个灰色地带,研发、业务等部门都无法立刻感受到系统的必要性,并且也不承担任何关于系统的责任,此时必须有一个主导的角色,一个带头人,只能是产品经理。

产品经理是解决问题的,如果严格的把问题边界划分清楚,那很多关于神策实施赋能业务的点,都无法推动,也就无法产生效果,作为一个产品,如果是站在解决问题的角度,可以使劲的把事情往前推,即使后面有了功绩大家一起平摊,也是一个正向的解决。

如果要站在“事不关己高高挂起”的态度,那么关于神策的实施这里会进入死停滞的状态,大家都在等,项目进度无法向前,最后项目失败,产品是肯定不愿看到的。

所以,在遇到一个问题时,产品要主动承担,先把所谓的背锅念头抛开。

七、结语

本系列文章的初衷,是对自己在这家教育公司数据化转型工作,做一个完整的总结,转化成自己经验的同时,也做到可以让别人学习,给其他接触神策系统的朋友们一些可实操的方法和工具。

现在由于职业规划的原因,神策的文章我们告一段落,后面我将开一个新篇章——UML,也希望大家喜欢。

 

作者:罗文正雄;公众号:罗文正雄

本文由 @罗文正雄 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Pixabay,基于 CC0 协议

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 看不懂

    回复
  2. 不错不错,给了我一个新的思路,但还是要实践出真相啊,先收藏了哈哈哈!

    回复