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

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

Что считать качеством

Качество данных — это соответствие результата ожидаемой схеме и бизнес-задаче. Минимальные метрики:

• количество строк;
• доля заполненных обязательных полей;
• количество дублей;
• диапазоны числовых значений;
• валидность ссылок;
• дата сбора;
• доля ошибок по источникам;
• стабильность относительно прошлого запуска.

Обязательные поля

Для каждого сценария выберите поля, без которых строка бесполезна.

Для мониторинга цен:

• SKU;
• цена;
• наличие;
• источник;
• дата проверки.

Для лидогенерации:

• название компании;
• сайт или телефон;
• регион;
• источник;
• дата сбора.

Если обязательное поле пустое, строка должна попасть в отдельный статус, а не смешиваться с нормальными данными.

Валидация типов

Примеры правил:

{
  "price": "number, greater_than: 0",
  "available": "boolean",
  "source_url": "url",
  "captured_at": "datetime",
  "currency": "RUB"
}

Цена “по запросу” не должна попадать в числовое поле. Дата “сегодня” не должна храниться как текст. Чем ближе данные к API или BI, тем важнее строгая схема.

Аномалии

Аномалия не всегда ошибка, но ее нужно проверять:

• цена изменилась на 80%;
• количество карточек упало с 5000 до 300;
• все товары стали “нет в наличии”;
• продавец исчез из всех карточек;
• средняя цена категории стала нулевой;
• доля пустых описаний выросла в 10 раз.

Такие события лучше отправлять как алерт, а не ждать, пока аналитик сам заметит странность.

Дубли

Дубли ломают аналитику. Для разных задач нужны разные ключи:

Важно хранить исходные ссылки: они помогают понять, почему строки объединились или разделились.

История запусков

Каждый запуск должен сохранять:

• время;
• источник;
• количество страниц;
• количество строк;
• ошибки;
• предупреждения;
• версию схемы;
• ссылку на результат.

Без истории невозможно отличить изменение рынка от поломки парсера.

Итог

Качество данных в парсинге нужно проектировать заранее. Если нет обязательных полей, правил валидации, контроля дублей и истории запусков, команда рано или поздно будет принимать решения по мусору. Хорошая система не скрывает ошибки, а показывает их до того, как они попали в отчет.