四分鐘建立服務帳戶。首次同步就能回填十六個月的 Search Console 歷史紀錄。已驗證且已授權的網域只要兩秒。而兩個月——這個數字造成的支援單比其他三個加起來還多，因為那是 GA4 預設的資料保留期限，而幾乎沒有人知道在連接前要先檢查這一點。
設定本身很簡短：在 設定 → Google 帳戶填入一組憑證，在網域管理按兩個連接按鈕，之後你大概就會忘了這個頁面的存在。但兩個月這個數字值得完整說明一下，因為它解釋了為什麼有些網域第一天就顯示豐富實用的 Analytics 歷史，有些卻幾週幾乎什麼都看不到——而且這種情況發生時，並不是平台的錯誤。
一組憑證，授權一次
你上傳一組 Google 服務帳戶金鑰——一個 JSON 檔案，而不是個人登入資訊。這是機器人身分，不是會過期或因有人變更密碼而失效的人類 OAuth 權杖。Google Cloud 只核發一次，之後就會持續運作直到你刪除它，這也是為什麼平台能在凌晨三點無人登入時自動同步。
如果你從未做過，建立一組大約要花那四分鐘：新建或使用現有專案，前往「IAM 與管理」→「服務帳戶」→「建立」，下載金鑰。權限比下拉選單看起來的還重要——在 Search Console 資源和 Analytics 資源上授予檢視者權限，不要更高。我看過有團隊因為「編輯者」是排在最上面的選項就直接授予，六個月後沒人能解釋為什麼一個機器人帳戶擁有 GA4 設定的寫入權限。唯讀才是正確做法；平台從不會去動你的設定。
一把金鑰能涵蓋該 Google Cloud 專案下的所有網域。如果你是經營十幾個客戶網站的代理商，這意味著最好每個客戶用一組獨立的服務帳戶，而不是全部共用一組——這樣結束與某客戶的合作時，只需刪除一把金鑰，而不必去審查哪些網域悄悄與剛離職的人共用了憑證。
Search Console：快的時候很快，卡住的時候很惱人
- 在網域上打開連接。Search Console 和 Analytics 各自有一張卡片，Analytics 有「與 Search Console 相同」的捷徑，因為通常一把金鑰就能同時涵蓋兩者。
- 如果已經驗證，且你的服務帳戶已被授予存取權？瞬間完成——一次權限檢查，大約兩秒就搞定。
- 尚未驗證的話：如果你提供網域註冊商的 API 金鑰（Cloudflare、Route 53 或其他少數幾家），可以自動化 DNS 驗證；否則就是自行新增一筆手動 TXT 記錄。
手動路徑是最容易讓人不耐煩的地方。傳播時間真的會因狀況而異——這次九十秒，下次可能要四小時，取決於 TTL 和解析器快取。平台會持續輪詢，所以你新增記錄後就可以先去忙別的。如果過了一整天還沒驗證成功，通常不是傳播延遲的問題，而是記錄值打錯，或記錄放到了錯誤的區域（例如放在根網域而不是子網域，或反過來）。在怪罪 Google 之前，先用 `dig TXT` 查一下實際生效的內容。
API 金鑰路徑會幫你自動寫入記錄，省去這些麻煩，但代價是要把 DNS 的寫入權限交給第三方工具——如果這個 DNS 承載的是正式環境流量，我認為猶豫是很合理的。手動路徑前期多花幾分鐘，換來的是之後再也不用煩惱這件事。
Analytics，以及沒人事先警告你的保留期限落差
Analytics 是透過「自動探索」而非「驗證」來連接的——平台會尋找該網域上既有的 GA4 資源，只要你的服務帳戶有存取權就會連接，因為 GA4 的權限本來就是由 Google 那端把關的。如果沒有既有資源，平台可以幫你建立一個新的，但只有真正的全新網站才適合讓它這麼做。如果你是從 Universal Analytics 遷移過來，或已經有一個累積多年歷史資料的資源，就要明確連接到那一個。一個只有三天資料的全新資源，起點會比一個已經累積九年、內建季節性模式的資源差得多，而優化循環對這段歷史資料的依賴程度，遠比連接流程呈現出來的更高。
這裡就是容易讓人踩雷的落差：Search Console 首次同步時最多能回填十六個月的查詢資料，因為 Google 在伺服器端本來就保留了這麼長的歷史，與你何時連接無關。GA4 沒有類似的保證——它的回填量會受限於該資源本身的資料保留設定，而這個設定除非有人在你的組織裡改過，否則預設就是兩個月。所以同一個網域、同一天、同一個設定流程，可能一連接就顯示十六個月的曝光和點擊資料，卻只有兩個月的工作階段資料。這不是同步失敗，而是 Google 的預設保留期限本來就是這樣運作的。如果你想讓之後的保留期限拉長，解法是直接到 GA4 資源設定裡調整保留期限，而不是這個平台這邊的任何設定。連接前先檢查這一點，會比連接後才對數字不一致感到困惑要好得多。
共用資源，以及連接之後會發生什麼
還有一個 Analytics 的小狀況：如果你的組織用單一 GA4 資源收集五個網站的資料——這在有人多年前設好追蹤、之後沒人拆分的情況下很常見——連接仍然可以正常運作，但每一個查詢在背後都會依主機名稱自動篩選。這不是一個核取方塊，也不是能被不小心關掉的東西。這也是為什麼儀表板顯示的永遠是這個網域自己的數字，而不是整個資源的合計總數。
兩個連接都完成後，同步就會依你設定的排程每天執行（參見排程章節），任何在平台上建構的專案，其商店分析資料也會自動合併。網域列會顯示「待處理」、「部分完成」或「已啟用」——「部分完成」代表兩個連接中有一個已上線、另一個還沒，這時你該做的是去查是哪張卡片顯示紅色，而不是只看總體狀態就以為沒事。
實際上容易出狀況的地方
我看過的問題單幾乎都落在三種情況裡，沒有一種很罕見。第一：服務帳戶金鑰有效，但範圍設在錯誤的 Google Cloud 專案下，所以權限檢查會回傳空結果，即使金鑰本身能正常上傳。第二：沒有人真的把服務帳戶的電子郵件——像是 [email protected] ——加進 Search Console 或 GA4 自己的存取設定裡當作檢視者；把金鑰上傳到平台並不會在 Google 那端自動授予任何權限。第三，更隱蔽的情況：某個網域在舊服務帳戶被刪除後改用新的服務帳戶重新連接，但排程卻悄悄用過期的憑證持續失敗一整週，直到有人才發現數字停止更新了。
以上這些都不是平台的錯誤——這只是一個機器人需要在兩個獨立的 Google 產品上取得授權的日常成本，而 Google 自己的模式並沒有把這件事講清楚。第一個網域請預留十五分鐘，而不是流程看起來暗示的兩分鐘。之後的每一個網域都會很快，因為憑證和操作經驗都能沿用。
