レポート | DTC成長スタックに潜む見えないコスト

読者の位置づけ

本レポートは、現代のDTCスタックが生む結果と日々向き合っている方々に向けて書いています。具体的には、グロース責任者、Eコマースマネージャー、パフォーマンスマーケター、ライフサイクルチーム、マーケティングオペレーション、テクニカルSEOチーム、フロントエンドエンジニア、アナリティクス担当者、そして、必要そうなツールを全部入れているはずなのに、なぜかサイトが遅いのかと問い続ける創業者です。

元のDTCサイトベンチマークでは、各ブランドがどのツールを使っているかを示しました。今回の調査では、別の問いを立てています。そうしたツールをストアフロントに積み重ねると、運用コストはどれだけ膨らむのか？

答えは「ツールは悪だ」ではありません。DTCブランドがアナリティクス、リテンション、アトリビューション、レビュー、チャット、サポート、決済、アップセル、実験系ツールを使うのは、それらが実際の売上課題を解決するからです。重要なのは、追加のレイヤーが増えるたびに、フロントエンドコスト、QAコスト、同意管理コスト、データ品質コスト、保守コストが発生するという点です。成長スタックは成長の余地を広げる一方で、インフラの負荷も増やします。

SEOやECコンテンツのライターにとって、本レポートは「DTCブランドはたくさんのツールを使っている」という話より、ずっと使いやすい切り口を提供します。より強いストーリーは、DTCの定番成長プレイブックが、パフォーマンスとガバナンスの問題になっているということです。

エグゼクティブサマリー

1,238件の採点済みDTCドメインを横断すると、このサンプルのホームページ中央値には52個のスクリプトタグと8つのサードパーティドメインが含まれています。これらは抽象的な技術指標ではありません。スクリプトとサードパーティドメインは、ブラウザ側から見えるブランドの成長スタックの証拠です。つまり、アナリティクス、ピクセル、リテンションツール、チャット、レビュー、パーソナライゼーション、決済、アップセル、実験、同意、サポートです。

このコストは、アナリティクスとマーケティングの深さでブランドを分けると、さらにはっきり見えてきます。

差は明白です。アナリティクスツール0〜2個のブランドを最初の2区分としてまとめると、スクリプト中央値は16個、サードパーティドメイン中央値は4つです。一方、アナリティクスツール5個以上のブランドでは、スクリプト中央値が69個、サードパーティドメイン中央値が11個になります。つまり、重い成長スタックは、低アナリティクス群の4倍超のスクリプト負荷を抱えているということです。

相関データも同じ傾向を示しています。スタック深度はスクリプト数と0.731の相関、サードパーティドメイン数と0.547の相関があります。アナリティクスツール数は、スクリプト数と0.658の相関、サードパーティドメイン数と0.557の相関です。リテンションツール数も、スクリプト数と0.611という有意な相関があります。これは単なる一部の外れ値ではありません。公開されている成長スタックが拡大するほど、ブラウザ側の複雑性が増していくという構造的なパターンです。

本レポートは、プライバシーとガバナンスのギャップも明らかにします。ここではCookiebot / OneTrust系の可視シグナルで測定した同意管理の出現率は、採点済みドメイン全体でわずか**9.6%です。アナリティクスツール5個以上のブランドでも、同意管理カバレッジは14.0%**にとどまります。これは他のブランドが非準拠だと断定するものではありません。なぜなら、同意ツールはこの検出方法では見えない形で実装されることがあるからです。ただし、トラッキングが多いサイトの多くで、取得したHTML上に明確な同意管理シグナルが見えていないことは示しています。

さらに、16.2%のドメインがextremeスクリプト負荷層に分類されました。ここでは、75個を超えるスクリプトタグをその定義としています。これはテクニカルSEO、グロースオペレーション、フロントエンドチームにとって有用なベンチマークです。DTCホームページに75個以上のスクリプトがあるなら、それはもはや単なるマーケティングページではありません。責任の所在が必要なインフラです。

中心的な結論はこうです。DTCの成長成熟度とストアフロントの複雑性は同時に高まる。次の競争優位は、さらにツールを足すことではない。すでにあるスタックを統治することです。

最も共有されやすい発見

1. このサンプルのDTCホームページ中央値には、52個のスクリプトタグと8つのサードパーティドメインがあります。

2. アナリティクスツール5個以上のブランドでは、スクリプト中央値69個、サードパーティドメイン中央値11個です。

3. アナリティクスツール0〜2個のブランドでは、スクリプト中央値16個、サードパーティドメイン中央値4つです。

4. 採点済みドメインの16.2%が、極端なスクリプト負荷層に入っています。

5. 同意管理の可視性は全体で9.6%しかなく、アナリティクスツール5個以上のブランドでも14.0%にすぎません。

6. スタック深度はスクリプト数と0.731という強い相関があります。

7. DTCの成長スタックは、もはや単なるマーケティングスタックではありません。フロントエンドのインフラです。

1. 成長スタックのコストが重要な理由

DTCチームは通常、ツールを期待される上振れで評価します。たとえば、より良いアトリビューション、より多いメール売上、より高いAOV、より良いサポート、よりクリーンなレビュー、より強いパーソナライゼーション、より良いリテンション、より高い広告最適化、より大きなCVR改善です。これは当然です。グロースチームは、成長するために雇われているのです。

ただし、どのツールにもコストがあります。見えやすいものとしては、サブスクリプション費用、導入作業、契約管理があります。見えにくいものとしては、ページ速度の低下、JavaScriptの増加、サードパーティ呼び出しの増加、QAパターンの増加、同意ロジックの複雑化、タグ衝突、アトリビューションの不一致、プライバシー審査の増加、ベンダー所有権の不明確化があります。

本レポートは、この見えないコストに焦点を当てています。スクリプト数、サードパーティドメイン数、スタック深度、ツールカテゴリ、プラットフォーム群、カテゴリ群を、複雑性の代理指標として使っています。スクリプト数が多いことが常に悪いとは主張しません。成果を出しているブランドは、各スクリプトが売上機能を支えているなら、合理的に多くのスクリプトを抱えることがあります。ただし、ガバナンスのない高複雑性は危険です。

正しい問いは、「どうすれば全部のツールを消せるか？」ではありません。正しい問いは、**どのツールが今もページ上の居場所を稼いでいるのか？**です。

2. ベースライン：52スクリプト、8サードパーティドメイン

このサンプルのホームページ中央値は次のとおりです。

• 52個のスクリプトタグ
• 8つのサードパーティドメイン

基礎となるパフォーマンス調査のp75値はさらに高く、69スクリプト、12サードパーティドメインです。最大値はもっと高いのですが、本レポートでは外れ値を悪例として使うのではなく、分布に焦点を当てています。

運用の観点では、中央値だけでも十分に意味があります。DTCのホームページは、HTML、CSS、商品画像、そしてチェックアウト導線だけでできていることは稀です。むしろ、さまざまなシステムをつなぐ調整レイヤーです。アナリティクス、ピクセル、タグマネジメント、セッション録画、レビュー、サポート、診断コンテンツ、ポップアップ、サブスクリプション、パーソナライゼーション、決済、同意、実験などが含まれます。

見えないコストは、いくつもの場所に現れます。

パフォーマンスコスト。 スクリプトが増えると、描画遅延、メインスレッドの競合、ネットワークリクエストの増加が起こり、Core Web Vitalsにも影響します。

QAコスト。 ベンダースクリプトが増えるたびに、デスクトップ、モバイル、同意承諾、同意拒否、ログイン状態、ログアウト状態、カート状態、チェックアウト導線、地域ドメイン、ブラウザ差異といったテスト対象が増えます。

アトリビューションコスト。 タグが増えれば、データ品質が上がるとは限りません。数値の食い違い、イベントの重複、チャネル貢献度の不一致を生むことがあります。

プライバシーコスト。 トラッキングの接点が増えるほど、同意とコンプライアンスの論点も増えます。

所有コスト。 ツールは、導入者本人より長生きすることがよくあります。チームがダッシュボードを使わなくなった後も、スクリプトだけがサイトに残っていることがあります。

だからこそ、成長スタックはマーケティングの付属品の寄せ集めではなく、インフラとして管理すべきなのです。

3. 最も明確なコスト要因はアナリティクス深度

調査の中で最も強い表は、アナリティクス深度の内訳です。

この表は、漠然とした懸念を具体的なベンチマークに変えてくれます。アナリティクスツール1〜2個から3〜4個へ増やすと、スクリプト中央値は30から54へとほぼ倍増します。5個以上にすると、中央値はさらに69まで上がります。

0個のグループを、より優れていると解釈すべきではありません。そうしたサイトの多くは、未整備、待機中、非常に単純、クライアントレンダリング中心、あるいは検出漏れの可能性があります。実際に比較すべきなのは、主流の運用グループである1〜2個、3〜4個、5個以上のアナリティクスツール群です。

特に重要なのは5個以上のアナリティクス群です。ここは、計測とグロースオペレーションに最も力を入れているブランドです。広告獲得、リテンション、アトリビューション、セッション行動、サポート、レビュー、CVR最適化に関心がある可能性が高い一方で、依存関係の負荷も最も重くなります。

これが成長スタックのパラドックスです。計測に最も真剣なブランドほど、計測オーバーヘッドの影響を受けやすいのです。

4. 相関関係：これは偶然ではなく構造です

相関マトリクスは、スタックの複雑性がランダムではないことを示しています。

スクリプト数との関係が最も強いのはスタック深度です。これは予想どおりですが、重要です。というのも、スタック深度はしばしば前進の証のように扱われるからです。ツールが増えれば機能も増えます。しかし、その分フロントエンドの重量も増します。

決済は、スクリプト数と0.689という意外に強い相関を示しています。だからといって、決済手段が悪いわけではありません。複数の決済導線や決済連携は、複雑性の一部だということです。特にAOVが高いカテゴリでは、複数決済への対応がCVR改善につながることがあります。ただし、それらの連携も技術ガバナンスの対象に含めるべきです。

リテンションツール数はスクリプト数と0.611で相関しています。これは直感的です。ライフサイクル系のツールは、オンサイトフォーム、ポップアップ、識別スクリプト、SMS取得、パーソナライゼーション、イベント収集を増やしがちです。リテンションはメールの中だけにあるのではありません。ストアフロントにも存在します。

ガバナンス上の含意は明快です。パフォーマンスはエンジニアリングだけでは解決できません。マーケティング、ライフサイクル、リテンション、広告、アナリティクス、Eコマースが、すべてページ上にコードを載せています。だからこそ、全員がパフォーマンスガバナンスに参加する必要があります。

5. プラットフォーム傾向：Shopifyサイトは可視スタックが重い

プラットフォーム別の比較は、サンプルがEコマースのツールエコシステムに偏っており、Shopifyが過剰代表されているため、慎重に読む必要があります。それでも、プラットフォーム表は公開シグナルのベンチマークとして有用です。

サンプル内のShopifyサイトは、スクリプト中央値64個、サードパーティドメイン中央値9つ、平均スタック深度6.3でした。これは「Shopifyがスクリプトを生む」という意味ではありません。より妥当な解釈は、このサンプルにおけるShopifyブランドが、アプリエコシステム、チェックアウト連携、ライフサイクルツール、レビュー系ツール、サポート系ツール、成長ベンダーに強くさらされているということです。

不明グループは、スクリプト中央値6個、サードパーティドメイン中央値2つですが、戦略的に見て必ずしも軽量とは限りません。不明なプラットフォームのサイトには、プラットフォームの痕跡を隠しているもの、ヘッドレス構成のもの、検出漏れのもの、あるいはサーバーサイドのマークアップが少ないものが含まれます。正しい読み方は、内部スタック全体ではなく、公開上の可視性です。

プラットフォーム表は、社内ベンチマークに特に役立ちます。ShopifyのDTCサイトに90個のスクリプトがあれば、このサンプルのShopify中央値を上回っています。40個なら下回っています。ここでの目的は、スクリプト数が多いサイトを非難することではありません。レビューのための基準を作ることです。

6. カテゴリ傾向：美容、食品、アパレル、ウェルネスは重いスタックを抱える

カテゴリ表を見ると、高成長DTCカテゴリほどスクリプト負荷が高い傾向があります。

美容・スキンケア、食品・飲料、アパレル・フットウェア、ヘルス・ウェルネスはいずれも、全体中央値に近い、あるいはそれを上回るスクリプト数を示しています。これらのカテゴリは競争が激しく、コンテンツ量が多く、ライフサイクル主導であることが多いです。教育コンテンツ、レビュー、広告獲得、クリエイター発見、サブスクリプション、ロイヤルティ、診断、パーソナライゼーションに依存するため、自然とツール数が増えます。

食品・飲料が興味深いのは、スクリプト中央値が高い一方で、同意管理の可視性が**5.9%**と比較的低いことです。これはコンプライアンス上のギャップを証明するものではありませんが、特に国際展開している場合、トラッキングが多い食品・飲料ブランドにとってガバナンス上の問いを生みます。

アパレル・フットウェアは、主要カテゴリの中で最も高い同意管理カバレッジ**16.1%を示しました。美容・スキンケアも15.3%**と近い水準です。これらのカテゴリは、このサンプル内では、より広い海外展開、より洗練された広告運用、より成熟したEコマーススタックを持っている可能性があります。

カテゴリから得られる教訓は、「あるカテゴリが悪い」ということではありません。重要なのは、パフォーマンスガバナンスはカテゴリを意識して設計すべきだということです。レビュー、診断、サブスクリプション、SMS取得、アトリビューションを持つ美容ブランドは、複雑性の低いカタログサイトとは当然見た目が異なります。ベンチマークは優先順位付けの指針であって、全カテゴリ共通の単一目標ではありません。

7. 同意管理：トラッキングとガバナンスの間にあるギャップ

同意管理は、採点済みドメイン全体で**9.6%にしか見られません。アナリティクスツール5個以上のブランドでも、出現率は14.0%**です。

これは最重要の発見のひとつです。グロースの計測基盤とプライバシーガバナンスがつながっているからです。スタックが重いほど、同意ロジックの重要性は高まります。それでも、Cookiebot / OneTrust系の可視シグナルは、なお比較的まれです。

この指標には注意点があります。ブランドが検出対象外の同意管理ツールを使っている可能性があります。独自ソリューションで同意を実装しているかもしれません。動的に同意スクリプトを読み込んでいる場合もあります。あるいは、異なるコンプライアンス期待を持つ市場を主に対象にしていることもあります。したがって、この数値を「わずか9.6%しかプライバシー法に準拠していない」と引用するのは強すぎますし、おそらく誤りです。

より正確な引用は、次のように限定されます。採点済みドメインの9.6%だけが、取得されたHTML上でCookiebot / OneTrust系の同意管理シグナルを露出している。 それでも十分に有益です。多くのトラッキング重視ストアが、公開クロール上では同意ガバナンスを明示していないことを示唆しているからです。

運用側にとってのアクションはシンプルです。法務監査を待ってトラッキング一覧を作るのではなく、目的、所有者、ベンダー、収集データ、同意カテゴリ、読み込み条件を含むタグマップを作ってください。グロースチームは、どのタグが同意前に発火し、どのタグが同意後に発火し、どのページで発火するかを把握すべきです。

8. 極端なスクリプト層：マーケティングページがインフラになるとき

本調査では、extremeスクリプト負荷層を75個を超えるスクリプトタグと定義しています。この基準では、**採点済みドメインの16.2%**が極端層に入ります。

極端だからといって、必ずしも間違いではありません。マルチリージョン配信、重いレビュー基盤、豊富な商品説明、パーソナライゼーション、複数の広告ネットワーク、アナリティクス、サポート、実験、チェックアウト連携など、複雑な要件を持つブランドもあります。複雑なブランドには、複雑なページが必要なこともあります。

ただし、極端な状態はガバナンスを発動させるべきです。75個を超えるスクリプトがあると、ホームページは単純なマーケティング資産ではありません。インフラです。必要なのは、

• スクリプト所有者一覧
• タグ読み込みポリシー
• 同意カテゴリのマッピング
• パフォーマンス監視
• ベンダー整理の定期実施
• カートとチェックアウトのQA導線
• イベント重複排除ルール
• 壊れたベンダーに対するロールバック計画

最も危険なスクリプトは、最も重いものではありません。所有者不在のスニペットです。いまのチームの誰も責任を持たず、誰も開かないダッシュボードにデータを送り、誰も監査しないページを遅くしているベンダースニペットこそ危険です。

9. 運用者のプレイブック：成長スタックをどう統治するか

このレポートへの実務的な対応は、ツールの一掃ではありません。ガバナンスワークフローです。

ステップ1：すべてのスクリプトを棚卸しする。 ホームページ、商品ページ、コレクションページ、カート、チェックアウト直前のページから、すべてのスクリプトソースを出力します。可能ならインラインスクリプトも含めます。

ステップ2：所有権を割り当てる。 すべてのスクリプトに、事業オーナーと技術オーナーが必要です。オーナーを誰も挙げられないなら、そのスクリプトは削除候補です。

ステップ3：目的を分類する。 獲得、リテンション、アトリビューション、レビュー、顧客サポート、決済、パーソナライゼーション、実験、同意、分析、監視、レガシーのいずれかです。

ステップ4：同意挙動をマッピングする。 各スクリプトが必須、分析、マーケティング、パーソナライゼーション、サポートのどれに当たるかを決めます。いつ発火するかも確認します。

ステップ5：実際の利用状況を確認する。 ダッシュボードは実際に使われていますか。ベンダー契約はまだ有効ですか。レポートは確認されていますか。意思決定にそのツールが使われていますか。

ステップ6：影響を測定する。 可能であれば、重いベンダーを有効・無効にした状態でページ性能を比較します。Core Web Vitals、操作遅延、メインスレッドのブロッキングを追跡します。

ステップ7：統合する。 同じ機能を持つツールが2つあるなら、1つに絞ります。重複したアトリビューションやアナリティクスツールは、明快さよりも議論を生みがちです。

ステップ8：四半期ごとに見直す。 成長スタックにも、広告アカウントやメールフローと同じように、整理のサイクルが必要です。

このワークフローによって、パフォーマンスの話はエンジニアの不満ではなく、運用規律に変わります。

10. SEOとコンテンツチームが引用できること

この調査は、いくつもの強いコンテンツ切り口を生みます。

「DTCホームページの中央値は52スクリプトです。」 これは最も広いパフォーマンスフックです。

「アナリティクススタックが重いほど、ページも重くなる。」 アナリティクスツール5個以上のブランドはスクリプト中央値69個で、0〜2個のブランドの16個を大きく上回ります。

「成長成熟度はパフォーマンス負債を生む。」 計測とライフサイクル基盤に最も力を入れるブランドほど、フロントエンドの依存関係が増えます。

「同意の可視性はトラッキングの深さに追いついていない。」 アナリティクスツール5個以上のサイトでさえ、可視同意管理カバレッジは14.0%しかありません。

「DTCのパフォーマンスは、もはや開発者だけの問題ではない。」 マーケティング、ライフサイクル、広告、サポート、アナリティクスが、すべてページにコードを置いています。

ただし注意点があります。スクリプト数を、パフォーマンスが悪い証拠として提示してはいけません。依存負荷とガバナンスの必要性を示す代理指標として使ってください。

11. 各チームはこのレポートをどう読むべきか

成長スタックの見えないコストは、部門横断です。だからこそ解決が難しいのです。各チームは問題の異なる部分を見ています。

グロースチームは売上の上振れを見ます。より良いアトリビューション、より精密なオーディエンス、強いリターゲティング、より明確なキャンペーンフィードバック、ランディングページテスト、ライフサイクル獲得を求めます。彼らの視点では、新しいスクリプトは、より測定可能な売上のための小さな対価であることが多いです。

フロントエンドチームは依存コストを見ます。彼らは、ページの遅延、レイアウトシフト、ブラウザエラー、サードパーティ障害、メインスレッドのブロック、ハイドレーションの問題、自分たちが所有していないスクリプトによるQA失敗に対処しています。彼らの視点では、マーケティングタグは管理されていない本番依存関係のように振る舞うことが多いのです。

SEOチームは順位とクロールのコストを見ます。Core Web Vitals、レンダリング性、構造化データ、クロール効率、ユーザー体験を重視します。サイトが遅くなったり壊れやすくなったりすると、その新しいベンダーが広告成長やリテンション目的で追加されたとしても、SEOパフォーマンスは低下しえます。

データチームは計測コストを見ます。ツールが増えると、イベント重複、ダッシュボード間の不一致、UTMの破損、チャネル貢献度の争い、どの数値を意思決定に使うべきかという不確実性が増えます。

法務・プライバシーチームは同意コストを見ます。トラッキングが増えるほど、ベンダー審査、データ処理の確認、同意カテゴリ、地域別挙動、リスク管理も増えます。

経営陣は予算と説明責任のコストを見ます。各ツールにはサブスクリプション費用がありますが、より大きいコストは、データの突合、連携保守、サイト問題の修正に費やす時間かもしれません。

本レポートの最も重要なマネジメント上の教訓は、この問題全体を標準では誰も単独で所有していないということです。成長スタックには共有された運用モデルが必要です。実務的には、グロース、ライフサイクル、Eコマース、SEO、エンジニアリング、アナリティクス、プライバシーを代表者として集める四半期ごとの「スタック評議会」が有効です。議題はシンプルでよく、何が追加され、何が削除され、何がまだ使われ、何がサイトを遅くし、何が法的にセンシティブで、何が測定可能な価値を生んでいるのか、です。

これは官僚的に聞こえるかもしれませんが、代替案はもっと悪いです。異なるチームが何年もかけてベンダースニペットを入れ続け、共通の地図も整理サイクルもない状態になるからです。

12. スタックレビューのテンプレート

DTCチームは、この調査を四半期レビューに変えることができます。シンプルな表で十分です。1行が1つのツールまたはスクリプトです。

ベンダーまたはスクリプト名。 それは何か。

事業オーナー。 誰が導入を求め、今も誰が使っているか。

技術オーナー。 誰が安全に削除または変更できるか。

目的。 獲得、リテンション、アトリビューション、サポート、レビュー、パーソナライゼーション、決済、実験、同意、監視、レガシーのいずれか。

読み込まれるページ。 ホームページ、商品ページ、コレクションページ、カート、チェックアウト、ブログ、ランディングページ、または全体共通。

同意カテゴリ。 必須、分析、マーケティング、パーソナライゼーション、サポート、不明のいずれか。

最終レビュー日。 チームがそのツールの有用性を最後に確認したのはいつか。

意思決定の証拠。 どの指標またはワークフローがそれに依存しているか。

パフォーマンスへの影響。 スクリプト数、サードパーティリクエスト、メインスレッド作業、Core Web Vitalsに実質的な影響があるか。

維持、延期、統合、削除。 結論は何か。

このテンプレートに高度なエンジニアリング基盤は不要です。スプレッドシートから始められます。大事なのは形式ではなく、説明責任です。ツールにオーナーと目的が付いた瞬間、チームは合理的に取捨選択できるようになります。この地図がなければ、あらゆるパフォーマンス議論は政治化します。

最良の成果は、最もスクリプト数が少ないことではありません。最良の成果は意図されたスタックです。放置されたベンダーが減り、同意挙動が整い、重複タグが減り、アナリティクスが信頼でき、真に重要なツールの性能が向上することです。

13. 最低限の実行可能なガバナンス基準

四半期ごとのスタック評議会をすぐに回せないチーム向けに、より軽い版もあります。まずは3つのルールから始めてください。

第一に、新しいベンダースクリプトは、オーナー、目的、削除条件が決まるまで追加しないこと。削除条件が重要なのは、多くのスクリプトがキャンペーン、テスト、移行、一時的なローンチのために導入され、そのまま静かに恒久化するからです。

第二に、すべてのアナリティクスまたはマーケティングタグは、公開前に同意カテゴリを持たせること。マーケティングチームに法的な完全性を求める必要はありませんが、プライバシー審査へつなぐ文書化された経路は必要です。

第三に、稼働中のストアフロントベンダーについて、チームは単一の正本を保つこと。インシデント中にページソースを調べないと何が動いているか分からないなら、そのスタックはすでに未管理です。

この3つのルールだけでは、すべてのパフォーマンス問題は解決しません。しかし、最もよくある失敗、つまり、記憶を持たないまま拡大し続ける成長スタックは防げます。

方法論

本調査は、2026年5月11日に収集されたDTC二重レポート用データセットを使用しています。master.csv、perf_metrics.csv、categories.csvを用いて1,238ドメインを採点しました。

分析では、ドメインをアナリティクス深度、プラットフォーム、カテゴリ、スクリプト負荷、サードパーティドメイン負荷、スタック構成でグループ化しています。スクリプト数とサードパーティドメイン数は、フロントエンド依存負荷の公開上の代理指標として使われています。

ツールカテゴリには、トラッキング、可観測性、リテンション、顧客体験、決済、同意管理シグナルが含まれます。相関は、数値化されたスタックおよび負荷項目全体で計算されています。

注意事項

1. スクリプト数は代理指標であり、完全なパフォーマンススコアではありません。 実際のCore Web Vitals、メインスレッドのブロック、ネットワークタイミング、ユーザー体験を直接測るものではありません。

2. スクリプト数が多いことは、必ずしも悪ではありません。 複雑なブランドには複雑なインフラが必要なことがあります。問題は、未管理の複雑性です。

3. ツール検出は下限値です。 一部のスクリプトは、同意後、タグマネージャー経由、あるいはクライアントサイドレンダリング経由で動的に読み込まれます。

4. 同意管理の検出は法的分析ではありません。 9.6%という数値は、取得されたHTMLに見えるCookiebot / OneTrust系シグナルを反映しているだけで、全体的な準拠率ではありません。

5. サンプルはDTC全体の国勢調査ではありません。 Eコマースツールエコシステムと公開DTCリストで見えるブランドに偏っています。

6. カテゴリラベルは方向性を示すものです。 パターン分析には有用ですが、厳密な分類体系ではありません。

再現性メモ

納品フォルダには次のファイルが含まれます。

• analyze_growth_stack_cost.py — ストアフロントのスタック負荷、アナリティクス深度、スクリプト数、サードパーティドメイン数、同意管理の可視性、関連ガバナンス指標を採点するために使った分析スクリプト。
• growth_stack_cost_scores.csv — ドメインレベルの成長スタックコストスコアと負荷指標。
• by_analytics_depth.csv — アナリティクス深度ごとにまとめたスクリプト負荷とサードパーティドメイン負荷。
• by_platform_stack_cost.csv — プラットフォームレベルのスタック負荷比較。
• by_category_stack_cost.csv — カテゴリレベルのスタック負荷比較。
• stack_cost_correlations.csv — スタック項目と負荷項目にまたがる数値相関マトリクス。
• highest_script_burden_domains.csv — 編集レビューと手動検証のための、スクリプト負荷が最も高いドメイン。
• summary.json — 本レポートで引用した主要集計値。中央値のスクリプト数、中央値のサードパーティドメイン数、アナリティクス深度比較、同意管理の可視性、極端なスクリプト負荷の割合を含みます。

方法論の修正、データセットの問題、追加分析は support@thunderbit.com まで歓迎します。本レポートは、Thunderbitが持ついかなる商業的立場とも独立して公開されています。私たちはAI搭載のウェブスクレイパーを開発しており、公開ECサイトが、運用者、研究者、検索エンジン、AIエージェントにとって、そこで何が動いているかを把握できる程度には検査可能であり続けることに構造的な利害があります。本ベンチマークは、2026年5月11日に収集された公開ウェブサイトシグナルに基づく1,238件の採点済みDTCドメインに基づいています。本レポートのデータはそれ自体で成立します。— Thunderbitリサーチチーム、2026年5月。