首先，我們必須要有一個認知，也就是了解到 GA4 所呈現的數據本身就不會百分之百準確，不能夠「完全」拿來跟後台訂單系統呈現的資料比較，基本上兩邊的數字一定會有誤差。
我們使用 GA4，是要協助我們觀察「趨勢」。
例如：
了解訂單從哪個來源/媒介而來？
來自特定來源/媒介的流量是否讓特定產品的銷量特別好？
大部分的訂單是從哪個裝置產生購買的？
已經來到結帳頁面卻沒購買的使用者是卡在哪個過程而中斷了購買行為？
舉凡不勝枚舉，但這些才是我們該去注意的，而不是去追求 GA4 的電子商務報表資料跟網站後台系統資料的百分之百吻合（儘管用伺服器端的 GTM，依然是會有落差）。
追求 GA4 數據準確率從 60% 到 90% 比去追求準確率從 90% 到 100% 要容易許多，而後者要花費的時間與心力，實在是要比前者多上太多太多（甚至不可能）。
ㅤ
在誤差的部分，過去可能是 5% 到 10% 的誤差率，但隨著隱私規範日漸嚴趨，這個誤差值也跟著日漸提升，相差到 50% 都是有可能的事情，光是一個「同意化聲明」以及阻擋廣告的 Chrome 擴充套件（Chrome 瀏覽器有約 65% 的市佔率 ）就不知道擋掉了多少 GA4/GTM 代碼的啟動，也因為如此，儘管使用者完成了訂單，我們也無法追蹤到，因而造成了 GA4 電子商務報表金額與後台搭不上的情況（不過呢，有產生實際業績才是最重要的，對吧？）。
在有了以上的認知之後，就可以開始進入今天的主題，了解到除了隱私保護機制以外，還有哪些原因會讓 GA4 沒有收到「購買」事件以及訂單的相關資料參數？
總不能當數據有問題時，把所有的問題都怪罪給上述提到的原因（就像過去廣告表現如果不佳，都會歸咎給演算法一樣），我們還是必須檢查幾個設定，看看是否因此影響了 GA4 電子商務「購買」事件的正確運作。
要記住的東西太多了，有時可能只是簡單的小問題造成的錯誤，卻因為一時的腦袋打結而疏忽了，這個時候有一份檢查清單就是很重要的事情，可以提醒我們檢查的方向，至於會有哪些可能的原因影響了數據的呈現呢？
讓我們繼續看下去。
ㅤ
本篇重點
#1 等待超過 24-48 小時了嗎？
這是第一個要檢查的部分， GA4 需要點時間處理資料，當你確定事件發生並傳送到 GA4 的時間已經超過 24-48 小時了，卻依然沒有資料，那再繼續看後續的解決方式。
ㅤ
解決方式
等。
ㅤ
#2 Data Layer 資料推送的時機錯誤
這是初期很常見的錯誤，就是「資料層」中的訂單資料相關參數推送時機比電子商務「購買」事件來得早或是晚，儘管我們很確定有在「購買」事件中帶上事件參數或是勾選「傳送電子商務資料」（擇一使用即可），但卻因為訂單資料推送至資料層的時間跟「購買」事件代碼觸發的時間點不同，使得「購買」事件抓不到訂單資料，造成 GA4 電子商務報表的不準確。
ㅤ
ㅤ
舉例來說：常見的情況就是網站在使用者按下結帳當下觸發了「購買」事件，接著隨即將使用者導入「感謝頁面」，並且將訂單相關資料推送到「感謝頁面」的「資料層」，在這樣的情況底下， GA4 依然會收到「購買」事件，但是就不會有訂單的資料了（因為「購買」事件觸發時，資料層根本沒有東西。）
又或是反過來，訂單相關資料推送到了結帳頁面的「資料層」，但是「購買」事件卻是在「感謝頁面」觸發，也是會產生一樣的結果，儘管有 GA4 有收到「購買」事件，但電子商務相關報表卻沒有數據的情況。
ㅤ
解決方式
透過 GTM「預覽」模式檢查當「購買」事件代碼啟動時，資料層中有無訂單相關資料，相關的「資料層變數」顯示為 undefined 或是有抓到值。
如果呈現 undefined，則是看看「購買」事件產生前後頁面的資料層是否有訂單相關資料，修改「購買」事件觸發時機或是將訂單資料推送到「購買」事件發生時的所在頁面資料層，並確保在「購買」事件之前推送。
最簡單的做法，就是照著這篇「如何用 GTM 設定 GA4 電子商務事件？」進行設定，使用「自訂事件」觸發條件，就能確保「購買」事件觸發時，資料層會有我們需要的訂單資料。
延伸閱讀》
GTM 變數介紹：資料層變數（Data Layer Variable）
ㅤ
#3 資料層格式錯誤
如果在「購買」事件代碼的設定中，你是在代碼設定中的「更多設定」區塊中勾選「傳送電子商務資料」，希望透過該選項自動傳送訂單相關數據（這樣就不用設定好多個「資料層變數」），但推送到資料層中的格式卻不是 GA4 官方指定的，那麼也不會收到正確的數據（只會收到「購買」事件，但不會有如訂單 ID、項目或是總收益等這些數據）
ㅤ
解決方式
如果可以直接更改推送到「資料層」的資料格式，那麼建議直接進行更改，使其符合 GA4 官方的要求，在設定所有的電子商務事件時也會相對省事。
如果需要請工程師協助修改，那麼可以參考這篇文章的做法與工程師溝通，使其了解你的需求。
但如果無法更改，那麼可以參考這篇「如何用 GTM 轉換【非】GA4 規格的電子商務資料層參數？」的做法。
ㅤ
#4 金額格式的錯誤
好，你參考了 #3 的步驟，將格式修正成 GA4 官方文件指定的格式，電子商務報表依然一片空白，最常見的細小錯誤就是金額（value）的「值」格式錯了。
ㅤ
很常見到有人會在這邊放上金錢的符號，變成 value: $72.05 或是 value: 72.05$。
要注意，GA4 只接受相對應的「值」類型為 number，而非字串（string），同理也應用在 tax 還有 shipping，這是一個非常細微且不容易被注意到的錯誤，但也相對很好處理。
ㅤ
因此，當你很確定資料層的參數名稱都正確時，請再確認相對應的「值」是否也是正確的格式， GA4 需要的是字串（string）還是數字（number），這種細小的錯誤，常常讓初入門的朋友摸不著頭緒，這也是為什麼我們在這篇文章中特別強調給工程師的代碼，不要直接複製貼上在 Email、Word 文件或是 Google Doc，此舉很容易造成代碼因為文件編碼方式不同，使得複製貼上的代碼出現錯誤。
ㅤ
解決方式
對照官方文件，確定參數「值」的類型該是字串的為字串（string），該是數字的都是數字（number）。
ㅤ
#5 你根本沒有發布容器
你可能會覺得：「太扯了吧，怎麼可能！」
不，這是很常見的狀況，我們常常遇到 GTM 操作人員費盡千辛萬苦完成了設定，也用「預覽」模式測試完畢，確保代碼都有正確發送且 GA4 DevugView 也有接收到正確的資料，然後就沒有然後了。
興高采烈的關閉了電腦下班去，等了 48 小時之後想要確認一下 GA4 的電子商務報表卻發現什麼東西都沒有，前面我們提到的可能原因也都排除了，最後我們一進去 GTM 容器中看才發現，容器根本沒有發布！
ㅤ
解決方式
確認 GTM 右上角的「工作變更數」是否為 0，如果不是，代表你的「電子商務購買事件」設定可能尚未提交，點擊「提交」後即可。
ㅤ
#6 同意化聲明的影響
隨著隱私保護隨著人們對於網路上隱私保護意識的抬頭，與隱私保護相關的法規也越來越嚴格，例如目前最為嚴格的歐盟 GDPR 以及美國的 CCPA 等，儘管你是台灣的公司，但只要網站有在歐洲運營，有蒐集到來自歐洲的流量，都必須要遵守 GDPR 的隱私規範。
只要使用者沒有同意追蹤，就不能啟動 GA4/GTM 等相關追蹤代碼，也因此無法接收到訂單相關的資訊，這都可能是造成 GA4 訂單金額與後台不符的情況。
ㅤ
儘管 Google 進階版的同意聲明（Consent Mode V2）有轉換模擬的功能，但頂多讓我們知道有轉換事件發生，仍然無法知道訂單詳細資料（如訂單號碼、金額以及產品項目等），因此如果你的網站有使用同意化聲明工具，就更不要糾結在 GA4 訂單金額與後台金額不符的情況了，這是必然會發生的事情。
ㅤ
解決方式
無解。
只要使用者不願意給我們追蹤，沒有點下「同意」，我們也愛莫能助（雖然台灣目前沒有強制安裝這個部分，但相信未來應該會逐漸跟上這個腳步。）
ㅤ
#7 GA4 沒有排除內部流量
如果沒有排除內部的流量，各部門或是你自己的測試訂單就會一同被記錄到 GA4 的報表當中，也因此造成實際訂單情況與 GA4 不符，因此當發現這樣的情況時，可以確認一下有多少人產生了測試訂單，並且到 GA4 的後台確認是否有排除內部流量。
另外，某些企業的商業模式會有內部電銷人員或是協助客戶下訂單的服務部門，通常這一類型的訂單因為是透過公司內部的電腦並且使用電銷人員的帳號進行下單，此時如果有排除內部流量，這些電銷人員的訂單就不會被記錄到 GA4 當中，這點是必須要注意的情況。
（當然，如果本來就不希望電銷人員的訂單一併記錄到 GA4 當中，排除內部流量就不會有什麼問題了。）
ㅤ
解決方式
GA4 左下角齒輪進入後台 > 展開「資源設定」區塊 > 「資料串流」> 選擇該 GA4 串流資源 > 選擇畫面下方「進行代碼設定 > 選擇「定義內部流量」
ㅤ
延伸閱讀 》GA4 新帳戶啟用前必須完成的 14 個後台設定
ㅤ
#8 瀏覽器或是廣告阻擋套件的影響
如果使用者有安裝阻擋廣告的 Chrome 擴充套件，如： AdBlocker、Adguard 或是 Ghostery 等，或是使用隱私保護的 Brave 瀏覽器，都會阻擋 GTM/GA4 代碼的啟動。
ㅤ
解決方式
使用伺服器端（Server-side GTM）來繞過瀏覽器以及廣告阻擋套件的限制，或是 Let it go。
ㅤ
#9 使用者停用了瀏覽器的 Javascript
這也是屬於使用者端的行為，一般來說，使用者不會去特別關閉瀏覽器的 Javascript 功能，儘管有，數量也不會太多，但還是寫出來讓大家知道一下有這樣的可能性，因為 GA4 跟 GTM 都是以 Javascript 為基礎的追蹤代碼，所以當瀏覽器停用了 Javascript，理所當然它們也無法啟動了。
ㅤ
解決方式
無，基於使用者端的行為我們無法控制。
ㅤ
#10 GA4 自動排除了重複訂單
在「購買」事件的資料格式中，有一個 transaction_id 參數，當我們將該參數隨著「購買」事件傳送到了 GA4 當中，未來只要有重複的 transaction_id，GA4 便不會紀錄該「購買」事件。
你可能會納悶：「怎麼可能會有重複的訂單 ID 呢？」
其實這情況比較常發生在使用 GTM 的操作人員身上，有時為了省事，我們可能會記錄下某次購買完成的「感謝頁面」網址，然後在使用 GTM 預覽模式的時候直接輸入該網址（跳過中間購買流程），單純想測試「購買」事件是否在「感謝頁面」正確觸發並抓到相關訂單資料。
此時就會出現 GTM Tag Assistant 中出現代碼成功觸發的畫面，但是在 GA4 Debug View 當中卻沒有收到「購買」事件，這是因為之前已經傳送過了該購買完成的訂單 ID 給 GA4，我們重複使用來進行測試就會讓 GA4 自動排除掉該筆訂單，所以才會出現 GTM 顯示代碼成功啟動，但 GA4 不會顯示「購買」事件的情況發生。
ㅤ
解決方式
不要偷懶，乖乖地走完一次完整的購買流程，使其產生不同的訂單 ID（transaction_id）
ㅤ
#11 訂單沒完成卻送出購買事件
這也是很常見的情況，因為觸發條件設定錯誤，結果不管訂單成立與否，都會啟動「購買」事件的代碼。
例如：
有些網站儘管使用者付款失敗，依然會引導使用者到「感謝頁面」，並且成立訂單號碼，只是在付款狀態的部分會顯示為「尚未付款」or 「付款失敗」，因為「購買」事件觸發條件是依據「感謝頁面」的網址（當 page_path or page_url 為 xxxx/thankyou 時），所以儘管付款失敗，GA4 依然收到了一個包含訂單資料的「購買」事件。
上述這樣的情況，就會造成資料上的錯誤，使 GA4 的訂單總金額比後台高出很多。
ㅤ
解決方式
- 付款失敗的訂單，不要引導至「感謝頁面」
- 只有付款成功的訂單，才會推送「購買」事件相關資料到「資料層」，並使用「自訂事件」觸發條件進行代碼觸發。
設定方式請參考》如何用 GTM 設定「GA4 電子商務事件」？
ㅤ
總結一下
我們依照了問題發生的可能性，列出了排查方式的優先順序，未來如果遇到了「購買」事件遺失或是電子商務報表中沒有訂單以及商品相關數據時，可以透過下列的方式找出可能的原因。
- #1 等待超過 24-48 小時了嗎？
- #2 Data Layer 資料推送的時機錯誤
- #3 資料層格式錯誤
- #4 金額格式的錯誤
- #5 你根本沒有發布容器
- #6 同意化聲明的影響
- #7 GA4 沒有排除內部流量
- #8 瀏覽器或是廣告阻擋套件的影響
- #9 使用者停用了瀏覽器的 Javascript
- #10 GA4 自動排除了重複訂單
- #11 訂單沒完成卻送出購買事件
（當然，也可能不只這些原因，如果你有發現任何特殊情況沒有在本文中提到，歡迎與我們討論，看是否能協助你解決問題，並讓我們收錄到這篇文章當中，方便未來遇到相同問題的朋友可以很快的解決問題。）
ㅤ
其實，如果有確實執行 GTM 預覽功能（Tag Assistant）＋GA4 Debug View 的測試，部分上述的情況應該會在測試階段就被發現，我們可以透過預覽模式觀察「購買」事件的代碼詳情或是「資料層」頁籤中顯示的資料，確認發送出去的格式是否正確。
ㅤ
同時也要確認 GA4 Debug View 是否有收到資料且包含「項目」頁籤以及 transaction_id、value 以及 currency 等必要參數，確認顯示的訂單金額、訂單ID 、產品數量和名稱是否與實際的訂單相符。
ㅤ
另外，別忘了「提交＆發布」你的容器，讓「購買」事件正式上線，接著等待 24-48 小時讓 GA4 消化一下資料。
基本上，只要是照著這篇「如何用 GTM 設定 GA4 電子商務事件？」來進行設定，相信都不會有遺失「購買」事件以及相關訂單資料的問題，如果遇到非 GA4 官方規格的資料層，也可以用這篇「如何用 GTM 轉換非 GA4 規格的電子商務資料層參數？」的方法來處理，如果還是遇到問題，再來照著這篇提供的方式一一除錯，如果這邊的方法都沒有辦法解決，可以到社群媒體聯絡我們，讓我們協助你看看是什麼可能的原因。
ㅤ
補充一下
後台盡可能紀錄更多該訂單相關的資訊
如果可以的話，讓後台紀錄多一點的訂單相關資訊，除了 GA4 基本的參數以外，也可以記錄結帳裝置、裝置系統、付款方式等，後台紀錄越多的資料，我們也就越有可能找出「購買」事件沒有被記錄到原因。
例如，發現許多後台有但是 GA4 沒有的訂單號碼，其付款方式都是來自於「貨到付款」，此時我們就可以查找一下當使用者使用「貨到付款」的方式結帳，是否被轉去了其它地方，所以沒有觸發「購買」事件。
或是透過查看後台紀錄完成訂單（但 GA4 沒記錄到）所用的裝置系統來進行比對，也可以讓我們進一步研究是發生了什麼事，是不是特定的裝置或是作業系統影響了追蹤事件。
ㅤ
定期比較 GA4 與後台的數據
在數據跑了一段時間之後（例如一週或是兩週），可以嘗試輸出 GA4 電子商務報表並且與網站後台的訂單比對一下，確認 GA4 數據與後台是否相符，可以這樣進行比對。
- 後台有的訂單 ID，GA4 也有嗎？
- 如果有，那該訂單在 GA4 的總金額與訂單內的產品數量與後台訂單相符嗎？
- 如果沒有，比對一下是少了哪組訂單號碼？可否從後台中看到使用者的付款方式、裝置以及會員 ID，比較 GA4 中是否有記錄到該會員 ID（USER ID），確認是追蹤代碼被封鎖所以沒有追蹤到「購買」事件還是其他原因所造成。
- 如果後台顯示有用折價券，GA4 有記錄到嗎？
- GA4 記錄到該訂單的會員 ID 與後台的會員 ID 是一樣的嗎？
（ 延伸閱讀 》 如何用 GTM 傳送 User ID 到 GA4？ ） - 訂單日期是相同的嗎？
- （歡迎補充…）
ㅤ
最後，必須再提醒一下，不要期望 GA4 的訂單數據會與網站後台訂單數據 100% 相符，我們用 GA4 看的是趨勢，花時間要去追求兩者之間 100% 的正確，不如將這個心力花費在獲得更高的訂單轉換率上面。
ㅤ