Как измерить качество сайта цифрами: 15 метрик вместо субъективного «нравится / не нравится»

Слова «сайт стал лучше» ничего не значат, пока мы не договорились, что такое «лучше». Быстрее? Стабильнее? Удобнее? Приносит больше заявок? Реже ломается? Лучше индексируется? Его быстрее развивает команда? У сайта может быть современный дизайн и при этом низкая конверсия. Может быть отличная скорость загрузки, но половина пользователей не заканчивает заполнение формы. Может быть высокая посещаемость, но ошибки API не дают клиентам оформить заявку. Поэтому качество цифрового продукта полезнее обсуждать не через: «Мне нравится новая версия».

А через: «После изменений конверсия выросла, LCP уменьшился, количество ошибок снизилось, а команда стала выпускать изменения чаще». Так разговор о дизайне и разработке превращается в разговор о результате. Качество сайта — это не одна метрика Невозможно выбрать один показатель и сказать: Если он хороший, значит и сайт хороший. Сайт одновременно должен решать несколько задач. Он должен:

• приносить бизнес-результат;
• быстро отвечать;
• стабильно работать;
• помогать человеку выполнить задачу;
• индексироваться;
• не создавать чрезмерную стоимость поддержки;
• позволять команде безопасно выпускать изменения.

Поэтому в VERB мы бы разделили качество сайта на несколько групп: Деньги Скорость Надёжность UX SEO и доступность Engineering Рассмотрим 15 метрик, которые позволяют измерять эти направления. Деньги

1. Conversion Rate

Conversion Rate показывает, какая доля посетителей выполняет целевое действие. Например:

• оставляет заявку;
• записывается;
• покупает;
• регистрируется;
• начинает пробный период.

Формула: Conversion Rate = количество конверсий / количество посетителей × 100% Допустим: на сайт пришли 10 000 пользователей. 300 оставили заявку. Conversion Rate: 3%. После изменения оффера и формы заявки: из 10 000 пользователей заявку оставили 420. Теперь: 4,2%. Трафик практически не изменился. Но сайт начал приносить на 120 заявок больше. Это хороший пример того, почему качество сайта нельзя оценивать только по внешнему виду.

2. Revenue

Для ecommerce и цифровых продуктов один из самых прямых показателей — выручка, которую генерирует сайт. Важно смотреть не только на абсолютное значение, но и на связь с изменениями продукта. Например: до изменений 1000 заказов × 5 000 ₽ = 5 000 000 ₽ после изменений 1150 заказов × 5 000 ₽ = 5 750 000 ₽ Если увеличение произошло при сопоставимом трафике, изменение интерфейса или пользовательского сценария могло дать измеримый бизнес-эффект. Для B2B-сайта вместо прямой ecommerce-выручки можно отслеживать сделки, дошедшие из сайта до продажи.

3. Lead Value

Не все заявки одинаково ценны. Сайт может начать генерировать в два раза больше лидов, но если большинство из них нерелевантны, реальный результат бизнеса не улучшится. Поэтому полезно считать Lead Value . Например, можно учитывать:

• среднюю стоимость сделки;
• вероятность конверсии лида в клиента;
• источник заявки;
• тип услуги;
• бюджет потенциального клиента.

Упрощённо: Lead Value = вероятность сделки × средняя ценность сделки Это помогает отличить: «Мы получили больше форм». от: «Мы получили больше качественных потенциальных клиентов». Скорость

4. TTFB

TTFB — Time to First Byte. Показатель показывает, насколько быстро сервер начинает отвечать пользователю. Высокий TTFB может указывать на проблемы в:

• backend;
• базе данных;
• инфраструктуре;
• кэшировании;
• серверном рендеринге;
• внешних сервисах.

Пользователь ещё не видит страницу, а задержка уже началась. Поэтому TTFB помогает отделить проблему frontend от проблемы серверной части. Если backend отвечает медленно, оптимизация одной картинки проблему не решит.

5. LCP

LCP — Largest Contentful Paint — одна из метрик Core Web Vitals. Она помогает оценить, когда основной крупный элемент страницы становится видимым пользователю. Это может быть:

• главный заголовок;
• изображение первого экрана;
• крупная карточка;
• hero-блок.

Для бизнеса смысл показателя простой: Насколько быстро человек увидел основное содержание страницы? Страница может технически начать загружаться быстро, но несколько секунд оставаться почти пустой. Именно поэтому одной общей метрики «страница загрузилась за N секунд» бывает недостаточно.

6. API Latency

Современный сайт часто состоит не только из HTML. Он обращается к:

• CRM;
• CMS;
• каталогу;
• системе авторизации;
• поиску;
• платежам;
• внутренним API.

Поэтому отдельно полезно измерять API latency . Например: GET /products — 120 ms POST /lead — 180 ms GET /search — 1 900 ms Общее среднее значение может выглядеть нормально, но один медленный endpoint будет портить конкретный пользовательский сценарий. Особенно важны:

• login;
• search;
• checkout;
• формы;
• каталог;
• CRM-операции.

Надёжность

7. Uptime

Uptime показывает, какую часть времени продукт доступен пользователям. Для маркетинга простой сайта означает потерю трафика. Для ecommerce — возможную потерю заказов. Для SaaS — невозможность использовать продукт. Поэтому uptime стоит измерять автоматически, а не ждать, пока клиент первым напишет: «У вас сайт не открывается». Мониторинг должен проверять не только наличие сервера. Полезнее контролировать критические пользовательские сценарии:

• открывается ли сайт;
• отвечает ли API;
• работает ли база;
• можно ли отправить форму;
• работает ли авторизация.

8. Error Rate

Error Rate показывает долю запросов или действий, заканчивающихся ошибкой. Например: из 100 000 API-запросов 1 500 завершились ошибкой. Error Rate: 1,5%. Но даже здесь важно смотреть глубже. Ошибка в малозначимом аналитическом endpoint и ошибка при оплате имеют разную бизнес-ценность. Поэтому полезно разбивать ошибки по:

• endpoint;
• типу;
• странице;
• пользовательскому сценарию;
• версии релиза.

Тогда после новой версии можно увидеть: Error Rate checkout вырос после deployment. Это уже конкретный инженерный сигнал. UX

9. Bounce Rate

Bounce Rate помогает понять, как часто пользователь покидает сайт, практически не продолжая взаимодействие. Сам по себе показатель нельзя трактовать вне контекста. Например, человек может найти телефон на странице контактов и уйти — при этом сайт полностью решил его задачу. Но если после изменения первого экрана резко увеличилось число пользователей, которые не продолжают сценарий, это повод для анализа. Bounce Rate полезно рассматривать вместе с:

• источником трафика;
• типом страницы;
• временем взаимодействия;
• конверсией;
• глубиной просмотра.

То есть не: «Bounce Rate высокий — сайт плохой». А: «Почему определённый сегмент пользователей уходит именно на этом этапе?»

10. Task Completion Rate

Очень сильная UX-метрика — Task Completion Rate . Она отвечает на простой вопрос: Может ли пользователь выполнить то, ради чего пришёл? Например:

• найти цену;
• оформить заказ;
• записаться на консультацию;
• скачать документ;
• создать аккаунт;
• найти нужную услугу.

Из 100 пользователей 81 успешно выполнил сценарий. Task Completion Rate: 81%. После изменения навигации показатель стал 92%. Вот это уже измеримое улучшение UX. Не: «Меню стало современнее». А: «Пользователи чаще находят нужный раздел и успешно заканчивают задачу».

11. Form Completion Rate

Форма может получать много открытий и мало отправок. Поэтому отдельно полезно измерять: Form Completion Rate = успешно отправленные формы / начатые формы Например: 300 пользователей открыли форму. 200 начали вводить данные. 70 отправили. Если считать только переходы к форме, проблема будет незаметна. Но funnel показывает: 300 → 200 → 70 Значит, значительная часть пользователей теряется внутри формы. Причиной могут быть:

• слишком большое количество полей;
• непонятные ошибки;
• обязательный телефон;
• неудобный mobile UI;
• технический сбой;
• неясная политика обработки данных.

После упрощения формы можно сравнить completion rate повторно. SEO и доступность

12. SEO Visibility

Для сайта, который должен получать органический трафик, важно измерять поисковую видимость. Можно смотреть на:

• количество страниц в индексе;
• позиции по целевым запросам;
• показы;
• органические переходы;
• CTR поисковой выдачи;
• долю целевых кластеров запросов.

SEO Visibility особенно полезна при:

• миграции сайта;
• redesign;
• изменении URL;
• смене CMS;
• переработке rendering.

Новый сайт может выглядеть лучше и одновременно потерять часть органического трафика, если при релизе были нарушены:

• redirects;
• canonical;
• sitemap;
• metadata;
• internal linking.

Тогда «новый дизайн» фактически ухудшил продукт.

13. Accessibility

Доступность тоже можно измерять. Например, проверять:

• keyboard navigation;
• contrast;
• labels форм;
• alt-тексты;
• semantic HTML;
• focus states;
• ошибки автоматических accessibility-проверок.

Accessibility полезна не только отдельным группам пользователей. Правильная семантика и понятное управление часто улучшают интерфейс вообще. Хорошо спроектированная форма удобнее:

• человеку;
• screen reader;
• автоматическим тестам;
• иногда поисковому роботу.

Поэтому accessibility можно рассматривать как один из признаков инженерного качества интерфейса. Engineering Пользователь не видит CI/CD, тесты или MTTR. Но именно они определяют, насколько быстро и безопасно продукт будет развиваться завтра.

14. Deployment Frequency

Deployment Frequency показывает, как часто команда способна безопасно выпускать изменения. Допустим, в одном проекте релиз происходит: раз в два месяца. В другом: несколько раз в неделю. Большая частота сама по себе не означает лучшее качество. Но если бизнес не может выпустить маленькое изменение без подготовки большого релиза, это часто говорит о дорогом процессе разработки. На Deployment Frequency влияют:

• CI/CD;
• тесты;
• архитектура;
• code review;
• автоматизация;
• качество окружений.

Для бизнеса эта метрика означает скорость реакции. Насколько быстро можно:

• исправить ошибку;
• изменить оффер;
• добавить функцию;
• проверить гипотезу.

15. MTTR и Defect Rate

Здесь полезно смотреть сразу на две связанные характеристики инженерного качества.

MTTR

Mean Time to Restore/Recovery показывает, насколько быстро команда восстанавливает систему после проблемы. Ошибка сама по себе неприятна. Но есть большая разница между: ошибка появилась и была исправлена через 20 минут; и: проблему обнаружили через два дня, а исправляли ещё неделю. Хороший продукт — не тот, где невозможно столкнуться с ошибкой. Это продукт, в котором проблемы:

• быстро обнаруживаются;
• локализуются;
• исправляются;
• не повторяются бесконечно.

Defect Rate

Defect Rate помогает отслеживать количество дефектов относительно объёма изменений, релизов или функциональности. Если после каждого крупного релиза команда получает десятки критических ошибок, скорость разработки может быть иллюзией. Поэтому полезно смотреть одновременно: как быстро выпускаем и сколько дефектов после этого создаём . 15 метрик в одной системе Получается следующая модель качества.

Деньги

1. Conversion Rate
2. Revenue
3. Lead Value

Скорость

1. TTFB
2. LCP
3. API Latency

Надёжность

1. Uptime
2. Error Rate

UX

1. Bounce Rate
2. Task Completion Rate
3. Form Completion Rate

SEO и доступность

1. SEO Visibility
2. Accessibility

Engineering

1. Deployment Frequency
2. MTTR / Defect Rate

Не каждому сайту нужны все показатели сразу. Для небольшого корпоративного сайта набор может быть компактнее. Для ecommerce, SaaS или платформы — значительно шире. Главное — выбрать метрики до начала изменений. Сначала метрика, потом изменение Представим задачу: Хотим переделать форму заявки. Плохой критерий успеха: Новая форма выглядит аккуратнее. Лучше заранее определить: Сейчас Form Completion Rate — 34% Conversion Rate — 2,1% Error Rate формы — 3,5% Цель увеличить завершение формы и снизить количество технических ошибок. После релиза показатели измеряются снова.

Тогда можно понять, действительно ли разработка улучшила продукт. То же самое работает для скорости. Не: Сделаем сайт быстрее. А: Уменьшим TTFB и LCP на ключевых landing pages и посмотрим, изменится ли конверсия. Так техническая метрика связывается с бизнес-результатом. Почему одна метрика может обманывать Представим: Conversion Rate вырос с 3% до 4%. Отлично? Не обязательно. Одновременно могло произойти следующее:

• средний Lead Value снизился;
• количество ошибок увеличилось;
• на mobile конверсия упала;
• пользователи стали отправлять больше некачественных заявок.

Поэтому важен набор связанных показателей. Другой пример: LCP стал значительно лучше. Но Conversion Rate не изменился. Это не обязательно означает, что оптимизация была бесполезной. Она могла:

• улучшить UX;
• снизить bounce;
• подготовить сайт к росту трафика;
• убрать техническое ограничение.

Но если целью проекта был именно рост заявок, нужно продолжать искать другие узкие места. Метрики нужны не для того, чтобы доказать успех. Они нужны, чтобы понять реальный результат. Baseline: без точки «до» невозможно измерить «после» Перед модернизацией сайта нужно сохранить исходное состояние. Например: МетрикаДоПослеConversion Rate2,4%3,1%Form Completion41%58%LCP4,1 сек2,3 секError Rate2,8%0,9%API Latency680 ms240 ms Тогда обсуждение становится предметным. Не: «Кажется, стало быстрее». А: «API отвечает почти в три раза быстрее».

Не: «Форма стала удобнее». А: «Доля пользователей, заканчивающих форму, выросла с 41% до 58%». Именно поэтому аналитика должна появляться до редизайна или модернизации, а не после. Метрики связывают бизнес и разработку У бизнеса и инженерной команды часто разный язык. Бизнес говорит: Нам нужно больше клиентов. Разработка: Нужно оптимизировать API. На первый взгляд это разные задачи. Но можно построить цепочку: медленный API ↓ форма долго отправляется ↓ пользователь повторно нажимает кнопку или уходит ↓ Completion Rate падает ↓ Conversion Rate уменьшается

↓ бизнес получает меньше лидов Теперь инженерная проблема имеет понятную бизнес-связь. И наоборот. Бизнес-задачу можно перевести в технические показатели. Хороший dashboard не должен содержать сто показателей Есть соблазн измерять всё. Но аналитика полезна только тогда, когда помогает принимать решения. Для конкретного сайта можно выбрать, например, восемь ключевых показателей: Бизнес

• Conversion Rate;
• Lead Value.

Performance

• LCP;
• API Latency.

Reliability

• Uptime;
• Error Rate.

UX

• Form Completion.

Engineering

• MTTR.

И уже вокруг них строить продуктовую работу. Каждое изменение должно отвечать хотя бы на один вопрос: Какую метрику мы пытаемся улучшить? Что измерять при модернизации сайта Перед проектом полезно сформировать три состояния.

До

Фиксируем baseline. Что происходит сейчас?

Цель

Определяем ожидаемый результат. Что именно мы хотим улучшить?

После

Повторно измеряем показатели. Что действительно изменилось? Получается простой цикл: measure → hypothesis → change → measure Например: Measure Mobile Conversion Rate значительно ниже desktop. Hypothesis Мобильная форма слишком сложная. Change Сокращаем форму и перерабатываем mobile UI. Measure Снова измеряем completion и conversion. Так дизайн и разработка превращаются в управляемый эксперимент. «Красивее» тоже может быть целью — но её нужно конкретизировать Это не означает, что визуальная сторона сайта неважна. Бренд, композиция, типографика и впечатление от интерфейса влияют на восприятие компании.

Но даже здесь полезно формулировать задачу точнее. Не: Сделать современнее. А: Повысить доверие новых посетителей и увеличить переход из страницы услуги в форму заявки. Тогда визуальное решение можно оценивать через поведение пользователей. Дизайн перестаёт быть только вопросом вкуса. Подход VERB В VERB мы стараемся начинать модернизацию не с вопроса: Что будем перерисовывать? А с вопроса: Что хотим улучшить и как это измерим? Для одного продукта главным показателем будет Conversion Rate. Для другого — скорость. Для третьего — Uptime.

Для внутренней системы — Task Completion. Для активно развивающегося продукта — Deployment Frequency и MTTR. После этого можно определить, где действительно нужна разработка:

• frontend;
• backend;
• инфраструктура;
• UX;
• CMS;
• аналитика;
• тесты.

Так проект получает критерий успеха ещё до первого изменения в коде. Главный тезис Слова: «Сайт стал лучше» ничего не значат, пока мы не договорились, что такое «лучше» . Лучше может означать: +25% к Conversion Rate −40% к API Latency −60% ошибок +18% к Form Completion меньше времени восстановления после сбоя больше органической видимости более частые и безопасные релизы Когда критерии определены заранее, сайт перестаёт быть набором субъективных впечатлений. Он становится измеримым цифровым продуктом.

Хотите понять качество своего сайта в цифрах?

VERB может провести аудит сайта и собрать baseline по ключевым направлениям:

• конверсия;
• скорость;
• Core Web Vitals;
• API;
• стабильность;
• формы;
• UX;
• SEO;
• accessibility;
• качество процесса разработки.

На выходе — не заключение «сайт хороший / плохой» , а карта измеримых показателей: что работает сейчас → где находится узкое место → какую метрику стоит улучшить → как проверить результат после изменений. Пришлите сайт на аудит — заменим субъективное «нравится / не нравится» измеримыми критериями качества.