AI Share of Voice 怎麼算？先固定 brand event 分母

AI Share of Voice 的算法，本文採用一個講得明白的工作定義：在同一批有效回答裡，每個候選品牌每個回答最多計一個 brand event，某品牌的 SOV 就是它的 brand events 除以所有候選品牌 brand events 的總數。這適用於候選品牌、題庫與引擎都先固定下來的觀測；品牌集合中途變動，前後兩輪就要用共同子集重算，別直接並排。本文提供的是可以照著建表的東西：四個指標的分母對照、四條公式、一組可以手算驗證的合成資料，以及報表要先列出哪幾個分母。

最常搞混的地方，用班上養寵物就講得完。「全班 30 個人裡，有 6 個人養狗」——分母是人。「全班養的 15 隻寵物裡，狗占 6 隻」——分母是寵物。兩句話都對，數字不一樣（6/30 和 6/15），回答的也是不同問題。

放回 AI 觀測：前者是 mention rate，後者才是本文說的 SOV。兩個數字擠進同一欄、共用一個名字，是這個指標最常出事的地方。所以先把題庫、候選品牌、引擎、地區、時間和去重規則固定，後面的比例才有機會重算、也才有機會比較。

SOV 的品牌事件分母與 mention rate 的有效回答分母應分開記錄。

AI Share of Voice 怎麼算：先決定比較層級

SOV 要回答的問題是：「在指定的觀測範圍內，候選品牌各自取得了多少 brand events？」AI 回答的麻煩在於，一個回答可能同時提到三個候選品牌，也可能一個都沒提。為了讓比較單位固定，本文只把下面這個事件份額稱為 SOV：

SOV(品牌 A)
= 品牌 A 的 brand events
  ÷ 同一批有效回答中所有候選品牌的 brand events 總數

每個候選品牌在單一有效回答中最多計一個 event。一個人喊三次「我投他」還是一票；品牌名稱在同一個回答裡出現三次，也還是一個 event。回答裡沒有候選品牌時，不製造任何 event。

這個工作定義要和 品牌提及與引用 FAQ一致，把回答事件與來源事件分開保存。它是本文採用的口徑，不是所有 AI 平台共同公布的標準。

其他比例要用自己的名字保存：

這張表的用途，是讓報表不會把「品牌出現在幾個回答」和「候選品牌事件中占多少」擠進同一欄。團隊若另外採用回答層的自訂 SOV，就在名稱裡明寫自訂口徑，跟本文主定義分開放。

資料表：題庫、品牌集合與有效回答

題庫先固定比較範圍

一組題庫要有版本、意圖和市場條件。認知題、比較題和決策題分層計算，因為它們要求的東西不一樣——把品牌直問和非品牌類別題混成一個總分，品牌集合的解釋就沒有脈絡可循了。

題庫欄位至少包括：

prompt_set_version   題庫版本
prompt_id            題目編號
intent               認知／比較／決策
market               市場
language             語言
region               地區
engine               引擎
observed_at          觀測時間
answer_status        有效／空／錯誤／被阻擋
raw_answer_ref       回答原文位置

以上是資料結構示例，不是任何實際觀測結果。intent 要在執行前定義好；等執行完再替每題貼標，很容易照著回答內容反過來調整分組，那樣分層就失去意義了。

有效回答和已執行事件分開

發出 30 份問卷、回收 27 份，那 3 份沒回收的不能算成「他們不支持」。

觀測也一樣。假設題庫有 30 題、實際執行 30 次，其中 27 次拿到可讀回答、3 次發生錯誤。口徑若是回答提及占比，分母通常是 27 個有效回答；那 3 個錯誤留在資料品質欄位。專案另要求以已執行數計算 operational rate 也可以，名稱和回答提及率分開就好。

品牌集合要先寫清楚

民調開始前要先決定選票上有哪些候選人。品牌集合也是，而且有三種決定方式：

看到結果之後才改品牌集合，前後 SOV 的分母與分子都會被回溯改寫，那兩輪就沒得比了。品牌別名、母子產品與同名普通詞也要有字典版本和人工覆核狀態——同一個人有本名、綽號和英文名，統計之前得先歸戶。

公式：提及、來源與推薦各自怎麼計

公式一：先算 mention rate，別和 SOV 混稱

在指定題庫、引擎、期間與意圖組中，品牌 A 的 mention rate 是：

mention rate(品牌 A)
= 提到品牌 A 的有效回答數 ÷ 有效執行數

它回答「有多少有效回答提到 A」。一個回答裡 A 出現三次，回答層仍只算一次。這個比例可以和其他品牌並列，但本文不叫它 SOV——它的分母是回答數，不是候選品牌事件總數。

公式二：本文的 SOV 是 brand events 份額

本文的主公式是：

SOV(品牌 A)
= 品牌 A 的去重 brand events
  ÷ 同一批有效回答中所有候選品牌的去重 brand events

用 10 個有效回答做合成示例。候選集合預先固定為 A、B、C，每個回答每個品牌最多一筆：

這十筆是合成示例，只用來驗證「每回答每品牌去重」和兩種分母的計數邏輯，不是平台、客戶或內容成效觀測。

算出來：事件數 A=6、B=5、C=4，候選品牌事件共 15 筆，所以 SOV 是 A=6/15、B=5/15、C=4/15。mention rate 則是 A=6/10、B=5/10、C=4/10。

注意 q10：它沒有任何候選品牌，所以進不了 SOV 的分母，卻仍然留在 mention rate 的有效回答分母裡。這個示例刻意讓兩個分母不一樣（15 和 10），就是為了讓計數邏輯自己說話。

公式三：來源引用占比另算

回答層的自有來源占比可以寫成：

自有來源回答占比
= 至少含有一個自有網域來源的有效回答數 ÷ 有效回答數

要比較不同品牌網域在所有可見來源中的份額，改用來源層：

來源事件份額(網域 A)
= 網域 A 的去重來源事件數 ÷ 所有去重來源事件數

兩個公式都能用，前提是報告明寫這是「回答層」還是「來源層」。一個回答有三個來源、其中兩個屬於同一網域時，來源層的去重規則要先決定；回答層比例和來源層比例則別放進同一欄。

公式四：推薦事件份額與決策題推薦回答率分開

推薦指標只能放在已定義選擇情境的題目裡。先把回答標成 recommendation_yes、no 或 needs_review，把推薦判讀保存成候選品牌事件，再分開計算事件層和回答層：

推薦事件份額(品牌 A)
= 品牌 A 的 recommendation_yes brand events
  ÷ 所有候選品牌的 recommendation_yes brand events

決策題推薦回答率(品牌 A)
= 品牌 A 在 recommendation_yes 的可判讀決策回答數
  ÷ 可判讀決策回答數

推薦事件份額允許同一回答有多個候選品牌事件，同一回答內同一品牌仍只計一次；推薦回答率則以可判讀決策回答為分母。needs_review 另列一欄。

判讀時最容易出錯的，是品牌被列在清單第一個就標成 yes。位置靠前跟回答有沒有替它背書是兩件事——清單、比較段落或背景說明裡出現，都還停在提及。推薦判讀可先看 AI 是否能保證品牌推薦；本文只規定 SOV 與推薦事件如何保存分母。

實作：建立可重查的 SOV 報表

第一步，先做題庫與品牌字典

把題目、意圖、條件、品牌正名、別名、排除詞和字典版本分開保存。普通詞和品牌同名時，保留上下文與人工判定。

產品名、公司名和服務名之間就算有關係，沒有規則以前也別自動合併。合併規則沒寫清楚，品牌事件會憑空膨脹——同一個回答提到公司和產品，被算成兩筆。

第二步，保存回答層與來源層

回答層記錄 answer_id、題目、引擎、日期、有效狀態、品牌事件和推薦狀態；來源層記錄來源顯示值、URL、網域、回答位置、取得狀態和正規化狀態。來源 URL 怎麼清理與分群，可先看已發布的 Citation Tracking。

第三步，計算前先列分母

報表先顯示：已執行數、有效回答數、錯誤或空結果數、品牌集合版本、題庫版本、觀測日期和引擎，然後才放提及、引用或推薦的分子。

任何一欄的分母不一樣，就在表頭直接寫出來。把它藏在註腳裡，讀者多半不會往下看，那個百分比就被當成同一把尺在用了。

第四步，按題型和引擎分層

至少按意圖、引擎或模式、語言地區分組。Google AI Overviews 和 AI Mode 的官方文件指出兩者可能使用不同模型與技術，回答及連結集合會變動，所以跨引擎並列時要把這些條件留在圖例或表格裡。

跨層級比較可以當探索。至於「某引擎占有多少 AI 回答市場」，那是三家不同民調公司、不同抽樣方式的數字加總成全國民調——加得出來，但不能用。

第五步，保留公式與原始事件

報告裡每個比例旁邊，都要找得到公式版本、分子清單和分母清單。品牌字典、題庫或 rubric 改變時，產生新報告版本，舊版本留著。

數字掉下來未必是內容出問題，也可能是資料取得或分類規則變了。先回事件表找差異，再談內容。

比較：跨引擎和跨期間怎麼解讀

同一個題庫的前後比較

題庫版本、品牌字典、引擎模式、語言、地區、判讀規則和有效回答規則都相同時，可以把兩次的 SOV 事件份額並列，再逐一讀每個回答的新增、消失和來源替換。mention rate 可以擺成另一欄，但別和 SOV 畫進同一條趨勢線。

內容版本要另外記錄。題目版本改了卻沒記，後面很容易把「題目換了」寫成「內容有效果」。

不同引擎的並列

跨引擎報表可以展示每個引擎在同一組題目下的事件數，同時要說明引擎的回答格式與來源介面不同。並列的回答提及占比描述的是各自觀測條件下的品牌出現情形，合起來變成跨引擎共同市場份額，中間少了好幾層假設。

不同品牌集合的比較

第一輪追蹤三個品牌、第二輪擴大到八個，這時先用共同集合重算一個可比子集，再另外展示新增的品牌。

道理和選舉一樣：本來三個人角逐，變成八個人角逐，得票率當然會降，支持者未必變少。不重算就並排，讀者會以為原有品牌的回答變少了。

限制：SOV 說得到哪裡為止

AI SOV 是題庫和事件定義下的觀測比例。它和銷售額、市占率、自然搜尋排名、流量或轉換率屬於不同的東西，中間沒有可以直接換算的關係。Google Search Central 現行指南提供 Search Console 的 Generative AI performance report，用來了解內容如何透過 Google 生成式 AI 功能被發現；那份報告和自建的逐題 SOV 事件表也是不同資料層。

Google AI features 文件提醒，AI Overviews 與 AI Mode 使用的模型和技術可能不同，回答和連結集合會變動，頁面符合條件仍可能遇到抓取、索引或提供上的差異。OpenAI ChatGPT Search 說明也提醒 citations 可能不完整、過時或錯誤。這些官方邊界的意思是：SOV 報告一定要帶著時間、引擎、模式和來源條件一起讀，一次比例說明的是那一次的觀測。

Otlex 是 EthorX（伊索斯科技有限公司）開發的 AI 搜尋優化平台，觀測 ChatGPT、Google AI Overview、Google AI Mode、Gemini、Grok、Perplexity、Claude 等七個 AI 引擎回答中的提及、引用與推薦，可以協助整理題庫、事件與內容缺口。本文的 SOV 公式仍要由專案先決定計數單位和分母。

相關概念與產品連結

要先拆開回答、提及、引用和推薦的指標，可以讀已發布的 AI 可見度量測方法；要設計題型和條件，可以讀 AI 監測 prompt 選擇 FAQ。若你準備持續重跑，接著看 ChatGPT 品牌監測。

Otlex 的產品範圍是觀測七個 AI 引擎回答中的提及、引用與推薦，並把觀測結果連回內容缺口與後續優化。若需要釐清題庫、分母、引擎和報告層級，可從 EthorX GEO 服務了解服務範圍，再依專案資料條件評估。

常見問題

查證邊界

本文外部文件查閱日期為 2026-09-21，使用 Google Search Central 的 AI features、生成式 AI 搜尋指南，以及 OpenAI ChatGPT Search 說明。SOV 層級、公式、品牌集合和分母是本文提出的方法，不是 AI 平台共同公布的標準；品牌提及占比不能擴張成市場占有率。文中的 10 筆回答、30 題、27 次有效與班級、問卷、民調等情境都是合成或假設案例，不是實測結果。本文沒有使用未授權的競爭資料、客戶觀測比例或單次回答推出市場結論。

參考來源

• Google Search Central：AI features and your website
• Google Search Central：Optimizing your website for generative AI features on Google Search
• OpenAI Help Center：Searching the web with ChatGPT
• EthorX：Otlex