Как создать и выгрузить отчет из CRM для проверки гипотез по воронке, источникам и сегментам

Если вам нужно быстро проверить гипотезу по воронке, чаще всего мешает не нехватка данных, а их избыток. Для первого прохода не нужен дашборд на двадцать метрик. Достаточно одного аккуратно собранного CRM-отчета, где не смешаны разные объекты, единый период и понятна логика источника.

Дальше речь только о CRM, где есть стандартные свойства стадий и источников, как в HubSpot: Lifecycle stage или Deal stage, автоматические даты входа в стадии, а также Original Traffic Source и Latest Traffic Source с drill-down-полями. Это не универсальная схема для любой CRM: если стадии и источники у вас кастомные и не имеют системных timestamp-полей, тот же подход придется адаптировать вручную.

Какие гипотезы реально проверять таким отчетом

Минимальный CRM-отчет полезен для трех типов вопросов.

• Где проваливается переход между стадиями. Например, из Lead в MQL проходит нормальный объем, а из MQL в SQL — заметно хуже.
• Какой источник дает не просто много входа, а лучшее продвижение по воронке. Не только сколько лидов пришло, но и сколько дошло до поздних стадий.
• Какие кампании и сегменты доходят дальше. Например, платный social дает много ранних стадий, а email или referrals — меньше входа, но выше доля переходов к сделке.

Такой отчет отвечает не на вопрос «какой канал лучший вообще», а на более прикладной: на каком этапе и у какого сегмента теряется качество движения по воронке.

Сначала выберите одну единицу анализа

Главная ошибка — смешать контакты и сделки в одном сравнении. В HubSpot funnel-отчеты строятся по одному объекту: контактам, компаниям или сделкам.

• Если вы анализируете маркетинговую квалификацию и lifecycle — обычно берут Contacts.
• Если вы проверяете прохождение коммерческого пайплайна — берут Deals.

Не стоит в одном файле одновременно сравнивать количество контактов на ранних стадиях и количество сделок на поздних: это уже две разные воронки с разной логикой перехода. Для минимального отчета лучше выбрать один объект на одну гипотезу.

Минимальный набор полей

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

Важная оговорка: в стандартной модели HubSpot контекст источника часто живет не в отдельных raw UTM-свойствах, а в Traffic Source Drill-Down. Например, название кампании может подтягиваться из utm_campaign, а source/medium — не всегда лежать в отдельных CRM-полях как готовые свойства контакта или сделки. Поэтому минимальный обязательный набор — это stage-поля и source-поля, а raw UTM добавляются, если они реально записываются в вашей конфигурации.

Еще одно полезное разграничение: Traffic Source — это про то, как контакт впервые или в последний раз пришел через веб-взаимодействие. Record Source — это про то, как запись вообще была создана в системе: импортом, API, вручную, интеграцией. Для гипотез по маркетинговому входу нужен прежде всего Traffic Source, а Record Source помогает понять, не смешали ли вы веб и офлайн-создание записей.

Как собрать базовый funnel report без лишних метрик

В HubSpot для этого удобнее всего использовать стандартный funnel report по lifecycle stages или deal stages.

1. Выберите объект: Contacts для lifecycle-воронки или Deals для pipeline-воронки.
2. Задайте единый период. Здесь важно помнить: фильтр по дате в funnel report относится к дате прохождения события или стадии, а не к дате создания записи.
3. Добавьте стандартные стадии в нужном порядке. Для такого отчета лучше не усложнять воронку необязательными промежуточными шагами без ясной цели.
4. Смотрите conversion rate между этапами. На первом проходе этого достаточно. Не нужно сразу добавлять десяток дополнительных KPI.

Критически важное ограничение: стандартные funnel-отчеты HubSpot работают на встроенных свойствах Lifecycle stage и Deal stage, потому что у них есть автоматические даты входа в стадию. Кастомные свойства такие timestamp-поля не создают, поэтому использовать их как шаги той же воронки нельзя.

Что читать в таком отчете:

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

Как подготовить выгрузку для сравнения источников, кампаний и сегментов

Сам funnel report хорош для визуальной диагностики, но для сравнения сегментов нужна выгрузка на уровне записей. Тут лучше не экспортировать сам funnel report как итоговую основу анализа. У HubSpot есть важное ограничение: воронка показывает записи, которые меняли стадии в выбранном диапазоне, а экспорт funnel report может содержать записи, созданные в этом диапазоне. Из-за этого числа в файле и в визуализации могут не совпасть.

Практически надежнее делать так:

1. Определите один объект анализа: только контакты или только сделки.
2. Сохраните тот же временной диапазон, что и в funnel report.
3. Выгрузите записи с нужными полями: stage, dates entered stage, source-поля, drill-down, при наличии — UTM и сегментные признаки.
4. Примените одинаковые фильтры для всех сравнений.
5. Постройте отдельно два сценария: first-touch по Original Traffic Source и latest-touch по Latest Traffic Source.

Сегменты для сравнения должны быть простыми и взаимно понятными: источник, кампания, medium, аудитория, регион, тип формы, продуктовая линия. Если вы одновременно поменяете объект, период и фильтры, гипотеза распадется: вы уже не поймете, из-за чего различие появилось.

Учебный пример. Допустим, вы сравниваете две аудитории внутри одного периода: лиды из paid social и лиды из email. Корректное сравнение — это одна и та же contact lifecycle-воронка, одинаковые стадии, одинаковый диапазон дат и два отдельных среза по source. Некорректное — сравнить paid social по контактам, а email по сделкам, потому что поздние стадии у вас удобнее смотреть в пайплайне.

Как интерпретировать узкие места

После выгрузки полезно задавать себе не вопрос «какой канал победил», а три более точных вопроса.

1. Проблема во входном качестве или в продвижении по стадиям?

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

2. Есть ли провал на конкретном переходе?

Смотрите не только общую конверсию в финал, но и падение между соседними этапами. Провал между Lead и MQL чаще указывает на качество входа или правила квалификации. Провал между SQL и Opportunity уже ближе к sales-процессу, маршрутизации или офферу.

3. Не маскируется ли проблема пропусками стадий?

Если объекты перескакивают этап, вы можете принять CRM-дисциплину за маркетинговую проблему. Например, команда переводит контакт сразу в SQL, не фиксируя MQL. Тогда конверсия воронки «ломается» не потому, что гипотеза неверна, а потому, что стадия не ведется последовательно.

Что проверить до выводов, чтобы не ошибиться

• Не смешан ли first-touch и latest-touch. Original Source отвечает на вопрос «откуда пришел впервые», Latest Source — «какой был последний известный веб-источник». Их нельзя подменять друг другом в одном выводе.
• Есть ли системные даты входа в стадию. Если вы построили логику на кастомных статусах без timestamp-полей, сравнение будет ненадежным.
• Полна ли UTM-разметка. Для кампаний нужны как минимум utm_source, utm_medium и utm_campaign; для креативов полезен utm_content. Неполная разметка распадается на пропуски и некорректные категории.
• Единообразно ли названы UTM. В аналитике регистр важен: Meta и meta — разные значения. То же касается вариантов вроде spring_sale и SpringSale.
• Не слишком ли много direct traffic, offline sources и пустых campaign/source. Это признак не только «бренда», но и дыр в разметке, cookie-ограничений, импорта записей или ручного создания.
• Не влияют ли блокировщики и reprocessing данных. HubSpot прямо указывает, что ad-blockers могут мешать tracking cookies, а исторические данные по источникам могут пересчитываться по мере уточнения.

Если после этой проверки картина остается устойчивой, у вас уже есть база для гипотезы. Например: «У paid social нормальный объем входа, но слабая конверсия из Lead в MQL по сравнению с email; стоит тестировать не следующий этап продаж, а качество первого касания, сегмент аудитории или креатив».

Итоговая логика проста: сначала минимальная стандартная воронка на одном объекте, потом аккуратная выгрузка на уровне записей, затем раздельный анализ first-touch и latest-touch, и только после этого — выводы по источникам, кампаниям и сегментам. Так вы проверяете гипотезу быстрее и не теряете смысл в лишних метриках.