【实操干货】神策埋点实施的全流程实操与业务经验分享

神策的文章,原计划4篇

第一篇为《从甲方角度拆解神策——优质的SaaS大数据产品》

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

 

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

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

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

 

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

 

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

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

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

神策需求对接的参与流程

神策需求对接的参与流程

 

分开来详细讲述

 

一、需求确认

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

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

 

二、指标梳理

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

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

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

 

三、事件埋点的梳理设计

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

神策的埋点逻辑,是基于用户-事件模型,这个模型的细节再上一篇文章有讲,感兴趣的小伙伴可以查看《从甲方角度拆解神策——优质的SaaS大数据产品》

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

 

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

 

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

 

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

 

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

 

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

 

设计“频道页浏览事件”,并且事件中增加属性“频道页类型”,各种类型的页面如A,B,都是频道页类型的一个属性值
这样,事件不会再增加了,每次增加都是上报了一个属性值,降低了维护成本
但是,不能一刀切,如果公司要做一个大型的活动,这个活动很重要,且需要单独的关注页面的浏览情况,关注用户行为,则有必要单独设计一个埋点事件了,如“双十一专题活动页浏览事件”,这样就能单独统计指定埋点,减少干扰

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

 

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

 

检查清单

1、事件英文变量名,大小写检查,重名检查

2、属性英文名,大小写检查,重名检查

3、属性值类型,逐个属性检查,避免出现同属性名,但类型不同的情况

4、埋点的端,要尽量标明

5、触发的时机,也要在每个事件上备注清楚

 

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

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

 

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

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

 

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

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

 

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

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

 

检查清单

1、检查测试环境上报的事件名与文档的事件名,包括大小写

2、检查测试环境上报的属性名与文档的属性名,包括大小写

3、测试环境上报的事件名与属性的关系,对比文档中的事件属性关系

 

五、系统上线与实施培训

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

 

六、业务推广与赋能

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

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

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

 

(一)培训

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

公司内部团体,其实本质就是一个社区

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

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

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

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

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

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

 

(二)传递价值

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

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

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

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

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

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

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

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

 

具体SOP主页截图如下,如果大家有需要,文章没法放附件,可以关注我的公号 罗文正雄,回复“SOP”即可获得脱敏源文件

 

 

此环节检查清单

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

 

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

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

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

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

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

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

 

结语

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

现在由于职业规划的原因,我已经离开这个教育公司,去往一家供应链的公司,想奔着数据做更深的发展,神策的文章我们告一段落,后面我将开一个新篇章——UML,也希望大家喜欢

 

You may also like...

发表评论