【実務者向け】LINE×GTMで友だち追加・CV計測を最適化するデータ設計（LIFF/Webhook活用）

最終更新日：2026年4月6日

1. なぜLINE友だち追加のCV計測は「乖離」が発生するのか？（技術的背景）

「Webサイト上のLINE登録ボタンのクリック数をGTMで計測しているのに、実際の友だち数が増えていない」。この乖離が発生する根本的な原因は、「ディープリンクによるセッションの分断」と「トラッキング保護技術（ITP）」の壁にあります。

原因①：「ボタンクリック＝友だち追加完了」という誤った前提

一般的なGTMの実装では、Webサイト上の「LINEで友だち追加」ボタンにクリックトリガー（Click – Just Links 等）を設定し、それをCVとしてGA4や各種広告タグへ送信します。
しかし、ユーザーがボタンをクリックした後、実際にLINEアプリが立ち上がり、「追加」ボタンを押すまでの間には「認証画面でのスキップ」「LINEアプリのログイン要求」「追加前の離脱（なんとなく押しただけ）」といった複数のハードル（歩留まり）が存在します。ボタンクリック数をCVとしている限り、実際の追加数と一致することは構造上あり得ません。

原因②：Apple ITPとIn-App Browser（LINE内ブラウザ）によるCookieの分断

さらに深刻なのが技術的な壁です。ユーザーが広告をクリックしてSafariでランディングページ（LP）を開き、LINEのボタンをタップすると、OSの仕様でLINEアプリが立ち上がります。
AppleのWebKit公式ブログでも言及されている通り、ITP（Intelligent Tracking Prevention）をはじめとするトラッキング保護機能により、Safari（ブラウザ）が保持していたサードパーティCookie（広告クリック時のUTMパラメータやセッションID）は、別アプリであるLINE側には引き継がれません。

さらに、LINE内で送られたメッセージのURLをタップすると、Safariではなく「LINE内ブラウザ（In-App Browser）」が立ち上がります。このブラウザは外部ブラウザとCookieを共有しないため、「どの広告・どの経路から来たユーザーが実際に友だちになったのか」を紐付けるセッションが完全に切断されてしまうのです。

2. 【アーキテクチャ比較】LINE友だち追加計測の3つのアプローチ

この課題に対し、実務現場では要件と開発リソースに応じて以下の3つのアーキテクチャから計測手法を選定します。

3. 現場で頻発する「計測漏れ」の3つの落とし穴と回避策

精緻なデータトラッキングを構築する上で、システム担当者やマーケターが陥りやすい技術的な落とし穴と、アーキテクト視点での回避策を解説します。

1. 「クリックトリガー」への過度な依存による機械学習の汚染
   前述の通り、クリック計測をCVとして広告プラットフォーム（Google広告など）に送信し続けると、広告媒体の機械学習アルゴリズムは「クリックはするが友だち追加はしない（意欲の低い）ユーザー」を優良顧客と誤認し、最適化の方向性が狂います。
   レベル1のクリック計測はあくまで「中間指標（マイクロコンバージョン）」としてのみ利用する。本番の広告自動入札の最適化には、後述するレベル3のLIFFを用いた実CV計測、もしくはMeasurement Protocolを用いたサーバーサイドからのCV送信を採用する。
2. UTMパラメータの引き継ぎ漏れ（リファラの欠落）
   広告をクリックしてLPに到達したユーザーが、ページ内のLINE追加ボタンを押してLINEアプリへ遷移する際、URLに付与されていたUTMパラメータ（?utm_source=…）が欠落し、GA4上で「Direct」や「Referral（参照元不明）」に分類されてしまう問題です。
   GTM内のカスタムJavaScript変数を用いて、URLのクエリパラメータをSessionStorageやファーストパーティCookieに一時保存する。LIFFアプリ内のサンクスページ等でその値を再度読み込み、GA4のイベントパラメータ（campaign, source, medium）に再セットして送信する設計を行う。
3. In-App Browser内でのトラッキングタグの未発火
   LINE内で配信されたリッチメニューやメッセージのURLをタップした際、立ち上がる「LINE内ブラウザ」では、ユーザーのセキュリティ設定やOSのバージョンによってはGTMのタグが正常に発火しないケースがあります。
   重要なコンバージョンポイントにおいては、ブラウザのJavaScriptに依存するクライアントサイド・トラッキングだけでなく、サーバー側の処理（Webhook等）をトリガーとしたサーバーサイド・トラッキング（SS-GTM）を併用し、確実にデータを送信するアーキテクチャを組む。

4. 【実践事例1】LIFF（liff.getFriendship）を用いた実CVトラッキング

実際に私たちがエンタープライズ向けのデータ基盤構築で採用している、「LIFF（LINE Front-end Framework）とGTMを連携させたトラッキングアーキテクチャ」をご紹介します。

この手法は、LINE Developersの公式ドキュメントで提供されているLIFFの初期化・ログイン機能（liff.login）と、友だち状態取得API（liff.getFriendship）、そしてGTMのデータレイヤー（dataLayer.push）を組み合わせる高度な実装です。

アーキテクチャ事例：LIFFを経由した実CVのGTM送信

「ボタンクリック」から「確実な友だち追加判定」への移行

【必須の事前準備：ボットリンク機能（Bot Link）の設定】
LIFFログイン時に公式アカウントの友だち追加画面を自然に表示させるため、LINE Developersコンソール上で当該LIFFチャネルの「ボットリンク機能」を「On（通常）」または「Aggressive（積極的）」に設定しておきます。

【設計フロー】
1. Webサイト上の「友だち追加」ボタンのリンク先を、通常のLINE URL（https://lin.ee/…）ではなく、自社で開発したLIFFアプリのURLに設定します。
2. ユーザーがボタンをタップすると、LINEアプリ内でLIFFが立ち上がります。未ログインの場合はliff.login()による認証画面が走り、同時に前述の「ボットリンク機能」によって友だち追加が促進されます。
3. LIFFアプリ内で初期化が成功した後、公式APIであるliff.getFriendship()を実行します。これにより「現在このユーザーが公式アカウントを友だち追加（かつブロックしていない）状態か」を確実に判定し、条件を満たした場合のみJavaScriptを発火させます。

// LIFF初期化と友だち追加判定後の処理例 (公式仕様準拠)
liff.init({ liffId: "YOUR_LIFF_ID" }).then(() => {
  if (!liff.isLoggedIn()) {
    liff.login(); // 未認証の場合はログインを要求
    return;
  }
  
  // 公式APIを用いて現在の友だち状態を取得
  liff.getFriendship().then(data => {
    if (data.friendFlag) {
      // 確実に友だち追加されている場合のみ、GTMのdataLayerにプッシュ
      window.dataLayer = window.dataLayer || [];
      window.dataLayer.push({
        'event': 'line_friend_added',
        'line_uid': liff.getContext().userId // ユーザーIDも合わせて送信可能
      });
    }
  });
});

【得られた成果】
この「line_friend_added」イベントをGTM側でカスタムイベントトリガーとして受信し、GA4やGoogle広告へCVとして送信します。これにより、「クリックしただけのユーザー」を完全に排除し、100%の精度でトラッキングできるようになり、広告運用（ROAS）の精度が飛躍的に改善されました。

※参考：LINE Developers 公式ドキュメント「LIFFアプリにボットリンク機能を追加する」「liff.getFriendship()」

5. 【実践事例2】Webhook × SS-GTMを用いた究極のサーバーサイド計測

前述のLIFFを用いた手法は非常に強力ですが、依然として「ユーザーのブラウザ（クライアントサイド）のJavaScript」に依存しているため、極端な通信環境のエラーや強力なアドブロッカーによってデータが欠損する可能性がゼロではありません。

さらに高度なセキュリティとデータ品質を求めるエンタープライズ環境では、ブラウザを一切介在させないサーバーサイドトラッキングを採用します。ここで用いるのが、LINE Messaging APIの公式機能であるWebhookの「followイベント」と、Google Analytics 4のMeasurement Protocol（またはサーバーサイドGTM：SS-GTM）の連携です。

アーキテクチャ事例：WebhookとMeasurement Protocol連携

ITPに一切影響されない100%のサーバー間通信トラッキング

【設計フロー】
1. ユーザーがLINEアプリ内で自社の公式アカウントを「友だち追加」または「ブロック解除」した瞬間、LINEのサーバーから自社のサーバー（Webhook URL）に対して、公式のfollowイベントを含んだJSONペイロードが即座にPOST送信されます。
2. 自社のサーバー（Node.jsやPython等のバックエンドプログラム）でこのWebhookを受信します。この時点で、LINE側での「友だち追加」という事実がサーバーレベルで確定します。
3. 受信したサーバーから、Google AnalyticsのMeasurement Protocol APIに対して、直接コンバージョンイベント（HTTP POSTリクエスト）を送信します。この際、リクエストペイロードには必須パラメータであるapi_secretやmeasurement_idの他、事前にWebサイト側で発行・DBに保存しておいたclient_id（GA4の識別子）とLINEのuserIdを紐付けて送信することで、広告流入からのセッションを繋げます。

【このアーキテクチャの圧倒的優位性】
この構成は、ユーザーのブラウザの設定（Cookieブロック、ITP、アドブロッカー等）に一切影響を受けません。LINEのサーバーと自社のサーバー、そしてGoogleのサーバー間での直接通信（S2S: Server to Server）となるため、現在技術的に可能な最も確実で堅牢なCVトラッキング手法となります。

※参考：LINE Developers 公式ドキュメント「Webhookイベントオブジェクト（followイベント）」 / Google for Developers 公式ドキュメント「Measurement Protocol (Google アナリティクス 4)」

6. まとめ：正しいデータ計測は「システム間連携の設計」から

LINEを用いたマーケティングにおいて、友だち追加数は最も重要なKPIの一つです。しかし、プラットフォーム間の仕様（ブラウザからアプリへの遷移やITP規制）を理解しないまま「とりあえずGTMでクリックを計測する」アプローチをとると、データが実態と乖離し、意思決定の方向性を誤らせます。

精度の高いトラッキングを実現するには、単なるGTMのタグ運用の知識だけでなく、「LIFFやMessaging API WebhookといったLINE側のシステム仕様」と「GA4のMeasurement Protocol設計」を統合的に理解するITアーキテクチャの視点が不可欠です。

「現在のLINE広告とGA4のCV数に大きなズレがあり、原因がわからない」「より厳密なLIFFやサーバーサイドトラッキング（SS-GTM）を用いた計測環境を構築したい」といったデータ基盤に関する課題をお持ちであれば、ぜひ一度ご相談ください。
私たちは、現場の実態に即したデータトラッキングと、その後のCRM（Salesforce等）への確実なデータ連携までを見据えた、最適なアーキテクチャをご提案いたします。