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