不得不面对的随机MAC问题

一、现状

为了完善安全机制、保护用户隐私，各个设备厂商开发了 MAC 地址随机功能，防止用户信息泄露。随机 MAC 地址，就是一个随机生成的伪 MAC 地址，一个假 MAC 地址，使用随机 MAC 地址进行网络通信，而不是真实 MAC 地址。

二、随机MAC带来的影响和问题

• 设备线索冗余，查看某账号下的设备，当前以mac为粒度展示数量膨胀
• 设备轨迹漂移，当前以mac为粒度的轨迹信息，可能是多设备贡献的
• 虚实转换关联到多人，无法准确定位背后实人
• 虚到虚的设备扩线失效

三、中期方案

建立随机mac识别公共服务层，所有涉及mac的下游应用及模型的调用先检查一次

业务结果上的目标，随机mac的落位准确率

业务指标评估成果

将正常mac、随机mac、不可用mac分为白灰黑三类。

• 白mac：目前的数据服务主力军，占大头
  1. imei和mac合法
  2. 1个mac关联不超过2个imei
  3. 如果有2个imei，则这两个imei的品牌一致（双卡双待机型）
  4. 1个imei只关联到一个mac
• 灰mac：随机mac，核心是识别随机mac
  1. 单imei有2个及以上的mac（已实现）
  2. 实人 + 设备nick粒度关联2个及以上的mac（已实现，可升级为账号 + 设备nick粒度）
  3. 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地址变化
一键换机场景	可能会变	可能会变	可能会变	可能会变	首次启动不变，后续启动可能会变，卸载一定会变
应用卸载重装	不变	不变	不变	不变

五、要做的事

1. 提升随机mac识别率
   1. 基于mac位置漂移，新增一批随机mac
2. 建立与机型品牌的关联关系
   1. 引入更多数据，关联到机型和设备
   2. 新的账号设备粒度的位置域数据，
3. 引入新的码值，如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 轨迹不完整问题

1. 如果只能关联到一个imei。则输出这个imei的全部轨迹，完毕
2. 关联到多个imei，根据活跃度推荐前3个imei，提醒下游应用大概率是这几个设备，分别输出展示

2.1.2 轨迹碰撞问题

1. 同上的第二条，推荐活跃度前3的imei的信息，分别输出展示

2.1.3 设备线索过多问题

1. 同上

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