LinkedIn Insight Tagが実際に行うこと

Insight Tagはsnap.licdn.comから読み込まれるJavaScriptスニペットで、媒体事業者のドメインにCookieを設定し、LinkedInの計測インフラにイベントデータを送信します。生成されるペイロードは、多くのマーケターが認識している以上にリッチです。ページURL、リファラー、ユーザーエージェント、訪問者のIPアドレス、同一ブラウザで最近LinkedIn認証を行った訪問者のLinkedIn側識別子、さらにタグが送信するよう設定されたコンバージョンパラメーター（フォーム送信、ボタンクリック、動画再生、スクロール深度のしきい値）を取得します。タグがハッシュ化メールマッチングを通じて媒体事業者のファーストパーティデータと組み合わされた場合、イベントペイロードにはLinkedInが訪問を特定のLinkedInメンバーアカウントに紐付けるためのハッシュ化識別子も含まれます。

標準コンバージョンとカスタムコンバージョン

Insight TagはコンバージョンイベントをLinkedIn所定のイベント分類（Lead、Sign-Up、Purchase、Add to Cart、Download）に従う標準コンバージョンと、タグのルールエンジンが検出できる任意のURL・クリック・ページイベントの組み合わせで起動できるカスタムコンバージョンの2種類サポートしています。同意の観点からこの区別に意味はありません。どちらのコンバージョンイベントも、含まれるCookieと識別子によって個人データ処理イベントであり、起動のきっかけとなったページビューと同一の法的根拠が必要です。

CookieとクロスサイトID

タグは媒体事業者のドメインに主に2つのCookieを設定します。li_fat_id Cookieは約90日間持続し、訪問者がログイン中の場合に訪問をLinkedInメンバーIDに紐付けます。li_sugr CookieはメンバーIDが利用できない場合にLinkedInが計測に使用するフィンガープリント由来の識別子です。どちらのCookieもEU ePrivacy指令のトラッキングCookie定義を満たしており、同意前にどちらかを設置することはB2B媒体事業者監査において規制当局が繰り返し指摘してきた発見事項です。

タグが継承する同意義務

このタグは他のアドテクトラッキングスクリプトと同じ規制上の交差点に位置しています。最も厳格な基準であるEU GDPRとePrivacyが他の法制度が求める大部分をカバーし、その上にUKおよび米国各州固有の追加要件が重なります。

GDPR、ePrivacy、UK ICOの立場

EU ePrivacy指令およびGDPRのもとでは、ユーザーが自由に、具体的に、情報を与えられた上で、明確に同意を与える前にタグを読み込むことはできません。「LinkedInメンバーはLinkedIn自身のプラットフォーム規約を通じてすでに同意している」というよくあるB2B言い訳は、規制当局の審査に耐えません。媒体事業者のドメインでの処理はLinkedInではなく媒体事業者のプライバシー通知のもとで行われる独立したイベントであり、Cookieが読み込まれる時点で同意を取得する必要があります。UK ICOはB2B媒体事業者に対して特に積極的に行動しており、2024年から2025年にかけての執行措置はまさに「Linkedinのオーディエンスは自発的に同意したコホートである」という前提を標的にしてきました。

正当な利益の問題

B2B媒体事業者は、業界サイトでのトラッキングをB2Bオーディエンスは期待しており、データ主体の合理的な期待がそれを支持するとの考えから、Insight Tagの法的根拠として正当な利益を主張することがあります。この主張には狭い余地があります。広告やパーソナライゼーションに供給されない分析については、適切なバランシングテストを行えば正当な利益のもとで守れる場合もあります。しかし、LinkedIn Insight Tagの主目的はターゲット広告に供給するコンバージョントラッキングであり、EDPBが公表しているガイダンスによれば明確に同意領域に位置します。標準的なタグ展開において正当な利益は実行可能な近道にはなりません。

CCPA、CPRA、米国各州の法制度

カリフォルニア州のCPRAはInsight Tagの送信シグナルを個人情報の売却または共有として扱い、媒体事業者にGlobal Privacy Control（GPC）ヘッダーを尊重し、明確なオプトアウトリンクを設け、その結果シグナルをLinkedIn互換の状態にルーティングすることを求めます。LinkedInは、米国州法のもとでオプトアウトしたユーザーに対して媒体事業者が有効化できるLimited Data Use（LDU）モードをサポートしており、MetaのLDUや現在ほとんどの主要アドテクベンダーが提供するプライバシーモードに相当します。IAB Multi-State Privacy Agreement（MSPA）が生成するUS Privacy Stringは、ほとんどの媒体事業者が1つの同意文字列で全州法を満たすために使用する単一の統合ポイントです。

CMPを通じたタグの接続

監査に耐える実装パターンは説明が簡単で間違えやすいものです。タグは同意が解決されるまで読み込まれてはいけません。同意状態はイベントが発火する前にタグに伝達されなければならず、ユーザーがナビゲートするたびに同意状態を再確認して、あるタブでの撤回がどこでも尊重されるようにしなければなりません。

デフォルト拒否とGoogle Consent Mode v2

CMPをマーケティングまたは広告同意カテゴリに対してデフォルト拒否に設定し、そのカテゴリ内でLinkedInを明確な平易言語の説明とともにベンダーとして表示し、対応する同意タイプが付与された場合にのみInsight Tagを起動するようタグマネージャーを設定します。Google Consent Mode v2のad_storage、ad_user_data、ad_personalizationシグナルは、LinkedIn統合に広告スタック全体が使用するのと同じステートマシンを提供します。3つすべてが拒否された場合、タグは決して起動しません。付与された場合、タグは完全な高度マッチングで起動します。部分的に付与された場合、タグはイベントを完全にドロップするのではなくLDUモードにフォールバックします。

Google Tag Managerトリガーのレシピ

最もクリーンなGTMのセットアップは、CMPが発行するconsent_update dataLayerイベントを監視するカスタムトリガーと、LinkedIn Tag自体の組み込み同意チェックを使用します。トリガーは同意が解決された後にのみInitialization-All-Pagesで起動し、追加同意としてad_storageを必須にする必要があります。CMPの前に実行されるPage Viewトリガーにタグをロードすることはやめてください。タイミングの競合により、B2B監査の大多数で「同意前にタグが起動する」という調査結果が生じます。

TCF v2.3とLinkedInベンダーエントリ

EU向けトラフィックには、CMPのTCF v2.3ベンダーリスト設定内にLinkedInを登録します。LinkedInのGlobal Vendor Listエントリは各目的に主張する法的根拠を公開しており、CMPはそれらの目的を同意UIに1対1で反映しなければなりません。一般的な「広告パートナー」トグルのもとにLinkedInをまとめることはTCF v2.3違反です。すべてのベンダーにベンダーごとのコントロールが必要であり、多数の指名ベンダーに単一スイッチを適用しているのを発見した規制当局は同意を無効と判断します。

サーバーサイドの経路：LinkedIn Conversions API

ブラウザタグはLinkedInが提供する唯一の経路ではありません。Conversions APIはサーバー間エンドポイントで、ブラウザサイドスクリプトなしでバックエンドがコンバージョンイベントを直接LinkedInに送信できます。2つの経路は共存しています。ほとんどのB2B媒体事業者は並行して実行し、共有イベントIDで重複を排除し、ブラウザタグが広告ブロッカー、企業ファイアウォール、または同意レイヤー自体によってブロックされた場合のバックアップとしてAPIを使用します。

2026年においてサーバーサイドの経路が重要な理由

3つの力がB2B媒体事業者を純粋なブラウザタグから遠ざけています。Chromeでのサードパーティ Cookie廃止の完了、サードパーティCookieがすでに利用できないSafariとFirefoxが一部のB2Bオーディエンスで優勢であること、そして広告ブロッカーとプライバシープロキシが標準装備されているB2Bターゲットアカウントの企業ネットワークです。Conversions APIは媒体事業者にバックエンドがデータプレーンを制御し、レイテンシが低く、ネットワーク割り込みを経てもイベントが残り、サーバーがブラウザには見えないファーストパーティ識別子を渡せるためマッチング率が向上するという経路を提供します。

同意は依然として適用される

Conversions APIはGDPRやCPRAを回避しません。法的根拠の要件はデータに付随するものであり、転送手段ではありません。ユーザーがCMPで広告同意を拒否した場合、どの経路を使用しているかに関わらず、バックエンドはそのユーザーの識別子をLinkedInに送信してはなりません。コンバージョン発行者がすべてのAPI呼び出しで読み取るリクエストスコープのフラグに同意状態を組み込み、同意プロンプトがまだ保留中の間に楽観的にコンバージョンを起動するエンジニアリングの誘惑に抵抗してください。

調査結果を引き起こすB2B固有の失敗

規制当局の調査結果を生み出すB2B Insight Tagの展開は、消費者向けピクセルのパターンとは少し異なるパターンで失敗する傾向があります。タグは、マーケティングファネルのページとはオーディエンスが実質的に異なる採用情報や投資家向け情報のページを含む企業サイトのすべてのページで読み込まれます。CMPのデフォルト設定は消費者スタイルのトラフィック向けに調整されており、B2B調査フェーズの訪問者のより長いエンゲージメントウィンドウ向けに調整されることはありません。ハッシュ化メールによる高度マッチングは、CMP対応フィルターなしでマーケティングオートメーションプラットフォームに接続されており、マーケティング同意カテゴリを拒否したユーザーのハッシュ化メールをLinkedInに送信しています。Conversions APIはデータチームがバックエンド最適化として実装しており、同意レイヤーには一切相談されないまま、ユーザーがフロントエンドで行うすべての同意決定を通じて途切れなく稼働しています。これらはそれぞれ1〜3日のエンジニアリング作業で修正できます。そしてどれも、ICOが公表したB2B執行決定で指摘してきたパターンそのものです。

結論

LinkedIn Insight Tagはリスクの低いB2Bユーティリティではありません。消費者向けピクセルと同じ同意ルールのもとで生きているトラッキング技術であり、B2Bオーディエンスとサイトがマーケティングチームを消費者サイドが何年も前に克服したコンプライアンス上の油断に陥らせがちであるという追加の落とし穴があります。コンプライアントなパターンはよく知られています。タグの存在を認識するCMP、Google Consent Mode v2またはTCF統合を通じてタグが尊重する同意ゲート、同じ同意状態を尊重するサーバーサイドのConversions API経路、そして同意を拒否したユーザーに対してタグが無音であることを確認するために新しいブラウザで承認と拒否のフローを確認する四半期監査です。これを正しく実装する媒体事業者と広告主はB2Bの計測を信頼性高く保ち、監査への回答を短く済ませます。LinkedIn オーディエンスを自発的に同意したコホートとして扱う事業者は、Cookie監査が「すべきでない」と言ってから9か月後も採用情報ページでタグが起動していた理由を規制当局に説明しながら2026年を過ごすことになります。