---
name: "cp-funnel"
description: "Строит карту пути «касание → вовлечение → подписка → прогрев → заявка → продажа → повтор» и находит узкое место по конверсиям между этапами, а не по абсолютным числам. Разводит воронку контента (охват → удержание → действие → подписка) и воронку продаж, чтобы их не лечили друг другом. Держит режим малых чисел: на десятках наблюдений конверсия неразличима, и скилл говорит это прямо вместо оптимизации шума. Знает реальность российского учёта — Метрика с Logs API за предыдущий день, соцсети без выгрузок, потеря источника при переходах из мессенджеров — и даёт ручные способы разметки. Отдаёт схему с цифрами, узкое место и три гипотезы с планом проверки. Триггеры — «воронка», «путь клиента», «где теряем людей», «конверсия», «посчитай этапы», «мало заявок», «сквозная аналитика». Use when the user needs a funnel map, conversion diagnosis or wants to find where leads are lost."
---

Перед применением прочитай [правила интеграции «Блог с нуля»](../../context/10-blog-runtime.md). Они задают единый запуск, текущий проект и производственные ограничения; не начинай второй независимый бриф.

# cp-funnel · Воронка и конверсии

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

Воронка — учётная модель, а не физика. Люди возвращаются, пропускают ступени, покупают с первого касания и через год после отписки. Модель нужна, чтобы считать, а не чтобы описывать реальность точно.

## Когда не этот скилл

- Нужен разбор статистики одной площадки или сводный отчёт по всем → `cp-analytics`, `cp-analytics-cross`. Здесь считаются переходы между этапами, а не метрики контента.
- Нужен общий разбор устройства аккаунта по слоям → `cp-audit`. Там воронка — один слой из девяти, проверяется на наличие.
- Нужно починить сам оффер, цену и возражения → `cp-offer`. Нужен вход в воронку → `cp-lead-magnet`, выдача в боте → `cp-bot`, страница → `cp-landing`.

## Контекст

Читай из `context/`: `02-metrics.md` (что за статистика вообще существует на каждой площадке и что несопоставимо), `07-evidence.md` §4 и §5 (порог по собственной медиане, режим малых чисел), `09-tech-ru.md` §2 (Метрика, Logs API, Вебмастер) и §6 (автоматизация и боты), `03-legal-ru.md` §7 (сбор контактов — это персональные данные). Профиль бренда — `brands/<slug>/`: `offer.md` (лестница и цены), `audience.md` (ступени осознанности), `assets.md` (площадки, роли, ссылки, аналитика). Не нашлось — скажи одной строкой и работай по врезке ниже, цифры спрашивай, не выдумывай.

## Врезка констант

**Считается конверсия между соседними этапами, а не абсолютные числа.** Конверсия перехода = число на следующем этапе ÷ число на предыдущем. Сквозная конверсия (продажа ÷ касание) годится для отчёта и бесполезна для починки: она не показывает, где рвётся.

**Узкое место** — переход с наибольшим падением относительно собственной истории и относительно соседних переходов. Чинится первым, остальное замораживается.

**Малые числа.** Относительная погрешность счётной величины примерно 1/√n. При 9 наблюдениях это около ±33%, при 100 — около ±10%, при 900 — около ±3,3%. Это свойство арифметики, а не отраслевая статистика. Следствие: на 20 заявках разница между 8% и 12% неотличима от нуля. Скилл обязан это сказать, а не давать рекомендации по шуму.

**Никаких нормативов конверсии.** «Нормальная конверсия лендинга» и «средняя конверсия из подписчика в заявку» из памяти не называются. Порог — собственная медиана за сопоставимый период.

**Атрибуция в РФ рвётся штатно.** Переход из мессенджера и из приложения часто приходит без реферера и учитывается как прямой заход. Считать, что «прямые заходы» — это лояльная аудитория, нельзя.

**Сбор контактов — персональные данные.** Любая форма, бот и чат подпадают под 152-ФЗ: уведомление РКН до начала обработки, политика, раздельные согласия, база в РФ. Детали → `cp-compliance`.

## Вход

Одним блоком. Что есть в профиле — не переспрашивай.

1. Что считаем целевым действием: заявка, оплата, запись, звонок, визит.
2. Какие площадки участвуют и какая из них дом аудитории.
3. Какие цифры есть по каждому этапу и за какой период. Нет — так и скажи.
4. Куда приземляется трафик: страница, бот, личные сообщения, форма, карта.
5. Есть ли счётчик на сайте, настроены ли цели, используются ли метки в ссылках.
6. Как сейчас учитываются обращения: таблица, CRM, память.

## Процесс

1. **Собери числа по этапам за один период.** Разные периоды не смешивать. Нет числа — пиши `[НЕТ ДАННЫХ]`, не подставляй.
2. **Посчитай конверсию каждого перехода.**
3. **Прогони проверку малых чисел.** Мало наблюдений — скажи это до выводов и переходи к плану накопления.
4. **Найди узкое место** по правилу ниже.
5. **Проверь, не артефакт ли это учёта:** битая ссылка, потерянная метка, дубль счётчика, изменение методики площадки (`07-evidence.md` §7). Артефакт чинится не гипотезами, а разметкой.
6. **Раздели воронку контента и воронку продаж** и определи, в какой из них проблема.
7. **Сформулируй три гипотезы** по расшивке узкого места, каждую с планом проверки.
8. **Назови, чего не хватает в учёте**, и дай минимальную схему разметки.
9. **Выдай схему, узкое место, гипотезы.** Дальше: оффер → `cp-offer`, вход → `cp-lead-magnet`, страница → `cp-landing`, выдача и автоворонка → `cp-bot`.

---

## Карта пути

| Этап | Что происходит | Чем измеряется | Где типично теряют | Что чинится первым |
|---|---|---|---|---|
| **Касание** | человек впервые видит единицу контента или рекламу | охват, показы, просмотры (внутри одной площадки) | вход не цепляет: обложка, первые кадры, первые строки | вход → `cp-hook`, обложка → `cp-cover` |
| **Вовлечение** | реагирует: досматривает, читает, кликает, сохраняет | удержание, клики, сохранения, переходы в профиль | обещание входа не оплачено содержанием; нет причины идти дальше | структура единицы → `cp-script-short`, `cp-carousel` |
| **Подписка** | остаётся, чтобы видеть ещё | прирост подписчиков, переходы в профиль → подписки | непонятно, о чём канал и зачем на него подписываться; шапка и закреп не отвечают | упаковка → `cp-audit`, закреп и описание |
| **Прогрев** | регулярно видит и понемногу доверяет | доля активных, просмотры на пост относительно числа подписчиков, отписки | подписался и не видит контента; нет причины возвращаться; всё в одном ключе | ритм → `cp-calendar`, состав → `cp-content-plan` |
| **Заявка** | делает шаг: пишет, оставляет контакт, записывается | число обращений ÷ активная аудитория | нет следующего шага; призыв одинаковый и невидимый; шаг слишком дорогой (длинная форма, «пишите в личку» без причины); нет промежуточной ступени | вход в воронку → `cp-lead-magnet`, ступень ниже → `cp-offer` |
| **Продажа** | платит | оплаты ÷ заявки, средний чек | медленный ответ; нет процесса обработки; цена и условия не названы до созвона; нечего отправить письменно | оффер и условия → `cp-offer` |
| **Повтор** | возвращается, покупает ещё, рекомендует | доля повторных покупок, доля пришедших по рекомендации | после оплаты касаний нет; второго продукта нет; отзыв не запрашивается | лестница → `cp-offer`, серия писем → `cp-email` |

Этапы можно объединять под конкретный бизнес: у локальной услуги «подписка» и «прогрев» часто схлопываются в один шаг, у товара «прогрев» может отсутствовать. Схема подгоняется под реальность, а не наоборот.

## Диагностика узкого места

1. **Считай переходы, а не итог.** Падение сквозной конверсии ничего не говорит о причине.
2. **Сравнивай переход сам с собой во времени**, а не с чужими нормами. Внешнего эталона у конверсии нет.
3. **Ищи наибольшее относительное падение.** Не самое большое абсолютное число потерь: на верхних этапах абсолютные потери всегда больше, это устройство воронки, а не проблема.
4. **Проверь ниже по течению, прежде чем чинить выше.** Наливать трафик в воронку, которая не конвертирует заявку в продажу, — умножение потерь. Порядок починки: сначала ближе к деньгам, потом ближе к охвату. Исключение — если на нижних этапах нечего чинить из-за отсутствия наблюдений.
5. **Отдели «сломано» от «неэффективно».** Битая ссылка, форма с ошибкой, бот, который не отвечает, потерянная метка — это не гипотеза для теста, это ремонт. Чинится сразу и бесплатно.
6. **Чини одно за раз.** Две правки одновременно делают результат неинтерпретируемым.

**Правило малых чисел в применении.** Прежде чем называть узкое место, посмотри на знаменатель перехода. Десятки наблюдений — разница между вариантами неразличима, и скилл говорит об этом прямо: «на этих объёмах вывод сделать нельзя». Что делать вместо оптимизации процентов: устранить явные поломки, укрупнить период, объединить сопоставимые каналы в один знаменатель, набрать наблюдения и читать качественные сигналы — что именно пишут в заявках и на чём люди останавливаются.

## Воронка контента против воронки продаж

Две разные системы. Их путают, и потому лечат не то.

| | Воронка контента | Воронка продаж |
|---|---|---|
| Этапы | охват → удержание → действие → подписка | заявка → диалог → оплата → повтор |
| Что показывает | доходит ли содержание до людей | превращается ли внимание в деньги |
| Скорость отклика | часы и дни | недели и месяцы |
| Чем чинится | вход, структура, ритм, форматы | оффер, цена, условия, скорость и качество обработки |

**Как отличить, где проблема.** Контентная воронка здорова (охваты и удержание в пределах собственной медианы, подписки идут), а заявок нет — проблема не в охвате: смотри следующий шаг, оффер и ступень осознанности аудитории (`cp-audience`). Контентная воронка просела, а конверсия из заявки в оплату прежняя — проблема наверху, и продающие тексты её не вылечат.

**Частая ошибка.** Ответ «мало продаж — надо больше публиковать» верен реже, чем кажется. Сначала считается переход заявка → продажа: если он низкий, рост охвата масштабирует потери.

## Реальность российского учёта

**Что доступно.**

- **Яндекс.Метрика** — счётчик, цели, отчёты по источникам. **Logs API** отдаёт неагрегированные визиты и события: сквозная аналитика, произвольные модели атрибуции, отчёты, которых нет в интерфейсе. **Ключевое ограничение: данные доступны за предыдущий день, не за текущий** — оперативно смотреть по ним нельзя.
- **Яндекс.Вебмастер, API мониторинга запросов** — позиции, показы, клики, CTR. История ограничена, отдельный день внутри диапазона не выгружается.
- **Статистика соцсетей** — по каждой площадке своё: у ВКонтакте есть нативная выгрузка и `stats.get`, у Дзена выгрузка есть, у Telegram выгрузки нет вообще, у Instagram нативного CSV нет. Состав метрик и способы выгрузки — `context/02-metrics.md` §1.
- **Учёт обращений руками.** На малых объёмах таблица с полями «дата, канал, последнее касание, что просили, что ответили, статус, сумма» даёт больше, чем любая аналитика. Это не временное решение, а нормальный инструмент.

**Где атрибуция рвётся.**

- Переход из Telegram, мессенджеров и части приложений приходит **без реферера** и попадает в «прямые заходы».
- Ссылка, пересланная в переписке, теряет метки при копировании текста.
- Обращение в личные сообщения не связывается с источником вообще.
- Часть площадок не показывает уникальных пользователей, только просмотры, поэтому знаменателя для конверсии там нет.
- Один человек приходит с нескольких устройств и считается несколько раз.

**Что с этим делать — по возрастанию трудозатрат.**

1. Отдельная ссылка на каждый канал и на каждое размещение, метки в ссылке.
2. Отдельный вход в бота с параметром в ссылке под каждый источник.
3. Кодовое слово или отдельная посадочная под конкретное размещение.
4. Вопрос «откуда узнали» в форме заявки — самоотчёт грязный, но лучше пустоты.
5. Промокод под канал, если есть оплата.
6. Сведение через Logs API, когда объёмы выросли настолько, что ручной учёт перестал справляться.

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

## Выход

```
ВОРОНКА · <бренд> · период <с — по> · целевое действие: <какое>

СХЕМА
  Касание        <N>                 источник данных: <откуда>
  Вовлечение     <N>    → <K1>%
  Подписка       <N>    → <K2>%
  Прогрев        <N>    → <K3>%
  Заявка         <N>    → <K4>%
  Продажа        <N>    → <K5>%
  Повтор         <N>    → <K6>%
  Сквозная: <N продаж / N касаний> = <…>%   (для отчёта, не для починки)

КАЧЕСТВО ДАННЫХ
  Нет данных по: <этапы>
  Разметка теряется на: <где>
  Наблюдений мало для выводов на переходах: <какие> — разница неразличима

УЗКОЕ МЕСТО
  Переход <A → B>, конверсия <…>% против <…>% на соседних переходах
  Почему именно он: <обоснование от чисел>
  Это поломка или неэффективность: <что именно>

ЧИНИМ СНАЧАЛА (ремонт, не гипотезы)
  <битые ссылки, потерянные метки, молчащий бот, форма с ошибкой>

ТРИ ГИПОТЕЗЫ
  1. <что меняем> → ожидаем сдвиг <какой метрики>
     Как проверить: <что делаем>, сколько наблюдений нужно, срок, что считаем результатом
  2. …
  3. …

ЧТО НЕ ТРОГАЕМ, ПОКА ИДЁТ ПРОВЕРКА
  <остальные этапы>
```

Гипотез ровно три и по одному узкому месту. Список из десяти улучшений не выполняется и не проверяется.

## Чек-лист перед выдачей

- Все числа за один период, период назван.
- Посчитаны конверсии переходов, а не только сквозная.
- Отсутствующие данные помечены `[НЕТ ДАННЫХ]`, а не заполнены правдоподобным.
- Проверка малых чисел выполнена и её вывод озвучен до рекомендаций.
- Узкое место одно, названо от чисел, а не от удобства.
- Поломки учёта отделены от гипотез и вынесены в ремонт.
- Разведены воронка контента и воронка продаж, сказано, в какой проблема.
- Три гипотезы, у каждой способ проверки, требуемый объём наблюдений и срок.
- Ни одного норматива конверсии из головы.
- Если собираются контакты — напоминание про правовой контур со ссылкой на `cp-compliance`.

## Красные линии

1. **Не называть «нормальную конверсию».** Внешнего эталона нет, порог — собственная медиана.
2. **Не строить выводы на десятках наблюдений** и не комментировать шум как результат.
3. **Не считать абсолютные потери проблемой.** Наверху воронки они всегда больше по устройству модели.
4. **Не сравнивать метрики разных площадок в одной колонке** — «просмотр» везде означает разное.
5. **Не обещать рост конверсии от правки.** Гипотеза называется гипотезой и проверяется.
6. **Не чинить верх воронки, пока не проверен низ**, если данные по низу есть.
7. **Не выдумывать источники трафика** там, где атрибуция потеряна. «Не знаем» — корректный результат.
8. **Не предлагать сбор контактов без правового контура** и не переносить базу в зарубежные сервисы.