02-【实操】神策埋点实施的全流程实操与经验分享

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

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

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

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

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

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

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

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


一、需求确认

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


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


二、指标梳理

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


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


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


三、事件埋点的梳理设计

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


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


事件作为一个完整的行为主体,事件下包含的叫事件属性,如“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,也希望大家喜欢

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,937评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,503评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,712评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,668评论 1 276
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,677评论 5 366
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,601评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,975评论 3 396
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,637评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,881评论 1 298
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,621评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,710评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,387评论 4 319
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,971评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,947评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,189评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 44,805评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,449评论 2 342

推荐阅读更多精彩内容