Hotjar, Clarity и аналоги: что видно когда смотришь как люди кликают по твоему сайту

Ты открываешь Google Analytics, видишь что конверсия на странице оплаты упала на четверть за неделю, и сидишь со скриншотами экрана как археолог. Цифры есть — а что именно пошло не так, неясно. Люди уходят с пятого шага. Почему? Кнопка не видна? Поле не заполняется? Они вообще доскролливают до неё?

Здесь и появляются Hotjar, Microsoft Clarity, PostHog Session Replay, FullStory, Smartlook и десяток аналогов. Это инструменты, которые записывают сессии пользователей и показывают тебе фильм: вот человек заходит, вот он водит мышкой, вот трижды кликает в пустое место, вот матерится и закрывает вкладку. Аналитика отвечает на вопрос «что произошло», запись сессий — «почему».

Главное, что нужно понять с самого начала: это не замена интервью, не замена A/B тестов и не серебряная пуля. Это микроскоп. Очень полезный, если знаешь куда смотреть, и совершенно бесполезный, если смотришь куда попало.

## Что вообще видно через эти инструменты

Все эти сервисы делают плюс-минус четыре вещи. Понимание набора важнее, чем выбор между логотипами.

### Записи сессий

Видеозапись движений мыши, кликов, скроллов, ввода в поля (с маскировкой чувствительных данных). Можно отсмотреть конкретного пользователя от входа до ухода. Это самая дорогая по времени механика — час реальных сессий смотрится час.

### Тепловые карты

Агрегат по куче пользователей: где кликали, докуда доскроллили, где двигалась мышь. Хорошо показывает усреднённую картину, плохо — конкретные сценарии.

### Карты кликов и rage-кликов

Отдельная категория: места, где люди бьют по элементу 3+ раза подряд, кликают в нерабочую зону, или резко двигают мышью туда-обратно. Это почти всегда сигнал «здесь что-то сломано или непонятно».

### События и воронки на их основе

Современные инструменты (Clarity, PostHog) умеют собирать кастомные события и сразу же показывать записи тех сессий, где событие произошло или, наоборот, не произошло. Это самое мощное применение — связка «метрика → конкретное видео».

## Зачем это дизайнеру, а не только аналитику

Аналитик ищет аномалии в цифрах. Дизайнер ищет причины в поведении. У нас разные вопросы.

• Почему люди не кликают на главную кнопку, хотя она единственная яркая?
• Доходит ли вообще пользователь до того блока, который мы три недели рисовали?
• Что человек делает между «открыл форму» и «отправил» — задумывается, ошибается, копирует откуда-то?
• Какие микро-фрустрации (rage-клики, скроллы туда-обратно) накапливаются за сессию?

На эти вопросы Mixpanel и GA не отвечают. А запись сессии отвечает за 30 секунд.

### Типичные сценарии, где это окупается

• Запустили редизайн флоу. Метрики не двигаются. Смотришь 15 записей и видишь, что половина людей не понимает новый toggle сверху.
• Падает конверсия в форме. Hotjar показывает, что люди вязнут на поле «телефон» — маска не принимает формат, который они вводят.
• Готовишься к ревью с продактом. Вместо «мне кажется, что блок ниже фолда лишний» приносишь скролл-карту: до него доходит хорошо если половина.
• Поддержка жалуется на одну и ту же проблему. Фильтруешь сессии по URL и видишь паттерн за 20 минут, а не за месяц переписки.

## Чего эти инструменты не делают (и за что их ругают)

Если ждать от записей сессий слишком многого, разочарование гарантировано. Несколько честных ограничений.

• Они не говорят, что пользователь думает. Видно действие, не мотивацию. Запись + интервью = понимание. Запись отдельно = гипотеза.
• Они смещают выборку. Бесплатные тарифы пишут не всех; некоторые блокируются адблоком и CSP; мобильные сессии записываются хуже. Это не репрезентативная социология.
• Они создают иллюзию работы. Можно три часа смотреть записи и не сделать ни одного вывода. Без гипотезы это сериал, а не исследование.
• Они создают приватностные риски. Если не настроить маскировку, в записи попадают пароли, адреса, паспорта и переписка. Это не «потенциальная проблема», это юридическая.

Короткий итог сегмента: запись сессий — это инструмент для проверки конкретных гипотез о поведении, а не способ «посмотреть, как там у нас дела». Дальше разберём, чем именно отличаются Hotjar, Clarity и остальные, как ставить их без вреда для приватности и как смотреть записи, чтобы не утонуть.

## Рабочий процесс: как смотреть, чтобы что-то понять

Запись сессии без гипотезы — это YouTube с плохим монтажом. Чтобы инструмент окупался, нужен повторяемый цикл: вопрос → фильтр → выборка → выводы → действие. Без любого из шагов вы либо смотрите случайные видео, либо собираете «инсайты», которые никто не применит.

### Шаг 1. Сформулируй вопрос до того, как открыл дашборд

Плохие формулировки: «посмотрим, как ведут себя пользователи на лендинге», «глянем записи за неделю». Это сериал, а не работа.

Хорошие формулировки:

• Почему конверсия в шаге «выбор тарифа» упала после релиза?
• Что делают пользователи, которые открыли калькулятор, но не отправили заявку?
• Доходят ли мобильные пользователи до второго блока с ценами?
• На каком поле формы регистрации люди останавливаются дольше 30 секунд?

Чем уже вопрос, тем быстрее найдётся ответ. Узкий вопрос задаёт фильтр.

### Шаг 2. Сегментируй до просмотра, а не во время

Если открыть «все сессии за неделю», утонешь. Базовые срезы, которые экономят часы.

• Устройство: мобайл / десктоп отдельно — поведение разное.
• Источник: платный трафик и органика ведут себя по-разному, и проблемы у них тоже разные.
• Длительность: сессии короче 10 секунд почти всегда мусор (отказ), 10-60 секунд — самые ценные для поиска фрустраций.
• Событие: дошёл до шага N, но не сделал N+1. Это основной рабочий фильтр.
• Rage-клики и u-turn скроллы: моментально показывают, где больно.

Правило, которое спасает день: один просмотр — один сегмент. Не смешивай.

### Шаг 3. Смотри маленькими батчами

10-15 записей по узкому фильтру дают паттерн. После пятой записи начинаешь видеть повторение, после десятой — уверенно формулировать гипотезу. Если после 15 записей паттерна нет — либо фильтр слишком широкий, либо проблемы нет в том месте, где ты её ищешь.

Запускай записи на 1.5x-2x, перематывай скучные участки, останавливайся на моментах колебания: задержка курсора, скролл туда-обратно, повторный клик. Именно там живёт фрустрация.

### Шаг 4. Фиксируй наблюдения, а не интерпретации

Разница важна. Наблюдение: «пользователь трижды кликнул по слову Pro, потом ушёл на FAQ». Интерпретация: «пользователю непонятен тариф Pro». Первое — факт, второе — гипотеза, которую ещё нужно проверить хотя бы на трёх других записях.

Заведи лёгкий лог: ссылка на сессию, тайм-код, что произошло, что предполагаешь. Через две недели этот лог станет основой для редизайна гораздо быстрее, чем память.

## Как применить это в макете

Записи полезны не только на пост-факторе, но и до того, как ты открыл Figma.

### Перед редизайном экрана

• Отсмотри 10-15 сессий старой версии того экрана, который будешь трогать.
• Выпиши места, где люди тормозят, кликают не туда, скроллят обратно.
• Сверь это со своим списком «что хочу улучшить». Половина пунктов отвалится как несущественные, появятся новые.

Без этого редизайн идёт от вкуса, а не от поведения. И когда продакт спросит «а почему ты переставил блоки», ответ «так чище» проигрывает ответу «вот 8 сессий, где люди пропускали этот блок».

### Во время работы над макетом

• Под рукой держи 2-3 типовые записи проблемного поведения. Каждый раз, когда добавляешь элемент, спрашивай: помогает ли это конкретно тем людям, что я только что видел?
• Скролл-карта подсказывает, где «горизонт». Контент ниже него работает только если у пользователя есть причина туда добраться.
• Карта кликов отвечает на вопрос «что они принимают за кликабельное». Если люди тыкают в иконку рядом с заголовком — она читается как кнопка, даже если ты её рисовал как декор.

### После релиза

• Поставь себе календарную задачу: через 3, 7 и 14 дней после релиза отсмотреть по 10 сессий нового флоу.
• Сравни наблюдения с предыдущим логом. Если старые проблемы ушли, а новых нет — релиз удался. Если ушли старые, появились другие — нормально, фиксируем и итерируем.

## Типичные ошибки, которые видно сразу

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

• Смотреть «всё подряд» по пятницам. Превращается в ритуал, выводов ноль. Лечится привязкой к гипотезе.
• Делать выводы по одной записи. Один пользователь — это анекдот, не паттерн. Минимум три повторения одного поведения подряд, иначе гипотеза слабая.
• Считать rage-клик доказательством бага. Иногда это просто нетерпеливый пользователь на медленном интернете. Смотри контекст вокруг клика, а не только сам клик.
• Игнорировать тех, кто справился. Очень полезно смотреть успешные сессии: видно, какой путь работает, и его стоит защищать в следующих итерациях.
• Презентовать запись как доказательство, а не как иллюстрацию. На ревью «вот видео, тут он мучается» убеждает, но это всё ещё n=1. Корректно: «вот паттерн на 12 сессиях, вот одна показательная запись».
• Не трогать настройки маскировки. Дефолты разные у разных инструментов, и часть из них пишет содержимое полей. Это нужно проверять руками на своём сайте до того, как включишь запись на проде.

## Вопросы для самопроверки перед просмотром

Короткий чеклист, который полезно прогонять прежде чем нажать play.

• У меня есть конкретный вопрос, на который я ищу ответ?
• Я выбрал один сегмент, а не «всех»?
• Я ограничил период (последние 7 дней лучше, чем «всё время»)?
• Я готов остановиться после 15 записей, если паттерн не складывается?
• Я знаю, куда запишу наблюдения?
• Я понимаю, какое действие я приму, если гипотеза подтвердится?

Последний пункт самый важный. Если ответ «не знаю» — лучше отложить просмотр и сначала договориться с командой, что вы сделаете с результатом. Иначе это очень дорогая форма прокрастинации.

Промежуточный итог: рабочий цикл — это вопрос, узкий сегмент, маленький батч, фиксация наблюдений, действие. Всё остальное — фон. Дальше посмотрим, чем именно различаются Hotjar, Clarity, PostHog и FullStory, и как выбрать инструмент, не переплачивая за функции, которыми вы не будете пользоваться.

## Продвинутые сценарии: когда обычного просмотра уже мало

Когда базовый цикл «вопрос → сегмент → батч → лог → действие» уже работает, появляются задачи, где простого пролистывания сессий недостаточно. Это не про новые кнопки в Hotjar, а про другие способы задавать вопросы данным.

### Сегмент по конкретному событию, а не по странице

Стандартная ошибка — смотреть «все сессии на /checkout». Полезнее — «сессии, где человек нажал Apply promo, но не дошёл до Pay». Почти все инструменты умеют фильтровать по последовательности событий: ты не ищешь экран, ты ищешь поведение. Дальше из этой выборки вытаскиваешь 10-15 записей — и это уже не «посмотрим что бывает», а проверка конкретной гипотезы.

### Сравнение двух сегментов параллельно

Полезный приём: одновременно держать два списка записей — те, кто конвертировался, и те, кто отвалился на том же шаге. Разница часто не в интерфейсе, а в контексте: новый трафик vs возвращающийся, мобайл vs десктоп, медленное соединение vs быстрое. Если ты этого не разделил, ты будешь чинить дизайн там, где сломана производительность.

### Связка с воронкой

Запись отвечает на «как», воронка — на «где и сколько». По отдельности они врут. Воронка показывает, что 40% уходят на втором шаге, но не объясняет почему. Записи показывают «он три раза кликнул в неактивное поле», но не говорят, насколько это массово. Рабочий порядок: сначала воронка сужает место поиска, потом записи объясняют причину, потом снова воронка — для проверки, что фикс сработал.

### Heatmap по сегменту, а не по всем

Карта кликов «по всем» почти всегда бесполезна — она усредняет новичков и опытных, и в итоге показывает «все кликают везде». Карта только по новым пользователям за последние 7 дней — уже инструмент. Если фильтр по сегменту недоступен на твоём тарифе, это серьёзная причина задуматься о смене инструмента, а не о смене дизайна.

## AI-фичи: где они реально помогают, а где мешают

Многие инструменты прикрутили автоматические саммари сессий и «выделение проблемных моментов». Относись к этому как к черновику стажёра: быстро, иногда полезно, но проверять руками обязательно.

### Где AI экономит время

• Кластеризация однотипных сессий: вместо 200 записей получаешь 6 групп по типу поведения и смотришь по 2-3 представителя из каждой.
• Транскрипт и поиск по голосу из записей с микрофоном (если у тебя есть модерируемые тесты в том же инструменте).
• Автотеги rage-кликов, dead-кликов, U-turn-скроллов — нормально как первый фильтр, плохо как финальный вердикт.

### Где AI врёт и куда не стоит его пускать

• Саммари «пользователь не понял форму» без указания таймкода. Это не наблюдение, это пересказ, на нём нельзя принимать решение.
• Автовыводы про «причину» отвала. Причину ты определяешь сам, потому что только ты знаешь контекст релиза, маркетинговой кампании и того, что вчера упал API.
• Любые цифры из AI-отчёта без ссылки на исходные сессии. Если нельзя кликнуть и пересмотреть — не цитируй на ревью.

Практический режим: AI отбирает кандидатов, человек смотрит и формулирует вывод. Наоборот — не работает.

## Как проверить, что выводы вообще качественные

Перед тем как идти с находкой к команде, прогони сам через короткий фильтр.

• Я видел паттерн минимум на 3 разных сессиях разных пользователей?
• Я проверил, что это не один и тот же человек в нескольких сессиях?
• Я знаю, на каком устройстве и в каком браузере это воспроизводится?
• Я отсмотрел хотя бы одну успешную сессию того же флоу для контраста?
• Я могу одной фразой описать наблюдение без слов «кажется» и «как будто»?
• Я отделил наблюдение («скроллит вверх-вниз 4 раза») от интерпретации («не находит цену»)?

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

## Как объяснять решение команде

Запись на ревью — мощный, но опасный инструмент. Одно видео мучающегося пользователя продавит любую дискуссию, даже если за ним нет данных.

### Формат, который работает

1. Сначала число: «на 14 из 30 просмотренных сессий новые пользователи делают X».
2. Потом одна короткая запись 30-60 секунд как иллюстрация, а не как доказательство.
3. Потом гипотеза и предлагаемое действие — отдельно, чтобы их можно было обсуждать.
4. Потом метрика, по которой будем понимать, помогло ли.

### Чего избегать на ревью

• Показывать запись без счётчика «сколько таких». Это манипуляция, даже если ненамеренная.
• Монтировать «нарезку страданий». Команда перестаёт верить через два раза.
• Приходить только с проблемой без предложенного шага. Записи без следующего шага копятся в Notion и обесценивают сам инструмент.
• Спорить с разработчиком в духе «вот же видно». Видно тебе, потому что ты отсмотрел 50 штук. Ему — нет. Дай контекст.

Хороший признак: после ревью команда не обсуждает запись, она обсуждает, какой вариант фикса дешевле проверить. Значит, ты донёс наблюдение, а не устроил кинопоказ.

Промежуточный итог сегмента: продвинутая работа с записями — это не больше просмотра, а более узкие сегменты, связка с воронкой, аккуратное использование AI как черновика и дисциплина при презентации находок. Дальше — сравнение конкретных инструментов и за что в них имеет смысл платить.

## За что в инструментах имеет смысл платить, а за что — нет

Когда дойдёт до выбора тарифа или смены инструмента, держи в голове, что цена обычно растёт не за «функции», а за объём трафика и срок хранения. Дальше — за фильтры и интеграции. Всё остальное чаще всего маркетинг.

### Платить стоит за

• Срок хранения записей хотя бы 30 дней, лучше 90. Меньше — не успеваешь связать поведение с релизом и с откликом из поддержки.
• Сегментацию по событиям и свойствам пользователя, а не только по URL и устройству.
• Сэмплирование, которое можно отключить или контролировать. Если инструмент молча выкидывает 80% сессий — твои выводы построены на огрызке.
• Нормальный экспорт: ссылки на конкретные сессии, которые не протухают через неделю.

### Платить не стоит за

• «AI-инсайты» как отдельный модуль. Если базовая аналитика слабая, AI поверх неё врёт красивее, не точнее.
• Бесконечные хитмапы по каждой странице. Хватает ключевых экранов воронки.
• Опросники внутри продукта, если у тебя уже есть отдельный инструмент для них. Дублирование тут ничего не даёт.

## Анти-паттерны, которые ломают всю работу с записями

Это вещи, которые на словах кажутся очевидными, а в командах встречаются постоянно.

• Смотреть записи «когда есть время». Без расписания инструмент превращается в дорогую подписку, которую никто не открывает.
• Один человек смотрит, остальные верят на слово. Через пару месяцев он становится единственным носителем знания о пользователях, и его выводы перестают перепроверять.
• Записи разработчику в личку с подписью «смотри, как всё плохо». Это не работа с данными, это эмоциональный шантаж.
• Собирать сессии «на всякий случай», без вопроса. Полный почтовый ящик, который ты никогда не разберёшь.
• Делать выводы по 2-3 сессиям, потому что они «очень показательные». Показательные сессии — это иллюстрация уже найденного паттерна, а не источник.
• Игнорировать согласие на запись и приватные поля. Один скандал с утёкшими данными карты — и инструмент отрубают целиком, вместе со всей пользой.

## Чеклист перед тем как внедрять инструмент

• Понятно, какой конкретный вопрос мы хотим закрывать записями в ближайший месяц.
• Есть человек, который отвечает за просмотр и шеринг находок, а не «команда вообще».
• В разметке скрыты поля с персональными данными, платёжкой, паролями.
• Согласие на запись соответствует местному закону и политике приватности.
• Воронка и ключевые события заведены до того, как накопится трафик, а не после.
• Решено, как долго храним сессии и кто имеет к ним доступ.
• В календаре есть повторяющийся слот на просмотр — хотя бы 60 минут в неделю.

## Вопросы для ревью процесса раз в квартал

Раз в три месяца честно ответь себе и команде:

• Какие решения за квартал мы реально приняли на основе записей? Назови три.
• Сколько раз мы открывали инструмент в среднем в неделю? Если меньше двух — он не работает.
• Сколько найденных проблем доехало до релиза, а сколько застряло в бэклоге?
• Какие сегменты пользователей мы ни разу не отсматривали? Почему — нет данных или нет интереса?
• Что из того, что мы «и так знали», подтвердилось записями, а что — нет? Второе важнее первого.
• Если завтра отключить инструмент, что мы потеряем конкретно? Если ответ размытый — пора менять процесс, а не тариф.

## Короткий практический итог

Записи и хитмапы — это не магия и не замена исследованиям. Это способ быстро увидеть, что человек делает руками, когда никто за ним не смотрит. Польза появляется только тогда, когда есть конкретный вопрос, узкий сегмент, регулярный слот в календаре и привычка отделять наблюдение от интерпретации. Всё остальное — фон, в котором легко утонуть и убедить себя, что ты «работаешь с данными», на самом деле просто смотря чужой экран.

Если из всей статьи остаётся одно действие — заведи на следующей неделе час под просмотр десяти сессий по одному конкретному флоу и принеси команде одно наблюдение в формате «число, запись, гипотеза, метрика». Дальше процесс сам подскажет, что докрутить.