# SQL для продакт-менеджеров: 7 когортных запросов, которые AI пишет лучше аналитика

> 7 SQL-запросов для когортного анализа: retention, revenue cohorts, activation, churn prediction. Готовые промпты для генерации через AI. Копируй и запускай.
> Author: Roman Belov · Published: 2026-04-14 · Source: https://futurecraft.pro/ru/blog/sql-product-managers/

Большинство аналитических запросов в product-командах повторяются с минимальными вариациями: когортный анализ, retention, revenue breakdown. Одни и те же паттерны, разные фильтры.

AI-модели генерируют SQL быстрее человека не потому что умнее, а потому что когортные запросы имеют жёсткую структуру, которая хорошо ложится на pattern matching. Аналитик тратит 30 минут на уточнение требований и написание запроса. Claude или GPT-5.4 выдают рабочий SQL за 15 секунд при правильном промпте.

Ниже 7 SQL-запросов для когортного анализа, промпт к каждому и пример вывода. Все запросы написаны для PostgreSQL, но адаптируются под BigQuery, Snowflake и ClickHouse заменой 2-3 функций.

## Схема данных для примеров

Все запросы работают с тремя таблицами. Если в продукте другая схема, AI адаптирует запрос за один промпт.

```sql
-- Пользователи
CREATE TABLE users (
  user_id       BIGINT PRIMARY KEY,
  created_at    TIMESTAMP NOT NULL,
  plan          VARCHAR(20),     -- free, pro, enterprise
  source        VARCHAR(50)      -- organic, paid, referral
);

-- События
CREATE TABLE events (
  event_id      BIGINT PRIMARY KEY,
  user_id       BIGINT REFERENCES users(user_id),
  event_name    VARCHAR(100),
  event_time    TIMESTAMP NOT NULL,
  properties    JSONB
);

-- Платежи
CREATE TABLE payments (
  payment_id    BIGINT PRIMARY KEY,
  user_id       BIGINT REFERENCES users(user_id),
  amount        DECIMAL(10,2),
  currency      VARCHAR(3),
  paid_at       TIMESTAMP NOT NULL
);
```

## 1. Классический retention по когортам регистрации

Retention показывает, сколько пользователей возвращаются через N дней/недель/месяцев после регистрации. Базовый запрос для любого продукта.

**Промпт для AI:**

> Напиши SQL-запрос для PostgreSQL. Таблицы: users (user_id, created_at), events (user_id, event_time). Рассчитай месячный retention по когортам регистрации за последние 6 месяцев. Когорта = месяц created_at. Retention = процент пользователей когорты, совершивших хотя бы одно событие в month N после регистрации. Выведи pivot-таблицу: строки = когорты, столбцы = month_0 ... month_5.

**SQL:**

```sql
WITH cohorts AS (
  SELECT
    user_id,
    DATE_TRUNC('month', created_at) AS cohort_month
  FROM users
  WHERE created_at >= CURRENT_DATE - INTERVAL '6 months'
),
activity AS (
  SELECT DISTINCT
    e.user_id,
    c.cohort_month,
    DATE_TRUNC('month', e.event_time) AS activity_month
  FROM events e
  JOIN cohorts c ON e.user_id = c.user_id
),
retention_raw AS (
  SELECT
    cohort_month,
    EXTRACT(YEAR FROM AGE(activity_month, cohort_month)) * 12
      + EXTRACT(MONTH FROM AGE(activity_month, cohort_month)) AS month_number,
    COUNT(DISTINCT user_id) AS active_users
  FROM activity
  GROUP BY cohort_month, month_number
),
cohort_sizes AS (
  SELECT cohort_month, COUNT(DISTINCT user_id) AS cohort_size
  FROM cohorts
  GROUP BY cohort_month
)
SELECT
  TO_CHAR(r.cohort_month, 'YYYY-MM') AS cohort,
  s.cohort_size,
  ROUND(100.0 * MAX(CASE WHEN month_number = 0 THEN active_users END) / s.cohort_size, 1) AS month_0,
  ROUND(100.0 * MAX(CASE WHEN month_number = 1 THEN active_users END) / s.cohort_size, 1) AS month_1,
  ROUND(100.0 * MAX(CASE WHEN month_number = 2 THEN active_users END) / s.cohort_size, 1) AS month_2,
  ROUND(100.0 * MAX(CASE WHEN month_number = 3 THEN active_users END) / s.cohort_size, 1) AS month_3,
  ROUND(100.0 * MAX(CASE WHEN month_number = 4 THEN active_users END) / s.cohort_size, 1) AS month_4,
  ROUND(100.0 * MAX(CASE WHEN month_number = 5 THEN active_users END) / s.cohort_size, 1) AS month_5
FROM retention_raw r
JOIN cohort_sizes s ON r.cohort_month = s.cohort_month
GROUP BY r.cohort_month, s.cohort_size
ORDER BY r.cohort_month;
```

**Пример вывода:**

| cohort  | cohort_size | month_0 | month_1 | month_2 | month_3 | month_4 | month_5 |
|---------|-------------|---------|---------|---------|---------|---------|---------|
| 2025-10 | 1240        | 100.0   | 42.3    | 31.1    | 24.8    | 21.2    | 18.9    |
| 2025-11 | 1385        | 100.0   | 45.1    | 33.7    | 26.4    | 22.8    |         |
| 2025-12 | 1102        | 100.0   | 38.9    | 28.5    | 23.1    |         |         |
| 2026-01 | 1467        | 100.0   | 47.2    | 35.9    |         |         |         |
| 2026-02 | 1290        | 100.0   | 44.6    |         |         |         |         |
| 2026-03 | 1158        | 100.0   |         |         |         |         |         |

**На что смотреть.** Стабилизация retention на month_3-month_4 указывает на формирование привычки. Если retention падает линейно без плато, продукт не создаёт привычку. Разница между когортами (45.1% vs 38.9% на month_1) сигнализирует об изменениях в onboarding или качестве трафика.

## 2. Revenue cohorts: LTV по когортам

Revenue cohorts показывают, сколько денег приносит каждая когорта со временем. Критический запрос для unit economics.

**Промпт для AI:**

> SQL для PostgreSQL. Таблицы: users (user_id, created_at), payments (user_id, amount, paid_at). Рассчитай кумулятивный revenue на пользователя по когортам регистрации (помесячно). Когорта = месяц created_at. Для каждого месяца после регистрации покажи cumulative revenue / cohort_size. Последние 6 месяцев.

**SQL:**

```sql
WITH cohorts AS (
  SELECT
    user_id,
    DATE_TRUNC('month', created_at) AS cohort_month
  FROM users
  WHERE created_at >= CURRENT_DATE - INTERVAL '6 months'
),
monthly_revenue AS (
  SELECT
    c.cohort_month,
    EXTRACT(YEAR FROM AGE(DATE_TRUNC('month', p.paid_at), c.cohort_month)) * 12
      + EXTRACT(MONTH FROM AGE(DATE_TRUNC('month', p.paid_at), c.cohort_month)) AS month_number,
    SUM(p.amount) AS revenue
  FROM payments p
  JOIN cohorts c ON p.user_id = c.user_id
  GROUP BY c.cohort_month, month_number
),
cumulative AS (
  SELECT
    cohort_month,
    month_number,
    SUM(revenue) OVER (
      PARTITION BY cohort_month ORDER BY month_number
    ) AS cum_revenue
  FROM monthly_revenue
),
cohort_sizes AS (
  SELECT cohort_month, COUNT(DISTINCT user_id) AS cohort_size
  FROM cohorts
  GROUP BY cohort_month
)
SELECT
  TO_CHAR(c.cohort_month, 'YYYY-MM') AS cohort,
  cs.cohort_size,
  ROUND(MAX(CASE WHEN month_number = 0 THEN cum_revenue END) / cs.cohort_size, 2) AS ltv_m0,
  ROUND(MAX(CASE WHEN month_number = 1 THEN cum_revenue END) / cs.cohort_size, 2) AS ltv_m1,
  ROUND(MAX(CASE WHEN month_number = 2 THEN cum_revenue END) / cs.cohort_size, 2) AS ltv_m2,
  ROUND(MAX(CASE WHEN month_number = 3 THEN cum_revenue END) / cs.cohort_size, 2) AS ltv_m3
FROM cumulative c
JOIN cohort_sizes cs ON c.cohort_month = cs.cohort_month
GROUP BY c.cohort_month, cs.cohort_size
ORDER BY c.cohort_month;
```

**Пример вывода:**

| cohort  | cohort_size | ltv_m0 | ltv_m1 | ltv_m2  | ltv_m3  |
|---------|-------------|--------|--------|---------|---------|
| 2025-10 | 1240        | 2.15   | 5.87   | 9.42    | 12.31   |
| 2025-11 | 1385        | 2.43   | 6.91   | 10.78   | 14.05   |
| 2025-12 | 1102        | 1.89   | 4.62   | 7.95    |         |
| 2026-01 | 1467        | 3.01   | 7.84   |         |         |

**На что смотреть.** Кумулятивный LTV должен расти от когорты к когорте. Если ltv_m1 когорты 2026-01 ($7.84) выше, чем у 2025-10 ($5.87), монетизация улучшается. Сравнение ltv_m0 показывает, насколько быстро новые пользователи совершают первую покупку.

## 3. Activation rate по когортам и источникам

Activation rate измеряет долю пользователей, выполнивших ключевое действие (aha-moment). Разбивка по источникам трафика показывает, откуда приходят самые качественные пользователи.

**Промпт для AI:**

> SQL для PostgreSQL. Таблицы: users (user_id, created_at, source), events (user_id, event_name, event_time). Activation event = 'project_created'. Рассчитай activation rate по когортам (месяц регистрации) и источникам трафика. Activation = пользователь совершил event 'project_created' в первые 7 дней после регистрации. Покажи cohort, source, cohort_size, activated_count, activation_rate.

**SQL:**

```sql
WITH cohort_source AS (
  SELECT
    user_id,
    DATE_TRUNC('month', created_at) AS cohort_month,
    created_at,
    source
  FROM users
  WHERE created_at >= CURRENT_DATE - INTERVAL '6 months'
),
activated AS (
  SELECT DISTINCT cs.user_id, cs.cohort_month, cs.source
  FROM cohort_source cs
  JOIN events e ON e.user_id = cs.user_id
  WHERE e.event_name = 'project_created'
    AND e.event_time <= cs.created_at + INTERVAL '7 days'
)
SELECT
  TO_CHAR(cs.cohort_month, 'YYYY-MM') AS cohort,
  cs.source,
  COUNT(DISTINCT cs.user_id) AS cohort_size,
  COUNT(DISTINCT a.user_id) AS activated,
  ROUND(100.0 * COUNT(DISTINCT a.user_id) / COUNT(DISTINCT cs.user_id), 1) AS activation_rate
FROM cohort_source cs
LEFT JOIN activated a
  ON cs.user_id = a.user_id
  AND cs.cohort_month = a.cohort_month
GROUP BY cs.cohort_month, cs.source
HAVING COUNT(DISTINCT cs.user_id) >= 30
ORDER BY cs.cohort_month, activation_rate DESC;
```

**Пример вывода:**

| cohort  | source   | cohort_size | activated | activation_rate |
|---------|----------|-------------|-----------|-----------------|
| 2026-01 | referral | 312         | 198       | 63.5            |
| 2026-01 | organic  | 845         | 423       | 50.1            |
| 2026-01 | paid     | 310         | 112       | 36.1            |
| 2026-02 | referral | 287         | 190       | 66.2            |
| 2026-02 | organic  | 761         | 399       | 52.4            |
| 2026-02 | paid     | 242         | 94        | 38.8            |

**На что смотреть.** Referral-пользователи активируются в 1.7 раза чаще paid-пользователей. Это не повод отключать платный трафик, а повод проверить, получают ли paid-пользователи тот же onboarding, и инвестировать в реферальную программу.

## 4. Churn prediction: пользователи в зоне риска

Запрос находит пользователей, которые были активны, но перестали совершать действия. Ранний сигнал оттока до того, как пользователь уйдёт окончательно.

**Промпт для AI:**

> SQL для PostgreSQL. Таблицы: users (user_id, created_at, plan), events (user_id, event_time). Найди пользователей в зоне риска оттока: были активны (3+ событий за предыдущие 30 дней), но за последние 14 дней не совершили ни одного события. Выведи user_id, plan, days_since_last_event, events_in_prior_period, created_at. Отсортируй по events_in_prior_period DESC (самые активные в прошлом = самые ценные потери).

**SQL:**

```sql
WITH recent_activity AS (
  SELECT
    user_id,
    MAX(event_time) AS last_event,
    COUNT(*) FILTER (
      WHERE event_time >= CURRENT_DATE - INTERVAL '44 days'
        AND event_time < CURRENT_DATE - INTERVAL '14 days'
    ) AS events_prior_30d,
    COUNT(*) FILTER (
      WHERE event_time >= CURRENT_DATE - INTERVAL '14 days'
    ) AS events_last_14d
  FROM events
  WHERE event_time >= CURRENT_DATE - INTERVAL '90 days'
  GROUP BY user_id
)
SELECT
  u.user_id,
  u.plan,
  CURRENT_DATE - ra.last_event::date AS days_since_last_event,
  ra.events_prior_30d,
  TO_CHAR(u.created_at, 'YYYY-MM-DD') AS registered
FROM recent_activity ra
JOIN users u ON u.user_id = ra.user_id
WHERE ra.events_prior_30d >= 3
  AND ra.events_last_14d = 0
ORDER BY ra.events_prior_30d DESC
LIMIT 100;
```

**Пример вывода:**

| user_id | plan       | days_since_last_event | events_prior_30d | registered |
|---------|------------|-----------------------|-------------------|------------|
| 48201   | enterprise | 16                    | 89                | 2025-04-12 |
| 33107   | pro        | 18                    | 67                | 2025-08-03 |
| 51422   | pro        | 15                    | 54                | 2025-11-21 |
| 29834   | free       | 21                    | 41                | 2025-06-15 |

**На что смотреть.** Enterprise-пользователь с 89 событиями за предыдущий месяц и 16 днями молчания — тревожный сигнал. Передавайте этот список в CRM или в triggered email-кампанию. Порог в 14 дней и 3 события можно адаптировать: попросите AI подставить параметры, соответствующие вашему продукту.

## 5. Feature adoption по когортам

Запрос показывает, растёт ли adoption новых функций и какие когорты их игнорируют.

**Промпт для AI:**

> SQL для PostgreSQL. Таблицы: users (user_id, created_at), events (user_id, event_name, event_time). Рассчитай feature adoption rate по когортам регистрации. Features = список event_name: 'export_report', 'invite_member', 'api_key_created', 'dashboard_created'. Для каждой когорты (месяц) и каждой фичи покажи процент пользователей когорты, использовавших фичу хотя бы раз в первые 30 дней.

**SQL:**

```sql
WITH cohorts AS (
  SELECT
    user_id,
    created_at,
    DATE_TRUNC('month', created_at) AS cohort_month
  FROM users
  WHERE created_at >= CURRENT_DATE - INTERVAL '4 months'
),
feature_usage AS (
  SELECT DISTINCT
    c.user_id,
    c.cohort_month,
    e.event_name
  FROM cohorts c
  JOIN events e ON e.user_id = c.user_id
  WHERE e.event_name IN ('export_report', 'invite_member', 'api_key_created', 'dashboard_created')
    AND e.event_time <= c.created_at + INTERVAL '30 days'
),
cohort_sizes AS (
  SELECT cohort_month, COUNT(DISTINCT user_id) AS cohort_size
  FROM cohorts
  GROUP BY cohort_month
)
SELECT
  TO_CHAR(cs.cohort_month, 'YYYY-MM') AS cohort,
  cs.cohort_size,
  ROUND(100.0 * COUNT(DISTINCT CASE WHEN f.event_name = 'dashboard_created' THEN f.user_id END) / cs.cohort_size, 1) AS dashboard_created,
  ROUND(100.0 * COUNT(DISTINCT CASE WHEN f.event_name = 'invite_member' THEN f.user_id END) / cs.cohort_size, 1) AS invite_member,
  ROUND(100.0 * COUNT(DISTINCT CASE WHEN f.event_name = 'export_report' THEN f.user_id END) / cs.cohort_size, 1) AS export_report,
  ROUND(100.0 * COUNT(DISTINCT CASE WHEN f.event_name = 'api_key_created' THEN f.user_id END) / cs.cohort_size, 1) AS api_key_created
FROM cohort_sizes cs
LEFT JOIN feature_usage f ON f.cohort_month = cs.cohort_month
GROUP BY cs.cohort_month, cs.cohort_size
ORDER BY cs.cohort_month;
```

**Пример вывода:**

| cohort  | cohort_size | dashboard_created | invite_member | export_report | api_key_created |
|---------|-------------|-------------------|---------------|---------------|-----------------|
| 2025-12 | 1102        | 34.2              | 18.7          | 12.4          | 5.1             |
| 2026-01 | 1467        | 41.8              | 22.3          | 14.1          | 7.9             |
| 2026-02 | 1290        | 45.1              | 25.9          | 15.8          | 9.2             |
| 2026-03 | 1158        | 47.3              | 28.1          | 16.5          | 10.4            |

**На что смотреть.** Рост adoption от когорты к когорте (dashboard_created: 34.2% → 47.3%) означает, что улучшения onboarding работают. Низкий adoption api_key_created (5-10%) нормален для technical feature. Если invite_member стагнирует, виральный цикл продукта не ускоряется.

## 6. Conversion time: время от регистрации до оплаты

Сколько дней проходит от регистрации до первой покупки. Запрос критичен для планирования payback period и настройки trial-to-paid воронки.

**Промпт для AI:**

> SQL для PostgreSQL. Таблицы: users (user_id, created_at, source), payments (user_id, paid_at). Рассчитай время от регистрации до первого платежа. Для каждого источника трафика покажи: количество конвертировавшихся пользователей, медианное время конверсии в днях, среднее время, 90-й перцентиль. Только пользователи, зарегистрированные за последние 6 месяцев.

**SQL:**

```sql
WITH first_payment AS (
  SELECT
    user_id,
    MIN(paid_at) AS first_paid_at
  FROM payments
  GROUP BY user_id
),
conversion_data AS (
  SELECT
    u.source,
    EXTRACT(DAY FROM fp.first_paid_at - u.created_at) AS days_to_convert
  FROM users u
  JOIN first_payment fp ON fp.user_id = u.user_id
  WHERE u.created_at >= CURRENT_DATE - INTERVAL '6 months'
)
SELECT
  source,
  COUNT(*) AS converted_users,
  ROUND(PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY days_to_convert)) AS median_days,
  ROUND(AVG(days_to_convert), 1) AS avg_days,
  ROUND(PERCENTILE_CONT(0.9) WITHIN GROUP (ORDER BY days_to_convert)) AS p90_days
FROM conversion_data
GROUP BY source
ORDER BY median_days;
```

**Пример вывода:**

| source   | converted_users | median_days | avg_days | p90_days |
|----------|-----------------|-------------|----------|----------|
| referral | 312             | 3           | 5.2      | 14       |
| organic  | 587             | 7           | 11.8     | 28       |
| paid     | 198             | 12          | 18.4     | 42       |

**На что смотреть.** Referral-пользователи конвертируются за 3 дня (медиана) против 12 у paid. Реферальный трафик приходит с более сформированным intent. P90 в 42 дня для paid-трафика говорит о том, что trial длиной 14 дней может быть слишком коротким для этого сегмента.

## 7. Net revenue retention по когортам

NRR показывает, как меняется выручка от существующих когорт: upsell, downgrade, churn. NRR выше 100% означает, что рост выручки от существующих клиентов компенсирует отток.

**Промпт для AI:**

> SQL для PostgreSQL. Таблицы: users (user_id, created_at), payments (user_id, amount, paid_at). Рассчитай net revenue retention по когортам. Когорта = месяц первого платежа. Для каждого последующего месяца покажи: revenue когорты в этом месяце / revenue когорты в month_0 * 100. Последние 6 месяцев.

**SQL:**

```sql
WITH first_payment_month AS (
  SELECT
    user_id,
    DATE_TRUNC('month', MIN(paid_at)) AS cohort_month
  FROM payments
  GROUP BY user_id
),
monthly_revenue AS (
  SELECT
    fpm.cohort_month,
    DATE_TRUNC('month', p.paid_at) AS revenue_month,
    SUM(p.amount) AS revenue
  FROM payments p
  JOIN first_payment_month fpm ON p.user_id = fpm.user_id
  WHERE fpm.cohort_month >= CURRENT_DATE - INTERVAL '6 months'
  GROUP BY fpm.cohort_month, DATE_TRUNC('month', p.paid_at)
),
base_revenue AS (
  SELECT cohort_month, revenue AS base
  FROM monthly_revenue
  WHERE revenue_month = cohort_month
)
SELECT
  TO_CHAR(mr.cohort_month, 'YYYY-MM') AS cohort,
  ROUND(br.base, 0) AS base_revenue,
  ROUND(100.0 * MAX(CASE
    WHEN EXTRACT(YEAR FROM AGE(revenue_month, mr.cohort_month)) * 12
       + EXTRACT(MONTH FROM AGE(revenue_month, mr.cohort_month)) = 0
    THEN revenue END) / br.base, 1) AS nrr_m0,
  ROUND(100.0 * MAX(CASE
    WHEN EXTRACT(YEAR FROM AGE(revenue_month, mr.cohort_month)) * 12
       + EXTRACT(MONTH FROM AGE(revenue_month, mr.cohort_month)) = 1
    THEN revenue END) / br.base, 1) AS nrr_m1,
  ROUND(100.0 * MAX(CASE
    WHEN EXTRACT(YEAR FROM AGE(revenue_month, mr.cohort_month)) * 12
       + EXTRACT(MONTH FROM AGE(revenue_month, mr.cohort_month)) = 2
    THEN revenue END) / br.base, 1) AS nrr_m2,
  ROUND(100.0 * MAX(CASE
    WHEN EXTRACT(YEAR FROM AGE(revenue_month, mr.cohort_month)) * 12
       + EXTRACT(MONTH FROM AGE(revenue_month, mr.cohort_month)) = 3
    THEN revenue END) / br.base, 1) AS nrr_m3
FROM monthly_revenue mr
JOIN base_revenue br ON mr.cohort_month = br.cohort_month
GROUP BY mr.cohort_month, br.base
ORDER BY mr.cohort_month;
```

**Пример вывода:**

| cohort  | base_revenue | nrr_m0 | nrr_m1 | nrr_m2 | nrr_m3 |
|---------|--------------|--------|--------|--------|--------|
| 2025-10 | 18500        | 100.0  | 94.2   | 91.8   | 105.3  |
| 2025-11 | 22100        | 100.0  | 97.1   | 103.6  |        |
| 2025-12 | 16800        | 100.0  | 88.4   |        |        |
| 2026-01 | 27300        | 100.0  | 101.2  |        |        |

**На что смотреть.** Когорта 2025-10 показывает NRR 105.3% на month_3 — upsell компенсировал отток. Когорта 2025-12 теряет 11.6% revenue к month_1 — возможная проблема с качеством пользователей или holiday churn. NRR выше 100% на ранних месяцах (когорта 2026-01: 101.2%) указывает на успешную стратегию expansion revenue.

## Как писать промпты для SQL-генерации

**1. Указывай схему.** AI не знает структуру базы данных. Перечисли таблицы, столбцы и типы. Чем точнее схема, тем точнее запрос.

**2. Описывай бизнес-логику явно.** "Активный пользователь" может означать "залогинился" или "совершил ключевое действие". AI не угадает. Определяй термины: "activation = выполнил event 'project_created' в первые 7 дней".

**3. Указывай СУБД.** PostgreSQL, BigQuery и ClickHouse используют разный синтаксис для дат, window functions и percentile-функций. Одно слово в промпте экономит цикл исправлений.

**4. Проси pivot-формат.** Когортные данные в длинном формате (cohort, month_number, value) неудобны для анализа. Pivot-таблица (строки = когорты, столбцы = месяцы) читается значительно быстрее.

**5. Добавляй ограничения.** "Последние 6 месяцев", "минимум 30 пользователей в когорте", "только платящие". Без ограничений AI вернёт запрос, который сканирует всю таблицу или включает нерелевантные данные.

## Связь с observability

Когортный анализ показывает, что происходит с пользователями. [LLM observability](/ru/blog/llm-observability-langfuse/) показывает, что происходит с AI-системой. Если продукт использует LLM-функции, когортные метрики без трейсинга LLM-вызовов дают неполную картину. Рост churn в когорте может коррелировать с деградацией качества модели, ростом latency или увеличением cost per query. Связка cohort SQL + Langfuse трейсинг закрывает обе стороны.

## Итого

Семь запросов покрывают 80% аналитических потребностей product-менеджера: retention, LTV, activation, churn risk, feature adoption, conversion time, NRR. Каждый запрос генерируется через AI за 15-30 секунд с правильным промптом. Ключевое условие — точная схема данных и явное описание бизнес-логики.

Аналитик всё ещё нужен для интерпретации результатов, построения data pipelines и работы с edge cases. Но написание стандартных когортных запросов больше не требует ожидания в очереди тикетов.

---

*Нужна помощь с настройкой продуктовой аналитики и когортного анализа? Я помогаю стартапам внедрять AI-решения и строить продукты — [belov.works](https://belov.works).*