产品运营中Oneid的实现，如何合理标识用户的唯一性？

　　编辑导语：产品运营的基础是埋点，这一过程中要对用户进行唯一性标识。为何要对用户进行标识？什么是用户标识？如何合理标识用户的唯一性？带着这些疑问，我们来看看作者的回答。

　　“平生不修善果，只爱杀人放火。忽地顿开金绳，这里扯断玉锁。钱塘江上潮信来，今日方知我是我”，这是鲁智深生前在杭州六合寺对自己的人生总结和一生的感悟。

　　仿佛在此之前的鲁智深处于一种非常混沌的状态，不清楚自己是谁，像隐匿了自己身份的一个人。直至到了六合寺听到钱塘江上潮信的瞬间，顿时参透人生真谛，把之前所有的事情关联起来，找到了最真实的自己。

　　那么，鲁智深的事情与本文要提及的产品运营中Oneid的实现有什么关系呢？

　　我们都知道产品运营的基础是埋点，埋点中对用户进行唯一性标识犹如鲁智深在听到钱塘潮信悟透自己的平生一样，即在某种场景下触发匿名身份的用户和真实身份用户之间的关联，进而把两种状态下用户行为归集为一个用户，完成用户的唯一性标识。

　　用户唯一标识，是用户唯一的身份ID，相同的身份ID，就会被当做是相同的一个用户。在进行埋点数据采集方案设计时，如何对用户唯一性进行标识对数据准确性影响较大。

　　即如何区分某个用户是此用户，而非彼用户是至关重要的，因为如果做不到对用户的唯一性进行识别，那么凡是涉及到用户的数据将都是不准确的，比如：累计用户量、新增用户量、活跃用户量。

　　因此，选取合适的用户标识对于提高用户行为分析的准确性显得尤为重要，尤其是诸如漏斗、留存、分群等用户相关的分析。

　　在互联网高速发展的今天，我们都在积极主动的融入这个世界，信息在高速流转，不再像以前那样闭塞。

　　各类互联网产品也在以一种前所未有的开放态度拥抱其用户，用户在触达一款应用时，可以在匿名(非登录)状态下使用应用中的大部分功能，此时用户的匿名ID一般是指设备ID。

　　在支付、充值、积分等一些关键的业务环节，应用会要求用户以某种方式进行登录。目前比较常见的登录方式主要是手机号，金融、政务、医疗、教育相关的应用除手机号以外，还支持身份证号、卡号等登录方式，我们称之为登录ID，下图是我们中原银行手机银行登录界面示例。

　　目前常见的需要做用户唯一性标识进而提升数据准确性的场景大致如下：

　　比如：用户A在移动设备X上使用中原银行手机银行浏览并购买了我行的中原如意宝这款年化高、可自主选择投资期限、比较符合自己投资意愿的理财产品，购买过程包含匿名访问、登录等操作。

　　一周后，用户A在另外一个移动设备Y上登录我行的手机银行查看了其购买的理财的收益情况。若不对用户进行唯一性标识，埋点数据上报的用户量是2个，而实际应该是1个用户。

　　在进行埋点方案设计时，为了对用户唯一性进行标识，需要在方案中写明如何采集用户匿名状态下的ID(设备ID)及登录状态下的登录ID，这里分别以first_id、second_id命名，后续文中涉及到的first_id、second_id均指匿名ID、登录ID。

　　基于采集到的与用户相关的first_id与second_id，在行为分析系统后台通过一定的关联规则，生成一个能够唯一标识用户的user_id，在以后的分析过程中，与用户量有关的指标均以user_id为基础进行统计分析。

　　匿名ID即设备ID，在不同类型的客户端上有所不同，且同一类型的客户端上，设备ID也并非是唯一的。例如 Web 端的 Cookies 有可能被各种安全卫士清空，而 iOS 端的 IDFV 在不同厂商的 App 间是不同的。

　　1）Android端

　　安卓系统经过多次升级，对权限控制越来越严格，唯一识别手机的方法也在不断发生变化。

　　Android端适合作为设备ID标识符的有OAID、Android_id、UUID、IMEI，IMEI是最适合做设备唯一标识的，但获取IMEI需要授予权限且Android 10以后不再开放IMEI的权限，App 卸载重装 UUID会发生变化。

　　综合起来，Android端比较适合作为标识符的是Android_id，如果 Android_Id 获取不到，则获取随机的UUID。

　　2）iOS端

　　苹果系统，可用于识别唯一设备的标识不像Andriod那样多。综合起来，苹果系统生成设备ID的标识符先后顺序应该是IDFA -> IDFV ->UDID，即优先获取IDFA，获取不到再获取IDFV，获取不到时，再获取UUID。

　　3）JavaScript

　　默认情况下使用 cookie_id，存贮在浏览器的cookie中。

　　4）微信小程序

　　一般使用UUID，但是删除小程序，UUID 会变。为了保证设备 ID 不变，建议获取并使用 openid。

　　如果选择使用 openid 的话，请注意操作暂存，由于获取 openid 是一个异步的操作，但是冷启动事件等会先发生，所以我们会把先发生的操作，暂存起来，等获取到 openid 后才会发送数据。

　　在介绍用户标识的实现方法前，先带大家了解一下，当前行为数据分析系统数据储存的模型。

　　目前主流的数据储存模型是用一张events表存储与用户相关的事件，其中event表中有个distinct_id字段，在事件发生时用户如处于匿名状态，则记录设备ID，登录状态下记录登录ID，用users表用来储存用户的匿名ID(设备ID)、登录ID、基于关联规则生成的user_id等用户属性。

　　这样通过events表和users表，就可以成功的把用户与事件联系在一起。

　　适用场景：适合没有用户注册体系，或者极少数用户会进行多设备登录的产品，如工具类产品、搜索引擎、部分电商等。

　　场景举例：

　　行为序列说明：

　　某用户在华为手机上新安装了 App，并进行了一系列操作，events表中distinct_id为设备ID,记为X，分配得到的user_id为1，同时把1、X分别存入users表中的user_id、first_id中。

　　该用户进行了注册并登录，设备未变，发送的 distinct_id 仍为 X，user_id仍为1。

　　该用户登录之后继续进行一系列操作，发送的 distinct_id 仍 为 X，user_id仍为1。

　　该用户把手机送给朋友了，朋友用自己的账号登录设备 X，发送的distinct_id 仍为 X，user_id仍为1。

　　该用户的朋友一直使用自己的账号在设备 X 上进行了一系列操作，由于设备未变，所以user_id仍为1。

　　该用户更换了新的小米手机，进行一系列操作，此时设备ID 变为Y，发送的 distinct_id 为 Y，分配的user_id为 2，则将user_id 2、设备ID Y 存入 users 表的 id, first_id 字段。该用户登录之后的后续操作，都会以user_id 2标识，只要不更换设备。

　　在上述场景中，仅使用设备 ID 识别用户的好处就是逻辑很简单，当然局限性也很明显：

　　当用户换手机后，用户换手机前后的行为无法关联上。

　　当用户把手机送给朋友后，朋友的行为却仍记在该用户下。

　　适用场景：成功关联设备 ID 和登录 ID 之后，用户在该设备 ID 上或该登录 ID 下的行为就会贯通，被认为是一个user_id发生的。在进行事件、漏斗、留存等用户相关分析时也会算作一个用户。所以一般来说，当遇到以下场景时，考虑一对一的关联：

　　需要贯通一个用户在一个设备上注册前后的行为。

　　需要贯通一个注册用户在不同设备上登录之后的行为。

　　场景举例：

　　行为序列说明：

　　某用户在小米手机上新安装了 App，并进行了一系列操作，对应的设备ID为 X，事件表中 distinct_id 为 X，对应分配的user_id为 1，则将user_id 1、设备ID X 存入 users 表的user_id,，first_id 字段。

　　该用户进行了注册并登录，其登录ID为A，事件表中 distinct_id 为A，设备ID X 和登录 ID A 关联成功，将登录ID A存入users 表的 second_id 字段，use_id仍为1。

　　该用户登录后继续进行一系列操作，事件表中distinct_id为 A，user_id仍为1。

　　该用户把手机送给朋友了，朋友用自己的账号登录设备 X，登录ID为B，将设备 ID X与登录ID B进行关联，由于 X 已与 A 关联，所以此次关联会失败，同时会分配一个新的user_id 2来标识此用户，并将登录ID B 同时存入users 表的 first_id 和 second_id 字段(用户的朋友账号上之前未关联过别的设备，且首次登录设备关联失败，则将登录 ID 同时记录到 first_id 上)，此时又称自关联。

　　之后，该用户的朋友一直使用账号B在设备 X 上进行了一系列操作，事件表中的 distinct_id为B，后续会用user_id 2来标识此用户。

　　该用户更换了一个新的苹果手机，并进行一系列操作，在未登录前，用新设备ID Y来标识用户，events表中的distinct_id 为Y，对应分配的user_id为3，将user_id 3 、设备ID Y 存入 users 表的 id, first_id字段。

　　该用户在苹果手机上使用账号A进行登录，此时将尝试将设备ID Y与登录ID A 进行关联，由于 A 已经与 X 关联，因此会关联失败，但是依然会切换到以A 为登录ID的用户，其对应的user_id为1。

　　该用户登录之后的后续操作，事件表中的distinct_id 为A，所以仍以user_id 1 标识。

　　在上述场景中，很大程度上已经实现了跨设备的用户贯通，但仍存在局限性：

　　当用户换手机后，虽然登录账号之后的行为与换手机之前的行为已经贯通，但是在新设备上首次登录之前的行为仍没法贯通，仍被识别为新的用户的行为。

　　当用户把旧手机送给朋友之后，由于旧手机已被关联到自己的登录ID，无法再与朋友的登录 ID 关联。后续使用这台旧手机的用户们，若不登录就操作应用，则都会被识别为同一个用户(旧手机成功关联的登录 ID)。

　　一对一虽然已经实现了跨设备的用户贯通，但是对于某些应用场景还是不够准确，因此产生了另外一种关联方案，支持一个登录 ID 绑定多个设备 ID 的方案，从而实现更准确的用户追踪。

　　适用场景：一个用户在多个设备上进行登录是一种比较常见的场景，比如 Web 端和 App 端可能都需要进行登录。支持一个登录 ID 下关联多设备 ID 之后，用户在多设备下的行为就会贯通，被认为是一个user_id发生的。

　　场景举例：

　　行为序列说明：

　　某用户在小米手机上新安装了 App，并进行了一系列操作，对应的设备ID为 X，事件表中 distinct_id 为 X，对应分配的user_id为 1，则将user_id 1、设备ID X 存入 users 表的user_id,，first_id 字段。

　　该用户进行了注册并登录，其登录ID为A，事件表中 distinct_id 为A，设备ID X 和登录 ID A 关联成功，将登录ID A存入users 表的 second_id 字段，use_id仍为1。

　　该用户登录后继续进行一系列操作，事件表中distinct_id为A，user_id仍为1。

　　该用户把手机送给朋友了，朋友用自己的账号登录设备 X，登录ID为B，将设备 ID X与登录ID B进行关联，由于 X 已与 A 关联，所以此次关联会失败，同时会分配一个新的user_id 2来标识此用户，并将登录ID B 同时存入users 表的 first_id 和 second_id 字段(用户的朋友账号上之前未关联过别的设备，且首次登录设备关联失败，则将登录 ID 同时记录到 first_id 上)，此时又称自关联。

　　之后，该用户的朋友一直使用账号B在设备 X 上进行了一系列操作，事件表中的 distinct_id为B，后续会用user_id 2来标识此用户。

　　该用户更换了一个新的苹果手机，并进行一系列操作，在未登录前，用新设备ID Y来标识用户，events表中的distinct_id 为Y，对应分配的user_id为3，将user_id 3 、设备ID Y 存入 users 表的 id, first_id字段。

　　该用户在苹果手机上使用账号A进行登录，此时将尝试将设备ID Y与登录ID A 进行关联，关联成功，其对应的user_id为依然1，同时将设备ID Y 添加到 users表中user_id 1 的 $device_id_list 字段。

　　该用户登录之后的后续操作，事件表中的distinct_id 为A，所以仍以user_id1 标识。

　　后续的修复如下：

　　由于设备 Y 被关联到登录 ID A 下，修复设备 Y 上登录之前的数据：user_id 3 -> user_id 1。

　　将users表中user_id 3的用户属性合并到user_id 1上，并删除 users 表user_id 3 这条数据。进行属性合并时，如果user_id 1的用户该属性有值，则不会修改该属性的值;如果user_id 1 的用户该属性没值，且user_id 3 的用户该属性有值，则将对应的值合并到user_id 1 的用户上，并删除 users 表中user_id 3 这条数据。

　　在上述场景中，真正实现了跨设备的用户贯通，通过修复解决了方案二中换手机登录之前的行为贯通问题，但仍存在局限性：

　　一个设备只能关联到一个登录 ID 下，当用户把旧手机送给朋友之后，由于旧手机已被关联到自己的登录 ID 了，无法再与朋友的登录 ID 关联。后续使用这台旧手机的用户们，若不登录就操作，则都会被识别为同一个用户(旧手机成功关联的登录 ID)。

　　而事实上，旧手机上后续的匿名登录很难识别到底是谁，可能归为匿名登录之前最近一次登录的用户会更合理一些。

　　综合起来看，以上三种对用户唯一性进行识别的方案没有对与错，在决定采取哪种识别方案时，结合产品的具体应用场景以及埋点复杂度来选择合适的方案即可。

　　作者：中原数据老工匠，一名金融科技从业者；微信公众号：数匠笔谈

　　本文由 @中原数据老工匠 原创发布于人人都是产品经理。未经许可，禁止转载

　　题图来自Unsplash，基于CC0协议

　　给作者打赏，鼓励TA抓紧创作！1人打赏