Аудит exit points: снижаем отток на 20%

Наша компания занимается разработкой, поддержкой и обслуживанием сайтов любой сложности. От простых одностраничных сайтов до масштабных кластерных систем построенных на микро сервисах. Опыт разработчиков подтвержден сертификатами от вендоров.

Разработка и обслуживание любых видов сайтов:

Информационные сайты или веб-приложения
Сайты визитки, landing page, корпоративные сайты, онлайн каталоги, квиз, промо-сайты, блоги, новостные ресурсы, информационные порталы, форумы, агрегаторы
Сайты или веб-приложения электронной коммерции
Интернет-магазины, B2B-порталы, маркетплейсы, онлайн-обменники, кэшбэк-сайты, биржи, дропшиппинг-платформы, парсеры товаров
Веб-приложения для управления бизнес-процессами
CRM-системы, ERP-системы, корпоративные порталы, системы управления производством, парсеры информации
Сайты или веб-приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, конструкторы сайтов, порталы предоставления электронных услуг, видеохостинги, тематические порталы

Это лишь некоторые из технических типов сайтов, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента

Услуги, которые мы предлагаем
Показано 1 из 1Все 2062 услуг
Аудит exit points: снижаем отток на 20%
Средний
~2-3 дня
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1358
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    957
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1188
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    947

Представьте: интернет-магазин тратит миллионы на рекламу, но брошенных корзин — 70%. Мы видим это в GA4: exit rate на странице чекаута — 62%, хотя bounce rate — 30%. Bounce rate не показывает проблему, exit rate — да. Согласно Google Analytics Help Center, bounce rate — это процент сессий с просмотром только одной страницы. Задача — найти эти точки и устранить причины.

На одном проекте (интернет-магазин электроники) мы снизили exit rate на странице оформления заказа с 65% до 38% за месяц. Анализ показал, что пользователи уходили из-за непонятной формы ввода промокода и отсутствия способов оплаты. Внедрили инлайн-подсказки и добавили Apple Pay, Google Pay — отток сократился в 1,7 раза. Упущенная выручка от таких проблем может достигать 500 000 руб в месяц. В другом проекте (сервис доставки) аналогичная ситуация стоила 300 000 руб ежемесячно.

Почему exit rate анализ точнее bounce rate для выявления проблем?

Bounce rate — метрика первой страницы, она не показывает, где именно ломается воронка. Exit rate, напротив, указывает на конкретную страницу, с которой уходят пользователи, уже вовлечённые в контент. Exit rate анализ выявляет проблемы в 5 раз точнее bounce rate, что позволяет быстрее находить узкие места. Сравним:

Метрика Что измеряет Когда сигнал тревоги
Bounce rate Уход с первой страницы >80% (зависит от типа страницы)
Exit rate Уход с любой страницы после взаимодействия >50% на конверсионной странице

На практике exit rate выявляет проблемы в 5 раз точнее, чем bounce rate, потому что показывает, где именно теряются потенциальные клиенты. В одном из кейсов для интернет-магазина одежды анализ exit rate помог сократить потери на 20%, что привело к существенному росту прибыли.

Классификация exit rate: норма vs аномалия

Не каждый высокий exit rate — проблема. Разберём на примерах:

Страница Exit Rate Оценка
/thank-you 95% Норма (конверсия завершена)
/contacts 70% Норма (пользователь нашёл контакты)
/checkout/step-2 60% Аномалия (брошенный чекаут)
/pricing 50% Требует анализа

Мы классифицируем страницы с помощью скрипта:

def classify_exit_pages(pages_with_exit_rate):
    for page in pages_with_exit_rate:
        # Нормальные конечные страницы
        if any(p in page['url'] for p in ['thank-you', 'success', 'confirmation']):
            page['exit_expected'] = True
        # Страницы с контентом, требующие анализа
        elif page['exit_rate'] > 40 and page['is_funnel_page']:
            page['exit_priority'] = 'HIGH'
        else:
            page['exit_expected'] = False

Анализ Exit Rate в GA4: готовый SQL-запрос

Для быстрого анализа используем Google Analytics 4 и BigQuery. Приводим запрос, который показывает топ страниц по exit rate:

-- BigQuery: топ страниц по exit rate
WITH page_views AS (
  SELECT
    user_pseudo_id,
    session_id,
    event_name,
    page_location,
    event_timestamp,
    LEAD(event_name) OVER (
      PARTITION BY user_pseudo_id, session_id
      ORDER BY event_timestamp
    ) AS next_event
  FROM `project.analytics.events_*`
  WHERE event_name = 'page_view'
),
exits AS (
  SELECT
    page_location,
    COUNT(*) AS page_views,
    SUM(CASE WHEN next_event IS NULL THEN 1 ELSE 0 END) AS exits
  FROM page_views
  GROUP BY page_location
)
SELECT
  page_location,
  page_views,
  exits,
  ROUND(exits * 100.0 / page_views, 1) AS exit_rate
FROM exits
WHERE page_views > 100
ORDER BY exit_rate DESC
LIMIT 50;

Пример: если страницу просмотрели 1000 раз, а покинули 300 раз, exit rate = 30%. Для страницы корзины это допустимо, для чекаута — аномалия.

Почему пользователи уходят с конкретных страниц?

Ответ кроется в поведенческих данных. Мы записываем сессии на exit-страницах и анализируем глубину скролла. Это помогает понять: пользователь не нашёл нужной информации или возникла техническая ошибка. В 80% кейсов проблема — либо плохая читаемость форм, либо медленная загрузка, либо неочевидный CTA.

// Hotjar/Clarity: фильтр по exit на конкретных страницах
// В дашборде: Recordings → Filter: Exit page = /checkout

// Microsoft Clarity API для программного анализа
fetch('https://api.clarity.ms/export/1.0/sessions', {
  method: 'POST',
  headers: { Authorization: `Bearer ${token}` },
  body: JSON.stringify({
    projectId: 'xxx',
    filters: [{
      field: 'exitPage',
      operator: 'contains',
      value: '/checkout'
    }],
    startDate: 'YYYY-MM-DD',
    endDate: 'YYYY-MM-DD'
  })
})
// Отслеживание глубины скролла при выходе
let maxScroll = 0
let lastScrollTime = Date.now()

window.addEventListener('scroll', () => {
  const scrollPercent = Math.round(
    (window.scrollY / (document.body.scrollHeight - window.innerHeight)) * 100
  )
  maxScroll = Math.max(maxScroll, scrollPercent)
  lastScrollTime = Date.now()
})

window.addEventListener('beforeunload', () => {
  gtag('event', 'exit_scroll_depth', {
    page_path: window.location.pathname,
    max_scroll_percent: maxScroll,
    time_on_page: Math.round((Date.now() - pageLoadTime) / 1000)
  })
})

Как удержать пользователя перед уходом?

Exit intent popup — один из способов. Срабатывает, когда курсор покидает окно браузера. Реализуем через JavaScript:

let exitIntentShown = false

document.addEventListener('mouseleave', (e) => {
  if (e.clientY <= 0 && !exitIntentShown) {
    exitIntentShown = true
    showExitPopup()

    gtag('event', 'exit_intent_triggered', {
      page_path: window.location.pathname
    })
  }
})

function showExitPopup() {
  document.getElementById('exit-popup').classList.remove('hidden')
}

Exit intent popup может удержать до 20% уходящих пользователей.

Что входит в работу

Мы предоставляем:

  • Отчёт с топ-50 exit pages и их классификацией
  • Путь пользователя до выхода (SQL-запросы готовы)
  • Рекомендации по каждому аномальному exit (дизайн, контент, технические ошибки)
  • Внедрение exit intent popup (по желанию)
  • Интеграция дополнительной аналитики (scroll depth, клики)

Процесс работы

  1. Аудит текущей аналитики: проверяем настройки GA4, корректность сбора данных.
  2. Сбор данных BigQuery: извлекаем exit rate по страницам и сегментам.
  3. Запись сессий: подключаем Hotjar/Clarity для просмотра поведения на exit-страницах.
  4. Глубинный анализ: выявляем причины ухода (айтрекинг, клики, скролл).
  5. Отчёт с рекомендациями: приоритезируем правки по эффекту.
  6. Внедрение (опционально): исправляем формы, CTA, exit popup.

Наши результаты и опыт

Более 5 лет работы в веб-аналитике и UX-оптимизации. За это время мы провели анализ exit points для 50+ проектов. Среднее снижение оттока — 20%. Мы гарантируем объективность данных и конкретные выводы. Закажите анализ exit points — получите отчёт через 2 дня и рекомендации по каждому аномальному выходу. Свяжитесь с нами для консультации.

Настройка веб-аналитики: GA4, GTM, Яндекс.Метрика и Amplitude

Мы часто видим: конверсия 1.2 %, трафик растёт, а конверсия стоит. Маркетолог смотрит в Google Analytics и говорит: «пользователи уходят с шага 2 оформления заказа». Разработчик открывает тот же шаг — ошибок нет, в Sentry тишина. Значит, дело не в JS-баге, а в UX или в кривых данных, которые показывает аналитика. Аналитика ломается незаметно: событие перестало трекаться после редеплоя — никто не заметил; GTM-тег стреляет дважды — данные задвоились; фильтр GA4 исключает бота, который на самом деле — реальный трафик с корпоративного прокси. Закажите аудит текущих тегов — мы найдём причину за неделю.

После правильной настройки экономия рекламного бюджета может достигать 150 000 ₽ в месяц — это реальный кейс интернет-магазина с 50 000 сессий в день, где дедупликация purchase вернула 20 % неверно приписанных конверсий.

Почему события GA4 дублируются и как это исправить?

Universal Analytics закрыт, его место заняла событийная модель GA4. В ней нет фиксированных хитов страниц и транзакций — только события с параметрами. Это гибче, но требует правильного дизайна событий.

Автоматические события GA4 собирает сам: page_view, scroll, click, session_start. Рекомендуемые события нужно реализовать самостоятельно: purchase, add_to_cart, begin_checkout, view_item. Google ожидает конкретную схему параметров — если передать product_id вместо item_id, данные попадут в GA4, но не в стандартные отчёты e-commerce. Кастомные события для специфики проекта: filter_applied, video_progress, form_step_completed. Кастомные параметры необходимо зарегистрировать в GA4 Admin → Custom definitions, иначе они не будут доступны в отчётах.

Частая ошибка — событие purchase с дублями. Причина: тег срабатывает на странице /thank-you, пользователь обновляет страницу — второй purchase уходит в GA4. Решение: на бэкенде генерируем уникальный transaction_id и передаём в событие. GA4 de-duplicates по нему (в теории — проверяйте через DebugView). Правильная атрибуция экономит до 20 % рекламного бюджета, который раньше уходил на неверно приписанные конверсии.

Как настроить data layer, чтобы не потерять данные?

GTM — инструмент для управления тегами без деплоя кода. Но «без кода» не значит «без архитектуры». Data Layer — основа всего. Передаём данные из приложения в GTM через dataLayer.push(). Структура: event + контекстные данные. Для e-commerce: перед открытием страницы продукта — push с данными товара. GTM-тег читает из dataLayer, не из DOM.

window.dataLayer = window.dataLayer || [];
dataLayer.push({
  event: 'view_item',
  ecommerce: {
    items: [{
      item_id: 'SKU-12345',
      item_name: 'Название товара',
      price: 1990.00,
      currency: 'RUB'
    }]
  }
});

Плохая практика: GTM-тег парсит DOM — ищет цену в span.price, название в h1. Это ломается при любом изменении верстки. Хорошая практика: всегда dataLayer. Используем Preview Mode для отладки и GTM Server-Side для чувствительных данных — отправка с сервера, не с браузера, обходит блокировщики рекламы, не теряет данные.

Как Яндекс.Метрика дополняет веб-аналитику?

Для российской аудитории Метрика обязательна — особенно Вебвизор. Запись сессии пользователя, который бросил корзину, часто даёт ответ быстрее, чем неделя анализа воронки. Цели в Метрике: событийные (через ym(COUNTER_ID, 'reachGoal', 'GOAL_NAME')) или автоматические (клик по кнопке, посещение страницы). Связка с CRM через Метрика Плюс — передача офлайн-конверсий. Наш опыт: в 8 из 10 проектов после настройки Метрики находили скрытые баги в UX, которые не показывали другие системы.

Что даёт product analytics в Amplitude?

Amplitude — продуктовый инструмент, в отличие от маркетинговых GA4 и Метрики. Он заточен под анализ поведения пользователей внутри продукта: воронки, ретеншн, user paths. Amplitude подходит для SaaS-продуктов, мобильных приложений и любых сервисов с зарегистрированными пользователями, где важно понять, как проходят онбординг, на каком шаге уходят, какие фичи используют чаще. Ключевые концепции: identify (связать анонимного пользователя с userId после авторизации), group (аккаунт в B2B SaaS), когорты для удержания. Amplitude Chart — воронка шагов за последние 30 дней с разбивкой по источнику.

Мониторинг качества данных

Аналитика без мониторинга — чёрный ящик. Настраиваем:

  • GA4 Realtime — проверяем после каждого деплоя, что ключевые события приходят
  • Alerting в GA4 — аномалия в количестве событий purchase (резкое падение = что-то сломалось)
  • GTM Preview в staging-окружении перед продакшеном
  • Ручные тесты воронок раз в неделю — просто пройти путь покупателя и проверить, что всё трекается

Что проверяем после каждого деплоя

  • Все ли рекомендуемые события присутствуют в DebugView
  • Нет ли задвоений (считаем количество purchase на 100 сессий)
  • Не изменилась ли структура dataLayer после обновления фронтенда

Что входит в работу

Компонент Описание
Аудит текущих тегов Проверка существующих GTM-тегов, dataLayer, дублей и ошибок
Дизайн событийной схемы Документация: список событий, параметры, триггеры
Настройка GA4 + GTM Создание конфигурации, тегов, Custom definitions
Яндекс.Метрика Установка счётчика, создание целей, настройка Вебвизора
Amplitude (опционально) Настройка клиентского и серверного SDK, когорты
QA и мониторинг Тестирование в Preview Mode, Alerting
Обучение и передача Доступы, инструкция по добавлению новых событий, консоль

Процесс и сроки

  1. Аудит текущих тегов и данных (2 дня)
  2. Дизайн событийной схемы (2 дня)
  3. Разработка Data Layer и настройка тегов (3–5 дней)
  4. QA в Preview Mode и на staging (2 дня)
  5. Деплой и настройка дашбордов (1 день)
Сценарий Срок
Базовая настройка GA4 + GTM 1 неделя
Полный e-commerce tracking + Метрика 2–3 недели
Server-side GTM + Amplitude 3–5 недель

Стоимость рассчитывается индивидуально. Получите консультацию по настройке веб-аналитики для вашего проекта — мы оценим объём работ за один день. Свяжитесь с нами, чтобы начать.

Wikipedia: Веб-аналитика — подробнее о методах и метриках. Официальная документация по событийной модели GA4 доступна в Google Analytics 4.