Przejdź do treści
Convor
Wróć do listy wpisów
Inżynieria

Dlaczego projektujemy Convor z myślą o prywatności

Z
29 maj 2026 - 2 min czytania
Dlaczego projektujemy Convor z myślą o prywatności

Produkt live chat stoi w wrażliwym miejscu. Może widzieć stronę, którą czyta odwiedzający, pytanie, które wpisał, operatora, który odpowiedział, załączony plik i notatki wewnętrzne dodane później przez zespół. Jeśli takie dane traktuje się luźno, czat przestaje być narzędziem wsparcia, a zaczyna wyglądać jak warstwa śledzenia. Nie chcemy, żeby Convor poszedł w tę stronę.

Domyślnie zbieraj mniej

Najwygodniejsza odpowiedź produktowa brzmi: zbierzmy wszystko, później się uporządkuje. To wygodne dla dashboardów i złe dla zaufania. Operatorzy potrzebują informacji, które pomagają: aktualnej strony, ostatnich wiadomości, podanych danych kontaktowych, przydatnych tagów i czasem krótkiej historii przejść. Nie potrzebują każdego sygnału z przeglądarki zapisanego na zawsze. System powinien ułatwiać sensowną ścieżkę i utrudniać przesadną.

Convor utrzymuje ciągłość wizyty przez techniczny rekord odwiedzającego i odcisk przeglądarki, zamiast traktować adres IP jak tożsamość klienta. Gdy ktoś poda e-mail albo wypełni formularz przed rozmową, to staje się jawnym kontekstem. Wcześniej produkt powinien ostrożnie podchodzić do tego, co rzekomo wie o osobie.

Granice tenantów nie mogą żyć tylko w UI

Każda rozmowa, wiadomość, osoba odwiedzająca, webhook, upload i ustawienie należy do organizacji. Panel powinien pokazywać tylko bieżącą organizację, ale serwer musi egzekwować tę samą zasadę. Kanały realtime też muszą być zawężone. Wysyłka webhooków również. Prywatność w multi-tenant SaaS zależy od nudnych kontroli powtarzanych we właściwych miejscach.

Procesy RODO muszą być używalne

Eksport wymagający ręcznego SQL-a nie jest prawdziwą funkcją eksportu. Usunięcie danych, które zostawia pliki albo kontekst odwiedzającego, nie jest prawdziwym usunięciem. Convor ma osobne endpointy i serwisy do dostępu, eksportu, usuwania oraz danych odwiedzających, bo takie prośby przychodzą pod presją czasu. Zespół nie powinien wymyślać procesu dopiero wtedy, gdy klient już czeka.

Logi audytowe są częścią tej samej historii. Administratorzy muszą wiedzieć, kto zmienił ustawienie bezpieczeństwa, wyeksportował dane, usunął rekord albo zmodyfikował webhook. Bez takiego śladu kontrolom prywatności trudno ufać, a po fakcie jeszcze trudniej cokolwiek wyjaśnić.

Retencja to nie jedno ustawienie

Transkrypt, upload, sygnał pisania, log audytowy i agregat analityczny nie powinny mieć tego samego czasu życia. Część rekordów jest historią klienta. Część jest tymczasowa. Część potrzebuje joba czyszczącego. Część może jeszcze istnieć w backupach. Traktowanie wszystkich danych tak samo jest prostsze w kodzie i gorsze w utrzymaniu.

Dla klientów privacy-first nie powinno oznaczać brakujących funkcji. Operatorzy nadal dostają użyteczny kontekst. Administratorzy dostają kontrolę i audyt. Odwiedzający może zadać pytanie bez zakładania konta. O taki balans chodzi: dość danych, żeby pomóc człowiekowi, ale nie tyle, żeby po cichu budować jego profil.

Nowe wpisy na Twoją skrzynkę

Bez spamu. Wypisz się w dowolnej chwili.