przetwarzanie danych po wypisie

Przetwarzanie danych po wypisie to naruszenie, gdy system nadal wysyła korespondencję mimo cofniętej zgody.

Jak powstaje przetwarzanie danych po wypisie

Przetwarzanie danych po wypisie w systemie komputerowym oznacza sytuację, w której rekord użytkownika nadal uczestniczy w określonym przepływie danych, mimo że powinien zostać z niego usunięty albo oznaczony jako nieaktywny. W praktyce może dotyczyć aplikacji wysyłającej wiadomości e-mail, systemu obsługi zgłoszeń, modułu powiadomień SMS, programu CRM albo lokalnej książki adresowej. Samo wycofanie zgody w formularzu nie zawsze zatrzymuje już uruchomione zadania. Konieczne jest jeszcze sprawdzenie, czy zmiana została zapisana w głównej bazie, przekazana do kolejki wysyłkowej i uwzględniona przez proces wykonujący wysyłkę.

Typowy przepływ obejmuje kilka elementów: formularz lub panel użytkownika, usługę API, bazę danych, kolejkę komunikatów oraz program wysyłający korespondencję. Jeżeli formularz zmieni pole consent na false, ale kolejka zawiera już przygotowaną wiadomość z wcześniejszym statusem, proces wysyłkowy może ją nadal pobrać. Podobny problem występuje wtedy, gdy aplikacja korzysta z lokalnego cache, repliki odczytowej albo osobnej tabeli subskrybentów, która nie została zaktualizowana razem z profilem użytkownika.

Kontrola stanu zgody w bazie i kolejce wiadomości

Podstawowym miejscem diagnostyki jest porównanie czasu cofnięcia zgody z czasem utworzenia, zakolejkowania i wysłania wiadomości. W rekordzie użytkownika powinny być rozróżnione co najmniej: aktualny stan zgody, moment ostatniej zmiany, źródło zmiany oraz identyfikator konta lub adresu. W tabeli kolejki przydatne są pola takie jak identyfikator odbiorcy, typ komunikatu, status, czas utworzenia, czas planowanej wysyłki i liczba prób. Pozwala to ustalić, czy wiadomość została dodana przed zmianą ustawienia, czy też aplikacja ponownie aktywowała odbiorcę wskutek błędnej synchronizacji.

Bezpieczny proces wysyłkowy powinien sprawdzać aktualny stan odbiorcy tuż przed przekazaniem wiadomości do serwera pocztowego lub bramki SMS. Sam filtr wykonany podczas tworzenia kampanii jest niewystarczający, ponieważ między wyborem odbiorców a wysyłką może nastąpić zmiana ustawień. Mechanizm anulowania powinien zmieniać status oczekującego zadania, a worker powinien odrzucać zadania oznaczone jako anulowane lub należące do odbiorcy bez aktywnej zgody. Ważne jest także stosowanie transakcji albo wersjonowania rekordu, aby późniejsza synchronizacja nie nadpisała nowszego cofnięcia zgody starszą kopią danych.

Ślady techniczne potrzebne do odtworzenia zdarzenia

Analiza takiego przypadku wymaga korelacji logów z kilku usług, a nie tylko sprawdzenia folderu wysłanych wiadomości. W logu aplikacji powinien pojawić się identyfikator operacji związanej z wycofaniem zgody, wynik zapisu do bazy oraz informacja o unieważnieniu zadań w kolejce. Proces wysyłający powinien rejestrować pobranie zadania, wynik ponownej kontroli statusu odbiorcy i decyzję o wysłaniu albo pominięciu komunikatu. Przydatne są również znaczniki czasu zapisane w jednej strefie, identyfikator wersji rekordu oraz identyfikator wiadomości nadany przez system pocztowy.

Brak odpowiednich logów utrudnia rozróżnienie kilku różnych usterek. Wiadomość mogła zostać wysłana przez drugi proces działający równolegle, przez opóźnioną kolejkę albo przez klienta pocztowego korzystającego z lokalnie zapisanej kopii. Należy więc sprawdzić harmonogramy zadań, liczbę aktywnych workerów, opóźnienia kolejki, retry po błędach sieciowych oraz ewentualne duplikaty konfiguracji. W systemach wieloprocesowych istotne jest, aby operacja anulowania była idempotentna: wielokrotne wykonanie powinno prowadzić do tego samego stanu, bez ponownego oznaczania odbiorcy jako aktywnego. Test powinien obejmować cofnięcie zgody przed utworzeniem wiadomości, po jej utworzeniu oraz w chwili, gdy worker oczekuje na wysyłkę.

Sprawdzenie stanowiska i konfiguracji aplikacji pocztowej

Na laptopie lub komputerze PC warto ustalić, czy korespondencja rzeczywiście pochodzi z centralnego systemu, czy została wygenerowana lokalnie przez program, skrypt lub zadanie harmonogramu. Można sprawdzić nagłówki wiadomości, adres nadawcy, identyfikatory śledzenia oraz historię zadań w aplikacji. Jeżeli wiadomość jest tworzona lokalnie, diagnostyka powinna objąć konfigurację klienta pocztowego, zapisane reguły automatyzacji, dodatki, skrypty startowe i lokalne pliki kolejki. Nie należy usuwać danych przed zabezpieczeniem kopii logów i konfiguracji, ponieważ utrudni to ustalenie kolejności zdarzeń.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, a w przypadku problemu z lokalnym środowiskiem może sprawdzić działanie systemu, aplikacji pocztowej, harmonogramu zadań oraz połączenia sieciowego. Przy zgłoszeniu warto przekazać dokładny czas otrzymania wiadomości, adres nadawcy, informację o momencie wycofania ustawienia oraz zrzut lub eksport nagłówków. Takie dane pozwalają oddzielić awarię komputera użytkownika od błędu w centralnej kolejce, synchronizacji bazy albo procesie odpowiedzialnym za wysyłkę.