為了要知道網站使用者是從何而來，「來源/媒介」維度可以說是 GA4 使用者最常查看的維度之一，而其中的「direct（直接）/ none」常常令人摸不著頭緒，到底這個「direct（直接）/ none」是什麼？應該要如何解讀這個流量來源？
過往最常見到的解釋就是：
- 使用者直接在瀏覽器的網址列中輸入你的網站網址，進入網站。
- 使用者將你的網址存在瀏覽器的書籤或是記事本中，並透過書籤或記事本連結進入網站。
- 使用者從 App 進入你的網站（同時連結沒有附加「 UTM 參數」）。
- 使用者透過 Line 或其它通訊軟體點擊連結進入網站。
（IG 訊息不會傳送 referrer，其它如 LinkedIn 以及 Messenger 則是都會。）
上述這些情況進站的流量確實都會變成「直接流量（direct）」，不過隨著隱私保護法規、同意聲明工具的影響以及瀏覽器隱私安全保護的規範日漸嚴謹，造成來源顯示為「直接流量（direct）」的原因已經不僅止這些。因此，網站「直接流量（direct）」的多寡，也不見得能代表品牌力的強弱了。
（過往我們會認為，如果消費者直接輸入你的網址或是透過書籤來到網站，代表他們對你的品牌有一定程度的認識和熟悉度，因此會將「直接流量」多寡作為判斷品牌力強弱的依據。
但現在，事情已經沒這麼簡單了。）
在這篇文章中，我們會告訴你造成「直接流量（direct）」的可能原因，以及列出幾個有可能導致這種結果的情況。簡單來說，我們越來越難單靠 GA4 的流量來源報表直接斷定「直接流量」的真正「來源」，還必須要配合當前的行銷活動以及善用「到達網頁」報表來了解實際發生的情況。
至於可能的原因有哪些呢？
讓我們繼續看下去。
本篇重點
GA4 如何判斷流量為「直接流量」？
在解釋可能的原因之前，我們可以先理解 GA4 是如何判斷這些流量來源的，認識基本的運作原理之後，未來你就可以以此類推，了解到報表中看到的「直接流量（direct）」，造成的原因可能跟你想的不一樣。
當使用者在網頁與網頁之間瀏覽時，每個網頁的 Http Headers 都會帶有 referer 參數的欄位，協助紀錄「使用者的上一頁是來自於哪裡」，大概會像是下圖這樣：
而 GA4 就是透過 Headers 中的 referer 欄位，來判斷使用者的「來源」為何。
如果想查看網頁 Http Headers 中的 referer，可以這麼做：
在「網頁檢查工具」選擇 network 頁籤 > 接著重新整理頁面 > 在左側介面中，隨意選擇一個 request > 接著在右側面板的 Headers 部分，就可以看到 referer。
（注意，這邊的 referer 我們沒有拼錯字，當初在制定 Http 協議時，開發者就不小心拼錯了，由於這個拼寫錯誤已經成為標準的一部分，為了保持與現有的應用程序和伺服器的兼容性，加上已經在網路上被廣泛接受和使用，改變它會導致很多實際問題，後續就一直被保留下來到現在。）
ㅤ
透過「網頁參照網址（referrer）」判斷
在 GA4 當中有一個「網頁參照網址」維度，可以幫助我們知道使用者在來到當前網頁之前是來自於哪裡，而這個維度對應的就是網頁上的 referer 參數欄位。
例如：如果「網頁參照網址」是來自於 www.google.com，GA4 就會判斷其來源為「organic」，如果網址同時還有帶上 gclid 參數（Google 廣告的參數），GA4 則會判斷其來源為「CPC」，但隨著瀏覽器對於隱私安全保護的限制，我們已經越來愈難取的完整的「網頁參照網址」了，而當 GA4 無法判別其來源網址時，也就會將其歸為「直接流量（direct）」
至於要如何查找「網頁參照網址（referrer）」呢？除了上一段提到的方式，我們還可以這麼做。
- 在網頁檢查工具的 console 頁籤中輸入
document.referrer。（沒錯，這邊是正確拼法 referrer。） - 用 GA4 Debug View 查看
page_view事件中的page_referrer參數。 - 透過 GA4 報表中的「到網網頁」＋「網頁參照網址」維度
我們在文章「GTM 變數介紹：參照網址 (Referrer)」中有圖文解釋操作方式，有興趣的朋友可以參考該篇文章。
ㅤ
透過「UTM 參數」判斷
如果你有為網址建立正確的「UTM 參數」，那 GA4 也會依據網址中的 utm_source 來判斷流量來源。
一個完整且正確帶有「UTM 參數」的網址必須要包含 utm_source 以及 utm_medium，但如果一個不小心，忘了帶上 utm_source 或是參數名稱打錯字變成 utn_source 且 GA4 無法透過網頁上的 referrer 參數來判斷上一頁的網址時，也會變成「直接流量」。
ㅤ
簡單來說，當網頁上 Http Headers 的 referer 參數欄位為空或是無法被判別且網址也沒有帶任何「 UTM 參數」的話，GA4 無法判斷並歸類，便會將其流量納入到「直接流量」。
現在你應該知道，為什麼直接在瀏覽器網址列輸入網址的造訪行為會被判斷為「直接流量」了吧？
同時，你也應該意識到，造成「直接流量」的原因可能還有很多種，沒有這麼簡單。除了上述這些情況，還有哪些情況可能會讓流量被判斷為「直接流量」呢？
接下來，我們會一次整理出所有可能性，讓你在未來可以有個判斷的依據。讓我們繼續看下去。（接下來的內容中，我們都會使用正確的 referrer 拼法。）
那些年，造成「直接流量」的可能原因
短網址造成 referrer 參數遺失
為了讓社群貼文美觀、讓網址連結直覺且好記憶以及方便追蹤點擊次數，我們很常使用短網址來替代原本冗長的網址。然而，某些短網址工具可能會造成 referrer 參數出錯，使其變成空值，導致流量來源被判斷為「直接流量」。
目前已知台灣常用短網址工具的 lihi、picsee.io 以及 bitly ，都會原封不動地將「原網址」帶入 referrer 欄位中，而 reurl 短網址服務雖有帶上 referrer，不過帶上的卻是自家 reurl.com 的網址，假設這個短網址原本是被應用在 Facebook 貼文上，那麼該來源雖不會被判斷為「直接流量」，卻也不會被判斷為來自 facebook.com，如此一來便會造成數據收集上的錯誤。
因此如果你有使用短網址工具，請記得自行於「網頁檢查工具」的 console 頁籤透過 document.referrer 指令檢查網頁 referrer 欄位中的值，避免收集了一段時間的資料後才發現流量來源的判斷有誤。
「UTM 參數」設定錯誤
雖然前面有稍微提到，但我們還是要更詳細地解釋一下，因為使用「UTM 參數」進行追蹤已經是如同呼吸一般自然的追蹤設定，在過去的文章中我們已多次解釋過這個概念，也強調過規劃好「UTM 參數」架構的重要性，除此之外，還有一個很常見的錯誤就是：「打錯字」。
當使用者來到你的網站，referrer 欄位的參數如果為空值，雖然網址帶有「UTM 參數」，但卻很不幸地在設定參數時，有人把 utm_source 打成了 utn_source，導致 GA4 無法判別，最終將來源歸類為「直接流量」。
一般來說，只要使用 Google 提供的 URL Builder 進行「UTM 參數」的設定，就不太會遇到問題。問題通常是因為手動編輯網址時出現的錯誤，除了打錯字或是大小寫的差異以外，還可能會因為「UTM 參數」沒有正確放在「？」之後的位置而造成錯誤，正確應該為 www.abc.ocm/?utm_source=Awebsite，而不是其它奇怪的設置方式。
基本上，只要網址正確帶有有效的「UTM 參數」，即使網頁的 referrer 參數為空值，GA4 就不會將其歸類為「直接流量」。
使用者來自於「非網頁」類型內的連結
例如 PDF 、Word 或是 Excel 等類型的文件，如果這些文件中包含網站連結且沒有設置「UTM 參數」，由於沒有上一個頁面可以提供 referrer，因此網頁的 referrer 欄位會顯示為空值，這樣的訪問來源就會被歸類為「直接流量」。
順帶可以思考一個問題，如果連結是放在網頁版的 Google 雲端文件中，例如 Google 試算表或是 Google 文件，你覺得這個流量「來源/媒介」會怎麼顯示？（先別往下看，猜一下也好。）
ㅤ
ㅤ
ㅤ
ㅤ
ㅤ
ㅤ
答案是：google / organic
驚不驚喜？意不意外呢？ 竟然被歸類到自然搜尋了！
來自於信件的流量通常會被歸類為「直接流量」
例如，在 Gmail 中，雖然其收發信件是在瀏覽器內運作，但當使用者點擊其信件內的連結進入網站，該網頁 referrer 欄位也會為空值，此時就會被判斷為「直接流量」。（或是「來源/媒介」維度被判斷為 mail.google.com / referral ）
同理，如果是使用外部收發信件的程式，點擊郵件中的連結也會面臨相同的情況，這些流量來源同樣會被歸類為「直接流量」。
如果你希望來自信件中連結的點擊不要被歸類為「直接流量」，請記得在連結中加入 utm_source=email 或是 utm_medium=email，GA4 就會將其歸類到「電子郵件」預設管道群組當中，「預設管道群組」維度不會是 direct，「來源/媒介」維度也不會是 (direct) / (none)。
延伸閱讀：GA4 預設管道群組中的「Unassigned」是什麼？
從 HTTPS 到 HTTP
如果你的網站沒有使用 SSL 憑證，網址為 http://www.abc.com （注意，http 後面沒有 s），而該連結出現在其它有使用 SSL 憑證的網站，網址為 Https://www.ssl.com，那麽當使用者這個點擊連結時，由於瀏覽器的安全設置，將不會傳送 referrer 參數，此時該流量來源也會被判斷為「直接流量」。
因此，我們強烈建議，在建立網站時就應該配置 SSL 憑證。這已經成為現代網站的標準配置，請確保為你的網站安裝 SSL 憑證。
過去我們也在文章「 GTM 變數介紹：參照網址 (Referrer)」中，提到了瀏覽器因為安全性的原因，對於 referrer 參數的傳送有了諸多的限制，有興趣的朋友可以看看該篇文章中對於瀏覽器安全性限制的介紹段落。
不過呢，儘管後來網站安裝了 SSL 憑證，並將所有前往 http://www.abc.com 的使用者自動導向到 https://www.abc.com，此時網頁的 referrer 參數欄位依然「有可能」會是空值（因為中間還是經過 http > https 這段過程）。
因此，如果還記得那些非 https 的網址曾經放在哪些合作的網站上，務必請對方協助更新到最新帶有 https 的連結。
另一個解決方法是，將所有在外流浪的連結都帶上正確的「UTM 參數」，這樣儘管網址為 http 開頭，GA4 也能正確識別其來源，而不會將其歸類為「直接流量」。
ㅤ
如果你有實驗精神
你會發現，即使是將 http 開頭的網址貼在 Meta 其下的社群中，雖然是由 https 網站到 http 網站，但由於 Meta 自家的轉址技術，瀏覽器仍然能正確傳送 referrer 參數，因此 GA4 就能辨識出其正確的來源。
GA4 追蹤代碼沒有安裝到每個頁面
這是很常被忽略的錯誤。
因為流量「來源（Source）」只會紀錄在「到達網頁」上，如果你的網站有些頁面有安裝 GA4 追蹤碼，而有些頁面沒有，就可能導致錯誤的統計數據。
例如：使用者透過 Facebook 來到你的網站，預期網頁的 referrer 參數應當是 facebook.com。但如果首次訪問的頁面沒有安裝到 GA4 追蹤碼，之後使用者再瀏覽其它有安裝 GA4 的頁面，第二個頁面就會被認為是「到達網頁」，而來源是自家網站。
因為 GA4 會自動忽略來自相同網域的 referrer（你會在 Debug View 中看到 igonre _referrer=true ），此時因為沒有 referrr 參數，該來源就會被判斷為「直接流量」。
ㅤ
如何查找沒有安裝 GA4 追蹤碼的頁面？
如果你是透過 GTM 安裝 GA4 追蹤代碼，可以用以下方式檢查是否有頁面沒有被安裝到 GTM 容器，也就可以確定是否全站皆有覆蓋到 GA4 追蹤碼（前提是 GA4 追蹤碼的「觸發條件」沒有排除特定頁面。）
GTM 介面上方選擇「管理」頁籤 > 選擇「代碼涵蓋範圍」> 確認是否有沒安裝到代碼的頁面
這樣可以確保你的網站所有頁面都正確安裝了 GA4 追蹤碼，避免因部分頁面缺少追蹤碼而產生的數據問題。
「同意聲明工具」的影響
儘管你很確定所有頁面都有安裝 GA4 追蹤碼，但還有一個情況也會造成類似的結果，也就是使用者在首次造訪網站時，沒有立即點選「同意聲明工具」中的「拒絕」或是「接受」選項。
試想一個情況：如果使用者來到了網站，網站的「同意聲明工具」視窗跳出，但因為沒有完全覆蓋整個頁面，儘管使用者沒有選擇「拒絕」或「接受」，依然能夠繼續瀏覽網站。
等瀏覽到了第三頁時，使用者按下了「接受」，此時 GA4 追蹤碼才會啟動，這時第三頁變成了「到達頁面」，而 referrer 參數則會是自家網頁網址。
（因為真正的到達頁面沒有尚未獲得使用者同意，不能啟動 GA4 追蹤碼，而「來源」只會紀錄在「到達頁面」。）
這樣的情況會導致 GA4 將其視為 self-referrer，因此會直接忽略 referrer 參數，該「到達頁面」（實際上是第三頁了）流量來源也同樣會變成「直接流量」。
因此，如果你的網站有使用「同意聲明工具」，建議可以將其選單完全覆蓋整個網站，讓使用者在沒有選擇「拒絕」或「接受」之前，無法繼續瀏覽網站內容，從而避免因未選擇「同意聲明工具」選項而導致的來源數據錯誤。
延伸閱讀 》如何用 GTM 設定「Google 同意聲明模式（Consent Mode）」
留意是否有「被」轉址
如果網站最近有更換網址，或是做好的活動頁面剛上線不久便因為某些因素要更換網址，但舊網址已經在外面宣傳一段時間了，此時通常會透過 .htaccess 或是前端 Javascript 轉址的方式讓點擊舊網址連結的使用者可以被正確導入到新的網站頁面。
這樣的情況就很有可能會造成 referrer 參數的遺失或是原網址的「 UTM 參數 」遺失，進而導致該流量來源被誤判為「直接流量」。如果你發現網站的「直接流量」驟升，建議檢查一下其「到達頁面」是哪些頁面，並詢問行銷團隊最近是否有舉辦什麼活動且更改了網址，或是直接詢問工程師團隊是否有進行轉址的動作，請他們務必在轉址後保留原本的 referrer 參數或是「UTM 參數」。
（如果你可以點擊第三方網站的連結，也可以透過 Chrome 擴充套件 Redirect Path 來協助查找轉址的過程。）
連結是否被加入 noferrer
如果有跟第三方網站合作，注意對方是否有在連結加上 noreferrer 參數，如下圖：
只要在連結中加入了 rel="noreferrer"，瀏覽器就不會傳送 referrer 參數的值。如果要避免這樣的情況，除了請對方移除以外，我們也可以在網址加上「UTM 參數」，如此一來，儘管沒有 referrer，我們依然可以知道流量「來源」為何，GA4 也不會將其歸類為「直接流量」。
此外，除了在連結上設置 rel="noreferrer" 外，也可以觀察是否有在網頁上設定 Referrer-Policy，通常會放在 <head></head> 的區塊，如果有，那該頁面上所有連結都不會傳送 referrer 參數。
這些是保護使用者隱私的措施，但在追蹤和分析流量時，需特別留意這些設置可能帶來的影響。
流量機器人造成的「直接流量」
在觀察 GA4 流量報表時，如果妳發現突然出現一個不尋常的「尖尖」，且都來自於「直接流量」，進一步透過「國家/地區」維度觀察後，發現這些流量都來自於非你的網站目標客群所屬國家或地區，都常都是流量機器人所帶來的直接流量，如下圖：
流量機器人通常會帶來大量的直接流量，它們不像真實使用者那樣通過正常的瀏覽行為進入網站，而是通過自動化程式造訪網站，這些機器人通常不會傳送正確的 referrer 信息，因此被 GA4 誤認為「直接流量」。
關於這點，除非透過 Server Side GTM 來先行排除來自這些 IP 的機器人流量（但通常會一直更換），否則也愛莫能助。
GA4 也是會出錯的
如果已經依照上述這些情況一一檢查，但依然在某些日子突然的看到許多「直接流量」進站，可以問問相關社團、論壇以及群組的 GA4 夥伴們是否有遇到一樣的情況，如果有，那可能是 GA4 在處理資料時出了錯誤，通常過幾天之後就會好了。
（但是，千萬不要遇到什麼狀況都把錯歸給 GA4，就像是廣告成效不好都怪罪給演算法一樣，一定要先試圖找出可能的原因。）
總結一下
造成「直接流量」的原因其實不單單只是透過書籤、網址列、即時通訊軟體以及 App 這麼單純，因此，綜合上面幾項所述，我們可以歸納出幾點造成 Google Analytics 4 (GA4) 將流量判斷為「直接流量」的主要原因：
- Referrer 參數為空： 當網頁的
referrer或document.referrer欄位為空時，GA4 將流量歸類為「直接流量」。
ㅤ - 缺乏正確的 UTM 參數： 即使有
referrer參數，如果網址沒有帶上正確的 UTM 參數，GA4 也會將其判斷為「直接流量」。
ㅤ - 轉址過程中的遺失： 當網站經過轉址，原本的
referrer或「UTM 參數」可能會遺失，導致流量來源被誤判為「直接流量」。
ㅤ - Referrer-policy 限制： 如果網站設定了 Referrer-policy，限制了從其他網站傳送
referrer參數，則 GA4 可能無法正確識別流量來源。
ㅤ - 使用短網址： 部分短網址服務或特定情況下，可能導致
referrer參數的遺失或錯誤，進而使流量被歸類為「直接流量」。
ㅤ - 「UTM 參數」設定錯誤： 如果手動設置「UTM 參數」時出現打錯字或大小寫不正確，也可能導致 GA4 無法正確辨識來源。
ㅤ - GA4 追蹤碼安裝問題： 如果 GA4 追蹤碼未正確安裝在所有網頁上，或是安裝的觸發條件有缺漏，可能會導致部分流量來源被誤判為「直接流量」。
不過呢，儘管如此，我們還是無法完全排除並解釋所有非預期中的「直接流量」。
但可以確定的是，造成「直接流量」的因素越來越多，我們不能再以「直接流量」的多寡來判定品牌的聲量了（或許透過 GSC 以及關鍵字查詢工具會是更好的辦法），持續的監控和調整是保持準確數據的關鍵。
如果有其它可能造成「直接流量」的情況未在本文提及，歡迎留言回覆分享，我們可以一同更新，幫助更多人理解和解決這個問題。
延伸閱讀
如果你很喜歡這篇文章並且覺得內容有幫助，又剛有些多餘時間，歡迎你看看其它文章，繼續探索（這坑？這地獄？這片樂土？）
同時，如果對於內容有疑問或是建議，也歡迎你留言或是到社群上找我們，我們都會盡我們所知道的進行回覆：）
