【HubSpot】オリジナルソースと最新ソースの違い｜流入経路のたどり方

HubSpotのレポートで「オリジナルソース」と「最新ソース」の数字が食い違い、どちらを信じればいいか迷ったことはないでしょうか。GA4の数字とも合わず、説明に困った方もいるはずです。この混乱は1つの原則で大半が解けます。「オリジナルソースは最初の既知のソースを保持し、最新ソースは新しいセッションが成立するたびに更新される」という原則です。
分類一覧、判定ロジック、コンタクトの経路のたどり方、GA4との数字のズレの理由を整理します。

HubSpotのトラフィックソースとは

トラフィックソースとは、コンタクトがどの経路でサイトに流入しHubSpot上で認識されたかを示す分類軸で、施策の費用対効果を評価する土台になります。実務では「オリジナル トラフィック ソース」と「最新トラフィックソース」という2系統のプロパティが混乱の原因になりがちですが、オリジナルソースは「最初の接点」、最新ソースは「直近の接点」と押さえれば整理できます。以降は読みやすさを優先し、それぞれ「オリジナルソース」「最新ソース」と表記します。

役割には限界があります。この2つが示すのは入口と直近の接点であり、「どのチャネルが受注につながったか」を単独で確定するものではありません。受注への寄与を語るには、後述するアトリビューションレポートや商談の経緯とあわせて読む必要があります。

トラフィックソースの分類一覧

HubSpotは流入経路を次のように分類します。

「その他のキャンペーン」と「オフラインソース」は混同されやすいものの境界は明確です。前者は識別情報を取得できているもの、後者はデジタルの接点自体に結びついていないもので、成り立ちはまったく違います。

ダイレクトとオフラインソースは「受け皿」であることに注意

特に注意したいのが、ダイレクトとオフラインソースです。ダイレクトは「参照元もUTMもない」という消去法的な分類で、積極的にダイレクトと判定されているわけではありません。オフラインソースも同様に、既知のデジタルセッションに結びつかない接点やコンタクト作成をまとめて受け止めるカテゴリで、訪問経路だけでなくインポートやAPI連携による登録も含みます。

割合が高いとき、すぐ「誤分類だ」と結論づけるのは早計です。確認すべきは、流入経路（識別情報を付けずに配信している施策がないか）、コンタクトの作成方法（インポートやAPI連携で作られたレコードが多くないか）、計測状況（トラッキングコードの設置漏れやCookie同意の状況）の3点。UTM運用の整備は有効な改善策ですが、それだけですべて解消するわけではありません。

「オリジナルソース」と「最新ソース」の違い

ここが本記事の核心です。オリジナル トラフィック ソースは最初にビジネスと接点を持った際の「最初の既知のウェブソース」で原則変わりません。最新トラフィックソースは「最も直近の既知のウェブソース」で、条件を満たすたびに更新されます。それぞれに「ドリルダウン1」「ドリルダウン2」という補助プロパティが付随し、プラットフォーム名やキャンペーン名、URLなどの文脈情報を保持します。自動設定専用で手動編集はできません。

更新はいつ起きるのか。最新ソース系プロパティは「新しいセッションが作成されたとき」にのみ更新され、同一セッション内の回遊では変わりません。新しいセッションは、マーケティングフォームの閲覧・送信、予約ページの送信、サイトへの再訪問がきっかけになります。セッションは30分無操作で終了し、アカウントのタイムゾーンの深夜0時にも強制リセットされます。

もう1点、匿名訪問者が後からコンタクト化されたケースには注意が必要です。過去の匿名活動と一致すると、オリジナルソースが最も古い訪問時点まで遡って更新されることがあり、フォーム送信時の流入経路が必ずしもオリジナルソースとは限りません。この例外を知らないと、「なぜオリジナルソースが想定と違うのか」に答えられなくなります。

判定ロジック：UTMとリファラーの優先順位

トラフィックソースは、UTMパラメータとリファラードメインという複数のシグナルで判定されます。UTMパラメータが付いている場合は、その内容（email・cpc・social等）が優先されます。UTMがない場合はリファラードメインのみで判定され、オーガニック検索・リファラル・ダイレクトのいずれかに丸められやすくなる点に注意が必要です。

ダイレクトに分類される代表例は次の2つです。

• 参照URLが空（URLの直打ち、ブックマーク経由など）
• 参照元がHTTPSで自サイトがHTTPの場合、参照情報が失われる

これとは別に、流入情報や行動履歴を十分に取得できない状況もあります。トラッキングコード未設置ページでのフォーム送信や、訪問者が解析Cookieへの同意を拒否したケースです。同意を拒否した場合、HubSpotはトラッキングデータを収集しません。これらは「分類が正しくない」のではなく「判断材料が届いていない」状態で、対処法も計測の見直しになります。識別にはファーストパーティCookieを使うため、Cookieが使えない場合は識別や履歴の関連付けに制約が生じます。

UTMまわりでは性質の異なる2つの問題が混同されがちです。「UTMを設定していない施策がある」場合は識別情報が不足し、リファラーなど別の情報での分類になり見分けにくくなります。「UTMは付けているが命名が統一されていない」場合は文字列としてそのまま集計されるため、同じ施策がレポート上で複数行に分散します。前者は設定漏れの棚卸し、後者は命名規則の統一と打ち手が異なります。

1件のコンタクトから流入経路をたどる手順

個別のコンタクトがどこから来たかは、次の順序で読み解きます。

1. オリジナルソースで、最初の流入がどの分類だったかを確認する
2. オリジナル トラフィック ソース ドリルダウン1・2で、具体的なプラットフォーム・キャンペーン・URLを補う
3. 最新トラフィックソースと最新トラフィックソースの日付で、直近の接点がいつ・どこだったかを確認する
4. ウェブ上の接点が想定される場合は、アクティビティタイムラインをページ閲覧で絞り、1〜3の分類と時系列の矛盾を照合する
5. 履歴が見当たらない場合は、履歴の取得条件とコンタクトの作成方法を確認する

これらのプロパティは、コンタクトレコードの「ウェブアナリティクス履歴」セクションでまとめて確認できます。

5番目が重要です。ページ閲覧が計測されていても、コンタクトに紐づいて表示されるとは限りません。匿名の閲覧履歴がタイムラインに関連付けられるのは、Cookie同意の上でトラッキングコード付きフォームを送信するか、トラッキングされたマーケティングメールをクリックした場合です。手動作成・インポート・API連携のみのコンタクトは、この条件を満たすまで閲覧履歴が結びつきません。「タイムラインに何も出てこない」と感じたら、まずここを疑ってください。

複数のコンタクトをまとめて見たい場合は、オリジナルソースをディメンションにしたカスタムレポートが使えます。トラフィック分析ツールやアトリビューションレポートも有力ですが、必要なプランは契約や対象によって異なるため、着手前に確認しましょう。

※「不明なキーワード(SSL)」も同じ性質の表示

同じ「情報が届いていない」タイプの表示として、キーワードのドリルダウンに現れる「不明なキーワード(SSL)」があります。ソースレポートでオーガニック検索のセッション数をクリックすると、検索キーワード別の内訳が見られますが、その多くがこの値で埋まっているはずです。

これは検索エンジン側がユーザーデータを暗号化しているために起きるもので、たとえばGoogleはユーザーが入力した検索語をすべて暗号化しています。HubSpotの設定不備ではないため、こちら側で解消する手立てはありません。オーガニック検索のキーワードを知りたい場合は、Search Consoleなど検索エンジン自身が提供するツールを使うことになります。

有料検索でも同じ表示が現れますが、こちらは仕組みが少し異なります。HubSpotは訪問者のURLに含まれる「q」パラメータから検索語を取得し、値がなければ「utm_term」を参照します。どちらにも値がない場合にキーワードを特定できず、この分類にまとめられます。

応用：フォーム単位でソースを記録として残す

ここまで見てきたとおり、ソースプロパティはコンタクトに紐づく値です。オリジナルソースは最初の接点を保持し続ける一方、最新ソースは新しいセッションが成立するたびに更新されます。裏を返すと、2回目以降のフォーム送信がどの経路から来たのかは、どちらのプロパティにも残りません。「今回のセミナー申込は、どの流入経路の人が多かったのか」を後から振り返ろうとしても、コンタクトのプロパティを見るだけでは足りないわけです。

ここで有効なのが、送信の都度ソース情報を別のレコードに切り出して保存する設計です。フォーム送信をきっかけにチケットを作成し、その時点のコンタクトのソース情報をチケット側のプロパティに書き写します。コンタクトの値が次の送信で上書きされても、切り出した記録は残り続けます。フォーム別・時期別に集計できるようになり、ダッシュボードでの可視化にもつなげられます。

【構成の流れ】

1. チケットに転記用のカスタムプロパティを3つ用意する
   • トラフィックソース
   • トラフィック ソース ドリルダウン1（URL）
   • トラフィック ソース ドリルダウン2（メディア・サイト名）
2. フォーム送信でチケットが作成されるように設定する。
3. チケットベースのワークフローを作り、トリガーを「Record created」に設定する
4. 遅延アクションを挟む
5. 「レコードを編集」アクションで、チケットの転記用プロパティに、関連コンタクトの最新トラフィックソース系プロパティの値を設定する

遅延を挟む理由

この設計でいちばん重要なのが、4番目の遅延です。

チケットはフォーム送信の直後に作成されますが、コンタクトのソースプロパティが更新されるまでには時間差があります。遅延を入れずに転記すると、更新前の値、つまり前回の流入経路をコピーしてしまう恐れがあります。エラーにはならず、それらしい値が入ってしまうため、後から気づきにくいのが厄介なところです。

適切な待ち時間は環境によって変わります。自社の環境でフォームを送信し、コンタクトのソースプロパティがいつ更新されるかを実際に計測したうえで、余裕を持たせた値を設定してください。
弊社の環境では7分後には更新が確認できたため、その値を採用しています。

転記するのは「最新ソース」

転記元に選ぶのは、オリジナルソースではなく最新トラフィックソース側です。オリジナルソースは最初の接点で固定されるため、今回のフォーム送信がどこから来たのかを知りたいという目的には合いません。直近の接点を保持する最新ソースを、送信のたびにスナップショットとして切り出すことになります。

ドリルダウン1（プラットフォーム名やURL）とドリルダウン2（キャンペーン名など）もあわせて転記しておくと、分類だけでなく具体的な流入元まで追えるようになります。

運用上の注意

ワークフローの再登録はオフのままにしてください。チケット作成時点の値を一度だけ記録するのが目的であり、再登録を有効にすると後から値が書き換わる可能性があります。

また、HubSpotはより正確なデータを取得できた場合にアナリティクスデータを再処理すると明記しています。転記した値はあくまで転記時点のスナップショットであり、後からコンタクト側の値が変わってもチケット側は追随しません。厳密な一致を前提とせず、傾向を掴むためのデータとして扱うのが実務的です。

ダッシュボードで見えるようになるもの

記録が溜まってきたら、あとはレポートに起こすだけです。チケットをデータソースにしたカスタムレポートを作り、フォームごとの分類名で絞り込んだうえで、転記したトラフィックソースをディメンションに置きます。これで「このフォームからの申込は、どの流入経路が多いのか」がフォーム単位で見えるようになります。

面白いのは、フォームを横に並べたときです。セミナー申込は広告経由が中心、資料ダウンロードはオーガニック検索が中心、といった具合に、同じサイト内でも入口によって流入構造がまったく違うことがよくあります。コンタクトのプロパティを眺めているだけでは気づけない差で、施策ごとの評価軸を分けて考えるきっかけになります。

ドリルダウン1・2もあわせて転記しておけば、リファラルの内訳を参照元ドメイン別に見たり、キャンペーン名で並べたりといった掘り下げもできます。期間で区切れば、施策の前後で流入経路がどう変わったかも追えます。

ここまでくると、冒頭で触れた「どのチャネルが受注につながったか」という問いにも一歩近づきます。とはいえ、これで確定できるわけではありません。フォーム送信という一点の記録である以上、そこに至るまでの複数の接点は依然として見えないままです。あくまで、判断材料が一つ増えたと捉えるのが適切です。

GA4と数字が合わない理由、どちらを正とするか

HubSpotとGA4の数字を突き合わせて「合わない」と感じた方は多いはずです。HubSpot公式も、両者は近い値になっても一致は期待すべきでないと説明しています。差異が生まれる主な要因は次の通りです。

• セッション定義が異なる（HubSpotは深夜0時にもリセット）
• 分類粒度が異なる（HubSpotは参照ドメイン単位、GA4はソース/メディア単位）
• アトリビューションモデルが異なる
• Cookie同意時の挙動が異なる場合がある

比較の前に確認すべきは、両者で同じものを見ているかです。対象（訪問者かコンタクトか）、指標、期間がずれていれば、数字が一致しないのは当然です。特に混同されやすいのが、HubSpotのオリジナルソースとGA4の指標の対応関係です。GA4の「最初のユーザーの参照元」は初回接点を見る目的が近い指標ですが、定義も母集団も同じではないため一致確認には使えません。訪問ごとに値が変わる「セッションの参照元」と並べるのは、なおさら意味がありません。

社内で説明を求められたときは、数字が違うのは異常ではなく計測の目的・対象・セッション定義・分類方法が違うからだと伝えましょう。用途を分け、各ツール内では増減のトレンドを追い、ツール間で絶対値の一致を前提にしないのが実務的です。受注や商談への紐付けはHubSpot、サイト内の行動分析はGA4、と役割を分けるのが現実的です。

運用の勘所とまとめ

最後に、実務のポイントをまとめます。まず、UTMの命名規則を最初に決めチーム全体で統一すること。表記が揺れるとレポートが分散し、施策単位の集計や比較が難しくなります。次に、オフライン施策はオンラインで計測できる接点がある場合に限って識別情報を設計しておくこと。案内先URLに識別情報を持たせれば、後から手作業で紐付ける必要がなくなります。加えて、フォーム経由の問い合わせを取りこぼさないよう、トラッキングコードの設置状況を定期的に確認することも欠かせません。

オリジナルソースは最初の既知の接点を保持する値、最新ソースは新しいセッションの成立にあわせて更新される値です。この違いを理解しUTM運用とレポートの見方を整えれば、トラフィックソースを自信を持って説明できるようになります。データ品質全般の考え方は「HubSpotが「ゴミ箱」化するのを防ぐ5つの習慣」、ソース別のレポート作成は「HubSpotで保存済みビューを作成・管理する方法」もあわせてご覧ください。

分類ルールの整理やUTM命名設計、レポートの組み立てを自社だけで進めるのが難しい場合は、データ品質・運用設計の支援を行うハレフルへお気軽にご相談ください。

→お問い合わせはこちらから