做 AI 搜尋監測 dashboard 的順序，是先定義資料欄位，再決定要畫哪些圖。六層資料——範圍、題目、執行、回答、引用、任務——各自有最小欄位，指標名稱跟計數單位綁在一起，每張卡片標明資料來源。這適用於要拿觀測結果做內容決策的團隊；同一畫面混了 Search Console 報告和跨引擎人工觀測時，兩者分列，別合併計算。本文提供的是可以直接建表的東西：閱讀前要能回答的四個問題、六層資料模型、提及率與引用率的命名規則、五種資料狀態的顯示方式，以及從摘要回到證據的三層閱讀順序。
一個只有總分的儀表板，等於車上只剩一顆亮著的紅燈。你知道有事，不知道是油、是水溫還是胎壓，也不知道該找誰。分數從 62 掉到 58 的時候，團隊會開一個小時的會去猜——而那一個小時本來可以拿去改內容。
本文討論的是資料模型與閱讀方式，不提供現成 UI，也不宣稱任何工具會自動擁有下列欄位。
題目、執行條件、回答與引用來源應能沿資料鏈逐層回查。
dashboard 要先回答哪四個問題
畫圖之前，先讓任何一個打開它的人能回答四件事：
- 這個數字涵蓋哪個市場、語言、引擎和題目？
- 分子和分母各是什麼，一筆資料代表一題、一次回答還是一個引用？
- 哪些回答已完成，哪些是執行失敗、部分完成或等待人工判讀？
- 點進去後，能否找到原始回答、引用 URL、題目版本和執行日期？
這四題是閱讀條件。沒有它們，趨勢線畫得越精細，讀者越容易忘記資料範圍——漂亮的曲線本身就會製造一種「這已經確定了」的感覺。
Google 的官方 AI optimization guide 目前提到 Search Console 的 Generative AI performance report。那份報告屬於 Google 自有搜尋資料的脈絡；跨引擎的回答、提及和引用觀測是另一種資料源。dashboard 要在每張卡片標示資料來源——把 Search Console 報告和第三方或人工觀測合併成同一個指標，數字算得出來，解釋不動。Google AI optimization guide
AI 搜尋監測 dashboard 的最小資料模型
先建立六層資料，再決定怎麼呈現。下面的欄位是編輯與資料治理建議，不是某個平台的官方標準。
| 資料層 | 最小欄位 | 讀者要核對的事 |
|---|---|---|
| 範圍 | 市場、語言、裝置或上下文、引擎 | 這筆資料能和哪一筆比較 |
| 題目 | 題目原文、題目識別、版本、意圖 | 當時送出的是什麼 |
| 執行 | 開始時間、完成時間、狀態、錯誤訊息 | 結果是否完整 |
| 回答 | 原始回答、人工摘要、品牌提及註記 | 摘要有沒有超出回答 |
| 引用 | URL、標題、抓取日期、相關性註記 | 引用與主張是否有關 |
| 任務 | 缺口、目標頁面、責任人、下一步 | 觀測如何交給工作流程 |
範圍欄位：決定能不能放在一起看
市場和語言不是備註。繁體中文台灣的題目和其他地區或語言的題目，內容脈絡可能完全不同；不同引擎的回答也不是同一個系統的連續值。每一列保留範圍，摘要卡才不會把兩種條件畫成一條線。
題目欄位：保留測量對象
題目要有穩定識別和版本。題目文字相同、前置條件不同的兩筆，也要分得出來。題目被改寫之後，新回答用新的版本欄位，別靜默覆蓋舊資料——覆蓋掉的那一刻，之前所有的趨勢就失去了解釋。更完整的題目權限與生命週期，放到跨團隊 prompt 治理處理。
執行欄位：避免把缺漏當成答案
完成、失敗、部分完成、逾時、尚未判讀要有不同狀態。某次任務沒留下回答時，顯示執行狀態和原因——直接列成「品牌沒有被提及」，是把一個技術問題寫成了一個行銷結論。這個區分也讓後續計算能選有效回答當分母，而不是把所有排程都算進去。
回答與引用欄位：摘要必須能回到材料
回答原文是人工判讀的依據。受限於保存方式只能留畫面或摘要時，欄位要明確記錄限制。引用 URL 也保留原始網址、取得日期和人工相關性註記，不只留一個來源分類——「官方網站」這個分類，回答不了「是哪一頁」。
提及率、引用率或 SOV 都應先寫清楚計數單位、比較集合與分母。
提及率、引用率與 SOV 怎麼命名
指標名稱要跟計數單位綁在一起。下面示範的是編輯資料模型，不是跨平台通用公式。
題目單位提及率
一次觀測若是一個「題目 × 引擎 × 條件」單位，就先固定兩個計數：指定條件下出現品牌提及的有效回答數，以及同條件的有效回答總數；前者除以後者才是這個欄位的比例。
舉例：某範圍內有 40 筆有效回答，其中 12 筆出現品牌提及，題目單位提及率就是 12 ÷ 40。這個數字描述的是「已定義範圍」——流量、排名或所有 AI 平台的市場份額，它一樣都沒說。
引用率
引用率也要先定義分母。一種可讀的寫法是：
有效回答中含指定來源引用的比例 = 含指定來源的有效回答數 ÷ 有效回答總數
另一種研究問題可能要算引用筆數，那時分子是一筆引用，不是一個回答。同一個名字底下躲著兩個分子，報表就開始騙人了。dashboard 要在卡片上寫出單位：「有效回答」還是「回答中的引用」。
SOV 是否適用
「SOV」常被拿來表示一種比較概念，但品牌提及率不能直接改叫所有平台通用的 SOV。團隊要用 SOV 的話，就寫清楚比較集合、競品清單、題目單位、引擎範圍、分母和品牌提及判定規則。
只計算自己的品牌有沒有出現時，用「題目單位提及率」通常安全得多——名字準確，就少了一整輪的誤讀。
這也是 dashboard 要保存原始回答和分類規則的原因。品牌被列出、被建議、被引用或被拿來比較，是四種不同事件，一個總數蓋不住它們。
把異常與來源放進同一個資料層
好讀的 dashboard 會把資料狀態和來源放在畫面上，而不是塞進註腳。建議每筆結果保留這些狀態：
| 狀態 | 顯示方式 | 可做的下一步 |
|---|---|---|
| 已完成且可回查 | 顯示回答、引用和日期 | 進入人工分類或任務整理 |
| 部分完成 | 顯示缺少的欄位 | 判斷是否重跑 |
| 執行失敗 | 顯示錯誤與發生時間 | 查排程、權限或外部服務 |
| 尚未判讀 | 顯示材料已到但未分類 | 指派內容或研究角色 |
| 條件改變 | 顯示新舊範圍差異 | 分組，不直接接成趨勢 |
dashboard 若會讀取網站資料，也記錄來源取得方式和限制。Google 的 AI features 文件提醒，頁面需符合一般搜尋的可抓取和索引資格，顯示仍由系統決定——所以「工具成功取得網頁」和「AI 回答引用網頁」是兩個欄位，不是同一件事的兩種說法。Google AI features 官方說明
政策欄位也值得留查閱日期。Google 官方更新指出 FAQ rich result 從 2026 年 5 月 7 日起不再顯示，並澄清 llms.txt 不需用於 Google Search，也不影響 Search 可見度。這不表示這些檔案不能被團隊管理，而是 dashboard 別把「檔案存在」寫成「Google 採用」——技術狀態和搜尋呈現分列兩欄。Google Search 文件更新
從摘要回到證據的閱讀順序
建議 dashboard 由上到下分三層：
- 範圍摘要：日期、市場、語言、引擎、題目集合和狀態分布。
- 指標摘要：有明確分母的提及率、引用率或題目完成率，旁邊標明計數單位。
- 證據清單：題目、回答摘要、引用 URL、人工判讀、責任人和下一步。
閱讀者先看範圍，再看指標，最後抽查原始回答。從第三層發現某一筆引用和摘要對不上時，回頭修人工分類——而不是直接調整總分。這個順序也是把錯誤留在原地的方法。
這種閱讀順序還能支持交接。內容角色關心描述要不要補充，SEO 角色關心頁面與內部連結，工程角色關心抓取和資料流程，產品或品牌角色關心事實正確性。四個人看的是同一筆證據，下一步各自不同。
如果你正在建立 Day 0 起點，可以先讀 GEO baseline workflow。正在採購工具的話，把本篇欄位放回採購核對清單——先評估工具提不提供證據，再看 GEO 工具評估框架。
常見問題
AI 搜尋監測 dashboard 最重要的是哪一張圖？
先確認範圍、分母、資料狀態和回查路徑，再決定用表格、趨勢還是分布圖——哪張圖最重要，答案會隨團隊而變。圖表若說明不了資料單位，少畫一張通常比留一個模糊的總分安全。
可以把品牌提及率命名成 SOV 嗎？
除非同時寫清楚比較集合、題目單位、競品、引擎、分母和判定規則。單一品牌在有效回答中的出現比例，先叫「題目單位提及率」——叫它 SOV，讀者會以為那是市場份額。
Search Console 的 Generative AI performance report 可以和工具數字放在一起嗎？
可以並列，並標記資料來源和適用產品。直接合併計算則不行：Search Console 報告與跨引擎回答觀測的單位、資料範圍和可回查材料都不一樣。
沒有原始回答，只剩摘要，dashboard 還能用嗎？
可以當暫時線索，並清楚標記材料限制和取得日期。缺了原始回答，人工分類的可重現性就低了——三個月後有人問「這一筆為什麼標成提及」，沒有人答得出來。
Otlex dashboard 一定包含本文所有欄位嗎？
不能從文章或產品名稱推導。Otlex 是 EthorX 的 AI 搜尋優化平台，公開定位包含多個 AI 引擎的提及、引用與推薦觀測；實際方案、欄位、保存與匯出要依當下產品說明和採購核對確認。EthorX GEO 工具頁
結語
AI 搜尋監測 dashboard 的品質，取決於讀者知不知道每個數字的範圍、單位、資料來源和限制。先建立最小資料模型，再把提及率、引用率和狀態分開，最後保留回到回答與 URL 的路徑——儀表板就會服務判斷，而不是用視覺蓋住資料缺口。若需要討論實際觀測範圍，可到 EthorX 聯絡頁提供需求，正式欄位與交付以核對後內容為準。
要把欄位放進實際產品情境，可先讀 Otlex 產品頁；GEO 專案範圍仍可從 GEO 服務頁 討論。
查證邊界
本文查證日期為 2026-09-21。Google AI features 文件支持可抓取、索引資格和 AI 顯示的邊界；Google AI optimization guide 支持 Search Console 有 Generative AI performance report 的官方脈絡；Search 更新頁支持 FAQ rich result 與 llms.txt 的當前狀態。這些官方文件不支持第三方 dashboard 的欄位完整性、工具有效性或通用 SOV 公式。文中的 40 筆、12 筆與 62／58 分都是說明用的假設數字。本文的資料模型、分母和回查順序是編輯方法建議；Otlex 畫面是示範帳戶資料，不代表客戶成果，也不單獨證明效益。
參考來源
- Google Search Central：AI features and your website（支持 AI 顯示與索引邊界）
- Google Search Central：Optimizing your website for generative AI features（支持 Search Console 生成式 AI performance report 的官方脈絡）
- Google Search Central：Latest documentation updates（支持 FAQ rich result 與 llms.txt 現況）
- EthorX：GEO 工具類別頁（僅作產品公開定位來源，不替 dashboard 欄位或工具有效性背書）