📚 课程目录第2章移动端设备标识基础

2. 移动端设备标识基础

在移动端风控、反欺诈、账号安全与增长分析中，“设备标识”几乎是所有策略的起点。它承担着把一次请求、一个账号、一台物理设备或一个应用安装实例关联起来的职责。理解设备标识的定义、分类与限制，是后续做设备画像、账号关联、团伙识别和风险评分的基础。

一、核心原理：设备标识到底标识了什么

严格来说，移动端并不存在一个绝对稳定、全局唯一、跨应用通用的“设备身份证”。我们通常说的设备标识，是在特定平台、特定权限、特定应用沙箱或特定联盟范围内，用于区分设备或应用实例的字符串。它可能标识的是：

物理硬件：如 IMEI、MEID、序列号，理论上贴近真实设备，但受权限和隐私政策限制严重。
系统或应用沙箱实例：如 Android ID、iOS 的 identifierForVendor，通常在同一设备同一应用或同一厂商应用集合内有效。
广告或统计用途的虚拟标识：如 IDFA、OAID、GAID，可由用户重置，主要用于广告归因与统计。
应用自生成标识：如 UUID、安装 ID，由应用首次启动时生成并持久化，卸载重装后会变化。

因此，设备标识的核心不是“找到唯一真身”，而是在业务可接受的稳定性和合规范围内，建立可追踪、可关联、可复现的标识体系。风控系统通常不会依赖单一标识，而是采集多标识并做交叉验证与降级兜底。

  关键认知：设备标识的稳定性、唯一性、可获取性三者往往不可兼得。Android 与 iOS 的差异、系统版本差异、用户授权状态差异，都会导致同一套采集逻辑在不同设备上得到不同结果。

二、分类与常见术语：IDFA、OAID、IMEI、Android ID、UUID

从工程视角，可以把常见标识分为四类：硬件级标识、系统级标识、广告级标识、应用级标识。下面用表格对常见术语做对比。

标识名称	所属平台	典型稳定性	是否可重置	主要用途	主要限制
IMEI	Android/功能机	高，贴近硬件	否	传统设备识别、风控	Android 10+ 普通应用不可读，需系统权限
Android ID	Android	中，同应用签名下较稳定	恢复出厂或部分系统变更后变化	应用内设备识别、统计	不同签名应用不同，卸载重装可能变化
IDFA	iOS	中，用户可关闭跟踪	是，可重置	广告归因、统计	ATT 授权后才可以获取，未授权返回全零
OAID	Android 国内厂商	中，厂商联盟内有效	是，用户可重置	国内广告归因、统计	依赖厂商 SDK，不同厂商实现有差异
UUID	跨平台	低到中，取决于存储策略	是，可重新生成	应用内会话、安装实例标识	卸载重装或清除数据后变化

除了上述标识，实际工程中还会遇到 GAID（Google Advertising ID）、VAID、AAID、MAC 地址、IP、User-Agent、设备指纹等。它们各自有适用边界，不能简单互相替代。

三、方法流程：移动端设备标识采集与降级策略

一个可落地的设备标识采集流程，通常遵循“多源采集、优先级排序、失败降级、本地持久化、服务端归一”的思路。典型流程如下：

启动采集：应用启动或关键业务节点触发标识采集。
按优先级获取：优先尝试广告标识或系统标识，再尝试硬件标识，最后使用应用自生成标识。
权限与合规检查：检查用户授权状态，未授权时不得强行获取或上传敏感标识。
本地持久化：将可用标识写入应用私有存储，如 SharedPreferences、Keychain、文件或数据库。
生成兜底 UUID：当所有外部标识不可用时，生成 UUID 并持久化，作为安装实例标识。
服务端归一：服务端将多标识组合成设备主键，并维护标识之间的映射关系与置信度。

下面是一个简化的 Android 端采集伪代码，展示优先级与降级逻辑：

fun collectDeviceIds(context: Context): Map<String, String> {
    val result = mutableMapOf<String, String>()

    // 1. 尝试 OAID（国内厂商广告标识）
    val oaid = OaidHelper.getOaid(context)
    if (!oaid.isNullOrBlank()) {
        result["oaid"] = oaid
    }

    // 2. 尝试 Android ID
    val androidId = Settings.Secure.getString(
        context.contentResolver,
        Settings.Secure.ANDROID_ID
    )
    if (!androidId.isNullOrBlank()) {
        result["android_id"] = androidId
    }

    // 3. 尝试应用内持久化 UUID
    val uuid = AppStorage.getOrCreateUuid(context)
    result["uuid"] = uuid

    // 4. 附加非敏感环境信息
    result["os_version"] = Build.VERSION.RELEASE
    result["model"] = Build.MODEL

    return result
}

服务端收到上述字段后，不应直接把某一个字段当作设备唯一键，而应建立类似 device_id = hash(oaid || android_id || uuid) 的归一逻辑，并记录每个字段的来源、时间与置信度。

四、案例与场景：设备标识在账号风险关联中的用法

假设某电商 App 发现一批新注册账号在短时间内集中领取优惠券，风控系统需要判断这些账号是否来自同一设备或同一设备农场。此时设备标识的作用非常直接：

同设备多账号：多个账号在相近时间使用相同 OAID 或 Android ID 登录，风险升高。
同账号多设备：同一账号短时间内在多个差异极大的设备标识上登录，可能为盗号或代刷。
设备农场识别：大量设备标识呈现相似硬件型号、系统版本、IP 段，且行为模式高度一致。
卸载重装绕过：用户卸载重装后 UUID 变化，但 OAID 或 Android ID 可能仍保留，可用于关联。

实战中，设备标识更适合作为“关联线索”而非“唯一真相”。将设备标识与账号、IP、行为序列、支付工具等维度组合，才能形成稳定的风险判断。

五、误区与复盘：设备标识使用中的常见问题

很多团队在初期容易把设备标识当成绝对可靠的唯一键，结果在真实环境中频繁踩坑。常见误区包括：

把 IDFA 当永久设备 ID：IDFA 可被用户重置，未授权时返回全零，不能作为长期唯一标识。
认为 Android ID 全局唯一：不同应用签名、不同用户、恢复出厂设置后都可能变化。
忽略权限与合规：IMEI 等硬件标识在 Android 10+ 已无法由普通应用获取，强行采集会导致上架风险。
只依赖单一标识：单一标识失效时，整个设备关联链路断裂，风控策略直接失效。
不做服务端归一：客户端采集多标识但服务端不建立映射，导致同一设备被识别为多个设备。

设备标识采集必须遵循最小必要原则与用户授权要求。涉及 IMEI、IDFA、OAID 等标识时，应明确告知用途，并在隐私政策中披露。未授权时，应使用应用内 UUID 等低敏感标识作为兜底。

复盘时，可以用以下清单检查设备标识体系是否健康：

是否覆盖 Android 与 iOS 双端，并区分系统版本与权限状态？
是否有多标识采集与降级策略，而不是单点依赖？
是否在本地持久化 UUID，避免每次启动重新生成？
服务端是否维护标识映射表与置信度，而不是直接使用原始值？
是否对未授权、全零、异常格式的标识做了过滤与标记？