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