różnice w definicji zgody

Różnice w definicji zgody między systemami mogą prowadzić do niespójnego traktowania tego samego kontaktu.

Jak systemy rozumieją zgodę kontaktu

Różnice w definicji zgody pojawiają się wtedy, gdy dwa programy zapisują podobną informację, ale przypisują jej inne znaczenie techniczne. W jednym systemie zgoda może oznaczać samo zaznaczenie pola w formularzu. W innym będzie uznana dopiero po wysłaniu formularza, potwierdzeniu adresu e-mail albo zapisaniu odpowiedniej wersji komunikatu, na który użytkownik się zgodził. Dlatego ten sam kontakt może mieć status „aktywny” w systemie marketingowym, „niezweryfikowany” w CRM i „brak zgody” w narzędziu wysyłkowym.

Znaczenie ma również zakres zgody. Program może przechowywać jedną wartość typu true/false, czyli informację, że zgoda istnieje albo jej nie ma. Bardziej rozbudowana aplikacja zapisuje osobne zgody dla różnych kanałów, takich jak e-mail, telefon, wiadomości SMS lub powiadomienia w aplikacji. Może też rozróżniać zgodę na kontakt handlowy, zgodę na newsletter oraz zgodę na przekazanie danych innemu systemowi. Jeżeli podczas integracji wszystkie te informacje zostaną połączone w jedno pole, część danych zostanie utracona, a wynik synchronizacji będzie niejednoznaczny.

Pola, statusy i daty wpływające na synchronizację

Systemy różnią się także sposobem zapisu statusu. Jedna aplikacja używa wartości „yes” i „no”, druga wartości logicznych true oraz false, a trzecia kilku stanów: „pending”, „granted”, „revoked” i „unknown”. Wartość pusta może oznaczać brak zgody, brak danych, błąd importu albo brak pytania o zgodę. Nie wolno automatycznie traktować pustego pola jako odmowy lub akceptacji bez sprawdzenia dokumentacji konkretnego programu i mapowania pól w integracji.

Istotne są również identyfikator zgody, czas jej udzielenia, źródło oraz wersja formularza. Jeżeli formularz został zmieniony, system może zapisać nową zgodę jako osobne zdarzenie, podczas gdy starszy CRM nadpisze tylko bieżący status. Problemy powoduje także różna interpretacja daty: jeden program zapisuje czas w UTC, a drugi w lokalnej strefie czasowej. W efekcie wpis wykonany wieczorem w Warszawie może zostać wyświetlony w innym dniu w systemie działającym według czasu UTC. Przy analizie trzeba porównać nazwę pola, typ danych, dozwolone wartości, identyfikator kontaktu, strefę czasową oraz regułę aktualizacji.

Przepływ zgody między formularzem a aplikacją

Typowy przepływ rozpoczyna się w formularzu na stronie internetowej. Po zaznaczeniu pola przeglądarka wysyła dane do aplikacji, która waliduje żądanie i zapisuje rekord kontaktu. Następnie integracja może przekazać dane do CRM, systemu newsletterowego albo programu do obsługi zgłoszeń. Każdy z tych etapów może zmienić nazwę statusu, pominąć nieobsługiwane pole lub zastosować własną regułę domyślną. Jeżeli transmisja nie zawiera informacji o zakresie zgody, odbiorca może przypisać otrzymaną wartość do niewłaściwego celu.

W praktyce warto śledzić całą ścieżkę konkretnego rekordu: identyfikator formularza, czas wysłania, odpowiedź serwera, identyfikator kontaktu w systemie pośrednim oraz wynik zapisu w systemie docelowym. Należy sprawdzić, czy ponowna synchronizacja tworzy nowy rekord, czy aktualizuje istniejący, oraz czy odmowa ma pierwszeństwo przed wcześniejszą zgodą. Ważne jest też rozróżnienie stanu bieżącego od historii zdarzeń. Pole „zgoda = tak” opisuje aktualny status, ale nie wyjaśnia, kiedy został nadany ani czy wcześniej odnotowano jego cofnięcie. Do diagnozy przydatne są dzienniki aplikacji, identyfikatory żądań HTTP, odpowiedzi API oraz historia zmian w bazie danych, o ile dany program ją przechowuje.

Weryfikacja konfiguracji na laptopie i komputerze PC

Na komputerze użytkownika można rozpocząć od sprawdzenia konfiguracji formularza, wtyczki lub aplikacji obsługującej kontakt. Należy porównać etykietę pola z nazwą przekazywaną w żądaniu sieciowym oraz sprawdzić, czy przeglądarka wysyła wartość dla każdego rodzaju zgody. W narzędziach deweloperskich przeglądarki można przeanalizować zakładkę Network i zobaczyć adres żądania, metodę HTTP, przesyłane pola oraz kod odpowiedzi. Jeżeli problem występuje tylko na jednym laptopie, trzeba dodatkowo zweryfikować wersję przeglądarki, rozszerzenia blokujące skrypty, ustawienia plików cookie i błędy JavaScript w konsoli.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich podzespołów, a przy problemach z formularzem może pomóc sprawdzić lokalne przyczyny niespójnego działania aplikacji. Diagnostyka powinna jednak rozdzielać awarię komputera od błędu konfiguracji po stronie serwera lub integracji. Jeżeli żądanie z urządzenia jest poprawne, a system docelowy zapisuje inny status, przyczyny należy szukać w mapowaniu pól, regułach synchronizacji, autoryzacji API albo sposobie interpretacji wartości przez konkretny program. Zapisanie wyników testu dla tego samego kontaktu w każdym etapie pozwala ustalić, w którym miejscu definicja zgody ulega zmianie.