Карта пути клиента: от первого контакта до повторной покупки

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

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

Аналитика через MCP PR-CY — только если она нужна для подтверждения этапов на сайте:
1. По домену получи project_id через get_user_project_by_domain. Проверь наличие доступа к Метрике.
2. Получи список целей через get_metrika_goals. Сопоставь названия целей с этапами и уточни неоднозначные; не выбирай покупку или заявку по догадке.
3. Для выбранных целей используй get_metrika_goals_conversion с goal_ids и явными date_from/date_to. Для связи источника, входной страницы и конкретной цели — get_metrika_conversion_rate_by_source_and_landing с goal_id и тем же периодом.
4. Эти отчёты дают агрегаты. Достижение нескольких целей не доказывает, что одни и те же люди прошли их последовательно. Для переходов между этапами нужна когортная или событийная выгрузка; для эмоций и мотивов — слова и наблюдения клиентов.
Если MCP, проект или Метрика недоступны, предупреди и запроси в чат отчёты по этапам с определениями метрик, периодом и интервью. Доступные части карты можно подготовить сразу.

Качество данных Метрики: перед расчётами проверь ошибку API в самом ответе (включая code/error, даже если внешнее isError=false), sampled/sample_share, общее число строк и выбранные dimensions/metrics, фильтры, атрибуцию и период. Семплированные значения отмечай как оценки; не выдавай их дробную точность за точный подсчёт людей и не округляй её молча. Ограниченная выборка top-N не является полным списком страниц/источников. Не объединяй отчёты с разной атрибуцией или охватом. Если запрос с несколькими целями возвращает «Query is too complicated», раздели его на отдельные цели с теми же датами; не повторяй сложный запрос без изменения.
Проверка выбранной цели: зафиксируй не только название, но и условие срабатывания цели. URL страницы оплаты не доказывает успешную оплату, название «активация» — успешную активацию. Нулевые показатели сначала требуют проверки настройки и сбора цели, а не вывода об отсутствии продаж. Показатели favoriteGoals в сводке источников не подменяют явно выбранную goal_id. Достижения цели показывай отдельно от уникальных целевых визитов/пользователей.

Как работать:
- Сначала опиши клиента и результат, к которому он стремится. Не смешивай разные сегменты в усреднённого посетителя.
- Выбери этапы по реальному сценарию: знакомство, оценка, покупка, первый результат, использование, повторная покупка или рекомендация. Не добавляй лишние этапы ради шаблона.
- Для каждого этапа укажи действия, вопросы, точки контакта, затруднения и источник доказательства. Эмоции без интервью помечай как гипотезы.
- Найди моменты принятия решения и места потери ценности. Отдели низкую конверсию от доказанной причины: цифра показывает, где исследовать, но не объясняет почему.
- Приоритизируй улучшения по подтверждённому масштабу проблемы, влиянию на задачу и усилиям. Если оценки неизвестны, не выдумывай точный балл.

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

Результат: таблица «этап | действие и вопрос клиента | точка контакта | затруднение | доказательство или гипотеза | улучшение»; главные моменты выбора; список следующих исследований. Сохранение в отдельной дизайнерской программе не требуется.