Все давно привыкли, что в статистических отчетах можно встретить выражение вроде "заболеваемость от COVID19 составила 10.5 случаев на 1000". И это вовсе не означает, что автор отчета намекает на то, что существуют какие-то полу-заболевшие полу-люди, также это не означает, что расчеты, лежащие в основе отчета, неверны, потому что случай заболевания или есть, или его нет.

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

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

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

Отчет об эффективности рекламных источников - это довольно простая таблица, в которой затраты и достижения представлены в какой-то разбивке по параметрам. Например, вот в такой:
Таблица 1. Пример отчета с расходами и достижениями:

В данной статье мы рассмотрим два совершенно разных подхода к построению такого отчета.

Из рекламных кабинетов при помощи ETL-коннектора можно получить данные о расходах в разбивке по utm-меткам:

В свою очередь, на стороне сайта при помощи счетчика UA/GA4/Yandex можно получить результаты приземлений этой рекламы в той же разбивке по utm-меткам.

Таблица 3. Данные посещаемости сайта

Если объединить эти две таблицы по общим ключам, которыми, в данном случае, являются UTM-метки, можно получить отчеты по всем возможным комбинациям UTM-меток:

Таблица 4. Отчет по source/medium

Таблица 5. Отчет по campaign

К достоинствам такого подхода, несомненно, относится кажущаяся простота построения ну и то, что клики и показы все еще целые.

А вот недостатки имеются, и довольно серьезные.

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

Например, вот так выглядит отчет в Universal Analytics по source/medium

А вот что будет, если добавить в этот отчет параметр device category, который есть только в данных Google.Ads, а в наборе данных от Яндекса этот параметр отсутствует:

Видно, что данные, которые не содержали треубемый параметр, были исключены из отчета, о чем свидетельствует не слишком заметная надпись "% of Total: 53.75%".

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

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

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

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

В этом подходе предполагается, что вы имеете доступ к исходным данным о поведении пользователей, которые сейчас проще всего получить при помощи нативного экспорта из Google Analytic 4 в Google Bigquery или при помощи других, имеющихся на рынке, Saas-сервисах.

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

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

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

Достоинства такого подхода:

1. Вы можете строить отчеты по любым немыслимым комбинациям параметров, при этом полученные данные всегда будут корректны и полная выборка без применения фильтров всегда будет содержать все расходы и все доходы, что исключает ошибку интерпретации, которую мы продемонстрировали выше на данных из UA
   
   
2. Вам становятся доступны отчеты по когортам, включая когортные расходы с доходами и расходами.
   
   
3. Поскольку данные в разрезе отдельных пользователей можно сопоставить с информацией о пользователях из вашей CRM, вы можете определить, как распределяются ваши маркетинговые усилия на разные группы пользователей (новые, добавившие в корзину, недавно купившие, давно купившие, женщины/мужчины, члены клуба и т.д.) и какова эффективность этих усилий на разных этапах жизненного цикла пользователей и, как было сказано выше, в любых разрезах.
   
   

Разумеется, у такого подхода есть и свои недостатки:

1. Ничего не бывает даром, и в этом случае это высказывание актуально как никогда. Дело в том, что этот подход не только сложнее, но и дороже в плане цены вычислений, поскольку обновление данных (а мы в своих решениях базируемся на Google Bigquery) - это довольно затратная операция. Вероятно, это одна из причин, почему отчеты в Google Analytics строятся только по агрегированным данным - цена ретроспективного обновления слишком высока.
   
   
2. Может сложиться ситуация, когда абсолютно неэффективная рекламная кампания, которая не привела на сайт ни одного посетителя, скроется от вашего внимания, потому что ее расходы будут распределены алгоритмом на уровень выше, то есть на все другие кампании. Для избежания подобной ситуации вам нужно не забывать использовать "обычные" отчеты по агрегированным данным.
   
   
3. В отчетах появятся дробные значения для кликов и показов ))