有赞埋点实践.docxVIP

有赞埋点实践 利用扫瞄器或APP自带的监听方式，对用户的扫瞄页面、点击等行为进行收集，可以收集到的信息次要有： 页面的url、APP的包名等 点击元素的xpath路径、title或商定的dom元素 无痕埋点的优势有： 前端接入成本低，不需要额外开发 用户动作收集完整，不会漏失 但同时也会存在以下问题： 有用、没用的数据都会收集 无法采集到特殊的行为动作、业务参数 采集到的信息需要进行二次标注，才可以被用户识别 当按钮的位置不固定、名称存在反复或页面重构时，无法做到精确?????的标识 无痕埋点在有赞一般用来做粗粒度的快速业务探究。 3.2 代码埋点 代码埋点是指依靠前端同学，自定义监听和收集处理。代码埋点的优势有： 大事标识明确 业务参数丰富 大事的触发方式可以机警自定义 分析更便利、精确 随之而来的是以下问题： 前端代码的开发、管理成本 只能收集到大事上线之后的数据 在业务需求简单，无痕埋点收集到的信息无法支持分析时，就需要进行代码埋点。 四、埋点sdk 为简化前端同学的埋点开发工作，使其只需要关注于业务本身，并对埋点的一些商定进行必要的约束，有赞开发了多个端（js/小程序/android/ios/java）的埋点sdk。 sdk默认支持以下功能： 访客标识管理 会话管理 环境参数默认收集 参数的生命周期管理 默认大事的收集 跨端的sdk通信（如app嵌套h5页面） 内部业务的特殊处理规律 日志的格式化、合并、生命周期管理 日志的上报机制 前端同学通过sdk供应的接口进行开发，只需要关注： SDK的初始化配置 大事怎样标识 大事需要哪些参数 大事如何触发 五、日志两头层 数据收集上来后，原始日志还处于格外精简的形态，需要进一步加工成日志两头层，次要有以下几个环节： 批量上报的日志拆分 日志模型的格式化处理 信息的二次加工和维度扩展?如IP、http_agent的解析等 特别流量的清洗 会话信息的补充?如落地页、二跳页、停留时长的计算 按业务拆分日志流和日志表 实时流两头层是以JSON格式存储在kafka中，并且供应对应的JavaBean类，便利实时任务开发解析处理，并且也可以与streamSql相结合使用。 离线两头层是存储在同一个表中，字段与实时流格式保持全都，以日期和业务作为分区条件，并会自动创建全部业务的视图表，便利两头层的统一调整以及数仓的权限管理。 到这个阶段，有了通用的日志模型和sdk，埋点工作可以标准化的开展起来。但随着承接的业务越来越多，更多的问题在等待着我们。 六、位置追踪规范 在精细化运营及算法推举等应用场景下，需要格外精确把握行为发生的位置场所。假如每个业务都自定义一套标识方式，那么每次分析工作都需要重新开发，无法复用规律，这将极大的铺张开发资源，因而需要制定出统一的位置规范。 我们将位置分成了四个粒度： 业务 页面域（包括页面类型和页面id） 组件域（如图中红色部分，包括组件类型和组件序号） 展位域（如图中绿色部分，包括展位标识和展位序号） 业务 + 页面域 + 组件域 + 展位域 + 页面随机码，可以独一确定一个访问的位置。基于位置分解出来的维度组合，可以很便利的分析出各个粒度的访问、曝光、点击数据。 类似的还有算法追踪规范，在此不作开放。 七、埋点管理平台 有赞的晚期阶段，全部业务的埋点方案都是记录在wiki中。随着业务线和项目的快速添加，wiki记录的弊端也渐渐暴显露来： 登记格式无法统一，关键信息简约缺失 大事查找不便，分析同学不晓得已有哪些大事 迭代更新大事无法合并，同时存在多份信息 开发进度、测试进度无法监控 埋点质量问题无法快速对接 基于开发中遇到的各类问题，愈发的让我们意识到平台建设的必要性，次要涉及以下几点力量： 埋点元数据的管理及开放力量 埋点流程的管理力量 当有了埋点元数据，可以延长出来更多的操作空间，如： 埋点的自动测试 埋点的自助分析 埋点的开发提示 埋点的质量监控 7.1 埋点元数据管理 依据大事模型及位置追踪规范，我们将元数据的组成分为 业务、 页面、 组件、 展位、 大事 业务：由业务类型（微商城、零售等）和SDK类型（js/小程序/android/ios/java）独一确定。页面、组件、展位、大事等属于且仅属于一个业务。 页面：具有相同页面结构的一类网页或者移动端页面。 组件：页面内的区块，也包括跨页面的可复用区块。 展位：组件内最细粒度的坑位，有三种位置标识，即递增（挨次陈列）、固定（特定的位置）和正则标识（简单规划）。 大事：埋点基本单元，对应用户的一个动作，比如进入页面、点击按钮、商品曝光等，每个大事还可以定义独有的参数。按其归属，可以分为全局大事、页面大事和组件大事。 7.2?项目流程管理 当一个新项目启动时，会有对应的一批埋点需求，为了便利PM管理与追踪进度