UTMパラメータの命名規則｜GitLabの公開ルールとGA4の判定条件

UTMパラメータは、リンクの末尾に付けて流入元を記録するための文字列です。付け方そのものは難しくありません。Google アナリティクスのヘルプにも、URLにパラメータを足すときは utm_source、utm_medium、utm_campaign を必ず使うように、と書かれているだけです。

つまずくのはその先です。どの欄に何を書くかを、組織として先に固定できるか。ここが決まっていないと、同じ広告なのに担当者ごとに Facebook と facebook が混ざり、メール施策の名前が「9月ウェビナー」「webinar_sep」「sept-webinar」に散らばります。集計の段階でその全部を人力でまとめ直すことになり、そこで力尽きます。

決めることは3つです。値を有限のリストにすること、複数の情報をまとめる欄の並び順と区切り文字を固定すること、そしてUTMを付けない場所を決めること。この3つを実際に文書にして、社外から読める場所に置いている会社があります。GitLabです。

この記事では、GitLabが公開しているUTM設計のページに実際に書かれている内容を引きながら、日本語のチームがそのまま移せる部分と、自社の計測ツールに合わせて読み替える必要がある部分を分けます。あわせて、同じ値をGoogle アナリティクス4（GA4）で使ったときに、既定のチャネルグループがどう判定するかを突き合わせます。確認日は2026年9月9日です。

GitLabは自社のUTMルールを外に出している

GitLabは、社内の業務手順を「ハンドブック」として公開しています。マーケティングの節もその一部で、UTMの設計はその中の1ページです。宣伝用に整えた資料ではなく、社内の担当者が実際に参照する手順書がそのまま外から読める形になっています。

ページの冒頭には、目的がこう書かれています。

The purpose of this handbook page is to outline how our UTM strategy drives insightful dashboards in Sisense. You may learn how to use the UTM builder, and why it is critical that we use this consistent process across all marketing channels for consistent and useful reporting.

一貫した手順をすべてのチャネルで使うことが、なぜ重要なのか。UTMを「計測のためのおまけ」ではなく、ダッシュボードを成り立たせる前提として位置づけていることが分かります。

もう1つ、運用の面で見ておきたい記述があります。

Everyone can contribute - See something you’d like to discuss or iterate on? Start an MR and post it in #mktg-analytics slack channel.

議論したいことや直したいことがあれば、マージリクエストを出して所定のSlackチャネルに投げてほしい、という案内です。命名規則は、決めた瞬間から現実とずれ始めます。変更を提案する経路が文書の中に書いてあることは、規則の内容そのものと同じくらい実務的な意味を持ちます。

そしてリンクにUTMを付けるかどうかの原則が、次のように置かれています。

As a general rule, when a link directs to a website GitLab controls, UTMs should be added to the link.

自社が管理しているサイトへ送るリンクには付ける、という単純な基準です。裏返せば、それ以外には付けません。この線引きは後半でもう一度扱います。

4つの欄は、それぞれ粒度が違う

UTMの欄をどう使い分けるかは、原文の説明が分かりやすい形になっています。utm_medium については、こう書かれています。

Campaign Medium is the overarching channel bucket like email, display, etc. It answers the question of “How did they come to us?”. utm_source will further categorize the overarching channel.

まず大きな区分としてのチャネルがあり、utm_source がその中をさらに細かく分ける、という関係です。同じ「どうやって来たか」という問いに、粒度を変えて2回答えていることになります。

この入れ子の関係が頭に入っていないと、utm_campaign に配信システムの名前を入れたり、utm_source に施策名を入れたりする書き方が生まれます。1件ずつ見れば意味は通じますが、まとめた瞬間に集計軸として使えなくなります。

utm_medium は自由入力をやめて、12個の値から選ぶ

GitLabのハンドブックには、utm_medium に使える値が列挙されています。担当者が考えて書くのではなく、この中から選びます。

値	ハンドブックの説明
email	Marketo、Outreach、Mailjet、Highspot などすべてのメール配信
cpc	検索連動型広告
display	ディスプレイ広告
paidsocial	SNSの広告
social	SNSの通常投稿
sponsorship	媒体社との有料の取り組み・スポンサーシップ
chat	サイト上の会話型ボット
pdf	ホワイトペーパー、電子書籍、レポートの中のリンク
referral	顧客レビューサイト
syndication	第三者によるコンテンツシンジケーション
webinar	第三者が主催する協賛イベント
video	自社が持つ動画

注目したいのは、リストの長さではなく増やし方が書いてあることです。新しい区分が必要になったときは、指定されたSlackチャネルへ依頼する、と決められています。同じことが utm_source にも書かれており、値の一覧はスプレッドシートのピックリストとして管理され、追加するときは記号を使わず小文字でそろえる、という書き方の作法まで添えられています。

日本語のチームがここから持ち帰れるのは、値そのものより手順のほうです。選択肢を先に用意し、足りないときの窓口を1か所に決める。この2つがないと、リストは3か月で形骸化します。

utm_campaign は、1つの欄に7つの情報を詰めている

GitLabの設計でいちばん特徴的なのが utm_campaign です。施策名を1つ書くのではなく、複数の情報を決まった順序で連結します。

Date_Region_Budget_Type_gtm_[Language]_[campaign_name]

ハンドブックに載っている実例で見ると、次のようになります。

なぜここまで詰め込むのか。理由もページに書かれています。

Encoding more data on the UTM campaign directly transfers that information to Bizible touchpoints and allows for drop-down / point and click reporting in SFDC.

情報を値の中に埋め込んでおけば、それがそのまま接点のデータへ移り、営業側のシステムでも選択式のレポートが作れる、という説明です。つまりこの連結は、見た目を整えるための書式ではなく、後で機械的に分解して集計軸に戻すことを前提にした設計です。

そう考えると、必須の区画で「該当しない場合は x を入れる」と決めてあることの意味がはっきりします。空欄にしてアンダースコアを詰めてしまうと、区画の位置がずれて分解できなくなります。常設の施策は日付の代わりに eg を入れる、複数地域にまたがる場合は地域に x を入れる、というのも同じ理由です。欄の数を必ず一定に保つための約束ごとです。

日付を先頭に置いている点も、実務では効きます。文字列を並べ替えるだけで時系列になり、四半期ごとの抽出も前方一致でできます。これはGitLab固有の事情ではなく、連結の順序を決めるときに一般に使える判断です。

utm_content は「オファー名」と「資産の種類」でそろえる

utm_content も自由記述ではありません。オファー名と資産の種類、必要なら業種を、この順で連結します。資産の種類にも一覧があります。

値	対象
ebook	登録が必要な電子書籍
whitepaper	ホワイトペーパー
blog	ブログ記事
video	動画
briefs	ソリューションブリーフ
infogr	インフォグラフィック

ハンドブックに載っている例は utm_content=devguideappsec_ebook や utm_content=seccspackage_ebook_fs です。前半がオファーの名前、後半が資産の種類にあたります。ここがそろっていると、「電子書籍とホワイトペーパーではどちらが登録につながったか」を、施策をまたいで比べられます。

ナーチャリング用のメールについては、utm_content に nurture と書かないように、という指示が明記されています。理由までは書かれていません。推測はせずに、そう決められている事実として読みます。ナーチャリングであることは施策側の情報であって、制作物の名前ではない、という整理だと考えると、上で見た入れ子の関係とは矛盾しません。メールの設計そのものはメールマーケティングのやり方で扱っています。

UTMを付けない場所を、先に決めておく

命名規則の話は「どう書くか」に集まりがちですが、GitLabのページは付けない場所にも同じだけ紙幅を割いています。

同じドメインの中を移動するリンクにUTMを付けてはいけない理由が、はっきり書かれています。

If UTMs are detected within an internal gitlab.com link, a new session will be counted, and conversion attribution will be overridden by the new UTM parameter values. The original source will not receive proper credit.

同一ドメイン内のリンクにUTMが検出されると新しいセッションとして数えられ、後から付いた値で成果の割り当てが上書きされる。もとの流入元は正しく評価されない、という説明です。これは自社サイトの内部リンクにキャンペーンURLを流用したときに起きるもので、実務でよく見る取り違えです。着地ページに付いていれば、その先の内部リンクには要りません。

流入元の評価そのものをどう扱うかはGA4のアトリビューションの側の話になります。UTMは、その手前で「材料をそろえる」工程だと考えると位置づけを間違えません。

GA4の既定のチャネルグループは、mediumの文字列を見ている

ここまではGitLabの設計です。ただしGitLabはBizibleとSalesforce、そしてダッシュボード側で集計する前提で値を決めており、GA4に合わせて作られたものではありません。同じ値をそのままGA4で使うと、既定のチャネルグループがどう判定するかは別の話になります。

GA4のヘルプには、既定のチャネルグループの条件が公開されています。手入力の流入について主なものを挙げると、Emailは「Source = email|e-mail|e_mail|e mail OR Medium = email|e-mail|e_mail|e mail」、Displayは「Medium is one of (“display”, “banner”, “expandable”, “interstitial”, “cpm”)」、Referralは「Medium is one of (“referral”, “app”, or “link”)」、Organic Videoは「Source matches a list of video sites OR Medium matches regex ^(.*video.*)$」です。

これをGitLabの12個の値に当てはめると、こうなります。判定の条件はGoogleのヘルプの記載、当てはめは当社によるものです。

GitLabの utm_medium	GA4の既定のチャネルグループ
email	Email
cpc	sourceが検索サイトの一覧に一致すればPaid Search、しなければPaid Other
display	Display
paidsocial	sourceがSNSの一覧に一致すればPaid Social、しなければPaid Other
social	Organic Social
referral	Referral
video	Organic Video
sponsorship chat pdf syndication webinar	どの条件にも一致しない

最後の行が実務上の分かれ目です。GA4は、どの規則にも当てはまらない流入をUnassignedとして扱うとヘルプに明記しています。GitLabの値をそのまま持ち込むと、スポンサーシップや資料内のリンクからの流入が、レポート上は行き先のない箱に入ることになります。

さらに、Paid SearchとPaid Socialが utm_medium だけでは決まらない点にも注意が要ります。どちらも「sourceが所定の一覧に一致し、かつmediumが ^(.*cp.*|ppc|retargeting|paid.*)$ に一致すること」が条件です。medium側を整えても、source側の表記が独自だと分類が変わります。

もう1つ、GA4のヘルプは値の大文字と小文字を別のものとして扱うと明示しています。utm_source=google と utm_source=Google は別の値です。GitLabがピックリスト側で「小文字でそろえる」と書いているのは、この性質と正面から噛み合っています。広告側の設定と合わせて確認する手順はWeb広告の効果測定にまとめています。

公開されているルールにも、ゆれは残っている

このページを読むときに気づいておきたいのは、公開されている手順書でも表記のゆれは残るということです。確認日時点で、次の点が目に付きました。

1つ目は、パートナー向けのパラメータです。冒頭の例示URLでは utm_partner_id と書かれ、その直後の箇条書きでは utm_partnerid と書かれています。実装上はどちらか一方しか動きません。

2つ目は、utm_medium に定義されていない値が別の節に出てくることです。ABM（企業を指定した施策）の節では medium に banner を、パートナー向けの節では partner を使うと書かれていますが、どちらも12個の一覧には入っていません。ちなみに banner はGA4の既定ではDisplayに入り、partner はどの規則にも当てはまりません。

3つ目は、URLを組み立てる手順の説明に utm_budget という欄が出てくるものの、その値の定義がページ内に見当たらないことです。予算区分は utm_campaign の3番目の区画としても登場します。

4つ目は、集計先の名前です。冒頭ではSisenseのダッシュボード、別の箇所ではTableauのダッシュボードと書かれています。

これを「だから参考にならない」と読むのは違います。運用が続くかぎり、規則と現実は必ずずれます。ずれることを前提に、提案の経路（マージリクエストとSlack）と、値を追加するときの窓口が文書の中に置いてあること。手順書として学ぶべきなのはそちらです。公開されている社内文書の読み方そのものは、文章のガイドを扱ったブランドボイスの決め方でも同じ論点に触れています。

命名規則は、依頼の受け方とセットで決まっている

規則を書いただけでは守られません。GitLabのハンドブックには、メール施策を担当するチームの受け付け方も公開されています。緊急の依頼は当日中に返答、通常の依頼は2営業日以内、メール施策は最低5営業日前までに依頼すること、と書かれています。依頼は所定のテンプレートから起票し、簡単な質問はSlackで受けるが、正式な依頼は記録が残る形にする、という運用です。

命名規則が崩れるのは、たいてい締め切りの直前です。「今日中に配信したいので、URLは後で直します」が積み上がって、集計できないデータになります。リードタイムを先に宣言しておくことは、規則を守らせるための仕組みの一部です。指標の設計と合わせて考えるならKPIレポートの作り方も同じ枠組みで読めます。

自社で先に決める4項目

最後に、日本語のチームが着手するときに先に決めておく項目を整理します。項目と順序は当社によるもので、GitLabがこの4項目を推奨しているという意味ではありません。

1つ目は、utm_medium と utm_source を有限のリストにすることです。作るときに、自社が使う計測ツールの分類条件と突き合わせてください。GA4を使うなら、既定のチャネルグループの条件に載る値かどうかを1つずつ確かめます。載らない値を使うなら、それを承知のうえでカスタムのチャネルグループを作る判断になります。

2つ目は、utm_campaign の中身です。複数の情報を連結するなら、並び順、区切り文字、該当しないときの書き方を同時に決めます。ここを決めずに連結だけ始めると、区画の数が人によって変わり、分解できない文字列が残ります。

3つ目は、付けない場所です。自社ドメイン内のリンク、外部サイトへのリンク、SNSのプロフィール欄など、迷いやすい場所を名指しで書いておきます。

4つ目は、追加と変更の窓口です。誰に言えば値を増やせるのか、決まったことはどこに書かれるのか。これが1か所に決まっていない規則は、運用の中で自然に消えます。

この記事で確認できたこと

GitLabは、UTMの設計を社外から読める手順書として公開しています。utm_medium は12個の値から選ぶ形にして自由記述をやめ、utm_source の追加にも窓口を決めています。utm_campaign は日付・地域・予算区分・施策の種類・訴求の枠・言語・施策名を決まった順序で連結し、該当しない区画には x を入れて欄の数を保ちます。utm_content はオファー名と資産の種類で構成します。そして自社ドメイン内の移動と外部サイトへのリンクにはUTMを付けません。

一方で、同じ値をGA4で使うと、sponsorship や pdf のように既定のチャネルグループのどの条件にも当てはまらない値が出ます。命名規則は、計測ツール側の判定条件と突き合わせて初めて完成します。ハンドブックの中には表記のゆれも残っていましたが、提案の経路と追加の窓口が文書に書かれている点が、規則を運用し続けるうえでの実際の要でした。

海外企業が公表している取り組みを扱った記事は海外マーケティングにまとめています。