UTM 建立器範例是一個完整的逐步說明,展示從一個普通的目的地 URL 到一個已標記的 campaign 連結的完整轉換過程,說明每一個輸入的值與每一個輸出的字元。下面的範例使用一個真實的登陸頁面網址以及三個必要的核心 campaign 欄位——source、medium 與 campaign——讓手動 campaign 標記的運作方式變得具體而不抽象。建立器接受一個完整的 http 或 https 網址,加入五個傳統的 UTM 參數,保留目的地路徑、URL 片段以及任何無關的查詢參數值,並回傳一個可直接貼到廣告、電子報、QR code 或合作夥伴版位的完成連結。第二個範例展示如何在不遺失 gclid 或 ref 等參數的情況下,重新整理一個既有的已標記連結。輸出僅只是一個建構好的 URL——這個工具不會檢查分析資料、重新導向、歸因或已簽署 URL 的簽章——而且所有資料都不會離開瀏覽器。

utm builder example
UTM 建立器範例:從 URL 到已標記的 Campaign 連結

從普通 URL 到已標記連結:完整實例

想像一個小型行銷團隊需要將付費搜尋流量導向一個春季產品上市的定價頁面。目的地一開始是一個乾淨、沒有 campaign 資訊的網址:

https://example.com/pricing

團隊打開 UTM 連結建立器,貼上網址,並輸入三個符合他們回報慣例的標籤:utm_source 為 google、utm_medium 為 cpc、utm_campaign 為 spring-launch。Term 與 content 留空,因為搜尋廣告在他們的回報設定中並未區分關鍵字或創意變化。建立器立即回傳一個完成的連結:

https://example.com/pricing?utm_source=google&utm_medium=cpc&utm_campaign=spring-launch

路徑維持不變。三個查詢參數被附加在後。結果是一行可以直接貼到 Google Ads 最終 URL 欄位、電子報範本、QR code 或合作夥伴版位試算表的內容,無需再編輯。建立器會顯示這個完全相同的輸出,讓團隊在上線前能確認標籤拼字正確且位於正確的位置。

建立 Campaign 連結的三個步驟

  1. 將完整的 http 或 https 目的地 URL 貼到建立器中。相對路徑、mailto 連結與非網頁通訊協定會被拒絕,因為此工具僅限用於網頁 campaign 目的地。
  2. 輸入 campaign 的 source、medium 與 name。僅在回報慣例確實使用時,才加入 utm_term 或 utm_content。三個核心欄位為必要,以確保產生的連結不會缺少 Google Analytics 指南中說明的手動 campaign 欄位。
  3. 建立 URL,檢視保留的參數與片段,然後將結果複製到廣告、電子郵件、社群貼文或 QR code。連結會立即顯示並保留在瀏覽器中。

選用的第四與第五個參數與必要的前三個行為不同。當 term 或 content 欄位為空時,建立器會將該參數從輸出中省略,而非加入空值。較短的連結較容易檢查,並能減少報表之間標籤的意外變化。值會經過 URL 編碼,因此 campaign term 中的空格會在最終網址中變成有效的字元序列。

已標記 Campaign URL 的結構

參數用途上述範例使用的值是否必要?
utm_source流量的來源google是
utm_medium行銷管道cpc是
utm_campaigncampaign 名稱spring-launch是
utm_term付費關鍵字(舊式)(留空)否
utm_content廣告創意或版位變化(留空)否

Source 用來識別來源——可能是搜尋引擎、電子報、社群網路或合作夥伴網站。Medium 用來識別管道,例如 cpc、email、social 或 affiliate。Campaign 用來識別活動,通常包含季節、上線或產品名稱。Term 最常用於付費關鍵字追蹤。Content 最常用於在同一個 campaign 內區分不同創意、版位或 A/B 變體。建立器僅管理這五個鍵,這也是下一節將重點放在 URL 其他部分會發生什麼的原因。

更新已標記連結而不遺失其他參數

許多登陸頁面已經帶有必須在 campaign 更新時保留下來的查詢參數。一個頁面可能包含 ref=homepage 用於推薦欄位、語言切換器,或像 gclid 這樣的 Google 點擊識別碼。從一個已經帶有這些值的已標記連結開始:

https://example.com/pricing?ref=homepage&gclid=abc123&utm_source=facebook&utm_medium=social&utm_campaign=winter-sale

團隊希望為新的 campaign 重新啟動這個連結,並且只更換三個核心標籤。他們將現有連結貼到 UTM 連結建立器中,並輸入 source 為 newsletter、medium 為 email、campaign 名稱為 march-sale。建立器只會移除它所擁有的三個 UTM 鍵,保留 ref=homepage 與 gclid=abc123,然後附加新的值:

https://example.com/pricing?ref=homepage&gclid=abc123&utm_source=newsletter&utm_medium=email&utm_campaign=march-sale

目的地路徑、片段以及任何無關的參數都維持不變。這就是建立器僅限於剛好這五個傳統鍵的實際原因:它能夠在不手動重建目的地網址的情況下更新 campaign。對於經常執行此作業的工作流程,請參考 如何在不破壞既有標記的情況下建立 UTM 連結。

UTM 建立器範例的限制

建立器範例展示的是建構,而非驗證。完成的 URL 已準備好可以複製,但工具本身不會檢查分析資源是否存在、自動標記是否啟用、重新導向是否會去除查詢參數、同意設定是否會抑制點擊,或未來的流量是否會出現在特定報表中。在發布重要的 campaign 連結之前,請在開啟回報檢視的真實瀏覽器中進行測試。

已簽署或預先簽署的 URL 不應通過建立器處理。瀏覽器的 URL API 可能會正規化查詢編碼,這將導致簽章失效。請改用一個普通的目的地 URL 作為起點。

Campaign 標籤應描述版位,而非個人。查詢參數可能會儲存在瀏覽器記錄、推薦日誌、分析系統與共用連結中,因此姓名、電子郵件地址、電話號碼與帳號都不應出現在任何 UTM 欄位中。一套簡單的團隊慣例——例如 source 為 google、medium 為 cpc、campaign 為 spring-launch——能讓報表比自由填寫的值更一致且更容易閱讀。建立器會在去除意外的外側空白後保留所輸入的文字,而不會自創分類法或變更大小寫。

最後,這個工具不會發出任何網路請求。目的地 URL 與 campaign 標籤都保留在瀏覽器中,這也是此類建立器能適用於不應被送到第三方伺服器的敏感內部目的地網址的主要原因。對於簡短的公開 URL,請先確認該服務在重新導向鏈中會保留查詢字串,再使用可信的重新導向或短網址服務。

如果您正在權衡各種選項,在匯出前避免批量 URL 產生器的錯誤 對此有詳細說明。