網路流量中出現自我參照連結網址的原因

這項資訊只會套用至傳統版 Analytics (分析) JavaScript (ga.js)。瞭解您使用的是傳統版還是通用 Analytics (分析)，或是瞭解如何將傳統版 Analytics (分析) 升級為通用 Analytics (分析)。

如果您使用通用 Analytics (分析) (包括行動應用程式分析)，就不可能在報表中看到許多自我推薦連結。

背景

使用者來到您的網站時，Analytics (分析) 會判斷他們來自何方，也就是流量來源。流量來源可分為直接、隨機 (免費搜尋)、廣告活動或參照連結網址。

參照連結網址通常是指從其他網站進入您網站的流量。透過「客戶開發」類報表中的「參照連結網址」報表，您就可以分析這一類型的流量。

如何得知是否有自我參照連結網址？

Analytics (分析) 中的自我參照連結網址指的是以下情形：您看到自己的網域顯示在 [客戶開發] > [所有流量] > [參照連結網址] 報表中。舉例來說，如果您的網站是 www.example.com，凡是報表項目列出 www.example.com，都是自我參照連結網址。

如果您將 Analytics (分析) 的執行方式設定為跨多個網域和/或子網域評估工作階段，自然可能會看到少許自我參照連結網址。

不過，出現自我參照連結網址可能代表 Analytics (分析) 導入方式出現問題，除了會造成您的指標產生誤差，也會使您無法判斷站上轉換和其他互動實際應該歸入哪些流量來源。

判斷自我參照連結網址的來源

analytics.js

如果您的網頁標有 analytics.js 程式碼片段，請務必確認您已經將自己所有的自有網域 (包括子網域) 加進資源的參照連結網址排除清單：

  1. 登入 Analytics (分析) 帳戶。
  2. 按一下 [管理]，然後瀏覽至您所需的資源。
  3. 按一下 [追蹤資訊]。
  4. 按一下 [推薦連結排除清單]。
  5. 按一下 [+ 新增推薦連結排除項目]。
  6. 輸入您想排除的網域，然後按一下 [建立]。

 

ga.js

如果您的網頁標有 ga.js 程式碼片段，自我推薦連結形成的原因就不只一個，許多不同的情況其實都可能產生自我推薦連結。我們根據過去曾在客戶網站碰過的狀況，在本指南中列出了發生自我參照連結網址問題的常見原因。您可以將本指南當做檢查清單，追查出現自我推薦連結的原因。

為了協助您找出您的內容中可能有問題的區段，我們附上了以下檢視篩選器和自訂報表，或許能在您排除自我推薦連結問題時有所幫助。展開各小節即可瀏覽詳情：

查看篩選器

為找出自我參照連結網址的成因，請前往 [客戶開發] > [所有流量] > [參照連結網址] 報表。

當您看到其中一個自有網域的項目時，細查該列即可查看「參照連結網址路徑」維度。這些參照連結網址路徑可能是您網站上需要進一步調查的網頁。

透過參照連結網址路徑維度，您可以大概瞭解使用者瀏覽至您的網站前停留在哪個網頁。不過，根據預設，參照連結網址路徑不包含參照連結網址的查詢參數部分，但查詢參數可能是十分重要的資訊。我們必須建立檢視篩選器，才能看到包含查詢參數的完整推薦連結網址。

以下方的參照連結網址路徑為例：
/path/sub-path/?query=123&parameter=456

根據預設，參照連結網址路徑報表中只會顯示：
/path/sub-path/

請使用下列資料檢視篩選器，在 Google Analytics (分析) 報表中還原完整的參照連結網址路徑：

警告：為 Analytics (分析) 資料檢視套用任何篩選器前，強烈建議您先建立新的測試用資料檢視 (瞭解如何複製資料檢視)。您最好隨時保留一項未經篩選的資料檢視以供參考，這項資料檢視不但可當做原始資料備份，還可用來確定資料收集功能是否運作正常。

常用篩選器的建構方式如下所示：

filter for self-referrals

資源數據篩選器屬性

  • 篩選器名稱：顯示完整的參照連結網址 (包含參數)
  • 篩選器類型：自訂篩選器 => 進階
  • 欄位 A -> 解壓縮 A：廣告活動媒介，^referral$
  • 欄位 B -> 解壓縮 B：推薦連結，^https?://[^/]+(/.*)
  • 輸出至 -> 建構函式：廣告活動內容，$B1
  • 必填欄位 A：是
  • 必填欄位 B：否
  • 覆寫輸出欄位：是
  • 是否需區分大小寫：否
自訂報表
Download this custom report from our solutions gallery for a quick way to narrowing down the potential page(s) on your site that could have tracking code inconsistencies. 這份報表方便您成對比較同一份報表中的「推薦連結路徑」和「到達網頁」、「來源」和「參照網址路徑」，以及「主機名稱」和「到達網頁」維度。這樣一來，您就能找出導致自我推薦連結產生的網頁組合。

自我推薦連結的常見原因和解決方法

自我推薦連結有幾種常見的成因。展開各小節即可瀏覽詳情：

到達網頁上的追蹤程式碼遺漏或無法運作

自我參照連結網址之所以會產生，通常是因為站上的到達網頁或其他網頁並未標上 Analytics (分析) 追蹤程式碼。您可以利用 Google Chrome 的 Google Tag Assistant 外掛程式，找出追蹤程式碼遺漏和/或無法運作的問題。

您必須確保網站上「所有網頁」都已安裝 Analytics (分析) 追蹤程式碼。

使用上述自訂報表和資料檢視篩選器，即可追查出程式碼遺漏或毀損的網頁。

追蹤程式碼設定不一致

追蹤程式碼的設定不一致，也是自我參照連結網址的常見成因之一。下列方法會改變 Analytics (分析) Cookie 的設定，以及儲存在您網域上的方式。

在整個網站上叫用這些方法的方式必須一致，這一點非常重要。如果在您網站的同一個網頁甚至不同網頁中叫用這些方法的方式不一致，就可能導致 Analytics (分析) 重設或建立一組新的 Cookie。無論是哪一種情況，Analytics (分析) 都會嘗試判斷廣告活動的來源，而這正是發生自我參照連結網址的常見時機。

以下舉幾個例子來說明哪些情況會出現自我參照連結網址：

子網域追蹤範例：

子網域追蹤是一項常用設定。若要進一步瞭解子網域追蹤，請參閱本文。不過，有些網站使用了多個範本檔案，因而必須在多個位置插入 Analytics (分析) 追蹤程式碼 (也就是說，整個網站上不會都使用 Include)。在這種情況下，請檢查您範本中的每一個 Include，以確認它們包含一致的 Analytics (分析) 追蹤程式碼片段。

假設上例中的首頁和產品網頁使用一個範本，購物車網頁則使用另一個範本。

不正確

首頁： (www.example.com) 
	_gaq.push([‘_setAccount’, ‘UA-XXXXXXX-X’]);
	_gaq.push(['_setDomainName', 'example.com']);
	_gaq.push([‘_trackPageview’]);
購物車網頁： (basket.example.com) 
	_gaq.push([‘_setAccount’, ‘UA-XXXXXXX-X’]);
	_gaq.push([‘_trackPageview’]);

在上面的範例中，從首頁移至購物車網頁的使用者會產生 2 組用來代表工作階段的 Cookie (utma、utmb、utmz)，每個網域下各 1 組：

  1. example.com (首頁和產品網頁)
  2. basket.example.com (購物車)

不呼叫 _setDomainName 與呼叫 _setDomainName(‘auto’) 的效果相同。使用 document.domain 方法，將會導致 ga.js 為 basket.example.com 建立 Cookie。

為防止這種情況下產生自我參照連結網址，無論使用者是在頂層網域 www.example.com 或是子網域 basket.example.com，都必須讓 Analytics (分析) 從同 1 組 Cookie 讀取資料。

為了確保頂層網域和子網域使用同一組 Cookie，請在整個網站上的所有 Analytics (分析) 程式碼片段中加入 _setDomainName 這行程式碼。

解決方法：確保您的追蹤程式碼透過一致的方式呼叫方法，如果呼叫方法的方式不同，就會影響 Analytics (分析) Cookie 的定義方式。

正確

首頁： (www.example.com) 
	_gaq.push([‘_setAccount’, ‘UA-XXXXXXX-X’]);
	_gaq.push(['_setDomainName', 'example.com']);
	_gaq.push([‘_trackPageview’]);
購物車網頁： (basket.example.com) 
	_gaq.push([‘_setAccount’, ‘UA-XXXXXXX-X’]);
	_gaq.push(['_setDomainName', 'example.com']);
	_gaq.push([‘_trackPageview’]);

多重 Analytics (分析) 追蹤程式碼範例

多重追蹤器設定有許多客戶經常使用，但通常不受支援。這項設定可用來同時將資訊傳送至多個 Analytics (分析) 帳戶。

使用者通常對這項設定有一種誤解，那就是把每個追蹤器都假設成獨立實體 (或物件)，但 Cookie 其實是在網域層級而非追蹤器層級完成設定，因此同一個網頁上的所有追蹤器物件都會共用並讀取同一組 Cookie。

因此，就像上方子網域範例中所有網頁都使用一致的追蹤程式碼一樣，不同追蹤器物件中的追蹤程式碼也必須一致。

不正確

	_gaq.push(
	  ['firstTracker._setAccount', 'UA-XXXXX-1'],
	  [‘firstTracker._setDomainName’, ‘example.com’],
	  ['firstTracker._trackPageview'],
	  ['secondTracker._setAccount', 'UA-XXXXX-2'],
	  ['secondTracker._trackPageview']
	);

您是否注意到 secondTracker 並未呼叫 _setDomainName 方法？這可能會導致追蹤器以及網站資源 UA-XXXXX-1 和 UA-XXXXX-2 同時發生自我推薦連結問題。

解決方法：請務必確保同一個網域上所有追蹤器物件呼叫的方法相同 (也就是採用相同的設定)，以免追蹤器之間發生衝突。在下例中，兩個追蹤器一致呼叫 _setDomainName。

正確

	_gaq.push(
	  ['firstTracker._setAccount', 'UA-XXXXX-1'],
	  [‘firstTracker._setDomainName’, ‘example.com’],
	  ['firstTracker._trackPageview'],
	  ['secondTracker._setAccount', 'UA-XXXXX-2'],
	  [‘secondTracker._setDomainName’, ‘example.com’],
	  ['secondTracker._trackPageview']
	);

跨網域追蹤範例

Analytics (分析) 的另一種常見設定，則是跨多個頂層網域追蹤使用者活動。若要進一步瞭解跨網域追蹤，請參閱本文

假設您有 www.example.com 和 www.otherexample.com 這兩個網域，並想要追蹤使用者在這兩個網域上移動時發生的活動，您就必須使用下列其中一種方法：

您可以使用這些方法，在不同網域之間傳送 Analytics (分析) Cookie 資料。至於該使用哪一種方法，主要取決於使用者是透過何種方式在網域之間移動，例如點擊連結、送出表單或開啟 iFrame 等。

不過，我們發現了一個常見的問題，那就是有些連結、表單或 iFrame 為了在不同網域之間傳遞資訊而使用的代碼不正確。

範例 HTML 網頁 (位於 www.example.com 上)

不正確

	<html>
	<head></head>
	<body>
	     <a href="http://www.otherexample.com/" onclick="_gaq.push([‘_link’, this.href]); return false;">link 1</a>

	     <a href="http://www.otherexample.com/page2">link 2</a>
	</body>
	</html>

在上例中，link 1 已設定為將 Analytics (分析) Cookie 資訊傳遞至 otherexample.com，但 link 2 未包含 onclick 屬性。

系統會在不同的網域上正確追蹤按下 link 1 的使用者，且會將按下 link 2 的使用者記錄為來自 example.com 的一次推薦連結。

解決方法：請確認所有連結都使用了正確的代碼，以便將 Cookie 資訊從 example.com 傳遞至 otherexample.com。

正確

	<html>
	<head></head>
	<body>
	     <a href=”http://www.otherexample.com/” onclick=”_gaq.push([‘_link’, this.href]); return false;”>link 1</a>

	     <a href=”http://www.otherexample.com/page2” onclick=”_gaq.push([‘_link’, this.href]); return false;”>link 2</a>
	</body>
	</html>

訣竅：如果您有多個連至其他網域的連結，就可以利用 JavaScript 架構 (例如 jQuery) 來監聽將使用者傳遞至其他網域的 onclick 事件。

這是一種慣用的跨網域連結處理方法，不但能省下為每個連結手動加入代碼的麻煩，而且不會造成干擾。

網域之間的重新導向

本文將進一步說明重新導向，但跨網域追蹤時產生自我參照連結網址的問題還有一個常見原因：在 Analytics (分析) ga.js 從接收網域上的網址讀取跨網域 Cookie 資訊時，重新導向就移除了這些資訊。

讓我們再次回到先前的跨網域 HTML 範例：

範例 HTML 網頁 (位於 www.example.com 上)

	<html>
	<head></head>
	<body>
	     <a href=”http://www.otherexample.com/” onclick=”_gaq.push([‘_link’, this.href]); return false;”>link 1</a>
	</body>
	</html>

_link 方法會產生一個 Analytics (分析) 跨網域網址，如下所示：

http://www.otherexample.com/?__utma=117945243.497169939.1345210711.1359390130.1360067715.18&__utmb=117945243.3.10.1360067715&__utmc=117945243&__utmx=-&__utmz=117945243.1358253212.11.5.utmgclid=TeSt1234|utmcsr=(not set)|utmccn=(not set)|utmcmd=(not set)|utmcct=(not set)&__utmv=-&__utmk=258513226

不過，如果首頁發生了重新導向：

http://www.otherexample.com/

 

並將使用者導向至：

 

http://www.otherexample.com/home

重新導向可能會忘記要加入 Analytics (分析) 跨網域資訊，並將它傳遞至重新導向網址。

http://www.otherexample.com/?__utma=117945243.497169939.1345210711.1359390130.1360067715.18&__utmb=117945243.3.10.1360067715&__utmc=117945243&__utmx=-&__utmz=117945243.1358253212.11.5.utmgclid=TeSt1234|utmcsr=(not set)|utmccn=(not set)|utmcmd=(not set)|utmcct=(not set)&__utmv=-&__utmk=258513226

重新導向至：

http://www.otherexample.com/home

注意：缺少 Analytics (分析) 跨網域參數 (?__utma=......)。

這通常是因為許多伺服器端的重新導向程序沒有將前一個網址中出現的查詢參數列入考量。重新導向規則只將使用者從一個網址移往下一個，但沒有在重新導向期間保留這些 Cookie 參數。

解決方法：

  1. 確保重新導向會將 Analytics (分析) 追蹤參數帶到下一個網址，例如：

    http://www.otherexample.com/home?__utma=117945243.497169939.1345210711.1359390130.1360067715.18&__utmb=117945243.3.10.1360067715&__utmc=117945243&__utmx=-&__utmz=117945243.1358253212.11.5.utmgclid=TeSt1234|utmcsr=(not set)|utmccn=(not set)|utmcmd=(not set)|utmcct=(not set)&__utmv=-&__utmk=258513226

  2. 此外，您也可以移除重新導向，或是將上一個網域的連結目標改成新的位置，讓系統不叫用重新導向。

行動子網域

您是否使用行動子網域，或是在同一個網域上建立了行動專用版本的網站？

為網站建立一個可透過子網域 (例如：m.example.com) 存取的行動版本，是一種常見的做法。

如果您設定行動版本的網站使用伺服器端 Analytics (分析) 追蹤程式庫 (PHP、JSP、ASP.NET 和 Perl，通常也稱為 WAP 追蹤)，而使用者能夠在您網站的行動版本和完整版本之間切換瀏覽，您可能會看到來自行動和主要網域的自我參照連結網址。

如果您的行動網頁並未使用一般的 ga.js 追蹤程式碼，效果與在您的網站上使用無代碼網頁是一樣的。

WAP 追蹤程式庫的主要用途在於追蹤低階行動裝置 (也就是僅針對 Cookie 和/或 javascript 提供有限支援的裝置)。

不過，現在有許多最新的智慧型手機跟一般桌機一樣，都支援 JavaScript、Cookie 和圖片。由於智慧型手機的普及率越來越高，您的行動網頁最好停止使用 WAP 追蹤程式庫，並改用一般的 ga.js 追蹤程式碼片段。

重新導向和自我推薦連結

重新導向是否會導致自我參照連結網址產生？除了一種例外情況 (請參閱本文件中的跨網域一節)，大部分的重新導向應該都不會導致自我參照連結網址產生。讓我們來看看幾個重新導向的例子，以及它們對 Analytics (分析) 廣告活動設定造成的影響。

301/302 重新導向

這類重新導向是一種由伺服器端叫用的重新導向，且會傳送 HTTP 狀態碼 301 或 302。這類重新導向會由網站管理員負責導入，這通常是因為某個或某組網頁的位置改變。

301/302 重新導向必須保留原始推薦連結資訊。

範例：

在上圖中，一名使用者在 some-other-website.com 上按下了指向您首頁 (位於 example.com) 的連結後，伺服器端開始進行 301 重新導向，並將使用者轉到您首頁的新網址。

在這種情況下，301 重新導向應該保留來自 some-other-website.com 的參照連結網址資訊 (透過 javascript document.referrer 擷取)。

中繼重新整理以及採用 JavaScript 的重新導向

由非伺服器端叫用的重新導向 (例如中繼資料重新整理 HTML 代碼或 JavaScript window.location 方法) 可能會隱藏或遮掩 Analytics (分析) 中的參照網址資訊，因此不建議在可能是到達網頁的任何網頁上使用這種方法。

頁框

若要進一步瞭解搭配使用 iFrame 和 Analytics (分析) 的影響，以及自我參照連結網址產生的可能性，請參閱頁框網站和 Analytics (分析) 這篇文章。

Adobe Flash 追蹤

您是否使用 Flash 追蹤 API？在理想情況下，使用這類追蹤程式庫時，您應該採用 Bridge 模式而非 AS3 模式 (請參閱這裡的資訊)。在 Bridge 模式下，Flash 追蹤程式庫可與 Cookie 進行通訊，就像一般的 ga.js 追蹤程式碼一樣。因此，系統可以將 Flash 物件中的活動追溯回正確的廣告活動來源 (也就是用來找到您網站的來源)。

使用 AS3 模式時，程式庫會使用 Flash Cookie。為了判定廣告活動的來源，程式庫會尋找用來開啟 Flash 物件的參照連結網址，這通常是指您自己的網站 (頂層網頁)，例如：www.example.com。

這對您有幫助嗎？

我們應如何改進呢？

還有其他問題嗎？

嘗試以下步驟：

張貼到產品討論社群 向社群成員尋求答案
與我們聯絡 進一步說明相關資訊，我們會盡力協助您
true
learning path
選擇自己的學習路徑

歡迎使用 google.com/analytics/learn 這項新資源，瞭解如何發揮 Google Analytics (分析) 4 的最大效益。新版網站提供了影片、文章、引導式流程等多種資源，以及 Google Analytics (分析) Discord、網誌、YouTube 頻道和 GitHub 存放區的連結。

立即開始學習！

搜尋
清除搜尋內容
關閉搜尋
主選單
10155811000264770699
true
搜尋說明中心
true
true
true
true
true
69256
false
false