クリックIDとは: Gclid、Fbclid、Ttclid、Msclkidを解説

クリックIDとは、誰かが広告をクリックした瞬間に広告プラットフォームが発行し、送信先URLに付加して、コンバージョン時に後から読み戻す不透明なトークンです。これにより、売上やサインアップを、それを生み出した正確なクリックに突き合わせられます。Googleの版はgclid、Metaの版はfbclid、TikTokの版はttclid、Microsoft Advertisingの版はmsclkidです。複数のプラットフォームで有料キャンペーンを実施すれば、この四つすべてに出会うことになり、たいていは「なぜURLがこんなに長くなったのか」と首をかしげながらになります。

それぞれが自分のプラットフォームのために同一の役割を果たしており、どれも自分で書くラベルではありません。UTMタグは、自社のアナリティクスがキャンペーンごとにトラフィックを分類できるように自分で作成するテキストです。クリックIDはそれとは違い、プラットフォームが生成する文字列であり、そのプラットフォーム自身のピクセルやAPIだけがその使い方を知っています。両方が必要です。それぞれ異なる問いに答えるものだからです。ここが、多くの解説記事が見落としている部分です。

クリックIDの正体

クリックIDは、名札ではなく荷物の引換券のようなものだと考えてください。誰かがGoogleの広告をクリックすると、Googleのサーバーは一意の文字列を生成し、そのクリックの背後にあるキャンペーン、広告グループ、キーワードに紐づけ、?gclid=...としてURLに付加します。その文字列はあなたにも他の誰にも読み取れません。Google自身のクリックログへの参照番号にすぎないからです。fbclid、ttclid、msclkidも同じパターンに従います。発行元は違っても、考え方は同じです。

その狙いは、「広告を表示した」ことと「あなたのサイトでこれが起きた」ことの間のループを閉じることです。クリックIDがなければ、プラットフォームはキャンペーンレベルの推定値しか報告できません。クリックIDがあれば、「3日前のこの正確なクリックが、この正確な購入につながった」と言えます。これはUTMだけでは得られない精度です。これがオフラインコンバージョンのインポート、Smart Bidding、CAPI方式のサーバーイベントを支えています。UTMパラメーターを解説は、多くのチームがクリックIDと並行して運用しているキャンペーンレベルのタグ付けについての姉妹記事です。

出会うことになる四つのクリックID

主要な広告プラットフォームはそれぞれ独自の版を持っており、重要な違いは「誰がそれを読み戻すのか」と「どのくらいの期間使えるのか」です。

四つのプラットフォーム、四つのパラメーター名、一つの仕組みです。そのすべてに広告を出稿していれば、一つのランディングページが同時に複数のクリック識別子を運ぶこともあります。先週のクリックによる古びたgclidが、今日のリターゲティング広告による新しいfbclidと並んで存在する、といった具合です。

クリックIDとUTMパラメーターの違い

これが「fbclidとは何か」という検索の背後にある混乱の正体です。クエリ文字列の中でutm_sourceのすぐ隣に並んでおり、一見トラッキングパラメーターのように見えますが、実際にはまったく違うことをしています。

UTMパラメーターはラベルです。utm_campaign=spring-saleのように自分で値を選び、アナリティクスツールは自分が入力した文字列に従ってセッションを分類します。クリックIDはルックアップキーです。gclidの値を選んだのはあなたではなくGoogleであり、それに対して何かできるのはGoogle自身のシステムだけです。gclidを一般的なアナリティクスレポートに放り込んでも、ただそこに座っているだけです。Google Adsには有用でも、他の誰にとっても無用の長物です。

この非対称性はトラブルシューティングにおいて重要です。UTMがレポートに表示されなくなったとき、原因はたいていブラウザか壊れたリンクにあります。この故障モードについてはFirefoxとBraveがUTMアトリビューションを壊している件で解説しています。クリックIDが突き合わなくなったとき、原因はほぼ常に、それがプラットフォーム自身のピクセルやAPIに間に合うように届かなかったか、コンバージョンが起きる前に有効期間が終了してしまったかのどちらかです。

クリックIDの往復の仕組み

プラットフォーム固有の名前を取り払ってしまえば、どのクリックIDも同じ三段階の旅をたどります。

第一段階、発行。 ユーザーが広告をクリックした瞬間、ブラウザがランディングページをリクエストするより前に、プラットフォームは識別子を生成し、それをリダイレクトURLに埋め込みます。

第二段階、移動。 識別子は、広告とランディングページの間にあるどのホップも通過しながら、クエリパラメーターとして移動します。プラットフォームのリダイレクトを経て、自社のドメインへと至ります。ここで捕捉し、後で使えるようにクッキー、隠しフォームフィールド、あるいはCRMレコードに書き込んでおきましょう。

第三段階、突き合わせ。 購入、サインアップ、フォーム送信といったコンバージョンが発生すると、自社のピクセルやサーバーが、保存しておいたクリックIDをイベントと一緒にプラットフォームのAPIへ送り返します。プラットフォームは自身のクリックログでそれを照合し、まだ有効期間内であれば元の広告に功績を割り当てます。これがコンバージョンをMetaのConversions APIへ転送するの裏にある仕組みです。早めに捕捉し、保持し、後で送り返す、という流れです。

パラメーターが頼んでもいないのに現れる理由、そして取り除いてよいのか

ほとんどの人はクリックIDに偶然出会います。Google AdsとMicrosoft Advertisingでは自動タグ設定がデフォルトで有効になっており、TikTokは2024年にオプトインなしでttclidを自動化しました。誰もそのパラメーターを求めたわけではなく、プラットフォームが勝手に付加し始めただけです。今のコンバージョントラッキングとはそういうものだからです。

つまり、取り除くこと自体は可能です。ただし、それが無害な整理整頓になるか、自ら招いたアトリビューションの穴になるかは、タイミング次第です。共有する前のリンクからfbclidを取り除いたり、レポートのURL列から消したりしても、ピクセルがすでに取得済みのコンバージョンデータには何の影響もありません。しかし、自社のスクリプトやリダイレクトがそれを読み取る前に取り除いてしまうのは話が別です。プラットフォームがクリックに功績を割り当てるために必要だった唯一のものを削除したことになり、どれだけUTMデータがあっても取り戻せません。最も安全な習慣は、最初のホップでクリックIDをサーバーサイドで捕捉することです。これはサーバーサイドのコンバージョントラッキングで解説しているアプローチであり、パラメーターを取り除くのは、その捕捉より下流で表示・保存するものからだけにしましょう。

ElidoのコンバージョントラッキングがすべてのクリックIDを自動で捕捉する仕組みを見る → gclid、fbclid、ttclid、msclkidを四つの広告アカウントにまたがって手作業で扱っているなら、これがその痛みを解決します。他の何かがURLに触れる前に識別子を記録する、一枚のリダイレクト層です。

クリックIDが失われる場所

クリックIDは、UTMが脆い部分とまったく同じ点で脆く、それに加えて一つ二つ独自の故障モードも持っています。

損失のほとんどは四つの状況によるもので、それぞれ異なる対処法を必要とします。

訪問者が、到達したURLをグループチャットにコピー&ペーストします。その貼られたリンクをクリックした全員が、他人のクリックIDを引き継ぐことになります。コンバージョンは間違ったクリックと一致するか、あるいは何とも一致しません。識別子は、最初に到着したセッションに紐づけて保存し、アドレスバーのURLを記録として扱うのはやめましょう。

クリックがアプリ内ブラウザで開きます。InstagramやTikTokは、そのタップを制限されたウェブビューに渡しますが、そのセッションを超えてファーストパーティクッキーを保持できないことが多く、URLに乗った識別子は行き場を失います。ブラウザが覚えていてくれることに頼るのではなく、最初のリクエストの時点でサーバーサイドでパラメーターを読み取りましょう。

リダイレクトが送信先URLを再構築し、クエリ文字列を落とします。クリックIDはランディングページにまったく届きません。ピクセルが読み込まれる前に消えてしまっているため、下流の何をもってしても救えません。経路上のすべてのリダイレクト層が、デフォルトでクエリパラメーターを転送していることを確認してください。

ブラウザがページの読み込み前にパラメーターを取り除きます。Firefoxのクエリパラメーターの除去は、Strictモードでfbclidを名指ししています。送信先ページとそのスクリプトが実行される前、リダイレクトの時点で識別子を捕捉しましょう。

コピー&ペーストのケースは、実のところクリックIDの衣装をまとったダークソーシャルの問題です。リンクは自社のアナリティクスから見えないプライベートなチャネルを通って移動しており、ダークソーシャルのアトリビューションがその隙間を余すところなく解説しています。fbclidとttclidの持続性に影響するSafari特有のクッキー制限については、Safari ITP後のクリックアトリビューションが専用の解説記事なので、ここでは繰り返しません。

コンバージョンのアトリビューションを保つ: 実践チェックリスト

ここまでの話のどれも、スタックを作り直す必要はありません。必要なのは、下流の何かがそれを落としてしまう前に、クリックIDが一度、早い段階で確実に捕捉されるようにすることだけです。

• gclid、fbclid、ttclid、msclkidは、スクリプトが読み込まれた後のランディングページではなく、最初のリダイレクトホップでサーバーサイドで捕捉する。
• クリックIDは、売上成立前に期限切れになりかねないクッキーだけでなく、自社データベースの注文レコードやリードレコードにも保存する。
• 保存したクリックIDは、それぞれのプラットフォームの有効期間内に、各プラットフォームのAPI(Conversions API、Enhanced Conversions、Events API、UETオフラインインポート)へ転送する。
• 自社の短縮サービスやリダイレクトチェーンがクエリ文字列を無加工で通過させることを確認する。ダミーの?gclid=test123でテストし、そのホップを生き延びることを確かめる。
• どちらか一方を選ぶのではなく、クリックIDとUTMを組み合わせて使う。クリックID単独では得られないキャンペーンレベルの視点のための並行セットアップについては、UTMをエンドツーエンドで追跡するで解説している。

私がこれまでデバッグしてきたアトリビューションの穴の多くは、二番目の項目に行き着きます。クッキーだけに生きていたクリックID、変わってしまったドメイン、取引が成立する前に期限切れになったセッション、といった具合です。この一つの習慣を直すことは、どんなプラットフォーム設定よりも多くの穴を塞ぎます。これは、ブログのtutorialsセクションがまさに扱っている類の修正です。

ブログの関連記事

• UTMパラメーターを解説: 完全ガイド
• FirefoxとBraveがUTMアトリビューションを壊している件
• Safari ITP後のクリックアトリビューション
• サーバーサイドのコンバージョントラッキング
• コンバージョンをMetaのConversions APIへ転送する