Показатель отказов
Bounce rate
Также: BR
Показатель отказов (bounce rate, BR) — доля визитов или сессий, которые система веб-аналитики признала отказами по своим правилам. Он показывает результат измерения поведения, а смысл числа зависит от определения отказа, настроек и выбранной аудитории.
В Google Analytics 4, или GA4, отказ связан с отсутствием вовлечённой сессии [1]. У Яндекс Метрики другое определение [2]. Поэтому одинаковые проценты в двух отчётах ещё не означают одинаковые посещения.
Человек может быстро найти номер телефона и уйти довольным, а может долго искать нужную кнопку и ничего не добиться. Эти два учебных примера показывают, почему отказ нельзя читать как прямое признание посетителя «мне не понравилось». Сначала нужно понять, какое поведение программа зарегистрировала и как его классифицировала.
Кратко
- Знаменатель показателя — визиты или сессии выбранной группы, а не число людей или просмотров.
- В GA4 отказ противоположен вовлечению; достаточно одного из предусмотренных признаков, чтобы сессия стала вовлечённой.
- В Метрике для отказа одновременно нужны три условия, включая отсутствие служебного сигнала «неотказ».
- Общий процент рассчитывают из суммарных количеств, а не простым усреднением процентов строк.
- Снижение отказов может отражать изменение учёта; коммерческий результат проверяют отдельно.
Происхождение и история термина
Термин присутствует в словаре Web Analytics Association, утверждённом 16 августа 2007 года. В нём различались визит на одну страницу, которую могли просмотреть повторно, и визит ровно с одним просмотром — bounce. Для сайта в целом bounce rate обозначал долю визитов второго типа; для отдельной страницы знаменателем служило число входов на неё [11, с. 1, 29–31]. Это историческая фиксация значения, а не доказательство того, что термин впервые появился именно тогда.
Документированное различие хорошо видно между поколениями Google Analytics. В справке Universal Analytics, помеченной как устаревшая, отказ описан как сессия с одной страницей и единственным запросом к серверу аналитики. Там же объясняется, почему без следующего обращения длительность такой сессии получалась нулевой [7]. Это историческое правило прежнего продукта.
В GA4 используется другая основа — вовлечённые и невовлечённые сессии [1]. Следовательно, старый ряд Universal Analytics и новый ряд GA4 нельзя соединить в одну непрерывную историю только потому, что столбцы называются одинаково. Разница может возникнуть в определении, даже если страницы и посетители не изменились.
Для сравнения разных периодов сохраняют название системы, действовавшее правило отказа и настройки на дату отчёта. Тогда изменение методики можно отличить от изменения посещений.
Суть и механизм
Система сначала собирает наблюдения: просмотры, время и события. Событие — запись об отдельном взаимодействии или происшествии: например, в GA4 так измеряют загрузку страницы, щелчок по ссылке или сбой приложения [14]. Затем наблюдения объединяются в визиты или сессии и проверяются по правилу отказа. Итоговый процент зависит и от поведения человека, и от того, какие сведения дошли до аналитики.
Сессия — период взаимодействия пользователя с сайтом или приложением. В GA4 по умолчанию она завершается после тридцати минут неактивности; тайм-аут можно менять [3]. Тайм-аут завершения сессии и короткий таймер вовлечения решают разные задачи. Первый разделяет посещения, второй участвует в оценке поведения внутри них.
Посетитель и сессия тоже различаются. Один человек способен вернуться несколько раз; число таких посещений не равно числу людей. Google отдельно определяет показатели всех, активных, новых и вернувшихся пользователей [5]. Подстановка любого из них вместо числа сессий меняет смысл доли.
Как считается отказ в GA4
При стандартном временном пороге сессия вовлечена, если выполняется хотя бы одно условие: длительность больше десяти секунд, есть ключевое событие или зарегистрировано не менее двух просмотров страницы либо экрана. Остальные сессии относятся к отказам. При этом Google исключает события first_visit, first_open и session_start из расчёта вовлечённых сессий, даже если им назначен ключевой статус [1].
Ключевое событие — действие, которое владелец ресурса считает особенно важным для бизнеса и помечает соответствующим образом в GA4 [8]. Обычное событие и ключевое событие — разные статусы. Например, регистрация на мероприятие может быть важным результатом, тогда как технический сигнал загрузки сам по себе ничего не говорит об успехе посетителя.
Таймер вовлечённых сессий настраивается отдельно в веб-потоке [3]. Поэтому десять секунд следует читать как исходное правило из справки, а для конкретного ресурса проверять фактическую настройку. Наличие одного просмотра само по себе ещё не решает, был ли отказ.
Как считается отказ в Метрике
Официальная справка Яндекса требует одновременного выполнения трёх условий [2]:
- за визит зарегистрирован максимум один просмотр;
- длительность меньше настроенного порога, исходно — пятнадцать секунд;
- служебный сигнал «неотказ» не зарегистрирован.
Сигнал «неотказ» отправляется в браузере по истечении заданного времени. Яндекс предупреждает о задержках передачи и расхождениях времени: короткая зарегистрированная длительность иногда встречается у визита, который отказом не признан [2]. Поэтому попытка пересчитать все отказы только по столбцу секунд может дать другой результат.
Кроме автоматического сигнала, разработчик может сообщить системе о неотказном визите методом notBounce [6]. Это отдельный механизм Метрики; правило о ключевых событиях GA4 к нему автоматически не относится.
| Вопрос | GA4 | Яндекс Метрика |
|---|---|---|
| Как устроено правило? | Отказ — сессия без признаков вовлечения [1] | Нужно одновременное выполнение всех трёх условий справки [2] |
| Что проверить в настройках? | Таймер вовлечения и ключевые события [3, 8] | Порог времени и передачу «неотказа» [2, 6] |
| Что означают два просмотра? | Это один из самостоятельных признаков вовлечения [1] | Условие «максимум один просмотр» уже не выполнено [2] |
Виды и классификации
Отказы можно анализировать для сайта целиком, страниц входа, источников трафика или устройств. Это редакционные способы группировки посещений, а не несколько официальных разновидностей BR. Меняется группа посещений, к которой применена доля.
Страница входа — первая просмотренная страница сессии. В отчёте GA4 Landing page она определяется по первому просмотру и относится к сессии: один пользователь может начать разные сессии с разных страниц [9]. Для анализа поведения после перехода из поиска выбирают сессии, начавшиеся на нужной странице. Все её просмотры включают и тех, кто пришёл на неё позже внутри сессии; это уже другая группа.
Сегмент — отобранная часть трафика за определённый период: такое понимание сегментированного анализа дано, например, в словаре WAA [11, с. 4]. Для BR здесь выбирают именно группу визитов, чтобы числитель и знаменатель относились к посещениям. Например, можно сравнить входы с телефона и компьютера на страницы одного назначения. Если в одну группу попали короткие справки, а в другую — оформление заказа, разницу трудно объяснять только устройством: вместе с ним изменена задача.
Наконец, различаются доля и количество отказов. Количество помогает оценить масштаб наблюдаемого поведения. Доля позволяет сопоставить его с объёмом посещений. Одно число без другого скрывает важную часть картины.
Как измерить: формула и знаменатель
Для GA4 и Метрики, когда выбрана одна согласованная группа посещений:
где B — число посещений, отнесённых к отказам, а S — все учтённые посещения той же группы и периода. Оба числа выражаются в визитах или сессиях; результат — в процентах. При S=0 доля не определяется: отсутствие посещений не означает нулевую отказность.
В GA4 формулу можно записать через число вовлечённых сессий E: B = S − E. Это соответствует определению bounceRate в Google Analytics Data API — программном интерфейсе получения отчётов [4]. Разность имеет смысл, когда обе величины относятся к той же группе сессий и периоду.
Учебный пример. За неделю учтены тысяча сессий, из них триста признаны отказами. Получается 300 / 1000 × 100% = 30%. Если на следующей неделе было сто пятьдесят отказов из пятисот сессий, доля снова равна тридцати процентам. Количество сократилось вдвое, а доля осталась прежней.
Предположим, первую тысячу сессий создали семьсот пользователей. Деление трёхсот отказов на семьсот людей даст приблизительно сорок три процента, но это уже не BR. Числитель описывает посещения, а знаменатель — другую единицу; возвращающиеся люди участвуют в таком смешении неодинаково.
Почему проценты строк нельзя просто усреднять
Пусть два источника полностью делят ту же неделю и не пересекаются:
| Источник | Сессии | Отказы | BR |
|---|---|---|---|
| Поиск | 800 | 160 | 20% |
| Рассылка | 200 | 140 | 70% |
| Всего | 1000 | 300 | 30% |
Простое среднее (20% + 70%) / 2 = 45% неверно для всего трафика: оно даёт источникам одинаковый вес, хотя посещений из поиска вчетверо больше. Общий показатель равен (160 + 140) / (800 + 200) × 100% = 30%.
Сложение допустимо потому, что группы в примере не пересекаются и вместе покрывают весь набор. Если один визит входит сразу в несколько выбранных сегментов, сумма строк повторно учтёт его. Тогда общий результат нужно брать для объединённой группы без повторов.
В другом учебном периоде поиск дал двести сессий и сорок отказов, а рассылка — восемьсот и пятьсот шестьдесят. Внутри источников сохранились двадцать и семьдесят процентов, но общий BR стал шестьюдесятью процентами. Изменился состав трафика. Утверждение «все страницы стали хуже» из этих данных не следует.
Как не перепутать долю с процентом
API GA4 возвращает bounceRate как долю: 0,2761 означает 27,61% [4]. Для отчёта можно оставить долю и применить процентное форматирование либо явно умножить на сто и подписать готовое число процентов. Одновременное применение двух способов увеличит отображаемое значение в сто раз.
При переносе данных полезно сохранять исходную величину рядом с показанным числом. Это позволяет отличить изменение метрики от ошибки оформления, не объясняя её поведением аудитории.
Как применяется на практике
Учебный пример различия систем. Предположим, обе системы зарегистрировали посещение длительностью двенадцать секунд с одним просмотром. Ключевого события, учитываемого GA4 при определении вовлечения, нет; Метрика не получила сигнал «неотказ». Пороги исходные: десять и пятнадцать секунд соответственно [1, 2].
В GA4 проверка даёт: двенадцать больше десяти — да; ключевое событие — нет; два просмотра — нет. Достаточно первого ответа «да», поэтому сессия вовлечена и не является отказом. В Метрике: максимум один просмотр — да; двенадцать меньше пятнадцати — да; «неотказ» отсутствует — да. Все три условия выполнены, поэтому визит является отказом. Это применение опубликованных определений к заданным наблюдениям, а не испытание реальных счётчиков.
Слова «хотя бы одно» и «одновременно» здесь решают результат. Если в этом же примере Метрика зарегистрирует «неотказ», третье условие перестанет выполняться и отказа не будет, несмотря на один просмотр и короткое время [2]. Временные границы тоже различаются: по профильному правилу GA4 требуется больше исходных десяти секунд, а по правилу Метрики — меньше пятнадцати для отказа [1, 2]. В сравнении нужно знать зарегистрированное время и действующие настройки, а не округлённое число секунд на экране.
Следовательно, переводного коэффициента между двумя процентами из такого примера не получится. Для пересчёта нужны сведения о распределении посещений и всех условиях классификации. Одинаковый общий объём трафика этих сведений не даёт. В реальном сравнении отдельно проверяют, совпадают ли границы посещений и полученные каждой системой события: учебное предположение об одинаковых записях само по себе этого не гарантирует.
Различие не ограничивается этими двумя платформами. В Adobe Analytics показатель строится как отношение Bounces к Entries — входам на страницу. Отказом считается визит ровно с одним обращением к аналитике; просмотр вместе с отдельным обращением отслеживания ссылки уже не считается отказом [12, 13]. Поэтому правило «два просмотра или время» нельзя переносить из GA4 в любой отчёт с названием bounce rate.
Для страницы расписания задача может состоять в быстром получении ответа. Для формы заявки важнее успешная отправка. Это разные учебные задачи, и проверка должна связывать отказы с конкретным результатом страницы. Даже верно измеренный BR не сообщает, прочитан ли ответ и состоялась ли заявка.
Практический разбор лучше начинать с понятной группы: одного назначения страниц, сходных источников и устройств. Затем рядом с отказами рассматривают данные о нужном действии. Если выросли отказы на мобильной форме, а завершений формы стало меньше, появляется проверяемая гипотеза о затруднении; причина ещё не установлена.
Как проверить изменение показателя
Ниже — редакционная процедура исследования, а не функция конкретной платформы. Сначала сохраняют описание измерения: систему, идентификатор ресурса или счётчика, даты и часовой пояс, группу посещений, настройки времени и перечень значимых событий. Оно позволяет понять, сравниваются ли одинаковые условия.
Далее проверяют регистрацию действий на выбранном сайте. Короткое посещение, переход на вторую страницу и выполнение нужного действия — разные сценарии. В каждом случае важно увидеть фактическую передачу данных, а не только движение курсора или нажатие кнопки. Отсутствие записи может означать проблему сбора, а не отсутствие поведения.
После обновления аналитики проверяют границу изменения. Назначение события ключевым влияет на последующие отчёты GA4 и не изменяет исторические данные [4]. Если после такой даты BR изменился, сначала нужно оценить влияние новой классификации. Сравнение с прежним периодом без этой оговорки смешивает разные способы измерения.
Отдельно проверяют посещения, которые могли получить лишний просмотр из-за ошибки регистрации. Если система действительно учла искусственный второй просмотр в том же посещении, GA4 получает самостоятельный признак вовлечения, а Метрика теряет необходимое условие отказа — максимум один просмотр [1, 2]. Сам по себе такой сигнал не доказывает, что человек перешёл дальше или прочитал больше.
Учебный пример ошибки учёта. Пусть зарегистрированы восемь секунд, один просмотр, нет учитываемого ключевого события GA4 и нет «неотказа» Метрики; пороги исходные. В GA4 отсутствуют все три признака вовлечения, а в Метрике выполнены все три условия отказа. Теперь ошибочно добавим второй учтённый просмотр, сохранив остальные данные. В GA4 выполнится критерий двух просмотров, а в Метрике нарушится ограничение по их числу: обе системы перестанут считать посещение отказом. Человек в условиях примера ничего дополнительно не сделал.
На долю влияет лишь переклассификация посещений, которые прежде были отказами. Если до лишнего просмотра сессия GA4 уже была вовлечённой по времени или ключевому событию, её классификация не изменится. При неизменном общем числе посещений доля может снизиться, если хотя бы один отказ исчезнет из числителя; величина снижения зависит от числа таких случаев. Это логическое следствие правил, а не измеренный эффект ошибки на конкретном сайте.
Для содержательной гипотезы требуется другое подтверждение. Если подозревается неудобная форма, её проходят на нужных устройствах и проверяют ошибки, отправку и связанные события. Найденный дефект объясняет возможный механизм затруднения, но сам по себе не определяет, какую долю изменения BR вызвал именно он.
При малом числе посещений рядом с процентом особенно нужны количества. Один отказ из двух и пятьдесят из ста дают одинаковые пятьдесят процентов. Масштаб наблюдений различается; ни одна из этих долей сама по себе не задаёт надёжность вывода о будущем поведении.
Ошибки, ограничения и спорные вопросы
Первая ошибка — называть любой выход отказом. В GA4 выход (Exits) учитывается на странице или экране, где произошло последнее событие сессии [10]. Это место завершения зарегистрированной последовательности, а отказ — классификация всей сессии по условиям вовлечения [1]. Например, в учебном маршруте «каталог → товар → подтверждение заказа» выход приходится на последнюю страницу, но сессия с тремя просмотрами вовлечена по правилу GA4 [1, 10].
Вторая — назначать «хороший процент» без описания задачи. Прежде чем использовать внешний ориентир, нужно установить, той ли системой он измерен, при каких настройках и для каких посещений. Иначе сравниваются разные определения и аудитории.
Третья — считать снижение отказов доказательством роста продаж. Для проверки продаж нужны сведения о заказах и их результате. Техническое событие, которому присвоен важный статус, не создаёт оплату; улучшение показателя учёта не равнозначно изменению экономики.
Четвёртая — приписывать изменение новому дизайну по одному совпадению дат. Одновременно могли измениться источники, события и период наблюдения. Сопоставимые группы и проверка сценария помогают сузить объяснения, но причинный эффект требует отдельного исследования.
Наконец, не стоит делать показатель целью сам по себе. Массовая отправка «неотказа» или лишних просмотров меняет классификацию, а не решает задачу посетителя. Полезный вывод описывает наблюдение, предполагаемую причину и способ её проверить. Допустим и результат «данных недостаточно», если именно он следует из проверки.
Правовой аспект
Зарубежные счётчики и персональные данные. С 1 июля 2025 года часть 5 статьи 18 закона № 152-ФЗ «О персональных данных» (в редакции Федерального закона от 28.02.2025 № 23-ФЗ) не допускает при сборе персональных данных граждан России, в том числе в интернете, их запись, хранение и другие операции с использованием баз данных за пределами России. Счётчики вроде Google Analytics передают на зарубежные серверы IP-адреса и идентификаторы cookie, которые могут относиться к персональным данным; о трансграничной передаче, кроме того, заранее уведомляют Роскомнадзор (статья 12 того же закона). Нарушения влекут ответственность по статье 13.11 КоАП РФ. Использование такого счётчика на российском сайте требует юридической оценки; для сбора данных о посетителях из России применяют системы веб-аналитики с хранением данных в России, например Яндекс Метрику.
Частые вопросы
Одна страница всегда означает отказ?
Нет: важно всё правило системы. В частности, в GA4 остаются критерии времени и ключевого события [1].
Можно ли напрямую сравнить GA4 и Метрику?
Сначала нужно согласовать определения, настройки и группы. Совпадение названия и процентов не делает методики одинаковыми; рассмотренный учебный визит показывает причину расхождения.
Почему отказы изменились после настройки событий?
Возможно, изменился учёт действий. Это гипотеза для проверки кода, настроек и контрольных сценариев, а не готовое объяснение любого скачка.
Снижение BR доказывает, что посетителям стало удобнее?
Нет. Удобство проверяют по выполнению задачи и другим свидетельствам. BR показывает долю посещений, удовлетворивших техническому определению отказа.
Связанные термины
Источники
- Google. (n.d.). [GA4] Engagement rate and bounce rate. Analytics Help. https://support.google.com/analytics/answer/12195621?hl=en (дата обращения: 02.11.2026). ↑ а б в г д е ж з и к л
- Яндекс. Яндекс Метрика: оценка эффективности продвижения. Раздел «Когда визит считается отказом» // Справка Директа. Б. д. URL: https://yandex.ru/support/direct/ru/statistics/metrika (дата обращения: 02.11.2026). ↑ а б в г д е ж з и к
- Google. (n.d.). About Analytics sessions. Analytics Help. https://support.google.com/analytics/answer/9191807?hl=en (дата обращения: 02.11.2026). ↑ а б в
- Google. (n.d.). API dimensions and metrics: bounceRate, engagementRate, engagedSessions, keyEvents. Google Analytics Data API. https://developers.google.com/analytics/devguides/reporting/data/v1/api-schema (дата обращения: 02.11.2026). ↑ а б в
- Google. (n.d.). [GA4] Understand user metrics. Analytics Help. https://support.google.com/analytics/answer/12253918?hl=en (дата обращения: 02.11.2026). ↑
- Яндекс. notBounce // Справка Метрики: JavaScript API. Б. д. URL: https://yandex.ru/support/metrica/ru/objects/notbounce (дата обращения: 02.11.2026). ↑ а б
- Google. (n.d.). [UA] Bounce rate [Legacy]. Analytics Help. https://support.google.com/analytics/answer/1009409?hl=en (дата обращения: 02.11.2026). ↑
- Google. (n.d.). Key event. Analytics Help. https://support.google.com/analytics/answer/9355848 (дата обращения: 02.11.2026). ↑ а б
- Google. (n.d.). [GA4] Landing page report. Analytics Help. https://support.google.com/analytics/answer/12931766?hl=en (дата обращения: 02.11.2026). ↑
- Google. (n.d.). [GA4] Entrances and exits. Analytics Help. https://support.google.com/analytics/answer/11080047?hl=en (дата обращения: 02.11.2026). ↑ а б
- Burby, J., Brown, A., & WAA Standards Committee. (2007). Web analytics definitions (Version 4.0, approved August 16, 2007, pp. 1, 4, 29–31). Web Analytics Association. https://stuker.com/wp-content/uploads/import/i-2731fa96a2de23f5b57b1471f450b9d0-WAA-Standards-Analytics-Definitions-Volume-I-20070816.pdf (дата обращения: 02.11.2026; исторический документ, копия первичного PDF). ↑ а б
- Adobe. (2026, April 24). Bounce rate. Adobe Analytics. https://experienceleague.adobe.com/en/docs/analytics/components/metrics/bounce-rate (дата обращения: 02.11.2026). ↑
- Adobe. (2026, April 24). Bounces. Adobe Analytics. https://experienceleague.adobe.com/en/docs/analytics/components/metrics/bounces (дата обращения: 02.11.2026). ↑
- Google. (n.d.). About events. Analytics Help. https://support.google.com/analytics/answer/9322688?hl=en (дата обращения: 02.11.2026). ↑
Служебный блок
- Версия
- 5.0
- Факты проверены
- Подготовка
- Редакция Медиатрона
- Публикация
- утверждена владельцем издания 4 ноября 2026 г.
Редакция Медиатрона. Факты сверены с первоисточниками на дату проверки, публикация утверждена владельцем издания.
Нашли ошибку? info@mediatrone.ru