Как дешёвые заявки становятся дорогими продажами?
Сравнивать каналы нужно хотя бы до оплаченного заказа, а при наличии данных о затратах ещё и до вклада в покрытие общих расходов. Один канал может давать много обращений, но мало покупателей. Ниже полностью вымышленный пример мастерской, чтобы проверить арифметику, а не чужой успешный кейс.
В этом примере выручка совпадает с полными оплатами за выполненные заказы. В учебном месяце обе кампании потратили по 30 000 ₽. Все показанные заказы оплачены целиком, возвратов пока нет. Прямые затраты включают материалы и работу по этим заказам; общие расходы мастерской пока не учитываем.
Цена заявки у А выглядит привлекательнее. Но из 100 обращений получилось столько же оплаченных заказов, сколько у Б из 25. При этом у А на выполнение заказов ушла большая доля полученных денег.
Наш расчёт: А: 100 000 − 80 000 − 30 000 = −10 000 ₽. Б: 180 000 − 90 000 − 30 000 = 60 000 ₽. Это вклад после указанных затрат. До чистой прибыли ещё нужно учесть остальные расходы, налоги и принятую учётную политику.
Я не стал бы по этой таблице сразу выключать А и удваивать Б. Сначала проверю, что заявки не повторяются, затраты собраны в одинаковом составе, платежи относятся к тем же заказам и сделкам хватило времени на закрытие. В нашем маленьком примере всего по 5 продаж: один крупный заказ заметно меняет итог.
Какие показатели считать: CPL, ROAS, ДРР и ROMI?
Формулу нужно записать рядом с названием показателя и одинаково применять к каждому каналу. Так маркетолог, руководитель и бухгалтер не будут называть одним словом разные суммы. Особенно это касается прибыли и маркетинговой окупаемости.
Наш расчёт: ROAS кампании А = 100 000 / 30 000 = 3,33; это примерно 333% при записи в процентах. ДРР = 30%. При прямых затратах 80 000 ₽ такая реклама всё равно дала отрицательный вклад. Высокий ROAS сам по себе не подтверждает прибыль. Для Б ROAS = 6, ДРР ≈ 16,7%; ROMI по указанной формуле = 200%, у А ≈ −33,3%. Состав затрат в вашем сервисе нужно сверить; различия ROI, ROMI и ROAS разобраны отдельно.
При нулевой выручке ДРР не вычисляется: деление на ноль не заменяют нулём процентов. При нулевых расходах ROAS и ROMI тоже не определены по этим формулам. Канал без платной рекламы может иметь затраты на работу автора, продвижение и обслуживание; бесплатность клика их не отменяет.
Пример расчёта цены заявки, замера и договора для бизнеса с замером (кухни на заказ) с таблицей контроля по неделям есть в статье про стоимость заявки на кухню.
Какие данные связывают рекламу, CRM и оплату?
Минимальная цепочка состоит из источника, обращения, заказа и платежа. Для каждого объекта нужен свой идентификатор и правило связи с соседним. UTM-метка описывает переход; она не является номером покупателя или заказа.
Связь нужна и с точки зрения получателя денег. В разборе собственного процесса выплат Stripe видно, почему внутреннего номера недостаточно: контрагенту тоже нужно узнать платёж в выписке и понять, какой счёт он закрывает.
CRM, система управления клиентами, хранит обращения и сделки. Что такое CRM и какие задачи она решает разобрано отдельно. Здесь нас интересуют поля, которые позволяют сверить путь и суммы.
У заказа бывает несколько платежей: предоплата, доплата, возврат. Нужно выбрать, что именно показывает отчёт: оплаченные заказы, фактические поступления за период или продажи группы клиентов, пришедших в определённый месяц. Это разные срезы; складывать их в одной колонке нельзя.
Статус «успешно» в CRM тоже не всегда означает, что деньги поступили. Сверьте правило статуса с платёжным или учётным источником. Если менеджер может вручную закрыть неоплаченный заказ, отчёт по этому статусу будет отчётом о работе менеджера, а не подтверждённых оплатах.
Неопределённый источник сохраняется как отдельная категория с количеством заказов и суммой. Не нужно присваивать ему самый частый канал. Доля неизвестных может вырасти после изменения формы: тогда проблема в сборе данных, и сравнение эффективности каналов до починки будет ненадёжным.
Как настроить сквозную аналитику в Метрике?
В Метрике понадобятся размеченные рекламные ссылки, расходы, идентификаторы посетителей в CRM и передача клиентов с заказами. Это описано в официальной инструкции по сквозной аналитике. Ниже порядок работ для постановки задачи специалисту, без привязки к чужой CRM.
- Выберите вопрос отчёта. Например: какие оплаченные заказы связаны с кампаниями и сколько стоило их привлечение. Запишите период, валюту, правило возвратов и состав расходов.
- Проверьте метки рекламных ссылок. Одна кампания должна одинаково называться в ссылках и выгрузке затрат. Посадочная страница и последующий переход к форме должны сохранять нужную связь.
- Передавайте в CRM доступный идентификатор посетителя вместе с реальной заявкой. Для Метрики это может быть ClientID, идентификатор браузера в счётчике, который получают методом getClientID. Он не равен ID контакта вашей CRM.
- Загрузите расходы по кампаниям и передавайте данные о клиентах и заказах. Конкретный способ зависит от интеграции. Проверяйте настройки по документации именно вашей версии и выбранного формата передачи.
- Сделайте явно тестовую заявку и проведите её через согласованный тестовый сценарий. Проверьте связи и статусы. Для проверки реальных денег сверяйте существующую операцию с учётом; искусственная запись не подтверждает приём оплаты.
- Откройте отчёты по источникам заказов и расходам. Сравните контрольные суммы с исходными системами. Исправьте дубли и несвязанные события до решения о рекламном бюджете.
Для офлайн-конверсий, то есть действий вне сайта, есть отдельный отчёт о привязке к визитам. Факт загрузки ещё не означает найденный визит. В отчёте видны причины, например неподходящая цель, отсутствующий идентификатор или событие вне периода учёта.
В этом формате Метрика указывает период учёта 21 день до загрузки. Не переносите этот срок на любые CRM-интеграции и все модели атрибуции. При длинном цикле продажи заранее уточните выбранный формат, допустимые даты и обработку поздних платежей; правила передачи офлайн-конверсий зависят от конкретной схемы.
Как учитывать звонки, мессенджеры и повторные обращения?
Звонок или переписка связываются с источником только при наличии проверяемого механизма. Кнопка «Позвонить» фиксирует намерение нажать, а не состоявшийся разговор. Переход в Telegram также не подтверждает отправленное сообщение или заказ.
Для звонков используют коллтрекинг, отслеживание источника телефонного обращения. Статический номер закрепляют за каналом, динамическая подмена помогает связать номер с посещением. Возможная детализация зависит от настройки, объёма выделенных номеров и данных интеграции; номер для каждого ключевого слова автоматически не возникает.
Для мессенджера сохраните техническую связь между переходом и обращением, если она поддерживается выбранным каналом. Если её нет, честно показывайте «Telegram, источник не определён». Ответ клиента «увидел рекламу» можно хранить отдельно как заявленный источник, не подменяя им технически подтверждённое касание.
Один человек может заполнить форму, позвонить и написать. Воронка обращений покажет 3 события; в учёте клиентов это может быть один контакт, а в заказах один договор. Перед расчётом цены заявки решите, какой уровень уникальности используете и по каким правилам удаляете дубли.
На примере повторных продаж на Авито показываем, как различать канал возвращения и причину нового заказа. Там же есть учебный расчёт: рост числа повторных работ может не дать прибавки после скидок и обслуживания переписки.
Как выбрать модель атрибуции в 2026 году?
Модель атрибуции задаёт правило, по которому конверсию относят к источникам. Один человек может прийти из статьи, вернуться из рекламы и купить после прямого входа. При смене модели вклад каналов изменится даже при тех же продажах.
В документации Метрики есть важное изменение: с 20 мая 2026 года отключены «Первый переход», «Последний значимый переход», «Последний переход из Директа» и его вариант кросс-девайс. Старый совет просто выбрать «Последний значимый переход» уже не соответствует текущему набору.
Доступные варианты включают последний переход, первый переход кросс-девайс, последний значимый переход кросс-девайс и автоматическую атрибуцию. Кросс-девайс означает учёт переходов с разных устройств. Проверьте, что нужный вариант доступен в конкретном отчёте; его название следует сохранить рядом с выгрузкой.
Атрибуция распределяет учтённый результат. Она не доказывает, что покупатель отказался бы от заказа без рекламы. Для такого вывода нужен отдельный эксперимент с заранее выбранным показателем и сопоставимыми условиями, а не перестановка колонок в отчёте.
Свои условия есть и у новых источников заказов. В предварительной программе Shopify для ИИ-агентов действует последний непрямой переход с окном в семь дней. Сохранённые метки и место завершения покупки влияют на начисляемую комиссию.
Что выбрать: таблицу, Метрику или готовый сервис?
Выбирайте по доступности данных, способу продажи и человеку, который будет поддерживать учёт. Таблица подходит для небольшого числа источников и заказов, если записи можно регулярно сверять. Готовый сервис полезен, когда нужны устойчивые интеграции и диагностика передач.
Roistat описывает сбор данных для сквозной аналитики, а Calltouch объясняет связь обращений с продажами. Возможности на сайте поставщика не подтверждают, что конкретно ваша интеграция настроена. Попросите показать путь одного заказа на ваших допустимых тестовых данных.
Свою панель можно написать, но экран с диаграммами решает лишь часть задачи. Надо сохранять связи, повторять неудавшиеся передачи, исключать повторную запись платежа и восстанавливать данные после сбоя. Для первого этапа я бы заказал подтверждённую цепочку и контрольные суммы, а оформление расширял после проверки.
Как принять работу и найти ошибки в отчёте?
Приёмка состоит из проверки пути одного заказа, общих сумм и намеренно ошибочных случаев. Успешное открытие панели не подтверждает корректные деньги. Ниже учебный набор для задания исполнителю; он не изображает проверку вашей CRM.
Я проверяю общий итог после отдельных случаев. Сверьте итог всех каналов плюс неизвестных с исходной выгрузкой. Если суммы расходятся, нужен список несопоставленных операций. «Часть не загрузилась» слишком расплывчато: по каждой записи должно быть видно, какой связи или поля не хватает.
Неизвестные затраты нельзя заменить нулём. Если есть подтверждённые оплаты, но себестоимость ещё не получена, покажите выручку и статус «вклад в прибыль не рассчитан». Это полезнее красивой доходности, которая появилась из пропущенной колонки.
Изменение вида отчёта тоже стоит принимать отдельно от его расчётов. На примере компактной формы сводных таблиц Google разобрали проверку общих итогов, выбранных групп и переноса между Google Таблицами и Excel.
Ещё один случай проверки отчёта — события приложений в аналитике Shopify. Разработчик должен объявить и передать подходящие события; технический журнал не становится отчётом автоматически. Число отправленных писем тоже нельзя подменять числом оплаченных заказов.
Технические сведения о посетителях тоже нельзя подменять источниками продаж. Новые заголовки Amazon CloudFront описывают интернет-провайдера и защищённое соединение. Они пригодятся диагностике сайта, но без связи с заявкой и оплатой не показывают окупаемость канала.
Как использовать ИИ для проверки аналитики?
ИИ может собрать черновик задания, пересчитать обезличенный учебный пример и перечислить пропуски в данных. Он не получает доступ к кабинету, CRM или платежам от одного промпта. Ниже инструкция с разделением режимов: сначала вопрос и данные, затем расчёт или приёмка.
Перед отправкой рабочей выгрузки уберите имена, контакты, секреты и ненужные переписки. Технические номера тоже лучше заменить учебными. Право передавать данные во внешний сервис проверяет ответственный компании; для этого примера реальные клиенты не нужны.
Ты специалист по маркетинговой аналитике. Твоя задача: помочь составить проверяемый отчёт от источника обращения до заказа и оплаты. Работай только с данными, которые я передал. Не представляй план настройки как уже работающую интеграцию.
Режим: [задание / расчёт / приёмка].
Бизнес и способ продажи: [ниша, заявка на сайте, звонок, переписка, заказ].
Главный вопрос: [какое решение я хочу принять].
Период и время: [даты, часовой пояс, кассовый срез или группа клиентов по дате обращения].
Системы: [рекламные кабинеты, счётчик, CRM, платёжный или учётный источник].
Доступные поля: [источник, ID обращения, ID заказа, ID операции, сумма, валюта, статус, время, возврат, прямые затраты].
Правила: [уникальность заявки, связь заказа с обращением, состав расходов, модель атрибуции].
Учебные строки: [обезличенные записи или таблица].
Неизвестное: [чего пока нет, какие связи не проверены].
1. Сначала перечисли исходные факты, ограничения и недостающие поля. Если не хватает данных для запрошенного вывода, задай вопросы. Можно выполнить только ту часть, для которой данные достаточны. Не назначай неизвестным суммам или счётчикам ноль. Не выбирай модель атрибуции по умолчанию. Гипотетическое происхождение данных не называй фактически подключённой CRM. Полученные деньги после возврата не равны выручке или прибыли без соответствующего учётного определения.
2. Раздели переходы, клики по кнопкам, отправленные заявки, заказы и подтверждённые платежи. У каждого типа свой счётчик. Объясни, что является источником истины для оплаты; статус CRM без проверки не приравнивай к поступлению денег.
3. Для режима «задание» предложи минимальную цепочку данных, поля связи, ответственного за обновление и проверки. Не выдумывай API, тарифы, сроки и настройки интерфейса. Наличие счётчика не означает готовую сквозную аналитику.
4. Для режима «расчёт» выпиши формулы и состав затрат. CPL = расходы на рекламу / уникальные заявки; цена оплаченного заказа = расходы на рекламу / оплаченные заказы; ROAS = выручка / рекламные расходы; ДРР = рекламные расходы / выручка × 100%. ROMI считай только после уточнения выручки, прямых затрат и маркетинговых расходов: (выручка − прямые затраты − маркетинговые расходы) / маркетинговые расходы × 100%. Укажи единицы и округление. Нулевой знаменатель означает «не определено», неизвестный означает «недостаточно данных».
5. Не называй выручку чистой прибылью. Возвраты учитывай по переданному правилу, повторную доставку одного ID операции не суммируй заново. Отдельные предоплату и доплату не удаляй как дубли только потому, что у них один заказ. Конфликтующие записи с одинаковым ID вынеси на проверку.
6. Для режима «приёмка» проверь один связанный заказ, повтор платежа, возврат, неизвестный источник, пропуск расходов и сбой обмена. Для каждого случая напиши: вход, ожидаемый результат, фактический результат из переданных данных и статус. Непроведённый тест пометь «не проверено».
7. Итог собери в таблицу: канал | расходы | уникальные заявки | оплаченные заказы | выручка | прямые затраты | вклад после рекламы | CPL | ROAS | ДРР | ROMI | ограничение. Недоступные колонки оставь с объяснением. При неполных данных не объявляй канал прибыльным и не рекомендуй отключение рекламы.
8. Отдели проверенный расчёт от гипотезы о причинах. Атрибуция не доказывает дополнительный эффект рекламы. В конце предложи одно следующее проверяемое действие, которое не требует передачи паролей, покупки сервиса или изменения живых данных.
Разберите свою схему учёта с помощником в Ное
Сохраните эту инструкцию в Ное и передайте обезличенный учебный пример. Получите черновик задания и список вопросов к исполнителю. Помощник работает с переданным текстом; самостоятельное подключение CRM, платёжного кабинета и запись рабочих данных этим промптом не создаются. Расчёты нужно сверить с исходной таблицей.
Ниже покажу результаты настоящего учебного прогона этой инструкции. Это проверка ответов модели на вымышленных данных, без подключения рекламного кабинета, Метрики или CRM. Сам расчёт дополнительно проверен обычной арифметикой.
Что получилось в настоящем учебном прогоне?
Проверил 2 задания на вымышленных данных моделью Gemini 3 Flash: расчёт кампаний и повтор платежа с возвратом. В первом ответе числа совпали с нашей арифметикой: вклад А −10 000 ₽, Б 60 000 ₽; CPL 300 и 1 200 ₽; ROMI −33,3% и 200%. Модель отметила, что прочие расходы неизвестны и чистую прибыль посчитать нельзя.
Во втором задании пришли операции p1 на 4 000 ₽, повтор p1 на ту же сумму, p2 на 6 000 ₽ и возврат r1 на 2 000 ₽. В ответе: «4000 + 6000 - 2000 = 8000 RUB». Это верная сумма поступлений после возврата. Повтор p1 не добавился второй раз.
Расходы и прямые затраты во втором задании не передавались. В ответе: «На основании текущих данных невозможно сделать вывод об эффективности канала и принять решение о его отключении». Неизвестный расход не превратился в ноль.
Но ответы требуют правки. В первом прогоне модель назначила атрибуцию по умолчанию, после усиления инструкции перестала. В повторном ответе назвала поступление «выручкой», хотя правило её признания не задано. Из общего отрицательного вклада вывела убыток каждого заказа; агрегированные данные этого не доказывают. Ещё назвала канал «убыточным по ROAS»: этот показатель сравнивает выручку с рекламой и сам по себе не измеряет прибыль. Такие фразы для рабочего отчёта отклоняю.
Результат теста: арифметика и исключение точного дубля проверены, финансовые определения и выводы надо перечитывать. Ответ модели не подтверждает подключение систем и не является готовой рекомендацией о бюджете.
Похожая ловушка есть и при оценке разработки: GitHub Copilot добавил сравнение команд по отраслям. Количество принятых изменений полезно наблюдать, но окупаемость инструмента нужно связывать с качеством и затратами.
У площадок появляются и собственные отчёты по отдельным участкам пути. В разборе аналитики витрин Ozon объяснили, какие источники и заказы показывает новый раздел и почему его нельзя автоматически считать полной картиной продаж.
Частые вопросы
Можно ли начать без CRM?
Да, с небольшой таблицы, если у каждого обращения и заказа есть номер, а платежи регулярно сверяются. Это ограниченный ручной учёт. Подключение CRM поможет поддерживать связи, но не сделает их правильными автоматически.
Показывает ли сквозная аналитика чистую прибыль?
Только если переданы все необходимые затраты и согласовано правило расчёта. Часто отчёт показывает выручку или вклад после прямых затрат и рекламы. Чистая прибыль требует более полного финансового учёта.
Почему заявки есть, а оплаченных заказов в отчёте нет?
Возможны незакрытые сделки, потерянные идентификаторы, другой период оплаты или ошибка передачи. Возьмите одну известную продажу и проверьте путь по записям. До проверки нельзя утверждать, что реклама не приносит денег.
Можно ли восстановить старый источник по UTM-метке?
Если метка была сохранена и связана с обращением, её можно использовать по принятым правилам. Если такой связи не было, нельзя задним числом назначить источник всем старым заказам. Неизвестные останутся неизвестными.
Нужно ли покупать отдельный сервис аналитики?
Решение зависит от количества источников, доступных интеграций и поддержки. Сначала опишите минимальный отчёт и проверьте контрольный заказ. После этого сравнивайте полный состав предложений, включая телефонию и настройку.
Почему числа в CRM и Метрике расходятся?
Разными могут быть единицы учёта, периоды, часовые пояса, модели атрибуции и правила дублей. Часть событий также может не привязаться к визиту. Сначала сравните определения и конкретные записи, затем итоговые суммы.
Может ли ИИ сам отключать убыточную рекламу?
Из этой инструкции такой доступ не возникает. Для начала используйте помощника как средство проверки таблицы и вопросов. Изменение бюджетов требует отдельно настроенного процесса, прав и контроля; при неполных данных рекомендация может оказаться неверной.
С чего начать прямо сейчас?
- За 10–15 минут запишите одно решение, для которого нужен отчёт: например, сравнить расходы каналов с оплаченными заказами. Укажите период и что считаете оплатой. Сервис на этом шаге не покупайте.
- Возьмите один уже известный заказ и найдите заявку, источник и подтверждённый платёж. Если связи нет, выпишите разрыв. Не пытайтесь заполнить его догадкой.
- Определите следующий маршрут. При нескольких заказах начните с таблицы и ручной сверки. При большом потоке передайте специалисту схему полей, обменов и приёмки; выбор сервиса пойдёт после этого.
- Заполните промпт обезличенными вводными и получите черновик задания. Проверьте, что неизвестные остались видимыми, а числа совпали с вашим учётом.
- Примите минимальную цепочку на контрольном примере, дубле и ошибке. Только после сверки используйте отчёт для гипотез о бюджете и расширяйте аналитику.
Что в итоге?
Для начала достаточно связать источник, обращение, заказ и платёж и проверить суммы. В учебной мастерской дешёвые заявки оказались слабее по вкладу после затрат, хотя цена оплаченного заказа была одинаковой. В вашей компании результат может быть другим: его нужно получить из собственных данных.
Моя отправная точка здесь: сначала один подтверждённый путь и понятные ограничения, затем общий отчёт. Если оплаты есть, а затраты или источники неизвестны, это полезный промежуточный результат. Он показывает, что ещё надо собрать, и не притворяется готовым расчётом прибыли.
Чтобы сквозной аналитике было что считать, нужен поток обращений. Один из источников — материалы на портале с формами в вашу воронку: их производство можно подключить в контент-заводе Wake Up.
