Готовый отчёт с примерами из этой части урока уже настроен и доступен для просмотра (редактировать его ты не сможешь).

Продолжаем готовить выгрузку в JetStat для построения автоматического дашборда. В прошлом разделе мы обработали данные из рекламного кабинета, теперь настала очередь AdRiver.

В целом шаги те же: очистить данные, добавить сегменты, привести всё в порядок, отсортировать и экспортировать результат в Google Таблицу. Однако очистка данных в этом случае немного сложнее — выгрузка из AdRiver содержит несколько подводных камней, о которых стоит знать заранее.

На этом проекте у выгрузки из AdRiver есть одна неприятная особенность — дубли. Посмотри на пример ниже и обрати внимание на столбец «user id»:

Видишь, с 4 по 11 строку повторяются одни и те же user id и дата показа (ad datetime), но различается время конверсий (conv datetime)? Это и есть дубли. По какой-то причине трекинговая система ошибочно фиксирует несколько конверсий для одного и того же пользователя. Такое встречается на разных проектах.

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

Подключаем блок «Группировка» и в настройках добавляем четыре столбца:

У тебя может возникнуть несколько вопросов.

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

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

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

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

Чтобы стало понятнее, вот как примерно выглядит дашборд, когда рекламные кампании уже остановлены, но в течение окна атрибуции продолжают приходить конверсии:

Серая зона — это и есть зона докатов. В этот период уже нет показов, кликов и расходов, но продолжают приходить конверсии и доход.

Теоретически тебе может попасться проект, где принято отслеживать данные иначе — в таком случае придётся использовать ad datetime, а не conv datetime.

Как ты уже знаешь, уровень баннера в AdRiver обычно соответствует уровню кампании в Ozon. Поэтому в Google Таблицах мы будем мэтчить данные именно на уровне баннера. Всё, что выше или ниже по иерархии, нам уже не нужно.

В выгрузке из AdRiver есть три столбца с конверсиями:

• pv conversions (post-view конверсии);
• pc conversions (post-click конверсии);
• total conversions (сумма двух предыдущих).

Дальше можно действовать по-разному:

• если на проекте используются только post-view или только post-click конверсии, можно выгружать соответствующий столбец или total — результат будет одинаковым;
• если на проекте есть и post-view, и post-click, и их важно различать, нужно добавить оба столбца.

На проекте из примера фиксируются только post-view конверсии, поэтому мы используем столбец total conversions.

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

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

Что произойдёт при такой конфигурации? Система схлопнет все дублирующие строки, оставив только одну — ту, где максимальное значение даты. При этом неважно, что дата конверсии может быть одинаковой (обычно различается только время) — JetStat просто оставит одну строку, а какая именно останется, для нас не принципиально.

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

После расчёта посмотри, как уменьшилось количество строк. В нашем случае было 2206, а стало 1932.

И по традиции задаём блоку понятное, читаемое название:

Теперь нужно извлечь доход из столбца «site_custom_string». Для этого воспользуемся блоком «Формулы». Как уже упоминалось, этот блок универсален и отлично подходит и для такой задачи.

Подключаем блок и создаём новый столбец:

Далее задай имя нового столбца, укажи тип данных и выбери из списка посередине функцию regex_extract:

Данная функция вытаскивает из текста часть данных согласно регулярному выражению.

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

Забегая вперёд, можно сказать, что с помощью двух функций — regex_extract (извлечь текст) и regex_replace (заменить текст) — можно выполнить почти все операции с текстом, которые встречаются в работе. Главная сложность обычно не в самих функциях, а в том, чтобы составить правильное регулярное выражение. Чем сложнее задача, тем изощрённее должна быть «регулярка».

Раньше для таких случаев приходилось обращаться к коллегам или разбираться в справочниках по синтаксису регулярных выражений. Сейчас можно обратиться к чату GPT — он подскажет подходящее решение. Иногда он может немного ошибиться в деталях синтаксиса JetStat (например, использовать вместо «;» запятую или поставить ’регулярное выражение’ вместо ”регулярное выражение”), но суть решения при этом будет верной.

В нашем случае именно с помощью чата GPT мы нашли нужную формулу. Исходная строка выглядит так:
10=4003403;150=1597898534;151=15291

Доход зашивается в переменной 151, значит, нам нужно вытащить значение, которое идёт после «151=». Решение:
regex_extract([site_custom_string]; "151=([0-9]+)")

Разберём по частям:

• [site_custom_string] — это столбец или строка, в которой ищут нужный кусок текста;
• "151=([0-9]+)" — регулярное выражение, определяющее, что нужно найти;
• 151= — находит место, где стоит «151=»;
• ([0-9]+) — выбирает все подряд идущие цифры после знака «=».

Добавь регулярку в поле «выражение»:

После этого сохрани новый столбец и через вкладку «Быстрый просмотр результатов» посмотри, как сработала функция (при необходимости нажми кнопку «обновить»):

Как видно, доход удалось корректно извлечь. Если бы формула была полностью некорректной, появилось бы уведомление о невозможности выполнить предварительный расчёт. А если бы формула была синтаксически верной, но не находила нужное значение, то в столбце «доход» отобразились бы серые пустые ячейки.

Теперь нужно удалить столбец «site_custom_string», так как он больше не нужен. Но как это сделать, ты уже знаешь:

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

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

То есть на одну дату и один ID баннера приходится несколько строк. Эти строки нужно схлопнуть (сложив конверсии и доход), оставив только одну.

Кстати, у этого проекта есть ещё одна особенность, из-за которой строк становится ещё больше: конверсии приходят сразу с двух сайтов — М.Видео и Эльдорадо, так как клиент владеет обоими брендами. Вот как это выглядит в исходной статистике (обрати внимание на последний столбец):

Чтобы сделать сводную таблицу, воспользуемся уже знакомым тебе блоком «Группировка», как при обработке данных из Ozon. В нём нужно сгруппировать дату и ID баннера, а метрики — просуммировать:

Количество строк сократилось с 1932 до 305. В конце, как обычно, переименуем блок для удобства:

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

В итоге в Google Таблице получится такая выгрузка: