サードパーティ
はじめに
サードパーティはウェブ上にあまねく存在しています。ウェブサイト開発者は、広告、アナリティクス、ソーシャルメディア連携、決済処理、コンテンツ配信などの主要機能を実装するためにサードパーティに依存しています。このモジュール型のアプローチは、豊富な機能の効率的かつ迅速なデプロイを可能にします。しかし、プライバシー、セキュリティ、パフォーマンスに関する潜在的な懸念をもたらします。今年新たに、使用されているコンセントフレームワークやシグナルを受け取るサードパーティを含め、ユーザーのコンセント選択がウェブ上のサードパーティ間でどのように伝達されるかを分析しています。
本章では、ウェブにおけるサードパーティの使用パターンについて実証的な分析を行います。以下の観点から調査します:
- 普及率: どれだけのウェブサイトがサードパーティを使用しているか、またその割合
- リソースタイプ: サードパーティが取る形式(画像、JavaScript、フォントなど)
- 機能カテゴリ: 広告ネットワーク、アナリティクス、CDN、動画プロバイダー、タグマネージャーなど
- 統合方法: サードパーティがページに直接または間接的にどのようにロードされるか
- コンセントインフラ: どのサードパーティがコンセントシグナルを転送し、それらの転送が実際にどのように行われているか
定義
まず、分析全体で使用される定義と用語を確認します。
サイトとページ
本章では、これまでの年と同様に、「サイト」という用語を特定のドメインの登録可能な部分を表すために使用します。これはしばしば拡張トップレベルドメインプラス1(eTLD+1)と呼ばれます。例えば、URL https://www.bar.com/ のeTLD+1は bar.com であり、URL https://foo.co.uk のeTLD+1は foo.co.uk です。「ページ」(またはウェブページ)とは、固有のURL、より具体的には特定のURLに存在するドキュメント(例えばHTMLやJavaScript)を意味します。
サードパーティとは?
以前のバージョンとの比較を可能にするため、Web Almanacの前版で使用されたサードパーティの定義に従います。
サードパーティ とは、サイトオーナー(ファーストパーティとも呼ばれる)とは異なるエンティティです。サイトオーナーが直接実装・提供していないサイトの側面を含みます。より正確には、サードパーティのコンテンツはユーザーが最初に訪問したサイトではなく、別のサイトからロードされます。ユーザーが example.com(ファーストパーティ)を訪問し、example.com が awesome-cats.edu から面白い猫の画像を含んでいる(例えば <img> タグを使って)とします。このシナリオでは、awesome-cats.edu はユーザーが最初に訪問したものではないため、サードパーティです。ただし、ユーザーが直接 awesome-cats.edu を訪問した場合、awesome-cats.edu はファーストパーティとなります。
分析では、HTTP Archiveデータセットの少なくとも5つの固有ページでリソースが見つかるドメインから発生するサードパーティのみを含めました。
サードパーティのコンテンツがファーストパーティドメインから直接提供される場合、ファーストパーティのコンテンツとしてカウントされます。例えば、セルフホストされたアナリティクススクリプト、CSS、またはフォントはファーストパーティのコンテンツとしてカウントされます。同様に、サードパーティドメインから提供されるファーストパーティのコンテンツはサードパーティのコンテンツとしてカウントされます。一部のサードパーティは異なるサブドメインからコンテンツを提供しています。ただし、サブドメインの数に関わらず、単一のサードパーティとしてカウントされます。
さらに、サードパーティがファーストパーティに偽装されることがますます一般的になっています。これを可能にする2つの主要な技術があります:
-
CNAMEクローキングは、CNAMEレコードを使用してサードパーティのコンテンツがファーストパーティドメインから来ているように見せる技術です。本分析では、CNAMEクローキングされたサービスはファーストパーティとして扱います。
-
サーバーサイドトラッキングは、サイトオーナーがトラッカーをファーストパーティとして組み込み、すべてのリクエストをファーストパーティドメイン経由でルーティングし、トラッカーをファーストパーティのように見せる新興のトレンドです。例えば、ウェブサイト
www.example.comがサーバーサイドGoogle Tag ManagerをGoogle Analyticsとともに組み込み、サブドメインsst.example.comをクロークしてGoogle Tag Managerコンテナにリクエストを送信する場合があります。このようにして、サードパーティへのリクエストはユーザーのブラウザではなく、タグマネージャーのサーバーから発生します。
分析では、サードパーティの通信はサーバー間で行われ、クライアントサイドのHTTP Archiveデータでは直接観測できないため、このようなケースをファーストパーティのインタラクションとして扱います。その結果、私たちの測定値はウェブ上のサードパーティの実際の普及率の下限を表しています。
カテゴリ
前述の通り、サードパーティは動画の埋め込み、広告の配信、ソーシャルメディアサイトのコンテンツの埋め込みなど、様々なユースケースで使用できます。昨年と同様に、データセットで観察されたサードパーティをカテゴリ分けするために、Patrick HulceによるThird-Party Webリポジトリを使用します。このリポジトリは以下のカテゴリでサードパーティを分類しています:
- Ad(広告): これらのスクリプトは広告ネットワークの一部で、広告の配信または計測を行います。
- Analytics(アナリティクス): これらのスクリプトはユーザーとその行動を計測またはトラッキングします。追跡対象によって影響範囲は大きく異なります。
- CDN: これらは公開CDNや私有CDNを通じて配信される、公開ホストされたオープンソースライブラリ(例:jQuery)と私的なCDN使用の混合です。
- Content(コンテンツ): これらのスクリプトはコンテンツプロバイダーまたは出版特有のアフィリエイトトラッキングからのものです。
- Customer Success(カスタマーサクセス): これらのスクリプトはチャットや問い合わせソリューションを提供するカスタマーサポート/マーケティングプロバイダーからのものです。これらのスクリプトは一般的に重量が大きいです。
- Hosting(ホスティング): これらのスクリプトはウェブホスティングプラットフォーム(WordPress、Wix、Squarespaceなど)からのものです。
- Marketing(マーケティング): これらのスクリプトはポップアップ/ニュースレターなどを追加するマーケティングツールからのものです。
- Social(ソーシャル): これらのスクリプトはソーシャル機能を有効にします。
- Tag Manager(タグマネージャー): これらのスクリプトは多くの他のスクリプトをロードし、多くのタスクを開始する傾向があります。
- Utility(ユーティリティ): これらのスクリプトは開発者向けのユーティリティ(APIクライアント、サイト監視、不正検出など)です。
- Video(動画): これらのスクリプトは動画プレーヤーとストリーミング機能を有効にします。
- Consent provider(コンセントプロバイダー): これらのスクリプトはサイトがユーザーのコンセントを管理することを可能にします(例:一般データ保護規則のコンプライアンスのため)。クッキーコンセント ポップアップとも呼ばれ、通常はクリティカルパスでロードされます。
- Other(その他): これらは正確なカテゴリや帰属のない共有オリジン経由で配信される雑多なスクリプトです。
Content-Type
Content-Type HTTPヘッダーを使用して、サードパーティリソースをスクリプト、HTMLコンテンツ、JSONデータ、プレーンテキスト、画像などの異なるタイプに分類します。これにより、ウェブサイト全体で配信されるサードパーティリソースの構成を分析できます。
普及率
前年と比較して、ウェブサイト全体で1つ以上のサードパーティを使用しているページの割合にわずかな減少が見られます。ただし、この減少にもかかわらず、1つ以上のサードパーティを持つページの割合は90%以上を維持しています。
前年と比較して、全ウェブサイトランクにわたってサードパーティドメインの中央値が大幅に減少しており、特に低ランクのウェブサイトで大きな減少が見られます。
この減少にはいくつかの要因が考えられます。第一に、サードパーティはCNAMEクローキングやサーバーサイドトラッキングを通じてますます隠蔽されており、クライアントサイドの計測での可視性が低下する可能性があります。第二に、HTTP Archiveのクローラーはウェブページとのインタラクションやページのスクロールを行わないため、遅延ロードにより一部のサードパーティが正しくロードされない場合があります。その結果、観察されるサードパーティリクエストが少なくなる可能性があります。
また、デスクトップページはモバイルページよりも一般的に多くのサードパーティを含んでいることも確認されています。
低ランクのウェブサイトはより多くのサードパーティリクエストをロードします。トップ1,000はデスクトップで129リクエスト、モバイルで106リクエストの中央値を持ち、全サイトのデスクトップ83リクエスト、モバイル79リクエストと比較しています。
前年比で、すべてのランクにわたってサードパーティリクエストが増加しています。トップ1,000サイトは2024年と比較してデスクトップで15リクエスト、モバイルで15リクエストの増加を示しており、より広いデータセットではデスクトップで5リクエスト、モバイルで5リクエスト増加しました。この上昇トレンドは、先ほど観察したユニークなサードパーティドメイン数の減少にもかかわらず起きており、個々のサードパーティがページあたりより多くのリクエストを送信していることを示しています。
棒グラフはランクとカテゴリ別のページあたりのサードパーティプロバイダーの中央値を示しています。前版ではこの分析はランクとカテゴリ別のページあたりのサードパーティドメイン数に焦点を当てていましたが、今年はユニークなサードパーティプロバイダーの数を計測しており、全体的に低い数値となっています。今年のトップカテゴリは ad、analytics、cdn です。
script(24.8%)、image(19.9%)、その他(13.9%)です。チャートはサードパーティリクエストが script、image、other カテゴリによって支配されていることを示しています。script、image、other の合計は全サードパーティリクエストのコンテンツタイプの半数以上を占めています。このパターンは script、image、other もトップリクエストタイプとして特定した2024年版と一致しており、昨年からほとんど変化がないことを示しています。
トップ10のサードパーティドメインは fonts.googleapis.com、googletagmanager.com、google-analytics.com、accounts.google.com、adservice.google.com を含むGoogle所有のサービスが独占しています。Metaの facebook.com はトップ10で唯一のGoogle以外のドメインで、21%のページで7位にランクインしています。
サードパーティ間のコンセント伝達
このセクションでは、異なるサードパーティがウェブ全体でユーザーコンセントをどのように転送しているかを調査します。先行研究では、サードパーティがコンセント情報の伝達に業界標準フレームワークに依存することが多いことが示されています。分析では、IABの3つのコンセント標準、すなわち透明性とコンセントフレームワーク(TCF)、CCPAフレームワーク、およびグローバルプライバシープロトコル(GPP)に主に焦点を当てています。
これらのフレームワークはコンセント情報がウェブサイトとサードパーティ間でどのようにエンコードされ共有されるかを定義しています。データセットで観察されたサードパーティの中でどのコンセント標準が最も普及しているかを特定することから始めます。サードパーティが使用するフレームワークを判定するために、リクエストURLの特定パラメータの存在に依存しています。異なる標準の詳細は以下の通りです:
-
TCF標準: IAB TCFで指定されているように、サードパーティリクエストに
gdprまたはgdpr_consentパラメータが含まれているかを確認することでTCFフレームワークの使用を特定します。 -
GPP標準:
gppとgpp_sidパラメータの存在を確認することでGPPフレームワークの使用を特定します。 -
USP標準と非USP標準: IAB CCPAフレームワークで定義されているように、リクエストが
us_privacyパラメータを送信しているかを確認することでUSP標準の使用を特定します。また、先行研究で特定された非標準パラメータを通じて送信されるコンセント文字列を検出することで、非標準USP標準の使用も特定します。
ウェブサイトランク、サードパーティカテゴリ、およびコンセントを受け取る最も頻繁に観察されるサードパーティにわたってコンセントシグナルの普及率を分析します。
異なるランクにわたるコンセントシグナルの普及率
TCF標準が主要なコンセント標準であり、特に低ランクサイトでは全サイトの18%に対して36%に達しています。この高い採用率はGDPR下での強力なオプトインコンセント要件と一致しています。USP標準は2番目に普及しており、ランク全体で9〜17%の採用率です。これはCCPAに対応して導入されたIAB CCPAコンセントフレームワークの使用を反映しています。GPPの採用は管轄区域をまたいでコンセントフレームワークを統一するという目標にもかかわらず、3〜6%と最小限に留まっています。
異なるカテゴリにわたるコンセント標準の分布
異なるサードパーティカテゴリにわたって異なるコンセント標準の選好が見られます。例えば、Socialサービスは最高のTCF採用率を示している一方、広告ベンダーはGPP、USP標準、そして小さなTCFシェアのより均衡した組み合わせを採用しています。さらに、Analyticsベンダーは主にGPPを採用しています。
コンセントを受け取るトップサードパーティ
トップランクのウェブサイトの中で、pubmatic.com が最も多くのコンセントシグナルを受け取り、adservice.google.com が2位です。最も多くのコンセントシグナルを受け取るドメインの大多数は広告とアドテクベンダー(広告取引所、DSP、広告サーバー)です。多くの管轄区域でサードパーティの広告やアナリティクスプロバイダーが広告やその他の目的でユーザーデータを使用する前にユーザーのコンセントを取得しなければならないことを考えると、これは直感的に理解できます。
インクルージョン
先ほどの例を振り返ると、example.com(ファーストパーティ)が awesome-cats.edu(<img> タグによるサードパーティ)から画像を含めることができます。この画像のインクルージョンは直接インクルージョンとみなされます。しかし、もし画像が XMLHttpRequest を介してサイト上のサードパーティスクリプトによってロードされた場合、その画像のインクルージョンは間接インクルージョンとみなされます。間接的にインクルードされたサードパーティはさらに追加のサードパーティを含める場合があります。例えば、サイトに直接インクルードされたサードパーティスクリプトが、さらに別のサードパーティスクリプトを含める場合があります。本章では、サードパーティのインクルージョンチェーンの深さについて基本的な分析を行います。
インクルージョンチェーンの中央深度は3であり、サードパーティの大多数がウェブページ上で少なくとも別のサードパーティを含めていることを意味します。インクルージョンチェーンの最大深度は2,285です。
結論
私たちの調査結果は、ウェブ上のサードパーティの遍在性と集中化が進んでいることを示しています。10のウェブページのうち9つ以上が1つ以上のサードパーティを含んでいます。前年と比較してユニークなサードパーティドメインの中央値は減少していますが、サードパーティからのリクエストの総数は大幅に増加しており、個々のベンダーがページあたりより多くのリクエストを送信していることを示しています。
コンセント標準に関しては、TCFが全ウェブサイトランクにわたって主要なコンセント標準です。個々のサードパーティの中では、pubmatic.com、adservice.google.com およびその他のアドテクドメインが最も多くのコンセントシグナルを受け取っています。
最後に、CNAMEクローキングやサーバーサイドトラッキングなどの難読化技術の使用の増加は、クライアントサイドの計測でのサードパーティの可視性を低下させており、私たちの調査結果が実際の普及率の下限を表していることを示しています。