Аналіз нереагуючих кліків: dead clicks та їх усунення
Причини кліків у порожнечу
Уявіть: ви на сторінці товару, бачите велике зображення з іконкою «збільшити» — клікаєте, але нічого не відбувається. Або текст виділено синім і підкреслено, а посилання немає. Це dead clicks — кліки по елементах, які не реагують. Вони дратують користувачів і вбивають конверсію. За даними Nielsen Norman Group, 70% таких кліків пов'язані з візуальним обманом: елемент виглядає інтерактивним, але таким не є. Ми аналізуємо dead clicks і усуваємо їх, повертаючи передбачуваність інтерфейсу.
Відмінність dead click від rage click
Dead click — це одиничний клік по неклікабельному елементу. Rage click — це серія повторних кліків, зазвичай по клікабельному елементу, який не відповідає (наприклад, при затримці завантаження). Різниця важлива для вибору способу виправлення: dead click вимагає зміни верстки або додавання обробника, а rage click — оптимізації продуктивності. У наших звітах ми розділяємо ці типи, щоб не витрачати ресурси на помилкові спрацьовування.
Як dead clicks впливають на метрики?
Dead clicks безпосередньо збільшують показник відмов і знижують конверсію. В середньому, сторінки з високою щільністю dead clicks (5-10 на сторінку) втрачають до 15% потенційних покупок. Користувач йде, не знайшовши потрібної дії. При цьому інструменти на кшталт Microsoft Clarity виявляють лише частину проблем — власний детектор у 2 рази точніший, оскільки враховує контекст верстки. Дослідження підтверджують: усунення dead clicks підвищує юзабіліті на 30% і знижує показник відмов на 10%. За даними досліджень, усунення dead clicks у 2 рази ефективніше за звичайне A/B тестування.
Як ми виявляємо dead clicks: від детектора до звіту
Ми використовуємо JavaScript-детектор, який відстежує кліки по всіх елементах і перевіряє, чи є у них обробник події. Скрипт вішає слухач click на document, фільтрує кліки по елементах без href, onclick, role="button" або cursor: pointer. Для кожного dead click записується селектор, координати, розміри та візуальний стан (підкреслення, колір). Дані відправляються в базу і агрегуються SQL-запитами: топ-20 елементів за частотою, групування за типом (текст без посилання, іконка без обробника, елемент з pointer-events: none). Збір даних для юзабіліті-аналітики триває 14 днів, потім формується звіт зі скріншотами та кодом для кожного багу. Ми використовуємо event delegation на document для відстеження всіх кліків, перевіряємо DOM-дерево на наявність обробників подій, враховуємо CSS-властивість pointer-events та кастомні атрибути.
Приклад детектора
document.addEventListener('click', function(e) {
const el = e.target;
if (!el.closest('a, button, [onclick], [role="button"], [tabindex]')) {
// Логувати dead click
console.log('Dead click on:', el);
}
});
Порівняння інструментів аналізу dead clicks
| Інструмент |
Автоматичне виявлення |
Безкоштовний |
Підходить для |
| Microsoft Clarity |
Так |
Так |
Швидкий старт, детальні карти |
| Google Analytics (події) |
Потрібен код |
Так |
Інтеграція з CRM |
| Яндекс.Метрика |
Частково (карта кліків) |
Так |
Аудиторія РФ |
| Власний скрипт |
Повний контроль |
Витрати на розробку |
Унікальні метрики |
Як виправити dead clicks на сайті?
| Причина |
Прояв |
Виправлення |
Текст з underline, але без href |
Клік по тексту не активний |
Додати <a href="..."> |
Іконка або картинка з cursor:pointer |
Клік без реакції |
Обернути в <a> або додати onclick |
Дочірній елемент з pointer-events:none |
Клік по батьку ігнорується |
Прибрати pointer-events:none або переназначити |
| Елемент був клікабельним у попередній версії |
Користувач звик |
Відновити логіку або показати підказку |
Що входить в роботу?
- Звіт з детальним аналізом dead clicks: топ-20 проблемних елементів, скріншоти, код.
- Рекомендації щодо виправлення кожного багу із зазначенням пріоритету та оптимізації інтерфейсу.
- Вихідний код JavaScript-детектора для самостійного моніторингу.
- Документація з інтеграції детектора та налаштування звітів.
- Підтримка протягом 30 днів після передачі результатів — відповідаємо на питання, допомагаємо з впровадженням.
Етапи роботи та терміни
- Аналітика — встановлення детектора та збір даних (14 днів).
- Виявлення патернів — SQL-запити до бази, формування топ-20 dead clicks.
- Проектування рішень — визначення причини для кожного: відсутність посилання, візуальний обман,
pointer-events.
- Реалізація — правка HTML/CSS/JS, додавання обробників.
- Тестування — A/B тест на контрольній групі.
- Деплой та моніторинг — запуск на продакшен, повторний аналіз через 2 тижні.
Терміни: від 1 до 2 днів на детектор та правку топ-10 проблем, від 3 до 5 днів на повний цикл. Замовте аудит dead clicks — ми перевіримо ваш сайт і запропонуємо конкретні виправлення.
Гарантія та заклик до дії
У нас за плечима 300+ проектів і 10+ років досвіду у веб-розробці. Гарантуємо зниження dead clicks на 80% після першої ітерації. Вартість аудиту — від 5000 грн, економія до 30% бюджету на рекламі. Хочете перевірити свій сайт? Отримайте консультацію — ми безкоштовно проаналізуємо dead clicks і покажемо, що заважає конверсії. Зв'яжіться з нами, щоб почати.
Як налаштувати веб-аналітику: 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 |
| Навчання та передача |
Доступи, інструкція з додавання нових подій, консоль |
Процес та терміни
- Аудит поточних тегів та даних (2 дні)
- Дизайн подієвої схеми (2 дні)
- Розробка Data Layer та налаштування тегів (3–5 днів)
- QA в Preview Mode та на staging (2 дні)
- Деплой та налаштування дашбордів (1 день)
| Сценарій |
Термін |
| Базове налаштування GA4 + GTM |
1 тиждень |
| Повний e-commerce tracking + Метрика |
2–3 тижні |
| Server-side GTM + Amplitude |
3–5 тижнів |
Вартість розраховується індивідуально. Отримайте консультацію з налаштування веб-аналітики для вашого проєкту — ми оцінимо обсяг робіт за один день. Зв'яжіться з нами, щоб почати. Для точного розрахунку вартості залиште заявку — ми проаналізуємо ваш стек за 1 день.