干货分享:埋点实践过程中碰到的坑点集合
作者|西索
埋点本身现在已经有太多的集成解决方案,神策、诸葛IO、GIO,但是在实践的过程中仍然还是会碰都很多问题,这些问题都是躺过的坑。
01 梳理当前业务,未来业务发展问题,目的是给埋点预留空间
① 业务兼容的问题
前期规范执行之后,后续随着业务的拓展,已有数据字段满足不了业务的分析需求;
② 产品兼容的问题
埋点从应用端来区分,web/ios/android,小程序,公众号,然后还要区分一下是否是原生,还是H5,新老版本之间肯定会带来一些模块化的差异;
③ 前后端埋点不一致的问题
前端请求服务端的数据大多是存在binlog里面的,数据日志同步解析的过程里面可能会存在丢包的可能性,数仓的稳定性也会影响数据质量;后端服务信息存储的数据是存在mysql,表字段结构化,分多表存储,需要靠主键进行关联,有大量的ETL过程。两者之间可能因为数据清洗、处理、实时技术等原因,造成数据差异化;
③ 自埋点和第三方应用统计口径的问题
自埋点一般都会定义一个唯一id作为区分用户的标志,但是第三方是缺少用户属性信息的判断,一般会以设备号uuid/imse,或者IP地址段、mac地址段作为区分标志,从而造成统计数据上的差异化,对于留存分析、转化分析、流失分析需要用到明细数据的场景,可兼容性不是很友好;
④ 埋点开发技术执行不到位的问题
绝大多数情况下我们说埋点,一般都是说前端埋点,前端开发工程师在做埋点的时候又多是人为埋点,在开发过程中,会造成部分信息冗余、重复、记录不完整的情况存在;
⑤ 多产品之间的模块差异化问题
埋点不能够只有一套标准规范,多生态应用下,业务繁琐,在产品、技术的架构上有明显的差异,不同的产品、模块、坑位、点击事件的定义也可能有一定的区别,这时候可能需要根据场景划分不同的埋点标准;
⑥ 自定义埋点信息的键对设计问题
往往会在埋点里面增加一个json的字段(bdata),在埋点的时候写入自定义的业务信息进行场景识别,譬如活动id、业务信息、用户快照的基本信息等,不同开发写入的自定义字段格式可能会有差异;
02 埋点应用场景,对应初期埋点预留
基于业务分析框架,梳理常规分析案例中需要用到的埋点数据集,核心指标必须要有埋点;
基于算法模型框架,梳理算法所需要构建的数据特征需要用到的字段信息;
基于业务诉求,梳理非常规,当前没需求未来有应用场景的字段信息;
举个例子,譬如供需匹配、资源调度、智能选址,所对应的几个信息主体分别是:用户需求方、用户供给方、商品信息、时间信息、空间信息、行为信息、业务信息;
03 标签预留场景,反推埋点预留
基于用户画像的标签建设,需要考虑画像的多层属性,社会属性、基本属性、市场属性、交易属性、行为属性等,通过画像筛选人群的时候,可能需要通过数据模型建立用户分层的过程,所需要用到的辅助数据;
基于智能运营的标签建设,运营策略、活动、方案的数据需求收集,哪些标签需要用到埋点中的信息;
基于营销系统的标签建设,涉及到渠道分配、广告投放、点击预测等,可能需要对曝光、点击、转化进行全链路的埋点建设,或者基于某一个产品使用链路,埋点数据要完备;
标签管理,没有一套产品来支撑,多标签你怎么对外提供;海量的标签,又要怎么做标签管理;
04 后面做推荐抓到核心指标,前期做埋点预设
推荐算法中需要用到的数据特征中包含哪些数据指标,其中埋点的部分所需要的数据格式是怎样的;
推荐算法的设计方案,基于用户、基于物品、协同过滤、基于规则、基于融合模型,不同的方案下,对数据底层的要求可能也会有一定的差异;
05 数仓库表的开发成本
埋点数据落到数仓后,需要预先建立哪些表,如何做埋点数据的分层;
毕竟埋点的数据体量是非常大的,TB级数据的存储本身就是一个比较大的成本,再加上调度系统、计算资源、运行性能等方面,就需要数仓团队在一开始就要把数据模型提前建立好,做好ods层到dw层、ads层的划分,维度和事实之间的建设;
06 数仓性能,时间问题(hive)
因为埋点数据的体量问题,落表的时候,一定会存在大量的冗余字段,如果集群资源比较紧张,对于常规数据的统计、计算都会带来性能上的问题;
在数据团队的架构中,有对外提供数据应用服务,对于数据的实时计算就有一定的要求,什么场景下应该是T+1,什么场景下应该是伪实时,避免数据调度任务影响前台应用产出;
07 产品全埋点还是分块埋点?分块儿埋点的话有什么响应机制?应用措施?
全埋点和分模块埋点,直接的影响是数据存储成本的问题,作为一个数据分析,这也是不得不考虑的问题,如果数据结构优化不做好,每年浪费的存储成本可能会是百万级的消耗。随着周期的增加,成本浪费会更严重。
所以说,企业数据的分析,不仅局限在数据本身,而应该是全面的剖析,多场景的结合。凡事都不简单,如果简单为什么那么多人都没有做成功,只不过是层次还到而已。
-END-