Продуктовая аналитика в одностраничном веб-приложении (SPA). Часть 1

В этой статье я расскажу о базовой аналитике в связке GTM – Amplitude на SPA (Angular), в т.ч WebView на Android и iOS.

Что такое SPA коротко и доступно написано тут:

Про аналитику в Amplitude рекомендую максимально полезные статьи от Тимура Тукаева

Вероятно, какие-то вещи я повторю снова – т.к сложно избежать желания давать советы.

Важно! Предполагается, что читатель обладает базовыми знаниями и уже пробовал работать с Amplitude и Google Tag Manager

Некоторые продуктовые менеджеры или аналитики привыкли к тому, что по веб-сайтам базовая аналитика собирается из коробки. В первую очередь речь идет про переходы между страницами. Всё, что вы увидите в Google Analytics для страниц на Angular или React – это будет название вашего сайта (как правило это и будет заголовком первой страницы).

Увы, из коробки ничего полезного собираться не будет. Но если вы когда-либо работали с нативными мобильными приложениями, то сложностей с понимаем основных принципов не будет. Хотите получить данные – их нужно разметить (с командой разработки).

Т.к нам все равно все размечать руками, то мой выбор в пользу Amplitude. В следующий раз попробую описать, что можно сделать и с GA4.

Google Tag Manager полезный инструмент, даже не смотря на ограничения в работе на SPA. Сложность в том, что если проект живой и в разработке, то гарантированно разметить триггеры в GTM (для SPA) не получится - не буду лукавить, есть теги, которые за 6 месяцев жизни проекта действительно не менялись.

За полгода из работающих событий в Amplitude созданных с помощью обычных механизмов GTM (когда вы размечаете триггеры самостоятельно, например, по селекторам - без разработки) осталось не более 30%

Да, селекторы в Angular (и любом другом SPA) тоже часто меняются. Даже название поля ввода - mat-input-0 завтра может стать mat-input-1, если в проекте появились новые поля ввода. SPA вообще не гарантирует нейминг селекторов - хотя тут скорее всего со мной кто-то может поспорить.

Тогда зачем GTM?

- С его помощью я запускаю разные конфигурации Amplitude на разных контурах для теста и для боя (нет смысла заставлять разработчиков решать такую задачу)

- Добавляю свойства событий и пользователей (например, браузер пользователя или размеры разрешения браузера). Много всего, у всех задачи разные

- Проверяю локальные проблемы добавляя временно новые события с помощью селекторов или других идентификаторов

и т.д

Т.е GTM передает события в Amplitude и это удобно, потому что данные можно модифицировать.

Подробнее про GTM почитать тут:

Конфигурация Amplitude в GTM

Код в поле HTML для тега конфигурации взять из кабинета Amplitude - JavaScript SDK.

Из необычного в проекте сделан кастомный триггер, который по доменному имени запускает разные конфигурации проектов в Амплитуде.

Саму проверку делаю в переменной

Переменная всегда должна что-то возвращать. Код не самый красивый - т.к часто преобразовывался, но тут скорее про смысл (домен конечно заменен).

С этой переменной работает Триггер на инициализацию с условием активации тега на значение переменной выше (триггера 3 - на 3 разных контура).

Дальше самое важное: фронт шлет пуш-события в data-слой по интересующим вас событиям. Для разработки, это будет что-то вроде:

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

Если разработка все сделала правильно, то в консоли GTM появятся события с неймингом из поля event, свойства этих событий можно посмотреть переключившись на вкладку Data Layer

Подробнее про дата слой тут:

Подключили GTM, настроили конфигурацию Amplitude, шлем пуш события в дата слой - что дальше?

Дальше в GTM создаем Тег с типом Пользовательский HTML

В теге будет примерно следующий код для каждого тэга для события:

В фигурных скобках ссылки на созданные переменные в GTM.

Если вам не нужна кастомизация под разные события, то вместо имени события 'MOE_SOBITIE_DLYA_AMPLITUDE' можно написать {{Event}} (так же заведите его, как переменную) - тогда нейминг ваших событий от разработки сразу будет прокидываться в Амплитуду.

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

Ну и наш Тег (теги) с пользовательским HTML должны запускаться по Триггеру "Специальные события"

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

Если у вас один Тег с именем {{Event}}, которое передается в Amplitude для всех событий, как я писал выше, то у него будет множество Триггеров под каждое событие. Не забывайте добавлять новые Триггеры с появлением новых ивентов от разработки.

Строчка с amplitude.getInstance().setUserProperties({'data': eventProperties.data}); скорее всего в рамках этой статьи вам не нужна - она присваивает свойства пользователю. Я думаю расскажу об этих особенностях в другой раз.

Полезные переменные

К сожалению, авторство указать сейчас для меня крайне сложно, но думаю кому важно загуглит. Точно помню, что много взял, например, тут:

Название переменных должно быть доступным и легко читаемым - именно к нему вы будете обращаться в Тегах в фигурных скобках.

Тип устройства по ширине экрана

Платформа

Размер экрана

Временная зона

Проверка на Touch Screen

Юзер Агент

Например, так выглядит парсинг ЮТМ меток (чтобы так же записать)

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

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