业务|埋点实施的全流程实操与经验分享( 二 )_企业|内部系统|感悟|saas|业务

这种设计方式可以清晰的区分两个类型的页面浏览。但如果页面的类型的灵活添加，并且无上限的话，每增加一次就得埋点一次，无限制的增加维护成本。
【业务|埋点实施的全流程实操与经验分享】这种某个属性来区分事件，且属性会无限制增加的场景，建议按照如下的设计模式。
设计“频道页浏览事件”，并且事件中增加属性“频道页类型”，各种类型的页面如A，B，都是频道页类型的一个属性值。
这样，事件不会再增加了，每次增加都是上报了一个属性值，降低了维护成本。
但是，不能一刀切，如果公司要做一个大型的活动，这个活动很重要，且需要单独的关注页面的浏览情况，关注用户行为，则有必要单独设计一个埋点事件了，如“双十一专题活动页浏览事件”，这样就能单独统计指定埋点，减少干扰。
按照此种思路，继续设计剩余埋点，也要把公共属性和自定义属性都在埋点文档顶部标记出来，公共属性是所有埋点事件都会带的（如平台类型，或者机构ID），便于研发识别。
为了提高准确性，我也列了事件埋点环节的检查清单，请大家收藏备用。
检查清单：

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

四、事件埋点的开发与校验确认埋点需求文档无误后，就进入开发环节，推动各端研发评审需求，讨论上报时机和实现机制，可能会出现需求变动，以全局最优方案为准。
如上所述，神策埋点分为自定义埋点和预置埋点，预置的埋点会直接通过sdk的方式上报到神策的数据库中，自定义埋点在我们公司则通过如下技术流上报：

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

这种架构是为了兼容一些业务属性需要二次处理，比如订单上报后还需要再从CRM系统读取是否为电销成单，所以就把这部分属性传到自己开发的程序中，取数补数等操作，然后再上传。
此处也是给个参考，redis可换成kafka，logagent可换成其他的导入工具，只要能适应公司自身业务就好。
开发环节会遇到各种bug，比如研发不看文档，自己命名，或者不同的研发有按照驼峰命名，有的按照下划线命名，最后上报到系统了，就乱成粥了。
这里也有一个检查清单，有需要的可以收藏备用。
检查清单：

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

五、系统上线与实施培训此环节和正常产品开发没有区别，只是需要提前发布上线邮件，并且组织现场培训，让涉及到的业务方都及时参会，培训埋点的使用场景，如果是第一次对接，这种上线神策方面会提供人员现场培训操作，不再赘述。
六、业务推广与赋能系统上线了，也培训完了，这个还远远不够，因为业务人员还没接受这个系统，不知道这个系统能提供什么价值，或者说知道了系统的价值却不知道如何获取。
所以造成了产品费了好大劲，以为提高了公司的数据成熟度，最终业务没人用的尴尬。
此时就需要业务推广了，分两个角度来阐述。
1. 培训培训的目的，就是让业务人员自己动手操作起来，如何培训也是有套路的。