В работе веб-аналитика много интересных задач, не обо всех удаётся рассказать, но сегодня я поделюсь историей настройки аналитики на мультилендинге Tilda. А ещё о том, на какие грабли наступил в процессе и как их обошел.
Статья будет полезна:
Изначально задача звучала как «настроить аналитику на сайте для мультилендинга». Известный факт, что чем точнее сформулирована задача, тем эффективнее её решим. Поэтому я уточнил недостающую информацию и сформулировал задачу конкретней.
Поясню последний момент. Сложность заключается в том, что в дальнейшем будут создаваться новые посадочные страницы. Планируются десятки новых мероприятий. Стандартное решение с добавлением событий на конверсионные кнопки не годится и вот почему.
При настройке событий на конверсионных кнопках придется добавлять новые идентификаторы: и в код сайта, и в системы аналитики для каждого нового мероприятия. Мало того, что в Google Analytics (далее GA) упираемся в 20 целей на одно представление, а в Яндекс Метрике (далее ЯМ) это ограничение в 200 целей на счетчик, что тоже может быстро закончиться.
Такая система не будет автоматизированной и в процессе работы, например, добавлении новых идентификаторов не исключено, что исполнитель допустит ошибку. К тому же идентифицировать название мероприятия не представляется возможным (в ЯМ совсем, в GA только для целей по отчёту «URL целей»).
В GA присутствует отчёт «Конверсии — Цели — URL целей», который показывает местоположение достигнутой цели. Возможно, его можно было бы использовать для анализа страниц, на которых пользователи достигли целей?
Привожу пример отчёта для наглядности:
Внимательно посмотрев на отчет, становится понятно, что он неспособен решить наши задачи. У нас нет возможности детально рассмотреть параметры сессий и желаемые метрики.
Честно говоря, идея с использованием целей так себе. Нужно что-то другое.
В GA присутствуют встроенные инструменты для расширения наших знаний о действиях пользователя «вокруг» событий, которые отлично подойдут для нашей задачи.
Например, если мы получаем событие (например, клик на кнопку «подробнее»), то можем передавать в интерфейс GA параметры этого события:
Этот инструмент называется пользовательские параметры (Custom Dimensions) и пользовательские показатели (Custom Metrics) (далее ПП и ПП). Именно это мы будем использовать!
Плюс их использования в том, что после настройки мы можем:
Примечание: Рекомендую ознакомиться с пользовательскими параметрами и показателями в GA. На деле данный инструментарий очень полезен и часто незаменим.
Для метрики используем аналогичный функционал, только называется он «Параметры визитов».
Отдельного внимания заслуживает Tilda — платформа, на которой «крутится» сайт.
1. Для решения задачи нам понадобится модернизировать код счетчиков GA и ЯМ. Сделать это в Tilda стандартными средствами, к сожалению нельзя, так как подключение кода счетчика идёт по идентификатору отслеживания счетчика.
Однако выход есть, нужно создать кастомный блок html и копирнуть туда наши, измененные, коды GA и ЯМ. Добавьте этот блок в шаблон страницы сайта, чтобы код присутствовал на всех страницах.
Примечание: Не забудьте убрать стандартную связь Tilda с GA и ЯМ, иначе могут возникнуть проблемы с получаемыми данными.
2. Ещё одной «прекрасной» новостью Tilda стал перечень разрешений на управление счетчиком GA. Не знаю, как вам, а мне он показался достаточно избыточным:
Приступим к построению нашей системы аналитики
Настройка ПП и ПП в GA
Алгоритм работы с Custom Dimensions и Custom Metrics выглядит так:
Пользовательские параметры и показатели задаются в интерфейсе GA на уровне ресурса:
Мы в эти параметры будем помещать информацию о названии ивента, а так же о варианте участия. «Регистрацию» и «Оплату» будем фиксировать как обычные события.
Настраиваем:
Google Analytics созданному параметру присвоит индекс. По индексу программисты позже, передадут значения.
Если вы его не запомнили, то всегда увидите в разделе «Пользовательские определения — Пользовательские параметры на уровне ресурса» (средний столбец в «администраторе»):
В коде обращение к Dimension будет только по dimension1, dimension2 и т.д. Например, вот так задаем:
Пообщавшись с техническим специалистом, было решено:
Важно! Отсюда первое и единственное ограничение к созданию страниц с событиями:
При последующем создании страниц мероприятий, важно не забывать добавлять в конце URL-адреса «_free» для страниц с бесплатной регистрацией и «_std», для страниц с платной регистрацией.
Дополнительно в GA, настроили пользовательские показатели.
Когда пользователь начинает регистрацию – отправляем этот показатель для него со значением 1.
Я это сделал для того, чтобы можно было смотреть эти данные в любых отчётах.
Когда пользователь успешно завершает регистрацию, мы отправляем в GA значение 1 в показатель «Количество успешных регистраций».
Значения показателей GA умеет суммировать, высчитывать среднее и любые другие операции, которые свойственны стандартным показателям.
Значение показателя в коде задается аналогично пользовательским параметрам:
Отправляем значения ПП и ПП в GA через событие. То есть сначала задаём все нужные параметры, показатели, а после этого в коде создаём событие, которое отправит наши данные в систему.
Пример кода с отправкой ПП:
ga(‘set’, ‘dimension1’, myName); /* задаём пп 1 */
ga(‘set’, ‘dimension2’, status); /* задаём пп 2 */
ga(‘set’, ‘metric2’, ‘1’); /* задаём пп 2 */
ga(‘send’, ‘pageview’, ‘/dimension’); /* передаём пп и пп через событие pageview*/
На этом с настройкой Google Analytics закончили, перейдём к метрике.
Для метрики записываем в «Параметры визитов»:
Для использования параметров визита нужно:
Примечание: напомню, мы отключили стандартную интеграцию Tilda с яндекс метрикой и перенесли модернизированный код яндекс метрики в html блок.
<script type="text/javascript"> var yaParams = {имя_параметра:'значение параметра'}; </script>
Например:
<script type="text/javascript"> var yaParams = {Название мероприятия:'Мероприятие 1'}; </script>
Примечание: параметры визита передаём в метрику с помощью необязательного аргумента метода reachGoal. Подробнее о разных способах передачи параметров визита.
>goalParams);»
В интерфейс метрики попадёт именно то название «имя_параметра», которое вы передали в коде. Данные вы сможете видеть в стандартном отчёте «Стандартные отчёты — Содержание — Параметры визитов» или можете создать кастомный отчёт с интересующими группировками.
Попытка number one. Изначально мы хотели передавать структуру из 3 уровней вложенности (в справке написано, что можно передавать до 10 уровней вложенности включительно), однако у нас не получилось это реализовать.
Ну как не получилось… сделали, но в структуре появлялись лишние звенья, которые усложняли процесс построения отчётности. Дело в том, что, так как параметры визита в нашем случае динамические (задаём с помощью переменных) из-за этого в промежуточные звенья попадают названия переменных, и в отчёте это выглядит так:
Хотя в настройках группировки можно убрать уровни, в которых присутствуют названия переменных, мы решили отказаться от этого способа.
Попытка number two. Пробовали передавать название мероприятия и вариант участия в мероприятии разными параметрами. И это было очередными граблями для карликов, которые больно били по … эго.
Пример
<script type="text/javascript"> var yaParams = {Название мероприятия:'Мероприятие 1'}; var yaParams = {Вариант участия:Бесплатно'}; </script>
Такая передача в отчётах отображалась следующим образом:
В таком варианте передачи параметров визитов нет возможности установить соответствие между названием мероприятия (1) и вариантом участия (2). Когда данных станет больше, установить взаимосвязь будет невозможно.
Попытка number three. Поэтому мы решили отказаться от вариантов выше и объединили параметры в один:
Передаём параметр визита так: «Название мероприятия – Вариант участия».
Этот вариант нас устроил. С настройками в яндекс метрике закончили.
После настроек проверяем корректность поступаемых данных и фиксим все сбои (если таковые будут).
При проверке корректной передачи параметров визитов (в Метрику), выявили проблему: на некоторых страницах стоял устаревший счетчик Я.Метрики. Банальная, но сложно диагностируемая проблема.
Косвенно об этом свидетельствуют множественные внутренние переходы с основного домена сайта. А явно это увидели, когда заглянули во все шаблоны страниц и сравнили коды счетчика.
Решение: поставили на всех страницах сайта одинаковый код ЯМ и переопубликовали каждую страницу (Tilda же).
На следующий день снова всплыли проблемы с получением данных. Успешные регистрации в ивентах не приходили в системы аналитики.
Немного покопав… да что уж там, перепробовав кучу разных вариантов, мы не нашли причин и уже почти отчаялись. Оставался только один вариант: пойти к руководителю технического отдела – уж этот человек на своём веку видел много разных «тильд», wix-ов… и уж он-то подскажет, в чём косяк.
Как и ожидали: дело было не в бобине.
Выяснили, что личный кабинет — это отдельный сайт на поддомене (чего мы не замечали раньше). По умолчанию, счётчик GA фиксирует посещения с поддоменов, но код GA на страницах поддомена вообще отсутствовал.
Поэтому мы добавили код GA на страницы личного кабинета. Дополнительно, в GA, быстренько запилил расширенный фильтр для междоменного отслеживания.
Междоменное отслеживание можно и не настраивать, но я настроил с целью получения информации о полном URL страницы, с которой была осуществлена оплата.
После настройки междоменного отслеживания в представлении GA не забываем подкорректировать цели, которые настроены на URL страниц. Так как после настройки междоменного отслеживания GA видит страницы вместе с доменом сайта.
Например, цель, настроенная на страницу /robox/success/, которая работала раньше, после настройки междоменного отлеживания не будет работать. Теперь GA видит эту же страницу как site.ru/robox/success/. Поэтому замените URL страницы в цели на site.ru/robox/success/. Помните об этом! Либо используйте условие «содержит», но это не всегда уместно.
Для получения данных по доходу настроили электронную торговлю в GA. Использовали только часть возможностей электронной торговли (id, name, price). Написано ТЗ техническому отделу, внедрили код на сайт. Теперь в GA поступают данные о заказах.
Настроил интеграцию почтовых рассылок (MailChimp) с Google Analytics. Не забывайте размечать каждую ссылку в письме utm-метками.
Добавил домен платежной системы в список исключаемых источников перехода, чтобы трафик с неё не определялся как рефферер и не создавался новый сеанс.
Настроил отчёты с нужными параметрами и показателями, чтобы в один клик смотреть нужные данные.
Настройка закончена (пока что). Сразу же после настройки запустили рекламные кампании, по окончанию которых я оценил их эффективность на основе новенькой системы аналитики.
Посмотрим, какие данные получили.
1. Клиент может поручать создание новых мероприятий любому специалисту и знать, что аналитика по сайту будет собираться в автоматическом режиме.
Единственное ограничение — при создании страниц новых мероприятий, не забыть добавить в конце URL-адреса «_free» для страниц с бесплатной регистрацией и «_std», для страниц с платной регистрацией.
2. В отчётах видно, с каких каналов совершены покупки, на какую сумму, какая конверсия канала в покупку.
3. Видно, какие мероприятия самые популярные и как распределились регистрации по варианту участия.
4. В отчете GA видим, как распределись регистрации с привязкой к источнику, с которого было посещение, плюс видно как проходил процесс регистрации.
5. Легко считаем конверсию в начатую регистрацию/успешную регистрацию в разрезе источников.
Конечно же, мы можем посчитать стоимость лида в платные мероприятия и в бесплатные в разрезе мероприятий и рекламных кампаний.
Update 1: Далее на сайте были настроены ClientID и UserID. Так, мы оценим продажи с точки зрения пользователей. Понять, какие пользователи на какие мероприятия зарегистрировались.
Прикладное использование этих данных огромно. Например, можно показывать рекламу пользователям, которые зарегистрировались в бесплатные мероприятия, участвовали в них и дожимать до покупки приятного бонуса на память о прошедшем событии.
Или, можем определять участников по приоритетным для них категориям событий и показывать только максимально релевантную рекламу.
Настройка UserID позволила увидеть использование сайта с нескольких устройств. Появилось наглядное представление того, как пользователи на самом деле посещают сайт.
Update 2: В отправку транзакции был добавлен ещё один параметр – category. Этот параметр мы использовали в своих целях и записываем туда дополнительные данные об оплате.
Так как цикл продаж может составлять пару месяцев, то чтобы не терять связь покупки и мероприятия, к которому она относится, мы и добавили параметр category. Он позволяет узнать дополнительную информацию о привязки произошедшей оплаты к мероприятию. Эти данные в дальнейшем используем в рекламе.
Задачи бизнеса решены. Настроили даже больше, чем изначально планировали. Приятная особенность такой системы в том, что работает в автоматическом режиме и не требует постоянных правок.
Подведу итог.
P.S. В будущем планирую:
На этом все, спасибо за уделенное время. Надеюсь – было полезно. Буду рад уточнениям, предложениям, вопросам. Интересных задач, высоких конверсий, счастливых клиентов!
В конце 2020 года вышел из беты новый продукт Microsoft - Clarity. Станет ли Clarity…
Дашборд - инструмент для понимания того, что данные соответствуют ситуации, в которой находится продукт. Но…
Друзья, есть идея подготовить для вас вебинар по веб-аналитике. Но мне нужна ваша помощь.
Скоро будет год как я стал экспертом Яндекса по обучению по продукту Яндекс Метрика. Первый…
В 2018 году я семестр преподавал веб-аналитику в СГЭУ. Офлайн, с домашками и экзаменом в…
На мой взгляд в МСБ (малый и средний бизнес) сделать автоматическую отчетность маркетинговых активностей и…
This website uses cookies.