AI-аналитика данных для собственного сайта: запросы на естественном языке, автоматические инсайты, обнаружение аномалий и отчёты

Четырёхуровневая архитектура запросов на естественном языке: бизнес-вопрос, семантический слой, представление только для чтения, проверка человеком

AI-аналитика данных для собственного сайта: запросы на естественном языке, автоматические инсайты, обнаружение аномалий и отчёты

Сначала вывод: Когда для анализа данных собственного сайта используют большую языковую модель, главный риск не в том, что она “отвечает медленно”, а в том, что она “отвечает правдоподобно, но с неверными цифрами”. Правильная архитектура состоит из четырёх уровней: сотрудники задают вопросы на естественном языке, семантический слой предопределяет методику расчёта метрик, модель обращается только к ежедневному снимку в режиме чтения, а выводы публикуются после проверки человеком. Контринтуитивный момент: позволить большой модели напрямую писать SQL и подключаться к продакшен-базе кажется самым простым путём, но на деле это даёт зелёный свет ошибочным выводам — модель уверенно назовёт цифры, посчитанные по неверной методике. Ниже разберём NLQ, автоматические инсайты, пороги аномалий и три вида галлюцинаций по отдельности.

I. Три сферы применения запросов на естественном языке для собственного сайта

Данных на собственном сайте и так немного: посещаемость, количество заявок, отправки форм, источники трафика. Традиционно сотрудники просят данные у коллег-аналитиков и ждут две недели. Запросы на естественном языке (NLQ, Natural Language Query) позволяют бизнесу спрашивать напрямую простыми словами: “На какой неделе в прошлом месяце было больше всего заявок из Германии”.

Он подходит для трёх сценариев: повседневные вопросы к данным, автоматическая генерация еженедельных отчётов, оповещения об аномалиях. Не подходит для прогнозного моделирования и сложной атрибуции. Как читать логи AI-краулеров — см.анализе логов AI-краулеров, как настроить мониторинг цитирования — см.Панель мониторинга цитирований в AI-движках.

Вот реальный пример: в понедельник утром вы открываете диалог и спрашиваете: «Какие три страницы принесли больше всего заявок на прошлой неделе». Система по предопределённой методике (успешная отправка формы, дедупликация, окно атрибуции семь дней) запрашивает снимок и возвращает три строки.

Результат: страница сравнения продуктов — 12 заявок, страница FAQ — 8, страница кейсов — 5, плюс примечание: «FAQ выросла на 4 заявки к прошлой неделе». Весь процесс занимает 10 секунд, не нужно переключаться между пятью панелями.

Ситуация	Пример на естественном языке	Пригодность для AI
Повседневные вопросы к данным	Из какой страны больше всего заявок в прошлом месяце	Высокий
Генерация еженедельного отчёта	Напиши данные за эту неделю в три абзаца	Высокий
Оповещение об аномалиях	Почему сегодня упала конверсия	Средняя, нужна проверка человеком
Атрибуционный анализ	Откуда пришла эта заявка	Средняя, нужна фиксированная методика
Прогнозное моделирование	Объём заявок в следующем квартале	Низкая, не использовать

II. Архитектура: семантический слой, база только для чтения, проверка человеком

Ядро четырёхуровневой архитектуры — средний слой, семантический. Семантический слой — это предопределённая методика для метрики «заявка»: что считается валидной заявкой, правила дедупликации, часовой пояс, окно атрибуции. Модель может задавать вопросы только в рамках этой методики и не может изобретать собственные определения.

Слой данных использует ежедневные снимки и не подключается к продакшен-базе. Модель ночью обрабатывает данные за предыдущий день, а бизнес днём смотрит вчерашний снимок — база не нагружается и не возникает грязных данных от одновременного чтения и записи. Как считается атрибуция лидов, см.Как правильно считать атрибуцию заявок.

Уровень	Что делаем	Красная линия
Слой вопросов	Бизнес спрашивает простыми словами	Нельзя запрашивать данные вне прав доступа
Семантический слой	Предустановленные определения метрик	Модель не должна придумывать определения на ходу
Слой данных	Ежедневный снимок только для чтения	Нельзя подключаться к продакшен-базе для записи
Слой выводов	Отправка после проверки человеком	Нельзя автоматически отправлять письма или менять цены

Три. Автоматические инсайты: за какими метриками стоит следить каждый день

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

Пример: система видит, что сегодня заявок на 40% меньше, чем в тот же день прошлой недели, и автоматически формирует инсайт: «Заявок стало на 40% меньше, при этом конверсия формы упала с 8% до 3%. Похоже, проблема в форме». Этот инсайт уходит дежурному, и человек проверяет форму. Как настроить оповещения сайта, см.Мониторинг сайта и оповещения.

Показатель	Частота проверки	Порог алерта
Дневной трафик	Ежедневно	Оповещение при падении на 30% год к году
Дневное количество заявок	Ежедневно	Оповещение при падении на 40% год к году
Конверсия формы	Ежедневно	Оповещение при падении больше чем на 2 процентных пункта
Показатель отказов	Еженедельно	Оповещение при росте больше чем на 10 процентных пунктов
Число ошибок на страницах	Ежедневно	Оповещение при появлении 5xx

Четыре. Обнаружение аномалий: как задать пороги и учесть праздники

Самая частая ошибка в обнаружении аномалий — принять праздники за аномалию. В понедельник данные и так выше, чем в выходные, а на рождественской неделе трафик всего сайта и так ниже. Правильный подход — сравнивать с тем же днём прошлой недели, а не со вчерашним днём, и включить в расчёт таблицу праздников: если день попал в праздники, оповещение не отправляется.

Ещё один порог — коридор колебаний: нормальные колебания в пределах плюс-минус 20%, оповещение только при выходе за него. У B2B-сайтов база небольшая, суточные колебания сильные, и дневные данные слишком чувствительны. Лучше использовать скользящее среднее за 7 дней и уже по нему определять аномалию. Метрики производительности см.Core Web Vitals.

Как вести таблицу праздников: перечислите государственные праздники целевых рынков, например рождественскую неделю в Германии, День благодарения в США, Национальный день Китая, и обновляйте её раз в год в начале года. Скрипт оповещений каждый день сначала проверяет эту таблицу: если день или два дня вокруг него попали в праздники, уровень оповещения автоматически понижается на одну ступень — только запись без отправки.

Ситуация	Как проверить	Действие
Естественные колебания в рабочие дни	В пределах ±20%	Без алертов
Резкое падение за один день	Падение на 30% к тому же дню прошлой недели	Оповещения
Праздники	День попал в таблицу праздников	Без оповещения, с понижением приоритета
Закономерность выходных	И так ниже на 40%	Без алертов
Пробитие среднего за 7 дней	Три дня подряд ниже порога	Повышение уровня оповещения

Пять. Как избежать ошибок: три вида галлюцинаций и одна ловушка автоматизации

Три вида галлюцинаций. Первая — добавление измерения из воздуха: вы спрашиваете «в какой стране больше», а оно добавляет «разбивку по типу устройства», хотя эти данные вообще не собирались. Вторая — выдача выборки за полные данные: оно обработало только первые 100 записей и говорит «все заявки». Третья — принятие праздника за аномалию: на Рождество трафик падает, а оно отправляет оповещение о «резком падении трафика».

Ловушка автоматизации: поручить ИИ рассылку еженедельных отчётов. Формулировки выглядят нормально, но цифры внутри могут быть неверными. Правильно так: ИИ готовит черновик, человек сверяет ключевые цифры и только потом отправляет. Как устроен поток данных в CRM — см.Лиды с сайта в CRM.

Тип галлюцинации	Симптом	Как ловит человек
Выдуманное измерение	В отчёте есть поля, которых не собирали	Сверить со словарём данных
Выборка выдаётся за полную	Объём выборки не указан	Проверить, есть ли в SQL LIMIT
Праздник принят за аномалию	На рождественской неделе алерты резко падают	Проверить, попадает ли момент алерта в таблицу праздников
Автоматическая отправка отчёта	Цифры неверны, но уже разосланы	Отчёт отправляется только после проверки человеком
Дрейф методики	Изменилось определение «лида»	Закрепить методику в семантическом слое

FAQ: частые вопросы

Можно ли просто подключить большую модель к базе данных, чтобы она писала SQL и доставала данные?

Не подключайте к продакшен-базе. Большая модель может написать SQL с не той таблицей или не тем join и произнести неверные цифры как истину. Правильно так: создать ежедневную read-only базу-снимок, модель запрашивает только этот снимок, а между ними поставить семантический слой, где методики метрик заданы жёстко. Модель ищет только внутри этой рамки и не изобретает, «как считать лид».

Команда из одного человека: с какого шага выгоднее всего начать аналитику данных с ИИ?

Начните с автоматической генерации еженедельного отчёта. Зафиксируйте пять–десять метрик, которые вы сейчас смотрите вручную каждую неделю, в одной таблице, и пусть ИИ каждый понедельник превращает эту таблицу в черновик из трёх абзацев. Вы правите и отправляете. На этом шаге новые инструменты не нужны: экспорт из Excel плюс один промпт — и уже работает. Когда пойдёт гладко, добавьте алерты по аномалиям.

Как задать пороги алертов по аномалиям, чтобы не было ложных срабатываний каждый день?

Сравнивайте с тем же днём прошлой недели, а не со вчерашним днём. Коридор нормальных колебаний — ±20%, алерт только при выходе за него. Включите таблицу праздников: при попадании в праздник автоматически снижайте вес и не алертите. У B2B-сайтов база маленькая, один день слишком чувствителен — судите по скользящему среднему за 7 дней. Эскалация только после 3 дней подряд за границей; колебания за один день фиксируйте, но не тревожьте.

Как понять, верны ли цифры в еженедельном отчёте, который написал ИИ?

Не читайте построчно, проверяйте только три числа: итог, изменение к прошлому периоду и аномалии. Сверьте эти три числа с исходной таблицей, выгруженной из бэкенда, — совпало, значит отправляйте. Пять минут в неделю на три числа выгоднее, чем полчаса на чтение всего текста. Ещё требуйте, чтобы ИИ указывал в отчёте период данных и объём выборки; без этого возвращайте на доработку.

Может ли запрос на естественном языке делать атрибуционный анализ?

Может, но методику нужно закрепить заранее. Например, «из какого канала пришёл этот лид»: сначала определите, использовать Last Touch или First Touch и какое окно атрибуции. Определение впишите в семантический слой, и ИИ отвечает только по этой методике. Не позволяйте ИИ выбирать модель атрибуции на ходу — это значит, что он каждый раз будет менять ответ. Методы атрибуции см.Как правильно считать атрибуцию заявок.

Не становится ли аналитика данных с ИИ тем опаснее, чем больше в ней автоматизации?

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

В заключение

AI-аналитика убрала порог входа в «достать данные», и настоящий порог сместился к «методологии» и «проверке человеком». Кто жёстко зафиксирует определения метрик, чисто изолирует слой данных и пропустит выводы через человека, тот спокойно позволит сотрудникам самим запрашивать данные. Кто поленится и подключит модель напрямую к продакшн-базе, тот рано или поздно примет неверное решение, опираясь на уверенную в себе ошибочную цифру.

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

Три шага внедрения: на первой неделе опишите на одной странице методологию ключевых метрик — «заявки, визиты, конверсия»; на второй выгрузите данные один раз и попросите AI написать черновик недельного отчёта, а сами проверьте три цифры; на третьей добавьте одно правило оповещения об аномалиях.

Не начинайте сразу со полностью автоматического дашборда — сначала отладьте этап проверки человеком.Практика GEO данные сами по себе тоже становятся корпусом, который читает AI, и цифры с единой методологией убедительнее любых формулировок.

Запомните одну фразу: AI ищет данные и пишет черновики, человек проверяет цифры и принимает решения. Разделите эти две роли — и автоматизация не превратится в автоматизацию ошибок.