報告｜DTC 成長堆疊的隱藏成本

讀者定位

這份報告是寫給那些必須承擔現代 DTC 技術堆疊後果的人：成長主管、電商經理、效益型行銷人員、生命週期團隊、行銷營運、技術 SEO 團隊、前端工程師、分析負責人，以及那些一直在問「明明每個工具看起來都很有必要，為什麼網站還是這麼慢？」的創辦人。

最初的 DTC 網站基準研究，回答的是品牌到底用了哪些工具。這次研究則進一步追問：把這些工具堆在門面上，真正的營運成本是什麼？

答案不是「工具不好」。DTC 品牌之所以會用分析、留存、歸因、評論、聊天、客服、付款、加購與實驗工具，是因為這些工具確實能解決營收問題。問題在於，每多加一層，就會多出前端成本、QA 成本、同意管理成本、資料品質成本，以及維護成本。成長堆疊能帶來成長能力，但也會讓基礎架構承受更多拖累。

對 SEO 與電商內容撰寫者來說，這份報告比單純說「DTC 品牌用了很多工具」更有用。更有力的敘事是：預設的 DTC 成長打法，現在已經變成效能與治理問題。

執行摘要

在 1,238 個有評分的 DTC 網域中，本樣本首頁的中位數包含 52 個 script 標籤，並引用 8 個第三方網域。這不是抽象的技術細節。Script 與第三方網域，正是瀏覽器端可見的品牌成長堆疊證據：分析、像素、留存工具、聊天、評論、個人化、付款、加購、實驗、同意與客服。

當品牌依分析與行銷深度分組後，成本差異就很明顯：

差距非常明顯。把前兩組合併來看，0-2 個分析工具品牌的 script 中位數是 16，第三方網域中位數是 4。而 5 個以上分析工具的品牌，script 中位數達到 69，第三方網域中位數達到 11。換句話說，較重的成長堆疊，其 script 負擔是低分析組的四倍以上。

相關性資料也支持同樣的結論。堆疊深度與 script 數量的相關係數是 0.731，與第三方網域數量的相關係數是 0.547。分析工具數量與 script 數量的相關係數是 0.658，與第三方網域數量的相關係數是 0.557。留存工具數量與 script 數量也有明顯相關性，達 0.611。這不只是少數離群值，而是一種結構性模式：隨著公開可見的成長堆疊擴張，瀏覽器端複雜度也會上升。

這份報告也揭露出隱私與治理的落差。這裡以 Cookiebot / OneTrust 類型的可見訊號來衡量同意管理，結果只有 9.6% 的有評分網域出現這類訊號。在擁有 5 個以上分析工具的品牌中，同意管理器覆蓋率是 14.0%。這並不代表其他品牌就一定不合規，因為同意工具可能以本偵測無法捕捉的方式實作。但它確實顯示，許多追蹤密集的網站，並沒有在抓取到的 HTML 中呈現明顯的同意管理訊號。

最後，16.2% 的網域落在 extreme 的 script 負擔層級，定義為超過 75 個 script 標籤。這對技術 SEO、成長營運與前端團隊來說，是很實用的基準。若一個 DTC 首頁超過 75 個 script，它就不再只是行銷頁面，而是需要明確歸屬與治理的基礎架構表面。

核心結論是：DTC 的成長成熟度與門面複雜度是同步上升的。下一個優勢，不是再加更多工具，而是治理你已經擁有的堆疊。

最值得分享的發現

1. 本樣本中的 DTC 首頁中位數有 52 個 script 標籤與 8 個第三方網域。

2. 擁有 5 個以上分析工具的品牌，中位數有 69 個 script 與 11 個第三方網域。

3. 擁有 0-2 個分析工具的品牌，中位數只有 16 個 script 與 4 個第三方網域。

4. 16.2% 的有評分網域落在極端 script 負擔層級。

5. 整體同意管理可見度只有 9.6%，即使在擁有 5 個以上分析工具的品牌中也只有 14.0%。

6. 堆疊深度與 script 數量的相關性高達 0.731。

7. DTC 成長堆疊早已不只是行銷堆疊，而是前端基礎架構。

1. 為什麼成長堆疊成本很重要

DTC 團隊通常會從預期收益來評估工具：更好的歸因、更多 Email 營收、更高的 AOV、更好的客服、更乾淨的評論、更強的個人化、提升留存、更好的付費媒體優化，或更高的轉換率。這很合理，因為成長團隊的責任就是成長。

但每一個工具也都會產生成本。有些成本很明顯：訂閱費、導入工作、合約管理。另一些成本則更難看見：頁面更慢、JavaScript 更多、第三方呼叫更多、QA 狀態更多、同意邏輯更多、標籤衝突更多、歸因差異更多、隱私審查更多，以及供應商歸屬問題更多。

這份報告聚焦的，就是這些隱藏成本。它用 script 數量、第三方網域數量、堆疊深度、工具類別、平台分組與類別分組，作為複雜度的代理指標。它並不是在說 script 數量高就一定不好。高表現品牌可能合理地承載更多 script，因為每一個都支援營收功能。但沒有治理的高複雜度很危險。

正確的問題不是「要怎麼移除所有工具？」而是：哪些工具現在還值得留在頁面上？

2. 基準線：52 個 Script 與 8 個第三方網域

本樣本首頁的中位數有：

• 52 個 script 標籤
• 8 個第三方網域

底層效能研究中的 p75 值更高：69 個 script 與 12 個第三方網域。最大 script 數量高得多，但這份報告重點在分布，而不是拿離群值當負面案例。

對營運者來說，中位數已經足以說明問題。DTC 首頁很少只是 HTML、CSS、產品圖片與結帳路徑，它更像是多套系統的協調層：分析、像素、標籤管理、工作階段錄製、評論、客服、測驗、彈窗、訂閱、個人化、付款、同意與實驗。

隱藏成本會出現在幾個地方：

效能成本。 更多 script 可能拖慢渲染、搶占主執行緒時間、增加網路請求，並影響 Core Web Vitals。

QA 成本。 每個供應商 script 都會增加要測試的狀態：桌機、手機、已接受同意、已拒絕同意、已登入、未登入、購物車狀態、結帳路徑、區域網域，以及不同瀏覽器。

歸因成本。 更多標籤不一定帶來更好的資料，反而可能造成數字衝突、重複事件，或通路功勞爭議。

隱私成本。 更多追蹤表面，會帶來更多同意與合規問題。

歸屬成本。 工具常常比安裝它的人活得更久。某個 script 可能在團隊早已不再使用儀表板後，仍然留在網站上。

這就是為什麼成長堆疊應該像基礎架構一樣管理，而不是像一堆行銷附加元件。

3. 分析深度是最清楚的成本驅動因子

這份研究中最有力的表格，是分析深度的拆解：

這張表把模糊的擔憂，轉化成具體的基準。從 1-2 個分析工具增加到 3-4 個時，script 中位數幾乎翻倍，從 30 增加到 54。增加到 5 個以上時，中位數再升到 69。

0 工具組不該被解讀為比較好。這些網站中有些可能是不完整、停放中、非常簡單、嚴重依賴前端渲染，或偵測不足。真正有參考價值的比較，是主流營運組別：1-2、3-4，以及 5 個以上分析工具。

5 個以上分析工具的群組尤其重要。這些品牌最重視量測與成長營運，通常也最在意付費獲取、留存、歸因、使用者行為、客服、評論或轉換優化。但他們同時也背負最重的依賴負擔。

這就是成長堆疊的悖論：最重視量測的品牌，也最容易承受量測開銷。

4. 相關性：這是結構性問題，不是偶發現象

相關矩陣顯示，堆疊複雜度並不是隨機的。

堆疊深度與 script 數量的關聯最強。這並不意外，但很重要，因為堆疊深度常被視為進步：工具越多，能力越多。但同時也代表前端負擔越重。

付款與 script 數量之間有令人意外地強的相關性，達 0.689。這並不代表付款方式不好，而是說付款選項與付款整合，本身就是複雜度的一部分。支援多種付款路徑的品牌，尤其在高 AOV 類別中，確實可能提升轉換；但這些整合仍應納入技術治理地圖。

留存工具與 script 數量的相關性是 0.611。這很直觀。生命週期工具常常會帶來站內表單、彈窗、識別 script、簡訊蒐集、個人化與事件收集。留存不只存在於 Email，也存在於門面上。

治理上的啟示很明確：效能不能只靠工程解決。行銷、生命週期、留存、付費媒體、分析與電商都會把程式碼放到頁面上，大家都必須參與效能治理。

5. 平台模式：Shopify 網站的可見堆疊更重

平台層級的比較需要謹慎解讀，因為這個樣本偏向電商工具生態，而且 Shopify 比例偏高。不過，平台表仍然是很有用的公開訊號基準。

樣本中的 Shopify 網站，script 中位數是 64、第三方網域中位數是 9、平均堆疊深度是 6.3。這不應被解讀為「Shopify 會造成 script」。更合理的理解是：本樣本中的 Shopify 品牌，通常高度依賴應用程式生態、結帳整合、生命週期工具、評論工具、客服工具與成長供應商。

Unknown 群組的 script 中位數是 6、第三方網域中位數是 2，但這不一定代表它們在策略上比較精簡。許多未知平台網站可能會隱藏平台特徵、採用 headless 架構、偵測不足，或暴露較少伺服器端渲染標記。正確的解讀是公開可見性，而不是完整內部堆疊。

平台表最適合拿來做內部基準比較。如果某個 Shopify DTC 網站有 90 個 script，那它就高於本樣本中的 Shopify 中位數；如果只有 40 個，就低於中位數。重點不是羞辱高 script 網站，而是建立可供審視的基準。

6. 類別模式：美妝、食品、服飾與保健帶有較重堆疊

類別表顯示，高成長的 DTC 類別通常伴隨較高的 script 負擔。

美妝與保養、食品與飲料、服飾與鞋類，以及健康與保健，script 中位數都接近或高於整體中位數。這些類別競爭激烈、內容量大，而且常常以生命週期經營為核心。它們依賴教育內容、評論、付費獲取、創作者發現、訂閱、會員制度、測驗與個人化，因此自然更傾向使用更多工具。

食品與飲料特別有趣，因為它有很高的 script 中位數，但同意管理器可見度卻相對較低，只有 5.9%。這並不證明有合規缺口，但對於追蹤密集的食品或飲料網站，尤其是經營國際市場者，確實提出了一個治理問題。

服飾與鞋類在圖中主要類別裡擁有最高的同意管理器覆蓋率，達 16.1%。美妝與保養也很接近，為 15.3%。這些類別可能具有更高的國際曝光度、更成熟的付費媒體操作，或更成熟的電商堆疊。

類別上的啟示不是某一類「比較差」，而是效能治理應該具有類別意識。擁有評論、測驗、訂閱、簡訊蒐集與歸因的美妝品牌，外觀上自然會和低複雜度目錄型網站不同。基準應該用來指引優先順序，而不是建立單一萬用目標。

7. 同意管理：追蹤與治理之間的落差

整體而言，有評分網域中只有 9.6% 出現同意管理。即使在擁有 5 個以上分析工具的品牌中，也只有 14.0%。

這是最重要的發現之一，因為它把成長儀表化與隱私治理連了起來。堆疊越重，同意邏輯就越重要，但可見的 Cookiebot / OneTrust 類型訊號仍然相對少見。

這個數字有其限制。品牌可能使用本偵測未涵蓋的同意管理器，也可能透過自訂方案實作同意，或動態載入同意 script，或主要在隱私要求不同的市場營運。所以這個數字不應被引用為「只有 9.6% 符合隱私法」。那樣說太強，也很可能不正確。

更精準的引用方式是：只有 9.6% 的有評分網域，在抓取到的 HTML 中呈現 Cookiebot / OneTrust 類型的同意管理訊號。 這依然很有價值，因為它表示許多追蹤密集的商店，並沒有在公開抓取中明顯呈現同意治理。

對營運者來說，行動很簡單：不要等到法務稽核才整理追蹤清單。建立一份標籤地圖，內容包含用途、負責人、供應商、收集的資料、同意類別與載入條件。成長團隊應該知道哪些標籤會在同意前觸發、哪些會在同意後觸發，以及會出現在那些頁面上。

8. 極端 Script 層級：當行銷頁面變成基礎架構

這項研究將 extreme script 負擔層級定義為超過 75 個 script 標籤。依此定義，16.2% 的有評分網域落入極端層級。

極端不代表一定錯。有些品牌確實有複雜需求：多區域路由、大量評論基礎設施、豐富的產品教育、個人化、多個廣告網路、分析、客服、實驗與結帳整合。複雜品牌合理地可能需要複雜頁面。

但極端狀態應該觸發治理。一旦超過 75 個 script，首頁就不再只是單純的行銷資產，而是基礎架構。它需要：

• Script 負責人清單
• 標籤載入政策
• 同意類別對照
• 效能監控
• 定期供應商清理
• 購物車與結帳 QA 路徑
• 事件去重規則
• 供應商異常時的回滾計畫

最危險的 script 不是最重的那一個，而是被遺棄的那一個：某段供應商程式碼沒有人再負責，卻仍在餵一個沒人打開的儀表板，還在拖慢一個沒人稽核的頁面。

9. 營運者手冊：如何治理成長堆疊

對這份報告的實際回應，不是全面刪工具，而是建立治理流程。

步驟 1：盤點所有 script。 匯出首頁、產品頁、集合頁、購物車與結帳相關頁面的所有 script 來源，若可能也包含內嵌 script。

步驟 2：指派負責人。 每個 script 都需要業務負責人與技術負責人。如果沒人能說出負責人是誰，這個 script 就是候選移除對象。

步驟 3：分類用途。 獲客、留存、歸因、評論、客戶支援、付款、個人化、實驗、同意、分析、監控或歷史遺留。

步驟 4：對照同意行為。 決定每個 script 是必要、分析、行銷、個人化還是客服類，並確認它何時觸發。

步驟 5：檢查實際使用情況。 儀表板還有在用嗎？供應商合約還存在嗎？報表還有人看嗎？這工具真的有影響決策嗎？

步驟 6：量測影響。 在可行的情況下，測試有無重型供應商時的頁面效能，追蹤 Core Web Vitals、互動延遲與主執行緒阻塞。

步驟 7：整合。 如果兩個工具做的是同一件事，就選一個。重複的歸因與分析工具，往往只會製造更多爭論，而不是更多清晰度。

步驟 8：每季審查。 成長堆疊應該像廣告帳戶與 Email 流程一樣，有定期清理週期。

這套流程把效能問題，從工程抱怨轉化為營運紀律。

10. SEO 與內容團隊可以怎麼引用

這份研究提供了幾個很強的內容角度：

「DTC 首頁中位數有 52 個 script。」 這是最廣泛的效能切角。

「分析堆疊越重，頁面也越重。」 擁有 5 個以上分析工具的品牌，中位數有 69 個 script；而 0-2 個分析工具的品牌只有 16 個。

「成長成熟度會創造效能債。」 最投入量測與生命週期基礎架構的品牌，背負著更多前端依賴。

「同意可見度落後於追蹤深度。」 即使在 5 個以上分析工具的網站中，可見的同意管理器覆蓋率也只有 14.0%。

「DTC 效能不再只是開發者的事。」 行銷、生命週期、付費媒體、客服與分析，大家都會把程式碼放到頁面上。

但有一個重要提醒：不要把 script 數量當成效能不佳的證明。它應該被用來作為依賴負擔與治理需求的代理指標。

11. 不同團隊應該如何閱讀這份報告

成長堆疊的隱藏成本是跨部門的，這也是它難解的原因。每個團隊看到的都是問題的一部分。

成長團隊看到的是營收上行空間。他們想要更好的歸因、更精準的受眾、更強的再行銷、更清楚的活動回饋、更好的落地頁測試，以及更多生命週期蒐集。從他們的角度看，為了更可衡量的營收，多加一個 script 往往是小代價。

前端團隊看到的是依賴成本。他們要處理較慢的頁面、版面位移、瀏覽器錯誤、第三方當機、主執行緒阻塞、hydration 問題，以及由他們未必擁有的 script 所導致的 QA 失敗。從他們的角度看，行銷標籤常常像未受管控的正式環境依賴。

SEO 團隊看到的是排名與抓取成本。他們在意 Core Web Vitals、可渲染性、結構化資料、抓取效率與使用者體驗。如果網站變慢或變脆弱，即使新增供應商的初衷是為了付費成長或留存，SEO 表現也可能受損。

資料團隊看到的是量測成本。工具越多，事件重複的可能性越高、儀表板間的差異越大、UTM 越容易出問題、通路功勞爭議越多，也越不確定究竟該用哪些數字來指引決策。

法務與隱私團隊看到的是同意成本。追蹤越多，供應商審查、資料處理問題、同意類別、區域行為與風險管理就越複雜。

高層看到的是預算與責任成本。每個工具都有訂閱費，但更大的成本可能是花在資料對齊、整合維護與修復網站問題上的時間。

這份報告最重要的管理啟示是：沒有任何單一團隊會自動擁有全部問題。因此成長堆疊需要共享的營運模型。一個實用版本，是每季召開一次「stack council」，由成長、生命週期、電商、SEO、工程、分析與隱私共同參與。議程應該很簡單：新增了什麼、移除了什麼、哪些還在用、哪些在拖慢網站、哪些在法律上敏感、以及哪些真的創造了可衡量的價值？

這聽起來有點官僚，但替代方案更糟：多年來由不同團隊安裝的供應商程式片段，沒有共同地圖，也沒有清理週期。

12. 堆疊審查範本

DTC 團隊可以用一個簡單表格，把這份研究轉成每季審查。每一列代表一個工具或一段 script。

供應商或 script 名稱。 它是什麼？

業務負責人。 是誰提出需求，又是誰仍在使用？

技術負責人。 誰可以安全地移除或修改它？

用途。 獲客、留存、歸因、客服、評論、個人化、付款、實驗、同意、監控或歷史遺留。

載入頁面。 首頁、產品頁、集合頁、購物車、結帳、部落格、落地頁，或全站。

同意類別。 必要、分析、行銷、個人化、客服，或未知。

上次審查時間。 團隊上次確認這工具是否仍有價值，是什麼時候？

決策依據。 哪個指標或工作流程依賴它？

效能影響。 它是否實質影響 script 數量、第三方請求、主執行緒工作，或 Core Web Vitals？

保留、延後、整合或移除。 最後決策是什麼？

這個範本不需要很複雜的工程平台，從試算表開始就可以。重點不是格式，而是責任歸屬。一旦某個工具有負責人與用途，團隊就能做理性的取捨。沒有這張地圖，任何效能討論都會變成政治問題。

最好的結果不是 script 數量最低，而是有意圖的堆疊：更少被遺棄的供應商、更乾淨的同意行為、更少重複標籤、更可靠的分析，以及真正重要工具的更好效能。

13. 最小可行治理標準

對於暫時無法立即召開完整季度 stack council 的團隊，可以先從三條規則開始。

第一，任何新的供應商 script，都必須先有負責人、用途與移除條件。移除條件很重要，因為很多 script 是為了活動、測試、遷移或短期上線而安裝，之後卻默默變成永久存在。

第二，任何分析或行銷標籤在上線前，都應先標明同意類別。這不代表行銷團隊要做到法律層面的完美，但至少需要一條有文件記錄的隱私審查流程。

第三，團隊應維護一份活躍門面供應商的唯一真相來源。如果唯一能知道網站跑了什麼的方法，是在事故發生時去檢查頁面原始碼，那代表堆疊早就失去管理。

這三條規則不會解決所有效能問題，但它們能防止最常見的失敗模式：成長堆疊持續擴張，卻沒有記憶。

方法論

這項研究使用的是在 2026 年 5 月 11 日 收集的 DTC 雙報告資料集。它透過 master.csv、perf_metrics.csv 與 categories.csv 對 1,238 個網域進行評分。

分析將網域依分析深度、平台、類別、script 負擔、第三方網域負擔與堆疊組成進行分組。Script 數量與第三方網域數量被用作前端依賴負擔的公開代理指標。

工具類別包括追蹤、可觀測性、留存、客戶體驗、付款與同意管理訊號。相關係數則在各種數值型堆疊與負擔欄位之間計算。

注意事項

1. Script 數量是代理指標，不是完整效能分數。 它無法直接衡量實際的 Core Web Vitals、主執行緒阻塞、網路時序或使用者體驗。

2. Script 多不一定不好。 複雜品牌可能需要複雜基礎架構。問題在於未經治理的複雜度。

3. 工具偵測只是一個下限。 有些 script 會動態載入、在同意後才載入、透過標籤管理器載入，或透過前端渲染載入。

4. 同意管理器偵測不是法律分析。 9.6% 這個數字反映的是抓取到的 HTML 中可見的 Cookiebot / OneTrust 類型訊號，而不是總體合規率。

5. 樣本不是完整的 DTC 普查。 它偏向於電商工具生態與公開 DTC 名單中可見的品牌。

6. 類別標籤僅具方向性。 它們適合用來做模式分析，但不是精確分類學。

可重現性說明

交付資料夾包含：

• analyze_growth_stack_cost.py — 用來評分門面堆疊負擔、分析深度、script 數量、第三方網域數量、同意管理器可見度與相關治理訊號的分析腳本。
• growth_stack_cost_scores.csv — 網域層級的成長堆疊成本分數與負擔指標。
• by_analytics_depth.csv — 依分析工具深度分組的 script 與第三方網域負擔。
• by_platform_stack_cost.csv — 平台層級的堆疊負擔比較。
• by_category_stack_cost.csv — 類別層級的堆疊負擔比較。
• stack_cost_correlations.csv — 各種堆疊與負擔欄位之間的數值相關矩陣。
• highest_script_burden_domains.csv — 供編輯審查與人工驗證的最高 script 負擔網域。
• summary.json — 本報告引用的重點彙總指標，包括 script 中位數、第三方網域中位數、分析深度比較、同意管理器可見度，以及極端 script 負擔占比。

歡迎針對方法論修正、資料集問題與後續分析來信至 support@thunderbit.com。本報告的發布，與 Thunderbit 任何商業立場無關；我們打造的是 AI 驅動的網頁爬蟲，而我們在結構上也確實希望公開電商網站能維持足夠可檢視性，讓營運者、研究人員、搜尋引擎與 AI 代理理解其運作內容。這項基準建立於 2026 年 5 月 11 日從公開網站訊號中收集的 1,238 個有評分 DTC 網域。報告中的資料本身即具有獨立性。—— Thunderbit 研究團隊，2026 年 5 月。