問い合わせのアトリビューションはどう計算すべきか:First Touch、Last Touch、12種のClick ID
1. 根本的な問題:多くのサイトのアトリビューションデータは源流から汚れている
まず「モデルを選ぶ」前に起きる、実際によくある4つの誤りを見てみましょう。
| 誤り | パフォーマンス | 結果 |
|---|---|---|
| 同一ドメイン内の遷移が未除外 | 顧客が記事ページから商品ページへ移動し、「新しいソース」として記録される | 自然流入が過大評価され、二重計上される |
| 直接アクセスが初回接点を占める | 顧客の初回訪問はGoogle経由なのに、初回接点が「直接アクセス」として記録される | 初回接点チャネルがすべて歪む |
| Click IDが期限切れで失われる | 広告クリックから30日後にコンバージョンし、gclidがすでに失われている | 広告効果が過小評価される |
| アクセス環境をチャネルと混同 | WeChat内蔵ブラウザが「チャネル = WeChat」と扱われる | 有料チャネルとWeChatが混ざり、どちらが効いているか判断できない |
これら4つの問題が重なると、アトリビューションレポートは「見た目は完全でも、実際には使えない」ものになります。したがって正しい順序は、まずデータソースを直し、それからモデルを選ぶ。以下、3層に分けて解説します。
2. 第1層:「ソース」を正確に識別する
2.1 ソース判定の優先順位
1回の訪問のソースは、以下の順序で判定すべきです。順序は入れ替えられません:
| 優先度 | 判定根拠 | 説明 |
|---|---|---|
| ① | Click ID パラメータ | 最も信頼性が高い(gclid / fbclid など)。あればそのまま帰属 |
| ② | UTM パラメータ | 手動タグ。信頼度は次点 |
| ③ | リファラー | 除外ルールが必要。下記参照 |
| ④ | 直接アクセス | フォールバック |
Click ID が UTM より優先される理由UTM は手動で付与するため、付け間違いや漏れ、改ざんが起こりやすい。一方 Click ID は広告プラットフォームが自動付与するため、一意で偽造できない。
2.2 Referrer の3つの除外ルール
referrer は最もミスが起きやすい部分です。必ず実施すべき3つの除外ルールは次のとおりです。
| ルール | やり方 | 理由 |
|---|---|---|
| 同一ドメインの除外 | referrer のドメイン == 自サイトのドメインの場合、サイト内遷移とみなし、流入元を上書きしない | そうしないと、サイト内クリックが実際の流入元を次々と「洗い流して」しまう |
| 検索エンジンの正規化 | 各国の Google ドメインを1つの流入元にまとめる | google.de/google.co.uk/google.comGoogle に統一すべき |
| 無効な referrer は直接アクセスに分類 | 空の referrer、自サイトアプリからの流入、メールクライアントからの流入 | メールクライアントの referrer は通常空で、誤判定しやすい |
同一ドメインの除外は3つの中で最も重要です。ある顧客があなたのブログ記事から製品ページに遷移したとき、それが「新しい流入元 = ブログ記事」と記録されると、元の流入元(たとえば Google 検索)が失われます。これが続くと、レポートに「ブログが最大の流入元」という誤った姿が現れます。
2.3 ファーストタッチの書き込みルール
First Touch(ファーストタッチ)は、本当に流入元を持ち帰ったときだけ書き込みます。このルールは細かく見えますが、アトリビューション体系全体の正確性を決めます。
| 状況 | ファーストタッチに書き込むか | 理由 |
|---|---|---|
| 初回訪問が Google 検索から | ✅ 書き込む | 明確な流入元がある |
| 初回訪問が広告クリックから(gclid 付き) | ✅ 書き込む | 明確な流入元がある |
| 初回訪問が直接アクセス(URL 入力 / ブックマーク) | ❌ 書き込まない | 流入元情報がなく、ファーストタッチ枠を占められない |
| 初回訪問がサイト内遷移から | ❌ 書き込まない | 実際の流入元ではない |
「直接アクセスがファーストタッチ枠を占めない」理由もし占めることを許すと、ブランド名検索で流入した顧客(まず直接アクセスと記録されがち)が、本当のファーストタッチを永久に失います。実際には、「直接アクセス」はしばしば以前の何らかのマーケティングの効果であり、ただそのときの流入元が記録されなかっただけです。
正しい処理は、ファーストタッチ枠を空のままにし、初めて本当の流入元を持ち帰った訪問で埋めることです。
三、12種類の Click ID と90日間の保持期間
Click ID は広告プラットフォームがランディングページの URL に付与する一意の識別子です。これらはクロスプラットフォームアトリビューションの唯一信頼できる手段です。なぜなら、「この訪問がどのプラットフォーム、どのクリック、どの広告から来たか」を教えてくれるのはこれらだけだからです。
| # | パラメータ名 | プラットフォーム | 一般的な有効期間 | 用途 |
|---|---|---|---|---|
| 1 | gclid |
Google Ads | 30〜90日 | 検索広告のアトリビューション |
| 2 | wbraid |
Google Ads(iOS) | 30〜90日 | iOS プライバシー制限下の代替 |
| 3 | gbraid |
Google Ads(iOSアプリ) | 30〜90日 | アプリ内 WebView のケース |
| 4 | fbclid |
メタ | 90日 | Facebook / Instagram 広告 |
| 5 | ttclid |
TikTok | 90日 | TikTok広告 |
| 6 | li_fat_id |
30日 | LinkedIn広告 | |
| 7 | msclkid |
Microsoft Ads | 90日 | Bing広告 |
| 8 | twclid |
X(Twitter) | 30日 | X 広告 |
| 9 | yclid |
Yandex | 90日 | Yandex広告 |
| 10 | epik |
30日 | Pinterest広告 | |
| 11 | s_kwcid |
Adobe / 一部のプラットフォーム | 30〜90日 | エンタープライズ向けコンバージョン追跡 |
| 12 | irclickid |
アフィリエイトマーケティング | 30〜90日 | アフィリエイトチャネルのアトリビューション |
3つの重要な設計上の決定:
| 決定 | やり方 | 原因 |
|---|---|---|
| 個別保存 | 12種類のIDをそれぞれ別フィールドに保存し、1つの”click_id”に統合しない | 同じユーザーが複数のIDを同時に持つ可能性があるため、個別にアトリビューションする必要がある |
| 90日間保持 | 初回キャプチャ後90日間保存 | B2Bの長い意思決定サイクル(30〜60日は一般的)をカバー |
| 初回キャプチャ優先 | 同じIDタイプは最初の1回のみ記録し、以降は上書きしない | アトリビューションを安定させ、”ラストクリック偏重”を避ける |
“90日間保持”という決定はB2Bでは特に重要です。産業機器の調達では、最初に広告をクリックしてから最終的に問い合わせを送信するまでに45〜70日かかるのが普通です。Click IDを30日しか保持しないと、半分以上のコンバージョンがアトリビューションに失敗し、広告効果が著しく過小評価されます。
四、第2層:4つのアトリビューションモデルと選択
データソースを修正してから、ようやくモデルの出番です。
| モデル | ロジック | 適用シーン | 限界 |
|---|---|---|---|
| ファーストタッチ | 最初の接触に100%帰属 | “誰が新規顧客を連れてきたか”を評価 | 最後の一押しのチャネルを過小評価 |
| ラストタッチ | 最後の接触に100%帰属 | “誰がコンバージョンを促したか”を評価 | 直接訪問やブランドワードが有利になりすぎる |
| ラスト非ダイレクト | 最後の非ダイレクト訪問 | デフォルト推奨(GA4のデフォルトと同じ) | 直接訪問を正しく処理する必要がある |
| 線形/位置ベース | 複数のタッチポイントに比例配分 | マルチタッチが成熟した後の精緻化 | より長いデータ蓄積が必要 |
なぜLast Non-Directをデフォルト推奨するのか?
純粋なLast Touchには重大な欠陥があるからです:多くのコンバージョン前の最後のステップは”直接訪問”(顧客はすでに連絡を決めて、直接サイトを開いてフォームを記入)。Last Touchで計算すると、これらのコンバージョンはすべて”直接訪問”に帰属され、すべてのチャネルが無意味に見えてしまいます。
正しい基準は:最後の”流入元を持つ”接触まで遡ることです。つまりGA4や多くの現代的な分析ツールが採用しているlast_non_direct基準です。
実用的なアドバイス:2つの基準を同時に見ること。
| どれを見るか | 何に答えるか |
|---|---|
| ファーストタッチ | どのチャネルが新規獲得しているか?(B2Bでは通常コンテンツと自然検索を指す) |
| ラスト非ダイレクト | どのチャネルがコンバージョンを促しているか?(通常ブランドワードとリマーケティングを指す) |
1つだけ見ると必ず誤判定します。典型的な誤判定は:Last Touchだけを見て”SEOは無効、広告が最も効果的”という結論を出すこと——広告はしばしばコンバージョン前の最後のクリックだからです;しかし実際には、SEOコンテンツが先に認知をもたらし、広告はただ便乗しただけ。
五、第3層:WeChatは”訪問環境”であり、”チャネル”ではない
この点は中国語の海外展開シーンでよく混同されるため、個別に説明する価値があります。
WeChat(WeComを含む)の内蔵ブラウザは”訪問環境”であり、”チャネル”とは直交する2つの次元です。
| 次元 | 値の例 | 回答した質問 |
|---|---|---|
| チャネル | 自然検索/有料広告/SNS/直接訪問/メール | どこから来たか? |
| 訪問環境 | WeChat / WeCom / 通常のブラウザ / アプリ内WebView | どこからアクセスしているのか? |
なぜ分ける必要があるのか?具体例で見てみましょう:
| シナリオ | チャネル | 訪問環境 | 正しい解釈 |
|---|---|---|---|
| 顧客がWeChatで友人のシェアリンクを開く | SNS(シェア) | WeChatは拡散の媒体であり、チャネルはSNS | |
| 顧客がWeChatで配信広告を開く | 有料広告 | 有料が最優先。WeChatで上書きされてはいけない | |
| 顧客がWeChatにURLを直接入力する | 直接アクセス | 環境はWeChat、チャネルはダイレクト | |
| 顧客がWeComで送った資料を開く | メール / IM 送信 | 企業微信 | 環境はWeCom |
混在させると、2つの誤りが起きます:
| 誤ったやり方 | 結果 |
|---|---|
| 「WeChat」をチャネル値にする | 有料広告の効果が「WeChat」に計上され、広告出稿を評価できない |
| アクセス環境の軸を無視する | 顧客のアクセス環境が分からず、シェア体験やランディングページの最適化ができない |
正しいやり方:チャネルとアクセス環境を別々のフィールドに保存し、有料チャネルを最優先(環境で上書きしない)、WeChatは独立したフィールドとして併存させる。これで「広告が何件の問い合わせを生んだか」も、「そのうち何件がWeChat経由か」も算出できます。
六、訪問者の帰属:国と都市をどう判定するか
アトリビューションでは「どこから来たか」だけでなく「どの国から来たか」も必要です。これは海外展開ビジネスの基礎データです。ここには2つのモードがあり、それぞれにトレードオフがあります:
| モード | 判断基準 | 精度 | 外部リクエスト | 向いている場面 |
|---|---|---|---|---|
| 軽量モード(デフォルト) | CDNが提供する国ヘッダー + ブラウザのタイムゾーン推定 | 国(タイムゾーンで補助判定) | ゼロ | 多くの海外向けサイト |
| 精密モード | サイト運営者が設定するIP照会API | 国 + 都市 | API設定が必要 | 都市レベルのデータが必要なとき |
なぜデフォルトが軽量モードなのか?1回の訪問で複数のリソースリクエストが発生するため、毎回IPデータベースを照会すると3つの問題が起きます:レスポンスの遅延、外部依存(APIが落ちれば全滅)、そしてプライバシーコンプライアンスのリスク(訪問者のIPを第三者に送信)です。軽量モードはCDNがすでにレスポンスヘッダーで提供している国情報を使うため、追加コストはゼロです。
いつ精密モードが必要か?「どの都市からの問い合わせが最も多く、現地で地推や出展をすべきか」といった問いに答える必要があるときです。その段階でAPIを設定する価値があります。
七、よくある誤りと受け入れチェックリスト
7つのよくある誤り
| # | 誤り | 結果 | 修正 |
|---|---|---|---|
| 1 | 同一ドメインのreferrerを除外していない | サイト内遷移が実際の流入元を上書きする | 同一ドメイン除外ルールを追加 |
| 2 | 直接アクセスが初回接点を占める | ファーストタッチチャネルが歪む | ファーストタッチは参照元付きの訪問のみ記録 |
| 3 | Click IDを30日しか保存しない | B2Bの長期商談でコンバージョンの帰属が失われる | 90日に延長 |
| 4 | Click IDを1つのフィールドに統合 | 複数チャネル併存時に帰属が誤る | 12種類を個別に保存 |
| 5 | ラストタッチしか見ない | コンテンツとSEOの効果を過小評価する | ファーストタッチとラストノンダイレクトの両方を見る |
| 6 | WeChatをチャネルとして扱う | 有料の効果が覆い隠される | チャネルと環境を直交して保存 |
| 7 | クライアントサイドのスクリプトでアトリビューションを記録 | プライバシー設定 / 広告ブロッカーでデータが欠落 | サーバーサイドで重要データを記録 |
公開前チェックリスト
| チェック項目 | 検証方法 | 合格基準 |
|---|---|---|
| 同一ドメイン内の遷移で参照元が上書きされない | 下層ページAから下層ページBへ遷移し、参照元が変わるか確認する | 参照元が変わらない |
| ファーストタッチは参照元がある場合のみ記録される | 参照元なしで新規訪問し、ファーストタッチのフィールドを確認する | ファーストタッチは空で、2回目に参照元付きで訪問した時点で記録される |
| Click IDが正しく取得される | 用带?gclid=test123付きのリンクでアクセスする |
データベースにtest123が確認できる |
| Click IDの保持期間 | 60日後に再度アクセスした状況を再現する | アトリビューションが引き続き一致する |
| チャネルと環境のフィールドが分離されている | WeChat内から?gclid=付きのリンクでアクセスする |
チャネル=有料、環境=WeChat |
| 初回訪問とコンバージョンが紐づく | テストの問い合わせを1件送信する | 問い合わせ記録に参照元の経路がすべて残っている |
| データをエクスポートできる | 直近30日分の問い合わせデータをエクスポートする | 参照元、Click ID、国、環境のフィールドを含む |
FAQ よくある質問
| 問題 | どれを見るか |
|---|---|
| 新規顧客はどこから来たのか? | ファーストタッチ |
| どのチャネルがコンバージョンを生んだのか? | ラスト非ダイレクト |
| 両方に現れるチャネルはどれか? | 両者を比較し、重なりが多いチャネルが最も確実に価値がある |
| チャネル種別 | 推奨アトリビューションウィンドウ |
|---|---|
| 有料検索(ブランド語) | 30日 |
| 有料検索(一般語) | 60〜90日 |
| SNS広告 | 30〜90日 |
| 自然検索・コンテンツ | 90日以上(ハードなウィンドウを設けず、長期で保持することを推奨) |
| 展示会・オフライン | 手動で補記録、ウィンドウ制限なし |
最後に
アトリビューションの価値は「どれだけ正確に計算できるか」ではなく、次の予算をどこに投じるかを決めること。
にあります。データが汚れていれば結論は誤り、結論が誤れば予算は「効果がありそうに見えて実際はただ便乗しているだけ」のチャネルに流れます。そして本当に新規獲得を担っている経路(多くの場合コンテンツと自然検索)は、即時のリターンがないという理由で削られてしまう——これが海外展開企業で最もよく見られるリソースの配分ミスです。
したがってアトリビューションに取り組む正しい順序は、まずデータソースをきれいにすること(同一ドメインの除外、初回接触ルール、Click IDの保持期間、チャネルと環境の分離)で、その後にモデル選択を検討する、です。前者はエンジニアリングの問題で、一度正しく作れば長く恩恵を受けられます。後者は分析の問題で、知見の進化に合わせて調整し続けられます。
