Katalog ma „Lampa USB”, „Lampka USB” i „Lampa z kablem USB-C”. Trzy wpisy, jeden produkt. Czwarty wpis dotyczy innego wariantu zasilania. AI chętnie połączy wszystko w jeden, bo nazwy są podobne. Porządkowanie katalogu nie polega na usuwaniu podobieństwa, tylko na rozstrzyganiu tożsamości produktu.
Dobry proces zachowuje warianty, identyfikatory i historię. Usuwa duplikaty dopiero po dowodzie. AI może proponować pary i wykrywać braki, ale decyzja o scaleniu wymaga danych.
Zacznij od migawki katalogu
Zachowaj oryginalny eksport z datą, źródłem i liczbą rekordów. Nie pracuj na jedynym pliku. Zapisz sumę wartości kontrolnych: liczba produktów, wariantów, pustych pól i unikalnych identyfikatorów.
Sprawdź typy: identyfikator, nazwa, wariant, cena, dostępność, marka, kategoria i linki. Tekstowa data i procent potrafią zmienić analizę. Microsoft wskazuje ograniczenia scalonych komórek i typów, więc najpierw struktura, potem model.
Nie wysyłaj całego katalogu na start. Wybierz jedną kategorię z problemami i mały zestaw wierszy. Popraw reguły przed skalą. Błąd deduplikacji mnoży się szybciej niż opisy.
Identyfikator jest ważniejszy od nazwy
Zachowaj SKU, GTIN, MPN, EAN lub inny właściwy identyfikator. Nazwa jest opisem, nie tożsamością. Może się zmieniać między kanałami i wersjami językowymi. Model nie powinien zastępować identyfikatora podobieństwem.
Sprawdź format i braki. Nie uzupełniaj numerów na podstawie podobnych produktów. Jeżeli identyfikator nie istnieje, zapisz to zgodnie z zasadami kanału. Fikcyjny numer tworzy nowy problem, a nie nowy produkt.
Przy wariantach zachowaj relację rodzic-dziecko. Jedna grupa może mieć różne kolory lub rozmiary z osobnymi identyfikatorami. Nie zamieniaj wariantu w duplikat rodzica tylko dlatego, że opis jest podobny.
Duplikat ma kilka możliwych znaczeń
Ten sam produkt może zostać dodany przez dwie integracje, ale podobne nazwy mogą też dotyczyć dwóch różnych pakietów. Zapisz źródło, datę, cenę, atrybuty i identyfikatory. Dopiero wtedy zdecyduj, czy wpisy opisują duplikat czy odrębne warianty.
Reguła kandydująca może łączyć identyfikator, markę, model i wariant. Nie usuwaj na podstawie samej nazwy. Model może zaproponować parę, ale ekran odbioru pokazuje różnice i historię.
Zachowaj rekord główny i mapę starych identyfikatorów. Integracje muszą wiedzieć, że rekordy zostały scalone. Bez tego przy następnej synchronizacji duplikat wróci jak nowy pracownik po zwolnieniu, którego nikt nie odnotował.
Atrybuty najpierw typy i jednostki
Sprawdź cenę, walutę, dostępność, wymiary, wagę i warianty. Rozdziel wartość od jednostki. „1,5” bez informacji o metrach nie jest atrybutem do publikacji. Model nie powinien zgadywać jednostki.
Zachowaj puste pola i ich powód. Brak może oznaczać nieznaną wartość, nie dotyczy albo niedozwolone. Nie zamieniaj ich w zero. Zero może być prawdziwą ceną lub wagą i wymaga osobnej decyzji.
Dodaj zasady dla każdej kategorii. Inne pola są wymagane dla odzieży, elektroniki i usługi. Specyfikacja kanału pomaga, ale katalog musi zachować własny słownik. Nie przypisuj jednej struktury wszystkim produktom.
Scalanie bez utraty historii
Przy scaleniu wybierz rekord główny i pola do zachowania. Nowszy opis nie zawsze jest lepszy. Zatwierdzony opis może mieć właściwy wariant, podczas gdy automatyczny wzbogaca nieznane atrybuty.
Zapisz, co zostało zmienione i dlaczego. Zachowaj stare linki i przekierowania, jeżeli adres się zmienia. Obrazy i relacje wymagają odbioru osobno od danych. Nie usuwaj historii sprzedaży.
Test obejmuje ponowny eksport i synchronizację. Sprawdź, czy stare identyfikatory nie tworzą nowych rekordów. Jeżeli nie da się cofnąć scalenia, nie uruchamiaj go masowo.
Zmiana ceny i dostępności
Porównaj katalog z publiczną stroną. Cena i dostępność muszą zgadzać się z wariantem. Model może wykryć różnicę, ale nie decydować, która wartość jest aktualna. Właściciel potwierdza źródło.
Zapisz datę i kanał sprawdzenia. Cena może różnić się z powodu regionu, promocji lub cache. Nie poprawiaj automatycznie po jednym odczycie. Przy rabacie zachowaj warunki i okres.
Przy usłudze cyfrowej zastąp dostępność planem i ograniczeniami. Klient nie powinien zobaczyć funkcji, która została wyłączona. Aktualizacja dotyczy także dokumentacji i porównań, nie tylko feedu.
Słownik kategorii przed wzbogaceniem
Uporządkuj nazwy kategorii i przypisania. „Akcesoria”, „inne” i „różne” nie pomagają wyszukiwarce ani zespołowi. Model może zaproponować kategorię z listy, ale nie powinien tworzyć nowej hierarchii bez właściciela.
Sprawdź warianty kategorii między kanałami. Zachowaj mapę, a nie zgadywanie. Jeżeli kategoria jest nieznana, zostaw do ręcznego przypisania. Błędna kategoria może zmieniać wymagane atrybuty i widoczność.
Nie przenoś produktów do nowej kategorii tylko dla lepszych fraz. Zmiana ma odzwierciedlać rzeczywisty typ i sposób wyszukiwania. SEO nie jest powodem do złej architektury.
Przykład pary, której nie wolno scalić
Mamy dwa produkty o nazwie „Lampa biurkowa USB-C”. Jeden ma kabel 1,5 m i jest wersją podstawową, drugi ma 2 m i zasilacz. Opisy są podobne, ale zawartość i warianty różnią się. Model proponuje duplikat.
Odbiór porównuje identyfikatory i zawartość. To nie jest duplikat, tylko warianty. Scalenie mogłoby przypisać zasilacz do wszystkich zamówień. Zachowujemy grupę i osobne rekordy.
Po poprawce opisów widać różnicę bez zmiany struktury. Deduplikacja nie zawsze oznacza scalenie. Czasem oznacza lepszy opis i właściwe identyfikatory. Sposób przejścia od danych do treści opisuje także przewodnik o opisach produktów z AI.
Kontrola po czyszczeniu
Porównaj liczbę rekordów, wariantów i pustych pól z początkiem. Jeżeli suma kontrolna zmieniła się bez powodu, zatrzymaj proces. Sprawdź kilka losowych produktów i wszystkie krytyczne zmiany.
Otwórz publiczną stronę dla wariantów. Cena, dostępność, opis, obraz i linki powinny zgadzać się z katalogiem. Test zakończony bez błędu importu nie oznacza poprawnych danych.
Zapisz decyzje i datę. Nowa synchronizacja powinna zachować reguły i unikać powtórek. Jeżeli duplikaty wracają, problem jest w integracji lub źródle, nie w liczbie analiz.
Kiedy nowa nazwa nie jest nowym produktem
Zmiana nazwy może poprawić opis, ale nie powinna tworzyć nowego identyfikatora bez decyzji. Zachowaj relację z poprzednim SKU i historią. Inaczej integracje potraktują zmianę jako dodanie nowego produktu i zgubisz powiązania.
Przy zmianie wariantu sprawdź, czy dotyczy tylko prezentacji czy atrybutu rzeczywistego. Nowy kolor zdjęcia nie zmienia produktu, ale nowy rozmiar już może go różnić. Właściciel zapisuje regułę.
Po zmianie sprawdź stare linki i przekierowania. Katalog ma prowadzić do właściwego wariantu, a nie pustej strony. Zaktualizuj opis i obrazy zamiast tylko nazwy.
Wzbogacanie z zewnętrznych źródeł
Dodawaj dane tylko z zatwierdzonych źródeł i zapisz datę. Publiczny opis dostawcy może dotyczyć innego regionu lub wersji. Model nie powinien przypisywać go do własnego produktu bez identyfikatora.
Rozdziel fakt źródłowy od interpretacji. „Producent podaje wagę 1,2 kg” jest faktem, „jest lekki” jest oceną. Jeżeli źródło nie zawiera informacji, zostaw puste pole. Wzbogacanie nie ma być kolekcją zgadywań.
Przy konflikcie wybierz właściciela danych, nie najpopularniejszy tekst. Dokumentacja wewnętrzna może być dokładniejsza niż opis hurtownika. Zapisz, dlaczego wybrano wersję i kiedy sprawdzić ponownie.
Test na dziesięciu rekordach przed dużym katalogiem
Wybierz poprawny produkt, duplikat, dwie wersje, brak identyfikatora i nietypową jednostkę. Zapisz oczekiwane decyzje przed użyciem modelu. To pozwala sprawdzić, czy reguły odpowiadają na pytania, a nie tylko tworzą nowe grupy.
Porównaj wynik z oczekiwaniem i oceń każdy błąd. Zły typ jest problemem danych, zły duplikat jest problemem reguły, a zła kategoria jest problemem słownika. Nie zmieniaj wszystkiego jednocześnie.
Po poprawce powtórz ten sam zestaw i dodaj kilka nowych rekordów. Jeżeli proces wymaga ręcznego sprawdzenia każdego, ogranicz automatyzację do propozycji. Mały test zapobiega dużej awarii tożsamości.
Odbiór publicznych stron po scaleniu
Otwórz stary i nowy adres. Stary powinien przekierowywać do konkretnego odpowiednika, a nowy pokazywać właściwy wariant. Sprawdź opis, obraz, cenę i linki. Nie wystarczy, że katalog w panelu wygląda dobrze.
Sprawdź wyszukiwarkę i kanały. Jeden system może zachować stare identyfikatory, inny nowe. Mapa powinna uniemożliwiać duplikaty przy kolejnej synchronizacji. Jeżeli wraca stara wersja, proces nie jest zakończony.
Po tygodniu porównaj zgłoszenia klientów i błędy danych. Jeżeli występują nowe niezgodności, wróć do mapy i historii. Nie zmieniaj kolejnych rekordów przed rozwiązaniem przyczyny.
Kolejka propozycji zamiast jednego wielkiego importu
Podziel wynik na cztery koszyki: pewne duplikaty zgodne po identyfikatorze, możliwe duplikaty wymagające porównania, osobne warianty oraz rekordy z brakami. Każdy koszyk ma inne działanie. Pierwszy nadal potrzebuje kontroli skutku, drugi decyzji człowieka, trzeci ochrony przed połączeniem, a czwarty uzupełnienia źródła. Nie mieszaj ich w jeden przycisk „napraw katalog”.
Przy propozycji pokaż tylko pola, które zmieniają decyzję: identyfikator, marka, model, wariant, zawartość, źródło. Długi opis i podobne zdjęcie mogą pomóc, ale nie powinny przykrywać różnicy w numerze produktu. Osoba odbierająca musi widzieć, dlaczego system uznał parę za podobną i które dane temu przeczą.
Zapisz wynik odbioru jako regułę lub przypadek testowy. Jeżeli model połączył dwa warianty z powodu wspólnej nazwy, dodaj przykład blokujący taką decyzję. Nie ograniczaj się do ręcznego rozdzielenia rekordów; bez zmiany reguły ten sam duet wróci przy następnym imporcie. Po tygodniu sprawdź, ile propozycji zostało odrzuconych i z jakiego powodu. Wysoki odsetek błędnych par oznacza, że automatyzacja powinna zostać przy wyszukiwaniu kandydatów, a nie przy scalaniu.
Uprawnienia do czyszczenia danych
Osoba analizująca katalog nie musi mieć prawa do usuwania produktów i historii zamówień. Rozdziel odczyt, przygotowanie propozycji, zatwierdzenie i wykonanie importu. To ogranicza skutek błędnego promptu oraz zwykłego pośpiechu. Przy eksporcie zawęź pola do zadania; pełna historia klientów nie jest potrzebna do rozpoznania dwóch lampek.
Przed każdą operacją zapisz migawkę i sposób przywrócenia. Test rollbacku wykonaj na jednym rekordzie, zanim zaufasz nazwie funkcji. Kopiowanie pliku do folderu „backup-finalny-2” bez sprawdzenia importu jest rytuałem, nie planem odzyskiwania. Po zakończeniu ogranicz dostęp do danych roboczych i usuń zbędne kopie zgodnie z retencją.
Kiedy nie scalać automatycznie
Odpuść przy nieznanych identyfikatorach, wielu wariantach i braku możliwości cofnięcia. Model może przygotować listę podejrzeń, ale człowiek musi zatwierdzić. Nie pozwól, żeby pierwsza reguła zrobiła porządek kosztem zamówień.
Nie używaj samego podobieństwa językowego do decyzji o produkcie. To jest wskazówka, nie dowód. Przy dużej katalogowej operacji przygotuj mały eksperyment i możliwość rollbacku.
Przy większej mapie danych Aeneia Audit pomaga zobaczyć źródła i odpowiedzialność. Podejście Aeneia Signal do deduplikacji CRM pomaga zachować historię.
Podobne nazwy mogą wskazywać zarówno duplikat, jak i dwa różne warianty. Zostaw niepewną parę do rozstrzygnięcia, zachowaj historię zmian i sprawdź powiązane zamówienia przed scaleniem.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
