「Safariからの流入だけ、コンバージョン数値が前年から3割減っているように見える」「Cookieバナーを置いたら、計測タグが空振りするケースが増えた」。EC事業者と話していて、ここ数年で急速に増えた相談です。原因の多くは、サイト側の不具合でも広告の不調でもなく、ブラウザと法令の両方が同時にサードパーティクッキー前提を壊しに来ている、という環境変化です。
本記事ではサードパーティクッキー廃止と改正電気通信事業法（外部送信規律）が EC 計測に与える影響を、何が壊れて、何が壊れないのか という観点で整理します。そのうえで、ファーストパーティ計測へのシフトを 4 ステップで具体化し、2026 年以降に EC 事業者が現実的に取れる計測戦略を提示します。
この記事のまとめ#
- サードパーティクッキー前提は、ブラウザと法令の両方から同時に終了している：Safari は 2020 年に 3rd party Cookie をデフォルトブロック、Firefox は 2022 年に Total Cookie Protection を全ユーザーへ展開、Chrome は Privacy Sandbox 移行を継続中で、日本では 2023 年 6 月の改正電気通信事業法で外部送信規律が施行された
- 「壊れる指標」と「壊れない指標」を切り分けるのが先決：クロスサイトトラッキング前提のリターゲティング・ビュースルー・媒体間 LTV は壊れる側、自社ドメイン内で完結する CVR / AOV / RPS / セッション単位アトリビューションは壊れない側
- ファーストパーティ計測への移行は 4 ステップで設計できる：①自社ドメインでの計測点を確定 ②外部送信規律の公表 4 項目を整備 ③UTM 設計を計測の正本にする ④売上から逆引きで KPI を再定義する。広告計測の精度を 100% 取り戻すのではなく、意思決定に必要な精度を残す という発想に切り替える
1. なぜ今、EC事業者はサードパーティクッキー前提を捨てる必要があるのか#
サードパーティクッキーとは、訪問しているサイト（ファーストパーティ）とは異なるドメインから発行されるクッキーのことです。広告配信プラットフォーム・アクセス解析ツール・タグマネージャー等が、サイト横断でユーザー行動を追跡するために長く使われてきました。
このサードパーティクッキー前提が、ここ数年で急速に終わりつつあります。背景は 3 つあります。
第一に、ブラウザ側の制限が段階的に強化されてきた ことです。Safari は 2017 年に Intelligent Tracking Prevention（ITP）を導入し、2020 年 3 月のバージョン 13.1 でサードパーティクッキーをデフォルトでブロックする実装に到達しました [4]。Firefox は 2022 年 6 月に Total Cookie Protection を全ユーザーへ展開し、サイトごとにクッキー保管領域を分離するモデルへ移行しています [5]。Chrome は Privacy Sandbox の段階導入を継続しており、Topics API や Attribution Reporting API といった代替仕組みを提示しています [3]。
第二に、日本では改正電気通信事業法による外部送信規律が 2023 年 6 月に施行された ことです [1]。電気通信事業者および電気通信事業を営む者がウェブサイト・アプリを通じて外部にユーザー情報を送信する際、利用者に対して送信先・送信情報・利用目的・オプトアウト手段の 4 項目を公表する義務が課されました。EC 事業者の多くもこの規律の対象となります。
第三に、iOS / Android の OS 側プライバシー機能 が個別アプリのトラッキング識別子（IDFA / GAID）にも制限をかけ、広告計測の前提が縮んでいます。これは厳密にはサードパーティクッキーの話ではありませんが、EC 事業者から見える計測環境という意味で同じ流れの一部です。
これらが同時進行している以上、「ブラウザの仕様が落ち着くまで様子見する」という選択肢は実質的に取れません。前提が戻ることはない と置いて、計測戦略を組み直す必要があります。
2. ブラウザ別の制限状況 — Safari / Firefox / Chrome の現在地#
EC事業者が把握しておくべきブラウザ側の制限は、ベンダーごとに前提が異なります。
| ブラウザ | サードパーティクッキー | ファーストパーティクッキー | 主な追加制限 |
|---|---|---|---|
| Safari（ITP） | デフォルトブロック（2020 年〜） | 残るが document.cookie 経由は最大 7 日に短縮 | クロスサイト遷移時の navigation tracking 抑制 |
| Firefox（ETP） | サイトごとに保管領域分離（2022 年〜） | 残る | フィンガープリント抑制・SocialTracking ブロック |
| Chrome（Privacy Sandbox） | 段階廃止と代替 API への移行を継続中 | 残る | Topics API・Attribution Reporting API への置換 |
| Edge | Chrome 同等 | 残る | トラッキング防止「バランス／厳密」モードを提供 |
EC 事業者にとって実務上重要な点は 2 つあります。
第一に、ファーストパーティクッキーは引き続き利用可能 ということです。自社ドメインから発行する visitor_id / session_id 等の識別子は、ブラウザの 3rd party 制限の対象外です。ただし Safari の ITP では JavaScript から書き込んだファーストパーティクッキーの寿命が最大 7 日に短縮されるため、長期 LTV を Cookie のみで追う設計は機能しません。
第二に、Chrome の Privacy Sandbox は計測の置換ではなく、用途別 API への分割 という性格を持ちます。ターゲティングは Topics API、広告計測は Attribution Reporting API、というように、従来サードパーティクッキーが一つで担っていた機能が複数の API に分かれます。EC 事業者から見ると、広告計測の精度は「100% 取り戻す」のではなく、用途ごとに必要な精度を残す という設計思想に変わります。
GA4 で「Direct / (none)」が増えていく挙動の多くも、このブラウザ側制限と無関係ではありません。流入元の判定に使われるリファラと UTM が、Cookie 制限・referrer policy・アプリ内ブラウザの組み合わせで欠落するためです。詳細は別記事 GA4の"Direct / None"が増える5つの原因と対処 で扱っています。
3. 改正電気通信事業法（外部送信規律）が課す日本固有の追加要件#
日本の EC 事業者にとって、ブラウザ側制限に加えて重要なのが 改正電気通信事業法の外部送信規律 です [1][2]。2023 年 6 月 16 日に施行され、電気通信事業者および電気通信事業を営む者がウェブサイト・アプリを通じて外部にユーザー情報を送信する場合、利用者への通知または公表を義務化しました。
外部送信規律で公表が求められる 4 項目は以下です。
| 公表項目 | 具体的に何を書くか |
|---|---|
| 送信先（情報送信指令通信の送信先） | 例：Google LLC（GA4）/ Meta Platforms（Meta Pixel）/ X Corp.（X 広告タグ） |
| 送信情報（送信される情報の内容） | 例：閲覧 URL・リファラ・ユーザーエージェント・cookie 識別子・購入金額 |
| 利用目的 | 例：アクセス解析・広告効果測定・リターゲティング配信 |
| オプトアウト手段 | 例：ブラウザ Cookie 設定・GA4 オプトアウトアドオン・該当広告アカウントの設定リンク |
実務上の注意点として、4 項目を プライバシーポリシー本文に埋め込むだけでは不十分 とされる構造があります。「外部送信に関する公表事項」のような独立したページまたはセクションとして、訪問者が容易に到達できる形で配置する運用が現実的です。
EC 事業者が抱えやすい誤解として、「弊社は電気通信事業者ではないから対象外」という理解があります。改正法の電気通信事業を営む者の解釈は広く、自社サイトで外部にユーザー情報を送信する EC 事業者の多くが対象に含まれる 設計です。GA4・Meta Pixel・各種広告タグ・チャットツール・ヒートマップツール等を 1 つでも導入していれば、対象事業に該当する可能性が高いため、4 項目の公表が必要かを確認することが推奨されます。
4. EC計測で「壊れる指標」と「壊れない指標」#
サードパーティクッキー制限と外部送信規律は、EC 計測のすべてを壊すわけではありません。何が壊れて、何が壊れないか を切り分けると、対応の優先順位が整理しやすくなります。
| 区分 | 指標例 | 影響度 | 理由 |
|---|---|---|---|
| 壊れる側 | リターゲティング配信の精度 | 大 | クロスサイト Cookie が前提のため |
| 壊れる側 | ビュースルー（インプレッション）アトリビューション | 大 | 媒体間トラッキング前提のため |
| 壊れる側 | 媒体跨ぎの個人単位 LTV | 大 | デバイス・媒体跨ぎの ID 紐付けが困難 |
| 壊れる側 | クロスドメイン GA4 セッションの一貫性 | 中 | サブドメイン跨ぎは設定で残せるが他社ドメインは難しい |
| 壊れない側 | 自社ドメイン内 CVR | 小 | ファーストパーティクッキーで十分計測可能 |
| 壊れない側 | AOV（平均注文単価） | 小 | 注文データから直接算出 |
| 壊れない側 | RPS（セッションあたり売上） | 小 | 自社サイト内のセッション × 売上で算出 |
| 壊れない側 | last-touch アトリビューション（自社内） | 小 | UTM とリファラが揃えば計算可能 |
ここで重要なのは、EC 事業者の意思決定の多くは「壊れない側」だけで完結する という点です。チャネル別 RPS が出れば、どの広告媒体に追加投資すべきかは判断できます。CVR と AOV が出れば、サイト改善か単価改善かの優先順位は決められます。
「壊れる側」の指標は、広告媒体の管理画面側（Google Ads / Meta 広告マネージャー）で、媒体内クローズドな計測として残ります。媒体間で集計を統合する個人単位 LTV のような指標は精度を取り戻すのが難しいですが、集計単位を媒体内に閉じる ことで実用に耐える数字は維持できます。
last-click アトリビューションの限界については、別記事 ラストクリック信仰の罠 ― なぜ大手ブランドはアトリビューションモデルを変えるのか で扱っています。Cookie 制限後のアトリビューション設計においても、last-click は「壊れない側」の指標として最後まで残る選択肢のひとつです。
5. ファーストパーティ計測へのシフト4ステップ#
ここまでの整理を踏まえ、EC 事業者がファーストパーティ計測へ移行するための 4 ステップを示します。
Step 1：自社ドメインでの計測点を確定する#
最初に決めるのは、自社ドメイン上のどこで何を計測するか です。具体的には以下の 5 点を確定します。
- 計測スクリプトの配置ドメイン（自社ドメイン直下推奨）
- 発行するファーストパーティクッキー（
visitor_id/session_id等）の名前と寿命 - セッションの定義（無操作タイムアウトの分数）
- 計測する主要イベント（pageview / add_to_cart / purchase 等）
- 計測しないことを明示する項目（個人特定可能情報・センシティブ情報）
ファーストパーティ計測スクリプトを自社ドメインに配置することで、Safari ITP のクッキー寿命短縮を回避でき、サブリソースとしてのブロック（広告ブロッカー等）の影響も小さくなります。
Step 2：外部送信規律の公表4項目を整備する#
第 3 章で示した 4 項目（送信先・送信情報・利用目的・オプトアウト手段）を、独立したページまたは目立つセクションとして整備します。
- 「外部送信ポリシー」のような専用ページを
/external-data-policy等のパスに配置 - フッターと初回訪問時の Cookie バナーから直接到達できる導線を確保
- GA4 / Meta Pixel / 各種広告タグ等、現状導入している外部送信を網羅的に列挙
- 新規ツール導入時に公表内容を更新するフローを社内で確定
ここで重要なのは、4 項目を書いて終わりではなく、追加・撤去のたびに更新する運用が前提 という点です。現実的には、ツール導入の意思決定プロセスにこの公表更新を組み込むのが、抜け漏れを防ぐ最短経路になります。
Step 3：UTM設計を計測の正本にする#
Cookie 制限が進む環境では、チャネル分類の正本は UTM パラメータ に寄せるのが現実解です。リファラは referrer policy・HTTPS→HTTP 遷移・アプリ内ブラウザ等で欠落しますが、URL に含まれる UTM はリファラより消えにくいためです。
utm_source/utm_medium/utm_campaignの値を、出稿ガイドラインとして社内で固定- 大文字小文字の表記揺れ・全角半角混在を避ける運用ルールを整備
- 広告管理画面のテンプレート機能を活用し、手作業での UTM 付与を最小化
- 計測側で UTM の小文字統一・trim を自動適用する処理を入れる
UTM パラメータの設計詳細は別記事 UTMパラメータの正しい使い方 で扱っています。Cookie 制限後の世界では、UTM の品質がチャネル別 RPS / ROAS の正確性に直結します。
Step 4：売上から逆引きでKPIを再定義する#
最後に、ブラウザ・法令の前提が変わったことを踏まえ、KPI を再定義する 段階に進みます。
- 「壊れる側」の指標（個人単位 LTV・媒体跨ぎビュースルー）を主要 KPI から外す
- 「壊れない側」の指標（CVR / AOV / RPS / 自社内 last-click）を主要 KPI に据える
- 媒体間統合の数字は「参考値」として扱い、意思決定の重みを下げる
- 月次レビューでは、自社ドメイン内で完結する指標から判断順序を始める
KPI 設計の考え方は別記事 マーケティングKPI設計の正解 で扱っています。Cookie 後の世界では、測れるものを増やす方向ではなく、意思決定に効くものを残す方向 に KPI を絞り込むことが、結果として現実的なマーケティング運用につながります。
6. 売上から逆引きする計測の作り方 — RevenueScope の位置づけ#
ここまでで整理した 4 ステップは、すべて 「ファーストパーティ計測点 → UTM → 売上分解 → 意思決定 KPI」 という同じ流れの上に並びます。問題は、この流れを チャネル別に切り出して 1 画面で見る仕組み が、既存のアクセス解析ツール単体では作りにくいことです。
GA4 はファーストパーティ計測のフロントエンドとして強力ですが、Cookie 制限による Direct / (none) 増加・チャネル分類の揺れ・サブドメイン跨ぎセッションといった構造的な弱点を抱えます。広告管理画面（Google 広告 / Meta 広告等）は媒体内 ROAS は出してくれますが、自社サイト全体の RPS は別途算出が必要です。
私が開発している RevenueScope は、この 「Cookie 制限後の世界で、売上から逆引きで意思決定に効く指標だけを残す」 ことに特化したアクセス解析ツールです。ファーストパーティ計測スクリプトを自社ドメインに配置し、UTM 名寄せ・チャネル別 RPS / CVR / AOV を 1 画面で見られる設計にしています。
GA4 eコマース設定をしているなら、RevenueScope の追加設定はほぼ不要です。dataLayer に相乗りで売上イベントを取得するため、新しいタグを仕込む必要がありません。「サードパーティクッキー時代の終わり」という前提を受け入れて、壊れない側の指標で意思決定を回す ための、最短の運用設計を提供します。
外部送信規律の公表 4 項目についても、RevenueScope を導入する場合の送信先・送信情報・利用目的・オプトアウト手段のテンプレートを公開しています。導入時に追加で書く文章を最小化することで、運用側の更新コストを下げる設計です。
参考文献#
[1] 総務省 「外部送信規律」 2023年6月
[2] 総務省 「電気通信事業における個人情報保護に関するガイドライン」 2024年
[3] Google for Developers 「Privacy Sandbox」 2024年
[4] Apple WebKit 「Full Third-Party Cookie Blocking and More」 2020年3月
[5] Mozilla 「Firefox rolls out Total Cookie Protection by default to more users worldwide」 2022年6月
[6] IAB Europe 「Transparency and Consent Framework v2.2」 2023年5月
[7] 経済産業省 「令和5年度電子商取引に関する市場調査の結果を取りまとめました」 2024年9月