- A+
本文目录
访客的唯一性的辨识
不同的设备终端数识别的人方式不同，基本原则都是通过尽量通过各种唯一的ID去作为人的唯一标识，具体如下表：
| 终端 | 识别方式 | 主流方式 |
| Web | IP、MAC地址、Cookie | Cookie |
| Wap/H5 | IP、MAC地址、Cookie、浏览器指纹 | Cookie |
| IOS端 | IMEI、UDID、UUID、OPEN-UDID 、MAC、IDFV、IDFA | IDFA |
| Android端 | IMEI、MAC、ADID、DEVICE_ID，ADDROID_ID…… | IMEI |
| OTT | 基于IOS或Android，声纹 | IDFA/IMEI |
（1） Web
Web是网络最早的终端，早期的识别是基于有什么，能获取到什么？
IP的全称是Internet Protocol，中文名为互联网协议地址，是分配给用户上网使用的网际协议 的设备的数字标签。常见的IP地址分为IPv4与IPv6两大类。IP的唯一性使得曾被作为用户的唯一标识，但由于后来网络环境的复杂，使得IP唯一标识的特征被弱化，如同一家公司的是一个IP出口访问互联网，但是很多人在使用；动态IP和IP偏移使得IP识别用户的准确度大大下降，另外，各国政府立法将IP作为PII信息使得整个信息变得很敏感。
MAC网卡信息，其实是一串字符号，每个网卡厂家自己编码上去的，MAC网卡地址虽然看似唯一，但实际上并不唯一，MAC协议只是保证本地唯一，而全局不唯一，就像你的中国身份证是1000，美国也有个身份证是1000，但是明显你们是两个不同的人，所以MAC不适合作为唯一标识。
Cookie，Cookie是能够让网站服务器可以从客户端存储或读取少量数据的一种技术，一般以小文件的形式存储，可以实现个人信息的记录，是的web的访问是连续性的，简单的就是原有的互联网是无状态的，你访问A页面后访问B页面，服务器是不知道是同一个人，但有了Cookie就知道了。
所以Cookie是最适合作为用户识别，但目前也面临各种问题，如浏览器隐私状态访问，ITP规则的升级，欧洲GDPR的实施……对现有的以Cookie作为用户标识的跟踪体系造成了巨大的挑战。
现在常提高的精准营销就是将用户打通，识别到同一个人，但不同站点在不同的平台生成的cookie是不同的，PC端就需要做cookie mapping。
（2）Wap
WAP除了具备WEB的识别方式，还多一种识别方式，那就是浏览器指纹，浏览器中有多个特征信息，将这些信息综合分析计算后，可对客户端进行唯一性识别，进而锁定、追踪。
浏览器指纹分为普通指纹、高级指纹、硬件指纹和综合指纹。
基本指纹是指浏览器具有的特征标识，如浏览器中的插件，字体，UA头文件，位置设置，时区设置，防追踪选项是否打开，是否开启了广告拦截等可以标识用户的信息，这些我们称之为基本指纹。
高级指纹是指通过H5的高级技术来实现的，利用硬件和软件的差异生成不同的哈希值作为标识，如Canvas和AudioContext。Canvas的原理是相同的HTML5 Canvas元素绘制操作，在不同操作系统、不同浏览器上，产生的图片内容不完全相同，也就是基于各种因素生成一个唯一的对应的hash值，这个就是用户标识，你可以访问https://browserleaks.com/canvas 去看看自己的标识。
硬件指纹就是获取硬件的一些信息作为用户特征，如CPU，GPU，摄像头，GPS……逻辑类似基本指纹，但硬件的重复率较高。
综合指纹就是综合应用前面的几种指纹技术去匹配或生成唯一的标识符，降低重复率。
目前Canvas是使用最多的，很多网站在使用的，但是由于影响指纹的参数有很多，所以稍微有一点差异会导致hash值不同，另一个就是目前有些浏览器已经关注到Canvas隐私保护问题，已经屏蔽了Canvas，使用的时候需要用户授权。
所以目前并不能替代Cookie，可以和Cookie结合使用，如果用户屏蔽了Cookie，那么用Canvas指纹。
（3）IOS端
IOS是一个封闭的生态环境，你能用什么ID去作为唯一标识符取决于苹果开放了什么。
IMEI，全称是International Mobile Equipment Identity，中文名为国际移动设备识别码，即通常所说的手机序列号、手机“串号”，用于在移动电话网络中识别每一部独立的手机等移动通信设备，相当于移动电话的身份证。早期的苹果是可以通过IMEI作为用户标识的，但是在IOS5以后就不是了，曾经发生过有手机厂商将整批手机都是用同一个IMEI的的情况，现在已经获取不到了。
UDID,全称Unique Device Identifier的缩写,中文意思是设备唯一标识，它由40个字符的字母和数字组成。非唯一，可修改，于2013年5月禁用。
UUID，全称是Universally Unique Identifier,中文意思是通用唯一识别码. UUID的目的,是让分布式系统中的所有元素,都能有唯一的辨识资讯,但是在用户重装或升级的时候UUID会不一样。
Open-UDID，设备的识别码,每台iOS设备的Open-UDID是通过第一个带有Open-UDID SDK包的App生成，不同APP之前可以通过剪贴板复制黏贴传递。
MAC，硬件标识符，包括WiFi mac地址和蓝牙mac地址。iOS 7 之后被禁止，13年9月份iOS7的发布，苹果又采取别的措施，获取到的Mac地址在iOS7上都是相同的值，并且对剪贴板进行限制，同时禁止的还有Open-UDID。
IDFV，全称Identifier For Vendor，中文名为应用开发商标识符，根据vendor的值，如果vendor相同，则返回同一字符串；如果vendor不同，则返回不同的字符串。Vender是指应用提供商，就是开发者。适用于对内分析用户在应用内的行为等。
IDFA，全称Identifier For Advertising，iOS独有的广告标识符。在iOS 6 时面世，可以监控广告效果，同时保证用户设备不被APP追踪的折中方案。这个值不是唯一确定的！也就是说用户可以根据自己的意愿来还原或者禁止获取这个值。如系统重置、在设置里还原广告标识符； 用户可以在设置里打开“限制广告跟踪”。
目前IOS的用户识别是基于IDFA。
（4）Android端
Android的由于限制没有IOS的严格，所以各种ID都可以用，但是各个手机厂家做了深度的定制和优化，又有各种限制的存在，导致的麻烦不比IOS的少。
除了IMEI和MAC是跟IOS一样的原理，Android还提供有DEVICE_ID，ANDROID_ID,ADID。
DEVICE_ID，Android系统为开发者提供的用于标识手机设备的串号，非手机设备不适用。
ANDROID_ID在设备首次启动时，系统会随机生成一个64位的数字，并把这个数字以16进制字符串的形式保存下来，这个16进制的字符串就是ANDROID_ID。不同的设备，ANDROID_ID可能会相同；重置会导致ANDROID_ID不同。
ADID，谷歌对标苹果的IDFA的一个东西，但是需要结合Google的其他产品来使用，由于大陆地区使用不了，所以获取不到这个ID，这个ID对大陆地区的废的。
综上，Android主要使用的识别ID是IMEI。
（5）OTT
OTT全称是Over The Top，是指基于开放互联网的视频服务，终端可以是电视机、电脑、机顶盒、PAD、智能手机等等，现阶段主要的就是电视了，OTT设备都有系统的，所以它能用什么识别取决于使用的系统。
另外，由于OTT设备上比较兴起的是语音交互，有些厂家就引申出声纹识别，通过用户的声音去识别，原理就是前面的高级指纹类似。
访客行为追踪的原理
目前追踪消费者行为的主要是通过页面标签技术，页面标签技术是一种从访客浏览器端收集数据的技术，通常是通过放置在网站中每个页面的javascript代码进行收集的。有些网站分析供应商也会添加一些特定的标签收集额外的信息，这是一种基于客户端的数据收集技术，被主机托管供应商广泛应用。
目前采用这种技术方式的有Google Analytics、Adobe Analytics、Piwik、百度统计……基本上需要在页面部署一段跟踪代码的都是采用这种形式。
Google Analytics通过在网页中嵌入一段GA的JS代码，然后这段GA的JS代码会收集相关信息通过1像素的gif图片来发送相关的信息给Google的服务器，以完成数据统计。
一般来说，Google Analytics（分析）跟踪代码 (GATC/ga.js) 会在以下情况下提取网页数据：
1.浏览器请求的网页包含跟踪代码。
2.创建了一个名为 _gaq 的 JavaScript 数组，且跟踪命令被推送至该数组。
3.创建并启用了一个 <script> 元素，以便进行异步载入（在后台载入）。
4.获取了 ga.js 跟踪代码，且自动检测到了适当的协议。获取并载入代码之后，执行了针对 _gaq 数组的命令，且该数组被传输至跟踪对象。后续跟踪调用直接针对 Google Analytics（分析）进行。
5.向 DOM 加载脚本元素。
6.在跟踪代码收集数据之后，GIF 请求被发送至 Google Analytics（分析）数据库，以便进行记录和后处理。
在Chrome打开任意部署了GA的站点，按F12，打开调试窗口，选择Network后按F5刷新，在找出向google发送数据的URL，如下图，URL后面的一大堆参数就是向谷歌服务器发送的数据，形式是1像素gif的形式。旧版版本的还可以在url上看到“_utf.gif”,新版的走MP（测量协议）格式协议，url上没有gif字段，有collect字段
网站、H5用户行为追踪
网站用户的所有行为都可以通过事件跟踪，“事件”是指用户与内容进行的互动，可以独立于网页或屏幕的加载而进行衡量。下载、移动广告点击、小工具、Flash 元素、AJAX 嵌入式元素以及视频播放都是可以作为事件进行衡量的操作。一句话就是，用户在站点的所有行为都可以通过事件跟踪实现。
实现跟踪实现的如：
ga('send', 'event', [eventCategory], [eventAction], [eventLabel], [eventValue], [fieldsObject]);
完整的例子就是，那个位置的点击，就将这个加到哪里去。
ga('send', 'event', 'Videos', 'play', 'Fall Campaign');
在某些情况下，您可能需要将某个事件作为非互动事件发送。为此，请将 send 命令的 fieldsObject 中的 nonInteraction 字段设为 true：
ga('send', 'event', 'Videos', 'play', 'Fall Campaign', {
nonInteraction: true
});
如果没有设置，那么这个事件跟踪将会纳入跳出率的计算，导致跳出率偏低。一般来说，播放视频，暂停，信息提交这些需要设置成交互类型的。
APP用户行为追踪与事件监测（埋点）
（1）什么是埋点？
埋点就是定点，定时的数据采集，跟踪用户行为，给后续的产品优化和用户运营提供数据支持，也叫事件跟踪。
更通俗一点就是，你为采集数据所做的部署就是埋点，如用户的点击，屏幕的浏览，这些都需要预先做一些部署，这些部署通常是实现，什么时候触发，什么时候发送什么数据，这样才能采集到这些数据，这些部署工作就是埋点。
（2）埋点的分类
根据部署的位置可以分为客户端埋点和服务端埋点，而客户端埋点可以根据埋点工具的方式划分，可以分为三种类型：代码埋点，可视化埋点和全埋点，现在市面上三种实现方式的工具都有，并没有说哪一种方式能够碾压其他几种，因为都各有弊端。
1、代码埋点
这是是目前最为人所知的一种类型，也是使用最广泛的，包括Google Analyitcs，友盟在内的一些第三方工具都是使用这个方案。
原理是：部署完基础的SDK后，在需要采集数据地方添加跟踪代码，APP启动的时候会初始化SDK，你点击或触发数据采集位置的时候就会调用SDK对应的数据接口把数据发送出去，例如，我们要对某个位置的点击做埋点，也就是该按钮被点击的，这个按钮对应的OnClick就会调用SDK提供的数据接口去发送数据。通常来说，为了避免消耗用户的流量，一般是多条数据压缩后发送，而不是一条就发一次。
优点：
准确度高：可以精准控制触发条件，什么时候才触发，准确统计某一事件；
自定义强：可以自定义很多丰富的数据数据传递到服务端；
缺点：
工作量大：需要跟踪的地方都添加对应的跟踪代码，需要埋点，因此工作量会比较大；
有人说，用这个方案，版本更新的代码大，容易造成混乱，我认为是不存在这样的问题，我用这个方案几年的，版本更迭根本不用对旧版本的埋点做重新部署的，只有说，放弃旧版本框架，完全重写一个APP的时候需要重新部署，当然，新增页面或需求的时候，会需要添加新的埋点，这个的工作量并不算大的，如果你内部有一个比较好的反馈机制，这个很快的。
另有人说，这个有性能影响，使用第三方SDK，肯定会消耗内存，带宽，这是避免不了的，至于说传递数据，现在大部分的第三方都不是实时发送的，都是累计压缩数据后，等网络比较好的时候才发送数据的；最后一个是，现在的手机，处理能力可能都不亚于一些旧的台式电脑的，如果说影响性能，那你的APP得有多大或你现有的架构有多复杂。
至于数据传输的不可靠，只要涉及到网络，都可能会有网络延迟或丢包出现的，是通病来的，也有很多解决方案，加锁，重发，回调。
2、可视化埋点：
就是开发者无需再对追踪点进行埋码，而是脱离代码，只需面对应用界面圈圈点点即可追加随时生效的事件数据点。将核心代码与资源配置分开，当APP启动的时候从服务端更新配置和资源，APP根据新的配置和资源上报数据，整个结构有点类似GTM的，配置都是在GTM，用户每次打开加载到的是最新的GTM配置，那么GTM上部署的触发条件有可能被触发，从而实现数据收集。
原理：web和APP的页面都有类似的结构，在部署完SDK后，SDK会自动获取页面各个层级的关系，在web是dom结构，在APP是UIVIEWs，当你用可视化页面设置埋点的时候，服务器能够自动知道元素的位置，并且将这些配置保存到服务器，用户打开的时候，就会加载这些配置到客户端，当用户触发该元素的位置时候，就会将相关数据发送出去。
优点：
部署简单，能大大节省人力成本；
对于不同代码的产品和运营，可以通过可视化界面进行配置；
缺点：
不灵活，不能自定义获取数据属性,部分可视化的位置可能覆盖不全;
每次启动加载服务端最新的配置资源，浪费流量。
3、全埋点：
也叫无埋点，就像字面说说的，不需要埋点，已经尽可能的收集所有控件的数据，最早是在2013年，由Heap提出的。
原理：SDK利用CSS选择器技术和监听控件的事件触发技术，在APP中嵌入SDK，这个SDK就会将APP中尽可能多的操作都采集下来，可以通过可视化操作界面对采集的数据做分类,基本上是先收集，后筛选的节奏，可能会出现数据噪音的情况。
优点：
部署简单，只需部署SDK，初始化几行代码，就会自动收集数据；
自动收集很多数据，能够回溯；
缺点：
不灵活自定义数据属性；
收集的数据多，给网络传输带来压力，消耗用户的流量和电量，部分会涉及隐私问题。
可视化埋点和埋点的是很类似的，只是它们对信息的采集和处理流程不一样而已，可视化埋点是，采集的才处理，而无埋点是先采集所有的，才选择性处理，无埋点采集的是尽可能多的数据，所以无埋点能够对数据做回溯，但是这也意味浪费流量，浪费电，坑用户。
4、服务端埋点
在后端将数通过协议的形式直接发送数去，如MP协议，日志等，最常用的还是日志，如日志做很多个性化的定制实现数据的采集，这个工作量就大了。
前面的客户端埋单都是使用第三方工具，服务端埋点，可以理解为，自己开发一个类似的工具架构了。
（3）埋点的原则
简单：埋点的方法简单，能够快速上线的，如果一个工具埋点都折腾个几个月，这不坑爹的嘛。
免费：大部分人在做工具选型的时候会着重考虑这个工具是否付费的，都想要免费的工具，现在市面上可视化埋点和无埋点的都是付费的，如果预算允许，可以考虑用可视化和无埋点的产品，但请选择大型厂家的产品。
准确：收集到的数据是准确的，才有参考价值，如果收集到的数据跟后其他其他数据有很大的误差，根本不可信的，再花哨的埋点功能也是没用的，目前准确度高的还是代码埋点的形式。
小程序行为追踪
小程序是这两年才兴起的，目前主要跟踪的方案有使用MP协议、使用GA拓展SDK和使用其他第三方工具。
(1)MP协议
MP协议的全称是Measurement Protocol,是Google Analytics专门用于传输线下数据的一种方式，小程序可以通过这种方式去跟踪，Google Analytics的数据都是通过Collect形式去发送的，需要将发送的数据组成成Collect的形式即可，在这个过程之中需要注意，cid和gid一定不能为空，cid就是client id要自己去生成。
(2)GA拓展SDK
这个是开源的，已经有人将MP协议写成包的形式了，方便部署，具体的地址可以看https://github.com/rchunping/wxapp-google-analytics
(3)其他第三方工具
目前市面上也有多种针对小程序的统计工具，各家更迭产品的速度还是比较快的，不断增加一些新的功能。
选择完第三方工具后，小程序的跟踪都是通过事件跟踪去实现的。如果使用的Google Analytics，那直接可以通过MP协议实现。
