编辑导语：埋点实施怎么做？第三方采购的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 协议