干货分享：埋点实践过程中碰到的坑点集合

埋点本身现在已经有太多的集成解决方案，神策、诸葛IO、GIO，但是在实践的过程中仍然还是会碰都很多问题，这些问题都是躺过的坑。

① 业务兼容的问题

前期规范执行之后，后续随着业务的拓展，已有数据字段满足不了业务的分析需求；

② 产品兼容的问题

埋点从应用端来区分，web/ios/android，小程序，公众号，然后还要区分一下是否是原生，还是H5，新老版本之间肯定会带来一些模块化的差异；

前端请求服务端的数据大多是存在binlog里面的，数据日志同步解析的过程里面可能会存在丢包的可能性，数仓的稳定性也会影响数据质量；后端服务信息存储的数据是存在mysql，表字段结构化，分多表存储，需要靠主键进行关联，有大量的ETL过程。两者之间可能因为数据清洗、处理、实时技术等原因，造成数据差异化；

③ 自埋点和第三方应用统计口径的问题

自埋点一般都会定义一个唯一id作为区分用户的标志，但是第三方是缺少用户属性信息的判断，一般会以设备号uuid/imse，或者IP地址段、mac地址段作为区分标志，从而造成统计数据上的差异化，对于留存分析、转化分析、流失分析需要用到明细数据的场景，可兼容性不是很友好；

④ 埋点开发技术执行不到位的问题

绝大多数情况下我们说埋点，一般都是说前端埋点，前端开发工程师在做埋点的时候又多是人为埋点，在开发过程中，会造成部分信息冗余、重复、记录不完整的情况存在；

⑤ 多产品之间的模块差异化问题

埋点不能够只有一套标准规范，多生态应用下，业务繁琐，在产品、技术的架构上有明显的差异，不同的产品、模块、坑位、点击事件的定义也可能有一定的区别，这时候可能需要根据场景划分不同的埋点标准；

⑥ 自定义埋点信息的键对设计问题

往往会在埋点里面增加一个json的字段（bdata），在埋点的时候写入自定义的业务信息进行场景识别，譬如活动id、业务信息、用户快照的基本信息等，不同开发写入的自定义字段格式可能会有差异；

基于业务分析框架，梳理常规分析案例中需要用到的埋点数据集，核心指标必须要有埋点；

基于算法模型框架，梳理算法所需要构建的数据特征需要用到的字段信息；

基于业务诉求，梳理非常规，当前没需求未来有应用场景的字段信息；

举个例子，譬如供需匹配、资源调度、智能选址，所对应的几个信息主体分别是：用户需求方、用户供给方、商品信息、时间信息、空间信息、行为信息、业务信息；

基于用户画像的标签建设，需要考虑画像的多层属性，社会属性、基本属性、市场属性、交易属性、行为属性等，通过画像筛选人群的时候，可能需要通过数据模型建立用户分层的过程，所需要用到的辅助数据；

基于智能运营的标签建设，运营策略、活动、方案的数据需求收集，哪些标签需要用到埋点中的信息；

基于营销系统的标签建设，涉及到渠道分配、广告投放、点击预测等，可能需要对曝光、点击、转化进行全链路的埋点建设，或者基于某一个产品使用链路，埋点数据要完备；

标签管理，没有一套产品来支撑，多标签你怎么对外提供；海量的标签，又要怎么做标签管理；

推荐算法中需要用到的数据特征中包含哪些数据指标，其中埋点的部分所需要的数据格式是怎样的；

推荐算法的设计方案，基于用户、基于物品、协同过滤、基于规则、基于融合模型，不同的方案下，对数据底层的要求可能也会有一定的差异；

埋点数据落到数仓后，需要预先建立哪些表，如何做埋点数据的分层；

毕竟埋点的数据体量是非常大的，TB级数据的存储本身就是一个比较大的成本，再加上调度系统、计算资源、运行性能等方面，就需要数仓团队在一开始就要把数据模型提前建立好，做好ods层到dw层、ads层的划分，维度和事实之间的建设；

因为埋点数据的体量问题，落表的时候，一定会存在大量的冗余字段，如果集群资源比较紧张，对于常规数据的统计、计算都会带来性能上的问题；

在数据团队的架构中，有对外提供数据应用服务，对于数据的实时计算就有一定的要求，什么场景下应该是T+1，什么场景下应该是伪实时，避免数据调度任务影响前台应用产出；

全埋点和分模块埋点，直接的影响是数据存储成本的问题，作为一个数据分析，这也是不得不考虑的问题，如果数据结构优化不做好，每年浪费的存储成本可能会是百万级的消耗。随着周期的增加，成本浪费会更严重。

所以说，企业数据的分析，不仅局限在数据本身，而应该是全面的剖析，多场景的结合。凡事都不简单，如果简单为什么那么多人都没有做成功，只不过是层次还到而已。