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

Две разные задачи: посчитать и объяснить

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

Для вычислений нужен инструмент, который выполняет заданную формулу одинаково при каждом запуске: электронная таблица, SQL-запрос, скрипт или отчёт аналитической системы. Нейросеть может помочь написать формулу и объяснить её, но число становится надёжным только после выполнения в таком инструменте.

Для смысловой части модель сильна. Она быстро собирает однотипные поисковые фразы в темы, превращает технические названия столбцов в понятный вывод, предлагает дополнительные разрезы и замечает, что один сегмент ведёт себя иначе. Это экономит время аналитика, но не снимает проверку.

Хороший процесс звучит так: «таблица посчитала, модель помогла увидеть вопросы, аналитик подтвердил причины и подготовил решение». Плохой — «мы вставили CSV и поверили готовому резюме».

Что модель делает хорошо: группировка, гипотезы и формулировки

Самая полезная роль — ассистент после расчёта. Дайте модели уже вычисленные показатели по сегментам и попросите:

• сгруппировать поисковые запросы по намерению и выделить нецелевые темы;
• сжать длинный отчёт до пяти изменений, которые влияют на деньги;
• переформулировать технический вывод для владельца бизнеса без потери ограничений;
• составить список возможных причин и данных, которыми каждую можно проверить;
• найти непоследовательные названия кампаний, каналов или статусов CRM;
• подготовить вопросы к подрядчику по строкам, где расход есть, а бизнес-результат отсутствует.

Полезно требовать формат ответа. Например: «Для каждого наблюдения укажи факт из таблицы, возможное объяснение, что нужно проверить и какое решение пока принимать нельзя». Это отделяет наблюдение от догадки.

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

При работе с текстовыми данными используйте обезличенные фрагменты. Отзывы и причины отказа можно группировать без имён, телефонов, адресов и номеров заказов. Для анализа часто достаточно категории услуги, региона верхнего уровня и текста после удаления идентификаторов.

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: 'lead_submit',
  form_id: 'audit',
  page_path: location.pathname
});

Где она ошибается: доли, динамика, периоды и атрибуция

Типовая ошибка с долей — неверный знаменатель. Если в выгрузке есть строки по дням и кампаниям, повторно сложить уже рассчитанные проценты нельзя. Нужно сложить числители и знаменатели, затем делить. Среднее из дневных конверсий даст иное число, особенно когда объём трафика по дням разный.

С динамикой проблема похожа. Модель может сравнить семь дней с полным предыдущим месяцем, календарную неделю с рабочими днями или период акции с обычным. Формально арифметика будет выглядеть правдоподобно, но вывод окажется бессмысленным.

Четыре зоны повышенного риска:

• Проценты и проценты. Рост с 2 до 3% — это плюс один процентный пункт и плюс 50% относительно исходного значения. Эти формулировки нельзя подменять.
• Пропуски и нули. Пустое значение может означать «нет данных», а не нулевой результат.
• Дубли. При объединении двух выгрузок одна транзакция или заявка может попасть дважды.
• Атрибуция. Разные отчёты относят одну конверсию к разным источникам. Нельзя смешивать их итоги без общего правила.

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

Как подготовить выгрузку, чтобы вопрос имел смысл

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

Дальше приведите файл в состояние, которое можно проверить:

1. Оставьте только нужные столбцы. Чем больше случайных полей, тем выше риск, что модель выберет не тот показатель.
2. Назовите единицы в заголовках: «Расход, руб.», «Конверсия, %», «Время, сек.».
3. Приведите даты к одному формату и добавьте признак полного или неполного периода.
4. Удалите итоги внутри таблицы, если строки тоже будут суммироваться: иначе итог попадёт в расчёт второй раз.
5. Отделите ноль от пропуска и подпишите причину пропуска.
6. Обезличьте данные и оставьте минимальный набор, необходимый для задачи.

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

Если нужен расчёт, сначала попросите формулу и список допущений, затем выполните её в таблице. Так ошибка обнаруживается до того, как число попадёт в решение по бюджету.

Три контрольные точки: проверка ответа за пять минут

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

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

Третья — обратная проверка вывода. Для каждого тезиса найдите строки, которые его подтверждают. Если написано «мобильный трафик ухудшился», должны быть видны сопоставимые показатели мобильных за оба периода и достаточный объём. Если тезис нельзя привязать к строкам, это гипотеза, а не результат анализа.

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

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

Отчёт подрядчика: что можно давать модели, а что нельзя

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

Нельзя без необходимости загружать:

• имена, телефоны, адреса, электронную почту и полные тексты обращений клиентов;
• записи звонков и переписку без обезличивания;
• логины, токены, ключи API, ссылки с секретными параметрами;
• договоры, точные коммерческие условия и детали реальных проектов;
• выгрузку CRM целиком, если для вопроса достаточно агрегированной таблицы.

Финальный ответ модели используйте как список вопросов к подрядчику, а не как автоматический приговор. Например: «почему рост заявок не совпал с ростом подтверждённых обращений», «почему сравниваются периоды разной длины», «какая правка могла повлиять на сегмент». Подрядчик должен показать исходный отчёт и логику расчёта. Если вывод нельзя воспроизвести, красивое объяснение не становится аналитикой.