埋点的方案选型

一般是推荐全埋点+代码埋点的组合使用可以cover大部分的场景。

考虑角度

发展阶段

首先需要考虑公司产品所在的当前阶段以及迭代的节奏，进而确定开发投入成本。

业务属性

是交互应用类，还是业务交易类的

分析深度

需求确认关于分析的深度。

案例分析

电商业务

从发展阶段看

产品导入期

在产品导入期的时候，可以使用代码埋点，基于核心功能流程埋点，确定重点点位，只需要满足基础的分析需求即可，无需引入SDK。

快速迭代器

可以引入SDK，产品交互使用分析以全埋点为主，可以快速响应产品迭代；

成熟稳定器

全埋点+代码埋点。

对于强业务属性的使用代码埋点，前端行为分析使用全埋点，满足深度分析需求

埋点规范如何统一

规范越早统一，后期的分析成本将会越低。

管理角度/制度

从制度上确定了意识之后，才能够推行下去。

自上而下的统一意识

需要让高层知道数据统一的重要性

工作流程

一般是数据产品来负责埋点的设计。

业务团队提出需求 -- 数据团队负责设计 -- 开发进行开发 -- QA团队测试 -- 数据团队校验 -- 业务验收。

QA偏单点的测试，最终的数据质量校验还是交由数据团队来负责。

明确职责

业务团队

明确需求 功能验收

数据团队 【核心】

指定埋点规范

设计埋点模型

需求审核与定义

埋点统计验证

埋点质量监控

业务开发

埋点实施 遵循规则 埋点自测

QA团队

触发时机测试 埋点规则核对 单点统计测试

确定埋点需求内容

需要按照规范提供需求文档，这样大家对于埋点的上下文理解更加统一。

基于目标确定

例如业务想知道，哪个功能使用人数最多，那么点击数据是核心； 业务想知道用户怎样使用产品，那么路径行为数据是核心； 业务想知道用户有什么样的特征，复合数据则是核心。

埋点数据的构成/数据模型

who where what 谁在什么时间点做了什么事情 例如，会员A使用设备iPhone在北京市点击了X页面下的Y按钮。

事件模型

主流的数据埋点产品基本上都是使用event模型。

即用户模型+事件模型 从逻辑上看，可以看作为一个用户表和一个事件表。

事件表

事件表的核心是事件字段和事件属性。

事件名称	用户id	时间	事件属性X (点击高度)	事件属性Y(url)	事件属性(来源渠道)
webclick	lisi	2022-12-12 00:09:12	456	/path/to/url	小红📕

用户表

用户id	用户内部系统id	手机号	首次登录时间
webclick	lisi	lisi_0001	2022-12-12 00:09:12