一、现状
为了完善安全机制、保护用户隐私，各个设备厂商开发了 MAC 地址随机功能，防止用户信息泄露。随机 MAC 地址，就是一个随机生成的伪 MAC 地址，一个假 MAC 地址，使用随机 MAC 地址进行网络通信，而不是真实 MAC 地址。
二、随机MAC带来的影响和问题
- 设备线索冗余，查看某账号下的设备，当前以mac为粒度展示数量膨胀
- 设备轨迹漂移，当前以mac为粒度的轨迹信息，可能是多设备贡献的
- 虚实转换关联到多人，无法准确定位背后实人
- 虚到虚的设备扩线失效
三、中期方案
建立随机mac识别公共服务层，所有涉及mac的下游应用及模型的调用先检查一次
业务结果上的目标，随机mac的落位准确率
业务指标评估成果
将正常mac、随机mac、不可用mac分为白灰黑三类。
- 白mac：目前的数据服务主力军，占大头
- imei和mac合法
- 1个mac关联不超过2个imei
- 如果有2个imei，则这两个imei的品牌一致（双卡双待机型）
- 1个imei只关联到一个mac
- 灰mac：随机mac，核心是识别随机mac
- 单imei有2个及以上的mac（已实现）
- 实人 + 设备nick粒度关联2个及以上的mac（已实现，可升级为账号 + 设备nick粒度）
- mac在短时间内有长距离移动（模型评估中）
- 黑mac：串码、刷机修改、设备克隆、不合法
四、长期方案，探索中（N码转换）
扩充四码，加入新的设备标识符号，如IDFA（苹果专属）、OAID（国内厂商联合）、SSAID（谷歌框架）
基本上IDFA、OAID比较靠谱
对OAID的支持
| 厂商 | 版本 |
|---|---|
| 小米 | MIUI10.2 及以上 |
| vivo | FuntouchOS 9 及以上 |
| 华为 | 全版本 |
| OPPO | Color OS 7.0 及以上 |
| Lenovo | ZUI 11.4 及以上 |
| 华硕 | Android Q |
| 场景 | imei | mac | utdid | oaid | 数据变化规律 |
| 双卡双待主卡切换 | 可能会变 | 不变 | 不变 | 不变 | 只会影响imei变化 |
| wifi网络切换（MAC变化） | 不变 | 可能会变 | 不变 | 不变 | wifi切换只会影响mac地址变化 |
| 一键换机场景 | 可能会变 | 可能会变 | 可能会变 | 可能会变 | 首次启动不变，后续启动可能会变，卸载一定会变 |
| 应用卸载重装 | 不变 | 不变 | 不变 | 不变 |
五、要做的事
- 提升随机mac识别率
- 基于mac位置漂移，新增一批随机mac
- 建立与机型品牌的关联关系
- 引入更多数据，关联到机型和设备
- 新的账号设备粒度的位置域数据，
- 引入新的码值，如IDFA、OAID这类广告ID，建立六码关系
二、新方向-概率推荐
如果我们不做随机mac的区分，每一个mac进来，我们都为他做概率推荐。无非是0-100%的问题。比如一个正常mac，那它的信息就是干净的，我们理解为100%推荐此条信息。
最先想到的就是跟mac关联性很强的imei和账号。
仍然回到我们最初设定的问题来分情况讨论。
2.1 IMEI的情况
在一个mac能够关联到过个imei的情况下，计算各个imei对该mac的数据贡献度。或者换句话理解，就是关系程度。这里我定义为活跃度。
很自然能够联想到某imei与该mac出现关系的时间越接近当下，出现的频次越高，他们的关系越紧密，活跃度越高。
所以这里有两个概念：关系的新鲜和关系的稳定，简称为 新和常。但到底是新重要还是常重要，这里根据我们的倾向和需求可以有多种处理方式。
所以我们要定义一个公式，来描述活跃度与 新和常 两个因子之间的关系，并且需要分配权重。
这里抛砖引玉，丢个公式：
这里n为统计周期，可以取180天。这里Wi为新鲜度权重，越接近当下，权重越大，代表 新 这个影响因子；同时，出现的天数越多，求和项也越多，代表 常 这个因子。当然，这里权当举个例子，具体活跃度分值的计算等 模型 大佬再研究下。
2.1.1 轨迹不完整问题
- 如果只能关联到一个imei。则输出这个imei的全部轨迹，完毕
- 关联到多个imei，根据活跃度推荐前3个imei，提醒下游应用大概率是这几个设备，分别输出展示
2.1.2 轨迹碰撞问题
- 同上的第二条，推荐活跃度前3的imei的信息，分别输出展示
2.1.3 设备线索过多问题
- 同上
2.2 账号的情况
其实随机mac场景下，imei有很大一部分是取不到的。 Android 10 带来的影响总结下来就两句话：mac越来越脏，imei越来越少。
我们不得不得考虑，没有合适的设备id的情况下，用什么来代替mac去输出信息。
实际上最适合串联各方数据的，就是账号了。
三个经典问题不再分别展示，参考imei的情况
三、设计方案
核心在于建立一张mac粒度的维表，用于描述活跃度前几的其他信息。
大概可能长这样：
| mac | imei_list | id_list | xx_list |
|---|---|---|---|
| mac1 | imei1:100,imie2:67,imei3:10 | id1:32,id2:11 | xx |
| mac2 | imei4:91,imei5:33 | id3:87 | yy |
| …… | …… | …… | …… |
所有以mac为入口的需求，都先走一次维表（可以做成数据服务，对外提供快速查询），按照mac+imei或者mac+id的形式提供给下游应用。而且可以按照要求的严密度限制活跃度分数，筛选出高活跃度的，排除掉低活跃度的。减少下游应用的查询复杂度和可靠性。
结构上比较简单，不再绘图。
四、终极方案？
做自己的ID-Mapping。
说白了，我们最大的痛点在于缺少一个唯一代表一台设备的设备id。
基于这么多码值之间的关联关系，我们利用ID-Mapping，将各种各样的设备级id，系统级id，应用级id等等等码值聚类。利用无向图的联通分量（最大连通图），将大部分正常设备ID聚簇在一起，形成一个自然设备ID簇。其簇的成员包含了各种类型的id。一个id簇，我们就认为是一台设备。
附录：各种各样的ID
