Informe | El costo oculto del Growth Stack de DTC

Posicionamiento del lector

Este informe está pensado para las personas que viven con las consecuencias de un stack DTC moderno: responsables de growth, managers de ecommerce, especialistas en performance marketing, equipos de lifecycle, marketing operations, equipos de SEO técnico, ingenieros frontend, responsables de analytics y fundadores que siguen preguntándose por qué el sitio se siente lento aunque todas las herramientas parezcan imprescindibles.

El benchmark original del sitio web DTC mostró qué herramientas usan las marcas. Esta investigación plantea una pregunta distinta: ¿cuál es el coste operativo de acumular todas esas herramientas en la tienda online?

La respuesta no es "las herramientas son malas". Las marcas DTC usan herramientas de analytics, retención, atribución, reseñas, chat, soporte, pagos, upsell y experimentación porque resuelven problemas reales de ingresos. El punto es que cada capa adicional tiene un coste en frontend, un coste de QA, un coste de consentimiento, un coste de calidad de datos y un coste de mantenimiento. Los growth stacks generan capacidad de crecimiento, pero también arrastran infraestructura.

Para SEO y para quienes escriben contenido de ecommerce, este informe ofrece un ángulo más útil que "las marcas DTC usan muchas herramientas". La historia más sólida es esta: el playbook de crecimiento por defecto en DTC se ha convertido en un problema de rendimiento y gobernanza.

Resumen ejecutivo

A lo largo de 1.238 dominios DTC puntuados, la página de inicio mediana de esta muestra contiene 52 etiquetas de script y hace referencia a 8 dominios de terceros. No son detalles técnicos abstractos. Los scripts y los dominios de terceros son la prueba, desde el navegador, del growth stack de una marca: analytics, píxeles, herramientas de retención, chat, reseñas, personalización, pagos, upsell, experimentación, consentimiento y soporte.

El coste se vuelve evidente cuando las marcas se agrupan por profundidad de analytics y marketing:

La diferencia es clara. Las marcas con 0-2 herramientas de analytics tienen una mediana de 16 scripts y 4 dominios de terceros cuando se combinan los dos primeros grupos. Las marcas con 5+ herramientas de analytics tienen una mediana de 69 scripts y 11 dominios de terceros. En otras palabras, el growth stack más pesado soporta más de cuatro veces la carga de scripts del grupo con menos nivel de analytics.

Los datos de correlación respaldan la misma idea. La profundidad del stack tiene una correlación de 0,731 con el número de scripts y una correlación de 0,547 con los dominios de terceros. El número de herramientas de analytics tiene una correlación de 0,658 con el número de scripts y de 0,557 con los dominios de terceros. El recuento de herramientas de retención también se correlaciona de forma significativa con el número de scripts, con 0,611. No se trata solo de unos pocos casos aislados. Es un patrón estructural: a medida que se expande el growth stack público, aumenta la complejidad del lado del navegador.

El informe también expone una brecha de privacidad y gobernanza. La gestión del consentimiento, medida aquí mediante señales visibles estilo Cookiebot / OneTrust, aparece solo en 9,6% de los dominios puntuados. Entre las marcas con 5+ herramientas de analytics, la cobertura de gestor de consentimiento es de 14,0%. Esto no prueba que las demás marcas incumplan la normativa, porque las herramientas de consentimiento pueden implementarse de formas que esta detección no captura. Pero sí muestra que muchos sitios con mucho tracking no exponen una señal obvia de gestión del consentimiento en el HTML capturado.

Por último, 16,2% de los dominios cae en el nivel extreme de carga de scripts, definido aquí como más de 75 etiquetas de script. Ese es un benchmark útil para SEO técnico, operaciones de growth y equipos frontend. Si una página de inicio DTC tiene más de 75 scripts, ya no es solo una página de marketing. Es una superficie de infraestructura que necesita responsables claros.

La conclusión central: la madurez del growth DTC y la complejidad de la tienda crecen a la vez. La próxima ventaja no consiste en añadir más herramientas. Consiste en gobernar el stack que ya tienes.

Los hallazgos más compartibles

1. La página de inicio DTC mediana de esta muestra tiene 52 etiquetas de script y 8 dominios de terceros.

2. Las marcas con 5+ herramientas de analytics tienen una mediana de 69 scripts y 11 dominios de terceros.

3. Las marcas con 0-2 herramientas de analytics tienen una mediana de 16 scripts y 4 dominios de terceros.

4. El 16,2% de los dominios puntuados cae en el nivel extremo de carga de scripts.

5. La visibilidad de la gestión del consentimiento es solo del 9,6% en general y del 14,0% incluso entre marcas con 5+ herramientas de analytics.

6. La profundidad del stack se correlaciona fuertemente con el número de scripts, con 0,731.

7. El growth stack DTC ya no es solo un stack de marketing. Es infraestructura frontend.

1. Por qué importa el coste del growth stack

Los equipos DTC suelen evaluar las herramientas por su beneficio esperado: mejor atribución, más ingresos por email, mayor AOV, mejor soporte, reseñas más limpias, personalización más sólida, mejor retención, optimización más eficaz de paid media o mayor incremento de conversión. Es lógico. Los equipos de growth están para crecer.

Pero cada herramienta también genera costes. Algunos son visibles: suscripciones, trabajo de implementación y gestión contractual. Otros son más difíciles de ver: páginas más lentas, más JavaScript, más llamadas a terceros, más escenarios de QA, más lógica de consentimiento, más conflictos de etiquetas, más discrepancias de atribución, más revisión de privacidad y más preguntas sobre quién se hace cargo de cada proveedor.

Este informe se centra en el coste oculto. Usa el recuento de scripts, el número de dominios de terceros, la profundidad del stack, las categorías de herramientas, los grupos de plataformas y los grupos por categoría como proxies de complejidad. No afirma que un número alto de scripts sea siempre malo. Una marca de alto rendimiento puede soportar razonablemente más scripts porque cada uno respalda una función de ingresos. Pero una complejidad alta sin gobernanza es peligrosa.

La pregunta correcta no es "¿cómo eliminamos todas las herramientas?". La pregunta correcta es: ¿qué herramientas siguen ganándose su lugar en la página?

2. La línea base: 52 scripts y 8 dominios de terceros

La página de inicio mediana de la muestra tiene:

• 52 etiquetas de script
• 8 dominios de terceros

Los valores p75 de la investigación de rendimiento subyacente son más altos: 69 scripts y 12 dominios de terceros. El recuento máximo de scripts es mucho más alto, pero el informe se centra en la distribución en lugar de usar los extremos como ejemplos negativos.

Para los operadores, la mediana ya basta para dejar claro el punto. Una página de inicio DTC rara vez es solo HTML, CSS, imágenes de producto y un flujo de checkout. Es una capa de coordinación para muchos sistemas: analytics, píxeles, gestión de etiquetas, grabación de sesiones, reseñas, soporte, quizzes, popups, suscripciones, personalización, pagos, consentimiento y experimentos.

El coste oculto aparece en varios frentes:

Coste de rendimiento. Más scripts pueden retrasar el renderizado, competir por el tiempo del hilo principal, aumentar las solicitudes de red y afectar a Core Web Vitals.

Coste de QA. Cada script de proveedor añade estados que probar: escritorio, móvil, consentimiento aceptado, consentimiento rechazado, sesión iniciada, sesión cerrada, estado del carrito, flujo de checkout, dominio regional y diferencias entre navegadores.

Coste de atribución. Más etiquetas no siempre generan mejores datos. Pueden crear cifras contradictorias, eventos duplicados o discrepancias en el crédito por canal.

Coste de privacidad. Más superficies de tracking crean más preguntas sobre consentimiento y cumplimiento.

Coste de propiedad. Las herramientas suelen sobrevivir a la persona que las instaló. Un script puede seguir en el sitio mucho después de que el equipo deje de usar el panel.

Por eso el growth stack debe gestionarse como infraestructura, no como un montón de complementos de marketing.

3. La profundidad de analytics es el principal motor del coste

La tabla más sólida de la investigación es el desglose por profundidad de analytics:

Esta tabla convierte una preocupación vaga en un benchmark concreto. Pasar de 1-2 herramientas de analytics a 3-4 casi duplica el número mediano de scripts, de 30 a 54. Pasar a 5+ herramientas eleva la mediana otra vez hasta 69.

El grupo de 0 herramientas no debe interpretarse como mejor. Muchos de esos sitios pueden estar incompletos, aparcados, ser muy simples, estar muy cargados en cliente o haber sido detectados de forma incompleta. La comparación útil es entre los grupos operativos habituales: 1-2, 3-4 y 5+ herramientas de analytics.

El grupo de 5+ herramientas de analytics es especialmente importante. Son las marcas más comprometidas con la medición y con las operaciones de growth. Probablemente se preocupan por adquisición pagada, retención, atribución, comportamiento de sesión, soporte, reseñas u optimización de conversión. Pero también cargan con el mayor peso de dependencias.

Ese es el paradoja del growth stack: las marcas más serias respecto a la medición también son las más expuestas a la sobrecarga de medición.

4. Correlaciones: esto es estructural, no anecdótico

La matriz de correlaciones muestra que la complejidad del stack no es aleatoria.

La profundidad del stack es la relación más fuerte con el número de scripts. Era de esperar, pero importa porque a menudo la profundidad del stack se interpreta como progreso. Más herramientas significan más capacidades. Pero también significan más peso frontend.

Los pagos muestran una correlación sorprendentemente fuerte con el número de scripts, de 0,689. Eso no significa que los métodos de pago sean malos. Significa que la variedad de checkout y las integraciones de pago forman parte del panorama de complejidad. Una marca que soporta varios flujos de pago puede mejorar la conversión, especialmente en categorías de AOV alto, pero esas integraciones siguen perteneciendo al mapa de gobernanza técnica.

El recuento de herramientas de retención se correlaciona con el número de scripts en 0,611. Tiene sentido intuitivo. Las herramientas de lifecycle suelen añadir formularios onsite, popups, scripts de identificación, captura de SMS, personalización y recopilación de eventos. La retención no vive solo en email. Vive en la tienda.

La implicación de gobernanza es clara: el rendimiento no puede resolverse solo desde ingeniería. Marketing, lifecycle, retención, paid media, analytics y ecommerce colocan código en la página. Todos deben participar en la gobernanza del rendimiento.

5. Patrones por plataforma: los sitios en Shopify llevan un stack visible más pesado

Las comparaciones por plataforma deben interpretarse con cuidado, porque la muestra está sesgada hacia ecosistemas de herramientas de ecommerce y Shopify está sobrerrepresentado. Aun así, la tabla por plataforma resulta útil como benchmark de señales públicas.

Los sitios de Shopify de la muestra tienen una mediana de 64 scripts y 9 dominios de terceros, con una profundidad media del stack de 6,3. Esto no debe leerse como "Shopify causa scripts". Una interpretación más plausible es que las marcas de Shopify de esta muestra están muy expuestas a ecosistemas de apps, integraciones de checkout, herramientas de lifecycle, herramientas de reseñas, herramientas de soporte y proveedores de growth.

El grupo Unknown tiene una mediana de 6 scripts y 2 dominios de terceros, pero eso no significa necesariamente que esos sitios sean más ligeros desde un punto de vista estratégico. Muchos sitios de plataforma desconocida pueden ocultar huellas de la plataforma, ser headless, estar poco detectados o exponer menos marcado renderizado del lado del servidor. La lectura correcta es visibilidad pública, no stack interno completo.

La tabla de plataforma resulta más útil para benchmarking interno. Si un sitio DTC en Shopify tiene 90 scripts, está por encima de la mediana de Shopify en esta muestra. Si tiene 40, está por debajo. El objetivo no es avergonzar a los sitios con muchos scripts. El objetivo es crear un benchmark para revisar.

6. Patrones por categoría: belleza, alimentación, moda y wellness soportan stacks pesados

La tabla por categoría muestra que las categorías DTC de alto crecimiento tienden a tener cargas de scripts elevadas.

Beauty & Skincare, Food & Beverage, Apparel & Footwear y Health & Wellness tienen todos recuentos medianos de scripts cercanos o superiores a la mediana general. Son categorías competitivas, intensivas en contenido y, a menudo, orientadas al lifecycle. Dependen de la educación, las reseñas, la adquisición pagada, el descubrimiento por creadores, las suscripciones, la fidelidad, los quizzes y la personalización. Eso empuja de forma natural hacia más herramientas.

Food & Beverage es interesante porque tiene un recuento mediano de scripts alto, pero una visibilidad de gestor de consentimiento relativamente baja, de 5,9%. Esto no prueba una brecha de cumplimiento, pero sí plantea una pregunta de gobernanza para las marcas con mucho tracking en alimentos o bebidas, especialmente si operan internacionalmente.

Apparel & Footwear tiene la mayor cobertura de gestor de consentimiento entre las principales categorías mostradas, con 16,1%. Beauty & Skincare se queda cerca, con 15,3%. Estas categorías pueden tener más exposición internacional, operaciones de paid media más sofisticadas o stacks de ecommerce más maduros en la muestra.

La lección de la categoría no es que una categoría sea "mala". La lección es que la gobernanza del rendimiento debe tener en cuenta la categoría. Una marca de belleza con reseñas, quizzes, suscripciones, captura de SMS y atribución se verá naturalmente distinta de un catálogo de baja complejidad. El benchmark debe guiar la priorización, no crear un objetivo único universal.

7. Gestión del consentimiento: la brecha entre tracking y gobernanza

La gestión del consentimiento aparece en 9,6% de los dominios puntuados en general. Entre las marcas con 5+ herramientas de analytics, aparece en 14,0%.

Este es uno de los hallazgos más importantes porque conecta la instrumentación del growth con la gobernanza de privacidad. Cuanto más pesado es el stack, más importante se vuelve la lógica de consentimiento. Sin embargo, las señales visibles estilo Cookiebot / OneTrust siguen siendo relativamente poco comunes.

Esta métrica tiene matices. Una marca puede usar un gestor de consentimiento no cubierto por la detección. Puede implementar el consentimiento mediante una solución personalizada. Puede cargar scripts de consentimiento de forma dinámica. Puede operar principalmente en mercados con expectativas de cumplimiento distintas. Por eso no se debe citar la cifra como "solo el 9,6% cumple la ley de privacidad". Eso sería demasiado fuerte y probablemente incorrecto.

La cita correcta es más precisa: solo el 9,6% de los dominios puntuados expone una señal de gestión del consentimiento estilo Cookiebot / OneTrust en el HTML capturado. Eso sigue siendo útil. Sugiere que muchas tiendas con mucho tracking no hacen evidente su gobernanza de consentimiento en el rastreo público.

Para los operadores, la acción es simple: no esperes a una auditoría legal para inventariar el tracking. Crea un mapa de etiquetas que incluya propósito, responsable, proveedor, datos recopilados, categoría de consentimiento y condición de carga. Los equipos de growth deben saber qué etiquetas se activan antes del consentimiento, después del consentimiento y en qué páginas.

8. El nivel extremo de scripts: cuando una página de marketing se convierte en infraestructura

Esta investigación define el nivel extreme de carga de scripts como más de 75 etiquetas de script. Bajo esa definición, 16,2% de los dominios puntuados cae en el nivel extremo.

Extreme no significa automáticamente mal. Algunas marcas tienen necesidades complejas: routing multirregión, infraestructura pesada de reseñas, educación de producto rica, personalización, varias redes publicitarias, analytics, soporte, experimentación e integraciones de checkout. Una marca compleja puede necesitar razonablemente una página compleja.

Pero extreme sí debe activar la gobernanza. Por encima de 75 scripts, una página de inicio ya no es un simple activo de marketing. Es infraestructura. Necesita:

• Una lista de responsables de scripts
• Una política de carga de etiquetas
• Un mapa de categorías de consentimiento
• Monitoreo de rendimiento
• Limpieza periódica de proveedores
• Flujos de QA para carrito y checkout
• Reglas de deduplicación de eventos
• Un plan de rollback para proveedores rotos

El script más peligroso no es el más pesado. Es el huérfano: un fragmento de proveedor del que ningún miembro actual del equipo se hace cargo, que alimenta un panel que nadie abre y ralentiza una página que nadie audita.

9. El playbook del operador: cómo gobernar el growth stack

La respuesta práctica a este informe no es eliminar herramientas sin más. Es un flujo de trabajo de gobernanza.

Paso 1: inventaría cada script. Exporta todas las fuentes de script de la página de inicio, la página de producto, la página de colección, el carrito y las páginas cercanas al checkout. Incluye scripts inline siempre que sea posible.

Paso 2: asigna responsables. Cada script necesita un responsable de negocio y un responsable técnico. Si nadie puede nombrar al responsable, el script es un candidato a eliminación.

Paso 3: clasifica el propósito. Adquisición, retención, atribución, reseñas, soporte al cliente, pagos, personalización, experimentación, consentimiento, analytics o legado.

Paso 4: mapea el comportamiento de consentimiento. Decide si cada script es esencial, analytics, marketing, personalización o soporte. Confirma cuándo se activa.

Paso 5: comprueba el uso real. ¿El panel sigue activo? ¿El proveedor sigue contratado? ¿Se revisan los informes? ¿La herramienta influye en decisiones?

Paso 6: mide el impacto. Prueba el rendimiento de la página con y sin proveedores pesados, siempre que sea posible. Haz seguimiento de Core Web Vitals, retraso de interacción y bloqueo del hilo principal.

Paso 7: consolida. Si dos herramientas sirven para la misma función, elige una. Las herramientas duplicadas de atribución y analytics suelen generar más discusión que claridad.

Paso 8: revisa cada trimestre. El growth stack debe tener un ciclo de limpieza, igual que las cuentas de anuncios y los flujos de email.

Este flujo de trabajo convierte el rendimiento de una queja de ingeniería en una disciplina operativa.

10. Lo que SEO y los equipos de contenido pueden citar

Esta investigación genera varios ángulos de contenido sólidos:

"La página de inicio DTC mediana tiene 52 scripts." Es el gancho de rendimiento más amplio.

"Cuanto más pesado es el stack de analytics, más pesada es la página." Las marcas con 5+ herramientas de analytics tienen 69 scripts medianos, frente a 16 en las marcas con 0-2 herramientas de analytics.

"La madurez del growth crea deuda de rendimiento." Las marcas más comprometidas con la medición y con la infraestructura de lifecycle cargan con más dependencias frontend.

"La visibilidad del consentimiento va por detrás de la profundidad del tracking." Incluso entre sitios con 5+ herramientas de analytics, la cobertura visible de gestor de consentimiento es solo del 14,0%.

"El rendimiento DTC ya no es solo un problema de desarrolladores." Marketing, lifecycle, paid media, soporte y analytics colocan código en la página.

El matiz es importante: no presentes el recuento de scripts como prueba de mal rendimiento. Úsalo como proxy de carga de dependencias y de necesidad de gobernanza.

11. Cómo deberían leer este informe los distintos equipos

El coste oculto del growth stack es transversal. Por eso es difícil de resolver. Cada equipo ve una parte distinta del problema.

Los equipos de growth ven la ventaja en ingresos. Quieren mejor atribución, audiencias más precisas, mejor retargeting, feedback más claro de campañas, mejores pruebas de landing pages y más captura de lifecycle. Desde su perspectiva, un script nuevo suele ser un pequeño precio a pagar por más ingresos medibles.

Los equipos frontend ven el coste de dependencias. Se enfrentan a páginas más lentas, cambios de layout, errores del navegador, caídas de terceros, bloqueos del hilo principal, problemas de hydration y fallos de QA causados por scripts de los que quizá no sean dueños. Desde su perspectiva, las etiquetas de marketing suelen comportarse como dependencias de producción no gestionadas.

Los equipos SEO ven el coste de ranking y rastreo. Les importan Core Web Vitals, renderización, datos estructurados, eficiencia de rastreo y experiencia de usuario. Si un sitio se vuelve más lento o más frágil, el rendimiento SEO puede empeorar aunque el nuevo proveedor se haya añadido para growth pagado o retención.

Los equipos de datos ven el coste de la medición. Más herramientas pueden significar más duplicación de eventos, más desacuerdo entre dashboards, más UTMs rotas, más discusiones sobre crédito de canal y más incertidumbre sobre qué cifras deben guiar las decisiones.

Los equipos legales y de privacidad ven el coste del consentimiento. Más tracking implica más revisión de proveedores, preguntas sobre tratamiento de datos, categorías de consentimiento, comportamiento regional y gestión de riesgos.

Los ejecutivos ven el coste de presupuesto y responsabilidad. Cada herramienta tiene una cuota de suscripción, pero el coste mayor puede ser el tiempo invertido en reconciliar datos, mantener integraciones y corregir problemas del sitio.

La lección de gestión más importante del informe es que, por defecto, ningún equipo posee todo el problema. El growth stack necesita un modelo operativo compartido. Una versión práctica es un "stack council" trimestral con representación de growth, lifecycle, ecommerce, SEO, ingeniería, analytics y privacidad. La agenda debe ser simple: qué se añadió, qué se eliminó, qué sigue usándose, qué está ralentizando el sitio, qué es sensible desde el punto de vista legal y qué está generando valor medible.

Esto suena burocrático, pero la alternativa es peor: años de fragmentos de proveedores instalados por distintos equipos, sin mapa compartido ni ciclo de limpieza.

12. La plantilla de revisión del stack

Un equipo DTC puede convertir esta investigación en una revisión trimestral mediante una tabla sencilla. Cada fila es una herramienta o un script.

Nombre del proveedor o del script. ¿Qué es?

Responsable de negocio. ¿Quién lo pidió y quién lo sigue usando?

Responsable técnico. ¿Quién puede eliminarlo o modificarlo con seguridad?

Propósito. Adquisición, retención, atribución, soporte, reseñas, personalización, pagos, experimentación, consentimiento, monitoreo o legado.

Páginas donde se carga. Página de inicio, páginas de producto, páginas de colección, carrito, checkout, blog, landing pages o global.

Categoría de consentimiento. Esencial, analytics, marketing, personalización, soporte o desconocida.

Última revisión. ¿Cuándo confirmó el equipo por última vez que la herramienta sigue siendo útil?

Evidencia de decisión. ¿De qué métrica o flujo depende?

Impacto en el rendimiento. ¿Afecta de forma material a los scripts, las solicitudes de terceros, el trabajo del hilo principal o Core Web Vitals?

Conservar, posponer, consolidar o eliminar. ¿Cuál es la decisión?

Esta plantilla no requiere una plataforma de ingeniería sofisticada. Puede empezar como una hoja de cálculo. Lo importante no es el formato; es la responsabilidad. Una vez que una herramienta tiene responsable y propósito, el equipo puede tomar decisiones racionales. Sin ese mapa, cualquier conversación sobre rendimiento se vuelve política.

El mejor resultado no es el número más bajo de scripts. El mejor resultado es un stack intencional: menos proveedores abandonados, un comportamiento de consentimiento más limpio, menos etiquetas duplicadas, analytics más fiables y mejor rendimiento para las herramientas que de verdad importan.

13. El estándar mínimo viable de gobernanza

Para los equipos que no pueden poner en marcha de inmediato un consejo trimestral completo del stack, existe una versión más ligera. Empieza con tres reglas.

Primero, no debe añadirse ningún script nuevo de proveedor sin un responsable, un propósito y una condición de eliminación. La condición de eliminación importa porque muchos scripts se instalan para una campaña, una prueba, una migración o un lanzamiento temporal y luego se vuelven, en silencio, permanentes.

Segundo, toda etiqueta de analytics o marketing debe tener una categoría de consentimiento antes de salir a producción. Esto no exige perfección legal por parte del equipo de marketing, pero sí requiere una ruta documentada para la revisión de privacidad.

Tercero, el equipo debe mantener una única fuente de verdad para los proveedores activos de la tienda online. Si la única forma de saber qué se ejecuta en el sitio es inspeccionar el código fuente durante un incidente, el stack ya está sin gestionar.

Estas tres reglas no resolverán todos los problemas de rendimiento. Sin embargo, sí evitarán el fallo más común: un growth stack que sigue creciendo sin memoria.

Metodología

Esta investigación utiliza el conjunto de datos del doble informe DTC recopilado el 11 de mayo de 2026. Puntuó 1.238 dominios usando master.csv, perf_metrics.csv y categories.csv.

El análisis agrupa los dominios por profundidad de analytics, plataforma, categoría, carga de scripts, carga de dominios de terceros y composición del stack. El recuento de scripts y el recuento de dominios de terceros se usan como proxies públicos de la carga de dependencias frontend.

Las categorías de herramientas incluyen señales de tracking, observabilidad, retención, experiencia del cliente, pago y gestión del consentimiento. Las correlaciones se calculan entre campos numéricos del stack y de la carga.

Advertencias

1. El recuento de scripts es un proxy, no una puntuación completa de rendimiento. No mide directamente Core Web Vitals reales, bloqueo del hilo principal, tiempos de red o experiencia de usuario.

2. Un alto número de scripts no es automáticamente malo. Una marca compleja puede necesitar infraestructura compleja. El problema es la complejidad sin gestionar.

3. La detección de herramientas es un límite inferior. Algunos scripts se cargan de forma dinámica, después del consentimiento, a través de gestores de etiquetas o mediante renderizado del lado del cliente.

4. La detección del gestor de consentimiento no es un análisis legal. La cifra del 9,6% refleja señales visibles estilo Cookiebot / OneTrust en el HTML capturado, no el cumplimiento total.

5. La muestra no es un censo completo de DTC. Está sesgada hacia marcas visibles en ecosistemas de herramientas de ecommerce y listas públicas de DTC.

6. Las etiquetas de categoría son orientativas. Son útiles para análisis de patrones, pero no constituyen una taxonomía exacta.

Notas de reproducibilidad

La carpeta de entrega incluye:

• analyze_growth_stack_cost.py — script de análisis utilizado para puntuar la carga del stack de la tienda online, la profundidad de analytics, el número de scripts, el número de dominios de terceros, la visibilidad del gestor de consentimiento y otras señales de gobernanza relacionadas.
• growth_stack_cost_scores.csv — puntuaciones de coste del growth stack a nivel de dominio y métricas de carga.
• by_analytics_depth.csv — carga de scripts y dominios de terceros agrupada por profundidad de herramientas de analytics.
• by_platform_stack_cost.csv — comparación de la carga del stack a nivel de plataforma.
• by_category_stack_cost.csv — comparación de la carga del stack a nivel de categoría.
• stack_cost_correlations.csv — matriz de correlación numérica entre campos del stack y de la carga.
• highest_script_burden_domains.csv — dominios con mayor carga de scripts para revisión editorial y validación manual.
• summary.json — métricas agregadas principales citadas en este informe, incluyendo el número mediano de scripts, el número mediano de dominios de terceros, comparaciones de profundidad de analytics, visibilidad del gestor de consentimiento y la proporción del nivel extremo de carga de scripts.

Las correcciones de metodología, los problemas del conjunto de datos y los análisis de seguimiento son bienvenidos en support@thunderbit.com. Este informe se publica de forma independiente de cualquier posición comercial que Thunderbit tenga; construimos un raspador web impulsado por IA, y tenemos un interés estructural en que los sitios de ecommerce públicos sigan siendo lo bastante inspeccionables para que operadores, investigadores, motores de búsqueda y agentes de IA puedan entender qué se ejecuta en ellos. El benchmark se basa en 1.238 dominios DTC puntuados a partir de señales públicas de sitios web recopiladas el 11 de mayo de 2026. Los datos de este informe se sostienen por sí solos. — El equipo de investigación de Thunderbit, mayo de 2026.