Как обновить отчеты для Google Analytics 4 без головной боли

Пользователям Google Analytics Universal (GAU) летом 2023 года придется перейти на Google Analytics 4 (GA4). Основная проблема заключается в том, что модель данных и логика расчета метрик в GA4 радикально отличаются от GAU. После перехода на GA4 часть исторических данных будет храниться в структуре GAU, а новые данные будут храниться в структуре GA4. По этой причине предприятия должны приложить серьезные усилия для оценки годовых (годовых) показателей после перехода (не менее 100+ часов работы для аналитиков данных среднего уровня).

Для аналитиков это означает, что они будут тратить день за днем ​​на написание и упорядочивание страниц SQL-запросов, чтобы достичь соответствия между метриками Google Analytics Universal и Google Analytics 4. Однако есть способ обойти это! Аналитики могут создавать специальные отчеты за считанные минуты, не переписывая постоянно SQL-запросы, и в этой статье мы расскажем вам, как это сделать.

Universal Analytics прекратит свое существование 1 июля 2023 г. и будет заменена Google Analytics 4. Для клиентов Google Analytics 360 (платная версия GA) переходный период продлен до 1 июля 2024 г. Но это не имеет значения. какую версию GA вы используете, это только вопрос времени, когда ваши отчеты будут обновлены до новой схемы данных.

В свете этого перехода одной из самых сложных задач для аналитиков является предоставление данных из Google Analytics Universal и Google Analytics 4 в унифицированном формате.

Обстоятельства, усложняющие эту задачу:

• Логика расчета метрик существенно различается между GAU и GA4. Примечательно, что эти версии продукта по-разному рассчитывают даже традиционные показатели. Вы не можете перетащить все показатели из GAU и GA4 в один график и ожидать, что все пройдет гладко.
• Схемы данных Google BigQuery также существенно отличаются. Universal Analytics применяет схемы данных на основе сеансов, тогда как Google Analytics 4 использует схемы данных на основе событий.
• Информационные панели включают показатели за год и тенденции сезонности. Итак, вопрос в том, как продолжать использовать информационные панели со всеми этими показателями.

Давайте рассмотрим конкретный пример. Скажем, у нас есть эта панель инструментов:

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

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

Следует также учитывать риски перехода. После переноса отчета на новый источник (из GAU в GA4) аналитики могут не учесть принципиальных отличий в схеме данных и логике расчета метрик. Например, сеансы формируются по-разному: в GA4 рассматривается только первый пользовательский источник, а все остальные источники, ведущие к сеансу, игнорируются. Поэтому некоторые источники трафика не будут видны в отчете.

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

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

В OWOX мы уже успешно решаем подобные задачи по переносу отчетов наших клиентов из схемы данных Universal Analytics (или GA 360) в схему данных Google Analytics 4. Вот почему мы хотим поделиться нашим решением и некоторыми SQL-запросами с читателями нашего блога. Надеюсь, эта информация поможет вам перенести отчетность без головной боли.

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

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

Существует четыре объекта — «Действия», «Пользователи», «Сеанс» и «Онлайн-конверсия» — и три соединения: «один ко многим» между сеансами и действиями, «один ко многим» между пользователем и онлайн-конверсиями и «один ко многим» между сеансами и действиями. онлайн-конверсии.

Модель данных отражает наше восприятие реального мира и отвечает на такие вопросы, как«О чем наши данные?».Как это связано?Какие условия и ограничения мы применяем при работе с данными?Модель данных необходима для того, чтобы люди четко понимали друг друга.

Моделирование данных — это процесс преобразования данных в формат, отвечающий требованиям вашей модели данных.

• Повысьте ценность и эффективность аналитической работы за счет:
• Ускорение внесения изменений в структуру отчетов и логику расчета метрик
• Снижение затрат на поддержку отчетов и дашбордов
• Упрощение обсуждения и утверждения отчетов
• Повысьте качество данных в отчетах за счет:
• Исключение дублирования при реализации логики расчета параметров и метрик
• Наличие одного слоя данных, который является источником точных данных

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

OWOX BI преобразует необработанные данные в готовый к аналитике формат, экономя часы на подготовке данных. Он легко интегрирует данные Universal Analytics и Google Analytics 4 в ваши отчеты.

Вот пример модели данных, построенной на основе данных Google Analytics:

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

Самое интересное и важное здесь то, что структура этих объектов никак не связана между собой и никак не связана с источниками данных. Неважно, какие источники используются для наполнения этих объектов живыми данными (Matomo, Adobe, Google Analytics и т. д.). Независимо от источника данных модель возвращает те же объекты, что и модель данных, представляющая ваш бизнес. Он иллюстрирует реальные объекты и показатели, с которыми вы работаете.

Давайте посмотрим, как это выглядит в реальном мире.

Вместо написания SQL-запросов поверх необработанных данных, таких как сеансы, экспортированные из Universal Analytics, или события, экспортированные из Google Analytics 4, вы можете создавать смоделированные данные. Это универсальные и простые для понимания таблицы, которые представляют объекты и сущности из реального мира, такие как сеансы, пользователи и просмотры страниц.

Рассмотрим конкретные примеры и схемы данных.

Вот пример необработанных данных. Это скриншоты схемы данных из Google BigQuery для Google Analytics Universal (слева) и Google Analytics 4 (справа).

Как мы писали выше, схемы данных различаются. Нам нужно найти способ связать эти данные с панелью инструментов Google Data Studio.

Исходя из нашего опыта, построение смоделированных таблиц — лучший способ упростить подготовку данных. Вот как они могут выглядеть:

Это списки объектов из приведенной выше модели данных. Вы можете видеть, что список объектов одинаков для Google Analytics 360 и Google Analytics 4.

Это означает, что вы можете связать запрос панели мониторинга с этими данными, используя те же запросы. Структура этого запроса такая же.

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

1. Данные похожи на фрукты: вы должны очистить их перед смешиванием.Аналитики собирают данные из разрозненных сервисов и систем. Естественно, структура и формат этих данных различаются в зависимости от источника. Для построения отчетов необходимо правильно объединить данные из разных источников. Сами по себе данные, загружаемые через коннекторы или различные ETL-сервисы, являются неточными (содержат ошибки, дубликаты и несоответствия), не имеют единой логики и структуры. Неточные и фрагментированные данные должны быть очищены и приведены в формат, пригодный для аналитики.

С OWOX BI вам не нужно вручную очищать, структурировать и обрабатывать данные. Сервис автоматически нормализует необработанные данные в формат, готовый для аналитики.

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

• Дедупликация транзакций
• Фильтровать бот и внутренний трафик
• Определить правила группировки каналов
• Определите критерии для новых и постоянных пользователей
• Исправить отслеживание параметров UTM

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

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

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

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

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

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

1. Смоделированные данные — это еще один средний слой.Для настройки требуется время, и вы также должны отслеживать и отлаживать смоделированные данные.

2. Сложные JOIN для нормализации.

3. Дополнительная обработка данных.Чтобы преобразовать данные в формат модели, вы должны запросить данные. Советуем использовать таблицу разделов на дату. С таблицей разделов, построенной на основе измерений даты, вы можете обновлять только необходимые данные. Вам не нужно переписывать все огромные таблицы и платить за все обработанные данные и гигабайты или терабайты данных в Google BigQuery. Вы можете просто обновить и обновить нужный вам раздел. Этот подход более экономичен, чем обработка всех таблиц данных.

Чтобы помочь вам справиться с этими недостатками, мы подготовили шаблоны SQL для моделирования данных Google Analytics 360 и Google Analytics 4. Вы можете ознакомиться с ними, скачав дополнительные материалы, представленные в этой статье.

Насколько легко обновить отчеты до новой схемы данных Google Analytics 4? Используйте смоделированные данные. Вместо создания отчетов на основе необработанных данных вы можете создавать универсальные и простые для понимания плоские таблицы поверх схем GA Universal и GA 4.

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

Подпишитесь на демонстрацию OWOX BI, если хотите настроить и оркестровать смоделированные таблицы. Мы с удовольствием поделимся подробностями о том, как подготовить подобные таблицы в ваших проектах на основе ваших данных.