Гипотеза 1: Изменение качества трафика Рекламная кампания привлекла менее целевую аудиторию. Общий объём регистраций вырос, но доля «горячих» пользователей снизилась. Проверка: сравнить конверсию по источникам трафика.

SELECT
  utm_source,
  COUNT(DISTINCT user_id) AS registrations,
  COUNT(DISTINCT CASE WHEN first_purchase_at IS NOT NULL THEN user_id END) AS buyers,
  ROUND(100.0 * COUNT(DISTINCT CASE WHEN first_purchase_at IS NOT NULL THEN user_id END)
    / NULLIF(COUNT(DISTINCT user_id), 0), 1) AS conversion_pct
FROM users
WHERE registered_at >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY utm_source
ORDER BY registrations DESC;

Гипотеза 2: Поломка в воронке онбординга Могла сломаться страница или шаг после регистрации. Проверка: построить воронку по шагам от регистрации до покупки, сравнить с предыдущим периодом.

Гипотеза 3: Сезонность Естественное сезонное снижение покупательской активности. Проверка: сравнить с аналогичным периодом прошлого года.

Гипотеза 4: Изменение ассортимента или цен Товары, которые привлекают новичков, могли закончиться или подорожать. Проверка: конверсия по категориям товаров первой покупки.

Гипотеза 5: Техническая проблема с оплатой Ошибки на этапе оплаты у определённых способов или устройств. Проверка: процент ошибок оплаты по дням и типам устройств.

Анализ метрик за февраль 2026

MAU +20.8% — рост. Положительно, но важно понять качество новых пользователей.

• Причина: рекламные кампании VK + Telegram Ads + новый регион.
• Действие: сегментировать MAU по источнику и проверить, какая доля доходит до заказа.

Заказы -4.4% — тревожный сигнал на фоне роста аудитории.

• Причина: новые пользователи из рекламы пока не конвертируются; возможно, ассортимент не адаптирован под Сибирь.
• Действие: рассчитать конверсию в заказ отдельно для старых и новых пользователей.

Средний чек -10.9% — тревожно.

• Причина: новая аудитория из VK Ads, вероятно, чувствительнее к цене; возможно, промо-скидки.
• Действие: проверить распределение чека по когортам (старые vs новые).

Выручка -14.9% — критично, требует немедленного внимания.

• Причина: сочетание падения числа заказов и среднего чека.
• Действие: декомпозировать выручку = заказы x средний чек и найти, какой фактор влияет сильнее.

CAC -12.5% — положительно, но с оговоркой.

• Причина: дешёвый трафик из VK и нового региона.
• Действие: рассчитать ROI по каналам — дешёвый трафик не равен качественному.

Retention D30 -6 п.п. — самая тревожная метрика.

• Причина: новые пользователи удерживаются хуже; возможно, ожидания после рекламы не совпадают с продуктом.
• Действие: построить retention-кривые отдельно для органических и рекламных пользователей.

WITH cohorts AS (
  SELECT
    user_id,
    DATE_TRUNC('week', registered_at)::date AS cohort_week
  FROM users
  WHERE registered_at >= CURRENT_DATE - INTERVAL '8 weeks'
),
user_activity AS (
  SELECT DISTINCT
    c.user_id,
    c.cohort_week,
    (e.created_at::date - c.cohort_week) AS days_since_reg
  FROM cohorts c
  JOIN events e ON e.user_id = c.user_id
),
cohort_size AS (
  SELECT cohort_week, COUNT(DISTINCT user_id) AS users_total
  FROM cohorts
  GROUP BY cohort_week
),
retention AS (
  SELECT
    ua.cohort_week,
    cs.users_total,
    COUNT(DISTINCT CASE WHEN days_since_reg BETWEEN 0 AND 0 THEN ua.user_id END) AS day_0,
    COUNT(DISTINCT CASE WHEN days_since_reg BETWEEN 7 AND 13 THEN ua.user_id END) AS day_7,
    COUNT(DISTINCT CASE WHEN days_since_reg BETWEEN 14 AND 20 THEN ua.user_id END) AS day_14,
    COUNT(DISTINCT CASE WHEN days_since_reg BETWEEN 30 AND 36 THEN ua.user_id END) AS day_30
  FROM user_activity ua
  JOIN cohort_size cs USING (cohort_week)
  GROUP BY ua.cohort_week, cs.users_total
)
SELECT
  cohort_week,
  users_total,
  ROUND(100.0 * day_0 / users_total, 1) AS ret_day_0,
  ROUND(100.0 * day_7 / users_total, 1) AS ret_day_7,
  ROUND(100.0 * day_14 / users_total, 1) AS ret_day_14,
  ROUND(100.0 * day_30 / users_total, 1) AS ret_day_30
FROM retention
ORDER BY cohort_week;

Запрос выведет таблицу вида:

Почему запрос медленный

1. Нет подходящего индекса. Запрос фильтрует по event_type и created_at, но индекс по этим полям отсутствует. PostgreSQL делает Seq Scan по 80 млн строк.
2. DATE(created_at) — функция в GROUP BY не позволяет использовать индекс для группировки.

Решение

Шаг 1. Создать составной индекс:

CREATE INDEX idx_events_type_created
ON events (event_type, created_at)
INCLUDE (user_id);

INDEX покроет все поля запроса (covering index), PostgreSQL обойдётся Index Only Scan.

Шаг 2. Переписать запрос с created_at::date:

SELECT
  created_at::date AS day,
  COUNT(*) AS events_count,
  COUNT(DISTINCT user_id) AS unique_users
FROM events
WHERE event_type = 'purchase'
  AND created_at >= '2026-01-01'
  AND created_at < '2026-02-01'
GROUP BY created_at::date
ORDER BY day;

Ожидаемый результат: с covering index запрос должен выполняться за 1-3 секунды вместо 45.

E-commerce Executive Dashboard

Блок 1: Ключевые показатели (верхняя полоса)

Тип: 4 карточки с числом + тренд за неделю

SELECT
  SUM(amount) AS revenue_today,
  COUNT(*) AS orders_today,
  ROUND(AVG(amount), 0) AS avg_check
FROM orders
WHERE created_at::date = CURRENT_DATE;

Блок 2: Динамика выручки (центр)

Тип: линейный график, 30 дней, с отметкой плана

• Ось X: дата
• Ось Y: выручка
• Линия плана пунктиром
• Алерт: 3 дня подряд ниже плана

Блок 3: Топ-категории (левый столбец)

Тип: горизонтальная гистограмма

• Топ-10 категорий по выручке
• Цвет: зелёный если рост WoW, красный если падение

Блок 4: Воронка (правый столбец)

Тип: воронка или горизонтальный бар

• Визиты → Просмотр товара → Корзина → Заказ → Оплата
• Показывать конверсию на каждом шаге

Блок 5: Проблемы (нижняя часть)

Тип: таблица

• Товары с высоким отказом в корзине (добавили, но не купили)
• Категории с падением выручки > 20% WoW

Принципы расположения:

• Глаз движется Z-образно: ключевые числа наверху, динамика в центре, детали внизу
• Не больше 7 блоков — руководитель тратит 2 минуты
• Каждый блок отвечает на один вопрос

=SUMPRODUCT(
  (C2:C5000="Электроника")*
  (D2:D5000="Москва")*
  (A2:A5000>=TODAY()-30)*
  (A2:A5000<=TODAY())*
  B2:B5000
) / MAX(1, SUMPRODUCT(
  (C2:C5000="Электроника")*
  (D2:D5000="Москва")*
  (A2:A5000>=TODAY()-30)*
  (A2:A5000<=TODAY())*
  (1/COUNTIFS(
    A2:A5000, A2:A5000,
    C2:C5000, "Электроника",
    D2:D5000, "Москва"
  ))
))

Упрощённый вариант (если достаточно разделить на 30 дней):

=SUMPRODUCTS(
  (C2:C5000="Электроника")*
  (D2:D5000="Москва")*
  (A2:A5000>=TODAY()-30)*
  B2:B5000
) / 30

Как работает:

1. SUMPRODUCT перемножает массивы условий — каждая строка получает 1 (проходит) или 0 (не проходит)
2. Результат умножается на сумму заказа из столбца B
3. Делим на 30 дней (упрощённый) или на количество уникальных дней (точный вариант)

Совет: для больших таблиц (> 10 000 строк) лучше использовать FILTER + UNIQUE:

=LET(
  filtered, FILTER(B2:B5000,
    (C2:C5000="Электроника")*
    (D2:D5000="Москва")*
    (A2:A5000>=TODAY()-30)),
  SUM(filtered) / 30
)

Статистический анализ

1. Конверсия: +0.5 п.п. (9.0% → 9.5%)

Z-тест для двух пропорций:

• p_A = 0.090, p_B = 0.095
• pooled_p = (1116 + 1197) / (12400 + 12600) = 0.0925
• SE = sqrt(pooled_p * (1-pooled_p) * (1/12400 + 1/12600)) = 0.00367
• Z = (0.095 - 0.090) / 0.00367 = 1.36
• p-value = 0.087 → не значимо при alpha = 0.05

Рост конверсии пока статистически не значим. Мощность теста при текущем размере выборки для обнаружения эффекта +0.5 п.п. составляет около 55% — недостаточно.

2. Средний чек: -130 ₽ (3150 ₽ → 3020 ₽)

Без стандартных отклонений точный t-тест невозможен, но падение на 4.1% заслуживает внимания. Рекомендую проверить, не связано ли это с изменением ассортимента покупок в группе B.

3. Рекомендация

Не раскатывать. Выручка на пользователя почти одинакова (283.5 ₽ vs 286.9 ₽, разница +1.2%), при этом ни одна из метрик не достигла статистической значимости.

4. Продлить тест

Да. Для обнаружения эффекта +0.5 п.п. при alpha=0.05 и power=0.80 нужно ~32 000 пользователей на группу. При текущем темпе (12 500 за 14 дней) нужно ещё ~22 дня. Общая длительность теста: 5 недель.

Еженедельный отчёт: 17-23 февраля 2026

Headline

Выручка -11% от плана из-за падения заказов; рост новых пользователей +34% WoW и улучшение NPS — позитивные сигналы.

Ключевые метрики

Что произошло

1. Баг корзины на iOS (среда, 2 часа простоя). Оценка потерь: ~280 заказов, ~800 тыс. ₽. Это объясняет примерно половину отставания от плана.
2. Рост новых пользователей на 34% — эффект запущенной рекламной кампании. Конверсия в первую покупку у новых: 6.2% (ниже среднего 9%).
3. NPS улучшился — связано с ускорением доставки (2.8 дня vs SLA 3 дня).

Риски и действия

1. Риск: низкая конверсия новых пользователей. Действие: команда продукта анализирует онбординг, результат в четверг.
2. Риск: отставание от плана выручки. Действие: запланировать промо-акцию на следующую неделю для компенсации.

Фокус следующей недели

• Увеличить конверсию новых пользователей (таргет: 8%)
• Мониторинг стабильности iOS-корзины
• Запуск промо для возврата к плану

Этот системный промпт задаёт роль, формат и ограничения для аналитического агента. Используется как system message в API-вызове.

Ключевые элементы:

• Фиксированный JSON-формат для парсинга downstream-системами
• Явный запрет на галлюцинации данных
• Мультизадачность: метрики + SQL + рекомендации в одном ответе
• Статусная модель (good/warning/critical) для алертов