数据产品之数据埋点
前端埋点：业务初期、产品功能简单，需求分析与后端没有交互的前端行为
后端埋点：各行业特殊业务需求的数据，优先后端埋点、追求精细化运营，需多维度分析，数据安全要求高，
代码埋点：手写代码，调用埋点SDK函数，在需要埋点的业务逻辑功能位置调用接口上报埋点数据。
优点：自定义属性、自定义事件控制发送的时机和发送的方式
可视化埋点
核心代码和配置、资源分开，通过部署在产品上的基础代码对产品的所有交互元素进行解析，并在可视化页面对埋点区域和事件进行设定。从而在用户操作时，对用户的操作行为进行记录。
优点：简单方便快速、无需版本更新、节省人力和更新的成本、新增埋点在所有版本生效，不纯正迭代问题
缺点：受限制、上报行为信息有限、不能自定义交互事件属性、不支持可以不断加载的内容瀑布流交互
无埋点
通过SDK，前端自动全量采集全部事件并上报埋点数据当用户触发任何事件时，会自动上报数据
优点：无需埋点、解决数据回溯更优，适合做页面点击热力图、技术门槛低、部署简单
缺点：自定义属性不灵活、传输时效性差、数据形式非业务导向、增加服务器负载、兼容性不佳、数据存储空间大
如何选择埋点方式
代码埋点：对埋点事件进行传参等自定义属性设置（较复杂但功能最完善，覆盖了埋点中的不同业务需求）
可视化埋点：分析或统计需求简单，无需对埋点事件进行传参等自定义属性设置（频繁上线或更新的H5类型的运营活动）
无埋点：分析或统计需求简单，无需对埋点事件进行传参等自定义属性设置（针对快速，频繁上线和迭代的H5类型的运营活动的评估）
设计前端代码埋点
设计埋点事件的原则
同属性的多个事件要命名为一个埋点事件ID，
并以key-Value的形式区分
不同属性的多个事件应该命名为多个埋点事件ID，
此时也尽量不用key-Value的形式埋点
Key-Value形式的埋点设计规划
key一般表示某个事件
Value代表相对应的值
一个key可以对应一个Value或多个Value
key-value形式
事件ID
| 活动A | |||
| 页面来源 | 活动B | ||
| 。。。 | |||
| 事件ID | 酒店人口按钮 | ||
| 元素类型 | 旅游入口按钮 | ||
| 。。。 |
| 功能 | 用户行为 | 事件类型 | key | value | 描述 | 备注 |
| 统计酒店和旅游两个按钮的点击事件 | 在不同页面点击酒店和旅游按钮 | click | page | activityA | 进A一次 | 通过Page、source和事件类型的值来查询数据 例如查询点击酒店按钮 进入页面a可通过page=activityAand source=HotelButton按ActionTypeclick来查询数据 |
| activityB | 进B一次 | |||||
| source | HoteButton | 点击酒店一次 | ||||
| TravelButton | 点击旅游一次 |
维护成本低、简单高效、加value参数即可
减少沟通成本
扩展性好
曝光事件？记录页面被用户浏览的次数、是埋点时记录页面浏览最常用的事件
上报机制？用户进入页面记录一次，刷新时记录上报一次
| key | value | 字段含义 |
| action-type | openpage | 打开页面 |
| page-name | hotel-mainpage | 页面名称 |
点击事件：
用户点击页面某个对象触发的事件，通常用于评估页面对象的使用情况
上报机制：当用户点击一次页面上的某个对象，都会记录一次数据
| key | value | 字段含义 |
| actiontype | click | 点击事件 |
| entitytypr | BUtton | 点击对象类型 |
| entiyname | hitelbutton | 点击对象名称 |
| pagename | appmainpage | 点击对象所在页面 |
页面停留时长
主要用来记录用户在某页面停留的时间，用来评估用户对页面或功能的粘性
计算规则：通过记录用户进入页面时间t1和离开页面时间t2计算
| key | value | 字段含义 |
| action-type | leave-page | 离开页面 |
| page-name | monthcard-renewal | 页面名称 |
误区
数据价值
1、过于简单的设计
2、全用无埋点
3、单一埋点方式
埋点设计模块--事件模型
完整描述和记录用户的每一次行为
who：用户和设备的身份特征
when ：事件发送时间和上报时间
where：事件发生的地方
how：事件发送的状态
what：事件标识和参数
埋点采集流程分析
梳理业务-确定需求-设计事件-数据采集-构建指标体系-数据分析