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

文章插图
神策的第一篇为《从甲方角度，拆解神策》，后续要讲解实操经验，为提高阅读体验和连贯性，本篇文章将神策的实施，埋点流程，业务赋能实操，原本后3篇的内容，压缩到一篇来讲解，也能省去一些铺垫，如果有问题探讨，可评论或者私信沟通，我将做到尽量解答。
第三方采购的SaaS系统，如何与自家业务结合，是一个比较头疼的事情。
首先，在接到需求之后，系统间的对接和调整，是一个比较大的工程。
其次，系统对接之后，业务实施需要哪些具体步骤，每个步骤如何行动，也比较难快速明确。
本篇文章尽量将业务实践中遇到的问题，以及每个细节都呈现出来，如果觉得有用，可以收藏，便于日后遇到有需要的时候使用和排查。
站在公司内部产品角度出发，神策这种数据系统，一个相对完整的实施流程会包含有如下环节：
需求确认——指标梳理——事件埋点的梳理设计——事件埋点的开发与校验——系统上线与实施——业务推广与赋能

文章插图
具体的环节和参与方，可参考这个图
一、需求确认即采购神策是为了解决什么问题，这一步是企业和神策双方一起讨论，澄清需求和问题。一般情况下企业的参与方必须有业务线的产品负责人，以及对应的产品经理，以及技术的负责人。
业务线产品负责人更偏向务虚，确认业务需求的满足，技术负责人更偏向务实，考虑和确认双方的技术对接，性能限制，接口逻辑等。
二、指标梳理在需求澄清后，进入到指标的梳理环节，即企业本身需要明确自身的业务发展阶段，确认本业务阶段中需要考察的核心指标，这个指标一般会面向各个业务端口收集。
拿在线教育举例，一般会关注访问相关的指标，活跃相关指标，营收相关指标，学习指标，如果是电销的业务还会关注外呼相关的指标。
此环节会有企业方和神策方一起协作完成，具体问题具体分析，但核心的原则，就是要理清楚自家企业要关注的指标，明确每个指标的描述口径，将有歧义的指标订正，将重复定义的指标去重，将无意义的指标删掉，确保第一期开发可以满足最小范围的业务闭环。
三、事件埋点的梳理设计此环节为重点环节，在指标梳理清楚之后，就进入到了事件的具体设计工作。
神策的埋点逻辑，是基于用户-事件模型，这个模型的细节再上一篇文章有讲，感兴趣的小伙伴可以查看http://www.woshipm.com/it/4342700.html
事件作为一个完整的行为主体，事件下包含的叫事件属性，如“web页面浏览事件”包含了“页面标题”，“页面地址”等属性。

文章插图
神策本身会自带预置事件和预置属性，名为“$xxx”的格式，为神策SDK中自行上报，如果这部分事件可以满足部分需求，则无需再开发。
神策没自带的事件，就需要自己设计了，这里有个例子，大家可以感受到两种不同的设计思路，根据自家业务情况灵活权衡。
公司的网页类型有很多，并且会经常随着业务的需求变化增加网页类型，但规律比较容易感知。产品这里可以按照每个类型的页面单独设计一个埋点，如“A类型页面浏览事件”，“B类型页面浏览事件”。
这种设计方式可以清晰的区分两个类型的页面浏览。但如果页面的类型的灵活添加，并且无上限的话，每增加一次就得埋点一次，无限制的增加维护成本。
这种某个属性来区分事件，且属性会无限制增加的场景，建议按照如下的设计模式。
设计“频道页浏览事件”，并且事件中增加属性“频道页类型”，各种类型的页面如A，B，都是频道页类型的一个属性值。
这样，事件不会再增加了，每次增加都是上报了一个属性值，降低了维护成本。
但是，不能一刀切，如果公司要做一个大型的活动，这个活动很重要，且需要单独的关注页面的浏览情况，关注用户行为，则有必要单独设计一个埋点事件了，如“双十一专题活动页浏览事件”，这样就能单独统计指定埋点，减少干扰。
按照此种思路，继续设计剩余埋点，也要把公共属性和自定义属性都在埋点文档顶部标记出来，公共属性是所有埋点事件都会带的（如平台类型，或者机构ID），便于研发识别。

稿源：(人人都是产品经理)

【傻大方】网址：http://www.shadafang.com/c/11159615G2021.html

标题：业务|埋点实施的全流程实操与经验分享