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

В этом разделе разберём все операции с данными, которые нужно сделать перед экспортом в Google Таблицы.

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

Например, из кабинета выгружаются: дата, ID кампании, показы, клики и расход; из аналитики — дата, ID кампании, конверсии и доход. Мэтчим по дате и ID кампании — и всё готово.

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

В этом уроке нам нужно смэтчить данные из Ozon и из AdRiver. У каждой системы есть свои подводные камни, которые мешают просто взять и объединить выгрузки. Сначала пошагово разберём, что сделать с данными из Ozon, затем — с данными из AdRiver, а после отдельно рассмотрим другие ситуации, не актуальные для этого проекта, но полезные в работе.

В Ozon нельзя выбрать нужные столбцы при выгрузке, поэтому система отдаёт «лишние» данные, не пригодные для построения дашборда.

Самый удобный и правильный способ очистить выгрузку — создать сводную таблицу. Но почему именно сводную?

В принципе, если нужно удалить только пару ненужных метрик (например, Ozon выгружает CTR, но мы будем рассчитывать его позже — уже в Google Таблице), можно просто убрать их через блок формулы. Для этого нажми на «X» напротив столбца, который хочешь удалить. После этого «X» сменится на стрелочку, при нажатии на которую столбец вернётся на место:

Но Ozon выгружает ещё и лишние параметры, например разбивку по месту показа (attributesPlatform), то количество строк в отчёте увеличивается. У каких-то кампаний за конкретную дату вместо одной строки получится две:

Во-первых, это без необходимости раздувает объём данных и замедляет работу JetStat. Во-вторых, такая разбивка иногда приводит к ошибкам при мэтчинге с данными из аналитики.

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

В нашем случае мы будем использовать:

• date (дата);
• campaign_id (ID кампании);
• views (показы);
• clicks (клики);
• moneySpent (расход).

Для параметров выбираем операцию «группировать», а для метрик — «сложить». В результате показатели будут суммироваться внутри каждой группы и для каждой даты. Выглядит это так:

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

Рассчитаем блок и посмотрим на результат:

В конце можно переименовать блок для удобства работы:

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

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

Обычно в выгрузке из рекламного кабинета (например в Яндекс Директе) уже есть название кампании и сегменты можно сформировать внутри JetStat с помощью блока «Сегменты» (позже расскажем как), но так как это не наш случай, мы пойдём другим путём. Самый простой вариант — это завести вручную на проекте таблицу соответствий и использовать её. Пример:

В этой таблице есть:

• ID кампании (Ozon);
• название кампании (Ozon);
• ID баннера (AdRiver), который соответствует этой кампании;
• название баннера (AdRiver);
• сегменты.

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

Для импорта данных из Google Таблицы в JetStat используется блок «Google Таблицы» из раздела «Источники»:

Добавляем файл через соответствующую кнопку. Для этого нужно войти в свой Google-аккаунт. Ранее подключённые файлы появятся в списке — просто выбираем нужный.

В этом блоке минимум настроек:

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

В нашем случае всё оставляем по умолчанию — как на скрине:

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

В нашем случае стоит изменить тип данных у двух столбцов с ID — с «текст» на «число»:

После этого сохрани настройки и запусти расчёт блока.

В конце можно переименовать блок для удобства:

Если бы мы работали в Excel или Google Таблицах, мы бы сейчас использовали функцию ВПР, чтобы подтянуть к выгрузке из кабинета данные по сегментам.

В JetStat для мэтчинга двух таблиц используется специальный блок — «Пересечение». Он заменяет функции ВПР / VLOOKUP, а также СУММЕСЛИ / СУММЕСЛИМН.

У блока два входа: левый (Left) и правый (Right):

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

Тем не менее, для удобства рекомендуем придерживаться следующей логики:

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

Открой настройки блока «Пересечение» — и первое, что ты увидишь, это выбор типа соединения (Join).

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

Закрашенная часть — это то, что получится в результате пересечения двух таблиц (левой и правой) при данном типе.

Мы не будем разбирать все типы соединений — это задание на твою самостоятельную проработку.

Но если тебе нужно соединить таблицы по принципу «взять всё из основной и добавить к ней информацию из второй» — то есть аналогично тому, как работают ВПР или СУММЕСЛИМН в Excel — тебе подойдёт тип соединения Left Outer Join:

Он похож на микс из обоих, но при этом работает по-своему.

Как СУММЕСЛИМН, Left Outer Join позволяет использовать несколько параметров для мэтчинга — например, дату и название кампании одновременно.

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

Но в отличие от ВПР, Left Outer Join не останавливается на первом совпадении. Он продолжает проходить весь список. Это поведение похоже на СУММЕСЛИМН, но с одним отличием: данные не суммируются, а выводятся построчно.

Представим, что у нас есть статистика из рекламного кабинета:

А вот статистика из системы аналитики:

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

Если мы используем ВПР, то Excel подтянет только первое совпадение, а вторую строку просто проигнорирует:

Если мы используем СУММЕСЛИ/СУММЕСЛИМН, Excel просуммирует оба значения по заданным условиям:

А вот если мы используем Left Outer Join в JetStat, то обе строки из аналитики будут добавлены в таблицу как отдельные строки:

Поэтому важно всегда проверять, сколько строк вошло в блок «Пересечение» и сколько вышло.

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

Например, если ты соединял по дате и названию кампании, то и в сводной оставь только эти два параметра и нужные метрики (например, конверсии). Конверсии просуммируются и проблема уйдёт.

Мы уже видели это выше на примере выгрузки из рекламного кабинета Ozon. С аналитикой происходит то же самое.

По умолчанию в JetStat чувствительность к регистру включена.

Это значит, что названия вроде campaign_A и Campaign_A будут считаться разными значениями. Нужно ли это отключать — зависит от тебя и твоего проекта.

Далее настраиваются выходы из блока:

По умолчанию блок «Пересечение» добавляет префиксы ко всем столбцам из левой и правой таблиц в финальной таблице (join):

Выглядеть это может, например, так:

Нужно это тебе или нет — решай сам.

Общая рекомендация такая: если таблица простая и ты точно не запутаешься, можно отключить.

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

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

Если ты хочешь задать несколько условий (например, дата + название кампании) — просто повторяешь действия: выбираешь следующий параметр слева и ему в пару — соответствующий параметр справа:

В нашем случае мы объединяем данные по одному параметру — ID рекламной кампании Ozon:

По умолчанию блок «Пересечение» включает в выходную таблицу все столбцы из обеих таблиц.

Посмотреть это можно в правом окне «Таблица на выходе» — все активные (добавленные) столбцы будут подсвечены синим.

Если часть столбцов тебе не нужна — просто отключи их, чтобы не перегружать отчёт лишними данными.

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

Часто имеет смысл отключить в правой таблице столбцы, по которым выполнялся мэтчинг — они дублируют данные из основной таблицы. Однако есть нюанс: если названия столбцов в левой и правой таблицах совпадают, JetStat сам определит, что это дубли, и не добавит их в итоговый результат.

Но если пересечение делалось наспех и столбцы названы по-разному (например, в одной таблице «date», а в другой — «day»), то лишний столбец стоит удалить вручную.

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

Рассчитаем блок и посмотрим, что получилось:

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

Но при объединении данных из рекламного кабинета и аналитики часто возникают разные проблемы.

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

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

• возможно, нужные данные для этих кампаний находятся в другой системе аналитики (или в другом аккаунте);
• возможно, ошибка в нейминге — названия в кабинете и аналитике не совпадают;
• может быть, это товарные кампании и поэтому в AdRiver нет данных по конверсиям;
• или есть другие технические причины.

Другая ситуация — на выходе таблицы строк стало больше, чем было на входе. Мы уже упоминали это выше, но повторим. Речь идёт о случае, когда в правой таблице есть несколько строк, подходящих под условия мэтчинга, и в итоге мы получаем нечто такое:

Поскольку блок «Пересечение» не умеет агрегировать данные, как это делают функции СУММЕСЛИ или СУММЕСЛИМН, он просто добавляет новые строки, дублируя данные из основной таблицы. Исправляется это предварительной группировкой (агрегацией) данных второй таблицы перед пересечением.

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

Для этого используем блок «Формулы». Мы уже применяли его раньше для удаления лишних столбцов, но его возможности гораздо шире. Это один из самых гибких и функциональных блоков в JetStat. С его помощью можно:

• выполнять математические расчёты — например, посчитать расход с НДС или АК, вычислить ДРР, CPL и т. д.;
• работать с текстом — удалить часть строки, добавить префикс, вырезать нужный фрагмент или заменить символы;
• задавать логические выражения — например, «если ... то ...»;
• преобразовывать форматы — например, привести ID к числу;
• менять порядок и названия столбцов.

Чтобы изменить тип данных (или переименовать столбец), выбери нужный столбец и нажми зелёную кнопку «Редактировать»:

После этого откроются настройки — меняем тип с «текста» на «число» и нажимаем «Сохранить»:

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

В конце рассчитываем блок и переименовываем для удобства:

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

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

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

В нашем случае отсортируем даты по возрастанию:

Результат:

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

В JetStat период отображения данных задаётся в левом верхнем углу, в разделе «Диапазон дат». Эта настройка определяет, за какой промежуток будут формироваться все данные в отчёте.

Один из доступных вариантов — выбрать конкретные даты начала и окончания. Такой вариант называется «фиксированный» и используется, когда нужен отчёт за строго определённый период, например, с 1 по 31 января:

Также можно задать динамическое обновление периода, выбрав «относительный» вариант:

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

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

Последняя функция — это «Расписание». Она позволяет настроить автоматическое обновление отчёта с нужной периодичностью, что особенно удобно для автоматических дашбордов и регулярного мониторинга:

В этом уроке мы часто упоминали мэтчинг данных из рекламного кабинета и системы аналитики. И делать это действительно можно прямо в JetStat с помощью блока «Пересечение». Однако такой подход подходит только для простой performance-атрибуции по модели Last Click.

Когда речь идёт о Post-view или Post-click, всё становится сложнее: дата фактической конверсии и дата показа объявления часто не совпадают. Разница может достигать до 30 дней — в зависимости от окна атрибуции на проекте.

То есть просто сопоставить данные по дате и названию кампании не получится: в какой-то момент показы в рекламном кабинете заканчиваются (кампания останавливается), а конверсии продолжают поступать ещё некоторое количество времени (в нашем примере — 14 дней). Эти конверсии (их называют докаты) уже нельзя будет мэтчить по дате, ведь таких дат в выгрузке из кабинета просто нет.

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

Добавь блок Google Таблиц (экспорт) в отчёт. В настройках блока ты можешь создать новый файл или добавить выгрузку в уже существующую таблицу.

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

Если нужно добавить данные в уже существующую таблицу, то:

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

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

Ниже расположена ключевая настройка — «Режим записи».

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

Другой режим — «Дозапись в конец».

После его выбора появляется дополнительное меню «Столбец замены». Здесь нужно указать столбец с уникальными значениями, например «Дата»:

При выгрузке за новую дату JetStat проверит этот столбец:

• если дата отсутствует, строка с данными добавится в конец таблицы;
• если дата уже есть, старая строка удалится, а новая запишется на её место.

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

• дата — фиксированная;
• период — весь флайт плюс окно атрибуции для докатов (например, если флайт идёт весь октябрь, а окно атрибуции две недели, период ставим 01.10.2025–14.11.2025);
• расписание — ежедневно в 5–7 утра (в это время ниже нагрузка на серверы и меньше риск получить ошибку в процессе расчёта);
• режим записи — перезапись.

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

Однако если флайт длится больше двух месяцев или является always-on кампанией, имеет смысл периодически сохранять исторические данные. Это позволяет не гонять JetStat на сбор больших периодов каждый раз, особенно если объём данных значительный.

Для таких долгосрочных кампаний есть альтернативная комбинация настроек: относительный период выгрузки, например «за прошлый день», и режим записи «дозапись в конец». В этом сценарии JetStat будет собирать данные только за последние сутки (автоматически «сдвигая» период) и добавлять их в конец сырой выгрузки. Вручную сохранять историю не потребуется, потому что старые строки не будут затираться.

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

Рассчитываем блок с настройкой «перезапись» и смотрим на результат в Google Таблице:

Всё отлично, можно переименовать блок для удобства: