1 问题

最近接触到一些埋点数据的处理，引发了一些思考。
目前主要的问题是: 埋点需求多，数据处理比较慢，数据需求及时性较低。

情况描述：比如上一个埋点需求，不同的开发，规则可能不一样(存储表设计、粒度等等)，于是在处理数据端又需要去了解不同的规则，这时候就要花费不少时间，而业务方又比较迫切需要数据的反馈。

可能存在的问题：埋点需求不够规范，埋点框架规则不够统一。

2 定义埋点

埋点需要埋什么，有哪些可以进行一些规范？
参考—如何定义埋点：https://zhuanlan.zhihu.com/p/272533190

2.1 描述一个埋点
image.png
命名：页面名称前缀+动作+类型后缀

2.2 优化
埋点事件属性组成： 公共属性 + 私有属性

好的埋点工具，会自带默认采集的属性，比如：设备型号，系统型号，地理位置,ip等

事件分类：点击事件、曝光事件、页面停留时长等。
优化方向还有埋点页面拆分、埋点抽象、埋点管理、文档等等。

3 埋点需求举例

需求文档如：
方案1：尽量简单些，满足大部分需求
image.png
或
image.png

方案2：参考神策埋点需求文档 — 数据采集需求文档.xlsx

内容丰富且能满足更复杂的埋点和全埋点需求，适合对接系统管理。

简版：模板_元事件与属性.xlsx

4 埋点技术方案

埋点技术分类：客户端(前端)埋点 和 服务端埋点
image.png
其中客户端可以分为 APP端和 Web端。

APP埋点跟web埋点的区别？
APP和WEb的埋点都是需要做部署，行为都是通过事件来跟踪，都有埋点跟踪和可视化跟踪。
不同点在于：

  • web是部署的js跟踪代码，浏览是页面
  • APP部署的SDK，浏览的是屏幕

一般埋点需要准确度高、自定义强，所以一般会采用借助第三方工具进行客户端埋点的方案。

使用比较广泛的第三方工具：
海外：Google Analytics
国内：神策，应用实践参考传送门

5 数据存储及处理

一般一个事件发生存储为一条记录，公共属性是相同的，但不同事件的私有属性的数量和字段通常是不一样的(灵活的)
一般第三方工具是以Json的形式存储，然后动态解析。
但如果以结构化的形式存储呢？ 如下:

  1. -- 法1： 一个表存储所有的事件(kv)，缺点是: 一条记录只有埋点的一个信息
  2. CREATE TABLE `events` (
  3.   `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'ID',
  4.   `user_id` int(11) NOT NULL DEFAULT '0' COMMENT '会员ID',
  5.   `group_name` varchar(64) NOT NULL COMMENT '事件分组',
  6.   `event_name` varchar(64) NOT NULL COMMENT '事件名称',
  7.   `page_name` varchar(64) DEFAULT '' COMMENT '页面',
  8.   `extra` varchar(255) DEFAULT '' COMMENT '额外信息',
  9.   `device` varchar(10) DEFAULT '1' COMMENT '设备 pc,android,ios,touch',
  10.   `device_id` varchar(64) DEFAULT '' COMMENT '设备ID',
  11.   `created_at` int(11) NOT NULL COMMENT '创建时间',
  12.   PRIMARY KEY (`id`),
  13.   KEY `events_group_event` (`group_name`,`event_name`)
  14. ) ENGINE=InnoDB AUTO_INCREMENT=1833734 DEFAULT CHARSET=latin1 COMMENT='事件埋点表';
  17. --法2： 一个表存发生的事件及公共属性, 另一个表存对应的私有属性
  18. CREATE TABLE `cfg_event` (
  19.   `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '自增ID',
  20.   `eventName` varchar(64) NOT NULL COMMENT '事件名称',
  21.   `showName` varchar(64) NOT NULL COMMENT '事件显示名称',
  22.   `group_name` varchar(64) NOT NULL COMMENT '事件分组',
  23.   `user_id` int(11) NOT NULL DEFAULT '0' COMMENT '会员ID',
  24.   -- 以及一些公共属性
  25.   `describe` varchar(256) DEFAULT NULL COMMENT '描述',
  26.   `status` tinyint(1) NOT NULL COMMENT '状态,1有效，0无效',
  27.   `created_at` datetime NOT NULL COMMENT '创建时间',
  28.   PRIMARY KEY (`id`),
  29.   UNIQUE KEY `UNIQUE_PRODUCTID_EVENTNAME` (`id`,`eventName`)
  30. ) ENGINE=InnoDB AUTO_INCREMENT=174 DEFAULT CHARSET=utf8;
  33. CREATE TABLE `cfg_event_attribute` (
  34.   `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'ID',
  35.   `eventId` int(11) NOT NULL COMMENT '事件ID',
  36.   `attributeName` varchar(64) NOT NULL COMMENT '属性名称',
  37.   `showName` varchar(64) NOT NULL COMMENT '显示名称',
  38.   `attributeValue` varchar(16) DEFAULT NULL COMMENT '属性值',
  39.   `unit` varchar(16) DEFAULT NULL COMMENT '单位',
  40.   `dictKey` varchar(64) DEFAULT NULL COMMENT '缓存KEY',
  41.   `status` tinyint(1) NOT NULL COMMENT '状态,1有效，0无效',
  42.   PRIMARY KEY (`id`),
  43.   UNIQUE KEY `UNIQUE_PRODUCT_EVENT_ATTR` (`attributeName`,`eventId`),
  44.   KEY `idx_evenid` (`eventId`)
  45. ) ENGINE=InnoDB AUTO_INCREMENT=1104 DEFAULT CHARSET=utf8;

6 Q&A

5.1 新老用户如何辨别
http://webdataanalysis.net/personal-view/web-user-identification/
GA 就是使用 Cookie 来定义新老用户的，即该 Cookie 之前出现过则该访客为老用户，否则为新用户。
这个定义适用于所有网站，但有它不准确的地方，Cookie 的删除、用户更换 PC 等都会造成数据上的偏差。
参考：神策标识用户方案说明