江苏龙网

  1. 首页 > 人文 > >

陆小曼|数据产品经理：埋点的设计、管理与应用( 三 )


这里就涉及到指标管理与数据使用便捷性的权衡：如果不传 ， 在使用的时候免不了要跨表联查 ， 是比较影响使用效率的 。 在指标管理时常需要通过用空间换时间的方式 ， 来保证数据能比较高效使用 ， 最大化数据的价值 。
其他说明：变量值类型 ， 比较常见的有：int、float、boole、string、timestamp；埋点形式 ， 对于自己研发的数据采集系统 ， 一般前端埋点和服务端埋点可以了 ， 如果外采第三方数据采集服务 ， 可能还会有全埋点；埋点版本和日志 ， 则是帮助你和开发快速回忆这个点的前世今生 。
如果这篇文章你只记住一句话 ， 我希望是：好好记录指标备注及变更日志 。 这个工作能让你后面少踩太多坑了 。
以上 ， 综合下来 ， 以电商商详页举例 ， 一个埋点事件最后的字段如下：
陆小曼|数据产品经理：埋点的设计、管理与应用
文章图片
图5：举例-商品详情页事件指标设计
2.1.2埋点指标定义-用户表
用户表 ， 顾名思义是记录用户信息、用户属性的表 ， 通过用户的唯一标识（user_id）能够将事件表和用户表两张表进行关联 。 事件与用户实现关联 ， 事件表里一条条的数据记录 ， 就不会再是孤立的统计数字 ， 而是能够与具体的用户产生关联进行分析 ， 或者用行为来圈定用户 ， 给用户设定分群和标签 。
陆小曼|数据产品经理：埋点的设计、管理与应用
文章图片
图6：事件表和用户表的关联
用户表的自定义维度设计与业务关联度最高 ， 除了常规的用户id、用户昵称、注册时间、首次登陆APP时间等字段外 ， 其他偏业务属性字段需要一个比较全局的视角 ， 不仅要与数据运营方沟通 ， 而是要与公司每一个有分析诉求的部门进行沟通 ， 采集他们的数据分析诉求 ， 来提炼抽象出比较通用的用户表 。
如上面提到的 ， 如果只是从事件表里把上报的数据聚合成统计数字或者图标 ， 是没有很大意义的 ， 还要能够下钻进行分析 。 事件表中变量字段的设计是为了从事件反映的用户行为侧进行下钻 ， 而用户表的属性字段则是基于从产生行为的用户本身进行下钻 。
举简单一例：当日商品详情页的总浏览数据是上升的 ， 但是总GMV确没有明显提高 ， 从事件侧分析 ， 发现某类异业合作主推的单品商详页浏览数据上升 ， 其他品类商详页没有明确上升；从用户侧分析 ， 该类单品新增流量主要来自于渠道A 。
从此得出的初步判断是：1）单本对渠道A的用户拉新效果明显；2）但是该类用户被吸引来了 ， 却没有下单 ， 很奇怪 ， 需要确认投放落地页与站内商品信息是否一致 ， 尤其是价格；3）该类用户对平台其他商品的兴趣不高 。
说回用户表的属性字段设计 ， 回到那句核心：采集共性诉求 ， 提炼出通用、容易理解的用户表 。 这个工作其实并不难 ， 考验的是数据PM沟通、提炼真实诉求 ， 并整合成具体的需求的能力 。 以我司做内容服务的平台举例 ， 用户属性表如下 ， 基本覆盖了通用的用户群的分析：
陆小曼|数据产品经理：埋点的设计、管理与应用
文章图片
图7：用户表维度举例
2.1.3埋点指标定义-默认属性
除了前面提到的自定义事件和用户属性外 ， 一般客户端或者第三方数据采集SDK还会采集一些默认的属性信息 ， 这些可能不需要你单独去定义 ， 但数据PM需要去了解平台获取的默认字段有哪些 。
陆小曼|数据产品经理：埋点的设计、管理与应用
文章图片
陆小曼|数据产品经理：埋点的设计、管理与应用
文章图片
图8：默认采集字段（部分）
2.2通用埋点设计在自定义埋点设计中 ， 有一些通用的事件往往是比较复杂的 ， 而且随着业务发展 ， 会变得越来越复杂 。 比如 ， APP平台的分享事件 ， 如果按功能模块 ， 每个功能模块都设计了自己的分享事件 ， 则这个事件会越来越分散 ， 且想聚合做复合指标时 ， 如通过分享/日活来衡量内容质量 ， 分享事件要先聚合平台各功能模块的分享事件 ， 太分散会产生应用上的问题 。


推荐阅读


上一篇：烟草味道|麒麟1020成为“绝版”？任正非早有后手，华为旗舰采用联发科芯片

下一篇：草莓味的棉花糖|一年前我们就可以了，中兴7nm芯片量产？中兴老总