8.2 instruction — Event-based валидация конфигураций¶

Этап RB-STEP-8 — ACQUISITION CONFIGURATION (Stage 7) · Линза: Business/Growth · Инструкция для Инженера Продукта нового поколения (PAF, [S1],[S2]). Преемственность метода: исходный раннбук RB-STEP-8-ACQUISITION-CONFIGURATION/8.2 Валидация конфигураций привлечения.md (3 фазы: Demand/Purchase/Unit Economics; A/B — классическое 95% или байесовский P2BB ≥ 75%; прокси-метрики).

🎯 Цель в PAF-оптике¶

Перевести валидацию из ручного запуска по чеклисту в event-based процесс под Кортексом: агент автозапускает тесты, непрерывно мониторит CP по узлам воронки, проектирует A/B и делает статанализ — с обязательной метапознание-валидацией человеком. Три фазы проверки исходника сохраняются полностью (Demand / Purchase / Unit Economics):

Этап 1 — Demand Validation: люди реагируют? (CTR, CR в лид, CPL).
Этап 2 — Purchase Validation: люди платят? (CR лид→клиент, CAC, время конверсии).
Этап 3 — Unit Economics Validation: экономика сходится? (LTV/CAC ≥ 3, Payback, Margin).

КЛЮЧЕВОЙ сдвиг: линейность 8.1→8.5 → event-based / Kanban: событие «CP вырос» запускает следующий гейт; событие «CP упал» → осознанный отказ или оптимизация [S1, reformation §8.3]. Bottleneck = дистрибуция [S2].

👤 Роль и ответственность¶

Growth Engineer / Growth PM — определяет пороги CAC/CPL/LTV; отвечает за time-to-activation, LTV, COGS токенов AI-функций в воронке [S2]; интерпретирует отчёты Кортекса.
Product Engineer — проектирует AI workflow агента-A/B; задаёт, какие прокси-метрики агенту разрешено подбирать автоматически, какие — только предлагать.
Product Ops — поддерживает Спелость контекста Нексуса (аналитика работает, UTM-метки, цели в GA4/Метрике, CRM); миссия — рост ИИ-зрелости [S2].
Зона человека: стратегическое решение по матрице исходника (валидирована / оптимизация / не валидирована); валидация AI-расчётов CAC; veto.

🤖 Что делает Кортекс-агент¶

Funnel Pulse Agent (event-based мониторинг CP)¶

Автозапуск тестов: по событию «конфигурация вошла в Банч с CP ≥ порога» агент готовит запуск (метод 8.2 Phase 1: UTM, цели, landing, лимиты) и стартует без ручного чеклиста.
Непрерывный мониторинг CP по узлам воронки: вместо «ежедневного чеклиста вручную» агент пересчитывает CP при каждом событии (клики, лиды, оплаты) по колесу Гилада [S1].
Авто-подбор прокси-метрики: при долгой воронке агент ищет событие с наибольшей корреляцией с финальной конверсией (метод 8.2 Phase 2 + кейс Flo: retention 2–8 день коррелирует на 61% с retention 2–8 мес).
Ранние сигналы: прокси-метрики (время на сайте, просмотр «Цены», Retention 7d) как индикаторы до набора полной выборки.

Experiment Design Agent (метапознание-валидация)¶

Проектирует A/B по правилам исходного 8.2: одна переменная за раз, равные выборки 50/50, статистическая значимость ≥ 95% (классический подход) или P2BB ≥ 75–80% (байесовский).
Байесовский P2BB — для малых выборок (< 500 посетителей/нед) и низких конверсий (< 5%); критерий: P2BB ≥ 75% → принять победителя; 55% → продолжить (метод 8.2).
Метапознание-чекпоинт: агент сам помечает «убедительные, но неверные» сценарии (Harvard × BCG [S2]) — ложный победитель на малой выборке, сезонный артефакт — и передаёт человеку.

Кортекс-связки¶

Чистота тестов (метод 8.2): одна переменная за раз; достаточная выборка (50–100 конверсий или P2BB); одинаковые условия; отдельная аналитика с UTM на каждую конфигурацию.
Минимальный период наблюдения по типу канала (контекст 7–14 дней, cold email 7–10 дней / 200–500 писем, SEO 3–6 мес — из 8.2).

🧠 Что делает человек (метапознание)¶

Метапознание — критический фильтр [S2]. Без него Кортекс даёт «убедительные, но неверные» результаты.

Валидирует AI-расчёт CAC (частая ошибка исходника: CAC считают как «расходы/регистрации» — это CPL, не CAC; полный CAC включает ФОТ — метод 8.5).
Ошибки 1/2 рода в ИИ-A/B:
Ошибка I рода (ложный победитель): масштабирование непродукта. Контрмера: P2BB ≥ 75% + sequential testing (метод Evan Miller из 8.2 Further Reading) + запрет подглядывания (peeking) — проверка только после плановой выборки.
Ошибка II рода (пропуск рабочей конфигурации): слишком жёсткий классический порог на малой выборке. Контрмера: переключение на байесовский подход при низком трафике.
Проверка выборки на аномалии (сезон, праздники, сбой кабинета) — метод 8.2 «качество данных теста».
Veto: при падении CP ниже порога — пауза теста, диагностика (метод 8.2 Phase 3 матрица решений).

📦 Артефакт = узлы Нексуса системы роста¶

Журнал экспериментов с CP (по колесу Гилада [S1]): каждая конфигурация → стартовый CP → CP после Demand → после Purchase → после Unit Economics.
Карточки A/B (что тестируем / варианты / метод 95% или P2BB / результат) — метод 8.2 Phase 2.
Прокси-метрика выбранная агентом: событие, период, корреляция с финалом (метод 8.4 Phase 4 + 8.2).
Финальный отчёт по конфигурации (статус: валидирована / оптимизация / не валидирована; метрики факт vs цель; delta) — метод 8.2 Phase 3.
Матрица решений (интерес есть + платят + CAC ок → масштабирование; и т.д.) — метод 8.2 Step 3.2.

🚦 Confidence Point-гейт¶

CP растёт при прохождении каждой фазы: Demand подтверждён (есть реакция) → Purchase подтверждён (платят) → Unit Economics подтверждена (LTV/CAC ≥ 3).
CP падает (Кортекс/инженер [S1]) при: CTR нулевой/низкий, воронка сломана, CAC выше плана, LTV ниже расчётного, аналитика не работает.
Gate pass (CP вырос через фазу) → следующая фаза / переход к оптимизации (8.3) или масштабированию (8.4).
Gate refuse (CP упал) → осознанный отказ: матрица решений исходника (смена оффера/сегмента/канала; при невалидности всех — GTM v2.0, пересчёт медиаплана, корректировка амбиций).
Если все конфигурации не валидированы — критический сигнал: возврат к Value Validation (Stage 3) или Business Model Validation (Stage 5) — метод 8.2 Phase 3.3.

🧮 Матрица решений по результатам валидации (метод `8.2` Step 3.2, в PAF — триггерится по CP)¶

Результат теста	Действие (CP-триггер)
Интерес есть + платят + CAC ок	✅ валидировано → масштабирование (`8.4`)
Интерес есть + платят + CAC высокий	⚙️ оптимизация CAC (`8.3`)
Интерес есть + не платят	🔄 проблема лид→клиент: оффер/воронка (`8.3`)
Интерес слабый + не платят	🔄 проблема в сегменте/оффере → переформулировать
Интереса нет (нулевые клики)	❌ канал не работает для сегмента → смена канала/сегмента
Все конфигурации не валидированы	🚨 пересмотр GTM v2.0, возврат к Stage 6 или пересмотр амбиций

🧮 Минимальный объём данных по типу канала (метод `8.2` Phase 1.2, PAF-условие гейта)¶

Канал	Мин. период	Мин. объём
Контекст / таргет	7–14 дней	30–50 кликов / 10–20 конверсий
Cold email	7–10 дней	200–500 писем
Cold звонки	5–10 дней	50–100 звонков
SEO	3–6 месяцев	первые органические позиции
Реферальная программа	4–8 недель	20–30 рефереров

Выводы раньше минимального периода — не данные (особенно для performance, где алгоритмы обучаются 5–7 дней). Минимальный бюджет теста: 30–50 конверсий × плановый CAC (метод 8.2 FAQ).

✅ Success Criteria (PAF-перевод критериев исходника `8.2`)¶

После event-based валидации: - Каждая конфигурация Банча получила статус (валидирована / оптимизация / не валидирована) с CP после каждой фазы (Demand/Purchase/Unit Economics). - Матрица решений применена — определено следующее действие по каждой. - Медиаплан обновлён на основе реальных данных (CAC/CPL факт vs прогноз). - Если конфигурации не валидированы — GTM v2.0 сформулирован, стейкхолдеры уведомлены честно (метод 8.2 Phase 3.3: «мы потратили X ₽ и узнали, что каналы A и B не работают — это сохранило Y ₽ на масштабировании»). - Хотя бы одна конфигурация перешла на оптимизацию (8.3) или масштабирование (8.4). - Качество данных проверено (метод 8.2): минимальный период соблюдён; выборка достаточна (≥ 30 конверсий или P2BB ≥ 75%); нет внешних аномалий; аналитика работала; конфигурации не пересекались по аудитории.

🔭 Связь с Тремя Линзами (3PL)¶

Business Lens (основная): каждая фаза валидации — проверка рычага дистрибуции; Unit Economics фаза = проверка NPV рычага (LTV окупает CAC) [S1].
Product Lens: Demand/Purchase фазы = проверка продуктовой ценности в канале (оффер резонирует? воронка не ломается?).
Strategic Lens: отчёт «все конфигурации не валидированы» = сигнал к пересмотру Ставок портфеля.

🛡️ Анти-workslop чекпоинт¶

workslop в отчётах: AI-сгенерированные выводы без опоры на данные → маркировка; трассировка каждой цифры до источника (рекламный кабинет / аналитика / CRM).
Ошибки 1/2 рода в ИИ-A/B (острейший риск Stage 8 [reformation §8.9]): P2BB ≥ 75% + sequential + запрет подглядывания; метапознание-валидация «убедительных» победителей.
COGS-эксплозия: при валидации AI-функций в воронке (онбординг-агент, AI-оффер) COGS токенов учитывается в CAC; агент помечает, если рост adoption потянет непрогнозируемый COGS.
Дофаминовая петля ИИ: «зелёный» дашборд агента приятен, но не заменяет метапознание; критерий — изменение CP/NPV, не «всё зелёное».

🧩 Маппинг к Skill Map / профстандарту 06.012¶

Skill Map [S3]: сектор 4 Growth & Experiments (средний круг — анализ, агрегация, обоснованные выводы; A/B-тестирование); луч связи — гипотеза (8.1) → валидация (8.2).
Профстандарт 06.012 [S4]: B/06.5 вывод на рынок, B/08.5 показатели успешности; функция B (уровень 5) → Product Engineer.

🔗 Связи¶

Назад: 8.1 instruction · Дальше: 8.3 instruction (Мульти-эксперимент оптимизации) Связанные: reformation · index · naming_conventions

Version: 1.0 · Last updated: 2026-06-20 Ground truth: index.md [S1,S2], naming_conventions.md, reformation.md §8.5 (строка 8.2), RB-STEP-8-ACQUISITION-CONFIGURATION/8.2…md.