Разработка инструмента для аналитики сервиса без помощи программистов

Руководитель группы веб-аналитики eLama Антон Леонтьев — о том, какие сервисы помогут составить график динамики активности пользователей.

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

В eLama есть ряд инструментов для контекстной рекламы: кроссминусация ключевых слов, комбинатор ключевых слов, загрузка расходов «Яндекс.Директа» в Google Analytics, «Рекомендатор», автоматическое управление ставками и другие. Коллег интересуют простые данные: сколько людей пользуются инструментами, какими опциями, насколько часто. Как получить ответы, особенно если ты работаешь в маркетинге, как я?

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

Хорошим решением задачи может быть введение отдельной должности аналитика в отделе разработки в подчинении у технического директора. Но мы рассмотрим вариант, когда веб-аналитик работает в маркетинге, и сделаем всё сами.

Нам понадобятся:

Разработку аналитики рассмотрим на примере инструмента «Рекомендатор», который проверяет соответствие кампаний в «Яндекс.Директе» и Google AdWords рекомендациям рекламных систем. Мы построим два отчёта, которые будут ежедневно автоматически обновляться:

1. Какие рекомендации показывались и как с ними взаимодействовали пользователи:

Обозначения полей разберём ниже, когда будем строить этот отчёт.

2. Динамика использования по месяцам: количество пользователей, кампаний, заходов.

1. С каждым действием внутри инструмента нам нужно передавать в Google Analytics user_id пользователя в eLama. Для этого попросим программистов передавать его на фронтенд сайта при каждой загрузке страницы через JavaScript в глобальный массив dataLayer. Например, для пользователя с user_id равным 53300 это будет такая команда:

window.dataLayer = [{ 'user_id': '53300' }];

Её нужно разместить в самом начале исходного кода HTML-страницы:

2. Каждое событие в инструменте будем отправлять в dataLayer. Например, «запросил рекомендации» — когда пользователь заходит в «Рекомендатор»:

В этот момент нужно отправить в dataLayer следующую команду:

User_id пользователя мы в этот момент не передаём, так как его значение определяется при загрузке страницы благодаря настройке из первого пункта.

В отладчике Google Tag Manager это событие будет выглядеть следующим образом:

3. Аналогичным образом реализуем событие «пришли рекомендации»:

User_id пользователя, recommendationsExternalCid и recommendationsAdSystem в этот момент мы не передаём, так как они уже определены в первом и втором пунктах.

Количество событий «запросил рекомендации» и «пришли рекомендации» в отчёте отличается, так как системе нужно несколько секунд на анализ кампании — не все пользователи дожидаются, пока придут рекомендации, иногда происходят ошибки, бывает недостаточно баллов API «Яндекс.Директа». Кроме того, рекомендации приходят после другого события — «обновить рекомендации».

4. Аналогично настраиваем событие «переход на ссылку — статью» (переход в Справочный центр eLama из описания рекомендации):

Так же реализуем остальные события в «Рекомендаторе»: «кликнул на подробнее», «переход на ссылку — кнопку», «переход на ссылку — объявление», «обновил список», «закончились баллы API «Яндекс.Директа», «попросил новую». Вот как эти опции выглядят в интерфейсе инструмента:

5. Теперь нужно создать переменные в Google Tag Manager, соответствующие каждой переменной из dataLayer (кроме event). Например, для recommendationsExternalCid:

6. Для каждого события (event в dataLayer) создадим триггер и тег в Google Tag Manager, чтобы отправлять события в Google Analytics. Например, «пришли рекомендации»:

В категории «события» Google Analytics мы указываем название инструмента, то есть «Рекомендатор». «События» — это тип взаимодействия с инструментом, например, «пришли рекомендации».

В ярлык события нам нужно передать остальные параметры: название рекламной системы, id кампании, количество пришедших рекомендаций и их идентификаторы. Поэтому будем передавать их в формате JSON, чтобы можно было обрабатывать в дальнейшем, то есть для нашего примера: {"adSystem":"direct","externalCid":"29833481", "count":"5","list":"r03 r04 r05 r08 r20"}.

В Google Tag Manager при настройке тега в ярлыке нужно указывать названия переменных в двойных фигурных скобках: {"adSystem":"{{recommendationsAdSystem}}","externalCid":"{{recommendationsExternalCid}}", "count":"{{recommendationsCount}}","list":"{{recommendationsList}}"}

User_id пользователя, воспользовавшегося инструментом, тоже можно передавать в ярлыке, но мы сделали иначе, передаём через поле userId и специальный параметр при вызове Google Analytics на странице:

7. Если всё настроили правильно, то в Google Analytics станет доступна статистика по событиям:

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

8. В простом виде у нас уже есть вся статистика по инструменту. Все события можно выгрузить из Google Analytics в файле Excel и вручную обработать. Но, конечно, этот вариант нас не устроит, поэтому мы будем обрабатывать данные автоматически, используя стриминг несэмплированных данных Google Analytics OWOX BI Pipeline в BigQuery.

Создадим в BigQuery view виртуальную таблицу tools_web.recommender, которая будет содержать все события в инструменте. Дальнейшие отчёты будем строить на её основе. Эта таблица будет выглядеть следующим образом:

Например, пользователь 184145 сначала запросил рекомендации, потом ему пришло три рекомендации, в том числе r03 и ещё две, которые не поместились на скриншоте. Затем он кликнул на «подробнее» в рекомендации r03 и перешёл в справку к статье по этой же рекомендации и так далее.

Ниже пример нашего SQL-запроса для создания view:

Сохранение view в интерфейсе BigQuery выглядит следующим образом:

9. Построим первый отчёт со статистикой по всем событиям:

SQL-запрос для получения отчёта будет иметь следующий вид:

С этим отчётом можно работать не только в интерфейсе Google BigQuery, но и сохранить его в Google Sheets или скачать в CSV. Можно поступить другим образом — создать Google Sheets с доступом коллегам, а в него данные подтягивать через OWOX BI BigQuery Reports, там же можно настроить ежедневное обновление по расписанию.

10. Построим второй отчёт с динамикой использования «Рекомендатора» по месяцам. В табличном виде он будет выглядеть так:

Если же подключить инструмент визуализации, например, Redash, можно получить отчёт в графическом виде:

В нашем случае SQL-запрос выглядит так:

11. Используя таблицу tools_web.recommender, содержащую все события, можно построить множество других отчётов: возвращаемость пользователей, частоту использования, найти самые проблемные кампании с точки зрения «Рекомендатора», или наоборот. Данные можно сегментировать по географии клиентов (регион определять по Google Analytics), по различным сегментам пользователей, например, по средним чекам, если в BigQuery хранятся транзакции клиентов и так далее.

12. Так как все события отправляются через Tag Manager, то без проблем можно добавить события «Яндекс.Метрики», Facebook, «ВКонтакте» для сбора рекламных аудиторий для ремаркетинга. А для Google AdWords можно сразу настраивать аудитории по описанным событиям Google Analytics.

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

Недостатки описанного метода:

#кейсы