触达量化核心：不是“多少人能用”，而是“多少人会因这个需求产生行为改变”。AI产品的非确定性和排队机制使得触达不仅要看UV，还要看并发和任务依赖。
#### 2.2 需求拆解与指标分解
触达量化的路径可以拆解为四个层级，对应不同的数据维度和验证方法：
1. 原始流量池（DAU/MAU）：产品的全局日/月活跃用户数，作为触达基数的上限参考。
2. AI功能曝光：从埋点日志中筛选出“看到或触发AI入口”的独立用户数。
3. 任务影响过滤：排除被动触达或中途流失用户，保留进入AI任务链（如：提示词输入—推理—结果消费）的用户。
4. 触达系数计算：根据任务核心程度、AI使用频次、会话留存比例，确定一个 0.1 ~ 1.0 的折扣系数。
#### 2.3 触达系数计算与数据来源
触达系数是整个量化过程中最需要主观校准的部分。下表提供了不同场景下的系数基准和推荐的数据验证方式：
| 功能类型 | 业务场景 | 影响系数 | 数据来源 | 验证字段 |
| :--- | :--- | :--- | :--- | :--- |
| **核心LLM能力** | 智能客服主流程 | 1.0 | 服务端API日志 | `user_id`, `session_duration` |
| **AI辅助工具** | 代码补全/文本续写 | 0.7~0.9 | IDE插件埋点 | `trigger_count`, `accept_rate` |
| **批处理/离线AI** | 数据去重/报表生成 | 0.3~0.6 | 任务调度系统 + 邮件触达 | `task_owner_id`, `open_email` |
| **实验性AI功能** | A/B测试桶功能 | 0.1~0.2 | AB实验分配表 | `experiment_group`, `page_view` |
计算示例：
- 产品DAU = 50万；目标功能入口点击率 = 40%；任务完成率 = 60%；触达系数 = 0.7（核心路径）。
- Reach = 50万 × 40% × 60% × 0.7 = **8.4万用户/日**。
数据可靠性要求：触达数据必须至少来自以下一种可回溯渠道，且覆盖完整用户生命周期：
-- 推荐SQL模板（Redshift/BigQuery）
SELECT
DATE_TRUNC('day', request_at) AS day,
COUNT(DISTINCT user_id) AS reached_uv,
COUNT(*) AS triggered_times,
COUNT(DISTINCT CASE WHEN is_core_task = TRUE THEN user_id END) AS core_reached
FROM ai_inference_logs
WHERE feature_name = 'image_upscale'
AND request_at >= CURRENT_DATE - INTERVAL '7 days'
GROUP BY 1
ORDER BY 1;常见失误：仅用API调用次数代替独立用户数。AI产品可能被高频调用，但实际触达用户很少（如：单个爬虫用户每天触发10万次推理）。必须同时关注 UV 和 调用频次分布。
#### 2.4 验收标准与交付物
验收标准：
1. 触达估算值与上线后两周实际值偏差 < ±15%。
2. 数据血缘文档覆盖所有系数来源及计算逻辑。
3. Reach值可随DAU/MAU波动自动更新（建议通过仪表盘展示）。
交付物模板：
- 数据字段定义表：列明 `user_id`、`session_id`、`feature_key`、`event_timestamp`、`weight_coefficient`。
- 触达系数校准记录：包含校准人、校准日期、场景描述、计算公式、版本号。
- Reach看板原型：展示日/周/月维度趋势、核心功能对比图、系数分布直方图。
产品需求课拆解点：触达量化是RICE中最容易被AI团队忽略的部分——人们倾向于认为“AI能服务所有人”，从而高估Reach。务必通过 任务影响过滤 和 系数校准 两个环节来克制估算冲动，保持分数可信度。