Часть вторая. Отдел масштабирования.
В первой статье , посвященной отделу трафика, мы рассмотрели базовые понятия отдела, его структуру и отдел тестов.
В этой статье мы поговорим об отделе масштабирования.
Отдел масштабирует все те связки, которые мы обнаружили в ходе работы отдела тестов. При этом мы берем в масштабирование подрядчиков, которые успешно прошли отдел тестов.
Главной задаче отдела масштабирования - масштабировать связки без потери окупаемости.
Общий вид структуры отдела масштабирования.
Самый главный документ отдела масштабирования - медиаплан (далее МП) на месяц (на квартал). МП необходим чтобы понимать, какой объем трафика мы закупим, по какой цене и с какой эффективностью. Он позволяет заранее просчитать результат в конце месяца и ориентировать подрядчиков на определенные цели.
Также МП позволяет рассчитать окупаемость и увидеть узкие места в воронке и на пути трафика, чтобы понимать, над чем имеет смысл поработать.
Исходя из общего МП мы делаем декомпозицию и составляем планы для каждого подрядчика.
Исходя из общего МП мы делаем декомпозицию и составляем планы для каждого подрядчика.
Каждому необходимо понимать, какой бюджет и на какие продукты у него заложен, какое кол-во лидов и по какой цене он должен поставить в течении месяца.
Эта информация отражена в таблице план-факт. Она же содержит прогнозирование результатов - колонка runrate, чтобы понимать, какое кол-во лидов мы будем иметь к концу месяца и заранее что-то предпринять, если мы видим, что прогноз не дотягивает до плановых значений.
Такой план-факт делается по каждому подрядчику и входит в стандартный файл отчета дейли.
Файл отчета дейли, у каждого подрядчика, содержит в себе такие вкладки как: план-факт, детальный план по каждой воронке (на которую льет подрядчик), рабочие связки и база знаний.
Это необходимый минимум , который содержит стандартный файл отчета.
Когда мы декомпозировали общий медиаплан на весь отдел, на каждого подрядчика, прописали им план-факт в их отчетах дейли, можно запускать трафик:
1. Масштабировать те связки, которые нашли на этапе тестов.
2. Генерировать новые гипотезы и искать новые связки.
Как видно из рис.5. процесс отлива трафика закольцован и процесс идет по кругу:
1. Каждый день заполняем отчет дейли.
2. Масштабируем эффективные связки не более 20-3% в день от текущего бюджета.
3. По итогам каждого месяца определяем топ 3 самый окупаемых связок и топ 3 самых не окупаемых, заносим о них информацию во вкладку "рабочие связки".
4. В параллель генерируем новые гипотезы и запускаем в тест.
В результате мы получаем:
1. Упорядоченную структуру отдела трафик.
2. Как следствие повышение эффективности и окупаемости всего трафика.
Почему считать ROMI, при оценке трафика, не правильно и как надо правильно ? Читайте в следующе статье.
Подпишитесь на блог, чтобы не пропустить следующие статьи про окупаемый трафик.
Для консультации пишите: https://t.me/Artem_Gallyamiev