在前文"GA4認證考試重點 (GA4 Certificate)"說到，就算你的觀念不是完全正確，你還是可以使用 Google Analytics，還是可以獲得「基本的數據」。但是得到基本的數據，只能大概知道網站流量，並不能保證是精準的數據。因為 Google Analytics 並不是「有裝就好」，本文把最常見的錯誤分成幾大類，讓你去檢核是否犯了相同的錯誤。
一、安裝與傳送資料最常見的錯誤
1) 重複安裝
因為 Google Analytics 的數據是透過追蹤碼而來，如果瀏覽一個網頁會啟動一個以上相同的追蹤碼，數據就會重複計算。
最常看到的情況是 :
(a) 同時以 Google tag (gtag.js) 安裝追蹤碼，又再次使用 GTM 安裝追蹤碼。
(b) 系統已經有啟動 Google Analytics 追蹤的方式 (例如 Google Blogger 在設定中填寫評估ID)，又再次使用 Google tag (gtag.js) 或 GTM 安裝追蹤碼。或是在 WordPress 手動貼上追蹤碼，又用外掛安裝GA。
要知道是否以上兩種情況，只需要看網頁內碼有無兩套追蹤碼，或是由 Google Analytics 的即時報表觀察，是否瀏覽流量都是雙份相同的。
如下圖，從事件觀察沒有雙份相同的狀況，就代表沒有兩套追蹤碼 :
或是一個追蹤碼內啟動一個以上相同的事件，數據也會重複計算。
如下圖，mouse_scroll 與 scroll 就是不同名稱，但是一樣的事件 (但是因為量測的門檻不同，因此就有不同的數據) :
2) 加強型評估重複計算
GA4 的加強型評估會「自動送」一批互動事件；如果你又在 GTM 自己做了同名/同類事件，就重複了。
加強型評估會使用的事件名稱 :
網頁瀏覽：page_view (此事件會自動蒐集，無法關閉)。
捲動：scroll。
外連點擊：click (不是 outbound_click，而是 click，並帶有 outbound=true 參數)。
站內搜尋：view_search_results。
影片互動：video_start、video_progress、video_complete (針對具備 JS API 支援的 YouTube 嵌入影片)。
檔案下載：file_download。
表單互動：form_start、form_submit。
如果你在 GTM 又產生跟以上同名的事件，就會重複計數，或是事件參數被搞亂。
例如使用 DebugView 去觀察，如下圖 :
3) 部分頁面漏裝或裝錯位置
追蹤碼如果「漏裝」或「放錯位置」，就可能導致 GA4 的追蹤不會正常初始化，進而出現兩種常見結果：第一是完全沒有資料進來(例如 page_view 都沒有)；第二是只有部分頁面或部分互動事件有資料(例如某些頁面有 page_view，但轉換事件或電商事件缺漏)。這通常是因為追蹤碼沒有在每個頁面版型一致載入，或沒有放在建議的 <head> 區塊，導致載入順序、觸發時機、或相依腳本沒有被正確執行。
頁面漏裝追蹤碼通常發生在手動貼上追蹤碼、或是頁面版型不一致、或是網站平台無法將追蹤碼貼在正常的區塊，這些通常發生在客製化平台上，較常見的網站平台比較不會有這個問題。
要偵測網站是否頁面漏裝追蹤碼，最全面的方式是使用爬蟲軟體 (例如 Screaming Frog ) 全面爬取，確認是否有頁面無法發現特定字串 (例如GA的評估ID)。
如果頁面都沒有漏裝的情況，再來就是要檢查安裝的位置。
正常來說，GA4 的 Google 代碼 (Google tag，gtag.js) 建議放在 <head> 內且越上方越好，讓追蹤程式能更早載入與初始化。若使用 GTM，容器碼分兩段：第一段 <script> 放在 <head> 內越上方越好；第二段 <noscript> 放在 <body> 開頭標籤後面立刻加入。這樣做的目的，是降低因載入順序、頁面快速離開、或前面腳本出錯而造成的漏追風險，但無法保證完全不會被廣告阻擋器 (Ad blocker)、內容安全政策 (CSP，Content Security Policy) 或其他限制所阻擋。
並且追蹤碼的順序問題也要特別注意，例如有使用 data layer 時，要確定先把 dataLayer 準備好(宣告、塞入你要的資料)，再載入 Google 代碼 (Google tag) 或 GTM 代碼；否則很容易出現第一個事件(通常是 page_view)已經送出了，但你要的參數還沒進 data layer，報表就會變成 (not set)。
例如下面的程式碼 :
<script>
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
event: "page_meta",
page_type: "product",
product_id: "SKU_123",
user_type: "member"
});
</script>
以上這段可以想成 : 先把你要給 GTM/GA4 用的資料，丟進一個排隊箱(Queue)裡」，等 Google Tag Manager 或 Google 代碼啟動後，再去把箱子裡的資料一筆一筆拿出來用。
因此如果 Google Tag Manager 或 Google 代碼啟動前，上面的程式碼沒有先執行，從排隊箱(Queue) 裡就撈不到資料。
二、流量來源與歸因最常見的錯誤
4) 沒有排除內部流量
公司的人員經常會需要查核自己網站，如果這些內部流量沒有排除，肯定會干擾流量數據分析。要排除內部流量，必須從兩個地方設定，第一步是定義內部流量，如下圖 :
第二步是建立資料篩選器，將內部流量排除，如下圖 :
5) 沒有排除回流網域
回流網域是指從你的網域出去，執行完某些任務後再回流的網域，例如你的電商網站透過 Paypal 結帳，就會從電商網站連到 Paypal 網域，結帳後會再由 Paypal 網域回到電商網站，此時你的 GA4 就必須把 Paypal 網域排除。如果沒有排除 Paypal 網域，Paypal 網域就會變成 Referrer，從 GA4 就會看到很多 Paypal 的 Referrer 流量，這類的網域就必須排除，GA4 才能的到正確的數據。
如下圖，從「列出不適用的參照連結網址」就可以把從 Paypal 之類網域的流量排除。
6) 跨網域追蹤沒有正確設定
許多網站會將不同功能放在不同的子網域，例如：
www.example.com：官方網站
blog.example.com：內容網站
shop.example.com：購物網站
這三個網址雖然不同，但都屬於 example.com 之下的子網域（Subdomain），並不是 GA4 所謂需要另外處理的不同根網域。
如果這些子網域都使用相同的 GA4 追蹤碼（相同 G-ID），而且沒有自行修改 Cookie 網域設定，Google Tag 預設會使用自動 Cookie 網域設定（Automatic Cookie Domain Configuration），將 Cookie 設定在可使用的最高層網域，例如 example.com。
因此使用者從： www.example.com → blog.example.com → shop.example.com 移動時，GA4 可以沿用相同的 Cookie 資訊，通常不需要另外設定跨網域追蹤（Cross-domain measurement）。GA4 同時具有自動自我推薦偵測（Automatic self-referral detection）。當來源網址屬於相同網域或其子網域時，GA4 預設不會將它重新判定為新的推薦流量，因此正常情況下，也不需要把 blog.example.com、shop.example.com 加入「不想要的推薦（Unwanted referrals）」。
也就是說，如果： 各子網域使用相同 G-ID + 使用 GA4 預設 Cookie 設定
通常不需要設定： 跨網域追蹤，也不需要排除自己的子網域推薦流量。
真正需要設定跨網域追蹤（Cross-domain measurement）的情況，是使用者會在不同的根網域之間移動，例如： www.example.com → checkout.payment-example.com 這時兩個網站無法直接共用第一方 Cookie，GA4 才需要透過跨網域追蹤，利用網址中的 _gl 參數傳遞使用者與工作階段資訊。
要進行 GA4 跨網域追蹤，各網域必須使用同一個網頁資料串流（Web data stream）的相同 G-ID。
另外要注意，如果不同子網域使用不同的 G-ID，那並不是「設定跨網域追蹤」就可以自動把資料合併。
若希望 www、blog、shop 被視為同一套網站分析資料，最直接的做法是讓這些子網域使用相同的 GA4 網頁資料串流與相同 G-ID。
只有在你自行修改 cookie_domain，導致不同子網域使用不同 Cookie 網域時，才可能發生使用者或工作階段被拆開、甚至出現 Self-referral 的問題。此時應優先檢查 Cookie 網域設定，而不是直接把所有子網域加入跨網域追蹤。
7) UTM參數沒有正確設定
一個完整的 UTM 連結通常由以下五個參數構成：
utm_source : 流量來自哪個平台或網站
utm_medium : 流量的類型（行銷手段）
utm_campaign : 具體的活動名稱或促銷標題
utm_term : (選填) 多用於關鍵字廣告
我們就可以在社交平台上貼文使用以下連結連回網站 : https://example.com/shop/?utm_source=facebook&utm_medium=social_post&utm_campaign=2025_winter_holiday_sale
當GA4收到這樣的流量時，就知道這是從臉書貼文的2025冬季促銷活動而來的。
何謂UTM參數沒有正確設定 ?
例如在自己的網站內部連結（例如從 blog.example.com 到 shop.example.com）加上 UTM 參數是數位行銷中的大忌。
因為當帶有UTM參數的連結被點選，「工作階段」會強制中斷，並開啟一個新的工作階段，並且原始流量歸因會遺失。當一個工作階段被 UTM 強制切斷後，前一個頁面會被判定為「結束頁面」。如此一來，整個分析數據就亂了。
那麼UTM參數正確設定是指什麼?
UTM 參數的正確設定，最重要的核心原則是：「UTM 只能用於追蹤從外部進入網站的流量」。其次的原則是：「UTM 參數要標準化，並遵守參數的命名原則」，最後的原則是：「不要帶入敏感資訊」。
UTM 參數的命名原則是 :
(a) 建議一律使用小寫。
(b) 避免使用空格，建議使用底線或連字號。
三、事件、轉換與電商最常見的錯誤
8) 事件命名混亂
GA4 事件有四大種類 :
(a) 自動收集的事件 : 只要您安裝了 GA4 追蹤代碼，系統就會自動開始收集，無需任何額外設定。
first_visit：使用者第一次造訪網站。session_start：使用者開啟新的工作階段。user_engagement：使用者在網頁停留超過 1 秒後觸發，用來計算參與時長。
(b) 加強型評估事件 : 這類事件需要在 GA4 後台的「資料串流」中手動開啟開關（通常預設為開啟）。它們能自動捕捉更細緻的行為。
page_view：網頁瀏覽（不可關閉）。scroll：使用者捲動頁面深度達 90% 時觸發。click：外連點擊（點擊導向外部網域的連結）。view_search_results：站內搜尋（偵測網址中的搜尋參數）。file_download：點擊下載檔案（如 PDF, docx, zip）。video_start / video_progress：與內嵌 YouTube 影片的互動。
(c) 建議事件 : 這些是 Google 預先定義好名稱與參數的事件，但需要您自行設定（透過 GTM 或程式碼）。使用建議名稱的好處是，GA4 的預設報表（如電子商務報表）能直接讀取這些數據。
電子商務類： view_item (查看商品)、add_to_cart (加入購物車)、begin_checkout (開始結帳)、purchase (購買)。
通用類： login (登入)、sign_up (註冊)、share (分享內容)。
(d) 自訂事件 : 如果以上三類都無法滿足您的需求，您可以自行命名並設定事件。
所謂事件命名混亂，就是你自訂事件時跟已經存在的事件衝到，或是相同事件存在多個不同事件名稱。
9) 事件沒有正確追蹤
(a) 事件名稱或參數拼錯
這個錯誤跟上述事件命名混亂有些關係，例如 purchase 事件，如果你在 GTM 設定了 Purchase 事件就無法辨識這是購買行為，因此電子商務報表會是一片空白，數據會跑去「自訂事件」。
(b) 觸發條件設定錯誤
例如把進入感謝頁觸發購買事件，當使用者重新整理感謝頁，導致 purchase 事件又傳送一次。或是點擊了「聯絡我們」但表單驗證失敗沒送出，GA4 卻紀錄了 form_submit。
如此一來，轉換率會被嚴重高估，導致行銷成效看起來假性良好。
(c) 遺漏必要的參數
例如只追蹤了「點擊」事件，但沒有帶上「在哪一頁點擊」或「點擊了什麼按鈕」的資訊。 結果報表只顯示 click 發生了 1000 次，但您無法分析使用者到底點了什麼，這類數據就沒有分析價值。
(d) 沒設定「自訂維度」
雖然把數據傳給了 GA4，但沒有在 GA4 後台「註冊」這個參數。結果在即時報表看得到數據，但在長期探索報表中抓不到該維度，導致數據「看得到用不到」。
(e) 跨網域或身分識別斷裂
就像之前提到的，使用者從 A 站到 B 站被拆成兩個人 (其實AB是子網域)。結果 GA4 判定這是一個「沒有來源」的轉換，或是歸因為 direct / none。
10) 電商事件傳送不完整
電子商務追蹤算是GA4中較為複雜的數據追蹤，因為如果沒有進一步設定，營利報表肯定沒有數據，如下圖 :
要實作事件追蹤，主要分為三個階段：定義事件、埋設代碼、驗證數據。
不過電子商務的事件都是已經定義的，因此不需要另外再定義事件，需要做的事是埋設代碼，在特定情況下觸發電子商務事件，餵給正確的資訊，最後是測試看看數據是否正確。
由於電子商務的事件追蹤比較複雜，細節另文再談。
四、GA4 基本設定最常見的錯誤
11) 時區、幣別設定錯誤
為什麼這兩個設定錯誤會是災難？
1. GA4 的時區決定了數據「換日」的時間點。
意思是如果網站主要客戶在台灣 (GMT+8)，但 GA4 預設維持在美國洛杉磯時間 (GMT-7)，兩者相差 15 小時。 就會造成廣告歸因錯亂，在台灣週一發送的電子報流量，會被紀錄在 GA4 的週日。 當比對「官網數據」與「後台訂單系統」時，會發現每天的總量永遠對不起來。你以為流量高峰在凌晨，其實是因為時差。
2. 幣別決定了所有價值指標（如收入、LTV、客單價）的單位。
如果網站收的是新台幣 (TWD)，但 GA4 預設是美金 (USD)。1,000 元的訂單會被 GA4 紀錄為 1,000 美金（數據直接膨脹 30 倍），或是被錯誤轉換。
如果 purchase 事件有傳送幣別參數，GA4 會嘗試進行每日匯率轉換。如果底層設定（資源設定）跟事件傳送的幣別不一致，就會產生額外的匯率計算誤差。
因此必須將幣別、時區正確設定，如下圖 :
12) Data retention (資料保留) 沒調整，造成資料不齊
GA4 資源建立時，會預設的保留期限僅為 2 個月。 受影響的範圍主要是 「探索」報表（即自訂報表）。當資料超過 2 個月，就無法在探索報表中使用自訂維度進行回溯分析。 不過「標準報表」（例如：流量開發、電子商務購買）使用的是彙總數據，通常不受此 2 個月限制影響，但靈活性較低。
因此建議把事件資料與使用者資料的資料保留都設為14個月，如下圖 :
除了以上設定常犯的錯誤之外，還要記得正確的授權給外包廠商，才能讓你的GA正確而安全。
GA4 設定常見痛點問題 (FAQ)
1. 子網域 (Subdomain) 需要設定跨網域追蹤 (Cross-domain tracking) 嗎？
不需要。在 GA4 的運作機制中，子網域（例如 blog.example.com 與 shop.example.com）預設會自動共用主網域的 Cookie。只要你在所有的子網域都安裝相同的評估 ID (Measurement ID)，GA4 就能自動串連使用者的工作階段 (Session)，你也不需要到後台設定排除推薦流量 (Referral traffic exclusion)。
2. 網站的內部連結可以使用 UTM 參數 (UTM parameters) 嗎？
絕對不行。UTM 參數的核心原則是「只用於追蹤從外部進入網站的流量」。如果在網站的內部連結（例如從首頁點擊到產品頁）加上 UTM 參數，會強制中斷原本的工作階段 (Session) 並開啟一個新的工作階段。這會導致原始的流量來源歸因 (Attribution) 遺失，讓分析數據嚴重失真。
3. 為什麼 GA4 的瀏覽量 (Pageviews) 或事件 (Events) 會重複計算？
最常見的原因是「重複安裝追蹤碼」。例如，網站同時使用了 Google 代碼 (Google tag, gtag.js) 直接安裝，又透過 Google 代碼管理工具 (Google Tag Manager, GTM) 再次觸發。另一種常見情況是，你在 GTM 中自訂的事件名稱，與 GA4 後台自動開啟的加強型評估 (Enhanced Measurement) 事件（例如 scroll 或 click）完全相同，導致系統重複接收資料。
4. 公司員工測試網站的流量會影響 GA4 數據嗎？該如何排除？ 會的，內部的測試與瀏覽行為會干擾真實使用者的數據分析，導致轉換率 (Conversion rate) 判斷錯誤。建議在 GA4 後台的資料串流 (Data stream) 設定中定義內部 IP 位址，接著到資料篩選器 (Data Filter) 將「內部流量」設定為排除。建議先以「測試中」狀態觀察，確認無誤後再切換為「有效」。
5. 為什麼 GA4 的電子商務報表 (Ecommerce reports) 裡面沒有數據？
電子商務追蹤需要傳遞特定的參數，報表才會有資料。通常沒有數據是因為事件名稱拼寫錯誤（例如將建議事件 purchase 大寫拼成了 Purchase，GA4 會將其視為一般自訂事件），或是遺漏了必要的事件參數 (Event parameters)，例如沒有傳送幣別 (Currency) 或商品陣列 (Items array) 資訊，導致 GA4 無法正確讀取並繪製營利報表。