简单介绍数据采集中的数据埋点

0x00 前言

每个人都会走路跑步，但是并不是人人都能成为专业的运动员那么出色。产品经理就是一种这样的职业，我们都可以站在产品的角度思考问题，但我们并不是都能够成为一名出色的产品经理。

这个道理其实挺适合概况很多事情，比如对于埋点方案这个技能，原理很简单，人人都可以听得懂，但是根据我的经验和目前视野，负责埋点方案和埋点工作对个人的技能要求非常高。

0x01 简述

数据采集包含很多数据工作方式和内容采集方向，数据埋点是其中一个重要部分，一般的用户访问行为数据日志可以通过请求日志获得，但是更加健全的是通过埋点数据上报采集获得。

那么该如何设计数据埋点呢？下面将举几个场景的栗子来说明埋点该怎么设计。

示例一

场景：A页面每天有多少人访问，每个人访问多少次？

解析1：

该场景下的埋点大概是这样设计的。

用户每访问一个页面，都会向服务器后端发送一条请求日志。日志中会记录一下用户的终端设备信息，用户信息，以及当前页面的信息。例如记录了用户的访问时间、设备号、手机系统、访问页面的URL。我们就可以根据时间、设备号、用户id和URL三个字段计算每天有多少用户访问A页面（对访问A页面URL的用户id做去重加和），每个人访问了多少次（计算每个用户id访问A页面URL的次数），因为有用户的手机系统字段，我们还可以分系统看数据，每天有多少Android用户方案A页面，每天有多少iPhone用户访问A页面。

试想一下，如果我们记录更多数据，我们是不是就可以拆分更多维度看数据。我们可以看每天北京市有多少女性用户方案A页面，我们也可以看访问A页面的用户都使用什么样的手机设备。

解析2：

如果我们以埋点的方式采集数据，我们一般的做法是当用户访问页面A的时候，我们让前端向服务器后台发送一条消息，这个消息通常可以是一串字符串，比如：page123。这个时候我们再加上其他渠道记录访问数据信息，我们仍然可以得出很多数据结论。page123的作用这个时候的作用相当于页面的URL。

那用URL和用page123有什么差异呢？简单来讲，URL相对于网页对应的地址，不便于我们改写或者加入更多的规则逻辑。比如，在整个网站中有首页，列表，商品详情页，订单页，个人中心。现在只想看每天有多少人 访问过商品详情产生过购买意愿。这个时候如果你网站有上百上千万的页面URL，在统计的过程中就会很困难。如果采用的是埋点数上报，我们仅需要对埋点的参数规则做一个策略设定就可以了。当访问商品详情页的时候我们不上报page123这样的参数，我们上报成goods_page123，当上报订单页的时候，我们上报成order_page123。我们将网页的类型进行了归类，分别给出一个对应字段goods、order，将这个字段放入到埋点参数中组成一个新的字符串组合。最终我们得到数据之后，想查看某一类页面的数据之后就可以根据这个参数进行匹配筛选数据。

示例二

场景：如果我们知道A页面上的一个广告每天曝光了多少次，点击了多少次该怎么做？

解析1：

同理，我们也可以通过请求日志统计广告曝光量，点击量。因为当广告曝光在页面的时候是需要首先向后台发送请求加载广告数据的，而在用户点击广告的时候，同样会向后台发送请求。我们可以根据这个请求数据统计每个广告的数据。

解析2：

实际上目前市场没有任何广告网站的广告是依靠上面的方法统计数据的，因为请求日志统计的数据并非用户通常认可和理解的数据口径。当浏览器向后台发送请求，数据可能返回失败，也可能返回数据之后加载失败，渲染失败。又或者广告成功加载但是广告位置出现在需要滑动屏幕的地方，访问者并没有向下滑动页面真实“看见”广告内容。因此请求日志统计数据，显得不是很“精确”。

对广告进行数据埋点是解决上述问题的思考之一，我们可以给广告设定一个参数page123_ad_123，page123代表广告所在的页面，ad代表是广告内容，123是区分广告的广告id。我们可以要求当广告真实出现在屏幕当中的时候，前端向后台发送一条数据参数page123_ad_123，这样我们就可以统计一个页面有多少广告被访问者真实“看见”，每个广告曝光了多少次。

同理如果用户点击广告的时候，我们可以上报另一个已经设定好的参数：page123_ad_click_123，我们就可以统计每个广告被点击的次数了。

0xFF 总结

通过上面的示例，我们可以总结看到数据埋点的灵活和作用在于

1、可以支持更加丰富的数据规则，对数据进行归类。

2、可以灵活的决定数据上报条件，满足个性化需求。

本篇转载自 Joker 的文章《数据采集中的数据埋点简单介绍》，修改了格式和个别文章结构。