這個儀表板是我們在這半部產品中建構出最不重要的一環。如果上線時程的壓力逼我必須砍掉一個部分才能準時發布其他所有東西，這就是我第一個會砍掉的——而我是每天都在看我們自家儀表板的人，說出這句話。
原因是這樣的。我看過同樣的模式重複太多次，已經可以預測：有人花六週打造出一個不錯的東西，週二上線，第一天檢查了 Analytics 十一次，隔天兩次，再隔天一次，然後就再也沒看過了。他們不是不在乎了。檢查很容易，行動很難——你得知道 Search Console 裡四十個查詢中哪些真正重要、4,000 次曝光中 2.1% 的點擊率算差還是對那個排名位置來說算正常，然後還得去打開自從上線週後就沒開過的 CMS 改寫一段 meta description。三個步驟，每一步的阻力都足以扼殺這個循環。儀表板解決不了這個問題。儀表板正是阻力所在之處。
每天會送來什麼資料，以及第一週你該相信多少
同步作業會從四個來源拉取資料，而它們在第一天的可信度並不相同。
| 來源 | 每日送達 | 轉化為 |
|---|---|---|
| Google Search Console | 每個頁面的查詢字詞、曝光次數、點擊次數、排名位置 | 有曝光但點擊率偏弱的頁面 → 重寫標題與描述 |
| Google Analytics | 每個主機名稱的工作階段、來源、使用者行為 | 吸引流量卻留不住使用者的到達頁面 → 內容與結構調整 |
| 應用程式商店 | 安裝量與上架資訊表現快照 | 商店表現與網站資料整合於同一個儀表板 |
| 你已發佈的貼文 | 發佈行銷草稿時記錄的網址 | 將推薦流量歸因於帶來成效的渠道 |
Search Console 是那個如果太早看就會誤導你的資料來源。Google 不會立即索引或排名一個新頁面——對全新的網域而言，可能要等兩到四週曝光數據才會出現，且第一個月的排名資料非常不穩定，因為 Google 還在判斷你的內容該歸屬在哪裡。正因如此，我們封鎖了智慧代理根據第一週的 Search Console 數字提出變更建議。一個只有三次曝光、零點擊的頁面，在統計上什麼都說明不了；根據這種數字重寫標題，只是多繞了幾步的瞎猜。Analytics 的資料能更快值得信賴，因為工作階段是有人造訪的那一刻就真實發生了，沒有爬蟲延遲的問題。
應用程式商店是大家最容易完全忘記的一項，不是因為這些資料不重要——而是因為它是不同的入口網站、不同的登入方式、不同的詞彙（他們的「曝光次數」比較接近「出現在搜尋結果中」，而不是「在頁面上顯示」），沒有人會主動想切換情境去看它。把它整合進同一個每日同步流程，代表上架轉換率的斷崖式下跌會和很可能導致它的網站流量下滑一起出現，而不是被晾在一個沒人記得要打開的 app 裡沒人讀。
那次教會我們不要相信快取篩選條件的網站屬性烏龍事件
有位使用者在同一個 Google Analytics 屬性下設定了兩個網站，這是他們加入平台前好幾年前就這樣設定的，為的是少管理一個屬性。約有一天時間，我們的儀表板把兩個網域的流量合併顯示，好像它們屬於同一個網站。工作階段數字看起來很不錯。跳出率看起來好到有點可疑，事後想想這其實應該就是破綻——因為那其實是兩個截然不同網站的平均值，而不是任何一個網站真正的數字。
解法是：每一次 Analytics 查詢都會針對即時請求套用主機名稱篩選，而不是根據連線時快取的設定值。屬性會被重新指派、子網域會被新增，過時的篩選條件比沒有篩選條件更糟，因為它會靜靜地失效，而不是明顯地出錯。我們特別測試共用屬性的情境——一個 GA4 屬性、二十個網域，驗證篩選後的總數是否與單一屬性的對照組相符——因為這個錯誤不會拋出任何錯誤訊息。它只會安靜地回報一則並不屬於你的好消息。
把數字轉化成決策，這才是真正的產品
儀表板本身，只是一種讓你感覺自己有掌握資訊、卻不需要因此採取任何行動的方式。價值出現在「看到數字」與「採取行動」之間的落差，而大多數個人專案的優化工作，就是死在這個落差裡。
Optimize 團隊的工作，就是彌合這個落差。我們自己有個網域裡的一個頁面，每週靠一組「自架分析工具設定」相關查詢帶來 1,800 次曝光，但點擊率只有 1.4%——遠低於一個排名 6-8 名的資訊型查詢通常會有的 3-5%。這個智慧代理不只是標記出這個問題，還提出了一個標題重寫方案，把使用者實際搜尋的痛點放進前 60 個字元內（也就是在搜尋結果頁面上不會被截斷的部分），並引用具體的查詢字詞與曝光數作為依據。套用之後，接下來兩週點擊率提升到 3.8%。這是一個真正頁面上的真正修正，而不只是一張圖表從紅轉綠。
這一切有多少是完全不需要你動手就能發生的，這是一個可調整的旋鈕，而不是一種固定的個性設定：
- 僅回報。 分析結果會以易讀的報告呈現，並附上證據。你可以選擇採取行動，也可以不採取。適合你特別謹慎看待的網域，或是你還想親自檢視推理過程的早期網域。
- 提案。 智慧代理會直接草擬實際的變更內容——真正的標題標籤、真正的段落——並等待你的確認。大多數人在使用一個月後，一旦這些提案已經贏得信任、但仍希望握有最終決定權時，就會停在這個階段。
- 全自動。 已核准的變更類型會被自動套用，一到兩週後再根據數字重新驗證。如果指標往錯誤方向移動，系統會自行回復，而不會讓一個更糟的頁面持續上線，等你哪天才注意到。
我們自己的網站對於 meta 與標題的變更採用全自動模式，但涉及頁面結構或新內容的變更則採用提案模式。標題錯了頂多兩秒鐘就能修正。但一次搞砸的內容改寫，可能會毀掉一個花了好幾個月才建立起來的排名，我寧願讓人在上線前發現問題，而不是上線後才發現。你的風險考量可能會落在不同的地方，這也很正常——一個佔了你全部收入的網域，理應比一個興趣型專案更謹慎對待，無論你有多信任自動化本身。
回復機制才是真正讓全自動模式站得住腳、而不是顯得魯莽的原因。一項變更上線後，平台會等待一段依指標而定的觀察期——例如對於低流量頁面的點擊率而言，這可能代表要等到累積幾百次曝光，而不是固定等幾天——然後比較前後差異。如果結果對你不利，系統就會回復並記錄原因。這其實是一個內建實驗機制的變更，說實話這比較接近一個謹慎的人本來就該有的優化方式；只是我們大多數人根本沒有那種耐心去等待和檢查。
批評者說對的地方
所以這裡是我的讓步。那些對全自動模式有疑慮的人，其實說得沒錯——可見性本身確實有其價值。搞不清楚自己網站上到底發生了什麼變化，是一種真實的代價，我自己也感受過。提案模式的存在，正是為了讓你永遠不會失去那條脈絡；它唯一的代價，是你要自己決定何時去讀報告，而不是決定何時套用變更。而儀表板，就算不是真正創造價值的地方，仍然是你會去查看的地方——去發現那個在凌晨三點悄悄觸發的回復動作，並問問為什麼會這樣。與其砍掉底層的同步流程，我寧可先砍掉它。但我不會把它砍到零，你也不該這麼做。
設定過程刻意做得很精簡，因為這裡的摩擦正是大多數上線後資料流程從未被建立起來的原因。在「我的網域」中連結 Search Console 與 Analytics——一個 Google 服務帳戶就能同時涵蓋兩者，只需一次 OAuth 授權，不用做兩次——每日同步就會開始把資料餵給智慧代理實際讀取的儀表板。透過平台的建置流程發佈的任何內容，商店分析資料都會自動附加。
