Почему импорт от нескольких поставщиков ломает каталог
Каждый поставщик отдаёт прайс в своём формате: у одного артикул в колонке SKU, у другого — Код, у третьего его нет вовсе, а товар опознаётся по названию. Импорт прайсов от нескольких поставщиков без нормализации приводит к тому, что один и тот же товар заводится заново при каждом обновлении: меняется регистр, добавляется бренд в название, отличается единица измерения. Так в каталоге появляются дубли, и дальше они расходятся по всей цепочке — в фильтрах, поиске, остатках на складе.
Цена ошибки видна не сразу. Покупатель видит три карточки одного товара с разными ценами и не понимает, какая настоящая; менеджер не может свести остатки, потому что часть лежит на одной карточке, часть на другой; аналитика по продажам размазывается, и решение о закупке принимается по искажённым данным. Целостность каталога держится не на аккуратности оператора, а на правилах сопоставления, которые отрабатывают на каждом импорте.
Дедупликация товаров — это не разовая чистка, а слой логики между прайсом и каталогом. Он определяет, по каким признакам товар считается тем же самым (артикул поставщика, штрихкод, связка бренд + модель), что делать при конфликте цен и как слить описания, не потеряв характеристики. Ниже разбираем, как это устроено и почему без такого слоя каталог деградирует с каждым новым поставщиком.
Что даёт корректная дедупликация товаров
Корректная дедупликация товаров — это не косметическая чистка каталога, а изменение его физики. Когда один и тот же товар приходит от трёх-четырёх поставщиков под разными названиями, артикулами и единицами измерения, каталог начинает расти быстрее, чем ассортимент: на сотню реальных позиций легко набегает триста карточек. После сведения по ключевым атрибутам — производитель, модель, модификация, штрихкод — число карточек сокращается в разы, и это первое, что видит заказчик в отчёте.
Второй эффект — конверсия поиска. Пока дубли живут отдельными карточками, остатки размазаны по ним: на одной позиции ноль, на другой три штуки, покупатель видит «нет в наличии» и уходит. После объединения остатки складываются в одну карточку, и доля запросов, которые заканчиваются добавлением в корзину, растёт без единого изменения в рекламе или ценах.
Третий эффект — ручные правки. Дедупликация товаров убирает главный источник постоянной работы контент-менеджера: сверку дублей, перенос описаний, ручной пересчёт остатков после каждой поставки. Правило сведения применяется на импорте автоматически, поэтому новые поступления от поставщиков сразу ложатся в существующие карточки, а не создают новые.
Отдельно стоит ошибка в остатках — самый дорогой класс сбоев. Когда две карточки ссылаются на один физический товар, списание по одной не уменьшает число на другой, и покупатель оформляет заказ на позицию, которой уже нет. Сведение карточек к единому идентификатору закрывает этот разрыв: остаток становится общим, а расхождение между складом и витриной перестаёт накапливаться.
Все три эффекта измеримы и проверяются на исторических данных поставщиков до внедрения — разбираем, как это устроено и какие правила сведения нужны именно вашему каталогу.
Сравнение подходов к сопоставлению товаров
Сопоставление товаров — это выбор между полнотой и точностью: чем агрессивнее алгоритм склеивает карточки, тем выше риск схлопнуть два разных товара в один. На практике выбор сводится к четырём подходам, и почти всегда рабочая конфигурация — гибридная: сначала точное совпадение по артикулу, затем нечёткое по названию, а спорные случаи уходят на ручной разбор.
| Подход | Когда подходит | Ограничения |
|---|---|---|
| Точное совпадение по артикулу | У поставщиков есть артикул производителя или штрихкод, справочник стабилен | Не работает, если поставщики дают свои внутренние коды; не ловит опечатки и разные форматы записи |
| Нечёткое совпадение по названию | Артикулы отсутствуют или противоречат друг другу, номенклатура текстовая | Ложные срабатывания на похожих моделях и расфасовках; нужен порог схожести и стоп-слова |
| Гибридный подход с правилами слияния | Несколько поставщиков, разнородные данные, нужен предсказуемый результат | Требует настройки приоритетов полей и регулярного пересмотра правил |
| Ручной разбор очереди спорных | Остаток после автоматики, критичные категории | Не масштабируется без очереди и ролей; без него ошибки копятся незаметно |
Точное совпадение даёт нулевую долю ложных склеек, но покрывает лишь ту часть каталога, где поставщики договорились об идентификаторах. Нечёткое сопоставление поднимает покрытие, зато требует порога схожести, нормализации регистра, единиц измерения и артикульных префиксов — иначе «кабель 2 м» и «кабель 2 м экранированный» слипнутся.
Гибридный подход с правилами слияния снимает это противоречие: точное совпадение закрывает ядро каталога, нечёткое добирает остальное, а правила определяют, из какой карточки берётся название, описание, цена и остатки. Спорные пары не удаляются молча, а попадают в очередь ручного разбора с сохранением истории решений — так ошибка исправляется один раз и не возвращается при следующем импорте.
Этапы внедрения дедупликации в существующий импорт
Внедрение идёт поверх работающего импорта, без остановки приёма прайсов. Первый шаг — аудит: смотрим, какие поставщики и в каком формате отдают данные, где дубли уже накопились и по каким полям товары совпадают фактически. Это даёт реальную картину, а не предположение, что «артикул всё решит».
- Аудит текущих прайсов. Собираем выгрузки всех поставщиков, считаем объём, долю пересечений и типовые расхождения — разное написание бренда, лишние пробелы, артикулы с префиксами поставщика.
- Схема ключей сопоставления. Определяем, что считаем одним товаром: связка «бренд + артикул» как основной ключ, нормализованное название и штрихкод — как вспомогательные. Фиксируем приоритет источников, чтобы при конфликте полей было понятно, чьё значение главное.
- Правила слияния. Настраиваем, как объединяются карточки: какие поля берём от поставщика-эталона, что дополняем, как поступаем с ценой, остатками и характеристиками. Правила описываются явно, а не «на усмотрение алгоритма».
- Проверка на исторических данных. Прогоняем новые правила на накопленных прайсах и смотрим, сколько ложных склеек и пропущенных дублей получилось. Порог совпадения подкручиваем до приемлемого уровня, спорные пары разбираем вручную.
- Внедрение в конвейер импорта. Подключаем дедупликацию к текущему потоку: новые позиции проходят проверку до записи в каталог, существующие — обновляются, а не создаются заново.
- Регламенты и передача. Отдаём описание ключей, правил слияния и порядка действий при спорных совпадениях — чтобы команда сопровождала процесс без нас.
После запуска каталог перестаёт расти за счёт дублей, а обновление цен и остатков идёт по одной карточке вместо нескольких. Опишите, как у вас устроен импорт сейчас, — вернёмся с оценкой и планом работ.
Что заказчик получает после настройки
На выходе — не «настроенный модуль», а комплект, по которому ваши инженеры смогут работать без нас: менять правила, добавлять поставщиков, разбирать спорные совпадения.
- Конфигурации правил дедупликации: приоритет источников, пороги схожести для артикула, названия и характеристик, поведение при конфликте полей — какой поставщик считается мастер-источником.
- Схемы сопоставления: карта полей каждого поставщика к вашей модели товара, включая единицы измерения, вложенные категории и составные атрибуты.
- Политики доступа: кто из сотрудников может править правила, кто — только просматривать очередь спорных совпадений, кто подтверждает объединение карточек вручную.
- Очередь ручного разбора: интерфейс для случаев, где автоматика не уверена, с историей решений — чтобы повторный импорт не поднимал уже закрытый вопрос.
- Документация: описание логики сопоставления, словарь синонимов и сокращений поставщиков, инструкция по добавлению нового источника.
- Регламенты обновления: как часто пересматриваются пороги, кто отвечает за чистку справочника, что делать при массовом расхождении после смены формата выгрузки у поставщика.
- Набор проверок на тестовой выборке: эталонные пары «дубль / не дубль», по которым видно, не деградали ли правила после правок.
- Метрики: доля автоматически объединённых карточек, объём ручной очереди, число ложных склеек — по ним видно, когда правила пора пересматривать.
Всё это передаём с разбором на ваших данных, а не абстрактным шаблоном. Опишите задачу — вернёмся с оценкой и планом.
Кейс: как мы устранили дубли в каталоге на 40 000 позиций
Что было до
Каталог на 40 000 позиций собирался из прайсов пяти поставщиков, и каждый импорт добавлял новые карточки вместо обновления существующих. Один и тот же товар приходил под разными названиями, артикулами и единицами измерения — поставщики не сверялись между собой. Каталог рос быстрее, чем продажи: к моменту разбора в нём было около 63 000 карточек, из них почти треть — дубли.
Ручные правки съедали время контент-менеджера: после каждого импорта приходилось вручную сводить совпадения, а часть дублей так и оставалась в выдаче. Покупатель видел три карточки одного товара с разными ценами и не понимал, какая настоящая.
Что изменили
Мы построили конвейер сопоставления на стороне приложения: нормализация названий и артикулов, сравнение по набору признаков — бренд, модель, единица измерения, штрихкод. Каждой паре присваивается вес совпадения, и по порогу система решает — обновить существующую карточку или создать новую. Спорные случаи не сваливаются в общую кучу, а попадают в отдельную очередь на подтверждение.
Импорт переписали на пакетную обработку с идемпотентным ключом: повторный запуск прайса больше не плодит дубли, а обновляет те же позиции. Логика зафиксирована в правилах, а не в голове менеджера — новый поставщик подключается без переписывания кода.
Что стало
| Метрика | До | После |
|---|---|---|
| Карточек в каталоге | ~63 000 | ~40 000 |
| Доля ручных правок после импорта | высокая | единичные спорные случаи |
| Время импорта прайса | растёт с каждым запуском | стабильное |
| Класс ошибок | дубли в выдаче, расхождение цен | не воспроизводится |
Дубли в каталоге перестали накапливаться: каталог теперь отражает реальный ассортимент, а не историю загрузок. Ручные правки свелись к разбору очереди на подтверждение — это десятки позиций вместо тысяч.
Проект вёл TrueTech: наши инженеры отвечали и за логику сопоставления, и за перестройку импорта, поэтому правила дедупликации сразу легли в основу, а не прикручивались поверх готового каталога.
Чем отличается дедупликация от нормализации данных
Нормализация данных приводит значения к единому виду, но не решает, что считать одним товаром. Это два последовательных этапа обработки, и путать их — значит получить каталог, где «iPhone 15 128Gb» и «Apple iPhone 15 128 ГБ» останутся двумя разными позициями. Нормализация отвечает на вопрос «как записать значение», дедупликация — «сколько записей должно остаться».
Нормализация работает на уровне отдельного поля: приводит регистр и раскладку, убирает лишние пробелы и непечатаемые символы, сводит единицы измерения к одной шкале, разбирает слипшиеся атрибуты вроде «128Gb Black» на объём и цвет, чистит артикулы от префиксов поставщика. На выходе каждая карточка остаётся сама собой, но её поля становятся сравнимыми — без этого следующий шаг невозможен, потому что сравнивать «128 ГБ» и «128gb» напрямую бессмысленно.
Дедупликация данных решает другую задачу: определить, какие записи описывают один и тот же физический товар, и свести их в одну карточку. Здесь работает составной ключ — нормализованные артикул производителя, бренд и модель плюс набор характеристик, — а не одно поле. Два поставщика могут называть позицию по-разному, давать разные фото и разную комплектацию, но за ними стоит один товар, и в каталоге он должен быть один.
Граница между подходами проявляется в спорных случаях. Нормализация не спасёт, если один поставщик пишет артикул с суффиксом склада, а другой — без: значения останутся разными, хотя товар один. И наоборот, дедупликация без нормализации склеит лишнее — «iPhone 15» и «iPhone 15 Pro» совпадут по бренду и модели, если не сравнивать характеристики в едином виде.
Поэтому порядок жёсткий: сначала нормализация данных по каждому полю, затем дедупликация по составному ключу, и только потом — слияние карточек с правилами приоритета по поставщикам. Если поменять этапы местами, часть дублей останется незамеченной, а часть разных товаров схлопнется в один — и оба класса ошибок придётся разбирать вручную.
Частые технические сомнения
Импорт уже работает, товары в каталоге, и мысль «а не сломает ли дедупликация то, что живёт» — нормальная реакция инженера. Ниже — разбор трёх сомнений, которые чаще всего всплывают до старта.
У нас уже развёрнут импорт от нескольких поставщиков. Всё переделывать?
Нет. Мы не трогаем работающий контур: разбираем текущие правила сопоставления, выгружаем каталог в staging, прогоняем дедупликацию на копии и показываем отчёт — сколько групп схлопнется, сколько останется спорными. Переключение идёт по одной категории, с возможностью вернуть предыдущее состояние каталога. Боевой импорт продолжает работать, пока вы не подтвердите результат на копии.
У поставщиков разные единицы измерения — как их сводить?
Приводим к базовой единице хранения через справочник коэффициентов: упаковка, вес, объём, штука. Коэффициент задаётся один раз на единицу и переиспользуется — при добавлении поставщика не нужно переписывать правила. Если единица неоднозначна (например, «коробка» без вложенности), товар уходит в очередь на ручную проверку, а не сопоставляется наугад.
Как не потерять историю товара при слиянии дублей?
История — это отдельная сущность, она не удаляется вместе с карточкой-дублем. Цены, остатки и движения привязываются к группе сопоставления, а не к конкретной записи поставщика, поэтому после слияния график цен и статистика продаж остаются непрерывными. Старые идентификаторы сохраняются как алиасы — внешние системы и ссылки продолжают находить товар по прежнему коду.
Что если алгоритм ошибётся и склеит разные товары?
Слияние обратимо: перед применением сохраняется снимок групп, а сам процесс идёт пакетами с журналом решений. Спорные пары не склеиваются автоматически — они попадают в отчёт с признаками совпадения, и решение принимает человек. Откат пакета возвращает карточки в исходное состояние без потери данных поставщиков.
Опишите, как у вас сейчас устроен импорт и сколько поставщиков в контуре, — вернёмся с оценкой и планом поэтапного внедрения.
Обсудим вашу задачу по дедупликации
Чтобы вернуться с оценкой и планом, а не с общими словами, нам нужен доступ к реальной картине каталога. Дедупликация товаров — задача, где решение целиком зависит от данных: сколько поставщиков, как отличаются их выгрузки, по каким полям вообще возможно сопоставление. Поэтому первый шаг — короткий разбор ваших данных, а не шаблонное предложение.
Пришлите то, что уже есть под рукой: выгрузки от двух-трёх поставщиков в исходном виде, справочник категорий и брендов, если он ведётся, и описание того, как товар сейчас попадает в каталог — вручную, скриптом или через готовый модуль. Этого достаточно, чтобы увидеть структуру полей, оценить долю дублей и понять, какие правила сопоставления сработают, а какие дадут ложные склейки.
Дальше мы разберём данные и вернёмся с конкретикой:
- карта полей по каждому поставщику — где совпадают названия, артикулы, штрихкоды, единицы измерения;
- оценка объёма дублей и типовых расхождений: опечатки, разный порядок слов, сокращения брендов;
- предложение по правилам сопоставления — что склеиваем автоматически, что уходит на ручную проверку;
- схема очереди на модерацию спорных пар, чтобы менеджер не тонул в ручных решениях;
- план внедрения с этапами, сроками и точками, где вы видите результат;
- варианты отката, если правило даёт ложные срабатывания на живом каталоге.
Следующий шаг — короткий разговор по этим материалам. Опишите задачу в удобной форме: сколько поставщиков, как часто обновляются выгрузки, кто сейчас разбирает дубли. Мы посмотрим данные и вернёмся с оценкой и планом — что делаем первым, что даёт эффект быстрее всего и где потребуется ваше участие.
