Яндекс.Метрика для дизайнера: как настроить аналитику интерфейса

Обычно аналитика появляется в проекте примерно так. Дизайнер закончил макеты, разработчики всё сверстали, продукт вышел. И тут кто-нибудь спрашивает: «А мы можем понять, сколько людей нажимает эту кнопку?»

И начинается. Какие события есть? Что вообще собирается? Как называется эта цель? Почему половина действий никак не размечена?

Хотя значительную часть этой работы можно продумать ещё до разработки. Я считаю, что аналитика должна быть продолжением пользовательского сценария. Если дизайнер понимает, что пользователь должен сделать, он уже может примерно понимать, что имеет смысл измерять.

Аналитика начинается не с Яндекс.Метрики

Самая распространённая ошибка — сначала открыть Метрику и начать создавать цели. Но цель сама по себе ничего не решает. Сначала нужно понять: какие действия пользователя важны для продукта.

Например, в интернет-магазине это может быть: поиск → фильтр → карточка товара → добавление в корзину → начало оформления → заказ. В SaaS: создание проекта → приглашение пользователя → настройка → сохранение → запуск. В MedTech: поиск врача → выбор клиники → выбор времени → запись → подтверждение.

И только после этого можно решить, какие действия нужно отправлять в аналитику. Получается простая цепочка:

Сценарий → действие → событие → цель → аналитика → вывод → изменение интерфейса.

А не наоборот.

Когда аналитикой не заморачиваются

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

Кажется: «потом посмотрим». А потом действительно наступает это самое «потом». И оказывается, что восстановить картину задним числом уже очень сложно.

Я сталкивался с ситуациями, когда нужного события просто не было. Нельзя было открыть отчёт и посмотреть: «вот столько пользователей сделали это действие, а столько — нет». Данные за прошлые периоды уже не содержали нужной детализации. И тогда приходилось собирать статистику периодами, например сравнивать отдельные трёхмесячные отрезки, смотреть доступные показатели и по косвенным сигналам пытаться восстановить происходящее.

Это намного сложнее, чем заранее договориться: что измеряем → как называем → где отправляем → зачем используем.

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

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

Что действительно стоит измерять

Не каждое нажатие пользователя обязательно превращать в отдельную цель. Например, пользователь кликнул по декоративной иконке. Можно технически зафиксировать этот клик. Но что мы потом будем делать с этой информацией?

Гораздо полезнее измерять действия, которые связаны с пользовательским сценарием. Например:

• отправка формы;
• начало оформления;
• добавление товара;
• применение фильтра;
• использование поиска;
• открытие определённого раздела;
• переход к следующему шагу;
• завершение регистрации;
• создание проекта;
• подтверждение действия.

То есть вопрос должен звучать не «что мы можем отследить?», а «что нам важно понимать о поведении пользователя?». Это две совершенно разные вещи.

Сначала сценарий, потом цели

Допустим, у нас есть форма заявки. Можно поставить одну цель form_submit и узнать, сколько людей успешно отправили форму. Но этого может быть недостаточно.

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

Поэтому для некоторых сценариев полезно выделять несколько ключевых событий:

form_open
form_start
form_error
form_submit

И тогда аналитика начинает показывать не просто количество отправок, а сам путь.

Как связать интерфейс с аналитикой

Здесь начинается интересная часть. Событие должно иметь понятный способ попасть из интерфейса в систему аналитики. Например, для CTA можно использовать отдельный атрибут:

<button
  type="button"
  data-ym-goal="checkout_start">
  Оформить заказ
</button>

Теперь у действия есть понятное имя checkout_start. А сам HTML остаётся читаемым. Для ссылки можно использовать тот же принцип:

<a
  href="/contacts/"
  data-ym-goal="contacts_open">
  Контакты
</a>

Для формы:

<form data-ym-goal="lead_form_submit">
  ...
</form>

Конкретный способ реализации зависит от того, как именно настроена передача событий в Метрику и реализован сайт. Но сама идея мне кажется важной: аналитическое событие должно быть связано со смыслом действия, а не с визуальным оформлением элемента.

Не называйте события по внешнему виду

Представим, что у нас есть синяя кнопка. Можно назвать событие blue_button_click. На первый взгляд всё понятно. Но через несколько месяцев дизайн изменился. Кнопка стала зелёной. А потом вообще превратилась в ссылку. Событие теперь называется неправильно.

Гораздо устойчивее назвать его checkout_start. Потому что пользователь по-прежнему начинает оформление заказа.

То же самое касается классов. Не стоит строить аналитику вокруг чего-то вроде button-blue-2 или main-btn-new. Визуальный класс описывает внешний вид или структуру. А аналитическое событие должно описывать действие пользователя.

Как я бы называл события

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

CTA

cta_click

Формы

form_open
form_start
form_submit
form_error

Поиск

search_start
search_result_click

Фильтры

filter_open
filter_apply

Товар

product_view
product_add_to_cart

Оформление

checkout_start
checkout_complete

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

А что делать, если элементов несколько?

Вот здесь начинается более интересная задача. Допустим, на странице интернет-магазина десять карточек товаров. У каждой есть кнопка «В корзину». Нам недостаточно знать только product_add_to_cart. Иногда нужно понимать, какой именно товар добавили.

В таком случае событие может передавать дополнительные параметры:

<button
  type="button"
  data-ym-goal="product_add_to_cart"
  data-product-id="12345">
  В корзину
</button>

Или можно передавать дополнительные данные другим способом — в зависимости от архитектуры сайта и настройки аналитики. Тогда одно событие может описывать множество одинаковых действий, но с разным контекстом.

Это особенно полезно для: товаров, тарифов, категорий, фильтров, ролей, способов оплаты, вариантов доставки.

Дизайнеру не нужен дашборд из 150 метрик

Есть ещё одна крайность. Иногда после настройки аналитики появляется огромное количество данных. События, цели, параметры, сегменты, отчёты. И в итоге никто не понимает, что с этим делать.

Для дизайнера важнее не количество метрик, а ответы на конкретные вопросы. Например:

• На какой шаг сценария пользователи чаще всего не доходят?
• Какие фильтры используют?
• Какие элементы интерфейса игнорируют?
• Где пользователи возвращаются назад?
• Какой CTA действительно приводит к следующему шагу?
• Где возникает много повторных действий?
• Какие сценарии чаще всего завершаются успешно?

Вот ради таких вопросов аналитика и нужна.

Яндекс.Метрика показывает не только цифры

Особенно полезно сочетать цели с другими инструментами Метрики. Например:

• карта кликов помогает понять, с какими элементами взаимодействуют;
• Вебвизор?Инструмент Метрики, который записывает реальные сессии пользователей. Позволяет увидеть, как человек двигается по интерфейсу — где останавливается, куда возвращается, что не замечает. позволяет посмотреть реальные пользовательские сессии;
• цели помогают измерять прохождение ключевых действий;
• сегменты позволяют сравнивать разные группы пользователей.

И тогда дизайнер получает возможность посмотреть на интерфейс уже не только глазами. Можно увидеть: «я думал, что пользователи нажимают сюда». А затем открыть данные и обнаружить: «нет. Они пытаются нажать вообще в другом месте».

Вот здесь аналитика становится действительно полезной для дизайна.

Аналитика может изменить дизайн

Допустим, мы спроектировали фильтры. На макете они выглядят очевидно. После запуска смотрим данные. Оказывается, пользователи часто открывают фильтр, но редко применяют его.

Тогда возникает вопрос: почему? Может быть: слишком много параметров, непонятные названия, неочевидная кнопка применения, отсутствие выбранных значений, слишком длинный сценарий, пользователь не понимает, что изменилось.

И вот здесь уже начинается работа дизайнера. Аналитика не говорит: «сделай кнопку зелёной». Она помогает увидеть проблемное место. А дальше дизайнер уже исследует причину и ищет решение.

В идеале аналитика появляется ещё в Figma

Мне нравится подход, когда о важных событиях начинают думать ещё во время проектирования. Например, есть экран каталога. В пользовательском сценарии мы заранее определяем: поиск → фильтр → карточка → добавление в корзину. И уже на этапе дизайна понятно, какие действия потенциально должны быть измеримыми.

То же самое можно делать со сложными продуктами: создание проекта → настройка → приглашение → сохранение → публикация. Или: выбор врача → дата → время → подтверждение → запись.

Получается, аналитика становится частью проектирования сценария. Не чем-то, что разработчики «прикрутят потом».

Хороший HTML тоже помогает аналитике

Есть ещё один момент, который часто недооценивают. Если интерфейс построен на понятной структуре, его проще анализировать и технически поддерживать. Семантические элементы <button>, <form>, <a> уже сообщают разработчику и браузеру, что это за элемент.

А дополнительные атрибуты могут описывать контекст аналитики. Получается понятное разделение:

• HTML → что это за элемент;
• CSS → как он выглядит;
• data-атрибут → какое действие или дополнительный контекст нужно передать.

Это намного устойчивее, чем пытаться определять смысл элемента по его цвету, классу или положению на странице.

Не превращайте аналитику в самоцель

Важно помнить и обратную сторону. Если начать измерять абсолютно всё, данные быстро перестанут помогать. Поэтому перед добавлением события я бы задавал три вопроса:

• Что именно мы хотим узнать?
• Как это связано с пользовательским сценарием?
• Что мы будем делать с результатом?

Если ответа нет, возможно, это событие вообще не нужно. Потому что аналитика ради аналитики только увеличивает количество данных. А нам нужны не данные сами по себе. Нам нужны решения, которые можно принимать на их основе.

В итоге

Хорошая аналитика начинается задолго до того, как пользователь нажмёт кнопку. Она начинается с понимания сценария:

что пользователь хочет сделать → какие действия совершает → что из этого важно измерять → какие события нужны → какие данные получаем → какие решения принимаем.

Яндекс.Метрика в этом случае становится не просто счётчиком посещений. Для дизайнера это ещё один способ увидеть продукт со стороны пользователя. Не только: «как выглядит этот экран?» Но и: «как люди действительно с ним взаимодействуют?»

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