Аудит 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 виключає бота, який насправді — реальний трафік з корпоративного проксі. Замовте аудит поточних тегів — ми знайдемо причину за тиждень. Ми маємо понад 5 років досвіду в налаштуванні веб-аналітики для 100+ проєктів — гарантуємо прозорість та достовірність даних.

Після правильного налаштування економія рекламного бюджету може досягати значної суми щомісяця — це реальний кейс інтернет-магазину з 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: null,
      currency: null
    }]
  }
});

Погана практика: GTM-тег парсить DOM — шукає ціну в span.price, назву в h1. Це ламається при будь-якій зміні верстки. Хороша практика: завжди dataLayer. Використовуємо Preview Mode для налагодження та GTM Server-Side для чутливих даних — відправка з сервера, не з браузера, обходить блокувальники реклами, не втрачає дані. Server-side підхід у 2-3 рази надійніший за client-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 тижнів

Вартість розраховується індивідуально. Отримайте консультацію з налаштування веб-аналітики для вашого проєкту — ми оцінимо обсяг робіт за один день. Зв'яжіться з нами, щоб почати. Для точного розрахунку вартості залиште заявку — ми проаналізуємо ваш стек за 1 день.