aa-conversion-funnel-analysis

Этот навык Adobe Analytics предназначен для разбора многошаговой воронки: он помогает определить, на каком переходе посетители прекращают путь, сравнить прохождение этапов и найти наиболее сильную утечку. Он подходит для вопросов о checkout, регистрации, add-to-cart, покупке и других последовательностях, где нужно сопоставить число визитов на каждом шаге. Навык не подменяет данные конкретного отчётного набора: сначала он просит описать воронку и уточнить, должны ли все шаги происходить в одной визите или допускается путь через несколько визитов. Для типичной checkout-воронки используется visit-level логика. В Adobe Analytics важно различать контейнеры hit, visit и visitor. В этом workflow этапы моделируются как сегменты уровня визита: в сегмент попадают визиты, в которых пользователь выполнил условие конкретного шага. Это отличается от CJA-подхода с event, session и person и не должно автоматически переноситься между продуктами. Источник также отмечает, что доступного через MCP нативного последовательного fallout API нет. Поэтому навык приближает последовательный анализ: для каждого этапа он находит или создаёт visit-level segment, запускает отчёт с метрикой visits и вычисляет проход по данным отдельных сегментов. Работа начинается с выбора report suite и установки контекста сессии через findReportSuites и setSessionDefaults. Затем пользователь описывает от трёх до восьми этапов обычными словами и для каждого указывает, задаётся ли он страницей, событием или их сочетанием, а также нужен ли hit- или visit-level критерий. findDimensions помогает найти подходящие dimensions, а searchDimensionItems проверяет фактические значения страниц или событий. findMetrics используется для поиска доступных метрик, например visits, orders или pageviews. Если подходящего сегмента нет, findSegments ищет существующий, а upsertSegment может подготовить отдельный сегмент для шага. После определения всех шагов runReport вызывается отдельно для каждого segment с dimensionId variables/page и metricIds metrics/visits. Отчёт читает итог из summaryData.totals[0], а не из случайной строки rows. Отдельный запуск без сегмента даёт базовое число визитов. Для каждого этапа можно получить число визитов и долю от общей базы; для соседних этапов рассчитываются step-to-step rate и drop-off rate. Абсолютная разница между соседними значениями показывает масштаб потери, а минимальная доля перехода — самое слабое место воронки. Это расчёт по возвращённым данным, а не универсальная оценка качества интерфейса. После нахождения худшего перехода навык предлагает drill-down. Можно сопоставить device type, traffic source или new/returning mix для сегментов до и после потери. Такой разрез помогает проверить гипотезу о том, что проблема связана с конкретным устройством, источником или типом посетителя, но сам по себе не доказывает причинность. Для длинных воронок полезно явно фиксировать период, названия dimensions, выбранную метрику и идентификаторы сегментов, чтобы повторный отчёт был сопоставимым. У workflow есть операционные ограничения. Он не получает права к Adobe Analytics, не выбирает report suite за пользователя и не исправляет неверные имена страниц или событий. Создание новых visit-level segments требует явного подтверждения; сначала нужно показать их список, а затем только выполнять запись. Результат зависит от доступных MCP-инструментов, корректного контекста компании, диапазона дат и качества разметки. Навык не обещает безопасность или рост конверсии, не заменяет проверку исходных данных и не превращает приблизительный fallout в доказательство поведения каждого пользователя.