分析设备数据时，只记录“手机、平板、桌面端”通常不够。产品团队真正关心的往往是：设备能否使用生物识别、是否支持某类网络、屏幕是否适合复杂交互，以及某项功能不可用究竟是设备限制、系统限制，还是用户尚未授权。
来源只给出了“为分析建模设备能力”这一主题，没有限定具体平台或数据仓库。下面以通用事件分析系统为假设，给出一种可以这样实践的数据模型：将稳定的硬件能力、随系统版本变化的软件能力，以及运行时权限和状态分开处理。
不要把设备名称直接当作能力
设备型号是事实，能力是从事实推导出的分析维度。两者混在事件表中，会很快产生问题。
例如，客户端直接上报下面这些字段：
{
"device_model": "ExamplePhone 12",
"supports_biometrics": true,
"supports_5g": true,
"camera_count": 3
}
这种方式看似方便，但能力判断散落在多个客户端版本里。旧版本可能上报错误，新型号上线后又可能被识别为未知设备。最终，同一个型号会出现相互矛盾的能力记录。
更稳健的办法是把数据拆成三层：
| 层次 | 示例 | 变化速度 | 推荐来源 |
|---|---|---|---|
| 设备事实 | 厂商、型号、硬件代次 | 慢 | 客户端采集或设备目录 |
| 推导能力 | 生物识别、NFC、5G、最低编解码支持 | 中等 | 版本化能力目录 |
| 运行时状态 | 权限是否授予、网络是否可用、功能是否启用 | 快 | 每次事件或会话 |
这里最重要的边界是：“具备能力”不等于“当前可用”。设备支持摄像头，不代表用户授予了摄像头权限；设备支持 5G，也不代表事件发生时连接的是 5G 网络。
用带有效期的能力目录保留历史
能力映射会被修正，新型号也会持续加入。如果只维护一张可覆盖更新的当前表，历史报表可能在没有新事件的情况下发生变化。
可以这样实践：为能力目录增加生效时间，并保留来源和规则版本。下面的 PostgreSQL 示例可以直接运行；在其他仓库中，可将 TIMESTAMPTZ 和布尔类型替换为对应方言。
CREATE TABLE device_capability_catalog (
manufacturer TEXT NOT NULL,
model_pattern TEXT NOT NULL,
valid_from TIMESTAMPTZ NOT NULL,
valid_to TIMESTAMPTZ,
supports_biometrics BOOLEAN,
supports_nfc BOOLEAN,
supports_5g BOOLEAN,
capability_version TEXT NOT NULL,
source_name TEXT NOT NULL,
PRIMARY KEY (manufacturer, model_pattern, valid_from)
);
CREATE TABLE analytics_events (
event_id TEXT PRIMARY KEY,
occurred_at TIMESTAMPTZ NOT NULL,
event_name TEXT NOT NULL,
manufacturer TEXT NOT NULL,
device_model TEXT NOT NULL,
os_name TEXT,
os_version TEXT,
camera_permission_granted BOOLEAN,
active_network_type TEXT
);
INSERT INTO device_capability_catalog VALUES
('Example', 'Phone 12%', '2024-01-01T00:00:00Z', NULL,
true, true, true, 'catalog-2024-01', 'internal-device-catalog');
INSERT INTO analytics_events VALUES
('evt-001', '2024-06-15T10:00:00Z', 'scan_started',
'Example', 'Phone 12 Pro', 'ExampleOS', '17.2', false, 'wifi');
SELECT
e.event_id,
e.event_name,
c.supports_biometrics,
c.supports_5g,
e.camera_permission_granted,
e.active_network_type,
CASE
WHEN c.model_pattern IS NULL THEN 'unknown_device'
WHEN e.camera_permission_granted IS FALSE THEN 'permission_denied'
ELSE 'available'
END AS camera_feature_status
FROM analytics_events e
LEFT JOIN device_capability_catalog c
ON e.manufacturer = c.manufacturer
AND e.device_model LIKE c.model_pattern
AND e.occurred_at >= c.valid_from
AND (c.valid_to IS NULL OR e.occurred_at < c.valid_to);
这个例子刻意使用 LEFT JOIN：没有匹配到能力目录的设备不能被默认为“不支持”。未知与否定是两种不同状态，否则新设备发布当天就会被错误归入低能力人群。
生产环境还需要处理型号模式重叠。如果 Phone 12% 和 Phone 12 Pro% 同时存在，应增加匹配优先级，或把客户端型号规范化为稳定的设备键，避免一次事件匹配多行。
把布尔值升级为可解释状态
单个布尔字段无法覆盖分析中的不确定性。对于关键能力，建议至少区分以下状态：
supported：目录明确确认支持。unsupported：目录明确确认不支持。unknown：设备未识别，或者目录没有该能力信息。conditional：取决于系统版本、地区、配件或配置。
例如，某项功能既依赖硬件，也要求最低系统版本。能力目录可以记录硬件支持，语义层再结合操作系统计算最终资格：
SELECT
event_id,
CASE
WHEN supports_biometrics IS NULL THEN 'unknown'
WHEN supports_biometrics = FALSE THEN 'unsupported'
WHEN os_name = 'ExampleOS' AND split_part(os_version, '.', 1)::INT < 16
THEN 'conditional'
ELSE 'supported'
END AS biometric_feature_eligibility
FROM enriched_device_events;
版本字符串在真实数据中常包含测试版后缀、空值和非数字字符。上述 SQL 是最小示例；上线前应先建立规范化的主版本字段，而不是在每张报表中重复解析字符串。
分析时比较“符合资格的人”，而不是所有用户
能力模型的价值不只是丰富画像，更重要的是修正指标分母。假设一个扫码功能要求摄像头能力和权限，如果把所有活跃设备放进转化率分母，产品表现会被设备限制和权限拒绝共同稀释。
更有解释力的漏斗可以拆成：
- 硬件支持该功能的设备数。
- 系统版本满足要求的设备数。
- 已授予运行权限的设备数。
- 实际启动功能的设备数。
- 成功完成任务的设备数。
这样的分层可以回答两个不同问题：产品在“能够使用”的人群中表现如何，以及有多少用户被设备、系统或权限挡在入口之外。
同时要避免将能力数据用于不必要的个体追踪。设备型号、系统版本、屏幕参数和硬件组合在一起，可能形成较强的识别信号。分析表应优先保留业务所需的能力维度，限制原始设备属性的访问范围，并设置合理的保留期限。
上线前的检查清单
- 为设备事实、推导能力和运行时状态定义不同字段，避免语义混用。
- 使用
unknown表示未识别设备，不要自动映射为false。 - 为能力规则记录版本、生效时间和来源，使历史结果可以复现。
- 监控未匹配设备比例，并按流量优先补充目录。
- 为模式重叠、目录回填和规则修正设计测试。
- 在指标中明确分母是全部设备、能力符合设备，还是权限可用设备。
- 只采集产品决策所需的属性，并评估设备组合带来的隐私风险。
设备能力模型不是一张不断加列的型号表，而是一套解释“理论支持、条件满足、当前可用和实际使用”的语义。把这些层次拆开后，报表才能在新设备、新系统版本和权限变化到来时保持稳定，也更容易定位真正阻碍用户完成任务的环节。