wysyłka do użytkowników po wypisie

Wysyłka do użytkowników po wypisie to naruszenie, gdy system nadal wysyła korespondencję mimo rezygnacji.

Co oznacza wysyłka po wypisie z listy użytkowników

Wysyłka do użytkowników po wypisie występuje wtedy, gdy system nadal kieruje wiadomości do osoby, która została usunięta z danej subskrypcji, listy odbiorców albo cyklu komunikacji. Technicznie nie musi to oznaczać jednego błędu w formularzu rezygnacji. Przyczyną może być rozdzielenie kilku mechanizmów: bazy kontaktów, kolejki zadań, harmonogramu kampanii, modułu wysyłającego oraz lokalnej pamięci podręcznej. Jeżeli wypis zmienia tylko rekord kontaktu, ale nie anuluje już utworzonego zadania wysyłkowego, wiadomość może zostać doręczona mimo poprawnego zapisania rezygnacji.

Ważne jest rozróżnienie między statusem użytkownika a konkretnym adresem wiadomości oczekującej w kolejce. Rekord może mieć status „wypisany”, podczas gdy kolejka zawiera wcześniej przygotowane zadanie z identyfikatorem odbiorcy, tematem i terminem wysyłki. Bez ponownego sprawdzenia statusu tuż przed przekazaniem wiadomości do serwera SMTP albo usługi API zadanie zostanie wykonane według stanu z chwili jego utworzenia. Dlatego sam widok potwierdzenia wypisu w panelu administracyjnym nie dowodzi jeszcze, że wszystkie ścieżki dostarczania zostały zatrzymane.

Przepływ danych od rezygnacji do zablokowania wiadomości

Poprawny przepływ powinien rozpoczynać się od jednoznacznego zdarzenia, na przykład unsubscribe, zapisanego razem z identyfikatorem użytkownika, adresem odbiorcy, źródłem żądania i czasem operacji. Następnie moduł odpowiedzialny za segmentację powinien wykluczyć ten kontakt z nowych kampanii. Osobny mechanizm powinien oznaczyć adres na liście blokad wysyłkowych, a proces kolejki powinien sprawdzać tę blokadę przed każdą próbą dostarczenia. Jeżeli aplikacja korzysta z kilku kanałów, takich jak wiadomości e-mail, SMS i powiadomienia w aplikacji, wypis powinien mieć jasno określony zakres, aby nie pozostawić aktywnej alternatywnej ścieżki.

Problemy pojawiają się często przy niespójnych identyfikatorach. Formularz może zapisywać wypis dla adresu w postaci znormalizowanej, na przykład małymi literami i bez końcowych spacji, natomiast kolejka może przechowywać adres w pierwotnej postaci. Jeszcze inny moduł może posługiwać się identyfikatorem rekordu z systemu CRM. Jeżeli porównanie odbywa się raz po adresie, a raz po identyfikatorze, blokada może nie zadziałać. Diagnostyka powinna więc porównać dokładną wartość odbiorcy w zdarzeniu wypisu, rekordzie subskrypcji, zadaniu kolejki i logu wysyłki.

Nie wystarczy także usunięcie kontaktu z bieżącej kampanii. System może ponownie dodać go do listy podczas synchronizacji z formularzem, importu pliku albo zadania cyklicznego. Bez trwałego znacznika rezygnacji proces synchronizujący może potraktować brak rekordu jako zgodę na utworzenie nowego wpisu. Bezpieczniejszy model przechowuje stan wypisu niezależnie od tego, czy kontakt jest obecnie aktywnym członkiem konkretnej listy.

Logi, kolejki i test pozwalający odtworzyć błąd

Analiza powinna objąć pełny łańcuch zdarzeń, a nie tylko komunikat o wysłaniu wiadomości. W logach należy znaleźć czas rezygnacji, identyfikator użytkownika, adres odbiorcy, identyfikator kampanii, identyfikator zadania kolejki oraz wynik próby dostarczenia. Istotne jest porównanie znaczników czasu: utworzenia zadania, wypisu, pobrania zadania przez worker, wykonania kontroli blokady i przekazania wiadomości do zewnętrznego dostawcy. Jeżeli zadanie pobrano przed wypisem, ale wysłano po nim, worker powinien je odrzucić albo oznaczyć jako anulowane.

Warto sprawdzić, czy mechanizm ponowień nie omija kontroli wypisu. Worker może zapisać pierwszą próbę jako nieudaną z powodu błędu sieciowego, a następnie automatycznie ponowić ją po kilku minutach. Jeżeli status blokady jest sprawdzany tylko przy tworzeniu zadania, kolejne próby będą nadal wysyłane. To samo dotyczy opóźnionych wiadomości, zadań cyklicznych i procesów uruchamianych po restarcie aplikacji. Każdy punkt wykonujący wysyłkę powinien mieć dostęp do aktualnego stanu blokady, a anulowanie powinno być idempotentne, czyli wielokrotne wykonanie tej samej operacji nie powinno tworzyć nowego aktywnego wpisu.

Test odtwarzający problem powinien używać kontrolowanego adresu testowego i obejmować co najmniej trzy przypadki: wypis przed utworzeniem kampanii, wypis po dodaniu zadania do kolejki oraz wypis po pierwszej nieudanej próbie i przed ponowieniem. Wynik należy potwierdzić w bazie, logach workera i systemie dostawcy wiadomości. Dodatkowo trzeba sprawdzić synchronizację, która wcześniej powodowała ponowne dodawanie kontaktu. Za poprawne zachowanie można uznać wyłącznie sytuację, w której nowe zadania są odrzucane, istniejące zadania są anulowane lub pomijane, a ponowienia nie przekazują wiadomości po zapisaniu wypisu.

Znaczenie spójnego zatrzymania komunikacji na komputerze

Na laptopie lub komputerze PC problem może być widoczny zarówno w aplikacji internetowej, jak i w programie pocztowym, który cyklicznie odświeża skrzynkę. Samo usunięcie wiadomości z lokalnego programu nie zatrzymuje wysyłki po stronie systemu. Trzeba ustalić, czy wiadomość została faktycznie przekazana do serwera, czy tylko pozostaje w lokalnym folderze, buforze klienta albo pamięci podręcznej przeglądarki. W przypadku aplikacji działającej w przeglądarce pomocne jest sprawdzenie historii zdarzeń w panelu użytkownika oraz identyfikatora operacji, a nie wyłącznie odświeżenie strony.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, dlatego przy problemach z aplikacją komunikacyjną można rozpocząć od sprawdzenia połączenia sieciowego, daty i czasu systemowego, rozszerzeń przeglądarki oraz lokalnych programów, które filtrują lub buforują pocztę. Jeżeli logi serwera potwierdzają wysłanie po wypisie, przyczyny należy szukać w logice kolejki, synchronizacji danych lub mechanizmie ponowień, a nie w samym ekranie komputera użytkownika.

Końcowa weryfikacja powinna potwierdzić, że wypis jest zapisany trwale, nowe kampanie nie wybierają tego odbiorcy, zadania oczekujące nie są wykonywane, a procesy ponawiające respektują aktualny status. Dopiero zgodność tych czterech elementów pozwala uznać przepływ za zamknięty. Pojedynczy komunikat „rezygnacja zapisana” opisuje tylko wynik jednej operacji interfejsu i nie zastępuje kontroli całego łańcucha przetwarzania.