投放做到第二週，我開始懷疑報表裡那些行。同一批素材只走一個郵件渠道，後台卻把來源拆成兩行，一行寫 Newsletter，一行寫 newsletter，兩行加起來才對得上文件。另一件事更早埋下：營運發出去的連結裡活動名帶了一個空格，百分比編碼之後整串字元比文件裡的寫法長出一截，誰也說不出該以哪一條為準。這兩件都不是參數名記不住，我把那批連結逐條拆開對了一遍。
五個參數各自管一個維度
標準的五個鍵各回答一個問題：utm_source 是誰把流量送過來，utm_medium 走哪一類渠道，utm_campaign 屬於哪一次活動，utm_term 是付費投放的哪個詞，utm_content 是同一位置的哪版素材。維度之間是乘法關係，報表行數就是這麼來的。
- 來源 3 個、媒介 2 個、活動 4 個、素材 2 個，相乘是 48 條連結。
- 素材位先不分、只算到活動那一層，是 24 條。
- 同一個來源寫成大小寫兩種，按大小寫敏感聚合的口徑下各算一行，48 條變成 96 行；這個口徑看平台設定，不是所有分析工具都一樣。
- 取值裡有中文時長度還會再變：5 個字元的
拼音 转换編碼後是 39 個字元。 双十一 大促是 6 個字元，UTF-8 佔 16 位元組，編碼後 48 個字元，那個空格單獨佔%20這 3 個字元。
樣例連結的構成，按字元數記一遍
下面幾條是我文件裡的樣例，長度按 URL 字串本身的字元數記；? 不屬於任何一段，所以前兩欄相加不等於完整長度。
| 樣例 | 連結部分 | 參數部分 | 完整長度 | 參數狀態 |
|---|---|---|---|---|
落地頁自帶 from=push，補三個 utm | 44 | 78 | 123 | from 沿用原值，三個 utm 都是新增 |
舊連結已有 utm_source=weibo 等三條，活動名換成 nov-2026-beta | 44 | 67 | 112 | 三條 utm 覆蓋原值，id=88 沿用原值 |
| 落地頁帶錨點和中文查詢詞，補四個參數 | 34 | 98 | 133 | 原查詢詞沿用原值，四個新增，錨點仍在最後 |
落地頁帶埠號 :8080，補三個參數 | 49 | 68 | 118 | 三條都是新增 |
同一條落地頁補到四個參數，素材位寫 banner-top | 44 | 88 | 133 | 四條都是新增 |
換活動名那條最有用：同名參數只留一組，換成 nov-2026-beta 後連結裡不會同時掛兩組 utm_campaign，讀到哪一組就輪不到我們決定；id、from 這類非 utm 參數原樣帶走。
48 條逐條手拼不現實，我想兜住的是命名口徑。UTM 連結產生器 把五個參數拆成格子填，來源和媒介用渠道預設一次填成同一個小寫連字號名，自動做 percent-encoding，並逐條標出新增、覆蓋原值、沿用原值；批次變體每行一個取值，同批連結可以逐行比對；拼接在瀏覽器本機完成，不上傳。
編碼膨脹的是長度，不是含義
utm_content=拼音 转换
utm_content=%E6%8B%BC%E9%9F%B3%20%E8%BD%AC%E6%8D%A2| 框裡寫的值 | 拼進連結的形式 | 長度變化 |
|---|---|---|
拼音 转换 | %E6%8B%BC%E9%9F%B3%20%E8%BD%AC%E6%8D%A2 | 5 字元變 39 字元 |
双十一大促 | 每位元組展開成 3 個 %XX | 15 位元組變 45 字元 |
双十一 大促 | %E5%8F%8C%E5%8D%81%E4%B8%80%20%E5%A4%A7%E4%BF%83 | 6 字元 16 位元組變 48 字元 |
| 一個空格 | %20 | 3 字元 |
只把 utm_content 填成帶空格的中文取值，整條連結是 96 個字元，參數部分 51：含義沒動，字面長度卻變了。
加號是另一個口徑問題。加號只在表單編碼（application/x-www-form-urlencoded）裡表示空格，寫在 URL 的路徑或查詢字串裡它就是字面加號；兩種口徑混用會出現加號變空格那類事故。我的規則是取值裡不放空格，用減號分隔，寫 banner-top 而不是 banner top。只想核對一段編碼結果，用 URL 編解碼 就夠。
順序沒改語義，但改了字串
? 之後那串是鍵值集合，把 utm_campaign 寫在 utm_source 前面，落進分析工具還是同一組鍵值：
?utm_source=weixin&utm_medium=social&utm_campaign=oct-2026-release&utm_content=banner-top
?utm_campaign=oct-2026-release&utm_content=banner-top&utm_source=weixin&utm_medium=social但這是兩條不同的 URL 字串，按 URL 字串去重的口徑會把它們當成兩條記錄。我後來把順序固定：落地頁本身沒參數時按 source、medium、campaign、term、content 排，已帶參數的樣例裡被沿用或被覆蓋的保持原位，新增的接在後面。
Q：utm_term 要不要填？
只在講得出付費投放詞的時候填。搜尋引擎早就不給具體的自然搜尋詞，非付費渠道硬填 term 只是多一個沒有對照的維度；我這批的 medium 是 email，term 那一格整個留空，那批樣例連結裡也都沒有出現 utm_term。
Q：大小寫誰來統一？
沒有誰會替我們統一，值是我們自己寫進去的。按大小寫敏感聚合的口徑下 Weibo 與 weibo 是兩行，具體口徑取決於平台設定；我按敏感那種情況準備，取值表裡只留小寫連字號名。
Q：錨點 # 和 ? 的先後呢？
按我那條帶錨點的樣例，#top 仍然排在最後，參數插在 ? 與 # 之間；錨點不進查詢字串，也不參與這批參數的區分。
Q：手工拼和產生的區別在哪？
手工拼留下的是這一次的正確，產生留下的是可核對的東西：五個鍵一次填齊、同名參數標清覆蓋還是沿用、長度分開記。想弄清連結被切成哪幾段、查詢編碼在哪一步發生，URL 的分段與查詢編碼 講得比我這裡細。
回到開頭那兩行。來源被拆開，不是誰寫錯了參數名，而是同一個值有兩種字面寫法，報表按字面把它們分開了；帶空格的活動名和文件對不上，也不是編碼出了錯，它本來就該比原文長。我的取捨是：命名表先定，全小寫、減號分隔、同一活動全渠道同名比如 oct-2026-release，編碼留到最後一步統一做，參數順序固定成一套。這樣 48 條連結分給幾個人發出去，報表裡也該只有該出現的行；真變成 96 行，我知道先查哪一格混了大小寫，而不是懷疑統計。