> 文档中心 > 数据产品经理必备技能之埋点

数据产品经理必备技能之埋点


一、埋点是什么

1.1 埋点的含义

主要描述用户在App内触发的一系列动作(比如:点击、侧滑等),事件采集主要通过应用内埋点来实现,因此也称为“埋点数据”。当页面加载和渲染完成之后,用户可以在页面上执行各类操作。通过采集用户的互动行为数据,以便通过量化获知用户的偏好或App优化点。

1.2 埋点的意义

埋点收集的用户相关数据,支持但不限于:

  • 产品方向:制作用户行为漏斗、指标等,优化产品功能设计、交互设计等。
  • 算法方向:支持推荐算法团队,合理分配流量,提高转化。
  • 开发侧:监控产品服务的稳定性,包含但不限于接口调用、页面加载等。
  • 数据分析:如业务拓展和业务优化,分析用户行为数据,探索发现业务蓝海,扩展业务。

1.3 埋点组成

埋点主要包含5个部分:事件名称(event) + 基础模块(header) +用户属性(user)+ 个性化模块(params)+其他参数

  • event:用户行为的类型
  • header:用户id/网络/设备号/型号/版本、GPS经纬度、事件发生时间
  • user:用户信息,例如用户ID、用户类型、用户使用的设备ID
  • params:通过个性化模块里面的参数能够查找到用户某个具体的行为
  • 其它参数:服务端下发参数,例如上报时间、会话ID、服务器更新时间戳
    上述组成部分,只有event和params部分需要数据产品单独设计,其他均为公共参数会自动上报。

1.4 埋点上报

不同类型的埋点,触发方式不同,也就是上报时机不同,具体详情如下表:

事件分类 描述 命名方式 举例 上报时机
曝光事件 页面中的组件像用户展现 名词_show house_show, element_show, feed_client_show 露出时上报
浏览事件 页面打开或跳转 动词_名词 go_detail, enter_category 目标页面加载时上报
点击事件 界面内容被点击 动词_名词 click_icon, click_options 点击时上报
停留事件 页面、列表或组件从可见转为不可见 动词_名词 stay_page, stay_category 离开页面时上报
其他事件 以上分类之外的事件 动词_名词 share_platform 上报事件不固定

备注: 首页banner_show为特殊事件,需要杀后台重启App才能触发该埋点,Tab间切换不能触发

1.5 埋点设计实例

  • 事件名称:card_show
  • 事件描述
    a. 埋点位置:卡片列表页
    b. 时间说明:卡片展现
    c. 触发时机:卡片露出时上报
  • 埋点类型:常规埋点
  • 模块:卡片列表页
  • 需求版本:V1.0
  • params:event_type、origin_from、enter_from、element_from、elemnt_type、page_type、group_id、rank
  • 是否必传:True
  • params类型:string、integer
  • params取值:{“house_app2b”:“终端名称”}、{“maintab”:“Tab名称”}、{“maintab”:“首页”}、{“be_null”:“无”}、{“be_null”:“无”}、{“company_house_list”:“卡片列表页”}

其中,红色高亮标记的参数:终端名称(event_type),入口参数(origin_from)、来源参数(enter_from、elemen_from)、定位参数(element_type、page_type),这六个参数是每个埋点事件中必须包含的;group_id和rank只有当场景需要时才需要添加。

二、埋点流程

在这里插入图片描述
备注: 数据产品处于产品流程中下游的位置,需求给到我们的时候,大概2~3d的时间给出文档。埋点整个流程的时间大致分为三部分, 了解需求和历史埋点40%,埋点设计30%,埋点验证30%。

三、埋点规范

  • 埋点设计的核心原则
    a. 原则1:能清楚定义且区别于其他用户行为;
    b. 原则2:优先靠齐历史埋点:能新增参数值的不增加参数,能增加参数的不增加事件;
  • 埋点文档输出规范
    a. 埋点文档要素包含以下模块、事件名称、事件描述(埋点位置、事件说明、触发时机)\埋点参数
  • 事件名称
    a. 事件名称是埋点对于用户行为的抽象化描述,事件名称的命名应该尽量收敛,使用以往用过的事件名称,不随便使用新的事件名称;详细参考事件矩阵表
  • 埋点位置:埋点上报的位置
    a. house_show事件,一般是当前页面上报上报埋点,相反,go_detail是在跳转后的页面进行上报
  • 触发时机:埋点上报时间点
    a. go_detail事件,在跳转页面以后,页面加载出来时刻进行上报,不在列表页点击时上报。
  • 埋点参数(params)
    a. 格式要按照上传ET的标准设计(需要持续去推进),后续需要上传ET关联roket
    b. 新增参数必须写清楚参数含义
    c. 新增参数枚举值,需要维护和记录枚举值的含义
    d. page_type: 详情页以_detail结尾,列表页以_list
    e. 对于log_pb内容,需要放入log_pb里面

四、埋点bad case

  • 产品与流程问题
    a. 产品文档流程图不直观,细节不完善,DA需要单独去了解产品细节问题
    b. 产品需求变动信息不同步,导致有返工现象
    c. 测试包分支多,部分测试需要加环境,或需要配置实验,或需要特定的账号,这些情况需要DA单独和测试沟通,测试包多,导致反复装机/卸载;(一个B端的076需求,安卓+iOS的8个测试包)
    d. iOS和安卓出现版本不统一问题
  • 埋点规范问题:埋点上报逻辑混乱
    a. 页面/按钮名称不统一,在不同的场景下,上报的名称不同;
    b. 上报逻辑不正确,如enter _from有的上报上级页面,有的上报的是上一个页面;
    c. 上报时机不清楚
  • 事件名称/参数属性命名不统一
    a. 事件名称不统一,同样的点击事件,有的使用click_icon, click_share, click_like等;
    b. 参数值命名不规范,没有对于详情页或者列表页的名称命名规范
  • 信息缺失
    a. 埋点描述信息:事件描述不清楚,不详细,缺少触发时机的描述;
    b. params参数信息缺失:枚举值,新增枚举值缺少响应的注释,难以复用和理解
    c. 参数使用枚举值的,没有标记每个枚举值的含义
  • 核心埋点梳理
    a. 核心埋点目前没有维护比较完善的一套
    总结: 沟通成本是埋点整个过程中消耗大部分的时间和精力;埋点不规范问题,会降低一部分的工作效率。

QQ头像吧