Сколько касаний нужно до B2B-заявки: как анализировать customer journey

Короткий ответ. Число касаний до B2B-заявки нельзя честно назвать одной «средней цифрой» для рынка. Оно зависит от чека, риска, количества ЛПР и категории. Полезнее восстановить реальные customer journeys и понять, какие касания чаще участвуют до qualified lead/opportunity.

Что считать касанием

Не каждое техническое событие. Полезный минимум:

• первый известный визит;
• commercial page;
• case/research/tool;
• paid return;
• branded search;
• email/CRM touch;
• event/demo;
• lead;
• opportunity.

Identity problem

Человек меняет устройства, удаляет cookie, коллеги из одной компании заходят отдельно. Поэтому digital journey всегда неполон. Не нужно создавать иллюзию абсолютной атрибуции.

Методика

1. Выбрать cohort закрытых/qualified leads.
2. Установить окно, например 90/180 дней в зависимости от цикла.
3. Собрать известные web/ad/CRM touchpoints.
4. Сгруппировать journeys: 1 touch, 2–3, 4+.
5. Сравнить типы контента/каналов.

Что важно кроме количества

Sequence. Путь SEO guide → case → branded Direct → form сильно отличается от generic Search → form. Первый показывает роль контента, даже если last click — реклама.

Роль нескольких ЛПР

B2B-решение может иметь journey на уровне аккаунта, а не cookie. Один специалист читает техническую статью, руководитель открывает pricing, закупщик возвращается к кейсу. CRM/account analytics должны учитывать это ограничение.

Как использовать вывод

Если много сделок проходят через case/research, усиливать эти форматы. Если посетители после generic статьи не двигаются дальше — улучшить internal linking и CTA. Если branded search часто финальный touch — не приписывать ему всю ценность.

Исследование должно давать карту реального пути, а не рекламную цифру «клиенту нужно 7 касаний».

Что спросить у подрядчика до старта

По теме B2B customer journey полезнее обсуждать не список работ, а способ принятия решений. Попросите подрядчика показать:

1. Как он определит исходную точку. Какие данные нужны до первой рекомендации?
2. Как разделит гипотезы. Что будет проверяться первым и почему?
3. Какие события настроит. Как результат дойдёт до Метрики/CRM?
4. Что считается успехом. Какая метрика и какой горизонт?
5. Что произойдёт при неуспехе. Есть ли заранее определённый следующий шаг?

Если ответ сводится к “мы всё настроим по лучшим практикам”, это слабый сигнал. Сильная команда может объяснить причинно-следственную цепочку ещё до начала работ.

Контрольный список

• Вопрос исследования один и конкретный.
• Выборка описана.
• Определения метрик одинаковы.
• Ограничения опубликованы.
• Сегменты проверены.
• Вывод приводит к действию.

Три уровня зрелости по теме «B2B customer journey»

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

Уровень 1 — рабочий минимум

На этом уровне есть корректный вопрос и чистая выборка. Главная задача — устранить очевидные потери и получить достоверную базовую картину. Здесь не нужны сложные dashboards и автоматизация ради самой автоматизации: важнее, чтобы ключевой путь пользователя работал предсказуемо.

Уровень 2 — управляемая система

Следующий уровень — выводы сегментированы и имеют ограничения. Команда перестаёт спорить о результате “по ощущениям”: у каждого этапа есть измерение, данные передаются между системами, а изменения запускаются как гипотезы. Обычно именно здесь digital начинает становиться воспроизводимым процессом, а не набором разовых работ.

Уровень 3 — масштабирование

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

Практический вывод: сначала определите свой уровень и не покупайте архитектуру третьего уровня, если ещё не закрыты проблемы первого. Но и не стройте первый уровень так, чтобы для перехода ко второму пришлось всё выбросить.

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

Нужно внедрять всё сразу?

Нет. Выберите одно ограничение и расширяйте систему после подтверждённого эффекта.

Когда нужен внешний подрядчик?

Когда задача проходит через несколько дисциплин и важна единая ответственность за результат.

Стандарт методологии для публикации исследования YANORA

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

Не публиковать только среднее

Для стоимости/конверсии показывайте медиану и распределение/диапазон, когда выборка позволяет. Один экстремальный проект может сделать среднее непохожим ни на один реальный кейс.

Сегментация до вывода

Разделяйте данные по факторам, которые могут менять результат: канал, ниша, география, intent, device, период, raw/qualified status. Но не дробите выборку до групп из двух наблюдений ради красивой диаграммы.

Корреляция и причинность

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

Privacy

Данные клиентов агрегируются и обезличиваются. Не публикуйте campaign names, запросы, суммы или screenshots, по которым можно восстановить конфиденциальную компанию, без разрешения.

Финальная структура вывода

1. Что обнаружили.
2. Насколько уверены.
3. Что может объяснять результат.
4. Что нельзя утверждать.
5. Как бизнес может проверить вывод на своих данных.

Именно такая честность делает исследование сильным ссылочным и доверительным активом.

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

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

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

Визуализация должна показывать распределение, а не только «красивое число». Для неоднородных данных добавляйте медиану, диапазон, sample size и подпись методологии. У читателя должна быть возможность понять, насколько вывод применим к его ситуации.

В конце обязательно дайте инструкцию «как проверить на своих данных». Именно это превращает исследовательскую статью из PR-материала в практический инструмент.

Проверка здравого смысла перед внедрением

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

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

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

Что делать дальше

Если вам актуальна тема B2B customer journey, YANORA может сначала разобрать исходную ситуацию, а не продавать готовый пакет. Мы посмотрим на спрос, страницу, данные и ограничения и предложим минимальную архитектуру решения.

Если задача проходит через несколько зон — например, сайт, трафик, SEO, CRM и автоматизацию — единая команда уменьшает количество стыков и взаимных «это не наша зона». Мы можем закрыть аналитику и CRM и связать работу с аналитикой.

CTA: Получить разбор задачи

Что делать дальше

Разобрать задачу на ваших данных

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

Получить разбор →