為甚麼只靠 Google Search Console 的報表是不夠的呢?
所以基於上面所說的四個因素,最後就做成 KPI 總表,且從原本不到 10 個項目,現在已經有一百個上下的項目,其中也會依網站的性質有所差異,如在中間頁的認定,次頻道的認定上都不可能一樣。
有些數字當然是越高越好,例如是流量,網頁收錄數,連結數,檢索數等等的;但有些數字是越低越好,甚至最好是『零』,例如錯誤數、警告數、不良數等等;而有些數字並不絕對一定是壞事,例如網頁排除數及其很多項目,有些是合理的。
但與其說是高或低,重點是要去了解每一個項目為甚麼會變高,為甚麼會變低,如何讓這數字變高或是變低,這是透過 KPI 總表最須要去了解的事,而在 KPI 操作上,不可能有資源去操作這些所有項目,因此要去挑出來最重要的項目,在之前會先標示出要去注意的事項。
最早的時候,高低標示是以與前一次做比較,超過 5% 才算高低,而變好則將字的顏色變成綠色,變差則變成紅色,而超過 10% 時會加上黃底。
但有些數字變化太過激烈,幾乎每次都有 10% 以上的漲跌,最後這樣的標示就變成是 Noise,沒有太大意義,因此後來是以是歷史新高才變紅綠色,而黃底是須要警示或檢查的數字。
而在這張表做很久之後,用歷史的新高新低時反而讓該有的訊號沒出來,所以將歷史極值改成一個半年的移動區間,這半年來的最高最低值再來變色,避免該注意沒注意。
只是有時還是會發現有些數字雖然沒有因為是極值而須要變色,但還是要去檢查或注意時,會在那欄數字加上灰底,讓最後再做檢查確認時可以注意到,而不會忽略。
SEO KPI 總表範例而在做表的時候有幾個須要討論的事:
在之前的角度,多久做一次表是以『開工作單且能完成的能力』去做區分,若是能夠每週開單,就應該每週填表,而在我擔任的顧問公司很容易是我去公司的間隔,我有些公司是每週都會去,因此就變成每週建表,但也有是一個月去兩次的,也有少數一個月去一次的,往往會是用這週期建表。
在 Google Search Console 的數值中,有的可以去拉時間區間統計,有些只能看到當下的數字,而有時間區間可以去選擇的話,最直覺的方式就是依製表的週期去拉,這樣可以有完整的覆蓋率,而沒有損失資料,也就是每週去的話就用七天週期製表,一個月檢討一次的就拉 28 天,雖然這 28 天會損失個兩三天資訊,但影響不大。
這大概是在去年之前製表時的原則,但在今年時又不一樣了,現在變成:
無論多久檢討一次,都以每週製表為原則,因此時間區間也是用 7 天為單位。
只是有時為了製表的延續性,對於去年之前就開始製表的公司與單位,還是延用舊方式,但新的公司或新的單位就用新的方式,也就是週期密度較高的方式。
最主要是發現 28 天的計算週期對資訊變化的敏感度太低了,往往當事情開始發生時報表還沒有發生極值的變化,這樣使得該有的訊號無法即時出現,錯失解決的時機。
但還是有一個數字是用 90 天的,就是『檢索統計報表』相關的資訊,因為這個報表固定週期是 90 天,無法調整,因此就只好記錄 90 天的平均數字;而也因為常常會發生數字反應不及的現像,最後也只好加記最近一天的數字做為參考;也曾有一陣子沒去記錄最後一天的數字,發現還是有問題只好先記錄,而不列為紅綠色的警示項目。
有一間公司很認真的把檢索統計報表的數字下載下來,然後平均七天的數字填上,這可能是最好的方式,因為這樣才能夠讓報表的週期保持一致。
雖然這些數字是 KPI,代表的是常常會有所變化,但『連結數』的更新週期常是 3~5 天才會變化,甚至有時或超過 7 天才輪到這個網站數字的更新,因此會發生最近兩週的數字一模一樣的狀況,這也就沒辦法了。
而 Core Web Vitals 是從 CrUX 過來的資料,也有自己的更新週期,甚至須要去按下要求檢查後才會更新,這個就不討論了。