W CRM są Jan Kowalski, J. Kowalski i Jan Kowalski z adresem prywatnym. Model proponuje jedno kliknięcie „scalić wszystko”. Problem: to dwie osoby, a trzeci rekord powstał przez powtórzony webhook. Podobieństwo nazwy brzmi jak dowód, dopóki nie sprawdzisz historii.
Deduplikacja odpowiada na dwa pytania: czy rekordy dotyczą tego samego podmiotu i jak zachować ich relacje. AI dobrze wyszukuje kandydatów oraz opisuje różnice. Nie powinna sama decydować o scaleniu przy niepewności.
Zacznij od mapy źródeł duplikatów
Sprawdź formularze, importy, integracje, ręczne dodawanie i ponowienia webhooków. Każde źródło tworzy inny typ duplikatu. Czyszczenie bazy bez mapy zapisu oznacza, że za tydzień problem wróci z nowym identyfikatorem.
Zapisz, które systemy mogą tworzyć i edytować kontakty oraz firmy. Przy każdym wskaż klucz: e-mail, identyfikator zewnętrzny, numer telefonu, NIP, domena lub kombinacja pól. Nie zakładaj, że wszystkie integracje używają tej samej logiki.
Rozdziel duplikat zdarzenia od duplikatu osoby. Ten sam formularz wysłany dwa razy nie zawsze powinien tworzyć nową aktywność. Nowe zgłoszenie istniejącego klienta może być prawdziwym zdarzeniem, ale nie nowym kontaktem.
Normalizacja przed porównaniem
Uporządkuj wielkość liter, spacje, format telefonu i oczywiste warianty zapisu domeny. Zachowaj oryginał przy każdym polu. Normalizacja pomaga porównywać, ale nie powinna nadpisywać danych źródłowych bez śladu.
Nie usuwaj automatycznie znaków diakrytycznych i nie zamieniaj nazwisk na wersje „uproszczone”. To może zwiększać liczbę fałszywych dopasowań. Jeżeli używasz wariantów do wyszukania kandydatów, ostateczna decyzja nadal wymaga innych dowodów.
Nie łącz adresów typu plus w jedną tożsamość bez sprawdzenia zasad. Dla jednej firmy alias jest tym samym odbiorcą, dla innej może być osobnym kontem. Zapisz reguły zgodnie z rzeczywistym procesem, nie z wygodnym tutorialem.
Identyfikator ma różną siłę
Dokładny adres e-mail bywa mocnym sygnałem, ale współdzielona skrzynka nie jest jedną osobą. NIP identyfikuje podmiot, lecz nie kontakt. Numer telefonu może zmieniać właściciela. Każde pole ma ograniczenie.
Zapisz hierarchię dowodów dla kontaktu i osobną dla firmy. Model może zaproponować parę na podstawie podobieństwa, ale aplikacja powinna pokazać zgodne i sprzeczne pola. Decyzja „to ta sama firma” nie oznacza automatycznie „to ta sama osoba”.
Nie twórz identyfikatora z samej nazwy. Jan Kowalski to nie unikalny klucz, nawet jeśli w twojej małej bazie przez rok wyglądał na taki. Nowy import potrafi szybko zakończyć tę serię szczęścia.
Kandydat nie jest decyzją o merge
Przygotuj kolejkę par z powodem dopasowania i różnicami. Pokaż źródła, daty, właścicieli, zgody, statusy i liczbę powiązanych zdarzeń. Człowiek powinien zobaczyć, co straci lub zmieni po scaleniu.
Rozdziel pary pewne według twardych reguł od podejrzanych. Nawet przy zgodnym e-mailu sprawdź typ rekordu i skutek dla historii. Przy podobnym nazwisku bez innych dowodów nie uruchamiaj automatycznego merge.
Oznacz także pary odrzucone. Bez tego model zgłosi je ponownie przy następnym imporcie. Zapisz powód odrzucenia i zakres reguły, żeby nie blokować przyszłych zmian na zawsze bez przeglądu.
Wybór rekordu głównego
Nie wybieraj automatycznie najnowszego. Starszy rekord może mieć zatwierdzone zgody, pełną historię i relacje. Nowszy może zawierać aktualny telefon, ale przypadkowego właściciela. Wybór dotyczy pól oraz relacji, nie tylko jednego ID.
Zapisz, który system jest źródłem prawdy dla każdego typu informacji. Marketing może być właścicielem zgody na newsletter, sprzedaż właścicielem etapu, a obsługa aktualnych danych kontaktowych. Scalenie nie powinno oznaczać zwycięstwa ostatniego zapisu.
Przy konflikcie zachowaj obie wartości i poproś właściciela o decyzję. Model nie powinien wybierać „pełniejszego” tekstu. Pełniejszy bywa po prostu bardziej rozwlekły i nieaktualny.
Zgody nie sumują się automatycznie
Jeden rekord może zawierać zgodę na określony kanał, drugi rezygnację lub sprzeciw. Ich połączenie wymaga reguły prawnej i procesowej. Nie ustawiaj zgody na „tak”, jeżeli którykolwiek rekord ją zawiera.
Zachowaj źródło, datę, cel i zakres każdego statusu. Po scaleniu system wysyłający musi respektować właściwy stan. Test obejmuje rezygnację przed i po merge, także przy cache oraz zaplanowanej kampanii.
Przy niejasności wstrzymaj komunikację marketingową i skieruj decyzję do właściciela. Techniczne scalenie nie może usuwać prawa do sprzeciwu. Zasady prywatności opisuje przewodnik o RODO przy AI.
Relacje są ważniejsze niż ładna karta kontaktu
Sprawdź aktywności, oferty, zgłoszenia, notatki, faktury, zadania i właścicieli. Po scaleniu wszystkie powinny wskazywać właściwy rekord. Dokumentacja Microsoft opisuje łączenie rekordów podrzędnych, ale twój proces musi potwierdzić skutek w każdej integracji.
Zachowaj mapę starych identyfikatorów. Systemy zewnętrzne mogą odwoływać się do nich po merge. Bez mapy kolejna synchronizacja odtworzy duplikat albo zapisze zdarzenie w nowym miejscu.
Nie kasuj historii źródła dla czystszego wyglądu. Osoba analizująca relację powinna wiedzieć, że doszło do scalenia, kiedy i z jakiego powodu. Inaczej przyszła korekta będzie zgadywaniem.
Rollback wymaga przygotowania przed merge
Zapisz migawkę pól, relacji, identyfikatorów i decyzji. Sprawdź, czy system pozwala cofnąć scalenie. Jeżeli nie, przygotuj procedurę ręcznego odtworzenia i przetestuj ją na danych fikcyjnych.
Nie zakładaj, że eksport CSV z kontaktami obejmuje wszystkie relacje i skutki w innych systemach. Sprawdź zakres dostępnego eksportu i to, czy da się z niego odtworzyć powiązania. Plan powinien opisywać, jak przywrócić właścicieli, zgody, zadania i identyfikatory integracji.
Przy dużej operacji wykonaj najpierw jedno scalenie kontrolowane i pełny odbiór. Dopiero potem kolejne partie. „Undo” w interfejsie bez sprawdzenia relacji jest ikoną nadziei.
Przykład: ta sama firma, różne osoby
Dwa kontakty mają imię i nazwisko Anna Nowak i pracują w tej samej firmie. Jeden adres dotyczy an.nazwisko, drugi anna.nazwisko. Model uznaje je za duplikat po nazwisku i domenie. To za mało.
Sprawdź role, telefony, źródła i aktywność. Jeżeli nadal nie ma pewności, zostaw osobne rekordy i zaznacz do weryfikacji. Błędne scalenie może wysłać prywatną historię lub ofertę do niewłaściwej osoby.
Ta sama ostrożność dotyczy współdzielonych skrzynek. Można połączyć zgłoszenia na poziomie firmy bez łączenia wszystkich osób w jeden kontakt. Model danych powinien odzwierciedlać rzeczywistość, nie upraszczać ją dla raportu.
Test ponowienia i wyścigu
Wyślij to samo zdarzenie dwa razy i jednocześnie z dwóch źródeł. System powinien użyć klucza idempotencji lub kontroli stanu, żeby nie utworzyć duplikatu. Samo sprawdzenie „czy istnieje” przed zapisem nie wystarcza przy równoległych żądaniach.
Dodaj opóźnienie odpowiedzi i ponowienie po timeout. Proces powinien wiedzieć, czy poprzednia operacja została wykonana. Nie twórz nowego kontaktu tylko dlatego, że pierwsza odpowiedź nie dotarła na czas.
Po teście sprawdź liczbę rekordów, historię i skutki uboczne: maile, zadania, kampanie. Brak duplikatu kontaktu nie wystarcza, jeżeli powstały dwa follow-upy. Tutaj przydają się zasady z artykułu o automatyzacji leadów CRM.
Czyszczenie historyczne partiami
Wybierz jeden typ duplikatu i ograniczony okres. Zapisz liczbę rekordów przed, kandydatów, zatwierdzone merge, odrzucone pary i błędy. Nie uruchamiaj jednego wielkiego zadania dla całej bazy.
Po partii otwórz losowe rekordy i wszystkie przypadki krytyczne. Sprawdź zgody, relacje i integracje. Porównaj raporty sprzedaży przed i po, żeby zauważyć zmianę mianownika lub przypisania.
Jeżeli błąd dotyczy reguły, zatrzymaj kolejne partie. Nie kończ harmonogramu tylko dlatego, że większość jest gotowa. Błędna reguła skaluje się szybciej niż ręczna poprawka.
Pomiar bez nagrody za mniejszą bazę
Nie zakładaj, że mniej kontaktów oznacza lepsze dane. Może oznaczać zbyt agresywne scalanie. Mierz liczbę potwierdzonych duplikatów, fałszywych par, powracających źródeł i czas odbioru.
Sprawdź, czy historia klienta jest łatwiejsza do odczytania i czy zespół nie poprawia ręcznie tych samych pól. Skutek powinien być widoczny w pracy, nie tylko w raporcie czyszczenia.
Raz na jakiś czas przeglądaj reguły z właścicielem sprzedaży, marketingu i danych. Nowe źródło może wymagać innego klucza. Nie zmieniaj reguł bez testu na starych parach i nowych przypadkach.
Minimalny stały proces
Przy nowym zdarzeniu normalizuj dane, sprawdź klucz, zablokuj duplikat zapisu i przypisz relację. W tle przygotowuj kandydatów do przeglądu. Merge wykonuje właściciel lub twarda reguła z pełnym logiem.
Zachowaj rejestr decyzji i sposób rollbacku. Po zmianie integracji powtórz test ponowienia i mapy identyfikatorów. Proces jest skończony dopiero, gdy nowe duplikaty nie wracają z tego samego źródła.
Uprawnienia do operacji scalania
Nie każda osoba analizująca jakość danych musi mieć prawo merge. Rozdziel odczyt, propozycję, zatwierdzenie i wykonanie. Ogranicz dostęp do pól, które nie są potrzebne do porównania tożsamości. Pełna historia medyczna, finansowa lub prywatna nie powinna pojawiać się w kolejce tylko dlatego, że rekord ma podobne nazwisko.
Agent powinien przygotowywać pary i dowody na koncie o ograniczonym zakresie. Nie musi mieć prawa usuwania rekordów ani zmiany zgód. Przy eksporcie użyj minimalnych pól i identyfikatorów. Log operacji zapisuje decyzję bez kopiowania całej zawartości kontaktu do kolejnego systemu.
Przeglądaj konto integracji po każdej zmianie uprawnień. Test odmowy jest równie ważny jak test poprawnego scalenia. Jeśli agent może wykonać operację, której proces mu nie pozwala, konfiguracja jest zła niezależnie od jakości promptu.
Przegląd reguł po nowym imporcie
Nowy plik może zawierać inne identyfikatory i formaty. Zanim uruchomisz scalanie, porównaj próbkę z obecnymi rekordami. Zapisz, które pola są dostępne i jakie nowe konflikty powstają. Nie zmieniaj hierarchii dowodów tylko dlatego, że import nie zawiera dotychczasowego klucza.
Po imporcie sprawdź liczbę nowych kandydatów oraz źródła. Nagły wzrost może oznaczać złą mapę pól, a nie epidemię duplikatów u klientów. Zatrzymaj dalsze partie do czasu wyjaśnienia. Po poprawce powtórz tę samą próbkę i kilka rekordów kontrolnych.
Przy odbiorze zapisz także pary, dla których brakuje dowodu, ale nie wolno ich scalać automatycznie. Nie usuwaj ich z kolejki bez decyzji. Przypisz właściciela i wymagany dokument albo kontakt. Brak pewności jest stanem procesu, a nie pozwoleniem na wybór wygodniejszej wersji.
Aeneia Audit pomaga zmapować źródła i odpowiedzialność. Przy większej bazie pomocne jest podejście Aeneia Signal do deduplikacji CRM.
Niepewna para kontaktów powinna zostać w kolejce z powodem i osobą odpowiedzialną za sprawdzenie. Zanim połączysz rekordy, upewnij się, że historia i identyfikatory trafią we właściwe miejsce.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
