Нужны ли нулевые заказы в Getcourse?

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

Почему вообще придумали нулевые заказы

Нулевой заказ в Getcourse часто служит попыткой «легализовать» заявку в бухгалтерском объекте. Так проще: есть заказ — значит, система далее может опираться на статусы, триггеры, «покупки» и привычную логику отчетности. Параллельно сохраняются UTM-метки на уровне заказа, и получается иллюзия целостной картины для рекламной аналитики.

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

Третий — учет повторных визитов. Если пользователь уже есть в базе и пришёл снова по платному трафику, хочется зафиксировать свежую UTM-связку. Самый простой инструмент под рукой — опять же заказ, пусть и на 0.

Но простота обманчива. За ней скрывается рост числа предложений, загрязнение реестра заказов и запутанная атрибуция, где «заявка» и «покупка» смешиваются. Там, где нужен прозрачный слой «интереса» (лид, событие формы, сессия), используется бухгалтерский объект «заказ». Это приводит к системным искажениям, которые усиливаются с каждым новым запуском.

Чем оборачиваются нулевые заказы на практике

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

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

Третье — путаница в атрибуции. Когда заявка создается как заказ, за ней тянутся UTM-метки и статусы, но связи сессий и переоткрытий оффера теряются. Старые пользователи накладывают новые сессии, и пересобрать внятный user-journey становится трудно. Добавьте к этому кросс-кампанийные ретаргеты — и вы получаете лоскутную картину.

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

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

Заказать Monitor Analytics →

«Добавлять в группы без заказа» — действительно ли лучше

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

Первая — потеря UTM для «старых» пользователей. Если человек уже был в базе, повторно пришёл по рекламе и оставил заявку на новом лендинге, его свежие UTM-метки часто не сохраняются. В результате для платного трафика вы теряете атрибуцию. Это бьёт по оценке эффективности подрядчиков и бюджету на растущие каналы.

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

Третья — неявная логика стадии «заявка». Когда у заявки нет собственного представления в данных, вы неизбежно утыкаетесь в произвольные комбинации тегов, групп и дат заполнения формы. Это «работает», пока в проекте нет десятков кампаний. Но при росте вести прозрачную аналитику и быстро адаптировать воронки становится сложно.

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

Как сформулировать задачу корректно

Если отойти от конкретных инструментов и спросить «что мы хотим видеть в данных», ответ чаще всего таков:

• Любую попытку оставить заявку на лендинге фиксируем как событие «лид» с UTM-метками.
• Сохраняем историю визитов и заявок для уже существующих пользователей, не стирая прошлые касания.
• Привязываем события лидов к фактическим заказам и оплатам, чтобы видеть путь от объявления до денег.
• Используем «заказ» только для реальных намерений оплатить (или для подтвержденных счетов), а не для фиксации интереса.

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

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

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

Архитектура без нулевых заказов: как это реализовать в Getcourse

Рассмотрим практическую схему, которая сохраняет UTM-метки и историю заявок, не создавая нулевые заказы.

Шаг 1. Единый шаблон форм. Все лендинги используют стандартный шаблон, где UTM-метки и прочие параметры кампаний прокидываются через скрытые поля. В шаблоне сразу заложены правила: не перезаписывать first_touch, фиксировать last_touch, а историю касаний собирать в текстовом поле (например, JSON-строкой) или в цепочке событий.

Шаг 2. Событие «заявка» вместо заказа. При сабмите формы создаётся событие пользователя «lead_submitted» через внутренний механизм или API. В событии — набор UTM-меток, URL, идентификаторы кампаний, плейсмента, дата и пр. Далее триггеры реагируют на событие, а не на «создание заказа».

Шаг 3. Одна техническая группа на воронку. Пользователи добавляются в техническую группу воронки для выдачи контента и цепочек писем. Разделение по продуктам и подрядчикам — не группами, а тегами и полями события.

Шаг 4. Отдельные поля для атрибуции. В карточке пользователя хранятся агрегаты: first_click_utm, last_click_utm, last_non_direct_utm, а также счётчик обращений и дата последнего лида. Но первичное — события.

Шаг 5. Связка лида с заказом. Когда пользователь оформляет реальный заказ, вы записываете в заказ идентификатор последнего релевантного лида. Так сохраняется «путь к оплате» без нулевых заказов. В отчётах это внешний ключ между сущностями «lead» и «order».

Шаг 6. Последовательности коммуникаций. Прогрев и до продажи работают по событиям: «лид создан», «лид подтверждён менеджером», «лид прослушал урок» и т.п. Правила становятся декларативными и не завязаны на статусы «заказа 0 ₽».

Шаг 7. Контроль качества вместо уборки мусора. Руководитель смотрит не на стопку фальшивых заказов, а на конверсию «лид → оплата», время до контакта, долю повторных лидов и неудачных контактов. Для этого нужны понятные дашборды. Их можно собрать самостоятельно или использовать готовые дашборды для руководителя.

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

Построить отдел работы с базой →

Поток данных: от клика до оплаты

Чтобы схема заработала, важен аккуратный поток данных.

• На клике по рекламе фиксируется набор UTM и идентификатор пользователя (cookie, client_id).
• При загрузке лендинга скрипт проверяет валидность UTM, обновляет «last_non_direct», не перетирая первый канал.
• Форма забирает UTM из клиентского хранилища, добавляет служебные параметры (страница, оффер, агентство, креатив) и отправляет в систему событий.
• На событие «lead_submitted» реагируют роботы: добавляют пользователя в техгруппу, запускают письма, ставят задачу менеджеру.
• При оформлении заказа заказ связывается с последним релевантным лидом по времени с настройкой «окно атрибуции» (например, 7 или 30 дней).
• Оплата закрывает цикл и отправляет сигнал обратно в слой аналитики для расчёта эффективности кампаний.

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

Как строить отчёты без нулевых заказов

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

Какие срезы нужны руководителю и маркетингу:

• Лиды, CPL и конверсия лида в заказ по источникам, кампаниям, креативам и лендингам.
• Время обработки лида: среднее и медиана до первого контакта, доля лидов без касания.
• Конверсия «лид → заказ → оплата» по менеджерам и очередям.
• Финансы: CAC, ROMI по каналам с учётом возвратов.
• Повторные покупки и LTV по источникам первого лида.

Если вы ведёте рассылки, полезно видеть влияние писем на переход «лид → оплата». Инструменты уровня метрики LTV и оттока помогают сравнить связки «канал + продукт + последовательность писем» и выбирать наиболее доходные дорожки.

Отчёты удобно собирать в дашбордах с фильтрами по воронкам и продуктам. Главное — не смешивать сущности. Лиды считаются по событиям, заказы и оплаты — по транзакциям. Тогда любой спор «какой подрядчик привёл деньги» решается парой фильтров, а не часом ручного сбора.

Заказать Monitor Analytics →

Как сохранить UTM у «старых» пользователей

Проблема потери UTM у тех, кто уже в базе, решается комбинацией клиентской и серверной логики.

Во-первых, политика cookie. Храните UTM минимум 90 дней, а лучше 180, с отдельными слотами под first_click и last_non_direct. Прямые заходы last_non_direct не переписывают.

Во-вторых, добавьте идентификаторы источников на уровне формы: campaign_id, adset_id, ad_id. Это уменьшит число «потерянных» связок, если UTM трекер где-то отвалился.

В-третьих, при сабмите формы всегда создавайте событие лида, даже если пользователь авторизован и известен системе. В событии фиксируйте весь набор UTM+ID.

В-четвёртых, не стирайте историю — используйте агрегат «история заявок» как массив или строку. И держите отдельные агрегаты для «первого касания» и «последней релевантной сессии».

И наконец, определитесь с окнами атрибуции. Для быстрых продуктов хватит 7–14 дней, для дорогих — 30–90. Это снижает споры о том, чья реклама «засчиталась».

Как масштабировать воронки без раздувания предложений

Раздел «предложения» должен служить материалом для продаж, а не контейнером для аналитики. Масштабировать без хаоса помогают три практики.

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

Вторая — технические группы. Под воронку выделяется одна техгруппа с ролевой логикой доступа. Разделение по подрядчикам — тегами и событиями, а не новыми группами.

Третья — игровая механика и акции без касания офферов. Применяйте надстройки «сверху» (таймеры, прогресс, уровни скидок) без создания десятка новых предложений. Для усилий в пиковые периоды удобно использовать игровые акции, не затрагивая структуру каталога.

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

Запустить игровую акцию →

Небольшой пример из практики

Возьмем школу с тремя флагманскими курсами и пятью типовыми воронками: вебинарная, трипвайр, интенсив, бесплатный марафон и прямой запуск. Исторически там работали нулевые заказы: формы создавали «заказ 0 ₽» с разными офферами под каждый лендинг. В нагрузку — дубли групп под подрядчиков.

Что видели в данных:

• В разделе «заказы» — 70% записей без намерения оплатить.
• На продукт «Курс А» — 18 офферов под кампании.
• Подрядчики спорили за атрибуцию, потому что одинаковый пользователь создавал 2–3 заказа 0 ₽ с разными UTM.
• Руководитель смотрел на конверсию «заказ → оплата», будто на fail marketing, хотя половина «заказов» — заявки.

После перехода на событийную модель:

• Формы пишут событие «lead_submitted», заказы создаются только при реальном оформлении.
• В каталоге по каждому продукту осталось 2–3 оффера (основной, рассрочка, акция).
• В отчётах появилась чистая воронка: лиды, квалификация, заказ, оплата.
• Новые подрядчики подключались без создания групп и офферов — только теги кампаний и доступ к фильтрам.

За 2 месяца стало видно, что «марафон» даёт много лидов с низкой квалификацией: время до контакта выше нормы, доля неоплаченных заказов после звонка — 60%. Команда выровняла прогрев и изменила критерии лид-скоринга. Конверсия «лид → заказ» выросла на 22%, при этом каталоги и «заказы» остались аккуратными.

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

Ограничения и риски, о которых стоит знать

• Getcourse не является «системой событий» в строгом смысле. Для удобства отчётности пригодится внешний слой хранения (даже если это простое хранилище + дашборд).
• Команда должна договориться о правилах атрибуции и именовании тегов. Иначе в событиях будет беспорядок, а смысла мало.
• Если CRM-процессы завязаны на «заказы», нужна миграция триггеров на события. Это разовый проект, но он окупается.
• С личными данными работайте аккуратно: хранение истории визитов и UTM — это персональные данные, требуются корректные согласия и политики.

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

Пошаговая дорожная карта внедрения

• Аудит текущей карты: где формы, какие группы, как создаются заказы, сколько офферов.
• Описание «как должно быть»: единый шаблон формы, события, поля атрибуции, окна, правила first/last.
• Быстрые победы: выключить нулевые заказы на одной воронке, добавить событие «lead_submitted», связать с заказом.
• Перенос триггеров: замена условий «создан заказ 0 ₽» на «создан лид/есть статус».
• Чистка каталога: сократить офферы, оставить рабочие, остальные — архивировать.
• Отчёты и дашборды: собрать базовый набор и обсудить решения, которые команда будет принимать по ним.
• Регламенты именования тегов и работы с событиями.
• Обучение команды и запуск «в прод».

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

Чтобы проект не буксовал на аналитике, удобно сразу подключить отчёты по трафику и совместить их с лидами и оплатами.

Частые вопросы

Нужны ли нулевые заказы для тестов оплаты? Да, но только в песочнице и на короткий период. В боевых сценариях лучше использовать отдельные «тестовые» флаги и не засорять рабочие реестры.

Что делать с офферами, если подрядчиков много? Сохранить 1–2 оффера на продукт и отдавать подрядчикам теги и события. У каждого будет свой срез отчёта без отдельной группы.

Как считать ROMI без нулевых заказов? По связке «событие лида → заказ → оплата → возврат». У вас есть и CPL, и CAC, и вы видите вклад писем и менеджеров. Полевая практика показывает, что так цифры становятся стабильнее.

Как учитывать рассрочку? Рассрочка — это финансовый профиль заказа/оплаты, а не тип заявки. Модель не меняется: лид → заказ, а уже в заказе — график платежей.

Как привязывать офлайн-активности? Через события с UTM stub (например, utm_medium=offline, utm_source=meetup) и код-приглашение, которое вводится в форме.

Когда нулевые заказы всё-таки уместны

• Тестирование платежной логики и UX на закрытом стенде.
• Импорт исторических данных из другой системы, если невозможно восстановить по событиям и нужно сохранить «следы» без денег.
• Специальные кейсы интеграций, где downstream-система требует «заказ» как сигнал, а адаптер событий недоступен.

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

Что делать, если «помойка» уже случилась

План «генеральной уборки» обычно выглядит так:

• Заморозить новые нулевые заказы и внедрить событие лида в одной тестовой воронке.
• Очистить каталог: оставить только продающие предложения, прочее — архивировать.
• Закрыть «технические» нулевые заказы, убрать из видимости или переместить в отдельный статус.
• Переписать триггеры на события.
• Свести отчёты к новой модели: лиды — события, заказы — транзакции.
• Настроить сегменты для повторных коммуникаций: на основе событий лида и покупок.

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

Построить отдел работы с базой →

Работа с базой после наведения порядка

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

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

Если вы готовы выстроить стабильный «второй контур» монетизации, имеет смысл спроектировать систему апсейлов и привязать её к событиям интереса, а не к заказам 0 ₽. Так коммуникации становятся адресными, а повторные продажи — предсказуемыми.

Итоги

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

Решение — событийная архитектура с единым шаблоном форм, аккуратным хранением first/last touch и связью лида с реальным заказом. В результате «заказы» снова означают «деньги», воронки — процессы, а атрибуция — понятный путь клиента. По мере роста вы масштабируете кампании без раздувания офферов и не спорите о вкладе каналов.

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