В онлайн-школах с большим количеством рекламных кампаний недостаточно знать, сколько денег потратили на рекламу и сколько заказов получили.
Гораздо важнее ответить на вопрос:
какой именно трафик приводит к продажам и насколько качественно он работает?
На простом проекте это можно посчитать относительно легко. Но когда одновременно работают несколько автовебинарных воронок, десятки рекламных кампаний, несколько таргетологов, социальные сети, органика и другие источники, стандартная атрибуция начинает давать искажённую картину.
В этом кейсе покажем, как мы построили индивидуальную модель атрибуции для платного трафика, связали её с данными из GetCourse и вывели результат в BI.
Все названия проекта в статье изменены.
С чего началась задача
Представим онлайн-проект «Вектор».
В проекте работает несколько автовебинарных воронок.
Если коротко, автовебинар — это заранее записанный вебинар, который запускается автоматически по расписанию. Пользователь регистрируется, а затем получает возможность посмотреть вебинар в определённое время.
В нашем случае вебинары проходят практически ежедневно, причём у пользователя есть два времени на выбор.
Получается довольно большой поток регистраций.
Человек увидел рекламу → перешёл на страницу → зарегистрировался на автовебинар → пришёл на вебинар → сделал заказ.
Но на этом всё не заканчивается.
Одновременно с платной рекламой в проекте работают:
- социальные сети;
- органические переходы;
- партнёрские источники;
- рассылки;
- прямые переходы;
- повторные регистрации;
- другие активности внутри проекта.
А ещё рекламой могут заниматься сразу несколько специалистов.
И здесь возникает главная проблема:
как точно определить, что именно считать платным трафиком?
Почему нельзя просто разделить источники на «реклама» и «не реклама»
На первый взгляд задача кажется простой.
Есть рекламные источники — относим их к платному трафику.
Есть социальные сети и органика — не относим.
Но в реальном проекте всё гораздо сложнее.
Например, рекламой могут заниматься десять разных таргетологов.
У каждого свои кампании, метки, кабинеты и правила именования.
Параллельно появляются новые рекламные кампании.
Меняются подрядчики.
Добавляются новые источники.
Часть переходов может идти через промежуточные страницы.
Какие-то источники могут быть платными только частично.
Поэтому недостаточно написать в отчёте:
«Если источник содержит слово advertising — считать его платным».
Для точной аналитики необходимо заранее определить справочник платного трафика.
То есть система должна понимать:
какие конкретно источники, кампании, метки и каналы относятся к платному трафику, а какие — нет.
Именно здесь появляется преимущество индивидуальной модели
Универсальная аналитика обычно пытается работать по единому правилу.
Но у каждого проекта своя структура трафика.
В одном проекте платными будут несколько рекламных кабинетов.
В другом — десятки таргетологов.
В третьем — дополнительно агентства, партнёры, контекстная реклама и другие каналы.
Поэтому мы сначала определяем классификацию источников.
Условно:
Платный трафик
- таргетолог №1;
- таргетолог №2;
- таргетолог №3;
- рекламное агентство;
- контекст;
- другие платные кампании.
Неплатный трафик
- органика;
- социальные сети без рекламного размещения;
- прямые переходы;
- собственные рассылки;
- внутренние переходы;
- другие бесплатные источники.
Причём этот справочник можно расширять и изменять вместе с проектом.
И только после этого имеет смысл строить атрибуцию.
Потому что сначала нужно ответить на вопрос:
«Что в нашем конкретном проекте является платным трафиком?»
И только потом:
«Какой платный источник получает заказ?»
Регистрация стала точкой входа в атрибуцию
В проекте работало несколько автовебинарных воронок, и у каждой были свои заказы.
Поэтому мы решили использовать регистрацию на автовебинар как ключевую точку входа.
Получилась следующая логика:
Источник → регистрация → автовебинар → заказ
При этом для каждого значимого действия мы смотрим историю регистраций пользователя.
Например, пользователь зарегистрировался на автовебинар через рекламный источник.
Через несколько дней он пришёл на сам автовебинар.
Система проверяет:
«Какая регистрация была последней перед этим событием?»
И дальше определяет, относится ли эта регистрация к платному трафику.
Как атрибутировали вход на автовебинар
Первый важный сценарий — человек пришёл на автовебинар.
Сам факт входа ещё не говорит, откуда пользователь пришёл.
Поэтому при формировании отчёта мы смотрим историю регистраций пользователя.
Упрощённо логика выглядит так:
Вход на автовебинар → поиск последней регистрации → определение источника регистрации → проверка, является ли источник платным.
Допустим:
- 1 октября — регистрация через рекламный источник;
- 4 октября — пользователь заходит на автовебинар;
- система находит последнюю подходящую регистрацию;
- определяет её источник;
- если источник входит в классификацию платного трафика — пользователь относится к платному каналу.
Так можно оценивать не просто количество посетителей вебинара, а какой именно трафик привёл этих пользователей на конкретную воронку.
А что делать с платным заказом?
Здесь логика становится ещё интереснее.
Пользователь может зарегистрироваться на вебинар, а заказ сделать спустя несколько дней.
Поэтому для каждого платного заказа мы также смотрим историю регистраций.
Условно:
Платный заказ → ищем подходящую регистрацию → определяем источник → проверяем его статус → относим заказ к нужному каналу.
Но здесь появляется ещё одна проблема.
Неплатный источник может «перехватить» продажу
Представим пользователя, который сначала пришёл из рекламы.
Он зарегистрировался на автовебинар.
Через несколько дней пользователь увидел публикацию в социальной сети и снова перешёл в проект.
Затем сделал заказ.
Если использовать только последнее действие, продажа может достаться социальной сети.
Для оценки эффективности рекламы это создаёт искажение.
Получается, рекламная система привела потенциального клиента, но в отчёте продажа оказалась у другого канала.
Поэтому мы добавили приоритет платного трафика.
Как работает приоритет платного источника
В модели предусмотрели отдельное правило:
если у пользователя есть релевантная регистрация через платный источник, она имеет приоритет при атрибуции платного заказа.
Но здесь важно понимать: платный источник получает приоритет не просто потому, что мы так решили.
Сначала система должна точно определить, является ли конкретный источник платным.
Именно поэтому классификация источников и атрибуция связаны между собой.
Получается двухэтапная логика:
1. Определяем, что является платным трафиком.
2. Среди релевантных регистраций определяем, какой платный источник должен получить заказ.
Это позволяет не смешивать в одном отчёте рекламу, органику, соцсети и другие источники.
Окно атрибуции: почему нельзя учитывать регистрацию бесконечно
Даже если мы точно знаем, что источник был платным, остаётся вопрос:
как долго регистрация должна влиять на будущий заказ?
Представим, что человек зарегистрировался на вебинар сегодня, а покупку совершил через три месяца.
Стоит ли считать этот заказ результатом той регистрации?
Не всегда.
Поэтому в модели появляется окно атрибуции.
В нашем проекте мы использовали ограничение 30 дней.
Алгоритм проверяет:
Была ли подходящая регистрация пользователя за последние 30 дней?
Если да — она может участвовать в атрибуции.
Если регистрация была раньше — она уже не используется для текущего заказа.
Но 30 дней подходят не для каждого проекта
И это ещё одна причина, почему мы не используем одну универсальную модель для всех клиентов.
В разных проектах цикл принятия решения может сильно отличаться.
Где-то покупка происходит практически сразу.
Тогда логичнее использовать окно:
0–7 дней.
Где-то пользователю требуется больше времени:
0–14 дней.
В проектах с более длинным циклом сделки может использоваться:
0–30 дней.
А в некоторых случаях ограничение вообще можно убрать, если логика бизнеса предполагает, что регистрация должна сохранять связь с покупателем независимо от времени.
То есть окно атрибуции — это настраиваемый параметр бизнес-модели, а не константа.
В нашем проекте 80% заказов приходили за 0–7 дней
На практике мы посмотрели фактическую статистику автовебинарных воронок.
Оказалось, что около 80% заказов приходится на первые 0–7 дней после регистрации.
Это говорит о том, что основная часть аудитории принимает решение достаточно быстро.
Но мы всё равно оставили окно в 30 дней.
Почему?
Потому что задача отчёта — не только показать уже сформировавшуюся статистику, но и максимально точно оценивать качество трафика в текущем моменте.
Слишком короткое окно может преждевременно исключить реальные заказы.
Слишком длинное — начать связывать покупку со слишком старой регистрацией.
Поэтому в конкретном проекте 30 дней оказались разумным компромиссом.
А иногда мы делаем скользящее окно
В некоторых проектах заказчик уже хорошо понимает принцип работы атрибуции и хочет самостоятельно оценивать данные с разным горизонтом.
Тогда можно сделать скользящий фильтр по окну атрибуции.
Например, руководитель или маркетолог выбирает:
7 дней → 14 дней → 30 дней
и смотрит, как меняется результат.
Это даёт дополнительный инструмент для анализа.
Например:
7 дней — показывает максимально быстрый эффект рекламы.
14 дней — позволяет учитывать более длинный цикл принятия решения.
30 дней — даёт более широкий горизонт оценки.
Таким образом, заказчик может самостоятельно определить, какое окно ему интересно для конкретного анализа.
Это особенно полезно, когда команда уже понимает механику атрибуции и хочет самостоятельно проверять разные сценарии.
В результате появилась собственная модель атрибуции
Вместо стандартного:
«последний клик забрал продажу»
мы получили модель, адаптированную под конкретный проект.
Упрощённо она выглядит так:
- Пользователь регистрируется на автовебинар.
- Система определяет источник регистрации.
- Источник классифицируется: платный или неплатный.
- Пользователь приходит на вебинар или делает заказ.
- Система ищет последнюю подходящую регистрацию.
- Проверяется окно атрибуции.
- Если найден платный источник — применяется его приоритет.
- Событие относится к нужному рекламному каналу.
А само окно при необходимости можно менять под бизнес-логику проекта.
Что в итоге увидели в BI
Следующим этапом было вынести рассчитанные показатели в BI.
Руководителю и маркетингу уже недостаточно просто видеть количество регистраций.
Им нужно понимать:
- сколько регистраций привёл каждый рекламный источник;
- сколько пользователей дошло до автовебинара;
- сколько заказов связано с рекламой;
- какая воронка работает лучше;
- какие источники приводят более качественную аудиторию;
- где находятся проблемы между регистрацией и продажей;
- как меняется результат при разных окнах атрибуции.
В результате BI-отчёт показывает связку между рекламным источником, регистрацией, автовебинаром и платным заказом.
Почему здесь нельзя было обойтись обычной таблицей
На первый взгляд кажется, что такую задачу можно решить несколькими формулами в Excel или Google Таблицах.
Но как только появляется:
- несколько автовебинарных воронок;
- десятки рекламных источников;
- несколько таргетологов;
- повторные регистрации одного пользователя;
- платные и бесплатные каналы;
- разные события;
- приоритет платного трафика;
- окно атрибуции;
- возможность менять это окно;
простая таблица быстро превращается в сложную систему правил.
И самое главное — эти правила нужно применять не один раз, а постоянно.
Сегодня появились новые регистрации.
Завтра новые заказы.
Появился новый таргетолог.
Добавился новый рекламный источник.
Изменилась разметка кампаний.
Изменилось окно атрибуции.
Вручную поддерживать такую модель становится неудобно и рискованно.
Retrafic стал источником данных для BI
Для построения отчёта мы использовали Retrafic как слой сбора, обработки и хранения данных.
Он позволяет собрать необходимые данные из источников проекта, привести их к единому виду и подготовить для дальнейшего анализа.
В нашем случае это было особенно важно, потому что BI должен был получать уже подготовленные данные, а не самостоятельно разбираться в десятках разрозненных событий.
Получилась связка:
источники проекта → Retrafic → обработка и атрибуция → BI → управленческий отчёт
То есть BI отвечает за визуализацию и анализ, а Retrafic — за подготовку данных, на которых строится эта аналитика.
Что даёт такая аналитика маркетологу
После внедрения такой системы становится гораздо проще оценивать рекламу.
Например, можно увидеть не просто:
«Этот источник дал 500 регистраций».
А:
«Этот платный источник дал 500 регистраций, привёл пользователей на автовебинары и в результате сформировал определённое количество заказов».
Это принципиально разные уровни аналитики.
Регистрация — ещё не продажа.
Посещение вебинара — тоже не продажа.
И даже большое количество участников автовебинара не обязательно говорит о высоком качестве трафика.
Главный вопрос:
что происходит с пользователем после регистрации?
Такая аналитика помогает оценивать и сам автовебинар
Интересный эффект этой модели — можно анализировать не только рекламу.
Допустим, два платных источника приводят примерно одинаковое количество регистраций.
Но пользователи первого источника значительно чаще покупают после просмотра вебинара.
Это может говорить о более качественной аудитории.
А если один и тот же источник хорошо работает на одной автовебинарной воронке и значительно хуже на другой, проблема может быть уже не в рекламе.
Возможно, отличается:
- тема вебинара;
- предложение;
- сценарий;
- время проведения;
- продукт после вебинара.
Получается, одна и та же модель помогает смотреть сразу на две стороны:
качество трафика + качество самой воронки.
Главное преимущество индивидуальной аналитики
Универсальный отчёт хорошо работает там, где структура проекта относительно простая.
Но чем больше становится источников и особенностей бизнеса, тем важнее не просто собрать данные, а правильно описать правила их интерпретации.
В нашем случае нужно было заранее определить:
кто является платным источником;
какие источники не относятся к рекламе;
какой источник получает приоритет;
какую регистрацию считать последней;
как связать регистрацию с автовебинаром;
как связать регистрацию с заказом;
сколько дней действует атрибуция;
можно ли менять это окно при анализе.
Именно эти правила делают отчёт действительно полезным.
Потому что красивый BI с неправильной атрибуцией всё равно будет показывать неправильную картину.
Не существует одной правильной модели для всех
В этом проекте мы использовали регистрацию на автовебинар, приоритет платного источника и окно 30 дней.
Но в другом бизнесе модель может быть совершенно другой.
Где-то достаточно 7 дней.
Где-то — 14.
Где-то нужен месяц.
Где-то окно вообще не ограничивается.
А где-то лучше дать руководителю возможность самостоятельно менять период с помощью скользящего фильтра.
То же самое касается классификации источников.
Для одного проекта достаточно нескольких каналов.
Для другого необходимо разделить десятки рекламных источников, несколько таргетологов, агентства и другие типы трафика.
Поэтому хорошая сквозная аналитика начинается не с выбора BI-системы.
Она начинается с понимания того, как именно устроен бизнес и путь пользователя до покупки.
Итог
В этом проекте нам нужно было связать платный трафик с реальными заказами в условиях сложной системы автовебинарных воронок.
Для этого мы:
- определили, какие конкретно источники относятся к платному трафику;
- учли большое количество рекламных специалистов и источников;
- выбрали регистрацию на автовебинар как ключевую точку атрибуции;
- определяли источник последней релевантной регистрации;
- использовали эту связь для анализа входа на автовебинар и платного заказа;
- добавили приоритет платного источника;
- ограничили окно атрибуции 30 днями;
- учли, что около 80% заказов происходит в первые 0–7 дней;
- предусмотрели возможность использовать окна 7, 14 или 30 дней в зависимости от проекта;
- в отдельных случаях полностью убираем ограничение;
- для некоторых проектов можем сделать скользящий фильтр, чтобы заказчик самостоятельно менял окно атрибуции;
- подготовили данные для BI через Retrafic;
- вывели итоговые показатели в управленческий отчёт.
В результате маркетинг получает не просто статистику по рекламным каналам, а более точную картину:
откуда пришёл пользователь → на какой автовебинар зарегистрировался → дошёл ли до него → сделал ли заказ → какому платному источнику этот заказ засчитать.
Именно такая логика позволяет принимать решения не только по количеству лидов, но и по реальному качеству платного трафика.
Нужно построить сквозную аналитику под свой проект?
Если у вас GetCourse, несколько воронок, десятки рекламных источников и нестандартная логика атрибуции, универсальный отчёт может не подойти.
В таком случае можно обратиться к профессионалам на Retrafic.site — специалисты помогут спроектировать индивидуальную модель сквозной аналитики, определить, какие источники считать платными, настроить правила приоритета и окно атрибуции, связать данные из разных систем и собрать отчётность под особенности конкретного проекта.
Нужна такая же система у себя? Разберём вашу схему аналитики за 30 минут и скажем, с чего начать.
Написать в TelegramТакже опубликовано на Дзене: открыть оригинал. Каноническая версия для поиска — эта страница на retrafic.site.