С какого вопроса начинается веб-аналитика
Посещаемость выросла, а обращений столько же: сайт стал работать хуже или на него пришли другие люди? Один график не ответит. Веб-аналитика связывает источник перехода, действия на страницах и нужный компании результат, чтобы выбрать следующее изменение и затем оценить его пользу. Я начинаю настройку с вопроса владельца, который допускает конкретное действие: почему заявки с мобильных телефонов доходят реже, какая страница привлекает покупателей определённой услуги, где теряются запросы на расчёт. Формулировка «хотим видеть всё» почти неизбежно заканчивается большим отчётом, который некому читать. Полезнее выбрать один участок пути клиента и договориться, какое наблюдение заставит команду изменить форму, содержание страницы или способ обработки обращения, причём возможность сделать это изменение должна быть у названного человека.
Для сайта услуг первой задачей может стать доставка запроса менеджеру. Интернет-магазину важнее разобрать цепочку от карточки товара до подтверждённого заказа. Информационный раздел оценивают по собственной задаче: прочтению инструкции, переходу к продукту, возвращению читателя. Нельзя требовать одинакового действия от всех страниц.
Сначала решение, затем показатели.
Вопрос превращается в проверку
Вопрос
Почему запросы с телефона не доходят до менеджера?
Наблюдение
Сравнить начало заполнения, успешную отправку и получение заявки.
Действие
Исправить обнаруженный разрыв и повторить проверку на том же пути.
Что именно считает система
Число просмотров описывает загрузки страниц, а визиты и посетители позволяют иначе оценить объём посещения сайта. Посетитель способен открыть несколько страниц и вернуться позже, поэтому числа не обязаны совпадать. Если руководитель называет любую из этих величин «трафиком», обсуждение результата быстро теряет точность.
В словаре Метрики визит описан как последовательность действий одного посетителя на одном счётчике; по умолчанию он завершается после 30 минут бездействия. Конверсия в этом же словаре — доля целевых визитов в общем числе визитов. Поэтому 20 достижений кнопки нельзя автоматически делить на число людей и называть полученное значение конверсией Метрики: сначала нужно убедиться, что сравниваются одинаковые единицы, ведь один человек может нажать кнопку несколько раз или выполнить действие в разных визитах.
Определения нужны рядом с отчётом. «Запрос» может означать нажатие кнопки, успешную передачу формы, новую запись в CRM или разговор с подходящим клиентом. Для владельца эти события выглядят близкими, а между ними возможны повторные попытки, тесты сотрудников и обращения не по адресу. Аналитик обязан показать, какой именно этап измерен. Название должно объяснять событие. Я выбираю «Успешный запрос расчёта» вместо общего «Лид», если система действительно подтверждает отправку. При этом удачное название ничего не гарантирует: доказательством служит воспроизведённый путь заявки и описание настройки.
Как собрать минимальный набор данных
Для первого разбора обычно достаточно источника перехода, страницы входа и одного основного действия. В Метрике отчёт «Источники, сводка» открывается через «Отчёты → Источники → Источники, сводка». Он показывает, откуда приходят посетители, и позволяет использовать выбранную цель для оценки целевых визитов.
Следующий слой добавляют под вопрос. Чтобы разбирать мобильную форму, нужен тип устройства; чтобы сравнить направления услуг, нужна страница или группа страниц; чтобы отделить рекламные объявления, нужны согласованные метки ссылок. Собирать длинный перечень параметров до появления задачи неудобно: названия расходятся между подрядчиками, половина полей пустует, а владелец не понимает, какую потерю объясняет каждое из них и какое решение можно принять по заполненным значениям.
Держите набор небольшим.
В учебном примере компании по ремонту оборудования достаточно четырёх событий: открытие страницы услуги, переход к запросу расчёта, успешная отправка и подтверждение получения менеджером. Последнее событие может храниться в CRM, а не в счётчике сайта. Отчёт должен честно показывать эту границу. Веб-аналитика заканчивается там, где заканчиваются доступные ей данные.
Минимальная карточка измерения
Событие
Успешный запрос расчёта по ремонту оборудования.
Условие
Сайт подтвердил приём данных; повторные попытки проверяются отдельно.
Разрез
Источник, страница услуги, устройство.
Проверка
Менеджер нашёл тестовый запрос и подтвердил его содержание.
Как проверить, что данные отражают действия клиента
После установки счётчика нужно пройти путь клиента с телефона и компьютера: заполнить форму, повторить отправку с ошибкой и найти полученное сообщение у менеджера. Затем сопоставьте каждое действие с событием в аналитике. От испытания должен остаться результат, который способен повторить другой сотрудник.
Здесь особенно опасно доверять слову «отправка». В описании цели «Отправка формы» Яндекс предупреждает, что по умолчанию может учитываться и безуспешная попытка, когда данные не прошли валидацию. После изменений HTML цель тоже способна работать некорректно. Если компания считает полученные запросы, попросите специалиста настроить и испытать событие успешного приёма, чтобы пустое обязательное поле или ошибка связи не выглядели в отчёте как обращение, за которое уже стоит платить рекламной системе.
Неудача требует отдельного испытания. Успешная тестовая заявка доказывает только один сценарий, а ошибка способна проявиться в другой форме или после выбора иной услуги. В протоколе нужны адрес страницы, устройство, время, ожидаемое событие и фактический результат. Персональные данные клиента для такого описания не нужны.
Небольшие расхождения между системами разбирают по этапам. Клик в рекламном кабинете ещё должен привести к загрузке страницы и работе счётчика; сам пользователь может закрыть вкладку раньше. Сначала найдите место потери, потом оценивайте её влияние. Бессмысленно менять текст объявления из-за технически сломанной страницы.
Как перейти от общего графика к причине
Отправная точка — страница, на которую пришёл человек. Отчёт «Страницы входа» находится в «Отчёты → Содержание» и учитывает визиты, начавшиеся с указанных страниц. Он помогает сравнивать первые страницы пути, а не все просмотры подряд.
Предположим, в учебном примере за месяц было 2 000 визитов и 40 целевых визитов: общая конверсия равна 2%. Внутри этого числа одна услуга получила 500 визитов и 25 целевых, другая — 1 500 и 15. Получаются 5% и 1%. Это собственный расчёт на условных данных, который показывает, насколько общий показатель скрывает различия между частями сайта, хотя сам по себе он ещё не объясняет причину разницы: услуги могут отличаться ценой, аудиторией, сроком решения и содержанием предложения.
Группы должны быть сопоставимы. Если на первую страницу пришли люди по названию компании, а на вторую — по широкому вопросу, победителя формы пока нет. Разделите наблюдения по источникам и устройствам, посмотрите содержание страниц и соответствие обещанию ссылки. Иногда причина низкой доли обращений находится до открытия формы. Одна разница — ещё гипотеза. Я бы сначала проверила отправку заявки на второй странице, затем разобрала качество запросов и только потом меняла весь первый экран. Такой порядок экономит работу: простая неполадка не требует нового дизайна, а другая потребность аудитории требует нового объяснения услуги.
Как из наблюдения получить полезное изменение
Из наблюдения должно следовать проверяемое действие. «Посетителям не нравится сайт» ничего не поручает команде. «На мобильной странице услуги кнопка запроса закрыта баннером; после его удаления сравним успешные отправки при сопоставимом составе визитов» задаёт и действие, и способ оценки.
Меняйте понятный участок.
Если одновременно переписать предложение, запустить новый канал и заменить форму, результат может улучшиться, но роль каждого изменения останется неизвестной. Для небольшой команды полезнее начать с одного разрыва, заранее назвать период наблюдения и отметить другие события: акцию, изменение цены, перебои связи. Когда данных мало, фиксируйте направление и границы вывода, а не объявляйте точный процент роста свойством нового решения, потому что несколько дополнительных обращений могут зависеть от состава аудитории или календаря, а не от кнопки.
Изменение иногда стоит принять без красивого прироста. Исправленная форма, которая раньше не принимала корректный телефон, устраняет подтверждённую ошибку. Для такого решения важнее воспроизводимая проверка, чем ожидание статистики за месяц. А вот спор о двух равноправных заголовках требует аккуратного сравнения и достаточных наблюдений.
Запись решения для команды
Нашли
Баннер перекрывает кнопку запроса на узком экране.
Поручили
Изменить положение баннера и проверить доступность кнопки.
Измеряем
Успешные отправки с мобильных устройств при сопоставимом трафике.
Ограничение
Параллельную акцию и изменения источников отмечаем в отчёте.
Какой отчёт нужен владельцу
Хороший отчёт помещает рядом наблюдение, объяснение и действие. В нём видны период, выбранная цель, единицы расчёта и существенные ограничения. Руководитель должен понять, что произошло с нужным участком пути клиента и кому поручено следующее изменение. Я оставляю в регулярном обсуждении немного показателей, но требую связи между ними: сколько было входов на выбранные страницы, сколько успешных обращений, какие из них дошли до обработки. Если продажи учитываются отдельно, аналитик так и пишет. Когда вся выручка компании делится на все посещения сайта без связи заказов с визитами, получается удобная цифра, но она не отвечает на вопрос о вкладе сайта, поскольку в числителе могут оказаться повторные продажи, звонки по старым контактам и заказы из других каналов.
Отчёту нужен владелец. Маркетолог разбирает источники и содержание, разработчик отвечает за исправность измерения, отдел продаж уточняет качество обращений. Руководитель выбирает приоритет и выделяет ресурс. Одному подрядчику трудно отвечать за весь путь, если он не видит получение и обработку заявки.
Рабочая запись: «Период — октябрь. Объект — мобильная страница ремонта. Событие — подтверждённый запрос расчёта. Наблюдение — после обновления формы часть тестов не доходит до менеджера. Решение — исправить отправку. Ответственный — разработчик; приёмку проводит маркетолог вместе с менеджером».
Что проверить перед первым управленческим решением
Для самопроверки достаточно проследить один вывод из последнего отчёта до исходного события. Понятно ли, какое действие засчитано, где оно проверено и почему сравниваются именно эти группы? Если ответ приходится угадывать по названию графика, принимать решение рано. Подрядчику предстоит показать успешный и неудачный сценарии, объяснить отличие целевого визита от числа достижений и найти обращение у получателя. Затем выберите одно изменение, которое команда способна выполнить, и зафиксируйте признак результата, не требуя от небольшого набора данных обещания будущей выручки: задача первого цикла состоит в том, чтобы получить достоверный сигнал и освоить способ разбора, который выдержит следующие изменения сайта и рекламных источников.
Первый шаг — один вопрос. Если настройка измерения и работа сайта требуют общего разбора, их можно включить в задачу для ШТАБ ИТ. Полезным результатом будет понятная связь между действием посетителя, записью в отчёте и решением ответственного сотрудника.
Источники и полезные ссылки
- Яндекс Метрика: термины и определения ↗
- Яндекс Метрика: Источники, сводка ↗
- Яндекс Метрика: Страницы входа ↗
- Яндекс Метрика: Отправка формы ↗
Интерфейсы и возможности сервисов могут меняться. Перед настройкой сверяйтесь с актуальной документацией.


