Google Analytics, сквозная аналитика и мультиканальная атрибуция

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

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

Что они делают?

• ставят на свой сайт счетчик (код) Google Analytics. Данные о визитах клиентов начинают записываться в Google Analytics бесплатно (пока ваш объем визитов на сайт не станет очень большим)
• до-обогащают данные в Google Analytics: передают информацию о транзакциях, достижении других важных целях и событий в их e-commerce
• в самом Google Analytics строят разные отчеты, изучают графики

И это вполне рабочий поход.

Но, есть несколько "но". При таком подходе сырые данные хранятся в Google Analytics и достать их не такая уж простая задача, хотя и возможная (с рядом ограничений вы можете выкачивать данные из Google Analytics по API).

Что еще важнее, так это то, что там со временем накапливается ключевая маркетингово-финансовая информация, и работать с ней через интерфейс Google Analytics становится все тяжелее: вопросы становятся сложнее, а ответов становится все меньше.

Поэтому для построения аналитики платного привлечения я обычно рассматриваю 3 варианта решения (от простого к сложному):

1. сохранение utm-меток в Базу Данных при совершении ключевых действий
2. сохранение Google Analytics clientId в Базу Данных при совершении ключевых действий
3. стриминг всех визитов в распределенную Базу Данных

Почему я расставил их именно в таком порядке?

Дело в том, что аналитика визитов на сайт это большая и сложная тема:

• определить, что такое сессия, с какого визита она начинается и когда заканчивается
• как понять, что эти N сессий это история одного клиента
• из каких рекламных каналов это клиент приходил 
• и т.д. 

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

Поэтому я всегда стараюсь НЕ идти в сторону истории сессионной аналитики и обязательно ставлю код Google Analytics. Так, из коробки, я получаю:

• бесплатное огромное хранилище для визитов, 
• сессионную логику и автоматический парсинг utm-меток
• механизм, с которым знакомы практически все маркетологи и аналитики

Давайте рассмотрим немного подробнее вариант (1).

сохранение utm-меток в Базу Данных при совершении ключевых действий

Этот подход предполагает следующее:

1. вы ставите код Google Analytics к себе на сайт 
2. во время ключевых событий на сайте вы сохраняете utm-метки (откуда этот трафик) в Базу Данных.

Зачем делать так?

Дело в том, что значительная часть ресурсов маркетинга (времени и денег) инвестируется в платное привлечение.

Это значит, что вам нужно понять как окупаются эти инвестиции.

Чтобы ответить на этот вопрос, вам нужно знать следующее:

• с какого канала пришел тот или иной клиент?
• как и сколько этот клиент покупал после регистрации?

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

Поэтому вы можете сделать аналитику окупаемости в несколько этапов:

1. взять данные из рекламных кабинетов в таком формате:
   date, source / medium, campaign
2. взять данные из Google Analytics по количеству новых сессий по каждой комбинации:
   date, source / medium, campaign
3. взять данные из Базы данных о том, кто из клиентов пришел в соответствующий день по соответствующим комбинациях:
   date, source / medium, campaign
4. по каждой регистрации по user_id найти все транзакции этого клиента за нужный вам период из таблицы транзакций 

Это простая задача для среднестатистического аналитика.

Плюс такого подхода:

• минимальные трудозатраты по записывания utm-меток во время ключевых событий (сейчас это можно легко сделать через Google Tag Manager)
• технически очень простой матчинг комбинаций
• легко посчитать окупаемость по модели Last Non-Direct Click (модель атрибуции по умолчанию в Google Analytics) 

Основные минусы:

• нет возможности рассчитывать другие модели атрибуции
• риск попасть в sampling при выгрузке данных из Google Analytics  

Но что, если мы хотим строить рассчитывать окупаемость по другим моделям атрибуциям (и при этом не строить свою сессионную аналитику)?

Тогда остаются варианты (2) и (3) упомянутые выше.

По варианту (3) есть ряд хороших постов от OWOX и продвинутых веб-аналитиков.

Если коротко, сырые данные, которые стримятся на сервера Google Analytics параллельно стримятся в распределенную Базу данных (наиболее распространенные варианты: Google BigQuery, Yandex ClickHouse, Amazon Redshift).

У вас есть сырые данные, а дальше все зависит от техничности вашего аналитика.

Сейчас я рассмотрю вариант (2).

сохранение clientId в Базу Данных при совершении ключевых действий

Этот вариант похож на вариант (1) но есть два важных отличия:

• во время ключевых событий на сайте вы сохраняете Google Analytics clientId в Базу Данных.
• из Google Analytics, вы, ежедневно, скачиваете "сжатый" лог визитов такого вида:
  ga:clientId, ga:countryIsoCode, ga:dateHourMinute, ga:sourceMedium, ga:campaign, ga:sessions, ga:goalNCompletions

 Давайте разберем эти пункты немного подробнее.

Что такое Google Analytics clientId?

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

Раньше этот идентификатор пользователя нужно было перехватывать из кода Google Analytics, вручную сохранять в Custom Dimension и затем обратно отправлять в Google Analytics.

Но, с Августа 2019 года, этот идентификатор появился в Google Analytics API в открытом доступе! Это позволяет вам получать clientId по историческим данным, даже если вы его вручную не передавали.

Зачем забирать лог визитов в формате ga:dateHourMinute?

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

В итоге у вас может быть картинка такого вида:

Google Analytics visits log.

Что мы видим из этой картинки?

1. в день регистрации было три сессии
2. в цепочке до регистрации участвовало 3 канала:
1. google / organic
2. direct / (none)
3. google / cpc
3. канал google / cpc привел к регистрации (goal1Completions = 1)
4. первый визит с этого устройства и браузера был сделан March 8, 2020 9:00:34 PM. Это время берется из clientId (число после точки) и хранится в формате unix epoch time

Плюсы такого подхода:

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

Минусы:

• нет возможности понять историю визитов пользователя без привязки к браузеру/устройству
  (строго говоря, даже стриминг, без дополнительных усилий не позволит вам решить эту задачу)
• для построения модели атрибуции, вам нужно будет выкачать все данные из Google Analytics по дням
• иногда clientId может не правильно записываться в Базу Данных (или вообще не записываться)
  (для надежного матчинга с clientId из Google Analytics нужны дополнительные сигналы - ga:dateHourMinute, ga:countryIsoCode, ga:goalNCompletions)
• риск попасть в sampling при выгрузке данных из Google Analytics

Как можно было бы смягчить минусы этого решения?

1. Сохраняя clientId во время ключевых действий (например логинов), накопить за период в несколько недель пары { device, clientId } и затем ретроспективно объединить визиты разных clientId под одним user_id.
2. Использовать R пакет googleAnalyticsR, который позволяет работать с ситуациями, когда Google Analytics выдает 503 ошибку из-за того, что вы обращаетесь к большому объему данных в Google Analytics и Google не хочет создавать лишнюю нагрузку на свои сервера.
3. Снова использовать R пакет GoogleAnalyticsR, который позволяет сильно смягчить проблему с sampling автоматически перейдя на выгрузку данных за меньшие периоды (вплоть до дня).