1. 前言
在了解常用匿名 ID 方案之前,需要先了解几个名词:
- Distinct ID:在神策分析中,使用该标识来标识用户;
- 匿名 ID:非登录状态下用户的标识,即非登录状态下用户的 Distinct ID;
- 注册/登录 ID:登录状态下用户的标识,即登录状态下用户的 Distinct ID;
而在微信小程序中,用来作为用户匿名 ID(即用户在非登录状态下的用户 ID) 的标识通常有 UUID、OpenID 或 UnionID。客户使用这几种不同的标识作为匿名 ID 会有不同的优缺点,下面就针对这三种标识作为匿名 ID 的优缺点做一下说明,方便客户根据自己对数据的要求作出选择。
2. UUID 作为匿名 ID
在默认情况下,按照文档集成了神策的微信小程序 SDK 后,触发事件时使用的匿名 ID 就是 UUID,该 UUID 是一串根据特定规则生成的具有唯一性的随机数。当项目中引入了微信小程序 SDK (即使不设置初始化参数以及调用 init() 接口),就会把这个 UUID 保存到微信的缓存即 stroage 中,当用户访问小程序时,会去判断微信缓存中是否存在该 UUID,存在就使用已有的 UUID,不存在,就会生成一个新的 UUID,如图2-1 所示。
使用该方案的优点:
- 集成微信小程序 SDK 后自动生成,简单,快捷;
- init() 接口的调用不需要依赖服务端返回的结果,只要网络没有问题,数据就可以网络实时发送出去,数据丢失率低;
使用该方案的缺点:
- 由于 UUID 是保存在 storage 中的,所以同一个用户,访问同一个小程序,UUID 为 123,删除 storage 后(如:从微信中删除小程序),再访问这个小程序, UUID 会变成 234。即同一个用户会由于删除 storage 的原因导致被标识成两个用户;
3. 使用 OpenID 作为匿名 ID
3.1. init() 接口放到成功回调函数中
使用 OpenID 作为匿名 ID,需要在调用 init() 接口之前,调用 setOpenid() 接口将匿名 ID 修改为 OpenID,如图 3-1
使用该方案的优点:
- 与微信那边的用户标识一致,便于数据 UV 比较;
- 匿名 ID 不会因为 storage 的删除而改变;
使用该方案的缺点:
- 处理逻辑较复杂;
- 由于获取 OpenID 需要通过网络从服务端获取,就会存在获取失败的情况。获取失败后,由于没有执行 init() 方法,用户触发的数据会被保存到内存中,当小程序生命周期结束后,这些数据就会丢失;
这个方案有这个缺点,那么是不是可以将 init() 方法调用同时也放到失败回调函数中或者完成回调函数中,下面就是关于放到完成回调函数中的介绍。
3.2. init() 接口放到完成回调函数中
使用 OpenID 作为匿名 ID,且 init() 接口放到完成回调函数中,流程如图 3-2
使用该方案的优点:
- 获取 OpenID 成功后与微信那边的用户标识一致,便于数据 UV 比较;
- 获取 OpenID 成功后匿名 ID 不会因为 storage 的删除而改变;
使用该方案的缺点:
- 处理逻辑较复杂;
- 由于获取 OpenID 需要通过网络从服务端获取,就会存在获取失败的情况。获取 OpenID 失败后,会去执行完成回调函数中的 init() 方法,此时,会使用 UUID 作为匿名 ID 来标识此后触发的数据;当用户再次进入小程序时,OpenID 获取成功后,就会使用 OpenID 作为匿名 ID 标识该用户,则同一个用户被标识成了两个用户;
4. 使用 UnionID 作为匿名 ID
4.1. init() 接口放到 UnionID 获取成功回调函数中
使用 UnionID 作为匿名 ID,需要在调用 init() 接口之前,调用 setOpenid() 接口将匿名 ID 修改为 UnionID,如图 4-1
使用该方案的优点:
- 获取 UnionID 成功后可以将同一个用户,同一个微信开放平台下的不同应用的行为打通;
- 获取 UnionID 成功后匿名 ID 不会因为 storage 的删除而改变;
使用该方案的缺点:
- 处理逻辑很复杂;
- 由于获取 UnionID 需要用户授权且需要通过网络获取到解密后的数据。用户不允许授权或者获取失败后,由于没有执行 init() 方法,用户触发的数据会被保存到内存中,当小程序生命周期结束后,这些数据就会丢失; ##4.2. init() 接口放到UnionID 获取完成回调函数中 使用 UnionID 作为匿名 ID,且 init() 接口放到获取 UnionID 完成回调函数中,流程如图 4-2
使用该方案的优点:
- 获取 UnionID 成功后可以将同一个用户,同一个微信开放平台下的不同应用的行为打通;
- 获取 UnionID 成功后匿名 ID 不会因为 storage 的删除而改变;
使用该方案的缺点:
- 处理逻辑很复杂;
- 由于获取 UnionID 需要用户授权且需要通过网络获取到解密后的数据。用户不允许授权,由于没有执行 init() 方法,用户触发的数据会被保存到内存中,当小程序生命周期结束后,这些数据就会丢失; 由于获取 UnionID 需要通过网络从服务端获取,就会存在获取失败的情况。获取 UnionID 失败后,会去执行完成回调函数中的 init() 方法,此时,会使用 UUID 作为匿名 ID 来标识此后触发的数据;当用户再次进入小程序时,UnionID 获取成功后,就会使用 UnionID 作为匿名 ID 标识该用户,则同一个用户被标识成了两个用户;
init() 接口作用: 在 init() 接口调用之前,采集的数据会被缓存在内存中;init() 接口调用后,数据通过网络直接发送出去;