关于作者：小姬，某知名互联网公司产品专家，对数据采集、生产、加工有所了解，期望多和大家交流数据知识，以数据作为提出好问题的基础，挖掘商业价值。
历史资料导读
历史加菜内容
0x00 前言
站在巨人的肩上
Standing on Shoulders of Giants
去年，美团出版了一本《美团机器学习实践》的书籍，虽然人气不如《大数据之路：阿里巴巴大数据实践》，我记得书中有这么一句话“数据和特征决定了机器学习算法的上限，而模型和算法只是不断的逼近这个上限而已”。
这句意味深长的话值得咀嚼，大家可以从中悟出不同的思考，但是毋庸置疑，值得肯定的是数据的重要性不言而喻。在我研究的数据领域，我习惯将数据归纳为两大类：
流量数据，以用户访问产品，记录用户浏览行为核心的埋点数据日志；
业务数据，以生产系统内存储的业务表单数据为核心的业务库数据记录；
简单一点，用户访问产品时候的交互“动作”触发的是埋点数据流量数据，用户访问产品看到的内容是业务数据。我们“点击广告”是“动作”事件，能够生产一条埋点数据，我们看的广告内容是“商品”信息，商品信息是被存储的业务数据。
我们学习数据埋点知识，就是为了设计“记录”用户“动作”的方案，记录用户“动作”发生的场景，探索用户“动作”背后的意图。
0x01 案例1
数据埋点的形式多种多样，但数据埋点的原理都是相同的。很多时候我们在观察和分析一个埋点的时候，首先要了解这个埋点信息是采用的什么数据埋点方案，不然我们会因为信息不足导致无法判断，如下我们开门见山的先看一个埋点案例数据：
数据埋点模块示意图：
数据埋点形式和参数说明：
[{
//Part1：配置信息
"user_id":"123", //埋点负责人的账号id
"business":"xx业务", //埋点数据的业务分类
"label":"标签属性"，//对埋点数据进行分类，对每个分类打标签
//Part2：环境信息
"uid":"123", //用户唯一ID，只要访问就生成一个新的身份标示
"user_id":"123", //用户的账户ID，仅登录用户可获取得到
"name":"joker",//用户的账户名称，仅登录用户可获取得到
"city_id":"2",//如果用户访问的页面有城市属性，这里可以获取页面的城市属性id
"city_name":"上海",//如果用户访问的页面有城市属性，这里可以获取页面的城市属性值
"locate_city_id":"1",//用户访问时候所定位的城市id
"locate_city_name":"北京"，//用户访问时候所定位的城市属性值
"wifi":"on",//用户访问时候wifi的开关状态
"app_version":"10.9.2",//用户当前使用的app版本
"os_version":"11.8.2", //用户当前手机系统的版本
"os_souce":"android" //用户当前的手机系统（Android，iPhone，小程序、web…）
//Part3：事件信息
"evs":[{
"id":"a1234"//坑位模块的全app唯一标示id
"val_val":{ //以下所有数据为同时携带的想要获取的数据内容
"user_id":"123", //访问用户的账号id；
"content_id":"123234", //商品唯一id标示
"title":"conklab连帽潮牌oversize情侣装",//商品标题；
"price":"298",//商品价格；
"business_id":"4",//商品分类属性id
"business":"女装",//商品分类属性
"strategy":"abc123",//不同策略的策略id，用于区分不同策略的数据效果
"shop_id":"123",//商品所属的店铺id
"mark":"双十一",//个性化的数据标签，比如双十一代表此商品正在参加双十一活动
"position":"2",//商品在列表中展示排序的第几个位置
}
}]
}]
数据触发时间上报策略说明：
1.露出上报采用实际展示曝光上报策略，只有当事件本身实际曝光显示在屏幕当中才需要触发上报策略进行数据上报（露出像素>0px）；
滑动：在页面内上下滑动时，不重复记录；
刷新：刷新当前页面时，重复记录曝光；
翻页：下拉到新一页后再返回到前一页，上下滑动不重复记录
返回：事件点击到落地页后，从落地页返回（包括返回按钮返回、滑动返回、支付等行为后自动跳转返回），不重复记录录曝光；
唤醒：a) 手机锁屏被打开，直接展示事件所在的页面，不重复记录曝光；b) 应用或者浏览器在后台被唤醒，展示广告所在的页面，不重复记录曝光；
2.没有特殊限制定义，埋点需要根据坑位颗粒端逐条上报，不做去重处理；
备注：
1.数据埋点中的“点击事件”在触发“点击”动作的时候上报埋点数据，触发条件很明显，不容易有歧义，所以很少单独强调。
2.其他类似的滑动、编辑、订单键、加载触发条件，因为不是主流触发条件，我们在后续课程中单独介绍。
0x02 案例2
假设我们有网址：https://www.xxxabc.com/about/1.html（运营促销活动），我们针对这个活动在某网站投放广告引流，最有效的数据埋点方法是对URL添加埋点参数如下：
例如：运营促销活动的URL添加参数如下：
https://www.xxxabc.com/about/1.html?source=sina_joker_ad_about_01
参数说明：
?：问号后面是我们的埋点参数，以问号分割的作用是不影响正常的访问链接
source：埋点字段的命名，source表示参数的名字，source后面是参数的值
sina：表示来源的渠道，如果是sohu，那么这里是搜狐即可
joker：表示来源渠道的负责人
ad：表示为广告类型，这里以ad表示一类广告
about：表示对应的是此次about这个活动
01：如果我们对这个资源位做了很多不同的广告图片素材，我们可以对素材编号为01，02……
0x03 案例3
storymark://业务场景标示，可以对应到不同的业务类型场景
“key1:”value"//页面跳转的时候传递的参数，采用key：value的形式写入参数值
“key2:”value"//保留尽可能多的keyxid，写入更多参数值
“key3:”value" //保留尽可能多的keyxid，写入更多参数值
……
数据触发上报说明：
我们希望统计浏览小视频的来源入口，比如通过首页的“搜索”还是“关注”进来的。我们需要在做如下2件事情。
1.当用户通过“搜索”进行内容筛选查找小视频的时候，在触发搜索任务的时候上报如下埋点数据。
storymark://业务场景标示，可以对应到不同的业务类型场景
“index:”search" //key（index）定义为是首页，value（search）标示是来自搜索功能
“content:”美女" //key（conten）定义的是携带的内容参数，value（美女）标示内容参数
2.当用户向下访问的时候，尤其是在到达“浏览小视频”目标页的时候，触发上报埋点参数。
同样原理类推如果想统计通过“关注”到达浏览小视频的目标页，埋点数据如下：
storymark://业务场景标示，可以对应到不同的业务类型场景
“index:”guanzhu" //key（index）定义为是首页，value（guanzhu）标示是来自guanzhu功能
“content:”guanzhu" //key（conten）定义的是携带的内容参数，value（guanzhu）标示内容参数
备注：
1.“关注”的埋点参数“content:”guanzhu" ，vlaue可以为空（“content:”“ ）
2.这种埋点有很严格和复杂的”抹除“逻辑，需要有很强的层级概念，比如用户通过”搜索“进入结果页但是未能再进一步，选择返回首页通过”关注“最终到达”浏览小视频“目标页，那么”搜索”相关的参数需要在“回退”的时候抹除，写出最新的“关注”埋点参数。
0x04 解读
案例1：常用的站内数据埋点方式，适用于各种平台WEB、APP、小程序；
案例2：常用的站外，站内数埋点方式，多用于WEB、小程序平台；
案例3：数据埋点中的一种透传方案，主要用于统计站内的来源入口，适用于WEB、APP、小程序。
关于案例1
在案例1中我们很容易总结出数据埋点的数据分为三个重要组成部分：
数据埋点的业务配置信息
用户访问环境信息
数据埋点动作信息（事件信息）
用户访问我们的产品的时候，触发单个“动作”事件信息的时候，我们会记录用户的所在城市、客户端，APP版本，埋点ID，以及很多其他的参数。
通过长期的总结和经验及常识分析，我们会发现用户在一次会话访问中城市不会发生改变，只需获取一次即可，不必每次“动作”时间的出发重复的获取用户的地理位置计算一个所属城市。
因此我们优化一下数据的获取方式，将城市作为环境信息在一次会话中仅获取一次，后在加工处理数据的时候将一次会话内的所有“动作”事件信息补全它所属的城市场景。
同样道理类推，我们会发现不仅城市拥有这个规律和常识，用户的wifi，APP版本，登录账号，手机系统，手机品牌的等等属性都是类似的，所以，我们将其统一归为环境数据信息，在一次会话中仅收集获取一次（特殊的业务场景除外，比如定位信息可能主动、被动的多次触发）。
和环境信息比较类似的是业务信息，我们在通过工具或者各种记事本管理数据埋点的时候，我们对埋点的业务定义已经明确，比如埋点数据的事件id，我们很清楚的知道它是谁负责的，中文名称是什么，所以我们在用户访问产品，触发埋点的时候完全可以选择不上报这部分数据，从而减少数据上报量。等我们将埋点数据收集采集到数据库的时候，同我们已知的明确的定义信息进行一次关联即可。
关于案例2
案例2本身通俗易懂，重点就是在于将参数安排在URL中，通过收集访问的URL日志来解析我们希望获取的埋点信息。
案例2可以延伸出很多种不同的数据埋点方式，以上述埋点的参数为例，我们也可以将其在进行一次整合优化。
比如：
运营促销活动的URL添加参数如下：
https://www.xxxabc.com/about/1.html?source=sina_joker_ad_about_01
修改为：
运营促销活动的URL添加参数如下：
https://www.xxxabc.com/about/1.html?source=abc123
备注：abc123=sina_joker_ad_about_01的含义可以维护在工具或者其他地方，这样就避免了URL过长，参数过多的数据现象。
关于案例3
案例3我在前面已经举例，这里在和大家针对一个数据问题埋个伏笔：
统计 x 页面的来源，统计 x 页面的分类 ，统计用户的访问路径。这是不同的数据概念模型，且依赖的数据埋点方案会存在差异。
0x05 作业
学习方式
1.发现日常使用产品（WEB、APP）的数据埋点现象，并总结记录下来；
2.梳理自己目前困惑的数据埋点问题和看到的埋点知识点，并总结记录下来；
备注：一分耕耘一分收获，大家努力。
推荐资料
1.神策分析使用手册：https://www.sensorsdata.cn/manual/
2.友盟_文档中心：https://developer.umeng.com/docs
3.书籍《SQL必知必会》//会SQL的绕过忽略
作业内容
1.每人将“学习方式”中的总结记录，尽可能的描述详细，然后发布在网上（任意发布平台，总之可以能打开分享，让小姬看到并检查作业）
2.评论回复作业，格式为：群昵称：作业地址
格式示例：小姬：https://www.xxxabc.com/about/1.html?source=abc123
备注：打卡截止日期为 2019-11-29 逾期不打卡连续3周不交作业，视为自动放弃需要退群，小姬在学习小组结束之后，也无法在给你分享数据埋点知识库。
广告时间
支持大家在作业中分享这篇文章的地址，也希望大家帮我多宣传，不强求。
0x06 FAQ
1.我看到有些URL中添加了埋点参数，为什么有的网站没有呢，是以为他们没有埋点吗？
小姬：并不是所有的埋点都体现在URL中，可以在触发条件之后，直接将参数发送至后台服务器，详细的内容，小姬会额外的“加菜”带大家学习。
2.我为什么看不懂他们的埋点参数都是什么意思？
小姬：埋点的参数很多时候都是字符串，它的含义在各自的数据埋点工具中维护。比如“案例2”这种常见的数据埋点方案，我不解释每个字段的含义，大家也看不懂。
3.我现在看不懂案例中的数据埋点方案，怎么办？
小姬：没关系，今天才是第1课，如果坚持下来还看不懂，是小姬的不对，小姬额外“加菜”。
4.埋点的类型是什么，怎么定义划分的？
小姬：多数场合中我们说的埋点类型指的是触发条件，比如点击触发为点击类型，曝光触发为曝光类型。在这个基础上有些触发时间比较特殊，比如用户点击“提交订单”按钮，会形成订单数据，我们可以将之称为“订单事件”。由此推荐埋点的类型指的是“事件类型”，大致要考虑触发动作和特殊的业务场景。
5.怎么评价一个埋点方案的好坏？
小姬：这个需求经验，在我们做埋点的时候会发现数据埋点的问题特别多。久而久之我们会通过埋点积累下解决经验，当我们再次看到一种埋点方案的时候，就可以根据经验判断利弊了。同时我们也就有了创造埋点方案的能力。
网友评论