zduplikowane rekordy w CRM i narzędziu mailingowym

Zduplikowane rekordy w CRM i narzędziu mailingowym wynikają z braku zsynchronizowanego identyfikatora między systemami.

Dlaczego ten sam kontakt pojawia się w dwóch systemach

Zduplikowane rekordy w CRM i narzędziu mailingowym powstają wtedy, gdy oba systemy przechowują informacje o tej samej osobie lub firmie, ale nie potrafią jednoznacznie rozpoznać, że chodzi o ten sam obiekt. Najczęściej przyczyną jest brak wspólnego identyfikatora technicznego, który byłby przekazywany razem z rekordem podczas synchronizacji. Każda aplikacja może wtedy nadać kontaktowi własne, lokalne ID. Identyfikator „12345” w CRM nie musi oznaczać tego samego kontaktu co „12345” w systemie mailingowym.

W takiej sytuacji integracja zaczyna porównywać pola opisowe, na przykład adres e-mail, numer telefonu, imię, nazwę firmy albo adres. Takie dane nie zawsze są jednoznaczne. Adres e-mail może zostać zapisany wielkimi literami, z niezamierzonym odstępem lub w innej postaci. Numer telefonu może występować z prefiksem kraju albo bez niego. Zmiana nazwiska, korekta nazwy firmy czy aktualizacja adresu również może sprawić, że mechanizm uzna istniejący rekord za nowy. Jeżeli systemy nie mają stabilnego klucza wspólnego, aktualizacja kontaktu może zostać wykonana jako utworzenie kolejnego rekordu.

Rola identyfikatora, klucza głównego i mapowania rekordów

W prawidłowo zaprojektowanej synchronizacji każdy kontakt powinien mieć stabilny identyfikator źródłowy oraz informację o powiązaniu z rekordem po drugiej stronie integracji. Może to być na przykład identyfikator CRM zapisany w dodatkowym polu narzędzia mailingowego. Podczas kolejnych operacji system nie musi wtedy zgadywać na podstawie adresu e-mail, lecz odwołuje się do konkretnego powiązania. Identyfikator powinien być niezmienny w czasie i nie może zależeć od kolejności importu danych.

Ważne jest także rozróżnienie klucza głównego od danych wyświetlanych użytkownikowi. Adres e-mail bywa użytecznym kluczem biznesowym, ale jego zastosowanie wymaga jednoznacznych reguł. Należy ustalić, czy porównanie ignoruje wielkość liter, jak usuwane są spacje oraz czy puste adresy są dopuszczalne. W niektórych systemach jedna osoba może mieć kilka adresów, a jeden adres może być przypisany do kilku odbiorców organizacji. Bez opisania tych przypadków automatyczne scalanie może połączyć niewłaściwe rekordy albo pozostawić duplikaty.

Połączenie systemów powinno również określać kierunek przepływu danych. Jeżeli CRM jest źródłem prawdy dla danych kontaktowych, narzędzie mailingowe powinno otrzymywać aktualizacje, ale nie nadpisywać samodzielnie danych nadrzędnych. Potrzebna jest reguła rozstrzygająca konflikt, gdy oba systemy zmieniły ten sam rekord. Bez takiej reguły integracja może naprzemiennie przesyłać różne wartości, tworzyć kolejne wpisy lub przywracać starsze dane.

Jak rozpoznać źródło duplikacji w przebiegu synchronizacji

Analizę należy rozpocząć od porównania kilku konkretnych rekordów, które opisują ten sam kontakt. Trzeba sprawdzić lokalne identyfikatory w obu systemach, wartość adresu e-mail przed normalizacją, datę utworzenia, datę ostatniej modyfikacji oraz identyfikator operacji integracyjnej. Przydatne jest także ustalenie, czy duplikaty powstają podczas pierwszego importu, przy cyklicznej synchronizacji, po ręcznej edycji, czy po ponownym wysłaniu komunikatu z kolejki. Sam fakt występowania dwóch rekordów nie wskazuje jeszcze, który etap zawiódł.

W logach integracji warto szukać rozróżnienia między operacją create, czyli utworzeniem rekordu, a update, czyli aktualizacją istniejącego wpisu. Jeżeli dla tego samego kontaktu każda kolejna synchronizacja kończy się operacją create, mechanizm wyszukiwania powiązania nie działa albo nie otrzymuje właściwego identyfikatora. Jeżeli pojawia się update, ale po chwili tworzony jest następny rekord, możliwy jest konflikt reguł, opóźnienie synchronizacji lub ponowne przetwarzanie tego samego komunikatu.

Trzeba również uwzględnić idempotencję. Operacja idempotentna daje ten sam stan po jednokrotnym i wielokrotnym wykonaniu z tym samym identyfikatorem żądania. Jeżeli integracja ponawia żądanie po błędzie sieciowym, a system docelowy nie rozpoznaje, że pierwsze żądanie zostało już przyjęte, może utworzyć drugi rekord. Kontrola powinna obejmować identyfikatory żądań, kody odpowiedzi, ponowienia, opóźnienia między systemami oraz przypadki częściowego wykonania operacji.

Porządkowanie danych i zabezpieczenie kolejnych importów

Naprawa wymaga najpierw ustalenia systemu nadrzędnego, a następnie przygotowania reguł dopasowania i scalania. Przed usunięciem lub połączeniem rekordów należy zachować mapę starych identyfikatorów, wybrać rekord kanoniczny oraz określić, które pola mają zostać zachowane. Trzeba uważać na historię aktywności, zgody komunikacyjne, przynależność do list i znaczniki używane przez automatyzacje. Mechaniczne skasowanie jednego z duplikatów może przerwać odwołania zapisane w innych tabelach lub procesach.

Po uporządkowaniu danych integracja powinna zapisywać identyfikator rekordu źródłowego w systemie docelowym, sprawdzać jego obecność przed utworzeniem nowego wpisu i stosować jednoznaczną politykę aktualizacji. Warto dodać raport wykrywający powtórzenia według identyfikatora, znormalizowanego adresu e-mail oraz innych ustalonych pól. Każda zmiana mapowania powinna być rejestrowana, aby można było odtworzyć kolejność zdarzeń. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów stacjonarnych PC i podzespołów, dlatego przy problemach z lokalnym stanowiskiem pracy można rozpocząć diagnostykę od sprawdzenia systemu, połączenia sieciowego, przeglądarki oraz aplikacji używanych do obsługi synchronizacji.

Jeżeli duplikaty pojawiają się mimo poprawnego identyfikatora, należy sprawdzić wersję konektora, konfigurację zadań cyklicznych, równoległe procesy importu oraz ręczne mechanizmy eksportu i ponownego wgrywania plików. Szczególne znaczenie ma test na kopii danych: ten sam rekord powinien zostać utworzony tylko raz, jego ponowne przesłanie powinno wykonać aktualizację, a zmiana danych w systemie nadrzędnym powinna zostać przekazana bez tworzenia nowego kontaktu. Dopiero po takim sprawdzeniu można uznać, że przepływ danych jest spójny.