Relatório | O custo oculto da stack de crescimento DTC

Posicionamento do leitor

Este relatório foi escrito para quem lida, no dia a dia, com as consequências de uma stack DTC moderna: leads de growth, gestores de ecommerce, profissionais de performance marketing, equipas de lifecycle, marketing operations, equipas de SEO técnico, engenheiros de frontend, responsáveis por analytics e fundadores que continuam a perguntar por que motivo o site parece lento mesmo quando todas as ferramentas parecem fazer falta.

O benchmark original de websites DTC mostrou que ferramentas as marcas usam. Esta pesquisa faz uma pergunta diferente: qual é o custo operacional de empilhar essas ferramentas na loja?

A resposta não é "as ferramentas são más". As marcas DTC usam ferramentas de analytics, retenção, atribuição, avaliações, chat, suporte, pagamentos, upsell e experimentação porque essas ferramentas resolvem problemas reais de receita. O ponto é que cada camada adicional traz um custo de frontend, um custo de QA, um custo de consentimento, um custo de qualidade de dados e um custo de manutenção. As stacks de growth criam capacidade de crescimento, mas também criam arrasto de infraestrutura.

Para SEO e redatores de conteúdo de ecommerce, este relatório oferece um ângulo mais útil do que "as marcas DTC usam muitas ferramentas". A história mais forte é: o playbook padrão de growth DTC tornou-se um problema de performance e governança.

Resumo executivo

Em 1.238 domínios DTC avaliados, a homepage mediana desta amostra contém 52 tags de script e referencia 8 domínios de terceiros. Estes não são detalhes técnicos abstratos. Scripts e domínios de terceiros são a evidência, do lado do browser, da stack de growth de uma marca: analytics, pixels, ferramentas de retenção, chat, avaliações, personalização, pagamentos, upsell, experimentação, consentimento e suporte.

O custo torna-se evidente quando as marcas são agrupadas por profundidade de analytics e marketing:

A diferença é notória. Marcas com 0-2 ferramentas de analytics têm uma mediana de 16 scripts e 4 domínios de terceiros quando os dois primeiros grupos são combinados. Marcas com 5+ ferramentas de analytics têm uma mediana de 69 scripts e 11 domínios de terceiros. Em outras palavras, a stack de growth mais pesada carrega mais de quatro vezes o peso de scripts do grupo com menos analytics.

Os dados de correlação reforçam a mesma ideia. A profundidade da stack tem correlação de 0,731 com a contagem de scripts e 0,547 com os domínios de terceiros. O número de ferramentas de analytics tem correlação de 0,658 com a contagem de scripts e 0,557 com os domínios de terceiros. O número de ferramentas de retenção também se correlaciona de forma relevante com a contagem de scripts, em 0,611. Não se trata apenas de alguns casos isolados. É um padrão estrutural: à medida que a stack pública de growth cresce, a complexidade no browser também aumenta.

O relatório também revela uma lacuna de privacidade e governança. O gerenciamento de consentimento, medido aqui por sinais visíveis no estilo Cookiebot / OneTrust, aparece em apenas 9,6% dos domínios avaliados. Entre marcas com 5+ ferramentas de analytics, a cobertura de gestor de consentimento é de 14,0%. Isto não prova que as outras marcas estejam em incumprimento, porque ferramentas de consentimento podem ser implementadas de formas que esta deteção não capta. Mas mostra que muitos sites com tracking intenso não exibem um sinal óbvio de gestão de consentimento no HTML capturado.

Por fim, 16,2% dos domínios caem na faixa extrema de carga de scripts, definida aqui como mais de 75 tags de script. Este é um benchmark útil para SEO técnico, operações de growth e equipas de frontend. Se uma homepage DTC tem mais de 75 scripts, já não é apenas uma página de marketing. É uma superfície de infraestrutura que precisa de ownership.

A conclusão central: a maturidade de growth DTC e a complexidade da loja crescem em conjunto. A próxima vantagem não é adicionar mais ferramentas. É governar a stack que já existe.

As conclusões mais partilháveis

1. A homepage DTC mediana desta amostra tem 52 tags de script e 8 domínios de terceiros.

2. Marcas com 5+ ferramentas de analytics têm uma mediana de 69 scripts e 11 domínios de terceiros.

3. Marcas com 0-2 ferramentas de analytics têm uma mediana de 16 scripts e 4 domínios de terceiros.

4. 16,2% dos domínios avaliados caem na faixa extrema de carga de scripts.

5. A visibilidade da gestão de consentimento é de apenas 9,6% no geral e de 14,0% mesmo entre marcas com 5+ ferramentas de analytics.

6. A profundidade da stack correlaciona-se fortemente com a contagem de scripts, em 0,731.

7. A stack de growth DTC já não é apenas uma stack de marketing. É infraestrutura de frontend.

1. Porque o custo da stack de growth importa

As equipas DTC normalmente avaliam ferramentas pelo ganho esperado: melhor atribuição, mais receita por email, maior AOV, melhor suporte, avaliações mais limpas, personalização mais forte, melhor retenção, otimização superior de paid media ou maior aumento de conversão. Faz sentido. As equipas de growth são pagas para crescer.

Mas cada ferramenta também cria custo. Alguns custos são visíveis: taxas de subscrição, trabalho de implementação e gestão contratual. Outros são mais difíceis de ver: páginas mais lentas, mais JavaScript, mais chamadas a terceiros, mais estados de QA, mais lógica de consentimento, mais conflitos entre tags, mais discrepâncias de atribuição, mais revisão de privacidade e mais dúvidas sobre ownership de fornecedores.

Este relatório foca o custo oculto. Usa contagem de scripts, contagem de domínios de terceiros, profundidade da stack, categorias de ferramentas, grupos de plataforma e grupos de categoria como proxies de complexidade. Não afirma que uma contagem alta de scripts seja sempre má. Uma marca de alto desempenho pode, de forma racional, carregar mais scripts porque cada um apoia uma função de receita. Mas alta complexidade sem governança é perigosa.

A pergunta certa não é "como removemos todas as ferramentas?". A pergunta certa é: quais ferramentas ainda merecem estar na página?

2. A linha de base: 52 scripts e 8 domínios de terceiros

A homepage mediana da amostra tem:

• 52 tags de script
• 8 domínios de terceiros

Os valores de p75 da pesquisa de performance subjacente são mais altos: 69 scripts e 12 domínios de terceiros. A contagem máxima de scripts é muito superior, mas o relatório foca a distribuição em vez de usar outliers como exemplos negativos.

Para quem opera o site, a mediana já é suficiente para mostrar o ponto. Uma homepage DTC raramente é apenas HTML, CSS, imagens de produto e um caminho de checkout. É uma camada de coordenação para muitos sistemas: analytics, pixels, gestão de tags, gravação de sessões, avaliações, suporte, quizzes, popups, subscrições, personalização, pagamentos, consentimento e experiências.

O custo oculto aparece em vários pontos:

Custo de performance. Mais scripts podem atrasar o render, competir por tempo da main thread, aumentar pedidos de rede e afetar os Core Web Vitals.

Custo de QA. Cada script de fornecedor adiciona estados para testar: desktop, mobile, consentimento aceite, consentimento recusado, sessão iniciada, sessão encerrada, estado do carrinho, caminho de checkout, domínio regional e diferenças entre browsers.

Custo de atribuição. Mais tags nem sempre criam melhores dados. Podem criar números em conflito, eventos duplicados ou disputas sobre crédito de canais.

Custo de privacidade. Mais superfícies de tracking criam mais questões de consentimento e conformidade.

Custo de ownership. As ferramentas muitas vezes sobrevivem à pessoa que as instalou. Um script pode permanecer no site muito depois de a equipa deixar de usar o painel.

É por isso que a stack de growth deve ser gerida como infraestrutura, e não como um conjunto de extras de marketing.

3. A profundidade de analytics é o fator de custo mais claro

A tabela mais forte da pesquisa é a distribuição por profundidade de analytics:

Esta tabela transforma uma preocupação vaga num benchmark concreto. Passar de 1-2 ferramentas de analytics para 3-4 quase duplica a contagem mediana de scripts, de 30 para 54. Passar para 5+ ferramentas eleva a mediana novamente para 69.

O grupo com 0 ferramentas não deve ser interpretado como melhor. Muitos desses sites podem estar incompletos, parados, ser muito simples, renderizar fortemente no cliente ou ter sido subdetetados. A comparação útil é entre os grupos operacionais principais: 1-2, 3-4 e 5+ ferramentas de analytics.

O grupo com 5+ ferramentas de analytics é especialmente importante. São as marcas mais comprometidas com medição e operações de growth. É provável que se preocupem com aquisição paga, retenção, atribuição, comportamento de sessões, suporte, avaliações ou otimização de conversão. Mas também carregam a maior carga de dependências.

Esse é o paradoxo da stack de growth: as marcas mais sérias em relação à medição são também as mais expostas ao overhead da medição.

4. Correlações: isto é estrutural, não anedótico

A matriz de correlação mostra que a complexidade da stack não é aleatória.

A profundidade da stack tem a relação mais forte com a contagem de scripts. Era esperado, mas importa porque a profundidade da stack é muitas vezes tratada como progresso. Mais ferramentas significam mais capacidades. Mas também significam mais peso no frontend.

Pagamentos mostram uma correlação surpreendentemente forte com a contagem de scripts, em 0,689. Isto não quer dizer que os métodos de pagamento sejam maus. Quer dizer que a flexibilidade no checkout e as integrações de pagamento fazem parte do quadro de complexidade. Uma marca que suporta vários caminhos de pagamento pode melhorar a conversão, especialmente em categorias de AOV alto, mas essas integrações continuam a pertencer ao mapa de governação técnica.

O número de ferramentas de retenção correlaciona-se com a contagem de scripts em 0,611. Isso faz sentido intuitivamente. Ferramentas de lifecycle muitas vezes adicionam formulários onsite, popups, scripts de identificação, captura de SMS, personalização e recolha de eventos. A retenção não vive só no email. Vive na loja.

A implicação de governança é clara: a performance não pode ser resolvida só pela engenharia. Marketing, lifecycle, retenção, paid media, analytics e ecommerce colocam código na página. Todos precisam de participar na governança de performance.

5. Padrões de plataforma: sites Shopify carregam uma stack visível mais pesada

As comparações ao nível da plataforma devem ser interpretadas com cuidado porque a amostra está enviesada para ecossistemas de ferramentas de ecommerce, e Shopify está sobrerrepresentada. Ainda assim, a tabela de plataforma é útil como benchmark de sinal público.

Os sites Shopify da amostra têm uma mediana de 64 scripts e 9 domínios de terceiros, com profundidade média da stack de 6,3. Isto não deve ser lido como "Shopify causa scripts". Uma interpretação mais plausível é que as marcas Shopify nesta amostra estão altamente expostas a ecossistemas de apps, integrações de checkout, ferramentas de lifecycle, ferramentas de avaliações, ferramentas de suporte e fornecedores de growth.

O grupo Desconhecida tem uma mediana de 6 scripts e 2 domínios de terceiros, mas isso não significa necessariamente que esses sites sejam mais leves em termos estratégicos. Muitos sites de plataforma desconhecida podem ocultar impressões da plataforma, ser headless, ter sido subdetetados ou expor menos marcação renderizada no servidor. A leitura correta é visibilidade pública, não stack interna completa.

A tabela de plataforma é mais útil para benchmarking interno. Se um site DTC em Shopify tem 90 scripts, isso está acima da mediana Shopify desta amostra. Se tem 40, está abaixo. O objetivo não é envergonhar sites com muitos scripts. O objetivo é criar um benchmark para revisão.

6. Padrões por categoria: beleza, alimentação, moda e bem-estar carregam stacks pesadas

A tabela de categorias mostra que as categorias DTC de maior crescimento tendem a ter cargas de scripts elevadas.

Beleza & Skincare, Alimentação & Bebidas, Moda & Calçado e Saúde & Bem-estar têm todas contagens medianas de scripts próximas ou acima da mediana geral. Estas categorias são competitivas, ricas em conteúdo e, muitas vezes, orientadas por lifecycle. Dependem de educação, avaliações, aquisição paga, descoberta por creators, subscrições, fidelização, quizzes e personalização. Isso cria uma tendência natural para usar mais ferramentas.

Alimentação & Bebidas é interessante porque tem uma contagem mediana alta de scripts, mas uma visibilidade relativamente baixa de gestor de consentimento, em 5,9%. Isso não prova uma falha de conformidade, mas levanta uma questão de governança para marcas de food ou beverage com muito tracking, especialmente se operarem internacionalmente.

Moda & Calçado tem a maior cobertura de gestor de consentimento entre as principais categorias mostradas, com 16,1%. Beleza & Skincare vem logo atrás, com 15,3%. Estas categorias podem ter maior exposição internacional, operações de paid media mais sofisticadas ou stacks de ecommerce mais maduras na amostra.

A lição por categoria não é que uma categoria seja "má". A lição é que a governança de performance deve ser sensível à categoria. Uma marca de beleza com avaliações, quizzes, subscrições, captura de SMS e atribuição vai parecer naturalmente diferente de um site de catálogo com baixa complexidade. O benchmark deve orientar a priorização, não criar um alvo universal.

7. Gestão de consentimento: a lacuna entre tracking e governança

A gestão de consentimento aparece em 9,6% dos domínios avaliados no geral. Entre marcas com 5+ ferramentas de analytics, aparece em 14,0%.

Esta é uma das descobertas mais importantes porque liga a instrumentação de growth à governança de privacidade. Quanto mais pesada é a stack, mais importante se torna a lógica de consentimento. Ainda assim, os sinais visíveis no estilo Cookiebot / OneTrust continuam relativamente raros.

Esta métrica tem ressalvas. Uma marca pode usar um gestor de consentimento que não seja captado pela deteção. Pode implementar consentimento através de uma solução personalizada. Pode carregar scripts de consentimento de forma dinâmica. Pode operar sobretudo em mercados com expectativas diferentes de conformidade. Portanto, o número não deve ser citado como "apenas 9,6% cumprem a lei da privacidade". Isso seria demasiado forte e provavelmente errado.

A formulação correta é mais restrita: apenas 9,6% dos domínios avaliados expõem um sinal de gestão de consentimento do estilo Cookiebot / OneTrust no HTML capturado. Isso ainda é útil. Sugere que muitas lojas com tracking intenso não tornam a governança de consentimento evidente no crawl público.

Para quem opera o site, a ação é simples: não espere por uma auditoria jurídica para inventariar o tracking. Crie um mapa de tags que inclua finalidade, owner, fornecedor, dados recolhidos, categoria de consentimento e condição de carregamento. As equipas de growth devem saber quais tags disparam antes do consentimento, depois do consentimento e em que páginas.

8. A faixa extrema de scripts: quando uma página de marketing se torna infraestrutura

Esta pesquisa define a faixa extreme de carga de scripts como mais de 75 tags de script. Sob essa definição, 16,2% dos domínios avaliados caem na faixa extrema.

Extremo não significa automaticamente errado. Algumas marcas têm necessidades complexas: routing multirregião, infraestrutura pesada de avaliações, educação rica de produto, personalização, várias redes de anúncios, analytics, suporte, experimentação e integrações de checkout. Uma marca complexa pode, com razão, precisar de uma página complexa.

Mas o extremo deve desencadear governança. Acima de 75 scripts, uma homepage já não é um simples ativo de marketing. É infraestrutura. Precisa de:

• Uma lista de responsáveis pelos scripts
• Uma política de carregamento de tags
• Mapeamento de categorias de consentimento
• Monitorização de performance
• Limpeza regular de fornecedores
• Caminhos de QA para carrinho e checkout
• Regras de desduplicação de eventos
• Um plano de rollback para fornecedores com falhas

O script mais perigoso não é o mais pesado. É o órfão: um snippet de fornecedor que nenhum membro atual da equipa possui, alimentando um painel que ninguém abre e a abrandar uma página que ninguém audita.

9. O playbook do operador: como governar a stack de growth

A resposta prática a este relatório não é uma purga de ferramentas. É um fluxo de trabalho de governança.

Passo 1: Inventariar todos os scripts. Exporte todas as origens de scripts da homepage, da página de produto, da página de coleção, do carrinho e das páginas adjacentes ao checkout. Inclua scripts inline sempre que possível.

Passo 2: Atribuir ownership. Cada script precisa de um owner de negócio e um owner técnico. Se ninguém conseguir nomear o owner, o script é candidato a remoção.

Passo 3: Classificar a finalidade. Aquisição, retenção, atribuição, avaliações, apoio ao cliente, pagamentos, personalização, experimentação, consentimento, monitorização ou legado.

Passo 4: Mapear o comportamento de consentimento. Decida se cada script é essencial, analytics, marketing, personalização ou suporte. Confirme quando é ativado.

Passo 5: Verificar o uso real. O painel está ativo? O fornecedor ainda tem contrato? Os relatórios são revistos? A ferramenta influencia decisões?

Passo 6: Medir o impacto. Teste a performance da página com e sem fornecedores pesados sempre que possível. Acompanhe Core Web Vitals, atraso de interação e bloqueio da main thread.

Passo 7: Consolidar. Se duas ferramentas servem a mesma função, escolha uma. Ferramentas duplicadas de atribuição e analytics muitas vezes criam mais discussão do que clareza.

Passo 8: Rever trimestralmente. A stack de growth deve ter um ciclo de limpeza, tal como as contas de anúncios e os fluxos de email.

Este fluxo de trabalho transforma a performance de uma queixa de engenharia numa disciplina operacional.

10. O que as equipas de SEO e conteúdo podem citar

Esta pesquisa cria vários ângulos fortes para conteúdo:

"A homepage DTC mediana tem 52 scripts." Este é o gancho de performance mais amplo.

"Quanto mais pesada a stack de analytics, mais pesada a página." Marcas com 5+ ferramentas de analytics têm 69 scripts medianos, contra 16 para marcas com 0-2 ferramentas de analytics.

"A maturidade de growth cria dívida de performance." As marcas mais comprometidas com medição e infraestrutura de lifecycle carregam mais dependências de frontend.

"A visibilidade de consentimento fica atrás da profundidade do tracking." Mesmo entre sites com 5+ ferramentas de analytics, a cobertura visível de gestor de consentimento é de apenas 14,0%.

"A performance DTC já não é apenas um problema de developers." Marketing, lifecycle, paid media, suporte e analytics colocam código na página.

A ressalva importa: não apresente a contagem de scripts como prova de má performance. Use-a como proxy da carga de dependências e da necessidade de governança.

11. Como diferentes equipas devem ler este relatório

O custo oculto da stack de growth é transversal. É por isso que é difícil de resolver. Cada equipa vê uma parte diferente do problema.

As equipas de growth veem o ganho de receita. Querem melhor atribuição, audiências mais precisas, retargeting mais forte, feedback de campanha mais claro, melhor teste de landing pages e mais captura de lifecycle. Do ponto de vista delas, um novo script é muitas vezes um pequeno preço a pagar por mais receita mensurável.

As equipas de frontend veem o custo da dependência. Lidam com páginas mais lentas, layout shifts, erros de browser, falhas de terceiros, bloqueios da main thread, problemas de hydration e falhas de QA causadas por scripts que podem não controlar. Do ponto de vista delas, as tags de marketing comportam-se muitas vezes como dependências de produção sem gestão.

As equipas de SEO veem o custo de ranking e crawl. Preocupam-se com Core Web Vitals, renderização, dados estruturados, eficiência de crawl e experiência do utilizador. Se um site fica mais lento ou mais frágil, o desempenho de SEO pode sofrer mesmo quando o novo fornecedor foi adicionado para growth pago ou retenção.

As equipas de dados veem o custo de medição. Mais ferramentas podem significar mais duplicação de eventos, mais desacordo entre dashboards, mais UTMs quebradas, mais disputas sobre crédito de canais e mais incerteza sobre quais números devem orientar as decisões.

As equipas jurídicas e de privacidade veem o custo de consentimento. Mais tracking significa mais revisão de fornecedores, questões de tratamento de dados, categorias de consentimento, comportamento regional e gestão de risco.

Os executivos veem o custo de orçamento e accountability. Cada ferramenta tem uma taxa de subscrição, mas o custo maior pode ser o tempo gasto a reconciliar dados, manter integrações e corrigir problemas do site.

A lição de gestão mais importante do relatório é que nenhuma equipa, por defeito, é dona de todo o problema. A stack de growth precisa de um modelo operacional partilhado. Uma versão prática é um "stack council" trimestral com representação de growth, lifecycle, ecommerce, SEO, engenharia, analytics e privacidade. A agenda deve ser simples: o que foi adicionado, o que foi removido, o que ainda está a ser usado, o que está a abrandar o site, o que é juridicamente sensível e o que está a criar valor mensurável?

Isto parece burocrático, mas a alternativa é pior: anos de snippets de fornecedores instalados por equipas diferentes, sem mapa partilhado e sem ciclo de limpeza.

12. O modelo de revisão da stack

Uma equipa DTC pode transformar esta pesquisa numa revisão trimestral usando uma tabela simples. Cada linha é uma ferramenta ou script.

Nome do fornecedor ou script. O que é?

Owner de negócio. Quem o pediu e quem ainda o usa?

Owner técnico. Quem o pode remover ou modificar em segurança?

Finalidade. Aquisição, retenção, atribuição, suporte, avaliações, personalização, pagamentos, experimentação, consentimento, monitorização ou legado.

Páginas carregadas. Homepage, páginas de produto, páginas de coleção, carrinho, checkout, blog, landing pages ou global.

Categoria de consentimento. Essencial, analytics, marketing, personalização, suporte ou desconhecida.

Última revisão. Quando foi a última vez que a equipa confirmou que a ferramenta ainda é útil?

Evidência de decisão. De que métrica ou fluxo depende?

Impacto na performance. Afeta materialmente scripts, pedidos de terceiros, trabalho da main thread ou Core Web Vitals?

Manter, adiar, consolidar ou remover. Qual é a decisão?

Este modelo não exige uma plataforma de engenharia sofisticada. Pode começar numa folha de cálculo. O importante não é o formato; é a responsabilidade. Assim que uma ferramenta tem owner e finalidade, a equipa consegue fazer trade-offs racionais. Sem esse mapa, toda a discussão de performance torna-se política.

O melhor resultado não é a menor contagem de scripts. O melhor resultado é uma stack intencional: menos fornecedores abandonados, comportamento de consentimento mais limpo, menos tags duplicadas, analytics mais fiáveis e melhor performance para as ferramentas que realmente importam.

13. O padrão mínimo viável de governança

Para equipas que ainda não conseguem lançar um stack council trimestral completo, existe uma versão mais leve. Comece com três regras.

Primeiro, nenhum novo script de fornecedor deve ser adicionado sem owner, finalidade e condição de remoção. A condição de remoção importa porque muitos scripts são instalados para uma campanha, teste, migração ou lançamento temporário e depois tornam-se, silenciosamente, permanentes.

Segundo, cada tag de analytics ou marketing deve ter uma categoria de consentimento antes de entrar em produção. Isto não exige perfeição jurídica da equipa de marketing, mas exige um percurso documentado para revisão de privacidade.

Terceiro, a equipa deve manter uma única fonte de verdade para os fornecedores ativos da loja. Se a única forma de saber o que corre no site for inspecionar o código-fonte durante um incidente, a stack já está sem gestão.

Estas três regras não resolvem todos os problemas de performance. Porém, evitam o modo de falha mais comum: uma stack de growth que continua a crescer sem memória.

Metodologia

Esta pesquisa usa o conjunto de dados do relatório duplo DTC recolhido em 11 de maio de 2026. Avaliou 1.238 domínios usando master.csv, perf_metrics.csv e categories.csv.

A análise agrupa domínios por profundidade de analytics, plataforma, categoria, carga de scripts, carga de domínios de terceiros e composição da stack. A contagem de scripts e a contagem de domínios de terceiros são usadas como proxies públicos da carga de dependência de frontend.

As categorias de ferramentas incluem sinais de tracking, observabilidade, retenção, experiência do cliente, pagamento e gestão de consentimento. As correlações são calculadas entre campos numéricos de stack e de carga.

Limitações

1. A contagem de scripts é um proxy, não uma pontuação completa de performance. Não mede diretamente Core Web Vitals reais, bloqueio da main thread, timing de rede ou experiência do utilizador.

2. Uma contagem alta de scripts não é automaticamente má. Uma marca complexa pode precisar de uma infraestrutura complexa. O problema é a complexidade sem gestão.

3. A deteção de ferramentas é um limite inferior. Alguns scripts carregam dinamicamente, após consentimento, através de gestores de tags ou por renderização do lado do cliente.

4. A deteção de gestor de consentimento não é análise jurídica. O valor de 9,6% reflete sinais visíveis do estilo Cookiebot / OneTrust no HTML capturado, não a conformidade total.

5. A amostra não é um censo completo de DTC. É enviesada para marcas visíveis em ecossistemas de ferramentas de ecommerce e listas públicas de DTC.

6. As etiquetas de categoria são direcionais. São úteis para análise de padrões, mas não constituem taxonomia exata.

Notas de reprodutibilidade

A pasta de entrega inclui:

• analyze_growth_stack_cost.py — script de análise usado para avaliar a carga da stack da loja, a profundidade de analytics, a contagem de scripts, a contagem de domínios de terceiros, a visibilidade do gestor de consentimento e sinais de governança relacionados.
• growth_stack_cost_scores.csv — scores de custo da stack de growth ao nível do domínio e métricas de carga.
• by_analytics_depth.csv — carga de scripts e domínios de terceiros agrupada pela profundidade das ferramentas de analytics.
• by_platform_stack_cost.csv — comparação da carga da stack ao nível da plataforma.
• by_category_stack_cost.csv — comparação da carga da stack ao nível da categoria.
• stack_cost_correlations.csv — matriz de correlação numérica entre campos de stack e de carga.
• highest_script_burden_domains.csv — domínios com maior carga de scripts para revisão editorial e validação manual.
• summary.json — métricas agregadas principais citadas neste relatório, incluindo contagem mediana de scripts, contagem mediana de domínios de terceiros, comparações por profundidade de analytics, visibilidade do gestor de consentimento e quota de carga extrema de scripts.

Correções metodológicas, problemas no conjunto de dados e análises de seguimento são bem-vindos em support@thunderbit.com. Este relatório é publicado de forma independente de qualquer posição comercial que a Thunderbit tenha; construímos um raspador web com IA e temos interesse estrutural em que websites públicos de ecommerce continuem suficientemente inspecionáveis para que operadores, investigadores, motores de busca e agentes de IA entendam o que lá acontece. O benchmark baseia-se em 1.238 domínios DTC avaliados a partir de sinais públicos de websites recolhidos em 11 de maio de 2026. Os dados neste relatório valem por si. — A equipa de pesquisa Thunderbit, maio de 2026.