В статье мы рассмотрим десять самых распространённых ошибок и недочётов в аналитических системах клиентов, которые нам удалось выявить за многие годы работы и с которыми до сих пор продолжаем сталкиваться ежедневно.
Зачастую причины данных ошибок кроются в низкой аналитической культуре и недостаточном понимании роли аналитики в компании и мире digital в целом. Давайте поговорим о них детально и разберём, как этих ошибок можно избежать или, по меньшей мере, минимизировать их.
Аналитика является безусловным трендом последних трёх лет, однако полезность аналитических инструментов осознали далеко не все. Мало кто умеет работать с аналитикой и понимает, какие задачи она решает. Все стараются быть в тренде, поэтому привлекают сторонних специалистов для установки и настройки аналитических систем. Зачастую такие «специалисты» не обладают должным опытом, оставляя клиента один на один с некорректно настроенной системой, с которой непонятно что делать. Обилие интернет-курсов наподобие «Стань профи веб-аналитики за 3 месяца» только подливает масла в огонь и усугубляет ситуацию, обогащая и без того раздутый рынок низко квалифицированными кадрами.
Продвижение медцентров и клиник: три кейса о SEO, TikTok и Instagram*
Как получить измеримые результаты в фарммаркетинге.
Показываем на примерах →
Спецпроект
Итак, перейдём к самим ошибкам.
1. Отсутствие «чистого» представления в Google Analytics
Иметь чистое представление очень важно. Оно не содержит фильтров, а значит вы будете иметь доступ к абсолютно всем данным, собранным счётчиком Google Analytics. К тому же, Google Analytics работает таким образом, что, если по причине установки фильтра данные не записываются системой в текущем моменте, то восстановить их будет уже невозможно.
Многие клиенты этим пренебрегают и сразу начинают работать в представлении «Все данные по веб-сайту», которое создаётся в Google Analytics по умолчанию. Они настраивают в нём цели, фильтры, модуль электронной торговли, но не создают чистое представление, тем самым лишая себя возможности посмотреть на абсолютно все данные, собираемые счётчиком.
Лучшая практика — создать ещё одно представление, назвать его «Рабочее», настроить в нём цели, фильтры, электронную торговлю и использовать в качестве основного представления для анализа данных. Представление «Все данные по веб-сайту» просто оставить в качестве чистого. Таким образом у вас всегда будет отдельное представление для просмотра «чистых» данных.
2. Перенос Google Analytics из кода сайта в Google Tag Manager без удаления старого кода
Данная ошибка встречается очень часто, и виной тому — банальная невнимательность и отсутствие плана переноса счётчика. Всё делается по наитию, и важные детали упускаются из виду. В результате это приведёт к просто «фантастическим показателям» в отчётах Google Analytics: количество просмотренных страниц за сеанс увеличится в два раза, а показатель отказов снизится до 5–7 %. На первый взгляд, результаты, действительно, могут показаться отличными.
На самом деле это лишь иллюзия успешной работы интернет-проекта. Google Analytics работает таким образом, что обрабатывает каждое обращение на свои серверы, даже если они идут с минимальным интервалом. Код, который забыли удалить из сайта, сработает первым. За ним сразу же отреагирует код Google Analytics, уже из Google Tag Manager, удвоит статистику просмотренных за сеанс страниц и снизит показатель отказов, так как система будет думать, что произошло взаимодействие пользователя с сайтом, но на самом деле его не было.
Лучшая практика — начать с составления плана переноса. В нём стоит указать список основных кодов счётчика и событий, которые нужно перенести. Далее переносим коды в Google Tag Manager и удаляем остатки кодов. Затем проверяем сбор данных в отчёте Google Analytics — «В реальном времени», а также сбор данных и отработку счётчика ещё раз через расширение Tag Assistant (by Google). В расширении важно обратить особое внимание на ошибки, которые оно указывает. Если ошибок нет, то наблюдаем за статистикой в течение недели для выявления возможных аномалий.
3. Выкатка изменений на «бой» без предварительного тестирования
Этим грешат даже крупные компании, и проблема довольно распространённая. Часто бывает, что разработчики клиента выкатывают технические задания агентства на установку/корректировку кодов аналитических систем в неподходящее время. Они делают это в пятницу вечером, и как следствие на проверку корректности работы системы уже не остаётся времени. А уже в понедельник клиент может увидеть пустые отчёты или аномалии в Google Analytics. Думаю, объяснять не нужно, что статистика за выходные дни будет либо искажена, либо потеряна. На больших объёмах продаж клиента такая ошибка может стоить больших денег.
Лучшая практика — не откладывать внедрение технических заданий на крайний срок и внедрить их хотя бы за день до выходных. Так у аналитиков агентства будет достаточно времени на проверку и проведение корректировок при необходимости. Самый верный вариант — внести изменения на тестовую среду, а не на «бой». Протестировать всё там, и только потом уже перенести на боевую версию сайта.
4. Код систем веб-аналитики установлен не на всех страницах сайта
Данная ситуация возникает практически у всех клиентов, кто не готовит предварительный план разработки новых страниц на своих сайтах.
Яркий пример такой ситуации: есть сайт, но к нему требуется добавить новые страницы. Сверстали, выкатили, а о том, что на страницу нужно поставить систему веб-аналитики, не подумали. Как итог: статистические данные по этой странице не собираются, но это ещё не всё. Если в качестве основной системы веб-аналитики используется Google Analytics, то при попадании пользователя на страницу, где отсутствует код Google Analytics, переход будет расцениваться системой как Прямой (direct/none), и изначальный источник трафика будет потерян. Яндекс.Метрика такой переход обозначит как «Внутренний» и тоже потеряет изначальный источник трафика, например, рекламный.
Перед тем, как сделать новую страницу, рекомендуем составить план разработки, который будет включать в себя список работ (в том числе работы по установке трекеров систем веб-аналитики) и сроки их реализации.
Для быстрой проверки наличия установленной и работающей системы Google Analytics советуем использовать расширение Tag Assistant (by Google). Оно способно дать всю необходимую информацию о текущем состоянии Google Analytics на конкретной странице всего за пару кликов.
5. Передача в системы веб-аналитики персональных данных
Таких случаев сейчас стало меньше, но они всё равно встречаются. Мотив такой передачи данных — превратить Google Analytics в некий аналог CRM-системы, где будут храниться данные по онлайн-трафику вместе с персональными данными пользователей. Это довольно удобно, и вариантов передачи пользовательских данных с сайта в Google Analytics множество. Самые распространённые — через URL страниц (см. картинку) и события.
Пример передачи персональных данных взят из поисковой системы Google
Однако передавать персональные данные в Google Analytics запрещено, как самой политикой безопасности Google, так и GDPR-правилами обработки персональных данных. За нарушение политики безопасности Google имеет право заблокировать ваш аккаунт Google Analytics с полной потерей всех исторических данных. Если вы думаете, что «никто не узнает», подумайте ещё раз. Все данные, которые отправляются в Google Analytics с сайта, может посмотреть любой человек находящийся на этом ресурсе. Для этого нужны всего лишь консоль и немного свободного времени. Далее тикет в поддержку Google — и вот он, бан аккаунта.
Лучшая практика — собирать данные по трафику в Google Analytics, а персональные данные пользователей в своей CRM-системе. Объединять данные между собой для формирования аудиторий можно с помощью специальных сервисов. Если очень хочется, то персональные данные можно передать в Google Analytics в зашифрованном виде, за что бан не последует.
6. Установка одного и того же кода Google Analytics на разных доменах
Бывает ситуация, когда у клиента есть несколько отдельных друг от друга сайтов. К примеру, одни сайт — информационный, второй для продаж, и оба сайта находятся на разных доменах. Эта схема подразумевает возможность перехода с информационного на сайт продаж. Не углубляясь в специфику, многие везде устанавливают единый счётчик Google Analytics.
В итоге статистика в отчётах внутри Google Analytics собирается в общую кучу. Из этих данных невозможно понять, на какой именно сайт изначально пришёл посетитель. И это ещё полбеды. Если клиент ведёт рекламу на информационный сайт (что вполне логично), то при переходе с информационного сайта на сайт продаж и совершении на нём покупки Google Analytics разорвёт сессию, так как переход был совершён в рамках разных доменов. В таком случае источником трафика будет не реклама, а реферальный переход с информационного сайта, и оценить эффективность рекламы уже будет невозможно.
Стоит отметить, что в настройках по умолчанию Google Analytics умеет автоматически отслеживать переходы и протягивать сессию у поддоменов, но не у отдельных сайтов. Однако в нашем кейсе домены разные, и для корректного отслеживания рекламы необходимо выполнить следующие действия.
-
Настроить модуль междоменного отслеживания, где информационный сайт и сайт для продаж будут ссылаться друг на друга.
-
Настроить внутренние исключения для внутренних источников перехода.
-
Создать представления в Google Analytics, где каждое представление будет фильтровать данные только своего домена (1. Чистое представление. 2. Общее представление. 3. Представление информационного сайта. 4. Представление сайта продаж.)
Таким образом, сессия не будет рваться, отчёты будут собираться корректно, мы получим отдельную статистику по каждому домену и возможность отслеживать эффективность рекламы.
7. Отсутствие исключённых источников переходов для платёжных шлюзов
Очень похожий на пункт выше случай, но ситуация несколько иная. Допустим, клиент имеет сайт интернет-магазина с возможностью проведения онлайн-транзакций с дебетовых/кредитных карт. Как правило, такие транзакции защищены технологией 3D Secure, и для успешного подтверждения транзакции необходимо ввести код из SMS-сообщения в специальном поле.
В момент подтверждения транзакции происходит перенаправление с сайта интернет-магазина на платёжный шлюз банка посетителя, в следствии чего сессия рвётся, а финальная транзакция, которую фиксирует Google Analytics, атрибутируется не изначальному источнику трафика, который привёл посетителя на сайт, а платёжному шлюзу.
В отчётах Google Analytics это выглядит вот так:
Чтобы этого избежать и видеть действительные источники транзакций, необходимо сделать несколько несложных, но довольно мучительных манипуляций с настройками Google Analytics.
Необходимо добавить каждый домен платёжного шлюза в список исключений. Взять список можно из вашего же отчёта Google Analytics по источникам трафика и фильтру 3ds. Да, это долго и тяжело, но это единственный способ привести свои данные в порядок.
8. Использование UTM-меток для отслеживания эффективности внутренних элементов сайта
Раньше таких случаев было довольно много. Сейчас — всё меньше и меньше. Суть в том, что клиенты устанавливают UTM-метки внутри сайта, чтобы отслеживать эффективность кнопок или форм (к примеру). UTM-метки — отличная штука и являются одним из главных орудий рекламщика в отслеживании интернет-трафика, но использовать их можно только для отслеживания переходов на сайт, но никак не внутри сайта между страницами и элементами.
У системы Google Analytics есть правило, где новая метка всегда «перетирает» предыдущую. Например, пришёл посетитель из Яндекса по рекламному объявлению с UTM-меткой yandex_direct /cpc и попал на сайт. Google Analytics записал этот переход как yandex_direct /cpc — и вроде бы всё отлично, но клиент решил отслеживать эффективность кнопки «Заказать звонок» на главной странице. И для этого добавил метку calltracking_button/site в кнопку «Заказать звонок». Посетитель, который изначально пришёл по рекламе Яндекса, нажал кнопку, и его сессия автоматически завершилась, так как сразу же началась новая сессия, но уже с источником calltracking_button/site. Рекламный источник Яндекса получит показатель отказов 100% и всего один просмотр страницы. Все остальные действия с момента нажатия посетителем на кнопку «Заказать звонок», будут соотнесены к источнику calltracking_button/site.
Дальше клиент уже будет ругаться на агентство и говорить «ваша реклама не работает», «показатели плачевные!», а аналитики агентства будут искать причину и найдут её в наличии UTM-меток, щедро рассыпанных на элементах сайта. Важно понимать, что такие метки крайне сложно искать, так как элементов на сайтах очень много, и на каждом из них может быть такая метка, то есть нужно руками просмотреть каждый элемент на сайте.
Лучшая практика — для отслеживания эффективности элементов сайта в Google Analytics существуют события. Они имеют гибкую структуру, которая позволяет отследить любой элемент на сайте с минимальными трудозатратами. Желательно при разметке элементов сайта с помощью событий предварительно составить карту событий в любой таблице. В будущем так будет проще следить за актуальностью настроек.
9. Включили сбор данных по User_ID и из отчётов пропали все данные
Google Analytics имеет поистине широкий функционал, однако не все понимают, что при неправильном использовании или незнании принципа работы этого функционала можно себе навредить. Так происходит очень часто. Клиент «наклацал» что-то, а потом всё пропало.
В данном случае произошло следующее: клиент захотел внедрить функционал USER_ID и перевёл в настройках тумблер в положение ВКЛ. Google Analytics автоматически создал новое представление под USER_ID, куда будут попадать только данные, которые содержат сам идентификатор. Сноску о том, что нужно дополнительно внедрить функционал USER_ID в код сайта и настроить передачу значений самих идентификаторов, оставили без внимания. Клиент зашёл в представление с USER_ID, не увидел там никаких данных и поднял панику.
На самом деле все исторические данные на месте и лежат в старых представлениях. Представление, которое было автоматически создано для работы с идентификаторами пользователей, останется пустым до тех пор, пока не будет настроена передача идентификаторов с сайта. Тип представления легко посмотреть в настройках Google Analytics. Если представление с USER_ID, то там будут только те данные, у которых данный идентификатор присутствует.
10. Нечёткое формирование KPI на старте кампании
Очень распространённая проблема и вишенка на торте этой статьи. Я уверен, что каждый из вас с этим сталкивался в работе хоть раз.
На этапе планирования и запуска кампании, когда речь идёт о формировании KPI для оценки успешности кампании, клиент зачастую перекладывает задачу по формулировке KPI на агентство. Такой подход имеет место быть, однако на начальном этапе специалисты рекламного агентства не всегда могут точно знать специфику и нюансы конкретного бизнеса. Главную роль в планировании должен играть клиент и снабжать этой информацией агентство.
Как итог: при планировании кампании не учли важные моменты, а аналитики не настроили нужные цели и события в системах веб-аналитики. Кампания прошла, и результаты оказались неизмеримы, а, как известно, исторические данные собрать уже не получится, если их не собрали ранее.
Всегда делитесь с агентством всеми нюансами и болями своего бизнеса. Лучше вас об этом никто не знает.
Мнение редакции может не совпадать с мнением автора. Ваши статьи присылайте нам на 42@cossa.ru. А наши требования к ним — вот тут.
Источник фото на тизере: Фотобанк Photogenica
Источник: