聊聊“埋点”这件事

起司Criss 2023-12-24 19:05:06

一、前言

互联网发展起始阶段，不关心流量，一切都处在野蛮生长的阶段。随着时代的进步，业务也在增长，网站流量开始增多，这时大家意识到这些数据中蕴含着大量的用户信息，加之用户需求越来越复杂，这时产品、运营人员就需要一些关键数据作为参考。

埋点应运而生。

二、应用场景

产品功能使用分析：对于产品来说，他们希望对比不同版本的数据，来评估当前产品改版的情况。
投放效果分析：对于投放人员而言，他们希望能够看到投放渠道的效果，以此评估改善投放策略。
个性化推荐：用户浏览、点击、互动、下单等行为是算法模型重要的特征输入。
其他广泛场景。

三、埋点主要采集哪些数据？

业内达成共识的就是4W1H数据模型，即who、when、where、what、how

WHO：「用户属性」相关信息（用户id、手机号、设备id等）
WHEN：时间相关信息（seeionid、客户端时间等）
WHERE：「事件属性」相关信息（页面名称、按钮名称、按钮位置等）
WHAT&HOW：「事件」相关信息（页面按钮点击、搜索点击、页面浏览等）

不同公司由于规模、业务属性不同，对于「事件」的定义可能存在出入

有些会完全抽象出来，如”页面按钮点击“”页面曝光“”页面浏览“
有些会将业务核心功能单独拎出来，如“支付””搜索“”关注“”分享”
有些会核心what&where组合，如“浏览主页”“浏览商品详情页”

对于如何定义「事件」没有一定之规，以精简易用为主，适合自身的就是最好的。

这里分享一个神策的思路：

WHAT：WHAT描述了一个事件具体是什么，这里就是神策事件设计模型的一个独特的地方。

在这里场景下，按照神策的事件设计规范，事件是“APP页面浏览”，而不是“首页的浏览”，通过增加『页面名称』这个属性来区分究竟浏览的是哪个具体的页面，大家可以思考下，为什么是这种设计思路呢？

实际上，一般一个产品会有N多个不同的页面，如果将每个页面都单独定义为一个事件，那么后台的事件将会有几百上千个，业务人员在使用时会非常的麻烦，筛选事件的成本也会非常大。

神策分析在做埋点需求设计时，针对所有类似的触发机制和场景的事件，都会做聚合处理，因此企业的事件量通常会维持在30-50个左右，配以神策的归类机制，极大方便企业进行事件管理，给业务人员带来极强的易用性。