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

読者の位置づけ

このレポートは、現代のDTCスタックがもたらす成果と運用負荷の両方に日々向き合う方を対象にしています。具体的には、グロース責任者、Eコマースマネージャー、パフォーマンスマーケター、ライフサイクルチーム、マーケティングオペレーション、テクニカルSEO、フロントエンドエンジニア、アナリティクス担当者です。また、必要なツールをひととおり導入したにもかかわらず、サイト速度が低下した原因を整理したい創業者にも役立ちます。

以前のDTCサイトベンチマークでは、各ブランドがどのツールを使っているかを示しました。今回は、その先にある運用コストに焦点を当てます。具体的には、そうしたツールをストアフロントに積み上げることで、どのような負荷が生じるかを検証します。

ここでの結論は「ツールは悪だ」というものではありません。DTCブランドがアナリティクス、リテンション、アトリビューション、レビュー、チャット、サポート、決済、アップセル、実験系のツールを使うのは、それらが実際の売上課題を解いてくれるからです。一方、レイヤーが1つ増えるたびに、フロントエンド、QA、同意管理、データ品質、保守にかかるコストも積み上がります。成長スタックは事業機会を広げる一方で、インフラの負荷を重くする場合があります。

SEOやECコンテンツを担当する方にとっても、本レポートの論点は、単に「DTCブランドは多くのツールを使っている」という事実にとどまりません。DTCで一般化した成長施策が、パフォーマンスとガバナンスの管理課題になっている点を、データに基づいて整理します。

エグゼクティブサマリー

採点済みの1,238件のDTCドメインを横断すると、このサンプルのホームページ中央値にはスクリプトタグが52個、サードパーティドメインが8つ含まれていました。これらは単なる技術指標ではなく、ブラウザーから観測できるブランドの成長スタックを構成する要素です。アナリティクス、ピクセル、リテンション、チャット、レビュー、パーソナライゼーション、決済、アップセル、実験、同意、サポートなどが含まれます。

ブランドをアナリティクスとマーケティングの深さで分けると、グループ間の負荷の違いが見えてきます。

アナリティクス深度の区分	サンプル数	スクリプト中央値	サードパーティドメイン中央値	平均スタック深度	同意管理カバレッジ
アナリティクスツール0個	157	1	0	0.0	0.0%
アナリティクスツール1〜2個	336	30	6	2.2	3.6%
アナリティクスツール3〜4個	352	54	8	4.9	14.8%
アナリティクスツール5個以上	393	69	11	8.2	14.0%

アナリティクスツール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. 取得したHTML上で観測できた同意管理シグナルは全体で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サイトの依存関係の多さが分かります。現在のDTCホームページは、HTML、CSS、商品画像、チェックアウト導線だけで構成されるとは限りません。多くの場合、アナリティクス、ピクセル、タグマネジメント、セッション録画、レビュー、サポート、診断コンテンツ、ポップアップ、サブスクリプション、パーソナライゼーション、決済、同意、実験などを接続するレイヤーとして機能します。

見えにくいコストは、主に次の領域で発生します。

パフォーマンスコスト。 スクリプトが増えると、実装や読み込み条件によっては、描画遅延、メインスレッドの競合、ネットワークリクエストの増加につながり、Core Web Vitalsへ影響する可能性があります。

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

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

プライバシーコスト。 トラッキングの接点が増えるほど、同意設計やコンプライアンス上の検討事項も増えます。

所有コスト。 導入した担当者が異動した後も、利用されなくなったツールのスクリプトだけがサイトに残る場合があります。

このため、成長スタックはマーケティングツールの集合ではなく、所有者と運用ルールを持つインフラとして管理することが重要です。

3. アナリティクス深度とスクリプト負荷の関係

今回の調査では、アナリティクス深度別の内訳から、ツール数とフロントエンド負荷の関係を確認できます。

アナリティクス深度の区分	サンプル数	スクリプト中央値	平均スクリプト数	サードパーティドメイン中央値	平均サードパーティドメイン数	平均スタック深度
アナリティクスツール0個	157	1	3.1	0	1.3	0.0
アナリティクスツール1〜2個	336	30	35.0	6	6.5	2.2
アナリティクスツール3〜4個	352	54	51.1	8	9.1	4.9
アナリティクスツール5個以上	393	69	69.1	11	11.3	8.2

この表は、アナリティクスツールが多いグループほど、観測されたスクリプト負荷も高いことを示しています。アナリティクスツールが1〜2個のグループから3〜4個のグループになると、スクリプト中央値は30から54へ増えます。5個以上のグループでは、中央値は69です。

ただし、0個のグループを「より優れている」と評価することはできません。このグループには、計測環境が未整備または待機中のサイト、構成が単純なサイト、クライアントレンダリング中心のサイト、検出漏れの可能性があるサイトが含まれます。運用実態を比較する際は、1〜2個、3〜4個、5個以上のグループを中心に見るほうが適切です。

5個以上のグループには、広告獲得、リテンション、アトリビューション、セッション行動、サポート、レビュー、CVR最適化など、複数の計測・運用目的を持つブランドが含まれます。その結果として、ブラウザー側で観測される依存関係も多くなっています。

つまり、計測環境を充実させる際は、得られるデータだけでなく、追加されるスクリプト、保守範囲、同意設計も同時に評価する必要があります。

4. スタック規模とフロントエンド負荷の相関

相関マトリクスから、スタックの各項目とフロントエンド負荷指標の関連を確認できます。

組み合わせ	相関係数
スタック深度とスクリプト数	0.731
アナリティクスツール数とスクリプト数	0.658
決済ツール数とスクリプト数	0.689
リテンションツール数とスクリプト数	0.611
スタック深度とサードパーティドメイン数	0.547
アナリティクスツール数とサードパーティドメイン数	0.557
スクリプト数とサードパーティドメイン数	0.562

スクリプト数との相関が最も高い項目はスタック深度で、相関係数は0.731です。ツールが増えれば提供できる機能も増える一方、フロントエンドで管理する依存関係も増える傾向があります。ただし、この相関マトリクスだけで、個々のツールが負荷増加の直接原因であると断定することはできません。

決済ツール数とスクリプト数の相関係数は0.689でした。これは決済手段の良否を示すものではなく、複数の決済導線や連携もストアフロントの複雑性を構成する要素であることを示します。特にAOVの高いカテゴリでは、複数決済への対応がCVR改善につながる場合もあります。その場合も、各連携を技術ガバナンスの対象に含める必要があります。

リテンションツール数とスクリプト数の相関係数は0.611です。ライフサイクル系ツールでは、オンサイトフォーム、ポップアップ、識別スクリプト、SMS取得、パーソナライゼーション、イベント収集などがストアフロントに追加される場合があります。リテンション施策は、メール配信だけでなく、サイト上の実装とも関係します。

この結果は、パフォーマンス管理をエンジニアリング部門だけに限定できないことを示しています。マーケティング、ライフサイクル、リテンション、広告、アナリティクス、Eコマースの各チームがページ上のコードに関与するため、導入判断と定期レビューを共同で行う運用が必要です。

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

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

プラットフォーム	サンプル数	スクリプト中央値	サードパーティドメイン中央値	平均スタック深度	同意管理カバレッジ
Shopify	783	64	9	6.3	11.1%
不明	324	6	2	1.2	7.1%
WordPress	23	24	6	2.3	13.0%
Salesforce Commerce Cloud	10	47	10	3.9	30.0%
Magento / Adobe Commerce	6	55.5	7.5	3.8	0.0%
BigCommerce	3	55	9	3.7	0.0%

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

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

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

6. カテゴリ別に見たスタック負荷

カテゴリ別の集計では、一部の主要DTCカテゴリで、全体中央値に近いか、それを上回るスクリプト負荷が観測されました。

カテゴリ	サンプル数	スクリプト中央値	サードパーティドメイン中央値	平均スタック深度	同意管理カバレッジ
美容・スキンケア	98	62	10.5	6.0	15.3%
食品・飲料	118	62	9	5.3	5.9%
アパレル・フットウェア	149	61	8	5.7	16.1%
ヘルス・ウェルネス	58	58	9	5.8	10.3%
ホーム・家具	48	58.5	9	5.4	8.3%
アウトドア・スポーツ	49	57	8	5.3	14.3%
ベビー・キッズ	27	57	9	4.7	7.4%

美容・スキンケア、食品・飲料、アパレル・フットウェア、ヘルス・ウェルネスは、いずれも全体中央値に近いか、それを上回るスクリプト数を示しました。これらのカテゴリでは、教育コンテンツ、レビュー、広告獲得、クリエイター発見、サブスクリプション、ロイヤルティ、診断、パーソナライゼーションなど、複数の施策を組み合わせる場合があります。こうした運用構成が、ツール数や依存関係の増加と関連している可能性があります。

食品・飲料は、スクリプト中央値が高い一方、同意管理の可視性が**5.9%**と比較的低い結果でした。これはコンプライアンス上の問題を証明するものではありません。ただし、特に国際展開するブランドでは、トラッキング構成と同意管理をあわせて点検する際の参考値になります。

アパレル・フットウェアは、主要カテゴリの中で最も高い同意管理カバレッジ**16.1%を示しました。美容・スキンケアも15.3%**です。背景には、海外展開の範囲、広告運用、Eコマーススタックの成熟度などが関係している可能性がありますが、本調査の集計だけでは要因を特定できません。

カテゴリ別ベンチマークは、カテゴリの優劣を評価するためのものではありません。レビュー、診断、サブスクリプション、SMS取得、アトリビューションなど、自社が実際に利用する機能を踏まえて、カテゴリごとにパフォーマンスガバナンスの基準を設計するために使います。ベンチマークは優先順位づけの指針であり、全カテゴリ共通の単一目標ではありません。

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

同意管理シグナルは、採点済みドメイン全体の**9.6%で観測されました。アナリティクスツール5個以上のブランドでは、出現率は14.0%**です。

この結果は、グロースの計測基盤とプライバシーガバナンスをあわせて検討する必要性を示しています。スタックが重くなるほど、分類すべきタグや同意後の読み込み条件も増える可能性があります。一方、Cookiebot / OneTrust系の可視シグナルは、本サンプルでは限定的でした。

ただし、この指標には明確な制約があります。ブランドが検出対象外の同意管理ツールを使っている可能性があります。独自ソリューションで同意を実装している場合や、同意スクリプトを動的に読み込んでいる場合もあります。また、異なるコンプライアンス要件を持つ市場を主な対象にしていることも考えられます。したがって、この数値を「9.6%しかプライバシー法に準拠していない」と解釈することはできません。

本調査から引用できる範囲は、次の記述です。採点済みドメインの9.6%だけが、取得されたHTML上でCookiebot / OneTrust系の同意管理シグナルを露出している。 これは、多くのトラッキング重視ストアで、公開クロールからは同意ガバナンスの実装を判定できないことを示します。

運用時は、法務監査の直前に整理するのではなく、目的、所有者、ベンダー、収集データ、同意カテゴリ、読み込み条件を記録したタグマップを維持することが重要です。各タグが同意前と同意後のどちらで発火するか、どのページで読み込まれるかを、グロース、エンジニアリング、プライバシーの各担当者が照合できる状態にします。

8. 75スクリプト超をガバナンス対象とする理由

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

この区分に入ること自体が、実装上の誤りを意味するわけではありません。マルチリージョン配信、レビュー基盤、豊富な商品説明、パーソナライゼーション、複数の広告ネットワーク、アナリティクス、サポート、実験、チェックアウト連携など、複雑な要件を持つブランドでは、必要なスクリプト数も増える場合があります。

一方、75個を超える状態は、定期的なガバナンスレビューを始める目安になります。ホームページを単純なマーケティング資産として扱うのではなく、依存関係を持つインフラとして、次の管理項目を整備します。

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

特にリスクが高いのは、所有者が不明なスニペットです。現在のチームで責任者が定まらず、利用されていないダッシュボードへデータを送り続け、ページ負荷にも影響している場合は、利用目的と削除可否を優先的に見直す必要があります。

9. 成長スタックを統治する8つのステップ

このレポートから導ける実務対応は、ツールを一律に削除することではなく、継続的なガバナンスのワークフローを整えることです。

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

ステップ2：所有権を割り当てる。 各スクリプトに事業オーナーと技術オーナーを設定します。担当者と現在の利用目的を特定できないスクリプトは、削除候補として扱います。

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

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

ステップ5：実際の利用状況を確かめる。 ダッシュボードの利用者、ベンダー契約の状態、レポートの参照状況、意思決定での利用実績を調べます。

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

ステップ7：重複を統合する。 同じ役割を持つツールが複数ある場合は、利用実績、データ品質、移行コストを比較し、統合できるか判断します。重複したアトリビューションやアナリティクスツールは、数値の不一致や運用負荷を増やす場合があります。

ステップ8：四半期ごとに見直す。 成長スタックにも、広告アカウントやメールフローと同じように、定期的な整理サイクルを設けます。

このワークフローにより、パフォーマンス上の課題を特定部門の不満として扱うのではなく、所有者、効果、負荷に基づく運用判断へつなげられます。

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

この調査には、パフォーマンス、計測、ガバナンスに関する複数のコンテンツ切り口があります。引用時は、調査対象が本サンプルに限られることと、スクリプト数が代理指標であることを併記する必要があります。

「本サンプルのDTCホームページでは、スクリプト数の中央値は52個です。」 全体傾向を紹介する際に使える基準値です。

「アナリティクスツールが多いグループほど、スクリプト負荷も高い傾向がある。」 アナリティクスツール5個以上のブランドはスクリプト中央値69個で、0〜2個のブランドの16個を大きく上回ります。

「計測やライフサイクル基盤の充実は、フロントエンドの依存関係増加と関連する。」 複数の成長施策を実装するブランドでは、管理対象となるスクリプトや連携も増える傾向があります。

「取得したHTML上の同意管理シグナルは、トラッキングの深さに比べて限定的だった。」 アナリティクスツール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の商業的立場とは独立した調査として公開しています。一方、ThunderbitはAI搭載のウェブスクレイパーを開発しており、公開ECサイトが、運用者、研究者、検索エンジン、AIエージェントにとって、そこで何が動いているかを把握できる程度に検査可能であることに、事業上の利害があります。この関係を明示したうえで、分析スクリプトとデータセットを公開し、集計の検証に利用できる形にしています。本ベンチマークは、2026年5月11日に収集された公開ウェブサイトシグナルに基づく1,238件の採点済みDTCドメインに基づいています。— Thunderbitリサーチチーム、2026年5月。

AIウェブスクレイピングでThunderbitを試す

AIウェブスクレイピングでThunderbitを試す Get Started Free