此專案從部署、測試到上線，總共約莫花了二~三週的時間，一開始，先聊聊為何要啟動此專案的緣由。
近期公司正式導入GA4後，當我們拉長時間進行自訂的探索（Explore）資料分析時，常常都會跳出一個討厭的「紅色驚嘆號提示」，它主要想告訴我們的就是，你的資料正在被大量的取樣中，總數與樣本數量的比率會影響資

職場產業

學習

音樂藝文

William Felker

此專案從部署、測試到上線，總共約莫花了二~三週的時間，一開始，先聊聊為何要啟動此專案的緣由。

近期公司正式導入GA4後，當我們拉長時間進行自訂的探索（Explore）資料分析時，常常都會跳出一個討厭的「紅色驚嘆號提示」，它主要想告訴我們的就是，你的資料正在被大量的取樣中，總數與樣本數量的比率會影響資料結果的準確性。

資料取樣門檻
GA4的預設報表不會進行資料取樣，臨時資料查詢的取樣量則設有下列一般門檻：
◆  Analytics (分析) 標準版：指定日期範圍內的 50 萬個資源層級工作階段
◆  Analytics (分析) 360：指定日期範圍內的 1 億個資料檢視層級工作階段

不僅僅有遇到取樣問題，當我在使用預設報表（Report）查看事件數據時，也常遇到大量的數字資料會歸入「(other)」列來做為一列，也就是說，當我的維度基數（Cardinality）高於系統限制時，就會將超過上限的部分納入「(other)」列。

※ Google文件參考：[GA4] 報表和探索的資料差異、[GA4] 報表中的「(other)」項目

數據的基數（Cardinality）
GA4中的每個報告都有分配給它的維度，每個維度也具有可分配的值。例如，性別維度擁有三個潛在值（男性、女性或其他），因此該維度的基數（Cardinality）就為三，具有大量可能值的維度就稱為高基數維度（high-cardinality dimensions）。如果資源收集的資料基數高於該表格的系統限制，則超出上限的資料都會匯總至「(other)」列。

視報表類型而定，高基數對報表的影響也有所不同。
所有預設報表都會查詢規模較小的表格資料，這類表格很少超過系統限制的 5 萬列上限。設有次要維度、比較和篩選器的自訂報表和預設報表，則會查詢列數上限較高的匯總表格，在這些情況下，列數上限為 200 萬列。這類表格包含許多高基數維度，因此匯總至「(other)」列的機率也比較高。

以上碰到的這些狀況（資料取樣或者資料歸入彙總「(other)」列），其實都會影響到數據分析上的準確度，官方文件中也有提到，此類問題最根本的解決方案，就是升級到GA360（GA360的採樣限制數據量約為免費版GA的200倍），白話一點的說，谷哥叫大家多付錢多享受拉😥！

只是因此需每年多噴幾百萬元，想想公司應該不會輕易答應。有道是山不轉路轉，路不轉人轉，我試著在網路上爬了一些Data Sampling Issues的相關議題，終於找到了一個不花錢的備案：

透過建置多種的GA property來追蹤網站的不同區塊，來分散資源取樣的數據量限制。

這是甚麼意思呢？以我操作的公司網站為例，「樂屋網」每月的工作階段流量已遠遠超過50萬個工作階段，此時，就可將不同頻道主題（這邊簡化說明才用頻道來劃分，實際上仍須考量使用者在瀏覽網站時的價值旅程，依此建立數據分析架構），拆分成買屋需求、租屋需求、後台作業需求...等，各自建立GA資源property，當計畫把網站整體的工作階段打散後，才可稍微減緩數據量爆表的問題。

整個GA4的帳戶層次結構如下圖所示：

接著下來，我將簡單的以「樂屋網」進行演練操作，示範如何建立這樣的資源架構。我們只先考慮想買屋的使用者來做討論，首先，到GA4管理介面新增一個全新資源【GA4 Property-2（買屋需求頻道）】，並在該資源底下建立一個Data Stream，如下圖。

接續著，進入GTM後台，複製原本的彙總（不拆分頻道）的基本追蹤代碼，將Measurement ID替換成剛剛所設定的Steam（G-XXXXXXXXXX）。

最重要的一點，將Trigger改成只有當User進入買屋需求流程時的頁面，才會觸發（簡單的說，公司網站：www.myweb.com.tw，買屋頻道：www.myweb.com/sell，就可以將觸發條件設置為「Page Path」matches RegEx 「^/sell」），如下圖。

新的設置代碼都完成之後，為了驗證資料正確無誤，就必須到GA4管理介面的DebugView，檢查是否有追蹤到該蒐集的頁面，沒問題即可發佈代碼。

等待兩三天後，我們再次進入GA4的預設報表（Engagement -> Pages and screens）中，重複檢驗資料，看是否有漏網之魚。這在大型的或是網址架構較混亂的網站，常會有非預期到的資料被蒐集到，當確認「我們擁有的就是我們所想的」數據時，就可另外按同樣的步驟，完成其他區塊的資源設置了。

以上，就是此次專案的簡單示範，幾個提到的重點整理如下：

確認使用者的價值旅程，依數據分析目標，將網站的不同區塊拆解成不同GA4資源。

不同資源需要設置各自的GA4基本追蹤代碼，並依照網址結構建立適當的觸發條件。

上線後從報表中檢驗數據資料，評估分析需求，據此調整對應的代碼（尤其須特別留意outbound link的影響）

這篇所提到的問題解決手法，只是省錢精打細算的折衷方案，但假如貴公司是「好野人」，花錢不手軟二話不說就訂閱GA360，除了有分析馬力更強大的優點外（GA免費版的200倍），真遇到需拆解網站的不同區塊時，還有Roll-up property和Subproperty兩種特殊類型的資源可靈活運用，果然付錢是老大呀!!!

這篇就先聊到此，後續會再分享更多實際遇到的有趣分析專案，掰掰~

檢舉內容GA4打雜實作｜如何拆解GA4資源架構緩解「資料不精確」的問題

檢舉內容
GA4打雜實作｜如何拆解GA4資源架構緩解「資料不精確」的問題