MQL/SQL появились как ответ на конкретный конфликт: маркетинг присылает лиды, продажи говорят “это не лиды, это мусор”. Квалификация по фирмографическим и поведенческим критериям, SLA между командами, воронка MQL -> SQL -> сделка - всё это решает вопрос качества лида. Если процесс настроен, обе команды хотя бы говорят на одном языке о том, что считать “хорошим” лидом.
Но у зрелой квалификации есть слепая зона. MQL/SQL отвечают на вопрос “этот лид достаточно хорош, чтобы им занимались продажи”, а не на вопрос “какой канал приносит SQL, которые реально закрываются в деньги”. Можно идеально настроить оценку лидов и держать конверсию MQL в SQL в норме - и продолжать лить бюджет в канал, который даёт много SQL, но почти не даёт закрытых сделок.
В чём остаётся проблема
Маркетинг смотрит в свою систему и видит объём: сколько MQL пришло с каждого канала за месяц. Продажи смотрят в свою систему и видят конверсию: какой процент SQL из каждого источника доходит до закрытой сделки. Эти два среза почти никогда не живут в одной таблице.
Здесь применима матрица Дэвенпорта - фреймворк зрелости аналитики по двум осям: время (прошлое/настоящее/будущее) и ценность выводов (факт -> причина -> рекомендация -> прогноз). “У канала A 500 MQL в этом месяце” - это низший уровень, отчёт: факт без причины. Хороший инсайт по Дэвенпорту начинается минимум с анализа причин, а на практике должен доходить до рекомендации - что делать с бюджетом. Отчёт по MQL-объёму этому критерию не соответствует: он говорит, что произошло, но не почему и не что делать дальше. Решения “куда лить бюджет”, принятые по MQL-таблице, опираются на аналитику самого низкого уровня зрелости - и потому систематически ошибочны.
Пример из практики небольшого B2B SaaS со средним чеком порядка $300 в месяц: канал A (LinkedIn Ads с широким таргетингом) даёт 500 MQL в месяц - объём здесь ожидаемо большой, это плата за широкий охват, - но лишь 10% доходят до SQL: 50 сделок в статусе SQL. Канал B (нишевая контекстная реклама по конкретным запросам) даёт всего 50 MQL, зато конверсия в SQL - 40%, двадцать штук: узкий трафик отбирает более целевую аудиторию сам по себе. По объёму воронки канал A выглядит сильнее в десять раз. Но у канала A закрывается 5 сделок из 50 SQL (10%, ниже среднего SQL-to-close 20-25% - типично для менее целевого трафика), а у канала B - тоже 5 сделок, но из 20 SQL (25%, ровно на уровне среднего). Одинаковый результат в деньгах при вдесятеро меньшем объёме воронки - а маркетинг может об этом не узнать, потому что данные о закрытии живут в CRM у sales, а отчёт по каналам собирается из рекламных кабинетов и GA4. MQL/SQL показывают, что лид качественный на входе в воронку - но не что происходит с ним дальше, вплоть до денег на счету.
Метрика, которой не хватает
Единственная метрика, закрывающая этот разрыв, - CAC по каналу, посчитанный не на MQL и не на SQL, а на число сделок, реально дошедших до оплаты.
Это тот же принцип, о котором мы писали, разбирая расхождение GA4 и CRM: бюджетные решения нужно принимать по данным о деньгах, а не по промежуточным метрикам воронки. MQL count и SQL rate - хорошие индикаторы здоровья квалификации, но не основание для решения “куда двигать бюджет между каналами”.
Почему это сложно получить
Источник лида фиксируется в рекламном кабинете в момент клика: gclid в Google Ads, fbclid в Meta, li_fat_id в LinkedIn. Факт закрытия сделки - событие в CRM, которое происходит через недели или месяцы после клика и обрабатывается совершенно другой командой в другой системе. По умолчанию эти две системы друг с другом не разговаривают.
Стандартный обходной путь - UTM-параметры плюс GA4, по умолчанию он считает по модели last-click: всю ценность сделки получает последний источник перед конверсией. Модель проста, но занижает роль каналов верхней части воронки - контента, brand-кампаний, SEO - и завышает роль “финишеров”, подхватывающих уже тёплого лида. Есть альтернативы: multi-touch распределяет ценность между всеми точками контакта (например, поровну между brand-показом, статьёй в блоге и платным поиском перед покупкой), time-decay взвешивает поздние касания сильнее ранних. Ни одна из моделей не единственно верная - у multi-touch нет универсального “правильного” распределения весов. Но даже он честнее last-click, который в B2B со sales-циклом от трёх месяцев почти гарантированно приписывает всю заслугу неправильному каналу.
Проблема глубже выбора модели: и last-click, и multi-touch, и time-decay распределяют ценность лида или клика, а не выручки. GA4 фиксирует “заполнил форму”, а не “подписал контракт через 60 дней” - он не видит воронку продаж после передачи лида в CRM. UTM+GA4 даёт атрибуцию до лида, но не до выручки, вне зависимости от модели - разрыв остаётся ровно там же, где начинается настоящий вопрос: какой канал приносит деньги, а не заявки.
Практический подход
Рабочая схема строится в три шага. Первый - захват click ID (gclid, fbclid, li_fat_id) в момент заполнения формы и сохранение его вместе с лидом в CRM как отдельное поле сделки. Подробно эта механика разобрана в материале про click ID атрибуцию - без этого шага следующие невозможны.
Второй - когда сделка закрывается, событие с суммой и привязанным click ID отправляется обратно в рекламную платформу как офлайн-конверсия: Google Ads Offline Conversion Import, Meta Conversion API, LinkedIn Conversion API. Так алгоритмы начинают оптимизироваться под реальную выручку, а не под клики.
Третий - регулярная сверка: CAC по каналу на закрытые сделки должен обновляться минимум раз в месяц и быть доступен и маркетингу, и продажам в одном месте. Это уже не отчёт по Дэвенпорту, а анализ причин, а с решением по бюджету - полноценная рекомендация.
Такую связку выстраивает Prooflytics: он соединяет данные рекламных кабинетов с CRM-воронкой и показывает реальный CAC по каналу, от первого клика до закрытой сделки, без ручной сборки таблиц из трёх разных систем.
Что это меняет на практике
Первый эффект - бюджет перестаёт незаметно утекать в каналы с хорошим объёмом MQL, но слабой конверсией в деньги: как только в отчёте появляется CAC на закрытую сделку, картина часто переворачивается.
Второй эффект важнее операционно: маркетинг и продажи перестают спорить о качестве лидов и начинают смотреть в одну цифру. Согласование MQL/SQL решает конфликт “это плохой лид” на входе в воронку. Атрибуция по каналу до выручки решает следующий конфликт - “мы тратим бюджет не туда” - который остаётся даже при идеально настроенной квалификации, и переводит разговор с уровня отчёта на уровень рекомендации.