Настройка аналитики на мультилендинге Tilda

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

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

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

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

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

Для каждого мероприятия создаются три лендинга: страница с описанием и 2 страницы с регистрацией.

Задачи

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Настройки в google analytics

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

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

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

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

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

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

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

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

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

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

В коде обращение к 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 блок.

• Определить момент, когда передавать параметр (например, при успешной отправке заявки).

• Задать значение, с помощью следующего кода:

  var yaParams = {имя_параметра:'значение параметра'};

  Например:

  var yaParams = {Название мероприятия:'Мероприятие 1'};

• отправить значение в метрику

  Примечание: параметры визита передаём в метрику с помощью необязательного аргумента метода reachGoal. Подробнее о разных способах передачи параметров визита..

  onclick="yaCounterXXXXXXXX.reachGoal('FREE_SEND', goalParams);"

  В интерфейс метрики попадёт именно то название «имя_параметра», которое вы передали в коде. Данные вы сможете видеть в стандартном отчёте «Стандартные отчёты — Содержание — Параметры визитов» или можете создать кастомный отчёт с интересующими группировками.

Особенности параметров визитов

Попытка number one. Изначально мы хотели передавать структуру из 3 уровней вложенности (в справке написано, что можно передавать до 10 уровней вложенности включительно), однако у нас не получилось это реализовать.

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

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

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

Попытка number two. Пробовали передавать название мероприятия и вариант участия в мероприятии разными параметрами. И это было очередными граблями для карликов, которые больно били по … эго.

Пример:

var yaParams = {Название мероприятия:'Мероприятие 1'};
var yaParams = {Вариант участия:Бесплатно'};

Такая передача в отчётах отображалась следующим образом:

В таком варианте передачи параметров визитов нет возможности установить соответствие между названием мероприятия (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. Легко считаем конверсию в начатую регистрацию/успешную регистрацию в разрезе источников.

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

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