Песочница

Как объединять данные при создании отчета в Data Studio

Всем привет, меня зовут Павел Мрыкин, я эксперт по сквозной аналитике в Calltouch. 

Было время, когда я не пользовался готовыми сервисами для создания отчётов и создавал отчёты в Google Таблицах, Google Data Studio, Power BI и находил в этом определённые плюсы. Главный из них это гибкость.

Именно из-за гибкости, а ещё из-за бесплатности многие специалисты выбирают для автоматизации отчётности Google Data Studio. Но часто сталкиваются с одной и той же проблемой объединение данных из нескольких рекламных каналов. В качестве решения часто пытаются использовать функцию «Объединение данных», но ни к чему хорошему она не приводит и на этом создание отчёта стопорится.

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

Способы объединения данных при создании отчёта

Прежде чем разбираться со способами объединения, нужно сначала понять, что мы будем объединять.

Чаще всего у нас есть следующие данные:

  1. Расходы из Яндекс.Директ.
  2. Расходы из Google Ads.
  3. Цели из Google Analytics.
  4. Заказы из CRM.

Таким образом у нас получаются данные трёх типов: 

  1. Рекламные площадки.
  2. Системы аналитики.
  3. CRM.

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

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

кампании

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

  1. Расходы из двух рекламных кабинетов.
  2. Целевые действия из системы аналитики.
  3. Заказы из CRM-системы.

Между собой таблицы мы будем связывать на основе трех параметров: даты, источника трафика и идентификатора рекламной кампании (Campaign ID). Предполагается, что в наших данных они уже есть. Как передать этот идентификатор в систему аналитики и CRM-систему тема отдельной статьи.

Первый способ объединения. Расходы + Аналитика

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

лефт джоин

При использовании языка запросов SQL это называется LEFT JOIN. В этом случае между обеими таблицами ищутся соответствия по заданному ключу и из первой таблицы остаются все строки, а из второй таблицы только те, по которым были найдены соответствия с первой. Итого, из двух таблиц, которые представлены ниже:

площадки+системы

У нас должна получиться одна:

сквозная отчетность

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

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

Минусы:

  1. В отчёте отображаются данные только по рекламным площадкам, т. к. таблица с этими данными используется в качестве той, к которой «цепляются остальные». Если для вас или клиента важны также данные по органике, по переходам из социальных сетей, которые не связаны с рекламными каналами их в отчётах не будет.
  2. Если клиент совершил клик по рекламной кампании первого февраля, а потом вернулся на сайт из закладки второго февраля и совершил новые целевые действия, то по этой рекламной кампании переход второго февраля засчитан не будет. Поэтому при сведении данных показатели из системы аналитики за второе февраля просто будут отброшены.

Второй способ. Аналитика + Расходы

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

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

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

  1. Клик по рекламному объявлению не гарантирует сессию. С вас могут списать деньги, но это не значит, что клиент не закроет сайт раньше загрузки счётчика или что на той странице вообще счётчик будет установлен.
  2. Клиент мог кликнуть по кнопке «показать телефон» в рекламной выдаче. Соответственно, клик засчитается, а перехода не будет.

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

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

Например, клиент пришел на сайт первого февраля, сделка закрылась 10-го. В большинстве случаев такую сделку привяжут к расходам и целевым действиям от 10-го февраля, что в корне ломает представление о воронке на сайте. Можно ли корректно связать сделку с сессией и расходами от первого февраля? Можно, однако это уже совершенно другой уровень аналитики, для этого лучше использовать облачные базы данных типа BigQuery или Clickhouse или готовые сервисы сквозной аналитики, которые сводят данные не просто по дате и источнику трафика, а с учётом данных о пользователе, его сессий и действий на сайте.

В заключение

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

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

10
4
2
Обнаружили ошибку? Выделите ее и нажмите Ctrl + Enter.

Комментарии (0)

Последние комментарии

    Чтобы оставить комментарий, нужно войти

    Чтобы оставлять комментарии, переключитесь на профиль читателя

    Подписаться

    на самую полезную рассылку по интернет-маркетингу

    Самое

    обсуждаемое популярное читаемое
    Cookies policy
    Просматривая этот сайт, вы соглашаетесь с нашей политикой конфиденциальности — Принять