Чому імпорт від кількох постачальників ламає каталог
Кожен постачальник віддає прайс у своєму форматі: в одного артикул у колонці 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, проганяємо дедуплікацію на копії та показуємо звіт — скільки груп згорнеться, скільки залишиться спірними.
Перемикання йде по одній категорії, з можливістю повернути попередній стан каталогу. Бойовий імпорт продовжує працювати, поки ви не підтвердите результат на копії.
У постачальників різні одиниці вимірювання — як їх зводити?
Приводимо до базової одиниці зберігання через довідник коефіцієнтів: упаковка, вага, об'єм, штука. Коефіцієнт задається один раз на одиницю і перевикористовується — при додаванні постачальника не потрібно переписувати правила.
Якщо одиниця неоднозначна (наприклад, «коробка» без вкладеності), товар потрапляє в чергу на ручну перевірку, а не зіставляється навмання.
Як не втратити історію товару при злитті дублів?
Історія — це окрема сутність, вона не видаляється разом із карткою-дублем. Ціни, залишки та рухи прив'язуються до групи зіставлення, а не до конкретного запису постачальника, тому після злиття графік цін і статистика продажів залишаються безперервними.
Старі ідентифікатори зберігаються як аліаси — зовнішні системи та посилання продовжують знаходити товар за попереднім кодом.
Що якщо алгоритм помилиться і склеїть різні товари?
Злиття оборотне: перед застосуванням зберігається знімок груп, а сам процес іде пакетами з журналом рішень. Спірні пари не склеюються автоматично — вони потрапляють у звіт з ознаками збігу, і рішення ухвалює людина. Відкат пакета повертає картки в початковий стан без втрати даних постачальників.
Опишіть, як у вас зараз влаштовано імпорт і скільки постачальників у контурі, — повернемося з оцінкою та планом поетапного впровадження.
Обговоримо ваше завдання з дедуплікації
Щоб повернутися з оцінкою та планом, а не із загальними словами, нам потрібен доступ до реальної картини каталогу.
Дедуплікація товарів — це завдання, де рішення цілком залежить від даних: скільки постачальників, чим відрізняються їхні вивантаження, за якими полями взагалі можливе зіставлення. Тому перший крок — короткий розбір ваших даних, а не шаблонна пропозиція.
Надішліть те, що вже є під рукою: вивантаження від двох-трьох постачальників у вихідному вигляді, довідник категорій і брендів, якщо він ведеться, та опис того, як товар зараз потрапляє до каталогу — вручну, скриптом або через готовий модуль.
Цього достатньо, щоб побачити структуру полів, оцінити частку дублів і зрозуміти, які правила зіставлення спрацюють, а які дадуть хибні склейки.
Далі ми розберемо дані й повернемося з конкретикою:
- карта полів за кожним постачальником — де збігаються назви, артикули, штрихкоди, одиниці виміру;
- оцінка обсягу дублів і типових розбіжностей: одруки, різний порядок слів, скорочення брендів;
- пропозиція щодо правил зіставлення — що склеюємо автоматично, що йде на ручну перевірку;
- схема черги на модерацію спірних пар, щоб менеджер не тонув у ручних рішеннях;
- план впровадження з етапами, строками та точками, де ви бачите результат;
- варіанти відкату, якщо правило дає хибні спрацювання на живому каталозі.
Наступний крок — коротка розмова за цими матеріалами. Опишіть завдання у зручній формі: скільки постачальників, як часто оновлюються вивантаження, хто зараз розбирає дублі.
Ми подивимося дані й повернемося з оцінкою та планом — що робимо першим, що дає ефект найшвидше і де потрібна ваша участь.
