Настройка аналитики на мультилендинге Tilda: проблемы и решения. Читайте на Cossa.ru

12 декабря 2017, 16:00

Настройка аналитики на мультилендинге Tilda: проблемы и решения

Эпическая история Дмитрия Карпушина о том, как настраивали веб-аналитику для страницы на Tilda. Кейс агентства Orwo.

Настройка аналитики на мультилендинге Tilda: проблемы и решения

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

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

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

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

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

  1. Тематика сайта — организация офлайн-мероприятий по всей России. Регистрация происходит в онлайне. У каждого пользователя есть личный кабинет.
  2. Сайт — мультилендинг на 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. Не знаю, как вам, а мне он показался достаточно избыточным.

Tilda требует разрешения на управление счётчиком GA

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

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

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

Настраиваем ПП и ПП в GA.

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

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

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

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

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

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

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-блок.

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

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

       <script type="text/javascript">
    var yaParams = {имя_параметра:'значение параметра'};
    </script> 

    Например:

       <script type="text/javascript">
    var yaParams = {Название мероприятия:'Мероприятие 1'};
    </script> 
  • отправить значение в Метрику.

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

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

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

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

Попытка number one. Изначально мы хотели передавать структуру из трёх уровней вложенности (в справке написано, что можно передавать до 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/. Помните об этом! Либо используйте условие «содержит», но это не всегда уместно.

Что ещё было настроено

Ecommerce

Для получения данных по доходу настроили электронную торговлю в GA. Использовали только часть возможностей электронной торговли (id, name, price). Написали ТЗ техническому отделу, внедрили код на сайт. Теперь в GA поступают данные о заказах.

Настройка в MailChimp

Настроили интеграцию почтовых рассылок (MailChimp) с Google Analytics. Важно не забывать размечать каждую ссылку в письме utm-метками.

Исключаемые источники перехода

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

Кастомные отчёты в GA

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

Какие данные удалось «вытащить» на основе настроенной системы аналитики

Настройка закончена (пока что). Сразу же после настройки запустили рекламные кампании, по окончании которых я оценил их эффективность на основе новенькой системы аналитики.

Посмотрим, какие данные получили.

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

Единственное ограничение — при создании страниц новых мероприятий не забыть добавить в конце URL-адреса «_free» для страниц с бесплатной регистрацией и «_std», для страниц с платной регистрацией.

2. В отчётах видно, с каких каналов совершены покупки, на какую сумму, какая конверсия канала в покупку.

3. Видно, какие мероприятия самые популярные и как распределились регистрации по варианту участия.

4. В отчёте GA отражено, как распределились регистрации с привязкой к источнику, с которого было посещение, плюс видно, как проходил процесс регистрации.

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

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.

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

Мнение редакции может не совпадать с мнением автора. Ваши статьи присылайте нам на 42@cossa.ru. А наши требования к ним — вот тут.

Телеграм Коссы — здесь самый быстрый диджитал и самые честные обсуждения: @cossaru

📬 Письма Коссы — рассылка о маркетинге и бизнесе в интернете. Раз в неделю, без инфошума: cossa.pulse.is