GEO记录放进内部BI前，先对齐这张维度映射表

把AI可见性监测记录纳入现有内部报告时，最常遇到的不是"数据有没有"，而是"数据对不对得上"。字段名不一样、时间粒度不一样、问题分类口径不一样，直接合并就会让趋势图看起来合理，实际上已经失真。这篇文章给出一份面向运营人员的维度映射表设计方法和校验流程，帮你在正式导入BI之前，先把源数据和目标报表的对应关系理清楚。

为什么不能直接拖进BI

导入前要先确认记录的基本单位：一次执行、一条回答、一个被引用页面，还是一段时间的汇总。单位不同，即使字段都叫“次数”，也不能直接相加或互换。

另一个现实是，监测工具的清洗和消歧逻辑通常不对外公开。你看到的"品牌提及次数"或"引用来源"已经是处理后的结果，它的统计口径可能和你内部BI里同名指标的定义并不相同。如果不做显式对齐，两个看起来一样的字段加在一起，得出的数字既不代表监测侧的真实情况，也不代表业务侧的真实情况。

还有一个容易被忽略的边界：AI监测数据只能反映AI侧的引用和提及，无法直接关联到用户级的转化行为。如果你的BI模板里有"AI来源订单数"这类字段，它不应该从监测记录中强行映射，而应该标记为需要从其他数据源单独获取。

维度映射表该包含哪些列

一张够用的映射表不需要复杂的技术架构，但需要把以下几个维度写清楚：

源字段名称 ：监测工具提供的原始字段名，保持原样，不要提前改名或翻译。

源字段含义 ：用一句话说明这个字段在监测工具里的实际定义，包括统计口径、是否去重、是否经过清洗。如果工具文档没有写明，就标注"待确认"并在后续校验环节核实。

目标BI字段 ：内部报表中对应的字段名。如果找不到对应项，就写"无对应"而不是硬凑一个近似字段。

映射规则 ：说明从源到目标的转换方式。是直接取值、需要拆分、需要聚合、还是需要与其他数据源拼接。对于无法直接映射的字段，写明处理方式（保留原始值、单独存放、或标记为不可用）。

时间粒度 ：源数据的记录频率和目标报表的汇总周期。例如源数据是按每次执行记录的，而BI报表是按周汇总的，就需要在这里注明聚合方式和注意事项。

原始值保留策略 ：明确是否在聚合之外同时保留原始记录。对于AI监测数据，建议始终保留原始快照，以便在聚合结果出现异常时可以回溯验证。

校验备注 ：记录该字段在校验过程中发现的问题、已确认的口径差异、或需要定期复核的事项。

一张示意表长什么样

以下为示意，实际字段以您的监测工具和BI定义为准。

字段映射示例 1

• 源字段名称：execution_date
• 源字段含义：单次监测执行的UTC时间戳
• 目标BI字段：report_week
• 映射规则：先转换为报表时区，再按ISO周聚合并取周一日期
• 时间粒度：执行级→周
• 原始值保留：保留全部执行记录
• 校验备注：注意时区转换，源为UTC，BI为本地时间

字段映射示例 2

• 源字段名称：brand_mentioned
• 源字段含义：本次执行中AI回答是否提及目标品牌（布尔值）
• 目标BI字段：brand_mention_count
• 映射规则：按周求和
• 时间粒度：执行级→周
• 原始值保留：保留原始布尔值序列
• 校验备注：确认"提及"定义是否包含间接引用

字段映射示例 3

• 源字段名称：query_text
• 源字段含义：触发本次监测的原始问题文本
• 目标BI字段：无对应
• 映射规则：不参与BI聚合，单独存档供抽样核查
• 时间粒度：不适用
• 原始值保留：全量保留
• 校验备注：用于排查异常周的原始上下文

字段映射示例 4

• 源字段名称：citation_domain
• 源字段含义：AI回答中引用的域名
• 目标BI字段：ai_citation_source
• 映射规则：直接取值，不做归一化
• 时间粒度：执行级→周明细
• 原始值保留：保留原始域名
• 校验备注：确认是否需要与内部域名主数据对齐

字段映射示例 5

• 源字段名称：platform_name
• 源字段含义：执行监测的AI平台标识
• 目标BI字段：ai_platform
• 映射规则：直接取值
• 时间粒度：执行级→周分平台
• 原始值保留：保留原始标识
• 校验备注：确认平台名称版本是否与BI字典一致

字段映射示例 6

• 源字段名称：conversion_order_id
• 源字段含义：—
• 目标BI字段：ai_source_orders
• 映射规则：不可映射，标记为"需外部数据源"
• 时间粒度：不适用
• 原始值保留：不适用
• 校验备注：AI监测不含转化数据，此字段应从CRM或归因系统获取

这张表的价值不在于字段本身，而在于它迫使你逐项回答"这个数据到底是什么""它能不能直接用""不能用的时候怎么办"。很多合并失真不是因为数据错了，而是因为这些问题没有被提前问出来。

导入前的三步校验

映射表填完不等于可以直接导入。建议在正式汇入BI之前完成以下三步校验：

第一步：抽样核对原始值。 从最近一个月的监测记录中抽取5-10条，逐条对照映射表中的"源字段含义"和实际值。重点检查那些经过聚合或转换的字段，确认聚合后的结果是否还能还原回原始记录。如果发现某条记录的聚合值与原始值逻辑上不一致，先暂停导入，回到映射表修正规则。

第二步：时间粒度交叉验证。 选一个完整的统计周期（比如一周），分别用监测工具的原始记录和BI中的汇总结果计算同一个指标。如果使用同一批已保存记录、同一口径和同一时间范围，两个汇总数字应当对齐。差异需要检查聚合逻辑、时区处理、遗漏或重复记录，不能归因于AI新一轮回答的随机变化。

第三步：无法映射字段的处置确认。 逐一检查映射表中标记为"无对应"或"不可映射"的字段，确认它们确实不会在任何下游报表或分析中被误用。常见的风险是某个字段虽然在映射表里标了"不可用"，但在BI模板中仍然保留了占位列，导致后续使用者以为数据缺失是临时问题而非结构性边界。

这三步校验的目的不是追求零误差，而是在数据进入BI之前，把所有已知的口径差异和结构性限制变成显式的、可追溯的记录。这样当未来有人质疑某个数字为什么和业务直觉不符时，你可以拿出映射表和校验备注，说明这个数字是怎么来的、它的边界在哪里。

关于数据粒度的一个提醒

AI可见性监测的数据价值在于它能反映AI侧的真实表现，而不是替代业务系统的转化归因。以AlphaRank当前项目的监测配置为例（40个监控词、6个平台、每日自动执行；需要分析时由用户发起Agent任务），团队可以从可见的回答与引用记录整理对照材料，再让Agent协助分析问题。这里的映射表由团队按自己的报告需要维护。但无论监测频率多高，它仍然是AI侧的观测数据，不是用户行为的完整画像。

在设计映射表时，把这个边界写进去，比把更多字段塞进去更重要。一张诚实的映射表，比一张看起来完整但实际上混合了不同口径的映射表，对长期决策更有价值。

希望先建立可持续观察的材料来源，可以了解AlphaRank；比较两份报告前，也可使用时间与统计口径的可比较性检查。