Как сделать ИИ-агента для продуктовой аналитики и метрик

Что получится в результате

Соберем ИИ-агента для продуктовой аналитики, который каждый день читает события, метрики, воронки, когорты, фичи, эксперименты и обратную связь, проверяет качество данных, находит аномалии, формулирует гипотезы и создает задачи продуктовой команде.

Первая рабочая версия будет делать так:

1. настройки хранятся в `settings`;
2. продукты и платформы хранятся в `products`;
3. события и свойства хранятся в `event_taxonomy`;
4. ключевые метрики хранятся в `metric_catalog`;
5. источники данных хранятся в `data_sources`;
6. выгрузки событий пишутся в `raw_events`;
7. ежедневные агрегаты пишутся в `daily_metrics`;
8. воронки пишутся в `funnel_steps`;
9. результаты воронок пишутся в `funnel_results`;
10. когорты пишутся в `cohort_definitions`;
11. retention пишется в `retention_report`;
12. фичи и релизы хранятся в `feature_registry`;
13. эксперименты хранятся в `experiment_log`;
14. проверки качества данных пишутся в `data_quality_checks`;
15. аномалии пишутся в `anomaly_log`;
16. продуктовые выводы пишутся в `insight_queue`;
17. рекомендации и задачи пишутся в `task_queue`;
18. спорные выводы уходят в `approval_queue`;
19. одобренные действия попадают в `execution_queue`;
20. еженедельная сводка пишется в `weekly_product_report`;
21. все решения пишутся в `audit_log`;
22. ошибки API и данных пишутся в `error_log`.

В первой версии агент не меняет трекинг, не запускает эксперименты, не меняет feature flags, не пишет в production-аналитику и не принимает продуктовые решения без approval. Он читает агрегированные данные, проверяет качество, объясняет изменения и создает задачи.

Что понадобится

• n8n Cloud или self-hosted n8n.
• Google Sheets для MVP-таблиц.
• Источник продуктовой аналитики: GA4, PostHog, Amplitude, Mixpanel, Яндекс Метрика, BigQuery, ClickHouse или CSV.
• Read-only API-ключ к аналитике.
• Список событий и свойств.
• Каталог утвержденных метрик.
• Список ключевых фич и релизов.
• Список экспериментов и дат запусков.
• Канал approval: Telegram, Slack, Teams, email или задача.
• Канал отчетов: Slack, Teams, email, Telegram или Google Docs.
• API-ключ LLM-провайдера.
• Ответственный продуктовый менеджер или аналитик, который подтверждает формулы и выводы.

Шаг 1. Выберите один аналитический сценарий

Не начинайте с агента “ответь на любой вопрос по данным”.

Для MVP выберите один сценарий:

1. ежедневная проверка ключевых метрик;
2. поиск аномалий в activation и conversion;
3. анализ воронки onboarding;
4. weekly retention report;
5. проверка качества событий;
6. отчет по релизу новой фичи;
7. перевод продуктовых сигналов в задачи.

Самый безопасный старт: `агент проверяет 5 утвержденных метрик, ищет аномалии и готовит weekly product report`.

Проверка: сценарий можно вручную проверить на одном продукте и одной неделе данных.

Шаг 2. Запретите опасные действия

В первой версии запретите агенту:

• менять схему событий;
• менять формулы метрик;
• запускать A/B-тест;
• останавливать эксперимент;
• менять feature flag;
• писать в production-базу;
• удалять события;
• отправлять внешние отчеты без проверки;
• принимать решение “катить релиз”;
• менять pricing или onboarding;
• делать SQL к неразрешенным таблицам;
• показывать персональные данные в отчетах.

Разрешите агенту:

• читать агрегированные данные;
• читать approved metrics;
• считать проверяемые формулы в коде;
• находить аномалии;
• готовить гипотезы;
• создавать задачи;
• отправлять approval;
• вести audit log.

Проверка: API-токен имеет read-only доступ, а LLM не получает персональные поля пользователей.

Шаг 3. Создайте Google Sheet проекта

Создайте таблицу:

Product analytics agent

Добавьте листы:

settings
products
event_taxonomy
metric_catalog
data_sources
raw_events
daily_metrics
funnel_steps
funnel_results
cohort_definitions
retention_report
feature_registry
experiment_log
data_quality_checks
anomaly_log
insight_queue
approval_queue
execution_queue
task_queue
weekly_product_report
audit_log
error_log

Проверка: n8n может читать и писать во все листы.

Шаг 4. Заполните settings

В `settings` добавьте колонки:

key
value
description
updated_at

Заполните минимум:

approval_required | true | действия только через approval
auto_execute | false | автоприменение выключено
pii_allowed_in_llm | false | персональные данные не отправлять в модель
min_sample_size | 100 | минимум выборки для вывода
anomaly_threshold_pct | 20 | порог аномалии к прошлому периоду
retention_window_days | 7 | окно retention для MVP
weekly_report_day | friday | день отчета
metric_timezone | Europe/Moscow | часовой пояс метрик

Проверка: PII выключены, min sample size задан.

Шаг 5. Заполните products

В `products` добавьте колонки:

product_id
name
platform
owner
primary_goal
main_conversion_event
status
updated_at

Пример:

PROD-001 | ezGPT site | web | product@example.ru | регистрация читателя | signup_completed | active | 2026-05-23

Проверка: у продукта есть главный conversion event.

Шаг 6. Заполните event_taxonomy

В `event_taxonomy` добавьте колонки:

event_name
product_id
description
required_properties
optional_properties
owner
status
first_seen_at
last_seen_at
updated_at

Пример:

signup_completed | PROD-001 | Пользователь завершил регистрацию | user_id, source, plan | campaign, referrer | analytics | active | 2026-05-01 | 2026-05-23 | 2026-05-23

Статусы:

active
deprecated
draft
broken
unknown

Проверка: агент не использует событие со статусом `broken`.

Шаг 7. Заполните metric_catalog

В `metric_catalog` добавьте колонки:

metric_id
product_id
metric_name
formula
source
grain
owner
good_direction
min_sample_size
status
updated_at

`grain`:

daily
weekly
monthly
cohort
funnel

Пример:

M-ACTIVATION | PROD-001 | activation_rate | activated_users / signup_users | daily_metrics | daily | product | up | 100 | active | 2026-05-23

Проверка: каждая метрика имеет формулу и owner.

Шаг 8. Заполните data_sources

В `data_sources` добавьте колонки:

source_id
product_id
source_type
tool
connection_name
allowed_tables
allowed_metrics
pii_fields
access_mode
status
updated_at

`tool`:

ga4
posthog
amplitude
mixpanel
bigquery
clickhouse
csv

Проверка: `access_mode = read_only`, а `pii_fields` не передаются в LLM.

Шаг 9. Подключите источник данных в n8n

Создайте workflow:

Product Analytics Agent - weekly metrics

Добавьте узлы:

1. `Schedule Trigger`;
2. `Read products`;
3. `Read event_taxonomy`;
4. `Read metric_catalog`;
5. `Read data_sources`;
6. `Fetch analytics data`;
7. `Write raw_events`;
8. `Calculate daily_metrics`;
9. `Calculate funnels`;
10. `Calculate retention`;
11. `Run data quality checks`;
12. `Detect anomalies`;
13. `LLM product analysis`;
14. `Write insights and tasks`;
15. `Send approval`;
16. `Write audit_log`;
17. `Write error_log`.

Проверка: workflow вручную получает данные за один день и пишет агрегат.

Шаг 10. Подключите GA4, PostHog или Amplitude read-only

Для GA4 Data API:

runReport
dimensions = date,eventName
metrics = eventCount,totalUsers

Для PostHog API:

GET /api/projects/{project_id}/events/
POST /api/projects/{project_id}/query/

Для Amplitude Dashboard REST API:

GET /api/2/events/segmentation
GET /api/2/funnels
GET /api/2/retention

Проверка: данные приходят без email, телефона, имени и других PII.

Шаг 11. Запишите raw_events

В `raw_events` добавьте колонки:

event_id
source_id
product_id
event_name
event_date
user_hash
session_id
properties_json
ingested_at

Правила:

1. `user_hash` вместо реального user_id;
2. email и phone удаляются;
3. свойства с PII удаляются;
4. события со статусом `unknown` идут в `data_quality_checks`.

Проверка: в `raw_events` нет персональных данных.

Шаг 12. Рассчитайте daily_metrics

Метрики считайте кодом или формулами, а не LLM.

В `daily_metrics` добавьте колонки:

metric_date
product_id
metric_id
metric_name
value
numerator
denominator
segment
source_id
calculated_at

Примеры:

2026-05-23 | PROD-001 | M-ACTIVATION | activation_rate | 0.42 | 420 | 1000 | all | posthog | 2026-05-23
2026-05-23 | PROD-001 | M-SIGNUPS | signup_users | 1000 | 1000 | 1 | all | posthog | 2026-05-23

Проверка: у ratio-метрик есть numerator и denominator.

Шаг 13. Настройте funnel_steps

В `funnel_steps` добавьте колонки:

funnel_id
product_id
funnel_name
step_no
event_name
step_name
required_properties
status
updated_at

Пример onboarding funnel:

FUN-ONB | PROD-001 | Onboarding | 1 | signup_started | Начал регистрацию | - | active | 2026-05-23
FUN-ONB | PROD-001 | Onboarding | 2 | signup_completed | Завершил регистрацию | - | active | 2026-05-23
FUN-ONB | PROD-001 | Onboarding | 3 | first_project_created | Создал первый проект | - | active | 2026-05-23

Проверка: все события воронки есть в `event_taxonomy`.

Шаг 14. Рассчитайте funnel_results

В `funnel_results` добавьте колонки:

result_id
funnel_id
product_id
period_start
period_end
segment
step_no
step_name
users_count
conversion_from_previous
conversion_from_start
calculated_at

Проверка: шаг 2 не может иметь пользователей больше шага 1 без объяснения или ошибки данных.

Шаг 15. Настройте cohort_definitions

В `cohort_definitions` добавьте колонки:

cohort_id
product_id
cohort_name
entry_event
entry_period
return_event
segment
status
updated_at

Пример:

COH-WEEKLY-SIGNUP | PROD-001 | Weekly signup cohort | signup_completed | week | app_opened | all | active | 2026-05-23

Проверка: entry_event и return_event существуют в `event_taxonomy`.

Шаг 16. Рассчитайте retention_report

В `retention_report` добавьте колонки:

cohort_id
product_id
cohort_period
users_in_cohort
day_1_retention
day_7_retention
day_30_retention
segment
calculated_at

Проверка: retention не считается, если `users_in_cohort < min_sample_size`.

Шаг 17. Заполните feature_registry

В `feature_registry` добавьте колонки:

feature_id
product_id
feature_name
release_date
owner
success_metric_id
guardrail_metric_id
status
updated_at

Пример:

FEAT-SEARCH | PROD-001 | Поиск по базе знаний | 2026-05-20 | product | M-SEARCH-USE | M-ERROR-RATE | released | 2026-05-23

Проверка: у новой фичи есть success metric и guardrail metric.

Шаг 18. Заполните experiment_log

В `experiment_log` добавьте колонки:

experiment_id
product_id
feature_id
hypothesis
primary_metric_id
guardrail_metric_ids
start_date
end_date
status
owner
updated_at

Статусы:

planned
running
paused
completed
cancelled

Проверка: агент не делает выводы по эксперименту без primary metric.

Шаг 19. Создайте data_quality_checks

В `data_quality_checks` добавьте колонки:

check_id
run_id
product_id
check_type
entity_name
status
problem
sample_json
owner
created_at

`check_type`:

missing_event
unknown_event
missing_property
pii_detected
low_sample_size
tracking_drop
duplicate_event
timezone_mismatch

Проверка: событие без обязательного свойства попадает в `missing_property`.

Шаг 20. Создайте anomaly_log

В `anomaly_log` добавьте колонки:

anomaly_id
run_id
product_id
metric_id
metric_name
period
current_value
previous_value
change_pct
segment
sample_size
risk_level
status
created_at

`risk_level`:

low
medium
high
critical

Условие:

abs(change_pct) >= anomaly_threshold_pct
и sample_size >= min_sample_size

Проверка: маленькая выборка не создает high confidence anomaly.

Шаг 21. Настройте prompt для LLM product analysis

В n8n добавьте узел `LLM product analysis`.

System prompt:

Ты продуктовый аналитик. Работай только с переданными метриками, проверками и аномалиями.
Не придумывай события, формулы, причины и цифры.
Разделяй observation, hypothesis и recommended_action.
Если выборка маленькая или данные сломаны, верни needs_data.
Любое изменение трекинга, фичи, эксперимента или внешнего отчета отправляй на approval.
Ответ возвращай только JSON.

User prompt:

Проанализируй продуктовые данные.

metrics:
{{$json.daily_metrics}}

funnels:
{{$json.funnel_results}}

retention:
{{$json.retention_report}}

features:
{{$json.feature_registry}}

experiments:
{{$json.experiment_log}}

quality_checks:
{{$json.data_quality_checks}}

anomalies:
{{$json.anomaly_log}}

Верни JSON:
{
  "product_id": "...",
  "status": "ok | at_risk | needs_data | tracking_broken",
  "risk_level": "low | medium | high | critical",
  "observations": ["..."],
  "hypotheses": ["..."],
  "evidence": ["..."],
  "recommended_actions": [
    {
      "action_type": "create_task | check_tracking | investigate_funnel | review_feature | prepare_report",
      "owner": "product | analytics | engineering | marketing | support",
      "text": "...",
      "requires_approval": true
    }
  ]
}

Проверка: ответ валидный JSON и не смешивает гипотезу с фактом.

Шаг 22. Создайте insight_queue

В `insight_queue` добавьте колонки:

insight_id
run_id
product_id
topic
observation
hypothesis
evidence_json
risk_level
confidence
recommended_action
owner_team
approval_required
status
created_at

`confidence`:

high
medium
low
needs_data

Проверка: insight с `needs_data` не попадает в финальный отчет как вывод.

Шаг 23. Настройте approval_queue

В `approval_queue` добавьте колонки:

approval_id
source
source_id
run_id
product_id
action_type
action_text
payload_json
risk_level
requested_by
approver
status
requested_at
approved_at
decision_comment

Статусы:

pending
approved
rejected
needs_changes
expired

В approval отправляйте:

1. изменение схемы событий;
2. изменение формулы метрики;
3. запуск эксперимента;
4. остановку эксперимента;
5. изменение feature flag;
6. внешний отчет;
7. продуктовую рекомендацию high impact;
8. вывод с low confidence.

Проверка: без `approved` нет записи в `execution_queue`.

Шаг 24. Сделайте Telegram approval

В n8n добавьте узел `Telegram`.

Сообщение:

PROD-001: activation_rate упал на 24%

Факт: 0.42 -> 0.32, sample 1800.
Гипотеза: просадка на шаге first_project_created после релиза FEAT-SEARCH.
Действие: проверить onboarding funnel и tracking события.

Approve: /approve PA-770
Edit: /edit PA-770
Reject: /reject PA-770

После `/approve PA-770` workflow должен:

1. найти `approval_id`;
2. проверить статус `pending`;
3. записать `approved`;
4. заполнить `approved_at`;
5. передать действие в `execution_queue`;
6. записать событие в `audit_log`.

Проверка: `/reject` не создает задачу и не меняет tracking.

Шаг 25. Настройте execution_queue

В `execution_queue` добавьте колонки:

execution_id
approval_id
product_id
action_type
target_system
payload_json
status
executed_at
result_json
error_message

Статусы:

queued
manual_only
executed
failed
skipped

Для MVP используйте `manual_only`: агент готовит действие, а продуктовый менеджер или аналитик делает его сам.

Проверка: tracking и эксперименты не меняются автоматически.

Шаг 26. Создайте task_queue

В `task_queue` добавьте колонки:

task_id
source
source_id
run_id
product_id
task_type
title
description
owner_team
assignee
priority
status
created_at
due_at
closed_at

`task_type`:

tracking_fix
funnel_investigation
retention_review
feature_review
experiment_review
support_signal_check
marketing_segment_check
data_quality_fix

Пример:

TASK-7701 | anomaly_log | ANOM-1001 | RUN-20260523 | PROD-001 | funnel_investigation | Проверить просадку activation_rate | activation_rate упал на 24%, просадка на first_project_created | product | pm@example.ru | high | open | 2026-05-23 | 2026-05-27 | -

Проверка: каждая важная аномалия превращается в задачу с владельцем.

Шаг 27. Соберите weekly_product_report

В `weekly_product_report` добавьте колонки:

report_week
product_id
health_status
active_users
activation_rate
main_conversion
day_7_retention
top_anomalies_json
top_insights_json
tasks_created
summary
created_at

Пример summary:

Продукт at risk: activation_rate снизился на 24%, D7 retention стабилен, новая фича FEAT-SEARCH имеет низкое использование. Главная задача недели - проверить onboarding funnel и tracking first_project_created.

Проверка: отчет показывает факты, гипотезы и задачи отдельно.

Шаг 28. Настройте audit_log

В `audit_log` добавьте колонки:

event_id
run_id
event_type
product_id
metric_id
actor
input_hash
output_hash
summary
created_at

Пишите события:

run_started
data_loaded
metrics_calculated
funnel_calculated
retention_calculated
quality_checked
anomaly_detected
insight_created
approval_requested
task_created
report_created
run_finished

Проверка: по `run_id` можно объяснить любую цифру в отчете.

Шаг 29. Настройте error_log

В `error_log` добавьте колонки:

error_id
run_id
step
source_system
product_id
metric_id
error_type
error_message
payload_sample
status
created_at
resolved_at

`error_type`:

api_error
missing_metric_definition
unknown_event
missing_property
pii_detected
low_sample_size
invalid_json
calculation_error

Проверка: если метрики нет в `metric_catalog`, агент пишет `missing_metric_definition`.

Шаг 30. Протестируйте на одной метрике

Создайте тестовые данные:

products:
PROD-TEST-001 | Demo app | web | product@example.ru | activation | signup_completed | active | 2026-05-23

metric_catalog:
M-ACTIVATION | PROD-TEST-001 | activation_rate | activated_users / signup_users | daily_metrics | daily | product | up | 100 | active | 2026-05-23

daily_metrics:
2026-05-16 | PROD-TEST-001 | M-ACTIVATION | activation_rate | 0.42 | 420 | 1000 | all | posthog | 2026-05-16
2026-05-23 | PROD-TEST-001 | M-ACTIVATION | activation_rate | 0.32 | 576 | 1800 | all | posthog | 2026-05-23

Ожидаемый результат:

1. `anomaly_log` получает падение `-24%`;
2. `insight_queue` содержит observation и hypothesis отдельно;
3. `task_queue` создает задачу product или analytics;
4. `weekly_product_report` содержит summary;
5. `audit_log` содержит шаги запуска;
6. `error_log` пустой.

Проверка: агент не пишет “причина точно в релизе”, если это только гипотеза.

Шаг 31. Проверьте негативные сценарии

Сделайте 5 тестов:

1. удалите метрику из `metric_catalog`;
2. добавьте событие `unknown_event`;
3. удалите обязательное свойство события;
4. поставьте sample size меньше 100;
5. верните от LLM невалидный JSON.

Ожидаемый результат:

1. нет метрики - `missing_metric_definition`;
2. неизвестное событие - `unknown_event`;
3. нет свойства - `missing_property`;
4. маленькая выборка - `low_sample_size`;
5. невалидный JSON - `invalid_json`;
6. отчет не делает confident вывод;
7. execution не запускается без approval.

Проверка: агент не превращает плохие данные в уверенные продуктовые решения.

Минимальная проверка результата

Прототип работает, если выполняются условия:

1. `products` содержит один активный продукт;
2. `event_taxonomy` содержит утвержденные события;
3. `metric_catalog` содержит формулы;
4. `data_sources` имеет read-only доступ;
5. `daily_metrics` содержит numerator и denominator;
6. `funnel_results` считает шаги воронки;
7. `retention_report` считает retention только на нормальной выборке;
8. `data_quality_checks` ловит ошибки событий;
9. `anomaly_log` ловит отклонения;
10. `insight_queue` разделяет факт и гипотезу;
11. `approval_queue` блокирует рискованные действия;
12. без `approved` нет записи в `execution_queue`;
13. `task_queue` назначает владельца;
14. `weekly_product_report` показывает факты и задачи;
15. `audit_log` объясняет цифры;
16. `error_log` показывает плохие данные.

Что нельзя автоматизировать в первой версии

• изменение схемы событий;
• изменение формул метрик;
• запуск и остановку экспериментов;
• изменение feature flags;
• изменение onboarding или pricing;
• отправку внешних отчетов;
• SQL к неразрешенным таблицам;
• передачу персональных данных в LLM;
• удаление событий;
• продуктовые решения high impact без approval;
• уверенные выводы на маленькой выборке;
• любые write-действия в аналитике без approval.

Частые вопросы

Можно ли подключить агента прямо к базе продукта?

Можно, но для MVP лучше начать с агрегированных данных и read-only доступа. Прямой SQL требует whitelist таблиц, маскирования PII и валидатора запросов.

Почему LLM не должен считать метрики?

Метрики должны считаться кодом, SQL или BI-системой. LLM может объяснять и формулировать гипотезы, но формулы, numerator и denominator должны быть проверяемыми.

Что важнее: GA4, PostHog или Amplitude?

Используйте то, где уже есть качественные события. GA4 удобен для сайта и трафика, PostHog - для продуктовой аналитики и feature flags, Amplitude - для funnels, retention и cohorts.

Как избежать неверных выводов?

Сначала проверяйте качество данных: события, свойства, период, сегмент, sample size, timezone и изменения трекинга. Только потом формулируйте гипотезы.

Какой минимальный результат считать успешным?

Успешный MVP: агент берет одну метрику, проверяет формулу, считает изменение, находит аномалию, отделяет факт от гипотезы, создает задачу и пишет weekly product report.