Кейс: как построить отдел аналитики в большой компании?

Зачем нужна аналитика в компании?

Слово «аналитика» происходит от древнегреческого άναλυτικά, что означает искусство анализа. Это была часть более широкого понятия логики, рассматривавшая процесс познания как разложение целого на составные части с целью более детального изучения.

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

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

Видов аналитики на данный момент появилось достаточно много (о чем частично мы рассказывали в этой статье) — это бизнес-анализ, системная аналитика, продуктовая аналитика, BI и тд. Но так как я работаю в сфере digital, то речь пойдет именно о аналитике данных и всем что с этим связано.

Так зачем же компании работающей в цифровой среде аналитика?

В реальности бизнесу неинтересны показатели просмотров рекламных объявлений, кликов по ним, количество событий на сайте и прочие непонятные вещи. Бизнесу интересны деньги (неожиданно, правда 🙂 ). И с его точки зрения, аналитика это — способ быстро и качественно сделать вывод о результативности маркетинга и его процессов для принятия решения.

Следовательно, аналитика нужна бизнесу для того чтобы:

• закупать качественный трафик и оптимизировать расходы;
• развивать продукты и увеличивать удовлетворенность пользователей;
• развивать дополнительные каналы привлечения пользователей;
• оцифровывать и считать ключевые метрики;
• выводить и отслеживать эти метрики на дашбордах.

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

1. Любой клиентский путь начинается с привлечения — это тот этап, на котором пользователь знакомится с компанией и ее услугами посредством digital или offline-рекламы. На этом этапе аналитика может быть полезна при сборе и анализе данных о расходах.
2. Вторым пунктом клиентского пути является посещение — это этап, на котором пользователь попадает на наш сайт или мобильное приложение. И тут мы уже знаем о источнике трафика приведшего клиента, а также о его идентификаторах (Client ID, User ID и тп).
3. На третьем этапе пользователь совершает какие-то действия, например, изучает каталог и знакомится с описанием товаров. Тут аналитика ответственна за сбор данных о событиях.
4. Некоторые действия являются конверсиями и переводят посетителя в статус клиента. На этапе конверсии аналитика помогает с анализом данных о доходах, а также при построении различных моделей атрибуции, для того чтобы честно оценить вклад каждого из источников трафика в достижение конверсии.
5. Между этапом действий и конверсий мы можем проводить A/B-тесты направленные на увеличение Convertion Rate и здесь возникают знания о экспериментах, которые необходимо анализировать и интерпретировать.
6. После совершения конверсии клиентский путь не заканчивается и он переходит на этап возврата, в котором аналитика ответственна за сбор данных о аудиториях и сегментах для загрузки в ретаргетинговые и crm-системы.

И теперь давайте дадим определение digital-аналитики:

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

Мой старт, какие вызовы стояли?

Осенью 2017 года я получил предложение о работе на позицию веб-аналитика в компанию Сравни.ру. Это сейчас Сравни крупнейший финансовый маркетплейс с лицензией ЦБ и десятками миллионов посетителей в месяц, а тогда это был сравнительно небольшой сайт с единственной вакансией аналитика во всей компании.

Параллельно с предложением от Сравни, я получил оффер от весьма именитого агентства. Передо мной встала диллема — идти работать в крупное агентство с большим спектром задач и разными клиентами или на текущее место работы, мой выбор пал на сторону клиента. Я четко осознавал риски «застоя» при работе на клиентской стороне и был заряжен на саморазвитие. Благо, работодатель поддержал мои стремления к росту и постоянной прокачке, благодаря чему и Сравни.ру стал получать профиты в виде выстроенной системы web/app-аналитики, собственного BI-инструмента, появлению A/B-тестирования и прочих аналитических радостей.

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

Трекинг рекламных кампаний и Google Analytics был настроен весьма странно — utm-разметка использовалась по наитию, невозможно было понять, что означает то или иное событие, не был настроен импорт расходов и тп.

Соответственно передо мной стояли следующие вызовы:

• разработать единый стандарт utm-разметки рекламных кампаний;
• провести аудит текущей системы событий и разработать новую;
• провести аудит настроек Google Tag Manager — убрать лишние теги и внедрить подход «одна система — один тег»;
• обеспечить бесшовный переход со старой системы событий на новую;
• избавиться от ежедневного ручного сбора отчета по контексту и автоматизировать его.

Закатав рукава, я приступил к реализации плана.

Аудит всего — от трекинга, до отчетов

UTM-метки и единый стандарт

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

UTM-метки на самом деле, являются одним из важнейших элементов так называемой «сквозной аналитики», без которых она работать не будет. А все потому что это не просто параметр в ссылке — после перехода на сайт параметры utm, содержащие источник/канал и много другой полезной информации, фиксируются системами трекинга и далее на этих данных строится вся аналитика по показам, кликам, конверсиям и расходам на маркетинг. Но это еще не все, далее эти параметры попадают в базы данных и CRM-системы, после чего на основе информации о закрытых сделках и продажах в разрезе источников принимаются решения о увеличении бюджета, либо остановке той или иной рекламной кампании.

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

• Название источника (utm_source) обязательно должно быть заполнено и являться краткими, но релевантными;
• Лучше всего, использовать домен в качестве имени источника;
• Выбирая название для канала (utm_medium), следуйте настройкам каналов по умолчанию в Google Analytics;
• Самая большая ошибка, которую можно допустить — это неправильно разметить каналы, так как это самый важный тег для правильной группировки в системах трекинга;
• Все utm-метки всегда пишите строчными (маленькими) буквами;
• Перед внедрением какой-либо новой метки, необходимо проверить не используется ли она уже в другом варианте.

Google Tag Manager и система событий

Первый аудит GTM закончился неожиданно…

Я решил переделать передачу Client ID в Google Analytics через customTask по методу, который был описан в блоге Simo Ahava, вечером зарелизил свежую версию тега в GTM и со спокойной душой ушел домой… Но результате моих действий наш сервис подбора кредита оказался парализованным и почти сутки тестировщики не могли найти в чем причина. А дело было в том, что в прошлой версии Client ID получаемый из cookies использовался для передачи в одном из полей формы заявки на кредит и каким-то образом все это было подвязано на GTM 🙁

Пришлось срочно все откатывать назад и подойти к аудиту трекинга более обстоятельно.

Из данной ситуации можно сделать два вывода:

1. Любой процесс всегда нужно опрозрачивать, чтобы все (продукт, маркетинг) были в курсе планирующихся изменений и они не стали для них неожиданностью;
2. Любое изменение должно проходить через этап тестирования к которому необходимо подключать сам продукт.

Вторая попытка оказалась успешней.

Была составлена карта событий, которые трекались на тот момент, но какой-то системности в них не было. Далее были опрошены product owners каждого из продуктов на предмет того, что бы им хотелось отслеживать и чего сейчас не хватает в плане аналитики. После этого я составил новую карту событий, построенную на следующих принципах:

• Учтён маппинг со старыми событиями, чтобы не пострадала аналитика по продукту;
• Единая событийная модель для всего сайта;
• Одинаковые действия (Event Action) в разных продуктах, должны называться одинаково;
• Унифицированный стиль именования событий — какой используется регистр, заменяются ли пробелы и тп.;
• Учет версионности — каждое изменение в карте событий должно отражаться;
• Доступная для всех документация с примерами кода для разработчиков.

Пример карты событий можно посмотреть по ссылке.

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

Параллельно с внедрением новой системы событий была переделана организация контейнера Google Tag Manager:

• Удалены все устаревшие или неиспользуемые теги, триггеры и переменные;
• Сам трекинг был перестроен по принципу одно логическое действие — один тег.

Про последний принцип расскажу чуть более подробно.

Часто встречал такие кейсы, когда начинающие web-аналитики настраивали по несколько десяткой тегов и триггеров для каждого нужного им события привязываясь к различным идентификаторам и классам того или иного элемента html-разметки. Из-за чего на контейнер GTM становилось страшно смотреть и в нем невозможно было разобраться не посвятив этому целый день.

А правильным подходом является разделение всех действий происходящих в контейнере на несколько логических этапов:

• Просмотр страницы;
• Событие на странице;
• Отправка конверсии во внешнюю рекламную систему;
• и тп.

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

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

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

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

// Где вместо переменных {eventCategory} и тп, подставляются необходимые параметры
dataLayer.push({
  'event': 'mainEvent',
  'eventCategory': '{eventCategory}',
  'eventAction': '{eventAction}',
  'eventLabel': '{eventLabel}',
  'eventValue': {eventValue}
});

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

Автоматизация отчета и появление хранилища данных

Когда была приведена в порядок utm-разметка и система событий, я перешёл к основной задаче, а именно автоматизации отчета по платному трафику.

Отчет представлял собой Google Sheets со сводной статистикой по рекламным кампаниям за вчерашний день и содержал в себе данные по:

• Показам;
• Кликам;
• Расходам;
• Сеансам;
• Конверсиям;
• Доходу;
• И ROMI.

Чтобы собрать отчет необходимо было вручную выгружать данные по расходам из кабинетов Google Ads и Яндекс Директ, а данные по сессиям из Google Analytics. Потом выгружать и добавлять в таблицу данные по продажам из продуктовых баз.

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

Необходимо было решить несколько проблем:

1. Завести аналитическую базу данных для сбора всей информации;
2. Объединить все расходы в одном месте, чтобы не приходилось ходить по кабинетам;
3. Загрузить в базу данных информацию по расходам, сессиям и событиям;
4. Продублировать в аналитической базе данные из продуктовых баз;
5. Настроить облачный Power BI для визуализации отчетности.

В компании была лицензия на MS SQL Server, поэтому выбор пал на эту базу. Тогда мне казалось, что база данных может быть любая и не имеет значение какая именно, но в будущем такой подход вышел боком (о чем расскажу в следующей статье). Поэтому есть у вас есть возможность, то выбирайте что-то облачное и масштабируемое в плане нагрузок.

Проблема сбора и загрузки расходов в единое место решилась достаточно просто. Был выбран вариант интеграции Google Analytics с OWOX Pipeline за его дешевизну и простоту. Достаточно было нажать пару кнопок, немного подождать и все расходы по digital-кампаниям появились в интерфейсе GA (подробнее о настройке тут).

Для получения данных из Google Analytics был написан коннектор, который ежедневно загружал в базу данных свежую информацию по сессиям, событиям и расходам. Обновление происходило ночью за предыдущий день, что позволяло уже утром видеть как отработали рекламные кампании и принимать решения по их оптимизации. Также коннектор позволял ретроспективно обновлять данные за последнюю неделю, так как довольно часто на стороне рекламных кабинетов происходит пересчет затрат на рекламу.

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

Все данные были собраны и оставалось дело за малым — написать SQL-процедуры отчетов, поставить их на обновление и визуализировать в Power BI. Про это в блоге есть подробнейшая статья «Автоматизация отчетности при помощи SQL и Power BI».

Итоги

Базовая аналитика была построена. Это позволило объединить данные о расходах, трафике и событиях на сайте с продуктовыми данными содержащими информацию о доходах, чтобы посчитать ROMI.

В следующих статьях я расскажу про появление полноценного Data Warehouse, о начале мобильной аналитики и создании собственной платформы A/B-тестов.