聊聊“埋点”这件事
随着精细化运营等需求的诞生,埋点这一事物也应运而生。那么,埋点都有哪些应用场景?埋点主要采集哪些数据?这篇文章里,作者谈了谈他的看法,一起来看。
一、前言
互联网发展起始阶段,不关心流量,一切都处在野蛮生长的阶段。随着时代的进步,业务也在增长,网站流量开始增多,这时大家意识到这些数据中蕴含着大量的用户信息,加之用户需求越来越复杂,这时产品、运营人员就需要一些关键数据作为参考。
埋点应运而生。
二、应用场景
- 产品功能使用分析:对于产品来说,他们希望对比不同版本的数据,来评估当前产品改版的情况。
- 投放效果分析:对于投放人员而言,他们希望能够看到投放渠道的效果,以此评估改善投放策略。
- 个性化推荐:用户浏览、点击、互动、下单等行为是算法模型重要的特征输入。
- 其他广泛场景。
三、埋点主要采集哪些数据?
业内达成共识的就是4W1H数据模型,即who、when、where、what、how
- WHO:「用户属性」相关信息(用户id、手机号、设备id等)
- WHEN:时间相关信息(seeionid、客户端时间等)
- WHERE:「事件属性」相关信息(页面名称、按钮名称、按钮位置等)
- WHAT&HOW:「事件」相关信息(页面按钮点击、搜索点击、页面浏览等)
不同公司由于规模、业务属性不同,对于「事件」的定义可能存在出入
- 有些会完全抽象出来,如”页面按钮点击“”页面曝光“”页面浏览“
- 有些会将业务核心功能单独拎出来,如“支付””搜索“”关注“”分享”
- 有些会核心what&where组合,如“浏览主页”“浏览商品详情页”
对于如何定义「事件」没有一定之规,以精简易用为主,适合自身的就是最好的。
这里分享一个神策的思路:
WHAT:WHAT描述了一个事件具体是什么,这里就是神策事件设计模型的一个独特的地方。
在这里场景下,按照神策的事件设计规范,事件是“APP页面浏览”,而不是“首页的浏览”,通过增加『页面名称』这个属性来区分究竟浏览的是哪个具体的页面,大家可以思考下,为什么是这种设计思路呢?
实际上,一般一个产品会有N多个不同的页面,如果将每个页面都单独定义为一个事件,那么后台的事件将会有几百上千个,业务人员在使用时会非常的麻烦,筛选事件的成本也会非常大。
神策分析在做埋点需求设计时,针对所有类似的触发机制和场景的事件,都会做聚合处理,因此企业的事件量通常会维持在30-50个左右,配以神策的归类机制,极大方便企业进行事件管理,给业务人员带来极强的易用性。
四、埋点设计方案
可以参考火山引擎这一篇,非常详细https://www.volcengine.com/docs/6285/110093
五、埋点形式
偏技术向,直接贴图:
本文由 @起司Criss 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。
- 目前还没评论,等你发挥!