niespójność między CRM a bazą e-mail

Niespójność między CRM a bazą e-mail objawia się kierowaniem korespondencji do osób, które w CRM figurują jako wypisane.

Jak powstaje niespójność między CRM a bazą e-mail

Niespójność między systemem CRM a bazą e-mail oznacza, że oba systemy przechowują różne informacje o tym samym kontakcie. W CRM może znajdować się znacznik wskazujący rezygnację z korespondencji, natomiast platforma wysyłkowa nadal może mieć adres oznaczony jako aktywny. W efekcie kampania e-mailowa korzysta z nieaktualnego statusu i kieruje wiadomość do osoby, która została wcześniej wypisana. Sam adres e-mail nie jest wystarczającym identyfikatorem, ponieważ w bazie mogą występować duplikaty, zmiany adresów oraz rekordy utworzone przez różne formularze lub integracje.

Do rozbieżności dochodzi między innymi wtedy, gdy synchronizacja działa tylko w jednym kierunku. Przykładowo CRM przekazuje nowe kontakty do bazy e-mail, ale nie odbiera informacji o wypisaniu dokonanym w wiadomości. Inną przyczyną jest opóźniona synchronizacja, błąd żądania API, odrzucony rekord albo przerwanie kolejki zdarzeń. Jeżeli systemy używają różnych pól, takich jak newsletter_status, subscribed i marketing_opt_in, integracja może również niepoprawnie mapować wartości logiczne. Szczególnej uwagi wymagają wartości puste, ponieważ jeden system może traktować je jako brak zgody, a drugi jako status aktywny.

Status wypisania, lista wykluczeń i identyfikacja kontaktu

W poprawnie zaprojektowanym przepływie wypisanie powinno być zapisane jako zdarzenie, a nie wyłącznie jako chwilowa zmiana widoku w panelu użytkownika. Zdarzenie może zawierać identyfikator kontaktu, adres e-mail, czas operacji, źródło zmiany oraz nową wartość statusu. Platforma wysyłkowa powinna przekazać taką informację do CRM albo udostępnić ją w mechanizmie webhooka. CRM musi następnie zaktualizować właściwy rekord, a nie utworzyć kolejny kontakt na podstawie samego adresu.

Przed wysłaniem kampanii system powinien sprawdzić zarówno status główny kontaktu, jak i listę globalnych wykluczeń. Lista wykluczeń, nazywana również suppression list, przechowuje adresy, do których wiadomości nie powinny być kierowane z powodu wypisania, wcześniejszego odrzucenia albo trwałego błędu dostarczenia. Usunięcie adresu z jednej listy nie powinno automatycznie oznaczać ponownego zapisu do wszystkich kampanii. Warto także rozróżniać wypisanie z konkretnego rodzaju komunikacji od całkowitego wyłączenia korespondencji. Błędne sprowadzenie tych stanów do jednej wartości typu „aktywny” lub „nieaktywny” może powodować niezamierzone wznowienie wysyłki.

Ślady techniczne potrzebne do znalezienia rozbieżności

Diagnozę należy rozpocząć od porównania tego samego kontaktu w obu systemach. Trzeba sprawdzić identyfikator rekordu, znormalizowany adres e-mail, status subskrypcji, datę ostatniej zmiany oraz źródło aktualizacji. Adresy powinny być porównywane po usunięciu przypadkowych spacji i z uwzględnieniem reguł używanych przez konkretny system dla wielkości liter. Nie wolno jednak zakładać, że dwa rekordy o tym samym adresie są zawsze tym samym kontaktem, jeżeli integracja opiera się na wewnętrznym identyfikatorze.

W logach integracji należy wyszukać żądanie wysłane po wypisaniu oraz odpowiedź systemu odbiorczego. Istotne są kody HTTP, treść błędu, czas wykonania, identyfikator operacji i liczba ponowień. Kod 2xx zwykle oznacza przyjęcie żądania na poziomie protokołu HTTP, ale nie gwarantuje poprawnego przetworzenia każdej wartości biznesowej. Kod 4xx może wskazywać nieprawidłowe dane lub brak uprawnień, a kod 5xx — problem po stronie usługi odbiorczej. Jeżeli używana jest kolejka, trzeba dodatkowo sprawdzić, czy komunikat nie trafił do kolejki błędów, nie został przetworzony dwukrotnie albo nie utracił kolejności. Bez tych danych można stwierdzić rozbieżność, lecz nie da się rzetelnie wskazać jej miejsca powstania.

Naprawa przepływu danych i kontrola przed wysyłką

Usunięcie problemu wymaga ustalenia jednego źródła prawdy dla statusu korespondencji oraz opisania reguł synchronizacji. Każda zmiana wypisania powinna być przekazywana w sposób powtarzalny, z możliwością ponowienia operacji bez tworzenia duplikatu. Taki mechanizm nazywa się idempotencją: ponowne przetworzenie tego samego zdarzenia nie powinno zmienić wyniku ani przywrócić kontaktu do aktywnej wysyłki. Przydatne są także okresowe raporty porównujące liczbę i statusy rekordów oraz alerty dla zdarzeń odrzuconych przez API.

Przed uruchomieniem kampanii warto wykonać kontrolę listy odbiorców: porównać ją z aktualną listą wykluczeń, wykryć duplikaty, sprawdzić brakujące identyfikatory i przeanalizować kontakty zmienione w ostatnim okresie. Test powinien obejmować wypisanie wykonane w CRM, wypisanie wykonane z wiadomości e-mail, ponowną synchronizację oraz próbę utworzenia kontaktu z istniejącym adresem. W środowisku lokalnym problem może dodatkowo wynikać z nieaktualnej konfiguracji integracji, błędnego adresu endpointu, wygasłego klucza API albo procesu synchronizacji uruchomionego w innej wersji aplikacji. Diagnostyka laptopa lub komputera PC może wtedy obejmować sprawdzenie klienta pocztowego, przeglądarki, zapisanych sesji, logów aplikacji i połączenia sieciowego, bez utożsamiania lokalnego urządzenia z właściwym źródłem danych.