埋点方案选择
全埋点 or 分模块埋点，直接影响数据存储成本
- 如果数据结构优化不做好，每年浪费的存储成本可能会是百万级的消耗，随着周期的增加、成本浪费会更严重。
技术层面问题
事件上报机制
- 例如：APP，需要做延时上报，将数据预先存储在手机上，等到有 WIFI 环境时再上报；
业务兼容的问题
- 前期规范执行之后，后续随着业务的拓展，已有数据字段满足不了业务的分析需求。
前端版本兼容的问题
- 埋点从应用端来区分，web/ios/android，小程序，公众号；
- 然后还要区分一下是原生、还是 H5，新老版本之间肯定会带来一些模块化的差异。
前端埋点数据丢失问题
- 前端请求服务端的数据大多存在 binlog 里面的，数据日志同步解析的过程里面可能会存在丢包的可能性，数仓的稳定性也会影响数据质量。
埋点数据和后端数据不一致
- 后端服务信息存储的数据是存在 mysql，表字段结构化，分多表存储，需要靠主键进行关联，有大量的ETL过程。
- 两者之间可能因为数据清洗、处理、实时技术等原因，造成数据差异化；
埋点开发技术执行不到位的问题
- 绝大多数情况下我们说埋点，一般都是说前端埋点，前端开发工程师在做埋点的时候又多是人为埋点，在开发过程中，会造成部分信息冗余、重复、记录不完整的情况存在；
应用层面问题
多产品之间的模块差异化问题
- 埋点不能够只有一套标准规范，多生态应用下，业务繁琐，在产品、技术的架构上有明显的差异，不同的产品、模块、坑位、点击事件的定义也可能有一定的区别，这时候可能需要根据场景划分不同的埋点标准；
自定义埋点信息的键对设计问题
- 往往会在埋点里面增加一个json的字段（bdata），在埋点的时候写入自定义的业务信息进行场景识别，譬如活动id、业务信息、用户快照的基本信息等，不同开发写入的自定义字段格式可能会有差异；
自埋点和第三方应用统计口径的问题
- 自埋点一般都会定义一个唯一id作为区分用户的标志，但是第三方是缺少用户属性信息的判断，一般会以设备号uuid/imse，或者IP地址段、mac地址段作为区分标志，从而造成统计数据上的差异化；
- 对于留存分析、转化分析、流失分析需要用到明细数据的场景，可兼容性不是很友好，需要进行 ID Mapping 操作。
预留字段问题
基于业务需求、预留字段
- 基于业务分析框架，梳理常规分析案例中需要用到的埋点数据集，核心指标必须要有埋点；
- 基于算法模型框架，梳理算法所需要构建的数据特征需要用到的字段信息；
- 基于业务诉求，梳理非常规、当前没需求未来有应用场景的字段信息；
基于用户标签、预留字段
- 基于用户画像的标签建设，需要考虑画像的多层属性，社会属性、基本属性、市场属性、交易属性、行为属性等，通过画像筛选人群的时候，可能需要通过数据模型建立用户分层的过程，所需要用到的辅助数据；
- 基于智能运营的标签建设，运营策略、活动、方案的数据需求收集，哪些标签需要用到埋点中的信息；
- 基于营销系统的标签建设，涉及到渠道分配、广告投放、点击预测等，可能需要对曝光、点击、转化进行全链路的埋点建设，或者基于某一个产品使用链路，埋点数据要完备；
基于推荐系统、预留字段
- 推荐算法中需要用到的数据特征中包含哪些数据指标，其中埋点的部分所需要的数据格式是怎样的；
- 推荐算法的设计方案包括，基于用户、基于物品、协同过滤、基于规则、基于融合模型，不同的方案下、对数据底层的要求可能也会有一定的差异；
数仓落表问题
数仓建模设计
- 埋点数据落到数仓后，需要预先建立哪些表，如何做埋点数据的分层；
数仓库表的开发成本
- 埋点的数据体量是非常大的，TB级数据的存储本身就是一个比较大的成本，再加上调度系统、计算资源、运行性能等方面，就需要数仓团队在一开始就要把数据模型提前建立好，做好ods层到dw层、ads层的划分，维度和事实之间的建设；
数仓性能问题
- 因为埋点数据的体量问题，落表的时候、一定会存在大量的冗余字段，如果集群资源比较紧张，对于常规数据的统计、计算都会带来性能上的问题；
查询响应时效问题
- 在数据团队的架构中，有对外提供数据应用服务，对于数据的实时计算就有一定的要求，什么场景下应该是T+1，什么场景下应该是伪实时，避免数据调度任务影响前台应用产出；
