AO2 GUIDE 29 · 搜尋與量測
GA4 與 Search Console 使用不同指標與觀察範圍。從資料定義、日期、篩選及使用者行為核對差異，避免直接把點擊與工作階段相比。
這篇提供企業團隊核對資料差異的工作方法，從定義、日期、範圍、網址到追蹤狀態逐步排查。文中的數字與情境是說明示例，不是特定網站的量測結果。
GA4 與 Search Console：先分清楚搜尋點擊、使用者與工作階段
Google 的 Search Console 文件把搜尋點擊描述為從搜尋結果點向網站的行為，GA4 則以自己的方式記錄使用者與工作階段。工作階段是一段網站或應用互動期間，不能直接當成一次搜尋點擊，也不等於一位新的潛在客戶。
同一個人可能有不同時間的互動，也可能多次看到或點擊搜尋結果。這些行為在兩個系統中的組織方式不同。報表應先寫出指標名稱與定義，不要只因為欄位都叫流量，就把它們當成相同單位。
若需要理解各指標用途，可以分別參考 Search Console 工作指南 與 GA4 企業量測指南。先建立共同語言，再討論差異是否值得追查，能減少跨部門誤會。
不同不一定是故障，突然改變才更需要縮小範圍
兩邊長期有穩定差異，可能與定義、範圍或實作有關；某一天突然擴大，則需要回查當時是否有部署、標記、網站或篩選改動。兩種情況的處理順序不同，不應每次都從重裝工具開始。
可以先保存一段正常觀察期間，再與異常期間比較。不要只取一天或幾個點擊的比例，就宣稱大量流失。資料量小時，少數行為就可能造成明顯百分比變化，需要保留判斷限制。
例如假設某份報表有一百次搜尋點擊、另一份有八十個工作階段，不能直接把差額當成二十位客戶離開。這只是算術示例，真正原因仍需核對定義、範圍與追蹤，不能把不同單位直接相減當成商業結論。
第一層核對：日期、資源與搜尋範圍
先確認選的是正確網站資源與 GA4 資料來源，再檢查日期、時區與報表更新狀態。比較期間應盡量完整一致，避免一邊包含尚未完成的當日資料，另一邊則使用已整理期間，最後誤判變化。
也要確認 Search Console 的搜尋類型與網站端來源篩選。某個報表可能只看 Google 搜尋，另一個卻包含其他自然來源；某一側只看手機，另一側則是全部裝置。這些差異應先排除，才有辦法討論更深的實作問題。
| 核對層次 | 要確認的項目 | 建議留下的紀錄 |
|---|---|---|
| 觀察期間 | 日期、時區與資料狀態 | 起訖與匯出時間 |
| 資源範圍 | 網站、資料來源與搜尋類型 | 資源與篩選條件 |
| 頁面範圍 | 路徑、參數與版本 | 對照網址清單 |
| 行為定義 | 點擊、工作階段與事件 | 指標與成功條件 |
這張表可以作為共同檢查底稿，讓不同人用相同條件重現觀察。如果基本範圍仍不一致，就先修正對照方式，不必急著為差額找一個技術原因。
第二層核對：網址是否真的對應同一份內容
網站可能有參數、大小寫、重新導向、不同語言與標準網址等情況。兩邊資料若使用不同網址組織方式，表面上可能像少了一部分流量。請先選少數重要頁面，確認它們的公開位置與實際到達路徑。
例如舊網址會轉到新頁，報表中的路徑又可能保留不同形式，就需要建立對照。不要只用一個完全相同字串篩選，然後認定其他資料不存在。也不能為了讓數字對齊，把不同產品或市場全部合併成一組。
若最近做過改版，可依 網站移轉指南 回查舊新網址與量測。涉及篩選與相近內容時，則參考 商品篩選與標準網址，先分清內容關係再整理數據。
第三層核對：追蹤是否在重要模板正常運作
網站端需要適合的量測實作，才能記錄相關互動。請由網站或分析負責人依設定檢查重要模板，而不是只確認首頁有標記。產品、文章、表單與不同語言頁面，可能使用不同模板或載入方式。
也要回查是否有重複標記、部署遺漏或近期工具調整。若某一模板的資料在改版後突然不同，先選代表頁驗證，不需要同時修改全站。每一項測試都保留預期行為、實際結果與負責人，避免只剩口頭說正常。
資料處理與使用者選擇也應依企業規則及工具安排確認，不能為了讓兩邊數字接近，就任意放寬原本的設定。量測的目的，是在適合範圍內支持判斷，而不是不計代價地補齊每一筆紀錄。
一次驗證一個假設，避免邊查邊改到失去依據
把可能原因寫成待驗證項目，例如日期不一致、頁面對照不完整，或某模板沒有正常記錄。每次選一項，用清楚方法確認，再保留結果。不要同時改篩選、網址與標記，最後即使數字接近，也不知道哪一項真的影響觀察。
可以使用受控的測試任務，確認頁面載入與必要事件是否出現，並依團隊安排辨認測試資料。這類驗證支持實作判斷，但不應被當成完整模擬所有真實使用者。測試環境與正式環境也要分清楚。
若某個原因仍無法確認，就標記未知與下一步所需資料，不必強行下結論。資料核對應讓不確定性逐步縮小，而不是把一份看起來完整的報告，建立在無法重現的猜測上。
搜尋成效與網站使用，可以並讀而不必強迫相等
Search Console 可以幫忙找出相關查詢與進站頁面，GA4 則觀察網站中的行為。兩邊可以一起支持內容改善，但各自回答不同問題。先用搜尋線索定位頁面，再用站內行為與實際詢問核對讀者是否完成任務。
例如某產品頁的相關查詢增加，網站端卻很少有人找到文件，就應檢查內容與入口，而不是先要求兩個總數完全一致。若有效詢問品質不佳，也要回到產品承諾與表單，不能只用更多點擊解決所有問題。
內容改善可參考 B2B SEO 規劃，產品與下一步則依 站內連結指南 整理。量測應幫團隊找到值得修正的地方，而不是讓工具比較本身成為唯一工作。
有效詢問需要另一層定義與業務回饋
按下表單按鈕、成功建立需求、業務確認適配與後續成交，是不同階段。若網站事件定義不清楚，就算搜尋與工作階段看起來接近，也無法確認商業成果。請先核對成功狀態與實際接收紀錄。
表單設計可依 詢問表單指南 確認，後續分派與回寫則參考 CRM 交接流程。不同團隊應使用清楚的狀態，不要把網站成功送出直接當成業務已完成評估。
報告也要區分自訂的內部指標與平台原生定義。若企業建立有效需求率，就寫出分子、分母與判斷方式；不能讓同一個名稱在不同月份代表不同工作，卻仍直接排列成成長趨勢。
報告先寫可確認的事，再列假設與工作
可以分成已確認、待驗證與建議處理三部分。例如已確認日期一致、待驗證某模板部署、建議抽查代表頁。這樣主管與維護者能知道目前掌握到哪裡，也比較容易安排下一步，而不是只看到「數據不準」四個字。
每項發現附上範圍、條件與紀錄，避免過度曝光不必要的聯絡資料。對外使用時也應確認公開範圍。分析工具與業務內容有不同用途，報告不需要把完整客戶詢問一起攤開，才能說明量測問題。
當差異仍在合理解釋範圍內，可以保留兩種觀察，讓它們各自支持決策。若需要估計資源與結果，則依 SEO 情境預估 把假設拆開，不把缺少的資料補成確定轉換。
為後續改版留下量測檢查基準
保存重要頁面、事件定義、篩選條件與代表測試，讓網站更新時有固定回查方式。模板、表單與工具改動，都應確認是否影響原本資料。這比每次數字不同才重新追問當初怎麼設定，更容易維護。
也可以指定資料與網站負責人，處理定義變更與交接。若某個指標修正了計算範圍，請在報告標明，不把新舊定義直接比較。穩定的量測不是永遠沒有差異，而是差異能被追溯與合理解讀。
需要把內容、網站與量測一起整理時，可了解 SEO／GEO 整合服務。好的核對結果，應讓企業更清楚自己知道什麼、還缺什麼，以及接著該改善哪一個任務。
常見問題
兩邊數字不同，哪個才是真實流量？
兩者描述不同階段。Search Console 的搜尋點擊用來理解搜尋結果端，GA4 的工作階段和事件則描述網站可量到的互動；不要選一個數字取代所有問題。先對齊日期、時區、資源、網址與搜尋來源範圍，再檢查追蹤部署和同意安排。報告明示各指標用途，若差異突然擴大，再查特定模板、裝置或變更，不把不相同本身當成錯誤。
差額可以直接當成網站流失嗎？
不能直接相減。點擊和工作階段不是同一統計單位，日期、歸屬網址、追蹤與同意範圍也可能不同。先寫出比較口徑，逐項核對差異，並用可辨認測試確認網站是否收到訪問及事件。若要研究真實流失，需使用同一套旅程與事件定義，而不是把兩個工具的總數差額稱為獨立訪客或商機。算術正確不代表推論成立。
只要把兩邊數字調到接近，就算完成嗎？
不是。目標是定義正確、部署可驗證、差異能解釋，而非把總數調成相等。保存日期、篩選、指標和網址規則，檢查代表模板與重要流程；修改後用相同範圍重算。若只改篩選讓數字接近，應說明新口徑而不能當成修復成果。實際詢問與業務結果另有確認責任，不因兩個流量報表對上就視為商務流程正常。
參考資料
本文為 AO2 獨立編寫的企業實作指南。工作情境與清單為方法示例；平台功能與技術規範請以所列官方文件為準。
