Аналіз dead clicks: де інтерфейс втрачає користувачів
Користувач натискає картку товару, плашку тарифу або іконку в шапці — візуально це явний елемент керування: змінюється курсор, є підкреслення й стан при наведенні.
Але обробника натискання за ним немає, клік іде в батьківський контейнер або в перекривальний шар, і сторінка не реагує.
Причин у розмітці зазвичай три: посилання без адреси, кнопка в неактивному стані після асинхронного підвантаження даних і елемент, накритий прозорим шаром із високим рівнем накладення.
Для аналітики такі натискання — не нешкідливий шум, а системна проблема інтерфейсу.
Кліки по неклікабельних елементах реєструються як звичайна взаємодія й потрапляють у теплові карти, воронки та шлях користувача: зростає час до цільової дії, просідає конверсія кроків, а точки виходу зміщуються до елементів, які початково не були інтерактивними. Показники гірші за реальність, рішення щодо доопрацювання ухвалюються за викривленими даними.
Окрема складність — відрізнити клік у порожнечу від усвідомленої відмови: користувач міг натиснути, не дочекатися відповіді й піти, а міг просто передумати.
Тому розбір іде від зіставлення розмітки й обробників — які вузли виглядають клікабельними за стилями та семантикою, чи підписані вони на подію, чи не перехоплює натискання батьківський елемент.
Далі дивимося послідовність: чи був клік одразу після відрисовки блоку, до появи даних у ньому, і чи повторювався він на одному й тому самому вузлі в різних сесіях. Так знаходимо відповідь, чому не працює елемент, і стає видно, які dead clicks справжні.
Розбираємо, як це закривається: як відокремлювати їх від хибних спрацювань і що правити в першу чергу.
Що дає розбір кліків по неактивних елементах
Клік по неактивній зоні фіксується автоматично, але сам собою проблемою не є. Користувач може промахнутися повз кнопку, тапнути по тексту при інерційному скролі або повторно натиснути елемент, поки завантажувався перехід.
У Яндекс Метрика такі події збираються у звіт карти кліків, де поруч лежать справжні провали інтерфейсу й шум — завдання інженера відокремити одне від одного.
Перший вимірюваний ефект — частка підтверджених проблем інтерфейсу. Без фільтрації за координатами, розміром цілі та часом між кліком і зміною структури сторінки звіт показує сотні «гарячих» точок, із яких реально ламають сценарій одиниці.
Після налаштування вибірки підтверджується більша частина сигналів у звіті замість приблизно десятої частки — верстальник більше не витрачає зміну на розбір хибних спрацювань.
Другий ефект — час пошуку причини просідання конверсії на конкретному кроці. Коли розбір налагоджено, причина локалізується в межах робочого дня: видно, на якому екрані користувачі б'ють у неклікабельний банер, блок ціни або підпис під полем. Раніше на це йшов тиждень гіпотез і сліпих правок верстки.
Третій ефект — знятий клас хибних сигналів. Тап при скролі, клік по тексту всередині пов'язаного елемента, повторне натискання після вже спрацьованої навігації — усе це перестає потрапляти в задачі й перестає викривляти пріоритети.
Як наслідок зростає довіра команди до звітів: пріоритети в черзі робіт будуються на підтверджених даних, а не на суперечці «мені здається, тут незручно». Розбір кліків по неактивних зонах стає регулярною перевіркою перед релізом, а не разовою акцією після падіння конверсії.
Варіанти впровадження: ручна розмітка, правила, готові звіти
Вибір варіанта визначає, де міститься джерело правди про клік: у розмітці інтерфейсу, у правилах обробки подій або в готовому звіті. Від цього залежить, скільки ручної роботи йде на кожен новий елемент і як швидко звіт почне розходитися з реальним інтерфейсом. Нижче — чотири робочі альтернативи та їхні межі застосовності.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Ручна розмітка подій | Ключові сценарії — оформлення, оплата, заявка, де важлива точність прив'язки до бізнес-кроку | Кожен новий елемент потребує правки коду; при переробці верстки прив'язки губляться |
| Правила фільтрації за ознаками елемента | Великі інтерфейси з часто змінюваною версткою, потрібне охоплення без правок у кожному компоненті | Хибні спрацювання на нестандартних блоках; правила потрібно переглядати після оновлення інтерфейсу |
| Розмітка на рівні компонента | Бібліотека повторно використовуваних компонентів — описується один раз і працює на всіх сторінках | Не покриває сторонні вбудовані блоки та зовнішні віджети |
| Готові панелі звітів | Потрібен перший зріз у короткий термін, інтерфейс типовий | Жорстка модель подій: складені зони та власні бізнес-кроки так не описати |
На практиці варіанти комбінують: компонентна розмітка закриває основні сценарії, правила добирають динамічні блоки, а готова панель слугує вітриною для регулярного перегляду.
Обмеження кожного підходу фіксуємо до старту робіт — інакше за місяць звіт перестає відповідати на питання, чому користувач не дійшов до цільової дії.
Як будується робота: етапи від аудиту розмітки до передачі
Починаємо з інвентаризації того, що вже збирається на сайті: лічильники, цілі, запис сесій.
Частки кліків по неклікабельних елементах цих даних зазвичай вистачає, а зрозуміти, який саме елемент натиснуто, — ні: обробник висить на контейнері, а координати при адаптивній верстці з'їжджають. Тому перший крок — аудит розмітки, а не нові звіти.
- Аудит розмітки. Звіряємо шаблони: де елементи вже розпізнаються за атрибутами, а де — ні. Окремо позначаємо динамічні блоки, що змінюють селектор після підвантаження.
- Схема подій. Домовляємося, що вважаємо кліком по неклікабельному елементу: текст, порожня область картки, зображення всередині посилання. Фіксуємо поля події, щоб звіт не наповнювався сміттям.
- Налаштування правил. Правило прив'язуємо до стійкої ознаки елемента, а не до порядкового селектора. У dead clicks потрапляє лише натискання, яке не веде ні до переходу, ні до зміни стану.
- Перевірка на живому трафіку. Кілька днів на реальних відвідувачах, вибіркове ручне відтворення та звірка з автоматикою. Відсіюємо свайпи, інерційний скрол і випадкові дотики.
- Зведення за сторінками. Групуємо знахідки за шаблонами та елементами — правки йдуть від частоти, а не від відчуттів.
- Передача проєкту. Віддаємо схему подій, документацію щодо правил, доступи та інструкцію, як додати новий елемент без розробника. Навчаємо команду й фіксуємо перегляд розмітки при релізах.
Що залишається на руках: конфігурації, схеми, регламенти
Звітність щодо мертвих кліків живе довше, ніж сам проєкт: новий аналітик або підрядник має розібратися в ній без листування з нами. Тому передаємо не разове вивантаження, а робочий комплект — від розмітки до порядку дій при аномалії.
- Карта подій — перелік відстежуваних дій із точною ознакою елемента, типом події та відповідальним за розмітку. За нею видно, який клік вважається мертвим, а який — навігацією всередині інтерфейсу.
- Правила фільтрації подій — що відкидаємо до розрахунку: приховані та заблоковані елементи, службові кліки, дублі при повторній ініціалізації лічильника. Правила лежать поруч із кодом розмітки, а не в листуванні.
- Політики доступу до даних — ролі, області видимості та строки зберігання сирих логів. Окремо зафіксовано, що йде у звіт, а що залишається у сховищі й хто це бачить.
- Регламент перевірки звітів — періодичність звірки, допустиме відхилення за ключовими сценаріями та порядок дій при сплеску мертвих кліків після релізу.
- Документація щодо проєкту — архітектура збору, схема проходження даних та інструкція з підключення нових сторінок без правки ядра.
- Набір перевірок розмітки — тести на ключові сценарії, які ловлять розходження карти подій з інтерфейсом до публікації.
- Журнал змін — що і коли правило або подія змінювалися, з прив'язкою до релізів: відкат перестає бути здогадкою.
Комплект передаємо на ваш бік у робочих форматах — так звітність можна розвивати силами своєї команди або віддати іншому підряднику без перезбирання з нуля.
Кейс: прибрали хибні сигнали й повернули довіру до даних
Перед розбором аналітика приносила близько 1 800 сигналів про «мертві» кліки — натискання по неклікабельних елементах. Команда розбирала їх вибірково: до інтерфейсу доходила мала частина, а спірні випадки закривали формулюванням «схоже на шум».
Правки вносили за гіпотезами, і після релізу ніхто не міг сказати, чи проблема зникла, чи просто змістилася.
Ми розділили сигнали за типами (клік по тексту без посилання, по картинці в картці, по візуально активній, але неактивній кнопці), відсікли ботів і натискання з перекриттям елемента та зіставили решту з розміткою сторінок у Яндекс Метриці.
У звіт потрапляло лише те, що повторювалося в кількох користувачів на одному й тому самому елементі.
| Метрика | До | Після |
|---|---|---|
| Сигналів до розбору на тиждень | ~1 800 | ~240 |
| Частка підтверджених проблем інтерфейсу | 12% | 68% |
| Час на висновок про причини | 3–4 дні ручної звірки | 4 години |
Що підтвердилося, а що зняли
Підтвердилися три причини: неактивна кнопка додавання в кошик на картці, блок «поділитися» без посилання в мобільній версії та підказка у формі замовлення, яка виглядала як кнопка.
Зняли дві гіпотези — про верстку меню та про розмір області натискання: сигнали за ними давали боти й подвійні тапи.
Після цього продуктові команди перестали сперечатися про те, чиї дані правильні. Кожна правка в інтерфейс прив'язана до підтвердженої причини, а ефект видно за падінням сигналів на конкретному елементі.
Чим мертвий клік відрізняється від збою розмітки та хибної події?
Мертвий клік — це натискання, на яке інтерфейс не відповідає взагалі: обробник не прив'язаний, елемент декоративний або перекритий невидимим шаром. Користувач б'є по кнопці другий і третій раз, потім іде — і в записі сесії видно серію натискань без жодного відгуку.
Збій розмітки виглядає інакше: елемент працює, відгук є, але подія йде з неправильними даними — втрачено ідентифікатор кнопки, не передано номер кроку, обробник повішено на контейнер замість самої кнопки.
Дія у звіті є, а пов'язати її з конкретним сценарієм уже не можна: метрика бреше м'яко, і помічають це пізніше.
Хибна подія — третій випадок, коли обробник спрацьовує на службові дії користувача: програмні натискання, автофокус, відновлення форми після перезавантаження, повторне надсилання при поверненні назад. Тут натискань і надсилань більше, ніж реальних дій, а зростання показника виглядає як успіх.
Розрізнити випадки допомагають три ознаки: чи була візуальна реакція на натискання, чи пішов запит на сервер, чи збігається набір даних події з тим елементом, по якому натиснули. Перша ознака вказує на мертвий клік, дві інші відокремлюють збій розмітки від хибної події.
Достовірність вимірювань тримається на тому, що будь-яка система аналітики, включно з Яндекс Метрикою, фіксує лише надіслану подію, а не намір користувача.
Тому перед висновками ми звіряємо воронку із записами сесій і розміткою обробників — розходження в одному місці зазвичай означає, що частина натискань у вимірювання не потрапляє взагалі.
Часті сумніви: точність вимірювань і хибні спрацювання
Точність вимірювань залежить від налаштування, а не від самого інструмента знімання поведінки. Якщо вважати проблемою будь-який клік, що не привів до зміни екрана, у звіт потраплять хибні спрацювання: декоративні рамки, області з власними жестами, елементи із затримкою відповіді.
Тому фіксуються тип елемента, зона натискання і час відгуку, а натискання всередині активних областей віджетів із вибірки виключаються. Нижче — сумніви, які зазвичай виникають до старту.
Повільне завантаження не викривляє картину?
Поки блок ще відрисовується, натискання по майбутніх кнопках рахуються окремо й в основну статистику не йдуть — їх розбирають як показник швидкості відрисовки, а не як дефект інтерфейсу.
У нас уже стоїть своя розмітка подій — її доведеться викидати?
Ні. Робочі події залишаються опорними точками, а збір кліків по неклікабельних елементах підключається поруч і пов'язується з ними за ідентифікаторами блоків.
Що з персональних даних потрапляє у звіт?
Лише знеособлена техніка: тип елемента, зона натискання, час відгуку та ідентифікатор сесії. Текст, який людина вводить у поля, не читається, вміст форм не зберігається, прив'язки до людини й пристрою немає.
Чи доведеться правити код продукту і скільки це займе?
Основний код застосунку не змінюється — підключення йде окремим шаром. Пробний запуск на одному розділі займає кілька днів разом із перевіркою на хибні спрацювання, далі охоплення розширюємо ітераціями. Точкові правки потрібні лише там, де інтерфейс сам повідомляє про готовність блоку.
Обговоримо задачу: які дані потрібні для старту проєкту
Стартувати можна без повного доступу до інфраструктури й без вивантаження всієї історії — для первинної оцінки вистачає набору даних про поведінку на 2-3 ключових сценаріях.
Чим конкретніший вхід, тим точніша оцінка обсягу робіт: ми одразу бачимо, де вистачить налаштування розмітки, а де потрібна переробка верстки та логіки інтерфейсу.
- адреса ресурсу та список сторінок або сценаріїв, де кліки по неклікабельних елементах найпомітніші;
- доступ до системи веб-аналітики з правами на вивантаження звітів і побудову сегментів;
- схема поточної розмітки подій: які дії вже фіксуються і за якими правилами іменуються;
- вивантаження записів сесій за 2-4 тижні або приклади конкретних візитів, де поведінка виглядає дивно;
- опис інтерфейсних елементів, які виглядають клікабельними, але не реагують на натискання;
- обмеження проєкту: тестове середовище, правила роботи з персональними даними, вікна для викладення змін;
- контакт людини з боку замовника, яка підтверджує пріоритети й відповідає на питання щодо сценаріїв.
У відповідь ми повертаємо оцінку обсягу робіт за етапами, план впровадження з черговістю кроків і перелік метрик, за якими будемо вимірювати результат — частку покинутих спроб натискання, глибину проходження сценарію, кількість звернень до підтримки щодо неробочих кнопок.
Обговорити задачу можна з нашим інженером або керівником напряму: опишіть сценарій у двох абзацах і додайте те, що є зі списку вище, — повернемося з оцінкою та планом.
