使用
定义某一个特定页面（首页）
如果想要定义一个首页，可以使用如下方法：
- 限制路径等于「/」，因为一般首页的页面路径即为「/」 定义某一个特定页面（首页）
如果想要定义一个首页，可以使用如下方法：
- 限制路径等于「/」，因为一般首页的页面路径即为「/」 定义某一个特定页面（基于路径定义的特定详情页）
如果想要的定义某一个特定的详情页，比如某一个特定商品的商品详情页，而这个商品详情页的 URL 规则和京东是类似的，可以采用如下定义方法：
- 限制页面路径，并且在页面路径中填写完整的页面路径地址 定义某一组页面
如果想要的定义一组特定的页面，比如说全部的商品的商品详情页的访问量，并且 URL 规则与京东类似，可以采取如下方法：
- 限制页面路径，但是选择包含关系，因为我们发现所有的商品详情页的路径，最尾部的数字不同，但是有一个共同的特征，就是包含「/product」这一信息，所以可以用这个方法来定义全部的商品详情页
认为当前控件绑定单击事件，可选择当前控件支持的事件类型
输入想绑定的功能点
点击保存或者可直接为当前功能点去添加属性。
定义某一个特定页面的按钮（比如商品详情页的购买键）
如果想要定义的就是当前这个特定页面的按钮，按照默认的页面匹配规则为当前页定义即可。
如果想要定义的按钮普遍存在于某一组特定页面，则需要先按照上文的方法点击定义页面匹配规则，然后在页面匹配规则栏中搜索选择已经被定义好的匹配规则。
定义元素点击事件的属性
可以在页面中选择元素内容定义为属性信息
首先，在创建元素点击事件页面中点击「添加属性」按钮，点击页面中的元素，并保存属性信息，保存后进行确认创建事件
部署
当决定去部署当前绑定的功能点后，需要点击部署按钮进行部署
如何来进行埋点选择呢
实施建议 分阶段实施：
第一阶段：启用自动上报，快速获得基础用户行为数据，数据上无法满足的使用数据自定义的方式补全（七月份改造完成） 第二阶段：等待自动上报数据充盈后，由数据部清洗数据，初始化一批埋点关系；可视化埋点上线后，查漏补缺，配置功能点绑定 第三阶段：针对特殊需求，补充手动上报 优先方案：如果默认数据已满足需求且无需功能点绑定，直接使用自动上报，无需额外工作
按需选择：根据具体需求选择最适合的方案，避免过度配置
渐进式实施：从简单方案开始，逐步扩展到复杂方案
功能点字典系统提供了可视化绑定埋点及验证等功能(目前仅支持Pc端Web应用)， 具体的功能列表如下： 1.定义页面和页面组，支持基于路径的页面组的设计 2.支持页面,控件和功能点的一对一绑定 3.支持自定义属性：可视化的方式选择页面元素内容定义为属性 4.支持验证已绑定的功能点 5.支持行为回溯
功能点字典可视化埋点适用场景 数据采集是基本、是源头。在数据采集的过程中，我们需要考虑如下问题： 1.前端埋点 VS. 后端日志 2.文本 VS. 格式化数据 3.批量 VS. 实时 4.文件落地 VS. 网络传输
在数据采集过程中，我们需要考虑的原则： 1.大：充分考虑用户规模与数据规模的增长，做好数据资产积累的准备 2.全：多端采集，针对全量用户行为而非抽样，贯穿用户使用产品的整个生命周期 3.细：尽可能采集足够全面的属性与维度，尽量保存数据细节，让积累的数据资产更加优质。例如，从 Who When Where How What 这 5 个角度来采集用户行为数据 4.时：在技术条件与成本允许的情况下，尽可能地提高数据采集的时效性，从而提高后续数据应用的时效性
代码埋点带来一些难题： 1.应用迭代更新时才能更新埋点 2.埋点较多时如何管理
结合当前功能点字典的系统支持度,推荐在以下不同的场景下应该选取合适的埋点方式：
场景 可视化埋点 代码埋点 分析页面的PV,滚动基础指标 √ 分析点击类控件的单击，双击，右键事件 √ 分析输入类控件的值改变，右键事件 √ 一条数据需分析多个控件包含的数据，如筛选时表单内所有控件的多个条件 √ 分析控件触发时该控件外的其他控件数据，如时间范围选取时输入结束日期时同时传开始日期 √ 分析控件触发时该控件外的系统状态数据，如下单时的商品库存 √(后端) 确定某个订单下单成功 √(后端) 精细化分析核心转化流程 √ 注意：系统目前推荐单一控件单一行为的单一功能点绑定,其他多对多场景暂不支持,也不推荐： 1.某一控件单个行为上报多个功能点 2.多个控件或多个行为上报同一个功能点
技术架构
主体考虑职责分离,为了将业务开发人员,产品,大数据人员的工作拆分,单一职责, 降低平台操作复杂度 最后拆分为标记插件,配置平台,圈选sdk,行为监控
- 整体是按照业务数据流向来考虑的
- 先有标记层,确保元素有唯一id 便于圈选,需要将id和埋点配置信息页面路径,映射匹配
- 之后基于此,为了能将需要埋点的页面,和配置平台,建立通信,策略执行,单独的圈选sdk处理
- 最后通过配置平台,管理埋点以及,由产品,进行无代码绑定埋点,将id埋点 ,绑定,入库
- 行为监控: 采集层拉取圈选服务根据已经绑定的埋点信息进行,校验,到达清洗层,统一格式,上报层统一去处理
标记层
本质是解决,圈选元素需要唯一稳定id问题. 早期调研的时候实际上 神策数据 采用的是Xpath ,边界在于,动态渲染的dom路径,及其不稳定,不采纳
之后考虑自动化场景,想到babel 通用的编译工具 我查询当前元素和父元素的jsx 属性,进行拼接,但是动态属性写法,多样,难以统一解析,并且在generator阶段: 会丢弃原始代码格式,行列号信息,造成代码无效的diff 改动,影响review成本
方案一版被业务方,拒绝
开始调用发现jscodeshift facebook出品,专注代码改造, 方案进行改进,不再采用jsx属性,采用全局随机唯一id 标注,持久化到代码中 并加入容错兜底层:从模块复用,区分,重复,cicd等解决 最后还沉淀到cli工具
圈选SDK
- 这里基于: 单一职责,为了更好的将埋点页面和配置平台,打通.
- 最后我拆分为 策略层,通信层,事件监听,样式
- 为了把圈选平台,各种配置状态,及执行逻辑,通过策略模式:封装
- 通信层: 为了将元素id属性,传送到平台侧,便于绑定
- 事件监听: 为了捕获到,产品点击的埋点元素
- 样式岑: 为了区分埋点,未埋点元素
埋点配置,圈选平台
埋点配置平台,核心解决,操作页面,点击元素,绑定埋点: 本质为id 元素 页面路径 埋点信息,建立映射关系,并入库,便于 监控时拉取服务,并进行采集上报
行为监控
首先整体行为监控sdk 被划分为采集层,清洗层,数据上报层 对于采集层:主体是采用插件模式,每个行为插件相互独立,更好的测试,以及解耦,并且方便,单独的异常捕获 采集层: 一个是一些核心插件逻辑的开发,如页面级别,元素级别,pv,单双击,路由监听 主体的开发思路: 通过watch 监听具体行为事件, 再统一进行数据格式的转换,适配圈选埋点,无痕,代码埋点格式 最后再到上报层
上报层这里:
扩展性问题
我们内部自研的ui库是高度适配的,但是个别业务线用的是第三方组件 典型场景,data-uc-id无法透传到内部,dom元素属性,造成最后无法绑定,进而无法采集上报行为数据
原始方案,采用人为修改,但是涉及较大工作量,侵入式
因此调研了,高阶函数,装饰器的思路 本质是,通过高阶函数,传入,修正,添加id的参数, 内部通过dom属性的修正, 并针对动态渲染场景,配合mutationObserver 动态修正id 卸载时解绑 最终方案被采纳,落地,大幅减少人为修改的工作量到5行
