Веб-аналитик креативного агентства Proximity Наталья Киселькова обозначила наиболее распространенные ошибки в проведении digital-кампаний, а также пути их избежания.
Сайт может выполнять разные функции в соответствии с задачами бизнеса. Однако независимо от его формата, будь то промосайт, конфигуратор для подбора автомобиля или контент-платформа, для большинства брендов он является ядром коммуникации, а также источником и накопителем подробной информации о пользователях.
Очень важно еще до запуска и даже до создания сайта продумать как его структуру, так и целевые показатели и проставить KPIs, чтобы после старта проекта получать полные и корректные данные. Задача digital-аналитика на этом этапе — не только настройка сбора информации, но и, прежде всего, понимание бизнес-задач проекта и бенчмарков, разработка соответствующей этим задачам карты событий и целей.
Занимаясь аналитикой эффективности сайтов наших клиентов, а также общаясь с коллегами, я обнаружила, что ошибки обычно имеют общий корень: аналитик «живет отдельно» от команды проекта. Его зовут, когда нужно получить данные, или когда уже «горит пожар», и далее следует работа над ошибками, которых можно было избежать.
Рассмотрим четыре наиболее распространенные ошибки:
Ошибка 1: «Да зачем нам веб-аналитик до старта кампании…»
Редко кто задумывается о том, что веб-аналитика начинается задолго до выгрузки данных и построения отчета. Чтобы бизнес получал нужные ответы, аналитик должен заранее задать нужные вопросы, понять задачи бизнеса и только после этого приступать к «настройке аналитики». В противном случае он действует вслепую.
Самый неудачный и распространённый сценарий: «сайт уже готов — рекламная кампания стартует завтра — зовем аналитика, пусть все настроит». Результат: все настройки сделаны «по наитию», информация вроде как собирается, но нужных данных нет, или они неполные, отслеживаемые цели «немного расходятся» с бизнес-задачами и прочее. Если проекту повезло, попался очень въедливый аналитик, он озадачится стратегически важными для бизнеса метриками, потратит время на их выяснение, настроит все под конкретный проект. Но данные за все это время, пока аналитик разбирается в проекте, будут безвозвратно потеряны.
Как избежать: подключать аналитика к проекту как можно раньше, брать его на все встречи, где обсуждаются цели и задачи проекта.
Ошибка 2: «Все события записываем в цели»
Крайне важно не только настроить сбор информации обо всех событиях на сайте, но и корректно выбрать те события, которые являются целями.
Широко распространена ситуация, когда никто не задумывается о том, что такое «цель на сайте», а что такое «просто взаимодействие»; какие события фиксировать как цели, а какие — нет. Это чревато тяжелыми последствиями: если сайт использует Google Analytics в качестве основного счетчика (а таких большинство), то очень быстро лимит в 20 целей заканчивается. И тогда исправить ситуацию будет катастрофически сложно, и в некоторых случаях это может привести к ошибкам в отчетах коллег, а в конечном счете — к принятию неверных решений.
Проекту повезло, если в Google Analytics настроены цели, которые фиксируют давно отсутствующие на сайте события, и, соответственно, имеют нулевые значения. Проекту совсем не повезло, если во всех 20-ти целях «сидят» активные события на сайте, потому что обычно новую цель записывают поверх какого-то незначимого события и в лучшем случае добавляют примечание.
Что происходит дальше? Ранее настроенные коллегами отчеты перестают собирать информацию корректно: под целью «А» (старой) на самом деле прячутся события «Б» (новые). Поэтому ретроспективный анализ данных усложняется с точки зрения временных затрат. Закрадывается много ошибок в интерпретации данных коллегами, если они пользуются веб-интерфейсом Google Analytics, потому что за прошедшие периоды они видят одно (заголовок), а скрывается за ним совершенно другое (событие).
Как избежать: чтобы закономерность действий и настроек была прозрачна и понятна для любого аналитика, который может войти в проект, после совместного обсуждения с клиентом целей и задач проекта необходимо создать отдельный документ «Конструктор событий» и фиксировать в нем логику настроек.
Ошибка 3: Непродуманная архитектура событий
Очень редко команда задумывается об архитектуре отслеживаемых на сайте событий до запуска сайта. Под архитектурой в этом контексте я имею в виду продуманную структуру и нейминг параметров (действий, категорий, ярлыков).
Событием в web-аналитике является действие пользователя на сайте, например, покупка билета, заказ карты, регистрация в личном кабинете.
Часто в проекте возникает хаос в данных: никто в отсутствие того, кто делал настройки, не понимает, что обозначают «эти странные непонятные названия» в данных по событиям.
Так, идентичные по смыслу действия в разных разделах сайта почему-то называют по-разному, или вдруг неожиданно меняют название действия. В довершение всего, количество групп событий на сайте (категорий) переваливает за сотню, хотя большинство из них по своей сути есть одно и то же. В конце концов, сам аналитик теряется в догадках, где в отчете найти действие, которое интересует менеджера, без проверки работы кода на сайте.
Представим, что клиент запросил выгрузку большого массива данных с сайта за длительный период для внутренней отчетности. И, как это часто бывает, информация нужна в срочном порядке. В ситуации хаоса в данных, мы, как минимум, потеряем огромное количество времени, а в случае, если сайт претерпевал изменения, возможно, даже не все удастся расшифровать. Поэтому только продуманная архитектура помогает быстро реагировать на любые запросы по предоставлению отчетности и данных с сайта.
Как избежать: создать и задокументировать архитектуру действий на сайте, дать событиям понятные названия, регулярно обновлять такой документ. Чтобы не плодить сотни групп (категорий) событий с идентичными действиями, нужно следовать определенной логике:
• Верхний уровень (категория) — отвечает на вопрос «что» (процесс, задача, которые выполняются в ходе действий посетителя сайта).
• Второй уровень (действие) — «что посетитель сайта делает» (кликает, отправляет форму, играет, смотрит видео
• Третий уровень (ярлык) — детали (идентификатор места, элемента и все прочее, что мы хотим знать дополнительно).
Важно заранее разбить все события по категориям так, чтобы связанные действия «жили» в одной категории. Например, регистрация на сайте: под общим названием категории «sign up» объединяем все возможные связанные с этим действия (клик по кнопке, открытие формы, ошибки заполнения и отправки, заполнение поля, отправка формы
Ошибка 4: Отсутствие единого подхода в разметке источников трафика
Часто на медийной части проекта работает сразу несколько команд, либо сам проект длительный, и его исполнители меняются. Если новая команда или сотрудник будут придумывать свою разметку источников и каналов трафика, кампаний
Как избежать: заранее продумать структуру разметки трафика и создать документ с правилами, в соответствии с которыми всегда размечается трафик.
Итак, «где-то в идеальном мире»:
Аналитик начинает работать на проекте задолго до его старта, еще на этапе предварительных встреч с клиентом. Заранее создаются важные документы, описывающие архитектуру действий на сайте, нейминг событий, а также правила разметки трафика.
Получайте обратную связь от вашего аналитика еще до запуска сайта. Поверьте, ему есть что предложить не только в рамках срочного отчета. Зовите аналитика на брифинг и обеспечьте его присутствие на каждом этапе проекта. Конечно, он должен участвовать и в прогнозировании показателей KPI’s сайта. Так вы получите диджитально-идеальную систему аналитической отчетности, которая позволит значительно оптимизировать работу на любом digital-проекте.