Для кого этот материал
Этот отчёт написан для тех, кто каждый день живёт с последствиями современного DTC-стека: руководителей growth-направления, ecommerce-менеджеров, performance-маркетологов, lifecycle-команд, специалистов по маркетинговым операциям, технических SEO-команд, frontend-инженеров, владельцев аналитики и основателей, которые всё время спрашивают, почему сайт кажется медленным, хотя каждый инструмент вроде бы нужен.
Исходный бенчмарк DTC-сайтов показывал, какие инструменты используют бренды. Это исследование задаёт другой вопрос: какова операционная цена, если всё это навесить прямо на витрину?
Ответ не в том, что «инструменты плохие». DTC-бренды используют аналитику, retention-инструменты, атрибуцию, отзывы, чат, поддержку, платёжные решения, upsell и инструменты экспериментов, потому что они решают реальные задачи по выручке. Но у каждого дополнительного слоя есть своя цена: для фронтенда, для QA, для согласий, для качества данных и для поддержки. Growth-стек создаёт потенциал для роста, но одновременно добавляет инфраструктурную нагрузку.
Для SEO-специалистов и авторов ecommerce-контента этот отчёт даёт более полезный угол, чем просто «у DTC-брендов много инструментов». Сильнее звучит другой тезис: базовая playbook-модель роста в DTC превратилась в проблему производительности и управления.
Краткий вывод
На выборке из 1 238 DTC-доменов медианная главная страница содержит 52 script-тега и ссылается на 8 сторонних доменов. Это не абстрактные технические детали. Скрипты и сторонние домены — это видимый в браузере след growth-стека бренда: аналитика, пиксели, retention-инструменты, чат, отзывы, персонализация, оплата, upsell, эксперименты, согласия и поддержка.
Цена становится особенно заметной, если сгруппировать бренды по глубине аналитики:
| Группа по глубине аналитики | Выборка | Медиана скриптов | Медиана сторонних доменов | Средняя глубина стека | Охват consent-менеджером |
|---|---|---|---|---|---|
| 0 аналитических инструментов | 157 | 1 | 0 | 0.0 | 0.0% |
| 1–2 аналитических инструмента | 336 | 30 | 6 | 2.2 | 3.6% |
| 3–4 аналитических инструмента | 352 | 54 | 8 | 4.9 | 14.8% |
| 5+ аналитических инструментов | 393 | 69 | 11 | 8.2 | 14.0% |
Разница очень заметна. У брендов с 0–2 аналитическими инструментами медиана составляет 16 скриптов и 4 сторонних домена, если объединить первые две группы. У брендов с 5+ аналитическими инструментами медиана — 69 скриптов и 11 сторонних доменов. Иными словами, более тяжёлый growth-стек несёт более чем в четыре раза большую script-нагрузку, чем группа с минимальной аналитикой.
Корреляции подтверждают тот же вывод. Глубина стека имеет корреляцию 0,731 с количеством скриптов и 0,547 со сторонними доменами. Количество аналитических инструментов имеет корреляцию 0,658 с количеством скриптов и 0,557 со сторонними доменами. Количество retention-инструментов тоже заметно коррелирует с количеством скриптов — 0,611. Это не набор отдельных выбросов. Это структурный паттерн: по мере расширения публичного growth-стека усложняется и браузерная часть.
Отчёт также показывает пробел в приватности и управлении. Consent-management, измеренный здесь по видимым сигналам формата Cookiebot / OneTrust, встречается лишь на 9,6% доменов в выборке. Среди брендов с 5+ аналитическими инструментами coverage consent-менеджера составляет 14,0%. Это не доказывает, что остальные бренды нарушают требования, потому что consent-инструменты могут внедряться так, что этот детектор их не видит. Но это показывает, что многие сайты с тяжёлым трекингом не показывают очевидный сигнал управления consent в захваченном HTML.
Наконец, 16,2% доменов попадают в категорию extreme по script-нагрузке, определённую здесь как более 75 script-тегов. Это полезный ориентир для технического SEO, growth-операций и frontend-команд. Если у DTC-лендинга или главной страницы больше 75 скриптов, это уже не просто маркетинговая страница. Это инфраструктурная поверхность, за которую должен кто-то отвечать.
Главный вывод: зрелость DTC-роста и сложность витрины растут вместе. Следующее преимущество — не в добавлении новых инструментов, а в управлении тем стеком, который уже есть.
Самые цитируемые выводы
-
Медианная DTC-страница в этой выборке содержит 52 script-тега и 8 сторонних доменов.
-
У брендов с 5+ аналитическими инструментами медиана — 69 скриптов и 11 сторонних доменов.
-
У брендов с 0–2 аналитическими инструментами медиана — 16 скриптов и 4 сторонних домена.
-
16,2% доменов в выборке попадают в extreme-уровень script-нагрузки.
-
Видимость consent-management в целом составляет только 9,6%, а среди брендов с 5+ аналитическими инструментами — 14,0%.
-
Глубина стека сильно коррелирует с количеством скриптов: 0,731.
-
DTC-growth-стек — это уже не просто маркетинговый стек. Это frontend-инфраструктура.
1. Почему стоимость growth-стека важна
DTC-команды обычно оценивают инструменты по ожидаемой выгоде: лучшая атрибуция, больше выручки от email, выше AOV, лучше поддержка, чище отзывы, сильнее персонализация, лучше удержание, эффективнее оптимизация paid media или больший uplift конверсии. Это логично. Growth-команды нанимают, чтобы расти.
Но у каждого инструмента есть и издержки. Одни видны сразу: подписка, внедрение, управление контрактами. Другие заметить труднее: более медленные страницы, больше JavaScript, больше запросов к сторонним доменам, больше сценариев для QA, более сложная логика согласий, больше конфликтов тегов, расхождения в атрибуции, дополнительные проверки на соответствие privacy-требованиям и больше вопросов о том, кому принадлежит конкретный vendor.
Этот отчёт сосредоточен на скрытой цене. В качестве прокси сложности используются количество скриптов, количество сторонних доменов, глубина стека, категории инструментов, платформенные группы и категорийные группы. Он не утверждает, что большой script-count всегда плох. Сильный бренд может обоснованно нести больше скриптов, если каждый из них поддерживает функцию, приносящую выручку. Но высокая сложность без управления — опасна.
Правильный вопрос не в том, «как убрать все инструменты». Правильный вопрос — какие инструменты всё ещё заслуживают своё место на странице?
2. Базовый уровень: 52 скрипта и 8 сторонних доменов
Медианная главная страница в выборке имеет:
- 52 script-тега
- 8 сторонних доменов
Значения p75 в исходном исследовании по производительности выше: 69 скриптов и 12 сторонних доменов. Максимальное количество скриптов значительно больше, но в отчёте мы фокусируемся на распределении, а не на выбросах как на негативном примере.
Для операторских команд одной медианы уже достаточно, чтобы увидеть суть. DTC-страница — это редко только HTML, CSS, изображения товара и путь к checkout. Обычно это прослойка координации для множества систем: аналитики, пикселей, tag management, session recording, отзывов, поддержки, квизов, pop-up’ов, подписок, персонализации, платежей, consent и экспериментов.
Скрытая цена проявляется в нескольких местах:
Цена производительности. Большее число скриптов может задерживать отрисовку, конкурировать за время основного потока, увеличивать количество сетевых запросов и влиять на Core Web Vitals.
Цена QA. Каждый скрипт вендора добавляет сценарии для проверки: desktop, mobile, consent принят, consent отклонён, вход выполнен, вход не выполнен, состояние корзины, путь checkout, региональный домен и различия браузеров.
Цена атрибуции. Больше тегов не всегда означает лучшее качество данных. Это может породить конфликтующие цифры, дубли событий или споры о том, какой канал получил кредит за конверсию.
Цена приватности. Чем больше поверхностей для трекинга, тем больше вопросов по согласиям и compliance.
Цена владения. Инструменты часто переживают человека, который их установил. Скрипт может оставаться на сайте ещё долго после того, как команда перестала пользоваться этим дашбордом.
Именно поэтому growth-стек нужно управлять как инфраструктурой, а не как набором маркетинговых дополнений.
3. Глубина аналитики — самый явный драйвер стоимости
Самая сильная таблица в исследовании — разбивка по глубине аналитики:
| Группа по глубине аналитики | Выборка | Медиана скриптов | Среднее число скриптов | Медиана сторонних доменов | Среднее число сторонних доменов | Средняя глубина стека |
|---|---|---|---|---|---|---|
| 0 аналитических инструментов | 157 | 1 | 3.1 | 0 | 1.3 | 0.0 |
| 1–2 аналитических инструмента | 336 | 30 | 35.0 | 6 | 6.5 | 2.2 |
| 3–4 аналитических инструмента | 352 | 54 | 51.1 | 8 | 9.1 | 4.9 |
| 5+ аналитических инструментов | 393 | 69 | 69.1 | 11 | 11.3 | 8.2 |
Эта таблица превращает расплывчатую тревогу в конкретный ориентир. Переход от 1–2 аналитических инструментов к 3–4 почти удваивает медианное количество скриптов — с 30 до 54. Переход к 5+ инструментам снова поднимает медиану — до 69.
Группу с 0 инструментов не стоит считать однозначно лучшей. Многие из этих сайтов могут быть незавершёнными, припаркованными, очень простыми, heavily client-rendered или просто хуже распознанными. Полезнее сравнивать основные операционные группы: 1–2, 3–4 и 5+ аналитических инструментов.
Особенно важна группа с 5+ аналитическими инструментами. Это бренды, которые сильнее всего инвестируют в измерение и growth-операции. Им, скорее всего, важны paid acquisition, retention, атрибуция, поведение сессий, поддержка, отзывы или оптимизация конверсии. Но именно у них и самая тяжёлая зависимостная нагрузка.
В этом и состоит paradox growth-стека: бренды, которые серьёзнее всего относятся к измерениям, одновременно сильнее всего подвержены издержкам измерений.
4. Корреляции: это структурный паттерн, а не отдельные случаи
Матрица корреляций показывает, что сложность стека не случайна.
| Пара | Корреляция |
|---|---|
| Глубина стека и количество скриптов | 0.731 |
| Количество аналитических инструментов и количество скриптов | 0.658 |
| Платежи и количество скриптов | 0.689 |
| Retention-инструменты и количество скриптов | 0.611 |
| Глубина стека и сторонние домены | 0.547 |
| Количество аналитических инструментов и сторонние домены | 0.557 |
| Количество скриптов и сторонние домены | 0.562 |
Наиболее сильная связь — между глубиной стека и количеством скриптов. Это ожидаемо, но важно, потому что глубину стека часто воспринимают как прогресс. Больше инструментов — больше возможностей. Но и больше фронтенд-спроса.
Платежи показывают неожиданно сильную корреляцию с количеством скриптов — 0,689. Это не означает, что платёжные методы плохи. Это значит, что вариативность checkout и платёжные интеграции входят в общую картину сложности. Бренд, который поддерживает несколько платёжных путей, может улучшать конверсию, особенно в категориях с высоким AOV, но эти интеграции всё равно должны быть в карте технического управления.
Количество retention-инструментов коррелирует с количеством скриптов на уровне 0,611. Это интуитивно понятно. Lifecycle-инструменты часто добавляют формы на сайте, pop-up’ы, скрипты идентификации, сбор SMS, персонализацию и event-collection. Retention живёт не только в email. Он живёт и на витрине.
Вывод по управлению очевиден: производительность нельзя решить только силами engineering. Marketing, lifecycle, retention, paid media, analytics и ecommerce — все размещают код на странице. Все они должны участвовать в governance производительности.
5. Паттерны платформ: сайты на Shopify несут более тяжёлый видимый стек
Платформенные сравнения нужно интерпретировать осторожно, потому что выборка смещена в сторону ecommerce-экосистем, а Shopify в ней представлен непропорционально сильно. Тем не менее таблица платформ полезна как публичный ориентир.
| Платформа | Выборка | Медиана скриптов | Медиана сторонних доменов | Средняя глубина стека | Охват consent-менеджером |
|---|---|---|---|---|---|
| Shopify | 783 | 64 | 9 | 6.3 | 11.1% |
| Unknown | 324 | 6 | 2 | 1.2 | 7.1% |
| WordPress | 23 | 24 | 6 | 2.3 | 13.0% |
| Salesforce Commerce Cloud | 10 | 47 | 10 | 3.9 | 30.0% |
| Magento / Adobe Commerce | 6 | 55.5 | 7.5 | 3.8 | 0.0% |
| BigCommerce | 3 | 55 | 9 | 3.7 | 0.0% |
У сайтов на Shopify в этой выборке медиана составляет 64 скрипта и 9 сторонних доменов, а средняя глубина стека — 6,3. Это не следует понимать как «Shopify сам по себе создаёт скрипты». Более правдоподобное объяснение: бренды на Shopify в этой выборке активно используют app-экосистему, checkout-интеграции, lifecycle-инструменты, review-инструменты, support-инструменты и growth-vendor’ов.
Группа Unknown имеет медиану 6 скриптов и 2 сторонних домена, но это не обязательно означает, что такие сайты стратегически проще. Многие неизвестные платформы могут скрывать следы платформы, быть headless, распознаваться хуже или показывать меньше серверно отрендеренной разметки. Корректное чтение здесь — это видимость в публичном HTML, а не полный внутренний стек.
Таблица платформ особенно полезна для внутреннего бенчмаркинга. Если у DTC-сайта на Shopify 90 скриптов, это выше медианы Shopify в этой выборке. Если 40 — ниже. Смысл не в том, чтобы стыдить сайты с большим числом скриптов. Смысл — дать ориентир для ревью.
6. Категорийные паттерны: beauty, food, apparel и wellness несут тяжёлые стеки
Таблица категорий показывает, что высокорастущие DTC-категории обычно имеют высокую script-нагрузку.
| Категория | Выборка | Медиана скриптов | Медиана сторонних доменов | Средняя глубина стека | Охват consent-менеджером |
|---|---|---|---|---|---|
| Beauty & Skincare | 98 | 62 | 10.5 | 6.0 | 15.3% |
| Food & Beverage | 118 | 62 | 9 | 5.3 | 5.9% |
| Apparel & Footwear | 149 | 61 | 8 | 5.7 | 16.1% |
| Health & Wellness | 58 | 58 | 9 | 5.8 | 10.3% |
| Home & Furniture | 48 | 58.5 | 9 | 5.4 | 8.3% |
| Outdoor & Sports | 49 | 57 | 8 | 5.3 | 14.3% |
| Baby & Kids | 27 | 57 | 9 | 4.7 | 7.4% |
Beauty & Skincare, Food & Beverage, Apparel & Footwear и Health & Wellness имеют медианные значения скриптов, близкие к общему медианному уровню или выше него. Это конкурентные, насыщенные контентом и часто lifecycle-ориентированные категории. Они опираются на education, отзывы, paid acquisition, creator-discovery, подписки, loyalty, квизы и персонализацию. Это естественно тянет к большему числу инструментов.
Food & Beverage интересна тем, что при высокой медиане script-count у неё сравнительно низкая видимость consent-менеджера — 5,9%. Это не доказывает наличие compliance-пробела, но создаёт вопрос управления для брендов с активным трекингом в food- или beverage-сегменте, особенно если они работают международно.
Apparel & Footwear имеет самый высокий охват consent-менеджером среди основных категорий в таблице — 16,1%. Близко находится Beauty & Skincare — 15,3%. Возможно, у этих категорий больше международного присутствия, более зрелые paid-media-операции или более развитые ecommerce-стеки в выборке.
Урок категорий не в том, что одна категория «плохая». Урок в том, что governance производительности должен учитывать категорию. Бренд в beauty-сегменте с отзывами, квизами, подписками, SMS-сбором и атрибуцией естественно будет выглядеть иначе, чем каталог с низкой сложностью. Бенчмарк должен помогать приоритизировать, а не навязывать единую универсальную цель.
7. Управление согласиями: разрыв между трекингом и governance
Consent-management встречается на 9,6% доменов в общей выборке. Среди брендов с 5+ аналитическими инструментами — на 14,0%.
Это один из важнейших выводов, потому что он связывает growth-инструментацию с управлением приватностью. Чем тяжелее стек, тем важнее логика consent. И всё же видимые сигналы уровня Cookiebot / OneTrust встречаются относительно редко.
У этого показателя есть оговорки. Бренд может использовать consent-менеджер, который не попадает в детект. Он может реализовать consent через кастомное решение. Он может загружать consent-скрипты динамически. Он может работать в основном на рынках с другими ожиданиями по compliance. Поэтому число не стоит цитировать как «только 9,6% соблюдают privacy law». Это было бы слишком сильное и, скорее всего, неверное утверждение.
Корректная формулировка уже точнее: только 9,6% доменов в выборке показывают в захваченном HTML сигнал consent-management в стиле Cookiebot / OneTrust. И это всё равно полезно. Это говорит о том, что многие сайты с тяжёлым трекингом не делают governance consent очевидным в публичном crawl.
Для операторов действие простое: не ждите юридического аудита, чтобы инвентаризировать трекинг. Создайте map тегов, где будет указано назначение, владелец, вендор, собираемые данные, категория согласия и условие загрузки. Growth-команды должны знать, какие теги срабатывают до consent, после consent и на каких страницах.
8. Extreme-уровень script-нагрузки: когда маркетинговая страница становится инфраструктурой
В этом исследовании extreme-уровень script-нагрузки определяется как более 75 script-тегов. По этому определению 16,2% доменов в выборке попадают в extreme-уровень.
Extreme не означает автоматически «неправильно». У некоторых брендов сложные потребности: маршрутизация по регионам, тяжёлая review-инфраструктура, насыщенное product-education, персонализация, несколько рекламных сетей, аналитика, поддержка, эксперименты и интеграции checkout.
Но extreme должен запускать governance. При 75+ скриптах главная страница уже не является простой маркетинговой активностью. Это инфраструктура. Ей нужны:
- список владельцев скриптов
- политика загрузки тегов
- карта категорий consent
- мониторинг производительности
- регулярная чистка вендоров
- QA-сценарии для корзины и checkout
- правила дедупликации событий
- план отката для сломанных вендоров
Самый опасный скрипт — не самый тяжёлый. Самый опасный — забытый: фрагмент вендора, за который уже никто не отвечает, который отправляет данные в дашборд, который никто не открывает, и замедляет страницу, которую никто не ревьюит.
9. Playbook для операторов: как управлять growth-стеком
Практический ответ на этот отчёт — не «вычистить всё». Практический ответ — внедрить governance-workflow.
Шаг 1: Инвентаризируйте каждый скрипт. Выгрузите все script-источники с главной страницы, страницы товара, страницы коллекции, корзины и страниц рядом с checkout. По возможности включайте inline-скрипты.
Шаг 2: Назначьте владельцев. У каждого скрипта должен быть бизнес-владелец и технический владелец. Если никто не может назвать владельца, скрипт — кандидат на удаление.
Шаг 3: Классифицируйте назначение. Acquisition, retention, атрибуция, отзывы, поддержка клиентов, платежи, персонализация, эксперименты, consent, мониторинг или legacy.
Шаг 4: Спланируйте поведение consent. Решите, является ли каждый скрипт essential, analytics, marketing, personalization или support. Подтвердите, когда именно он срабатывает.
Шаг 5: Проверьте фактическое использование. Дашборд активен? Договор с вендором ещё действует? Отчёты кто-нибудь смотрит? Этот инструмент действительно влияет на решения?
Шаг 6: Измерьте эффект. По возможности протестируйте производительность страницы с тяжёлыми вендорами и без них. Отслеживайте Core Web Vitals, задержку взаимодействия и блокировки основного потока.
Шаг 7: Консолидируйте. Если два инструмента делают одно и то же, оставьте один. Дублирующиеся инструменты атрибуции и аналитики часто создают больше споров, чем ясности.
Шаг 8: Пересматривайте раз в квартал. Growth-стек должен проходить цикл чистки так же, как рекламные кабинеты и email-flow’ы.
Этот workflow превращает проблему производительности из жалобы engineering-команды в операционную дисциплину.
10. Что могут цитировать SEO- и контент-команды
Это исследование даёт несколько сильных контентных углов:
«Медианная DTC-страница содержит 52 скрипта». Самый широкий performance-hook.
«Чем тяжелее аналитический стек, тем тяжелее страница». У брендов с 5+ аналитическими инструментами — 69 скриптов по медиане, против 16 у брендов с 0–2 инструментами.
«Зрелость роста создаёт performance-долг». Бренды, которые сильнее всего инвестируют в measurement и lifecycle-инфраструктуру, несут больше фронтенд-зависимостей.
«Видимость consent отстаёт от глубины трекинга». Даже среди сайтов с 5+ аналитическими инструментами видимый охват consent-менеджером составляет лишь 14,0%.
«DTC-производительность — это уже не только проблема разработчиков». Marketing, lifecycle, paid media, support и analytics всё размещают код на странице.
Важно одно предостережение: не представляйте количество скриптов как доказательство плохой производительности. Используйте его как прокси нагрузки зависимостей и потребности в governance.
11. Как разные команды должны читать этот отчёт
Скрытая цена growth-стека — кросс-функциональна. Поэтому её так сложно решить. Каждая команда видит только часть проблемы.
Growth-команды видят upside по выручке. Им нужна лучшая атрибуция, более точные аудитории, сильнее retargeting, понятнее feedback по кампаниям, лучше тестирование landing page и более точный сбор lifecycle-сигналов. С их точки зрения, новый скрипт — часто небольшая цена за более измеримую выручку.
Frontend-команды видят цену зависимостей. Им приходится разбираться с более медленными страницами, layout shift, ошибками браузера, отказами сторонних сервисов, блокировками основного потока, проблемами hydration и QA-сбоями, вызванными скриптами, которые им могут даже не принадлежать. С их точки зрения, маркетинговые теги часто ведут себя как неконтролируемые production-зависимости.
SEO-команды видят цену для ранжирования и crawl-эффективности. Их волнуют Core Web Vitals, возможность рендеринга, structured data, эффективность обхода и пользовательский опыт. Если сайт становится медленнее или более хрупким, SEO может просесть даже тогда, когда новый вендор был добавлен ради paid growth или retention.
Data-команды видят цену измерений. Больше инструментов — больше дублирования событий, больше расхождений между дашбордами, больше сломанных UTM, больше споров о том, какой канал заслужил credit, и больше неопределённости в том, какие цифры должны вести решения.
Юристы и privacy-команды видят цену consent. Чем больше трекинга, тем больше вопросов по вендорам, обработке данных, категориям consent, региональному поведению и управлению рисками.
Руководители видят цену бюджета и ответственности. У каждого инструмента есть подписка, но ещё большая цена — время, потраченное на сверку данных, поддержку интеграций и исправление проблем на сайте.
Самый важный управленческий вывод отчёта в том, что по умолчанию никто не владеет всей проблемой целиком. Growth-стеку нужен общий operating model. Практичный вариант — ежеквартальный «stack council» с участием growth, lifecycle, ecommerce, SEO, engineering, analytics и privacy. Повестка должна быть простой: что добавили, что убрали, что всё ещё используется, что замедляет сайт, что юридически чувствительно и что приносит измеримую ценность?
Это звучит бюрократически, но альтернатива хуже: годы vendor-snippets, установленных разными командами без общей карты и без цикла очистки.
12. Шаблон ревью стека
DTC-команда может превратить это исследование в ежеквартальный review с помощью простой таблицы. Каждая строка — один инструмент или один скрипт.
Название вендора или скрипта. Что это?
Бизнес-владелец. Кто его запросил и кто до сих пор им пользуется?
Технический владелец. Кто может безопасно удалить или изменить его?
Назначение. Acquisition, retention, атрибуция, поддержка, отзывы, персонализация, платежи, эксперименты, consent, мониторинг или legacy.
Где загружается. Главная страница, страницы товаров, страницы коллекций, корзина, checkout, блог, landing pages или глобально.
Категория consent. Essential, analytics, marketing, personalization, support или unknown.
Когда последний раз пересматривали. Когда команда в последний раз подтверждала, что инструмент всё ещё полезен?
Доказательство решения. От какой метрики или workflow он зависит?
Влияние на производительность. Существенно ли он влияет на скрипты, сторонние запросы, работу основного потока или Core Web Vitals?
Оставить, отложить, консолидировать или удалить. Каково решение?
Для этого шаблона не нужна продвинутая инженерная платформа. Он может начаться как обычная таблица. Важен не формат, а ответственность. Как только у инструмента есть владелец и назначение, команда может принимать рациональные trade-off’ы. Без такой карты любая дискуссия о производительности превращается в политику.
Лучший результат — не самый низкий count скриптов. Лучший результат — осознанный стек: меньше забытых вендоров, чище поведение consent, меньше дублей тегов, надёжнее аналитика и лучшая производительность у тех инструментов, которые действительно важны.
13. Минимально жизнеспособный стандарт governance
Для команд, которые не могут сразу запустить полноценный ежеквартальный stack council, есть более лёгкая версия. Начните с трёх правил.
Во-первых, ни один новый vendor-скрипт не должен добавляться без владельца, назначения и условия удаления. Условие удаления особенно важно, потому что многие скрипты ставят ради кампании, теста, миграции или временного запуска, а потом они незаметно становятся постоянными.
Во-вторых, каждый analytics- или marketing-тег должен иметь категорию consent до выхода в продакшн. От маркетинговой команды не требуется юридическое совершенство, но нужен документированный путь на privacy review.
В-третьих, у команды должна быть одна source of truth по активным поставщикам витрины. Если единственный способ понять, что работает на сайте, — открыть исходный код страницы во время инцидента, значит стек уже не управляется.
Эти три правила не решат все проблемы производительности. Но они предотвратят самый распространённый провал: growth-стек, который всё растёт и растёт, но уже не помнит, зачем.
Методология
Это исследование использует DTC dual-report dataset, собранный 11 мая 2026 года. Было оценено 1 238 доменов с помощью master.csv, perf_metrics.csv и categories.csv.
Анализ группирует домены по глубине аналитики, платформе, категории, script-нагрузке, нагрузке сторонних доменов и составу стека. Количество скриптов и количество сторонних доменов используются как публичные прокси фронтенд-зависимостей.
Категории инструментов включают tracking, observability, retention, customer experience, payment и сигналы consent-management. Корреляции рассчитаны по числовым полям стека и нагрузки.
Оговорки
-
Количество скриптов — это прокси, а не полный показатель производительности. Он не измеряет напрямую Core Web Vitals, блокировку основного потока, сетевые тайминги или пользовательский опыт.
-
Большое число скриптов не всегда плохо. Сложному бренду может быть нужна сложная инфраструктура. Проблема — в неуправляемой сложности.
-
Детектирование инструментов — это нижняя граница. Некоторые скрипты загружаются динамически, после consent, через tag manager или через client-side rendering.
-
Детектирование consent-менеджера — это не юридический анализ. Показатель 9,6% отражает видимые сигналы Cookiebot / OneTrust в захваченном HTML, а не общую compliance-ситуацию.
-
Выборка — не полный census DTC-рынка. Она смещена в сторону брендов, заметных в ecommerce-экосистемах и публичных DTC-списках.
-
Категории — ориентирующие. Они полезны для анализа паттернов, но не являются точной таксономией.
Примечания по воспроизводимости
В папке с результатами находятся:
analyze_growth_stack_cost.py— скрипт анализа, использованный для оценки нагрузки growth-стека, глубины аналитики, количества скриптов, количества сторонних доменов, видимости consent-менеджера и связанных governance-сигналов.growth_stack_cost_scores.csv— оценки стоимости growth-стека и метрики нагрузки на уровне доменов.by_analytics_depth.csv— нагрузка по скриптам и сторонним доменам в разрезе глубины аналитических инструментов.by_platform_stack_cost.csv— сравнение нагрузки стека по платформам.by_category_stack_cost.csv— сравнение нагрузки стека по категориям.stack_cost_correlations.csv— матрица числовых корреляций по полям стека и нагрузки.highest_script_burden_domains.csv— домены с наибольшей script-нагрузкой для редакционного ревью и ручной проверки.summary.json— сводные показатели, цитируемые в этом отчёте, включая медианное количество скриптов, медианное количество сторонних доменов, сравнения по глубине аналитики, видимость consent-менеджера и долю extreme-уровня script-нагрузки.
Скачать все скрипты и наборы данных
Исправления методологии, вопросы по данным и предложения по дополнительному анализу можно отправлять на support@thunderbit.com. Этот отчёт опубликован независимо от любой коммерческой позиции Thunderbit; мы создаём AI Web Scraper и имеем структурный интерес в том, чтобы публичные ecommerce-сайты оставались достаточно прозрачными для операторов, исследователей, поисковых систем и AI-агентов, которые должны понимать, что на них работает. Бенчмарк основан на 1 238 оценённых DTC-доменах по публичным сигналам сайтов, собранным 11 мая 2026 года. Данные в этом отчёте стоят сами по себе. — Исследовательская команда Thunderbit, май 2026.
Попробовать Thunderbit для AI веб-скрейпинга
Попробовать Thunderbit Get Started Free
