AI 可見度資料契約怎麼做？從去重鍵到報表對帳

AI 可見度資料契約的做法，是先把事件欄位、去重鍵、有效條件與版本寫成一份大家共用的規格，再用斷言把不該進彙總的資料攔在門外，最後從母事件和子事件雙向對帳。這適用於已經有觀測資料、接下來要讓數字被重算的團隊；候選品牌集合、去重規則或分母只要改過，就開新的指標版本，舊趨勢別直接往後接。本文提供的是可以照著建的東西：欄位字典、一份最小資料契約、三層去重鍵、七條斷言、一組手算得出來的合成樣本、版本相容對照表，以及交付前的對帳表。

公式寫得出來，和數字能被重算，是兩件事。假設報表上寫著品牌提及率 44%，你回頭想知道那是哪 44%——結果發現同一個回答被匯入兩次、題庫九月換過版但舊資料還接在同一條趨勢線上、有幾筆標成 valid 卻找不到回答原文。這三件事都不會讓報表跳出錯誤，它只會安靜地給你一個數字。

指標的基本公式可以在 既有 AI Visibility 量測文章找到，本文不重講。這裡處理的是下一層：把指標落成資料處理和人工審核可以共用的規格。

Otlex 示範帳戶的總覽畫面，示意指標會用到哪些欄位與狀態；畫面資料不代表客戶成果或完整資料契約。

AI 可見度資料契約：先定義輸入與輸出

資料契約的角色，跟買賣雙方事前講好的驗收規格一樣：每一欄是什麼意思、什麼情況算不合格、驗收表上必須留下哪些數字。寫報表的人、執行觀測的人和審核回答的人，照同一份規格做事。

先建一份短字典。欄位名稱可以依工具調整，同一專案裡的意思要固定——今天 answer_status 指一件事、明天 valid 又指另一件，等於倉庫裡「在庫」有兩種算法。

契約本身可以用一段簡化設定表達。這不是 Otlex 或任何 AI 平台公布的格式，而是本文建議的最小工作模型：

contract_version: metrics-v2
observation_key:            # 什麼組合算「同一筆觀測」
  - prompt_set_version
  - prompt_id
  - engine
  - surface_or_mode
  - language
  - region
  - observed_at
event_unit: one_candidate_brand_per_valid_answer   # 每個有效回答每個候選品牌最多一筆
valid_answer_requires:      # 這兩項缺一，這筆就不算有效
  - raw_answer_ref
  - answer_status: valid
metric_definition_version: md-2026-09-21-01

契約管得到欄位與計數邊界，管不到品牌別名怎麼歸戶、推薦強度怎麼判、內容要點怎麼拆——那些規則另存版本，並在報表上顯示是哪一版。

去重鍵：一筆觀測如何保持唯一

去重不是把資料表裡看起來一樣的文字刪掉。要先決定「同一筆」的邊界——就像人用身分證字號辨識，同一個人辦了兩張卡，不會因此變成兩個人。本文建議把一次觀測的鍵寫成：

observation_key =
(prompt_set_version, prompt_id, engine, surface_or_mode,
 language, region, observed_at, run_id)

同一題因為重試產生兩個回答時，run_id 要不同，兩筆都保留，並在執行狀態註明重試關係——刷卡失敗重刷一次，兩筆授權紀錄都留著，但只出一次貨。反過來，只是匯入工作重跑、並沒有新的回答，就要用相同的 observation_id 做冪等寫入；那跟重新整理付款頁面不該重複扣款是同一件事。

observed_at 的精度也要先講好。只存日期，做日級報表沒問題，但同一天的兩次合法重測就分不開了。

品牌事件再使用另一個鍵：

brand_event_key = (observation_id, canonical_brand_id)

一個回答裡品牌名稱出現四次，仍然只產生一個品牌事件。別名、產品名和公司名要不要指向同一個 canonical_brand_id，看當時的品牌字典版本；看到結果之後才合併，等於回頭改了分子。來源事件也要有自己的鍵，例如 (observation_id, displayed_source_id)——來源呈現和品牌提及是兩種事件。

可以用下表檢查三種最常被混在一起的計數：

這樣分層之後，「同一回答出現多個品牌」保存得完整，同一品牌重複出現也不會因為字串次數把事件數吹大。真的需要量字串出現幾次，那是另外一欄，別覆蓋品牌事件數。

斷言：先攔住不該計算的資料

進貨要過驗收站：不合規格的退到待處理區，而不是先塞進倉庫、再在盤點表旁邊加一句提醒。資料也一樣，彙總前先跑斷言，失敗的進待修清單並保留原因。以下是本文建議的最小集合：

1. observation_id 不可重複；若是重試，必須有不同 run_id 和重試關係。
2. valid 回答必須有 raw_answer_ref、題庫版本、引擎和觀測時間。
3. empty、error、blocked 或 not_observed 不得直接產生品牌、來源或推薦事件。
4. 每一筆品牌事件的 observation_id 必須存在於回答母表，canonical_brand_id 必須存在於同一版候選品牌集合。
5. 同一 observation_id + canonical_brand_id 最多一筆品牌事件；重複資料退回，別讓最後寫入的那一筆把問題蓋掉。
6. 指標彙總的分子不能大於它所使用的事件分母；推薦與回答涵蓋也要套用各自的適用條件。
7. 彙總列必須帶著題庫、品牌字典、判讀規則和指標定義版本，缺任何一項就標記為不可比較。

用接近 SQL 的寫法，前兩個去重檢查長這樣：

-- 母事件鍵重複就退回匯入
select observation_id, count(*)
from observations
group by observation_id
having count(*) > 1;

-- 品牌事件同一回答同一品牌只能一筆
select observation_id, canonical_brand_id, count(*)
from brand_events
group by observation_id, canonical_brand_id
having count(*) > 1;

這些是資料品質示例，不是特定資料庫的部署指令。重點在於把錯誤變成可以定位的那幾列，而不是讓儀表板用空白、零或最後一筆值把它吞掉。

合成樣本：讓公式可以被重算

磅秤上線前會先放砝碼校正。接真實觀測之前，也先用合成資料驗證去重和彙總。

下面有 5 個有效回答，候選品牌固定為 A、B、C。每個回答中同一品牌只算一次；o3 雖然把 A 寫了兩次，仍然只有一筆 A 事件。這是公式測試，不是平台或客戶觀測。

加總後，A 有 4 筆事件、B 有 3 筆、C 有 2 筆，全部候選品牌事件 9 筆。事件份額因此可以重算為 A 4/9、B 3/9、C 2/9。A 的回答提及率則是 4/5——分母是有效回答數，和事件份額的分母不同。

這個樣本的用途是當回歸測試：o3 的重複 A 若沒去重，A 會變成 5 筆、總事件變成 10 筆，比例全部跑掉。資料契約要攔的就是這個。

再加一個沒有候選品牌的有效回答 o6。A、B、C 的事件數和事件份額都不動，有效回答數卻變成 6。o6 仍然留在回答提及率的分母裡，因為它確實是一個有效回答，只是沒有產生品牌事件。對帳時要看得出這個差異——為了讓 SOV 分母好看而把 o6 從母表刪掉，等於同時改壞了另一個指標。

版本相容與分層彙總：避免報表失真

版本不只是一個檔名。至少有四種版本會影響可比性：題庫版本、品牌字典版本、執行條件版本和指標定義版本。內容頁版本可以當變更脈絡，替代不了前面那四種資料規則。

分層報表最容易在彙總這一步失真，而且失真得很有說服力。假設第一組是 1/1，第二組是 9/99。兩組比例的簡單平均是 54.5%；把相同定義的分子和分母相加，正確答案是 10/100 = 10%。這就是兩家分店的成交率平均不等於全公司成交率——一家只接待一組客人就成交，另一家接待九十九組成交九組，平均起來卻像是一半。

只有在兩組的單位、適用條件和指標定義都相同時，才可以用 sum(numerator) / sum(denominator)。一組是回答事件、另一組是品牌事件的話，連這樣的合併都不成立。

SOV 尤其要避免拿回答數當品牌事件分母。沿用前面那 5 個回答：A、B、C 的 SOV 分母是 9 筆品牌事件，不是 5 個回答。跨日期彙總時，先把同一指標版本的品牌事件相加，再算比例；先算每天百分比再做未加權平均，得到的是「每日比例的平均」——那是另一個指標，要用就明寫。

對帳實作：從原始事件到可交付報告

契約落地可以照下面的順序做。每一步都有一個可以回頭檢查的結果，先不用管儀表板好不好看。

1. 封存輸入。 保存題庫、品牌集合、版本、觀測條件與原始回答位置，先算出已執行、有效、空結果、錯誤與阻擋筆數。
2. 建立母事件。 每個合法的觀測鍵只建一筆回答事件；匯入重跑用冪等鍵，真正的重測才建新的執行識別。
3. 衍生子事件。 從有效回答產生去重後的品牌事件與來源事件，人工待判定的資料留在狀態欄，別轉成否定結果。
4. 跑斷言。 把重複鍵、孤兒事件、缺版本、非法狀態和分子分母矛盾列成錯誤表，錯誤列不進正式 KPI。
5. 做雙向對帳。 這一步就是盤點：帳上有的，貨架上要找得到；貨架上有的，帳上也要有。從母表往下數，確認每個有效回答都有對應判讀狀態；再從事件表往上查，確認每個子事件都有母回答與原始證據。
6. 輸出報表。 每個比例附上分子、分母、事件單位、版本、期間、分層條件、排除筆數與待修筆數，並保存產出版本。

交付前至少留下這張對帳表：

這套流程可以和 品牌提及、引用事件的留證方法接合，本文更關心事件表能不能穩定交給彙總層。只需要理解一般指標的基本分母，先讀 AI Visibility 量測方法；要追查來源 URL，再看 Citation Tracking。

限制：資料契約能保護什麼

資料契約保護的是計數邊界、版本脈絡和重算路徑。AI 回答本身穩不穩定，它管不到。

Google Search Central 的 AI features 文件說明，AI Overviews 與 AI Mode 使用的模型和技術可能不同，回答與連結集合也會變動；頁面符合條件，Google 仍不保證一定抓取、索引或提供。這些是觀測結果的外部限制，資料表的斷言消不掉。

Google 的 生成式 AI 搜尋指南目前保留 SEO 基礎，也指向 Search Console 的 Generative AI performance report。那份報告可以補充 Google 生成式 AI 功能的搜尋表現，卻不會替你保存其他引擎的逐題回答、品牌事件或自訂契約。對本篇來說，重要的是把外部報告的來源、日期與口徑寫進版本欄位——外部工具給的是摘要，不是事件計數。

OpenAI 的 ChatGPT Search 說明提醒，搜尋回答與 citations 可能不完整、過時或錯誤，重要資訊仍要開啟原始來源核對。資料契約能做的，是把這個限制與來源位置留下來；一次讀回成功，證明的也只是那一次。

相關概念與產品連結

若你要先決定題庫怎麼分組，可讀既有的 ChatGPT 品牌監測文章；若要理解重複觀測的執行條件，可讀 GEO 與 SEO 的差別。兩篇處理的是題庫與觀測條件，本文專注在事件鍵、斷言、版本和對帳。

Otlex 是由 EthorX（伊索斯科技有限公司）開發的 AI 搜尋優化平台，觀測 ChatGPT、Google AI Overview、Google AI Mode、Gemini、Grok、Perplexity、Claude 等七個 AI 引擎回答中的提及、引用與推薦，協助整理內容缺口並回看改動後的觀測。是否適合導入，仍要依題庫、平台可取得性、資料保存與審核範圍評估。

常見問題

查證邊界

本文外部文件查閱日期為 2026-09-21，使用 Google Search Central AI features、生成式 AI 搜尋指南、更新紀錄，以及 OpenAI ChatGPT Search 說明。指標字典、資料契約、去重鍵、斷言、版本相容與對帳流程是本文提出的編輯方法，不是 AI 平台共同公布的標準。文中的 44%、o1–o6、1/1 與 9/99 都是合成或假設案例，只用來驗證計數邏輯，沒有使用客戶或未授權觀測結果。

參考來源

• Google Search Central：AI features and your website
• Google Search Central：Optimizing your website for generative AI features on Google Search
• Google Search Central：Latest documentation updates
• Google Search Central：How to specify a canonical URL
• OpenAI Help Center：Searching the web with ChatGPT
• EthorX：Otlex