Настройка аналитики на tilda: проблемы и решения

практика настройки аналитики на tilda

В работе веб-аналитика много интересных задач, не обо всех удаётся рассказать, но сегодня я поделюсь историей настройки аналитики на мультилендинге Tilda. А ещё о том, на какие грабли наступил в процессе и как их обошел.

Статья будет полезна:

  • интернет-маркетологам, и людям, которые развивают бизнес в интернете. Привожу примеры реальных задач, которые решаются с помощью веб-аналитики;
  • начинающим веб-аналитикам. Вы сможете повторить настройки и, возможно, избежать возникших у меня проблем;

Исходные данные и важные мелочи

Изначально задача звучала как «настроить аналитику на сайте для мультилендинга». Известный факт, что чем точнее сформулирована задача, тем эффективнее её решим. Поэтому я уточнил недостающую информацию и сформулировал задачу конкретней.

  1. Тематика сайта – организация офлайн мероприятий по все России. Регистрация происходит онлайн. У каждого пользователя есть личный кабинет.
  2. Сайт — мультилендинг на Tilda (о, ужас!) со следующей структурой:
пример структуры сайта на tilda
Для каждого мероприятия создаются три лендинга: страница с описанием и 2 страницы с регистрацией

Задачи

  • Узнать стоимость лида в платные мероприятия и в бесплатные в разрезе мероприятий и рекламных кампаний.
  • Настроить отслеживание событий так, чтобы видеть перечисленные ниже показатели в интерфейсе счетчиков (Яндекс Метрика, Google Analytics) по множеству метрик и показателей:
    • Название мероприятия
    • Тип участия (бесплатно, платно)
    • Факт регистрации
    • Факт оплаты
  • Система аналитики должна быть максимально автоматизированной, т.е. исключать человеческий пофигизм фактор.

Поясню последний момент. Сложность заключается в том, что в дальнейшем будут создаваться новые посадочные страницы. Планируются десятки новых мероприятий. Стандартное решение с добавлением событий на конверсионные кнопки не годится и вот почему.

При настройке событий на конверсионных кнопках придется добавлять новые идентификаторы: и в код сайта, и в системы аналитики для каждого нового мероприятия. Мало того, что в Google Analytics (далее GA) упираемся в 20 целей на одно представление, а в Яндекс Метрике (далее ЯМ) это ограничение в 200 целей на счетчик, что тоже может быстро закончиться.

Такая система не будет автоматизированной и в процессе работы, например, добавлении новых идентификаторов не исключено, что исполнитель допустит ошибку. К тому же идентифицировать название мероприятия не представляется возможным (в ЯМ совсем, в GA только для целей по отчёту «URL целей»).

Примечание

В GA присутствует отчёт «Конверсии — Цели — URL целей», который показывает местоположение достигнутой цели. Возможно, его можно было бы использовать для анализа страниц, на которых пользователи достигли целей?

Привожу пример отчёта для наглядности:

как выглядит отчет url целей в ga
Пример того, как мы бы видели информацию о регистрации на мероприятия

Внимательно посмотрев на отчет, становится понятно, что он неспособен решить наши задачи. У нас нет возможности детально рассмотреть параметры сессий и желаемые метрики.

Честно говоря, идея с использованием целей так себе. Нужно что-то другое.

Что-то другое

В GA присутствуют встроенные инструменты для расширения наших знаний о действиях пользователя «вокруг» событий, которые отлично подойдут для нашей задачи.

Например, если мы получаем событие (например, клик на кнопку «подробнее»), то можем передавать в интерфейс GA параметры этого события:

  • страницу, где расположена кнопка;
  • статус пользователя (зарегистрированный или нет);
  • название элемента, к которому относится кнопка;
  • тип страницы, если это A/B тест и так далее.

Этот инструмент называется пользовательские параметры (Custom Dimensions) и пользовательские показатели (Custom Metrics) (далее ПП и ПП). Именно это мы будем использовать!

Плюс их использования в том, что после настройки мы можем:

  • создавать по ним сегменты;
  • добавлять их в качестве дополнительных параметров в любые стандартные отчеты;
  • использовать в качестве основных параметров в собственных отчетах.

Примечание: Рекомендую ознакомиться с пользовательскими параметрами и показателями в GA. На деле данный инструментарий очень полезен и часто незаменим.

Для метрики используем аналогичный функционал, только называется он «Параметры визитов».

Отдельного внимания заслуживает Tilda — платформа, на которой «крутится» сайт.

«Преимущества» платформы Tilda

1. Для решения задачи нам понадобится модернизировать код счетчиков GA и ЯМ. Сделать это в Tilda стандартными средствами, к сожалению нельзя, так как подключение кода счетчика идёт по идентификатору отслеживания счетчика.

Однако выход есть, нужно создать кастомный блок html и копирнуть туда наши, измененные, коды GA и ЯМ. Добавьте этот блок в шаблон страницы сайта, чтобы код присутствовал на всех страницах.

Примечание: Не забудьте убрать стандартную связь Tilda с GA и ЯМ, иначе могут возникнуть проблемы с получаемыми данными.

2. Ещё одной «прекрасной» новостью Tilda стал перечень разрешений на управление счетчиком GA. Не знаю, как вам, а мне он показался достаточно избыточным:

запрос прав от tilda
Рука не поднялась дать перечисленные разрешения для аккаунта GA, на котором есть счетчики других сайтов. Все коды счетчиков добавили в кастомный блок html

Приступим к построению нашей системы аналитики

Настройки в Google Analytics

Настройка ПП и ПП в GA

Алгоритм работы с Custom Dimensions и Custom Metrics выглядит так:

  1. Создаём параметры или показатели в интерфейсе GA.
  2. Определяем момент, когда мы будем задавать и отправлять значения пп (например, при успешной отправке заявки).
  3. Задаём значение пп в выбранный на шаге 2 момент (через специалистов технического отдела).
  4. Отправляем значение в GA (через специалиста технического отдела).

Пользовательские параметры и показатели задаются в интерфейсе GA на уровне ресурса:

где посмотреть пользовательские параметры и показатели в интерфейсе GA

Мы в эти параметры будем помещать информацию о названии ивента, а так же о варианте участия. «Регистрацию» и «Оплату» будем фиксировать как обычные события.

Настраиваем:

  • название мероприятия — CustomDimension;
  • тип участия (бесплатно, платно) — CustomDimension;
  • факт регистрации — Событие;
  • факт оплаты — Событие.

добавляем в ga новый пользовательский параметр

Google Analytics созданному параметру присвоит индекс. По индексу программисты позже, передадут значения.

в google analytics индекс пользовательского параметра
Индекс параметра — цифра после названия переменной dimension

Если вы его не запомнили, то всегда увидите в разделе «Пользовательские определения — Пользовательские параметры на уровне ресурса» (средний столбец в «администраторе»):

в 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 уровней вложенности включительно), однако у нас не получилось это реализовать.

Ну как не получилось… сделали, но в структуре появлялись лишние звенья, которые усложняли процесс построения отчётности. Дело в том, что, так как параметры визита в нашем случае динамические (задаём с помощью переменных) из-за этого в промежуточные звенья попадают названия переменных, и в отчёте это выглядит так:

в отчёте яндекс метрики динамические параметры визита
myParam – это название переменной. Сложно воспринимается информация

Хотя в настройках группировки можно убрать уровни, в которых присутствуют названия переменных, мы решили отказаться от этого способа.

Попытка 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 видим, как распределись регистрации с привязкой к источнику, с которого было посещение, плюс видно как проходил процесс регистрации.

смотрим распределение регистраций с привязкой к источнику в google analytics
Желтым цветом отметил значение, которое требуется в перепроверке, возможно один пользователь отправил заявку на регистрацию раньше, а в отчётный период подтвердил регистрацию с почты

5. Легко считаем конверсию в начатую регистрацию/успешную регистрацию в разрезе источников.

посчитаем конверсию в начатую и успешную заявку по источникам
В таблице выше наблюдаем, как нещадно сливается трафик, а вместе с ним и деньги, с рекламы в google. Как я выяснил во время анализа трафика, причина была в «кривой» адаптивной вёрстке сайта

Конечно же, мы можем посчитать стоимость лида в платные мероприятия и в бесплатные в разрезе мероприятий и рекламных кампаний.

Update 1: Далее на сайте были настроены ClientID и UserID. Так, мы оценим продажи с точки зрения пользователей. Понять, какие пользователи на какие мероприятия зарегистрировались.

Прикладное использование этих данных огромно. Например, можно показывать рекламу пользователям, которые зарегистрировались в бесплатные мероприятия, участвовали в них и дожимать до покупки приятного бонуса на память о прошедшем событии.

Или, можем определять участников по приоритетным для них категориям событий и показывать только максимально релевантную рекламу.

Настройка UserID позволила увидеть использование сайта с нескольких устройств. Появилось наглядное представление того, как пользователи на самом деле посещают сайт.

посещение сайта с разных устройств
К вопросу о том, стоит ли настраивать UserID. Конечно стоит!

Update 2: В отправку транзакции был добавлен ещё один параметр – category. Этот параметр мы использовали в своих целях и записываем туда дополнительные данные об оплате.

Так как цикл продаж может составлять пару месяцев, то чтобы не терять связь покупки и мероприятия, к которому она относится, мы и добавили параметр category. Он позволяет узнать дополнительную информацию о привязки произошедшей оплаты к мероприятию. Эти данные в дальнейшем используем в рекламе.

Выводы

Задачи бизнеса решены. Настроили даже больше, чем изначально планировали. Приятная особенность такой системы в том, что работает в автоматическом режиме и не требует постоянных правок.

Подведу итог.

  1. Ставьте перед собой конкретные, измеримые цели, конкретизируйте постановку задачи.
  2. Максимально автоматизируйте систему аналитики, все условия, без которых она не будет работать нужно документировать и доводить до сведения всех лиц, участвующих в работе сайта.
  3. Многие функции ЯМ и GA скрыты от глаз, но это не значит, что их нет. Изучайте мануалы от Яндекса и Google. Подпишитесь на их рассылки о новинках, чтобы быть в курсе последних нововведений.
  4. Если есть возможность – откажитесь от сайта на конструкторе в пользу сайта на популярной системе: bitrix, modx, wordpress. Если возможности нет, то можно работать и с конструктором, но сложнее.
  5. С помощью специальных параметров и показателей можно расширять наши данные о событиях.
  6. Нюансы ПП и ПП:
    1. Нужно не только задать значения ПП и ПП, но и отправить данные в GA.
    2. Если событие прописать в коде выше задания показателей, то данные не уйдут.
    3. Если прописать несколько событий, то данные отправятся несколько раз и статистика исказится.
  7. Параметры визитов в метрике поддерживают вложенность.
  8. В процессе выполнения работ будут косяки, нужно уметь их признать, исправить и двигаться дальше.
  9. Старайтесь сделать больше, чем просят. Но то, что просят – делайте в первую очередь.
  10. Анализируйте рекламные кампании, стройте гипотезы причин успешности/неуспешности кампаний, проверяйте их и принимайте бизнес-решения на основе чистых данных.

P.S. В будущем планирую:

  • настроить импорт расходов из рекламных систем в GA;
  • визуализировать отчёты в power bi.

На этом все, спасибо за уделенное время. Надеюсь – было полезно. Буду рад уточнениям, предложениям, вопросам. Интересных задач, высоких конверсий, счастливых клиентов!

Оцените статью
DiKosmos.ru
Добавить комментарий

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.