Report | Il costo nascosto del growth stack DTC

Posizionamento per il lettore

Questo report è pensato per chi vive ogni giorno le conseguenze di uno stack DTC moderno: responsabili growth, manager ecommerce, performance marketer, team lifecycle, marketing operations, team SEO tecnico, frontend engineer, responsabili analytics e founder che continuano a chiedersi perché il sito sembri lento, anche quando ogni strumento sembra indispensabile.

Il benchmark originale dei siti DTC mostrava quali strumenti usano i brand. Questa ricerca pone una domanda diversa: qual è il costo operativo di accumulare questi strumenti sullo storefront?

La risposta non è "gli strumenti sono cattivi". I brand DTC usano strumenti per analytics, retention, attribution, recensioni, chat, supporto, pagamenti, upsell e sperimentazione perché risolvono problemi reali di fatturato. Il punto è che ogni livello aggiuntivo comporta un costo sul frontend, un costo di QA, un costo di consenso, un costo sulla qualità dei dati e un costo di manutenzione. Gli stack growth creano capacità di crescita, ma creano anche attrito infrastrutturale.

Per i team SEO e per chi scrive contenuti ecommerce, questo report offre un’angolazione più utile di un semplice "i brand DTC usano molti strumenti". La storia più forte è questa: il playbook standard della crescita DTC è diventato un problema di performance e governance.

Executive Summary

Su 1.238 domini DTC con punteggio, la homepage mediana di questo campione contiene 52 tag script e fa riferimento a 8 domini di terze parti. Non si tratta di dettagli tecnici astratti. Gli script e i domini di terze parti sono la prova, lato browser, dello stack growth di un brand: analytics, pixel, strumenti di retention, chat, recensioni, personalizzazione, pagamenti, upsell, sperimentazione, consenso e supporto.

Il costo diventa evidente quando i brand vengono raggruppati per profondità di analytics e di marketing:

La differenza è netta. I brand con 0-2 strumenti analytics hanno una mediana di 16 script e 4 domini di terze parti se si combinano le prime due fasce. I brand con 5+ strumenti analytics hanno una mediana di 69 script e 11 domini di terze parti. In altre parole, lo stack growth più pesante comporta più di quattro volte il carico di script del gruppo con meno analytics.

I dati di correlazione confermano la stessa storia. La profondità dello stack ha una correlazione di 0,731 con il numero di script e una correlazione di 0,547 con i domini di terze parti. Il numero di strumenti analytics ha una correlazione di 0,658 con il numero di script e di 0,557 con i domini di terze parti. Anche il numero di strumenti di retention correla in modo significativo con il numero di script, a 0,611. Non si tratta di pochi casi isolati. È un pattern strutturale: con l’espansione dello stack di growth pubblico, aumenta anche la complessità lato browser.

Il report fa emergere anche una lacuna sul piano privacy e governance. La gestione del consenso, misurata qui attraverso segnali visibili in stile Cookiebot / OneTrust, compare solo nel 9,6% dei domini analizzati. Tra i brand con 5+ strumenti analytics, la copertura del gestore del consenso è del 14,0%. Questo non dimostra che gli altri brand siano non conformi, perché gli strumenti di consenso possono essere implementati in modi che questa rilevazione non intercetta. Ma mostra che molti siti con forte tracking non espongono un segnale evidente di gestione del consenso nell’HTML catturato.

Infine, il 16,2% dei domini rientra nella fascia extreme di carico script, definita qui come più di 75 tag script. È un benchmark utile per SEO tecnico, growth operations e team frontend. Se una homepage DTC ha più di 75 script, non è più solo una pagina marketing. È una superficie infrastrutturale che richiede ownership.

Conclusione centrale: la maturità della crescita DTC e la complessità dello storefront crescono insieme. Il prossimo vantaggio non è aggiungere altri strumenti. È governare lo stack che già esiste.

I risultati più condivisibili

1. La homepage DTC mediana in questo campione ha 52 tag script e 8 domini di terze parti.

2. I brand con 5+ strumenti analytics hanno una mediana di 69 script e 11 domini di terze parti.

3. I brand con 0-2 strumenti analytics hanno una mediana di 16 script e 4 domini di terze parti.

4. Il 16,2% dei domini analizzati rientra nella fascia estrema di carico script.

5. La visibilità della gestione del consenso è solo del 9,6% complessivamente e del 14,0% anche tra i brand con 5+ strumenti analytics.

6. La profondità dello stack è fortemente correlata al numero di script, con 0,731.

7. Lo stack growth DTC non è più solo uno stack di marketing. È infrastruttura frontend.

1. Perché il costo dello stack growth conta

I team DTC di solito valutano gli strumenti in base al vantaggio atteso: attributi migliori, più ricavi da email, AOV più alto, supporto migliore, recensioni più pulite, personalizzazione più forte, retention più efficace, ottimizzazione paid media migliore o più conversion lift. È ragionevole. I team growth sono pagati per far crescere il business.

Ma ogni strumento crea anche un costo. Alcuni costi sono visibili: fee di abbonamento, lavoro di implementazione e gestione dei contratti. Altri sono più difficili da vedere: pagine più lente, più JavaScript, più chiamate di terze parti, più stati da testare in QA, più logiche di consenso, più conflitti tra tag, più discrepanze di attribution, più revisione privacy e più domande su chi possieda un determinato vendor.

Questo report si concentra sul costo nascosto. Usa numero di script, numero di domini di terze parti, profondità dello stack, categorie di strumenti, gruppi di piattaforma e gruppi di categoria come proxy della complessità. Non sostiene che un numero alto di script sia sempre negativo. Un brand performante può avere ragionevolmente più script, perché ognuno supporta una funzione di revenue. Ma una complessità elevata senza governance è pericolosa.

La domanda giusta non è "come facciamo a rimuovere ogni strumento?". La domanda giusta è: quali strumenti si stanno ancora meritando il loro posto nella pagina?

2. Il baseline: 52 script e 8 domini di terze parti

La homepage mediana del campione ha:

• 52 tag script
• 8 domini di terze parti

I valori p75 della ricerca di performance sottostante sono più alti: 69 script e 12 domini di terze parti. Il numero massimo di script è molto più elevato, ma il report si concentra sulla distribuzione, non sugli outlier come esempi negativi.

Per chi gestisce l’operatività, la mediana basta già a chiarire il punto. Una homepage DTC raramente è solo HTML, CSS, immagini di prodotto e un percorso di checkout. È uno strato di coordinamento per molti sistemi: analytics, pixel, tag management, session recording, recensioni, supporto, quiz, popup, abbonamenti, personalizzazione, pagamenti, consenso ed esperimenti.

Il costo nascosto emerge in diversi punti:

Costo di performance. Più script possono ritardare il rendering, competere per il tempo del main thread, aumentare le richieste di rete e influenzare i Core Web Vitals.

Costo di QA. Ogni script di un vendor aggiunge stati da testare: desktop, mobile, consenso accettato, consenso rifiutato, accesso effettuato, accesso non effettuato, stato del carrello, percorso di checkout, dominio regionale e differenze tra browser.

Costo di attribution. Più tag non significano necessariamente dati migliori. Possono creare numeri in conflitto, eventi duplicati o disaccordi sull’attribuzione dei canali.

Costo privacy. Più superfici di tracking significano più domande su consenso e conformità.

Costo di ownership. Gli strumenti spesso sopravvivono alla persona che li ha installati. Uno script può restare sul sito molto tempo dopo che il team ha smesso di usare la dashboard.

Ecco perché lo stack growth va gestito come infrastruttura, non come un insieme di accessori marketing.

3. La profondità analytics è il driver di costo più chiaro

La tabella più forte della ricerca è il breakdown della profondità analytics:

Questa tabella trasforma una preoccupazione vaga in un benchmark concreto. Passare da 1-2 strumenti analytics a 3-4 quasi raddoppia il numero mediano di script, da 30 a 54. Passare a 5+ strumenti lo fa salire ancora, fino a 69.

Il gruppo con 0 strumenti non va interpretato come il migliore. Molti di questi siti possono essere incompleti, parcheggiati, molto semplici, pesantemente renderizzati lato client o sotto-rilevati. Il confronto utile è tra i gruppi operativi mainstream: 1-2, 3-4 e 5+ strumenti analytics.

Il gruppo con 5+ strumenti analytics è particolarmente importante. Sono i brand più impegnati nella misurazione e nelle operations di growth. È probabile che tengano molto ad acquisizione paid, retention, attribution, comportamento delle sessioni, supporto, recensioni o conversion optimization. Ma portano anche il carico di dipendenza più pesante.

Questo è il paradosso dello stack growth: i brand più seri sulla misurazione sono anche quelli più esposti all’overhead della misurazione.

4. Correlazioni: è un fenomeno strutturale, non aneddotico

La matrice di correlazione mostra che la complessità dello stack non è casuale.

La profondità dello stack ha il legame più forte con il numero di script. È prevedibile, ma conta perché la profondità dello stack è spesso vista come progresso. Più strumenti significano più capacità. Ma significano anche più peso frontend.

I pagamenti mostrano una correlazione sorprendentemente forte con il numero di script, pari a 0,689. Non significa che i metodi di pagamento siano negativi. Significa che la varietà di checkout e le integrazioni di pagamento fanno parte del quadro di complessità. Un brand che supporta più percorsi di pagamento può migliorare la conversion, soprattutto nelle categorie ad AOV elevato, ma queste integrazioni restano comunque parte della mappa di governance tecnica.

Il numero di strumenti di retention correla con il numero di script a 0,611. Ha perfettamente senso. Gli strumenti lifecycle spesso aggiungono form onsite, popup, script di identificazione, raccolta SMS, personalizzazione e raccolta eventi. La retention non vive solo nell’email. Vive sullo storefront.

La implicazione di governance è chiara: la performance non può essere risolta solo dall’ingegneria. Marketing, lifecycle, retention, paid media, analytics ed ecommerce inseriscono codice nella pagina. Tutti devono partecipare alla governance della performance.

5. Pattern di piattaforma: i siti Shopify portano uno stack visibile più pesante

I confronti a livello di piattaforma vanno interpretati con cautela perché il campione è sbilanciato verso gli ecosistemi di strumenti ecommerce, e Shopify è sovrarappresentato. Detto questo, la tabella per piattaforma è utile come benchmark di segnale pubblico.

I siti Shopify nel campione hanno una mediana di 64 script e 9 domini di terze parti, con una profondità media dello stack di 6,3. Non va letto come "Shopify causa gli script". Un’interpretazione più plausibile è che i brand Shopify di questo campione siano molto esposti a ecosistemi di app, integrazioni di checkout, strumenti di lifecycle, recensioni, supporto e vendor growth.

Il gruppo Unknown ha una mediana di 6 script e 2 domini di terze parti, ma ciò non significa necessariamente che quei siti siano più snelli in senso strategico. Molti siti con piattaforma sconosciuta possono nascondere i fingerprint della piattaforma, essere headless, essere sotto-rilevati o esporre meno markup renderizzato lato server. La lettura corretta riguarda la visibilità pubblica, non lo stack interno completo.

La tabella delle piattaforme è soprattutto utile per il benchmark interno. Se un sito DTC su Shopify ha 90 script, è sopra la mediana Shopify di questo campione. Se ne ha 40, è sotto. Il punto non è mettere alla gogna i siti con molti script. Il punto è creare un benchmark da rivedere.

6. Pattern di categoria: beauty, food, apparel e wellness portano stack pesanti

La tabella per categoria mostra che le categorie DTC ad alta crescita tendono ad avere un forte carico di script.

Beauty & Skincare, Food & Beverage, Apparel & Footwear e Health & Wellness hanno tutte un numero mediano di script vicino o superiore alla mediana complessiva. Queste categorie sono competitive, ricche di contenuti e spesso guidate dal lifecycle. Si basano su education, recensioni, acquisizione paid, discovery tramite creator, abbonamenti, loyalty, quiz e personalizzazione. Questo spinge naturalmente verso più strumenti.

Food & Beverage è interessante perché ha un numero mediano di script elevato ma una visibilità relativamente bassa della gestione del consenso, pari a 5,9%. Questo non prova una lacuna di compliance, ma crea una domanda di governance per i brand food o beverage con forte tracking, soprattutto se operano a livello internazionale.

Apparel & Footwear ha la copertura del gestore del consenso più alta tra le principali categorie mostrate, con 16,1%. Beauty & Skincare è vicina, con 15,3%. Queste categorie possono avere più esposizione internazionale, operazioni paid media più sofisticate o stack ecommerce più maturi nel campione.

La lezione della categoria non è che una categoria sia "cattiva". La lezione è che la governance della performance deve essere consapevole della categoria. Un brand beauty con recensioni, quiz, abbonamenti, raccolta SMS e attribution avrà naturalmente un profilo diverso da un sito catalogo a bassa complessità. Il benchmark deve guidare la priorità, non imporre un unico target universale.

7. Gestione del consenso: il divario tra tracking e governance

La gestione del consenso compare nel 9,6% dei domini analizzati complessivamente. Tra i brand con 5+ strumenti analytics, compare nel 14,0%.

Questo è uno dei risultati più importanti perché collega l’instrumentation di growth alla governance della privacy. Più pesante è lo stack, più importante diventa la logica del consenso. Eppure i segnali visibili in stile Cookiebot / OneTrust restano relativamente rari.

Questa metrica ha delle cautele. Un brand può usare un consent manager non coperto dalla rilevazione. Può implementare il consenso tramite una soluzione custom. Può caricare gli script di consenso in modo dinamico. Può operare principalmente in mercati con aspettative di compliance diverse. Quindi il numero non va citato come "solo il 9,6% è conforme alla legge sulla privacy". Sarebbe troppo forte e probabilmente sbagliato.

La citazione corretta è più ristretta: solo il 9,6% dei domini analizzati espone un segnale di gestione del consenso in stile Cookiebot / OneTrust nell’HTML catturato. È comunque utile. Suggerisce che molti store con tracking intenso non rendono evidente la governance del consenso nel crawl pubblico.

Per chi gestisce il sito, l’azione è semplice: non aspettare un audit legale per inventariare il tracking. Costruisci una mappa dei tag che includa finalità, owner, vendor, dati raccolti, categoria di consenso e condizione di caricamento. I team growth dovrebbero sapere quali tag si attivano prima del consenso, dopo il consenso e su quali pagine.

8. La fascia estrema di script: quando una pagina marketing diventa infrastruttura

Questa ricerca definisce la fascia extreme di carico script come più di 75 tag script. Con questa definizione, il 16,2% dei domini analizzati rientra nella fascia estrema.

Estremo non significa automaticamente sbagliato. Alcuni brand hanno esigenze complesse: routing multiregione, infrastrutture di recensioni pesanti, contenuti prodotto ricchi, personalizzazione, più network pubblicitari, analytics, supporto, sperimentazione e integrazioni di checkout. Un brand complesso può ragionevolmente richiedere una pagina complessa.

Ma il livello estremo dovrebbe attivare la governance. Oltre 75 script, una homepage non è più un semplice asset marketing. È infrastruttura. Ha bisogno di:

• Un elenco di responsabili degli script
• Una policy di caricamento dei tag
• Una mappatura delle categorie di consenso
• Monitoraggio della performance
• Pulizia regolare dei vendor
• Percorsi di QA per carrello e checkout
• Regole di deduplicazione degli eventi
• Un piano di rollback per i vendor che si rompono

Lo script più pericoloso non è il più pesante. È quello orfano: uno snippet di vendor di cui nessun membro attuale del team si occupa, che alimenta una dashboard che nessuno apre, rallenta una pagina che nessuno rivede.

9. Il playbook operativo: come governare lo stack growth

La risposta pratica a questo report non è una rimozione indiscriminata degli strumenti. È un workflow di governance.

Step 1: inventaria ogni script. Esporta tutte le fonti degli script dalla homepage, dalle pagine prodotto, dalle pagine collezione, dal carrello e dalle pagine adiacenti al checkout. Includi gli script inline, dove possibile.

Step 2: assegna l’ownership. Ogni script deve avere un responsabile business e un responsabile tecnico. Se nessuno sa indicare il responsabile, lo script è un candidato alla rimozione.

Step 3: classifica la finalità. Acquisizione, retention, attribution, recensioni, supporto clienti, pagamenti, personalizzazione, sperimentazione, consenso, analytics, monitoraggio o legacy.

Step 4: mappa il comportamento del consenso. Decidi se ogni script è essenziale, analytics, marketing, personalizzazione o supporto. Verifica quando si attiva.

Step 5: controlla l’uso reale. La dashboard è attiva? Il vendor è ancora sotto contratto? I report vengono letti? Lo strumento influisce sulle decisioni?

Step 6: misura l’impatto. Testa le performance della pagina con e senza i vendor pesanti, dove possibile. Monitora Core Web Vitals, ritardo di interazione e blocco del main thread.

Step 7: consolida. Se due strumenti servono la stessa funzione, scegline uno. Strumenti duplicati per attribution e analytics spesso generano più discussioni che chiarezza.

Step 8: rivedi ogni trimestre. Lo stack growth dovrebbe avere un ciclo di pulizia, proprio come gli account pubblicitari e i flussi email.

Questo workflow trasforma la performance da lamentela dell’ingegneria in disciplina operativa.

10. Cosa possono citare i team SEO e content

Questa ricerca crea diversi angoli di contenuto forti:

"La homepage DTC mediana ha 52 script." È l’aggancio più ampio sulla performance.

"Più pesante è lo stack analytics, più pesante è la pagina." I brand con 5+ strumenti analytics hanno 69 script mediani, contro i 16 dei brand con 0-2 strumenti analytics.

"La maturità di growth crea debito di performance." I brand più impegnati nella misurazione e nell’infrastruttura lifecycle portano più dipendenze frontend.

"La visibilità del consenso è in ritardo rispetto alla profondità del tracking." Anche tra i siti con 5+ strumenti analytics, la copertura visibile del gestore del consenso è solo del 14,0%.

"La performance DTC non è più solo un problema per sviluppatori." Marketing, lifecycle, paid media, supporto e analytics inseriscono tutti codice nella pagina.

La cautela è importante: non presentare il numero di script come prova di scarse performance. Usalo come proxy del carico di dipendenze e del bisogno di governance.

11. Come i diversi team dovrebbero leggere questo report

Il costo nascosto dello stack growth è cross-funzionale. Per questo è difficile da risolvere. Ogni team vede una parte diversa del problema.

I team growth vedono il vantaggio di revenue. Vogliono attribution migliore, audience più precise, retargeting più forte, feedback di campagna più chiaro, test di landing page migliori e più raccolta per il lifecycle. Dal loro punto di vista, uno script nuovo è spesso un piccolo prezzo da pagare per ricavi più misurabili.

I team frontend vedono il costo delle dipendenze. Si occupano di pagine più lente, layout shift, errori del browser, outage di terze parti, blocchi del main thread, problemi di hydration e fallimenti QA causati da script che potrebbero non possedere. Dal loro punto di vista, i tag marketing spesso si comportano come dipendenze di produzione non gestite.

I team SEO vedono il costo per ranking e crawling. Si interessano a Core Web Vitals, renderabilità, dati strutturati, efficienza del crawl e user experience. Se un sito diventa più lento o più fragile, le performance SEO possono peggiorare anche quando il nuovo vendor è stato aggiunto per supportare growth paid o retention.

I team data vedono il costo della misurazione. Più strumenti possono significare più duplicazione di eventi, più disaccordi tra dashboard, più UTM rotti, più discussioni sulla channel credit e più incertezza su quali numeri guidino le decisioni.

I team legali e privacy vedono il costo del consenso. Più tracking significa più review dei vendor, più domande sul trattamento dei dati, più categorie di consenso, più comportamenti regionali e più gestione del rischio.

I dirigenti vedono il costo di budget e accountability. Ogni strumento ha una fee di abbonamento, ma il costo più grande può essere il tempo speso per riconciliare i dati, mantenere le integrazioni e risolvere problemi del sito.

La lezione manageriale più importante del report è che nessun singolo team possiede di default l’intero problema. Lo stack growth ha bisogno di un modello operativo condiviso. Una versione pratica è un "stack council" trimestrale con rappresentanti di growth, lifecycle, ecommerce, SEO, engineering, analytics e privacy. L’agenda dovrebbe essere semplice: cosa è stato aggiunto, cosa è stato rimosso, cosa è ancora usato, cosa rallenta il sito, cosa è sensibile dal punto di vista legale e cosa crea valore misurabile?

Sembra burocratico, ma l’alternativa è peggiore: anni di snippet di vendor installati da team diversi, senza mappa condivisa e senza ciclo di pulizia.

12. Il template per la revisione dello stack

Un team DTC può trasformare questa ricerca in una revisione trimestrale usando una tabella semplice. Ogni riga è uno strumento o uno script.

Nome del vendor o dello script. Di cosa si tratta?

Owner business. Chi lo ha richiesto e chi lo usa ancora?

Owner tecnico. Chi può rimuoverlo o modificarlo in sicurezza?

Finalità. Acquisizione, retention, attribution, supporto, recensioni, personalizzazione, pagamenti, sperimentazione, consenso, monitoraggio o legacy.

Pagine caricate. Homepage, pagine prodotto, pagine collezione, carrello, checkout, blog, landing page o globale.

Categoria di consenso. Essenziale, analytics, marketing, personalizzazione, supporto o sconosciuta.

Ultima revisione. Quando il team ha confermato per l’ultima volta che lo strumento è ancora utile?

Evidenza decisionale. Da quale metrica o workflow dipende?

Impatto sulla performance. Influisce in modo materiale su script, richieste di terze parti, lavoro del main thread o Core Web Vitals?

Mantenere, rimandare, consolidare o rimuovere. Qual è la decisione?

Questo template non richiede una piattaforma di engineering sofisticata. Può iniziare come foglio di calcolo. La parte importante non è il formato, ma l’accountability. Una volta che uno strumento ha un owner e una finalità, il team può fare tradeoff razionali. Senza quella mappa, ogni discussione sulla performance diventa politica.

Il miglior risultato non è il numero di script più basso. Il miglior risultato è uno stack intenzionale: meno vendor abbandonati, comportamento del consenso più pulito, meno tag duplicati, analytics più affidabili e performance migliori per gli strumenti che contano davvero.

13. Lo standard minimo di governance

Per i team che non possono avviare subito un vero stack council trimestrale, esiste una versione più leggera. Si parte da tre regole.

Primo, nessun nuovo script di vendor dovrebbe essere aggiunto senza un owner, una finalità e una condizione di rimozione. La condizione di rimozione conta perché molti script vengono installati per una campagna, un test, una migrazione o un lancio temporaneo e poi diventano silenziosamente permanenti.

Secondo, ogni tag analytics o marketing dovrebbe avere una categoria di consenso prima di andare online. Questo non richiede perfezione legale da parte del team marketing, ma richiede un percorso documentato per la revisione privacy.

Terzo, il team dovrebbe mantenere una singola fonte di verità per i vendor attivi dello storefront. Se l’unico modo per sapere cosa gira sul sito è ispezionare il sorgente pagina durante un incidente, lo stack è già non governato.

Queste tre regole non risolveranno ogni problema di performance. Ma impediranno la modalità di fallimento più comune: uno stack growth che continua a espandersi senza memoria.

Metodologia

Questa ricerca utilizza il dataset DTC dual-report raccolto l’11 maggio 2026. Ha analizzato 1.238 domini usando master.csv, perf_metrics.csv e categories.csv.

L’analisi raggruppa i domini per profondità analytics, piattaforma, categoria, carico script, carico di domini di terze parti e composizione dello stack. Numero di script e numero di domini di terze parti vengono usati come proxy pubblici del carico di dipendenze frontend.

Le categorie di strumenti includono segnali di tracking, observability, retention, customer experience, pagamenti e gestione del consenso. Le correlazioni vengono calcolate tra i campi numerici di stack e carico.

Avvertenze

1. Il numero di script è un proxy, non un punteggio completo di performance. Non misura direttamente i Core Web Vitals reali, il blocco del main thread, i tempi di rete o l’esperienza utente.

2. Un numero alto di script non è automaticamente negativo. Un brand complesso può aver bisogno di infrastrutture complesse. Il problema è la complessità non governata.

3. La rilevazione degli strumenti rappresenta un limite inferiore. Alcuni script si caricano in modo dinamico, dopo il consenso, tramite tag manager o tramite rendering lato client.

4. La rilevazione del gestore del consenso non è un’analisi legale. Il dato del 9,6% riflette segnali visibili in stile Cookiebot / OneTrust nell’HTML catturato, non la conformità totale.

5. Il campione non è un censimento completo del DTC. È sbilanciato verso i brand visibili negli ecosistemi di strumenti ecommerce e negli elenchi pubblici DTC.

6. Le etichette di categoria sono orientative. Sono utili per l’analisi dei pattern, ma non per una tassonomia esatta.

Note sulla riproducibilità

La cartella di consegna include:

• analyze_growth_stack_cost.py — script di analisi usato per valutare il carico dello stack storefront, la profondità analytics, il numero di script, il numero di domini di terze parti, la visibilità del gestore del consenso e altri segnali di governance.
• growth_stack_cost_scores.csv — punteggi del costo dello stack growth e metriche di carico a livello di dominio.
• by_analytics_depth.csv — carico di script e domini di terze parti raggruppato per profondità degli strumenti analytics.
• by_platform_stack_cost.csv — confronto del carico dello stack a livello di piattaforma.
• by_category_stack_cost.csv — confronto del carico dello stack a livello di categoria.
• stack_cost_correlations.csv — matrice di correlazione numerica tra i campi di stack e carico.
• highest_script_burden_domains.csv — domini con il carico script più alto per revisione editoriale e validazione manuale.
• summary.json — metriche aggregate principali citate in questo report, inclusi numero mediano di script, numero mediano di domini di terze parti, confronti per profondità analytics, visibilità del gestore del consenso e quota di carico script estremo.

Correzioni alla metodologia, problemi nel dataset e analisi successive sono benvenuti a support@thunderbit.com. Questo report è pubblicato in modo indipendente da qualsiasi posizione commerciale detenuta da Thunderbit; costruiamo un estrattore Web basato sull’AI e abbiamo un interesse strutturale nel fatto che i siti ecommerce pubblici restino abbastanza ispezionabili da consentire a operatori, ricercatori, motori di ricerca e agenti AI di capire cosa vi gira sopra. Il benchmark si basa su 1.238 domini DTC con punteggio, ricavati da segnali pubblici del sito raccolti l’11 maggio 2026. I dati di questo report valgono per sé stessi. — Il team di ricerca Thunderbit, maggio 2026.