Работая над оптимизацией рекламных кампаний в Яндекс Директ, мы столкнулись с несколькими проблемами. У клиента есть многостраничный сайт по продаже электронных подписей. Пользователи заходят на сайт несколько раз, изучают материал, затем могут оставить заявку или позвонить. У нас нет доступа к CRM клиента, поэтому мы не можем отследить дальнейший путь пользователя. Это затрудняет оптимизацию кампаний, так как неизвестно, с каких кампаний были продажи. При отсутствии отчетов по продажам, мы работаем на уровне обращений.
При составлении отчетов по обращениям возникает несколько стандартных проблем:
Ниже показана конфигурация отчета. Параметр ga:dimension1 — пользовательский параметр Client ID. Цели с номерами 4 и 5 — формы на сайте.
После обработки данных, получили таблицу:
После преобразования данных, получили табличку, похожую на приведенную выше, но уже по звонкам:
Складываем заявки и звонки, получая единый столбец — обращения (app). Сводим данные по client_id, дате, источнику, каналу и кампании:
В итоге получили таблицу с Client ID, источниками, каналами и кампаниями, хитами и обращениями. Теперь можно строить модели атрибуции.
В каждой ячейке второго столбца содержится таблица с подробными данными по этому Client ID:
Теперь нужно посчитать суммарное количество хитов по каждому Client ID, чтобы в дальнейшем можно было узнать долю каждого источника.
Используем функцию List.Sum для подсчета общего количества хитов (hits_sum):
Аналогичным способом считаем сумму обращений (app_sum). В итоге получаем два новых столбца:
После чего разворачиваем столбец «Все строки», нажимая на значок справа от названия столбца:
Таблица возвращается к прежнему виду, но теперь у нас есть сумма хитов и сумма обращений по каждому Client ID:
В итоге получаем ценность каждого сеанса в рамках цепочки конверсий. Её нужно умножить на общее количество конверсий по Client ID:
В итоге получили количество обращений по каждой сессии.
В таком методе расчета мы неизбежно получаем дробные значения, так как распределение конверсий идет в соответствии со множеством действий пользователя на сайте.
- пользователи совершают обращение после нескольких визитов на сайт, поэтому модель атрибуции Last Click дает некорректные данные
- заявки и звонки часто совершаются одним и тем же пользователем, что приводит к дублированию данных и ошибкам в расчетах итоговых показателей
- клиент хотел бы видеть данные по обращениям (включая звонки) в едином отчете
- вопрос выбора модели атрибуции, которая наиболее точно покажет вклад каждого источника в конверсию
- стандартный API Google Analytics не отдает данные в заданных моделях атрибуции
- не все звонки корректно передавались в Google Analytics
Реализация
1. Client ID
Нужно добавить Client ID в Google Analytics. Это основной параметр для сведения данных и построения моделей атрибуции. Из всех инструкций по установке Client ID, мы выбрали метод Simo Ahava. После сбора статистики по Client ID в течение нескольких месяцев, получили данные для анализа.2. Big Analytics Data
Для выгрузки данных по API из Google Analytics мы выбрали инструмент Big Analytics Data. Он бесплатный, удобный, позволяет регулярно обновлять данные. Также, он показывает семплирование данных и позволяет его обходить. Работает как дополнение к Google SpreadSheets, устанавливается аналогично:
Ниже показана конфигурация отчета. Параметр ga:dimension1 — пользовательский параметр Client ID. Цели с номерами 4 и 5 — формы на сайте.
После обработки данных, получили таблицу:
3. Запрос по API к коллтрекингу
Помимо данных из Google Analytics, нужны данные коллтрекинга. Изучив справку API коллтрекинга, написали запрос:
После преобразования данных, получили табличку, похожую на приведенную выше, но уже по звонкам:
4. Объединение таблиц: аналитика и коллтрекинг
Соединяем таблички в единое целое:
Складываем заявки и звонки, получая единый столбец — обращения (app). Сводим данные по client_id, дате, источнику, каналу и кампании:
В итоге получили таблицу с Client ID, источниками, каналами и кампаниями, хитами и обращениями. Теперь можно строить модели атрибуции.
5. Группировка All Rows
Основной метод объединения данных по Client ID в Power Query — группировка All Rows (Все строки). C её помощью мы получили табличку из 2 столбцов — Client ID и все остальные данные:
В каждой ячейке второго столбца содержится таблица с подробными данными по этому Client ID:
Теперь нужно посчитать суммарное количество хитов по каждому Client ID, чтобы в дальнейшем можно было узнать долю каждого источника.
Используем функцию List.Sum для подсчета общего количества хитов (hits_sum):
Аналогичным способом считаем сумму обращений (app_sum). В итоге получаем два новых столбца:
После чего разворачиваем столбец «Все строки», нажимая на значок справа от названия столбца:
Таблица возвращается к прежнему виду, но теперь у нас есть сумма хитов и сумма обращений по каждому Client ID:
6. Удаление дублей в обращениях
Сводим к единице или нулю количество обращений по каждому Client ID. Если клиент не обращался — ноль, если обратился хотя бы один раз — единица:
7. Вычисление количества обращений
Рассчитываем ценность каждого визита в обращении (value). Если суммарное количество хитов равно нулю, считаем, что пользователь сразу вышел с сайта. Если есть хотя бы один хит — считаем отношение количества хитов в конкретном визите к общему числу хитов:
В итоге получаем ценность каждого сеанса в рамках цепочки конверсий. Её нужно умножить на общее количество конверсий по Client ID:
В итоге получили количество обращений по каждой сессии.
8. Статистика по кампаниям
Агрегируем данные по рекламным кампаниям, считаем количество обращений (value_app):
В таком методе расчета мы неизбежно получаем дробные значения, так как распределение конверсий идет в соответствии со множеством действий пользователя на сайте.
9. Оптимизация рекламных кампаний
Подгружаем расходы, строим график по расходам (costs) и стоимости обращения по модели «активность пользователя» (CPA_active). Видим, какие кампании нуждаются в оптимизации:
10. Сравниваем модели атрибуции
Из графика сравнения моделей атрибуции видно, что модель Last Click идет в отрыве от остальных и не является объективной. Модель атрибуции по данным активности очень похожа на линейную модель, но мы считаем её более интересной благодаря учету действий пользователя на сайте. Красный столбец — стоимость обращения по модели атрибуции «активность пользователя». Желтый столбец — стоимость обращения по модели атрибуции «First Click». Фиолетовый столбец — стоимость обращения по модели атрибуции «Last Click» Оранжевый столбец — стоимость обращения по линейной модели атрибуции.
Итог
Мы объединили пользователей по Client ID, исключили дублированные заявки и звонки, учли пути пользователей к конверсии, использовали данные о поведении людей на сайте. Теперь можно проводить более точную оптимизацию рекламных кампаний и демонстрировать отчетность клиенту с четким обоснованием выбора модели атрибуции. Так как все данные автоматически подтягиваются в единый отчет, в любой момент можно посмотреть статистику и принять решение о дальнейших действиях. В качестве метрики активности можно использовать не только хиты. Более интересная метрика — длительность активного посещения. Для этого нужен циклический скрипт учета активности пользователей. Если каждые 30 секунд активного пребывания на сайте запускать событие, ценность можно распределять в соответствии с длительностью активного посещения. Это более точная метрика, так как она включает в себя время реальной активности пользователя: движения мыши, скролл и клики по элементам. Не советую брать в качестве показателя активности время посещения из Google Analytics — по нашим наблюдениям данные некорректны. Если вы хотите исключить участие некоторых каналов в моделировании атрибуций — нужно отфильтровать их на этапе загрузки данных из Google Analytics. Лучше оставить только платные источники, чтобы понять, как распределяется ценность между ними. Перераспределять бюджеты по этим данным — наиболее целесообразно. Мы получили бесплатное решение, которое можно применять для любого клиента. Если клиенту важна атрибуция и не подходит Last Click — рекомендую пользоваться атрибуцией с учетом активности пользователя. По результатам сравнения моделей атрибуции, в нашем случае она была ближе всего к линейной модели. Очевидный её плюс перед другими моделями — учет данных о поведении пользователя на сайте.