Rejestr czynności przetwarzania (art. 30 RODO)

1. Jak czytać ten rejestr

To wewnętrzny dokument rozliczalności zgodnie z art. 30 RODO. Nie jest to polityka prywatności, nie powstał w celu informowania osób, których dane dotyczą, choć jest opublikowany, i nie został napisany po to, żeby dobrze wyglądać. Jego jedynym zadaniem jest umożliwić organowi nadzorczemu — albo następnej osobie, która będzie musiała odpowiedzieć na pytanie — zobaczyć, co faktycznie jest przetwarzane, gdzie to leży i jak długo tam zostaje.

Redakcję tego dokumentu określiły trzy zasady. Pierwsza: stwierdzenie pada tylko tam, gdzie popiera je kod, schemat albo pomiar. Tam, gdzie brakuje danej, lukę oznacza symbol zastępczy, a nie zdanie brzmiące wiarygodnie. Uczciwa luka przetrwa kontrolę; dobrze sformułowane przypuszczenie nie. Druga: tam, gdzie kod dokumentuje własne uzasadnienie, uzasadnienie to jest cytowane wraz z plikiem i numerem wiersza, żeby późniejszy czytelnik mógł je sprawdzić, zamiast ufać temu dokumentowi. Trzecia: okresy przechowywania podano dwukrotnie — raz dla tabel objętych codziennym usuwaniem, raz dla tabel, których ono nie obejmuje. Rejestr, który podaje termin usunięcia obowiązujący dla połowy tabel, jest gorszy od takiego, który nazywa lukę, ponieważ to właśnie luka zostaje sprawdzona.

2. Podmiot i dlaczego ten rejestr ma dwie części

Pole	Wpis
Podmiot prawny	LW IT Solutions Company Lukas Wójcik
Adres	al. Tadeusza Kościuszki 80/82 lok. 301, 90-437 Łódź, Polska
Identyfikacja podatkowa	NIP: PL7252266190
Kontakt	office@mouseplayer.com (nie opublikowano numeru telefonu)
Produkt	MousePlayer — odtwarzanie sesji (session replay), mapy ciepła, analityka behawioralna
Przedstawiciel w rozumieniu art. 27	Nie dotyczy. Podmiot ma jednostkę organizacyjną w Unii (Polska).
Inspektor ochrony danych	Nie wyznaczono. Ocena według art. 37 znajduje się w rozdziale 9.

MousePlayer zajmuje dwie różne pozycje wobec dwóch różnych grup osób, a ich pomieszanie daje rejestr bezwartościowy dla obu. Wobec danych ODWIEDZAJĄCYCH strony klientów MousePlayer jest podmiotem przetwarzającym, a klient administratorem — stosuje się art. 30 ust. 2. Wobec danych własnych KLIENTÓW MousePlayera (konta, rozliczenia, wsparcie, dzienniki dostępu do panelu) administratorem jest MousePlayer — stosuje się art. 30 ust. 1.

To nie jest wygoda redakcyjna. Rozróżnienie jest już wdrożone w kodzie i niesie dla każdej z części inną konsekwencję techniczną: class/Server.class.php:416 stwierdza „REGEL B ... Hier sind wir AUFTRAGSVERARBEITER”, a wiersze 421-425 oddzielają „Regel A (volle Adresse) fuer DIREKTE Zugriffe auf die eigene Anwendung” od reguły B (adres skrócony) dla danych odwiedzających. Adres IP odwiedzającego jest skracany w class/Server.class.php:432-435; adres IP użytkownika-klienta zapisywany jest w całości. System zachowuje się więc już tak, jakby ten rejestr istniał.

• Część A (rozdział 3) — art. 30 ust. 2: dwadzieścia dwie czynności przetwarzania (A.1–A.22) wykonywane w imieniu administratorów.
• Część B (rozdział 5) — art. 30 ust. 1: osiem czynności przetwarzania (B.1–B.8) wykonywanych na własną odpowiedzialność MousePlayera.
• Rozdziały od 6 do 8 są wspólne dla obu części: przechowywanie, zautomatyzowane podejmowanie decyzji oraz ogólny opis środków technicznych i organizacyjnych.
• Rozdział 10 wymienia luki, których istnienie zostało wykazane. Rejestr jest narzędziem pracy, a nie certyfikatem.

3. Część A — art. 30 ust. 2: czynności wykonywane w imieniu administratorów

A.0 Strony

Pole	Wpis
Podmiot przetwarzający	LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82 lok. 301, 90-437 Łódź, Polska. office@mouseplayer.com
Administratorzy	Klienci prowadzący strony internetowe, na których zainstalowano tag MousePlayera (www/mp.js). Każdy administrator jest identyfikowany w systemie przez projects.channelid; dane kontaktowe znajdują się w users i workspaces, przynależność i rola w workspace_users. Zmierzone na instancji deweloperskiej: 7 projektów, 4 konta klientów, role 4 owner / 1 admin / 1 viewer.
Miarodajna lista administratorów	Prowadzona w systemie, nie powielana tutaj. Lista jest generowana, nie przepisywana: w panelu administracyjnym pod „Records of Processing (Art. 30)” przycisk tworzy ją na żądanie jako CSV — dla każdego obszaru roboczego właściciel wraz z nazwiskiem, adresem e-mail, firmą, adresem, numerem VAT, planem i objętymi domenami. Odpowiedzialny za pobranie: Lukas Wójcik, właściciel; pobierana jest przy każdym przeglądzie tego rejestru, czyli corocznie i przy każdej zmianie przetwarzania. Każde pobranie trafia do dziennika zmian (export_controllers). Lista przepisana tutaj byłaby drugim miejscem dla tej samej prawdy i dezaktualizowałaby się z każdym nowym klientem, a nikt by tego nie zauważył. (decyzja administratora, 17.08.2026)
Przedstawiciel podmiotu przetwarzającego	Nie dotyczy (jednostka organizacyjna w Polsce).
Inspektor ochrony danych	Nie wyznaczono — zob. rozdział 9.
Środki techniczne i organizacyjne	Rozdział 8 dotyczy każdej czynności w części A i nie jest powtarzany przy poszczególnych czynnościach.

A.1 Odtwarzanie sesji — rejestrowanie zdarzeń behawioralnych

Pole	Wpis
Pochodzenie zdarzeń	Dwie drogi. (1) Przeglądarka odwiedzającego przez www/mp.js — tam automat stanów mpEinw technicznie egzekwuje zgodę. mp.js przesyła dane przez HTTPS do nginx, gdzie kończy się TLS: standardowo przez WebSocket pod /mp_wss/; jeśli połączenie WebSocket nigdy nie dochodzi do skutku, od 11.10.2026 r. przez tunel HTTP pod /mp_wst, do którego stosują się te same kontrole serwera WebSocket (zgoda, wykrywanie botów, pochodzenie, limit); duże zrzuty stron od 07.10.2026 r. jako przesyłanie HTTP pod /mp_dom z podpisanym, ograniczonym czasowo dostępem (przechowywane do 120 sekund w Redis, następnie przetwarzane jak zwykły zrzut). Punkt pomiarowy /mp_wsfail zlicza wyłącznie nieudane połączenia WebSocket według projektu, przyczyny, rodziny przeglądarki i rodzaju urządzenia, bez identyfikatora odwiedzającego; adres IP jest tam jedynie haszowany i przechowywany najwyżej godzinę w celu eliminacji powtórzeń. (2) Po stronie serwera przez www/api/capi_ingest.php z systemu klienta; ta droga wymaga podpisu (HMAC-SHA256 nad znacznikiem czasu i treścią, okno pięciu minut) oraz wyraźnego oświadczenia przy każdym przekazaniu, że zgoda istnieje — bez niego żądanie jest odrzucane z kodem 403. MousePlayer nie może technicznie zweryfikować zgody na tej drodze; zapewnia ją klient jako administrator (umowa powierzenia, rozdział 2). Drogę można włączać i wyłączać przez site_settings.capi_ingest_aktiv; była wyłączona do 18.08.2026 r. i od tego czasu jest włączona. Ponadto istnieje wersja zapoznawcza natywnego SDK aplikacji (Android) z własną drogą przyjmowania danych (www/api/native_ingest.php, tabele mp_native_apps i mp_native_sessions); występuje wyłącznie w systemie deweloperskim i jest wyłączona (native_preview_enabled = 0; stan na 16.10.2026: brak zapisanej sesji).
Cel	Rejestrowanie zachowania odwiedzających na stronach klientów — ruch myszy, kliknięcia, przewijanie, dotknięcia, zmiany kart — aby klient mógł odtworzyć i przeanalizować sesję.
Kategorie osób, których dane dotyczą	Odwiedzający strony internetowe klientów MousePlayera.
Kategorie danych osobowych	Współrzędne ruchu, przesunięcie czasowe, pozycja przewijania, wysokość dokumentu; rodzaj zdarzenia; wymiary okna przeglądarki i ekranu; identyfikatory sesji i odsłony. Zmierzony rozkład zdarzeń: move 100934, mutation 66153, scroll 28214, tab_focus 6185, resize 2590, screen_info 2034, pageview 2031, click 1863, input 599, input_mode 425, k 407, tap 401. W visitor_sessions ponadto: referrer, parametry UTM, identyfikator kliknięcia sieci reklamowej wraz z typem, ścieżka wejścia, kanał pozyskania, znacznik przeglądarki wbudowanej w aplikację, identyfikator przeglądarki (user agent), znacznik bota wraz z powodem, jakość sesji oraz od 26.09.2026 r. wskaźnik tarcia wraz z powodami (friction_score, friction_gruende). Powyższy rozkład zdarzeń zmierzono 10.08.2026 r.
Miejsce przechowywania	mouse_events (event_id, pageview_id, event_type, time_offset_ms, x, y, scroll_y, scroll_x, doc_height, target_selector) — 225892 wiersze, 322,6 MB, największa tabela w schemacie. session_pageviews (pageview_id, session_id, tab_id, url, viewport_width, viewport_height, start_time, start_time_ms, end_time, page_title). visitor_sessions (session_id, channelid, screen_width, screen_height, start_time, end_time, duration_seconds, is_active, device_type). mouse_events_analytik (id, erfasst_am, pageview_id, channelid, event_type, time_offset_ms, x, y, target_selector) — 11812 wierszy: odchudzona kopia zdarzeń KLIKNIĘĆ i kontekstu, z której czyta warstwa kliknięć mapy ciepła. Wskazana jest osobno, ponieważ ma inny okres przechowywania niż mouse_events — te po 7 dniach trafiają do archiwum, kopia zostaje i dlatego niesie mapę kliknięć przez całą historię. Z niej co noc powstaje agregat dzienny, mp_hm_klick_tag wraz z mp_hm_ansicht_tag (od 07.10.2026): dla każdego dnia, adresu, typu urządzenia, klasy ekranu, celu i komórki 8 px tylko liczba, bez sesji, identyfikatora odwiedzającego ani odsłony. Mapa kliknięć korzysta z niego dla dni, których sesje już nie istnieją. Usunięcie pojedynczych sesji lub osób go nie dotyczy, ponieważ żadnego wiersza nie da się przypisać osobie. Od października 2026 r. ponadto mp_aufnahme_quittung: dla każdej przychodzącej wiadomości identyfikator i status; dla wiadomości, której nie da się przetworzyć, dodatkowo jej surowa treść i przyczyna. Wiersze są usuwane po 7 dniach (srv/db_worker.php). Liczby wierszy w tym wpisie bez daty: stan na 10.08.2026.
Podstawa prawna (określa ją administrator)	Zgoda. Uzasadnienie w ai/migrations/018_consent.sql: rejestrowanie jest obserwacją zachowania (motyw 24 RODO) i dostępem do urządzenia końcowego (par. 25 TDDDG); wymaga zgody, a prawnie uzasadniony interes jej nie uniesie. Wszystkie 7 projektów ma ustawienie projects.consent_mode='required'. Egzekwowanie po stronie serwera: class/Server.class.php:977-1004; wyłącznik awaryjny site_settings.consent_gate_active=1.
Kategorie odbiorców	(a) Dany klient — członkowie przestrzeni roboczej z rolą owner, admin lub viewer. (b) Każdy posiadacz linku udostępniającego, BEZ logowania: /s/<40-znakowy token hex> prowadzi do player.php?share=..., tabela session_shares. (c) Opcjonalnie klient przez REST API v1 z własnym kluczem API, wyłącznie w planie płatnym; stan na 16.10.2026: brak klucza API. (d) Opcjonalnie agenci AI klienta przez serwer MCP (/mcp): dostęp tylko do odczytu kluczem odczytu REST API, odrębnie włączany dla każdego projektu (projects.mcp_active, domyślnie wyłączony); dostępne są projekty, wskaźniki, listy sesji z linkiem do odtworzenia, pojedyncze sesje z odsłonami i zdarzeniami, strony, sygnały frustracji i cele — nie zrzut strony. Stan na 16.10.2026: nie jest włączony dla żadnego projektu. (e) Klient w postaci pliku: eksport CSV listy sesji i odpowiedzi na ankiety z jego interfejsu, z limitem (csv_export_max_zeilen); każdy eksport jest zapisywany w dzienniku zmian (csv_export).
Przekazanie do państwa trzeciego	Brak w ścieżce rejestrowania. Nie znaleziono żadnego wywołania wychodzącego; ustalanie lokalizacji geograficznej działa na lokalnych plikach MaxMind. Zob. rozdział 4.
Okres przechowywania	Zależnie od planu, egzekwowane przez codzienne usuwanie w srv/db_worker.php (rozdział 6.1) za pośrednictwem łańcucha usuwania mp_sitzungen_loeschen(): free 7 dni, small 30, business 90, enterprise według uzgodnionego planu (domyślnie 365). Sesje rozpoznane jako zautomatyzowane (boty) mają własne, krótsze terminy: ich nagranie (zrzut strony i zdarzenia) jest czyszczone po upływie retention_bot_recording_days (termin w dniach: 1), a wiersz sesji wraz ze wszystkim, co jest z nim powiązane, usuwany po upływie retention_bot_session_days (termin w dniach: 14); oba są konfigurowalne w panelu administracyjnym, a 0 wyłącza odrębny termin, wtedy obowiązuje termin planu. Po 7 dniach zdarzenia przechodzą z mouse_events do skompresowanych plików archiwum dla każdej sesji (srv/cron_archiv.php); dzielą termin swojej sesji, są usuwane razem z nią i od 06.10.2026 r. stanowią część codziennej kopii zapasowej (rozdział 4). Jeżeli klient usuwa projekt, przestrzeń roboczą lub konto albo zostaje uruchomione usunięcie według adresu IP lub odwiedzającego, od 07.10.2026 r. dane są najpierw archiwizowane — ukryte, bez dalszego nagrywania, możliwe do przywrócenia — i ostatecznie usuwane najpóźniej po 30 dniach (rozdział 6.2, mp_loesch_archiv).

A.2 Rejestrowanie treści strony — migawka DOM i zmiany DOM

Pole	Wpis
Cel	Rejestrowanie treści strony, aby sesję można było odtworzyć tak, jak widział ją odwiedzający.
Kategorie osób, których dane dotyczą	Odwiedzający strony klientów; a pośrednio każda osoba, której dane wyświetla własna strona klienta — na przykład potwierdzenie zamówienia z adresem pocztowym.
Kategorie danych osobowych	Pełny kod HTML odwiedzonej strony wraz z tekstem, adresami URL obrazów i metadanymi, tak jak wyświetla go przeglądarka, bez skryptów i z maskowaniem opisanym w A.3. Ponadto serializowane fragmenty HTML każdej późniejszej zmiany DOM, zapisywane w polu target_selector zdarzeń mutation. Od 30.09.2026 r. dodatkowo: zawartość otwartych shadow rootów komponentów webowych wraz z ich arkuszami stylów (zamknięte shadow rooty nie są nagrywane); elementy canvas jako obraz statyczny w zrzucie, a przy zmianie na bieżąco jako obraz (najwyżej raz na takt jednej sekundy, z limitem na odsłonę; nie w obszarach maskowanych i nie dla canvas z obrazami obcego pochodzenia); ramki iframe tego samego pochodzenia wraz z zawartością, a od 02.10.2026 r. także z obsługą w ich wnętrzu (kursor, kliknięcia, wprowadzanie, przewijanie); ramki iframe obcego pochodzenia wyłącznie jako symbol zastępczy bez zawartości.
Miejsce przechowywania	session_pageviews.payload_blob (longtext), od 14.08.2026 r. zapisywany w postaci skompresowanej (prefiks MPZ1:, gzip, Base64); stan na 16.10.2026: wszystkie wypełnione wiersze mają ten format. session_pageviews.has_recording jest zwykłą kolumną, a nie generowaną: worker ustawia ją przy zapisie zrzutu i zeruje, gdy go czyści; podobnie hat_interaktion, hat_scroll i scroll_max_y. mouse_events.target_selector przy event_type='mutation', w tym zawartość shadow rootów, canvas i ramek iframe; po 7 dniach w plikach archiwum (A.1). session_pageviews.html_path istnieje, ale według stanu na 16.10.2026 nie jest ustawiona w żadnym wierszu.
Podstawa prawna (określa ją administrator)	Zgoda, jak w A.1.
Kategorie odbiorców	Klient, przez www/player.php, www/ajax_get_events.php i www/player_theatre.php. Każdy posiadacz linku udostępniającego. NIE przez REST API — www/api/v1_session_detail.php:25 odnotowuje świadome wyłączenie pełnego payloadu odtwarzania.
Przekazanie do państwa trzeciego	Brak w ścieżce rejestrowania.
Okres przechowywania	Jak A.1: razem z sesją przez codzienne usuwanie i mp_sitzungen_loeschen(); w sesjach rozpoznanych jako boty zrzut jest czyszczony po terminie z A.1 (retention_bot_recording_days, termin w dniach: 1). Zob. rozdział 6.
Uwaga o zakresie maskowania	Maskowanie działa wyłącznie WEWNĄTRZ obszarów oznaczonych data-mp-mask albo .mp-masked (www/mp.js:3934-3970). Cały pozostały kod HTML strony jest zapisywany bez zmian. Wszystko, co wyświetla sama strona klienta, znajduje się zatem w nagraniu i żadne ustawienie maskowania tego nie obejmuje.

A.3 Rejestrowanie danych wpisywanych w formularzach

Pole	Wpis
Cel	Rejestrowanie danych wpisywanych w formularzach, znak po znaku, aby interakcję z formularzem można było odtworzyć.
Kategorie osób, których dane dotyczą	Odwiedzający strony klientów.
Kategorie danych osobowych	Wartości wpisane w elementach input, textarea i select — w pełni zamaskowane, częściowo zamaskowane albo jawne, zależnie od poziomu maskowania. Stan pól wyboru i przycisków opcji (true/false), który NIGDY nie jest maskowany (www/mp.js:4810-4811). Kategoria pola ustalona przez classifyFieldName() (www/mp.js:4657-4674): email, password, phone, payment, address, name, search, coupon, quantity, other.
Miejsce przechowywania	mouse_events.target_selector przy event_type='input', format {"t":"<data-mp-id>","v":"<wartość>"} — 599 wierszy.
Podstawa prawna (określa ją administrator)	Zgoda, jak w A.1.
Kategorie odbiorców	Klient (odtwarzacz); każdy posiadacz linku udostępniającego.
Przekazanie do państwa trzeciego	Brak w ścieżce rejestrowania.
Okres przechowywania	Brak własnego terminu; jak A.1, razem z sesją (termin planu, w przypadku botów terminy z A.1), po 7 dniach w plikach archiwum.
Obowiązujące zabezpieczenia	Twarda granica dla haseł i danych płatniczych niezależnie od poziomu (www/mp.js:4831-4837). Pełne maskowanie na poziomie 0 (www/mp.js:4818-4819). Wszystkie 7 projektów ma ustawienie projects.smart_masking=0, które mimo etykiety jest ustawieniem NAJSUROWSZYM.
Ustalenie dotyczące starego zasobu	10.08.2026 r. 173 wiersze w mouse_events zawierały NIEZAMASKOWANE dane wprowadzone tekstem jawnym z okresu od 2026-07-21 do 2026-07-27, w tym imiona i nazwiska; wiersze od tego dnia są maskowane. Stan na 16.10.2026: w mouse_events nie ma już żadnego niezamaskowanego wpisu (zmierzono tym samym zapytaniem). Dotknięte wiersze zostały usunięte 17.08.2026 r. (ocena skutków, R2), a więc przed wprowadzeniem plików archiwum 18.08.2026 r.; nie mogą zatem znajdować się w plikach archiwum ani w kopii zapasowej, która obejmuje je od 06.10.2026 r. Zaszyfrowane kopie z tamtego czasu na Google Drive usunięto 06.09.2026 r.; nie jest znana żadna nadal istniejąca kopia zapasowa sprzed 17.08.2026 r., jednak jej brak nie został szczegółowo wykazany.

A.4 Rozpoznawanie odwiedzającego pomiędzy sesjami

Pole	Wpis
Cel	Rozpoznawanie odwiedzającego pomiędzy sesjami i odsłonami.
Kategorie osób, których dane dotyczą	Odwiedzający strony klientów.
Kategorie danych osobowych	Pseudonimowy identyfikator odwiedzającego, generowany i przechowywany w localStorage odwiedzającego pod kluczem 'mp_visitor_id' (www/mp.js:5056-5059). Jawny identyfikator ustawiany przez klienta — login albo numer klienta — przez MousePlayer.setUserId() (www/mp.js:4909-4913, localStorage 'mp_user_id'), a także automatycznie ze ścieżki 'uid' w dataLayer (www/mp.js:3585-3637). Pseudonim i nazwa przeglądarki dla każdego odwiedzającego, przechowywane PONAD projektami (UNIQUE na visitor_id).
Miejsce przechowywania	visitor_sessions.visitor_id (varchar 64), custom_user_id (varchar 128, własny indeks idx_custom_user_id), nickname_key. visitor_nicknames (visitor_id, nickname_key, browser_name, city, created_at) — 329 wierszy; kolumna city jest pusta we wszystkich 329. consent_events.visitor_id.
Podstawa prawna (określa ją administrator)	Zgoda, jak w A.1.
Kategorie odbiorców	Klient. Przez custom_user_id połączenie z własnym zbiorem klientów jest wyraźnie przewidzianym zastosowaniem.
Przekazanie do państwa trzeciego	Brak w ścieżce rejestrowania.
Okres przechowywania	Wraz z ostatnią sesją odwiedzającego. mp_sitzungen_loeschen() (srv/db_worker.php) po każdym usunięciu sprawdza, czy odwiedzającemu pozostała jakakolwiek sesja, i w przeciwnym razie usuwa pseudonim; ścieżka usuwania w odtwarzaczu działa tak samo. Codzienne usuwanie według planu wywołuje tę samą funkcję — osierocony wpis nie może już powstać. Odrębny termin nie istnieje i nie jest potrzebny: wpis nigdy nie żyje dłużej niż sesje, które nazywa.

A.5 Dane sieciowe i przybliżona lokalizacja

Pole	Wpis
Cel	Ustalenie danych sieciowych i przybliżonej lokalizacji odwiedzającego oraz ustalenie regionu na potrzeby sprawdzenia zgody.
Kategorie osób, których dane dotyczą	Odwiedzający strony klientów.
Kategorie danych osobowych	Adres IP (skrócony w ścieżce rejestrowania, zob. niżej), dwuznakowy kod kraju, miasto (ustalane na podstawie adresu skróconego, nie pełnego), numer ASN i nazwa dostawcy, kod regionu.
Miejsce przechowywania	visitor_sessions.ip_address (varchar 45), country, city, asn_number, asn_org, region_code. ip_lifetime_stats (ip_address, first_seen, total_conns, total_msgs, total_traffic, total_uptime_sec) — 446 wierszy.
Podstawa prawna (określa ją administrator)	Zgoda na rejestrowanie. Ustalanie kraju wykonywane jest celowo po stronie serwera, aby przed uzyskaniem zgody nie kontaktować się z żadnym podmiotem trzecim (class/Server.class.php:941-944).
Kategorie odbiorców	Brak odbiorcy zewnętrznego. Ustalanie lokalizacji odbywa się na podstawie LOKALNYCH plików MaxMind w cfg/maxmind/ (GeoLite2-City i GeoLite2-ASN; odczytywanych w class/IP2CityLite.class.php i class/Server.class.php), które srv/geoip_update.sh regularnie pobiera z MaxMind; nie są przy tym przekazywane żadne dane odwiedzających. Ustalone wartości są zapisywane w visitor_sessions i są widoczne dla klienta jak pozostała część rekordu sesji.
Przekazanie do państwa trzeciego	Brak. W ścieżce rejestrowania nie ma wywołań wychodzących.
Skracanie	Serwer WebSocket (class/Server.class.php, reguła B) zastępuje ostatni oktet IPv4 ciągiem 'xxx', a ostatnią grupę IPv6 ciągiem ':xxxx', bezpośrednio po ustaleniu adresu połączenia (za nginx z X-Forwarded-For, uznawanego wyłącznie od lokalnego węzła), a więc przed każdym odbiorcą. Pełny adres występuje jedynie przejściowo w pamięci operacyjnej serwera WebSocket, w licznikach Redis wygasających po kilku sekundach oraz — dla adresów, które wyzwalają automatyczną blokadę — na czas trwania blokady (24 h) w Redis (mp_autoban:); instancja Redis zapisuje swoje dane na dysku w celu zapewnienia trwałości (AOF). Stan na 16.10.2026: żaden wiersz w visitor_sessions ani ip_lifetime_stats nie zawiera nieskróconego adresu.
Przechowywanie i ustalenie dotyczące starego zasobu	365 dni od first_seen dla ip_lifetime_stats, egzekwowane przez codzienny przebieg w srv/db_worker.php; wartość znajduje się w site_settings pod kluczem retention_ip_stats_days i jest konfigurowalna w panelu administracyjnym. visitor_sessions podlega usuwaniu według planu. Stary zasób został załatwiony: pomiar z 17.08.2026 wykazał 267 z 267 skróconych adresów w ip_lifetime_stats i 881 z 901 w visitor_sessions. Pozostałe 20 zawiera 0.0.0.0 i pochodzi z danych testowych analizy formularzy (s_mptest_form_) — nie są to adresy odwiedzających.

A.6 Zapisy dotyczące zgody

Pole	Wpis
Cel	Wykazanie zgody i każdej jej zmiany (art. 7 ust. 1 RODO).
Kategorie osób, których dane dotyczą	Odwiedzający strony klientów.
Kategorie danych osobowych	Stan (GRANTED, GRANTED_LATE, withdrawn, region_exempt), źródło, znacznik czasu; nazwa i wersja CMP; SHA-256 ciągu TC — celowo nie sam ciąg; sygnał GPC; kod regionu; wersja konfiguracji projektu.
Miejsce przechowywania	consent_events (id, session_id, channelid, visitor_id, consent_state, consent_source, cmp_name, cmp_version, tcf_hash, gpc_signal, region_code, consent_config_version, occurred_at, created_at) — 120 wierszy. visitor_sessions.consent_state, consent_source, consent_ts, cmp_name, cmp_version, tcf_hash, gpc_signal, region_code, consent_config_version, recording_offset_ms.
Podstawa prawna	Obowiązek wykazania, uzasadniony w ai/migrations/018_consent.sql: ciężar dowodu skutecznej zgody spoczywa na administratorze, a bez dziennika nie ma czego pokazać w sporze.
Kategorie odbiorców	Klient.
Przekazanie do państwa trzeciego	Brak.
Okres przechowywania	730 dni, licząc od wycofania zgody. Okres i punkt odniesienia znajdują się w site_settings (consent_evidence_days, consent_evidence_anchor) i są konfigurowalne w panelu administracyjnym; egzekwuje je codzienny przebieg w srv/db_worker.php. Przy usunięciu sesji dowód nadal nie jest usuwany, lecz pozbawiany powiązania z osobą: to, że decyzja zapadła, musi pozostać wykazywalne (art. 5 ust. 2), kto ją podjął — nie. Usuwane jest tylko to, do czego nie odnosi się już żadna sesja: dopóki istnieje nagranie, musi istnieć jego dowód, inaczej nagranie stałoby bez podstawy.
Jakość danych	671 z 706 sesji ma consent_source='testdata' z consent_ts IS NULL, ustawione przez ai/devdata/001_altsitzungen_markieren.sql. To NIE są prawdziwe dowody zgody. Prawdziwe zapisy: 27 (api), 5 (gcm), 2 GRANTED_LATE (api), 1 withdrawn (gcm).
Usunięcie przy wycofaniu zgody	Opcjonalne i wszędzie wyłączone: projects.consent_delete_on_withdraw=0 we wszystkich 7 projektach, oceniane w srv/db_worker.php:1067-1070. Wycofanie zgody zatrzymuje więc dalsze rejestrowanie, ale niczego nie usuwa.

A.7 Zdarzenia własne, sygnały frustracji i błędy JavaScriptu

Pole	Wpis
Cel	Rejestrowanie zdarzeń zdefiniowanych przez klienta, sygnałów frustracji i błędów JavaScriptu występujących na stronie klienta.
Kategorie osób, których dane dotyczą	Odwiedzający strony klientów.
Kategorie danych osobowych	Nazwa zdarzenia — zmierzone: dead_click 355, gtm.scrollDepth 290, rage_click 52, text_copied 26, text_selected 26, error_detected 22, consent_status 19, consented_ready 17, consented_update 8, mouse_thrashing 5, add_to_cart 3. Wartości parametrów — target 407, tag 386, desc 274, count 57, length 52, snippet 22, message 22, type 19, filename 9, lineno 9, masked_area 4, price 1, currency 1, item_id 1. Dwa z nich niosą więcej, niż sugeruje ich nazwa: 'snippet' przy text_copied i text_selected to tekst strony zaznaczony albo skopiowany przez odwiedzającego; 'filename' zawiera pełne adresy URL, a stwierdzono w nim adres moz-extension://, czyli identyfikator rozszerzenia przeglądarki charakterystyczny dla urządzenia.
Miejsce przechowywania	session_custom_events (event_id, session_id, pageview_id, event_name, created_at) — 823 wiersze. session_custom_event_params (param_id, event_id, param_key, param_string_value, param_int_value, param_float_value) — 1264 wiersze.
Podstawa prawna (określa ją administrator)	Zgoda, jak w A.1.
Kategorie odbiorców	Klient. Opcjonalnie przez webhook na adres URL swobodnie wybrany przez klienta — zob. rozdział 4.
Przekazanie do państwa trzeciego	Przez webhook miejsce docelowe jest nieokreślone, a zatem potencjalnie w państwie trzecim. Obecnie nieaktywne: projects.webhook_active=0 i webhook_url NULL we wszystkich 7 projektach.
Okres przechowywania	Razem z sesją przez codzienne usuwanie i mp_sitzungen_loeschen() (termin planu, w przypadku botów terminy z A.1); session_custom_event_params jest powiązana z session_custom_events przez FOREIGN KEY ON DELETE CASCADE. Zdarzenia konsoli, sieci i Web Vitals w mouse_events jak A.1; mp_cwv jest usuwana razem ze swoją odsłoną (czyszczenie co godzinę).
Komunikaty konsoli i żądania sieciowe (od 30.09.2026)	To, co strona zapisuje w konsoli przeglądarki (poziom ustawia operator, domyślnie: błędy i ostrzeżenia), oraz żądania strony, które kończą się niepowodzeniem lub trwają dłużej niż ustawiony próg: metoda, adres, kod statusu i czas trwania. Nigdy nagłówki ani treść żądania lub odpowiedzi, nigdy zawartość logowanych obiektów, tylko ich rodzaj. Teksty przed wysłaniem przechodzą przez filtr (adresy e-mail, adresy IP, długie ciągi cyfr, tokeny dostępu), a adresy tracą wartości parametrów o wrażliwych nazwach. Żądania do samego MousePlayera nie są rejestrowane. Przechowywane jak zdarzenie myszy w mouse_events (event_type con lub net), z tym samym okresem przechowywania i łańcuchem usuwania co nagranie (A.1); widoczne w odtwarzaczu obok osi czasu.
Czasy ładowania i reakcji (Web Vitals, od 02.10.2026)	Jak szybko strona ładuje się i reaguje u odwiedzającego, mierzone w przeglądarce dla każdego wyświetlenia strony: Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift, First Contentful Paint i Time to First Byte. Do tego krótki opis największego widocznego elementu oraz elementu najwolniejszej interakcji, tak jak przy kliknięciu (rodzaj, identyfikator, widoczny tekst; w maskowanych obszarach tylko rodzaj). Bez wpisywanych danych, bez treści żądań. Przechowywane jak zdarzenie myszy w mouse_events (event_type cwv) oraz dla każdego wyświetlenia w mp_cwv, z tym samym okresem przechowywania i łańcuchem usuwania co nagranie (A.1); widoczne w zakładce Web Vitals i w nagłówku odtwarzacza.

A.8 Cechy wyprowadzone i maszynowo generowane osie czasu sesji

Pole	Wpis
Cel	Wyprowadzanie cech dla poszczególnych sesji oraz maszynowo generowanych protokołów tekstowych — punktowa ocena zauważalności zachowania i uwagi.
Kategorie osób, których dane dotyczą	Odwiedzający strony klientów.
Kategorie danych osobowych	Wektor cech: czas trwania, liczba stron, głębokość przewijania / mediana / zmiany kierunku, przerwy, efektywność ścieżki, prędkość szczytowa, kliknięcia gniewne (rage) i puste (dead), dotknięcia, powiększenie, źródło i kampania, czas zatrzymania na rolę elementu (role_dwell_json), zachowanie kart. Oceny: engagement_score (0-255), session_quality, is_bot. Oś czasu sesji zapisana tekstem ciągłym — próbka: 't=0.0 landing / src=(direct) kanal=direct attr=direct mode=unknown motion=unavailable viewport=1699x935 / t=2.0 session ende'.
Miejsce przechowywania	ai_session_features — 4043 wiersze (jeden wiersz na sesję ORAZ builder_version, więc sesja pojawia się raz na każdą wersję). ai_timelines (timeline_id, session_id, channelid, builder_version, input_mode, line_count, char_count, pageviews, duration_s, text jako mediumtext, built_at) — 3203 wiersze, 5,5 MB. mp_session_ziel (channelid, session_id, goal_id, tag, ziel_fp, gebaut_am) — 628 wierszy: która sesja osiągnęła który cel, policzone raz zamiast przy każdym wywołaniu. ziel_fp to odcisk reguły celu; gdy administrator ją zmieni, przypisanie jest budowane od nowa, a nie po cichu używane dalej. mp_hm_tag (channelid, tag, url_md5, url, titel, ansichten, engagiert) oraz mp_hm_tag_stand (channelid, tag, berechnet_am), od 24.09.2026 (migracja 148): dla każdego projektu, dnia i adresu strony liczba odsłon oraz odsłon zaangażowanych, z których zasilana jest lista map cieplnych stron. Wyłącznie liczniki i adresy — bez identyfikatora odwiedzającego ani sesji; liczba odwiedzających dla adresu nadal jest liczona z samych sesji.
Podstawa prawna	Nieudokumentowana w kodzie. Wyprowadzone z nagrania, a zatem pośrednio objęte zgodą uzyskaną na nie. Polecenie: powstaje z chwilą rejestracji klienta i jest wykonywane, gdy tylko wbuduje on skrypt na swojej stronie i odwiedzający zaczną być nagrywani (oświadczenie administratora, 17.08.2026). Wyprowadzanie cech, osi czasu i progów wartości należy do zleconej usługi. Rozróżnia się przy tym dwie części. Progi wartości klient ustawia sam na swoim projekcie; każda zmiana jest rejestrowana (log_audit, save_wertregeln). Podsumowania pisane przez model językowy działały do 17.08.2026 wyłącznie na podstawie globalnego ustawienia w panelu administracyjnym — klient nie miał na nie wpływu, nie opierały się więc na jego poleceniu. Od migracji 041 decyduje dodatkowo projects.ki_texte_aktiv, domyślnie włączone; klient może je w każdej chwili wyłączyć w zakładce ustawień, a każda zmiana pojawia się jako ki_texte_changed w dzienniku zmian. Przełącznik nie jest poleceniem, lecz środkiem jego ograniczenia: domyślnie włączone znaczy, że klient go nie włączył, a jedynie nie wyłączył.
Kategorie odbiorców	Klient (cfg/project_ai_overview.php).
Przekazanie do państwa trzeciego	Brak. Wygenerowane zdania formułuje model językowy na własnym sprzęcie w Łodzi (rozdział 4); do zewnętrznej usługi AI nie trafia nic.
Okres przechowywania	Wraz z sesją. ai_session_features i ai_timelines od 12.08.2026 należą do mp_sitzungen_loeschen() (srv/db_worker.php), więc są usuwane zarówno przy wyraźnym usunięciu, jak i przez codzienne usuwanie według planu. Wcześniej stało tu twierdzenie przeciwne; był to stan sprzed tej zmiany. Wyliczana z nich ocena na odwiedzającego i dzień (ai_visitor_value) oraz generowane teksty (ai_insights) mają dodatkowo własny termin — zob. sekcja 6.2.

A.9 Współpraca przy odtwarzaniu — komentarze i linki udostępniające

Pole	Wpis
Cel	Komentowanie odtwarzanej sesji w oznaczonym momencie oraz udostępnianie nagrania linkiem.
Kategorie osób, których dane dotyczą	Użytkownicy klienta (autorzy) oraz pośrednio nagrani odwiedzający.
Kategorie danych osobowych	Treść komentarza (do 2000 znaków), przesunięcie czasowe, autor. Token udostępnienia (40 znaków szesnastkowych), twórca, wygaśnięcie, cofnięcie, liczba wywołań, ostatni dostęp.
Miejsce przechowywania	session_comments (comment_id, channelid, session_id, user_id, time_offset_ms, body, created_at, updated_at) — 12 wierszy. session_shares (share_id, channelid, session_id, token, created_by, expires_at, revoked_at, last_seen, view_count, created_at) — 9 wierszy.
Podstawa prawna	Nieudokumentowana w kodzie. Polecenie: klient wyraźnie zezwala na udostępnianie, również poza własną organizację, i ponosi za to odpowiedzialność (decyzja administratora, 17.08.2026). Polecenie jest udokumentowane samą czynnością: link tworzy uprawniony członek obszaru roboczego klienta, a utworzenie jest rejestrowane (log_audit, akcja create_share; cofnięcie jako revoke_share). MousePlayer udostępnia funkcję; wybór odbiorców i zgodność przekazania z prawem należą do klienta. Ograniczenie techniczne: każdy link wygasa — domyślnie 7 dni, najwyżej 90 — i można go w każdej chwili cofnąć.
Kategorie odbiorców	Każdy posiadacz linku udostępniającego, BEZ logowania (www/.htaccess:77). Tokeny wymyślone, wygasłe i cofnięte zwracają tę samą odpowiedź, więc nie da się z nich odczytać żadnej informacji.
Przekazanie do państwa trzeciego	Nieokreślone z założenia — link można przesłać w dowolne miejsce. To właściwość funkcji, a nie incydent.
Okres przechowywania	Razem z sesją: session_comments i session_shares od 12.08.2026 r. należą do mp_sitzungen_loeschen() i są usuwane razem z sesją. Niezależnie od tego linki udostępniające mają własny maksymalny okres ważności: session_shares.expires_at ma ograniczenie NOT NULL, mp_share_erstellen() (cfg/lib.php) ustawia domyślnie 7 dni i ogranicza do najwyżej 90. Aplikacja nie może utworzyć linku bezterminowego. Gdy link wygaśnie lub zostanie cofnięty, codzienne usuwanie kasuje jego wiersz po 90 dniach; dostępy zapisane w share_views są usuwane razem z nim przez klucz obcy (B.6).

A.10 Podgląd na żywo — obserwacja trwającej sesji

Pole	Wpis
Cel	Obserwacja trwającej sesji w czasie rzeczywistym: lista obecnych odwiedzających, tryb podążania z lustrzanym odwzorowaniem strony, przesyłaną pozycją kursora, a od 16.08.2026 także z odtworzonym stanem najechania (:hover).
Kategorie osób, których dane dotyczą	Odwiedzający strony Klientów (obserwowani), użytkownicy Klienta (obserwujący).
Kategorie danych osobowych	Te same kategorie co w A.1 i A.2 — pozycje kursora i przewijania, kliknięcia, zdarzenia wejściowe, odwzorowanie strony i jego zmiany — lecz w chwili ich powstawania. Do tego identyfikator sesji, aby obserwator podążał za właściwą sesją.
Miejsce przechowywania	Nie są przechowywane. Strumień biegnie przez serwer WebSocket (class/Server.class.php) i jest przekazywany wewnątrz procesu do połączonych obserwatorów. Token dostępu znajduje się w tabeli bazy danych live_tokens (identyfikator, projekt, identyfikator użytkownika, w stosownych przypadkach obserwowana sesja, czas ostatniego potwierdzenia). Od 17.09.2026 r. do tego strumienia podłącza się również odtwarzacz trwającej sesji z własnym dostępem (identyfikator z prefiksem pl_, powiązany z obserwowaną sesją), aby wyświetlać jej zdarzenia bez opóźnienia. Nagranie tej samej sesji powstaje niezależnie od tego w ramach A.1 i A.2.
Podstawa prawna	Polecenie: obserwację uruchamia uprawniony członek obszaru roboczego klienta; dostęp działa przez czasowy token w live_tokens powiązany z jego identyfikatorem. Użytkownik końcowy nie jest odrębnie informowany w chwili obserwacji (decyzja administratora, 17.08.2026). Poinformowanie następuje wcześniej: przez zgodę poprzedzającą każde nagranie oraz przez politykę prywatności, która od 17.08.2026 wprost mówi, że trwającą sesję można śledzić w czasie rzeczywistym. Wcześniej wymieniała podgląd na żywo tylko jako funkcję na liście — decyzja opierała się więc na zdaniu, którego jeszcze nie było.
Kategorie odbiorców	Klient, w granicach uprawnionych członków obszaru roboczego.
Przekazanie do państwa trzeciego	Brak.
Okres przechowywania	Sam strumień nie jest przechowywany. Wiersz w live_tokens serwer WebSocket usuwa po zakończeniu podglądu, z krótkim okresem na ponowne załadowanie; dostęp, który nie jest już potwierdzany, po krótkim czasie traci skuteczność i jest później usuwany.

Tego wpisu nie było w rejestrze do 17.08.2026. Należy go oddzielić od A.1 i A.2, choć płyną te same dane: tam są odtwarzane później, tutaj człowiek patrzy w chwili, gdy odwiedzający działa. Właśnie ta jednoczesność jest cechą, na której art. 35 ust. 3 opiera pojęcie systematycznego monitorowania, a ocena skutków opiera na niej własną niezbędność.

A.11 Dziennik dostarczeń integracji

Pole	Wpis
Cel	Dowód i diagnostyka dla przekazań wymienionych w 4.1. Bez niego administrator nie może stwierdzić, czy most działa — niepowodzenie byłoby z jego strony nieme.
Kategorie osób, których dane dotyczą	Odwiedzający strony klientów, o ile administrator ustawił dla nich własny identyfikator klienta. Bez ustawionego identyfikatora wpis nie zawiera odniesienia do osoby.
Kategorie danych osobowych	Znacznik czasu, rodzaj mostu, identyfikator (identyfikator klienta dostarczony przez administratora przez setUserId, sieć reklamowa albo nazwa zdarzenia), powodzenie lub niepowodzenie, czas trwania w milisekundach, numer próby oraz tekst odpowiedzi lub błędu odbiorcy. Tekst ten może zawierać identyfikator rekordu w systemie zewnętrznym. Brak danych behawioralnych, treści strony i adresu IP.
Gdzie przechowywane	Redis, klucz mp_webhook_log:<channelid>. Ostatnie 25 wpisów na projekt; starsze wypadają przez lTrim. Nie w bazie danych, a więc i nie w codziennej kopii zapasowej.
Podstawa prawna (określona przez administratora)	Jak A.1. Wpis powstaje wyłącznie wtedy, gdy administrator włączył most — jest zapisem wykonania jego własnego polecenia.
Kategorie odbiorców	Administrator, przez ustawienia projektu (zakładka Integracje). Bez dalszego udostępniania.
Przekazanie do państwa trzeciego	Brak. Wpis nie opuszcza naszego serwera.
Przechowywanie	30 dni. Ustawiane jako czas wygaśnięcia w Redis przy zapisie; dodatkowo ograniczone do 25 wpisów na projekt. Wygasa samo i nie wymaga przebiegu usuwania. Liczba znajduje się w site_settings.retention_intlog_days i jest ustawialna w panelu administracyjnym.

A.12 Profile zachowań — automatyczne grupowanie wizyt

Pole	Wpis
Cel	Automatyczne grupowanie zarejestrowanych WIZYT według ich przebiegu, aby administrator nie przeglądał sesji po sesji, lecz widział grupy — i mógł odtworzyć jedną typową wizytę na grupę. Obok tego powtarzające się sekwencje stron i zdarzeń w oknie obliczeniowym.
Kategorie osób, których dane dotyczą	Odwiedzający witryny klientów. Grupowane są WIZYTY, a nie ludzie: ta sama osoba z dwiema wizytami może trafić do dwóch grup, i interfejs jest tak sformułowany. Profil na OSOBĘ nie jest obliczany — wymagałby identyfikatora klienta przekazywanego przez setUserId, a 0 z 4226 sesji taki nosi (pomiar 27.08.2026).
Kategorie danych osobowych	Żadnych nowych kategorii. Wektor cech z A.8, zawężony do siedmiu cech o stopniu wypełnienia powyżej 90 %: czas trwania, liczba odsłon, ocena uwagi, pauzy, kliknięcia frustracji, martwe kliknięcia, przełączenia kart. Wyprowadzone z nich: do której grupy należy sesja i jej odległość od środka grupy. Na grupę dodatkowo identyfikator sesji wizyty najbardziej i najmniej typowej, aby obie dały się odtworzyć. Przy sekwencjach łańcuch wzorca ze ścieżek i nazw zdarzeń oraz do trzech identyfikatorów sesji jako przykłady. Żadnej treści strony, żadnego adresu IP, żadnych danych z formularzy.
Gdzie przechowywane	mp_profile — jeden wiersz na kanał i grupę (wielkość, udział, środek, wskaźniki, nazwa obliczona, nazwa nadana ręcznie, przedstawiciel, odstający); 15 wierszy. mp_profil_sitzung — sesja do grupy wraz z odległością; 4226 wierszy. mp_sequenzmuster — łańcuch, wsparcie, lift, do trzech przykładów; 115 wierszy. Wszystkie trzy są POCHODNE: mogą w każdej chwili zniknąć i zostać przeliczone od nowa, i nie zawierają danych surowych, których nie ma gdzie indziej. Od 06.09.2026 r. mp_profil_sitzung zawiera dodatkowo klucz osoby (person_key, migracja 112): kopię klucza z A.4 (identyfikator klienta, a w jego braku identyfikator odwiedzającego), którą przebieg profilowania codziennie aktualizuje; na jej podstawie obliczana jest lista powracających odwiedzających. Liczby wierszy w tym wpisie: stan na 27.08.2026.
Podstawa prawna	Jak A.8. Wyprowadzone z nagrania i tym samym pośrednio oparte na zgodzie zebranej na nie. Polecenie: część zleconej usługi; powstaje wraz z rejestracją klienta i jest wykonywane, gdy tylko odwiedzający są rejestrowani. Dwie granice warto nazwać. Grupowanie jest OBLICZANE, a nie generowane: o tym, do której grupy należy wizyta, decyduje k-średnich po siedmiu cechach w ai/profile.py, a nazwy grup powstają ze względnego położenia środka, nie z tekstu. Tam, gdzie model językowy pisze zdanie o grupie, otrzymuje wyłącznie liczby GRUPY — wartości procentowe i średnie — nigdy identyfikatora sesji ani odwiedzającego, a ten sam strażnik co w A.8 odrzuca każdą liczbę, której wśród nich nie ma. Nie istnieje jednak przełącznik na projekt: profile_aktiv jest globalnym ustawieniem operatora, a wybór sekcji AI na projekt (projects.ki_module) tej zakładki nie obejmuje. Odnotowane jako luka w sekcji 10.
Kategorie odbiorców	Klient, przez zakładkę Profile zachowań (cfg/project_profiles.php). Brak przekazywania osobom trzecim: przynależność do grupy nie trafia do żadnego z mostów z 4.1. Sprawdzone wyszukiwaniem profil_key w cfg/, srv/, www/ i class/ — występuje wyłącznie na ścieżce odczytu i w odtwarzaczu, ani w www/mp.js, ani w class/Server.class.php, nie trafia więc również do przeglądarki odwiedzającego.
Przekazywanie do państw trzecich	Brak. Obliczenia wykonywane są na tej samej maszynie (ai/profile.py, uruchamiany przez srv/ai_worker.php). Opcjonalne zdanie na grupę formułuje model językowy na jednym z własnych komputerów z kartą graficzną w tej samej sieci lokalnej (zob. rozdział 4), który pobiera w tym celu wyłącznie liczby dotyczące grupy, przez HTTPS. Do zewnętrznej usługi AI nie trafia nic.
Okres przechowywania	Wraz z sesją: mp_profil_sitzung znajduje się w mp_sitzungen_loeschen(). Ponadto 180 dni, zakotwiczone na POCZĄTKU SESJI, a nie na momencie obliczenia — ten dzienny przebieg ustawia za każdym razem na nowo, termin oparty na nim nigdy by nie upłynął i nikt by tego nie zauważył. Wiersze, których sesji już nie ma, usuwane są całkiem bez terminu, bo każdy termin skaluje się po wierszu, którego już nie ma. Liczba znajduje się w site_settings.retention_profile_days, jest ustawialna w panelu administracyjnym i podnoszona do co najmniej okna obliczeniowego, aby przebieg usuwania nie sprzątał tego, co przebieg profili zapisał tego samego dnia. mp_profile znika, gdy tylko nie zostaje mu żadne przypisanie, i to tej samej nocy — dlatego to polecenie stoi za dwoma powyżej. mp_sequenzmuster znika po 180 dniach bez przeliczenia oraz natychmiast, gdy jego kanał nie ma już żadnej sesji. Tam kotwicą JEST moment obliczenia, i słusznie: inaczej niż przypisanie, wzorzec opisuje BIEŻĄCE okno i jest zapisywany w całości od nowa dla każdego kanału, świeży znacznik czasu naprawdę znaczy więc „opisuje dzisiejsze dane“.

A.13 Własna nazwa odwiedzającego — nadana przez administratora

Pole	Wpis
Cel	Administrator nadaje pojedynczemu odwiedzającemu własną nazwę, aby rozpoznać go na listach i w nagraniach. Nazwa zastępuje wygenerowany przydomek z A.4 wszędzie tam, gdzie ten by się pojawił. Powodem jest sprawa wsparcia: „to jest klient, który dzwonił“.
Kategorie osób, których dane dotyczą	Odwiedzający witryny klientów — a konkretnie pojedynczy, wybrani przez administratora. Inaczej niż A.1 do A.12, to przetwarzanie nie powstaje samo, gdy ktoś otworzy stronę, lecz wyłącznie przez świadome wprowadzenie danych. Bez niego nie ma wiersza: 28.08.2026 własną nazwę nosi 0 z 3830 odwiedzających.
Kategorie danych osobowych	DOWOLNY TEKST o długości najwyżej 64 znaków, do tego czas i konto użytkownika, który go nadał. Odniesieniem jest identyfikator odwiedzającego z A.4. Treść nie jest ani narzucona, ani sprawdzana — może to być numer umowy, przydomek albo imię i nazwisko wraz z działem. To odróżnia niniejsze przetwarzanie od wszystkich pozostałych w części A: tam dane pochodzą od odwiedzającego albo są liczone z jego zachowania, tutaj wpisuje je administrator. Odnotowane jako luka w sekcji 10.
Gdzie przechowywane	visitor_nicknames.custom_label, label_set_at, label_set_by (migracja 093) — ten sam wiersz, który już nosi wygenerowany przydomek, jeden na odwiedzającego, 3830 wierszy. Świadomie bez własnej tabeli: nazwa zastępuje dokładnie ten przydomek, który tam stoi, wisi na tym samym kluczu i dlatego znika razem z nim bez dodatkowych działań. Osobna tabela byłaby piątym miejscem w łańcuchu usuwania, o którym można zapomnieć.
Podstawa prawna	Polecenie administratora (art. 28 ust. 3 lit. a), wydane samym wprowadzeniem — żadne zadanie ani ustawienie domyślne nie tworzy nazwy. Czy dla wprowadzonej treści istnieje podstawa prawna, MousePlayer nie jest w stanie ocenić: administrator wybiera tekst i zna kontekst, z którego go bierze. Wskazówka w polu wpisu nazywa więc cel („tę nazwę widzi tylko Twój zespół“), a nie tylko samo pole.
Kategorie odbiorców	Klient, na własnych listach i w odtwarzaczu. Bez przekazywania osobom trzecim: pole nie trafia do żadnego z mostków z 4.1 — sprawdzone wyszukaniem custom_label w cfg/, srv/, www/ i class/; nie występuje ani w www/mp.js, ani w class/Server.class.php, nie dociera więc również do przeglądarki odwiedzającego. Link udostępniania (B.6) wyraźnie go NIE pokazuje, lecz wygenerowany przydomek: kto przekazuje link niewymagający logowania, dzieli się nagraniem, a nie tożsamością za nim. Ta sama myśl co w www/selbstauskunft.php.
Przekazywanie do państw trzecich	Brak. Pole opuszcza bazę danych wyłącznie do interfejsu zalogowanego klienta.
Okres przechowywania	Wraz z ostatnią sesją odwiedzającego, tak jak wiersz, w którym stoi: mp_sitzungen_loeschen() usuwa go, gdy dla tego identyfikatora odwiedzającego nie ma już żadnej sesji — obiema drogami, przez codzienny przebieg usuwania i przez usunięcie konta. Bez własnego terminu kalendarzowego, i to celowo: termin nałożony na nazwę oznaczałby usunięcie jej, gdy odwiedzający wciąż tu jest i wciąż jest nagrywany. Administrator może ją w każdej chwili usunąć sam; puste pole ją kasuje, a wtedy znów obowiązuje wygenerowany przydomek.

A.14 Import z Google Analytics 4 — liczby i sesje z konta administratora

Pole	Wpis
Cel	Administrator zleca pobranie do MousePlayera danych z własnego konta Google Analytics 4. Dwie niezależnie włączane drogi: Data API dostarcza wyłącznie sumy dzienne i odpowiada na pytanie o pokrycie — GA4 liczy dla danego dnia 3000 sesji, MousePlayer nagrał 40, a bez tej wielkości odniesienia różnicy nie da się ani wyjaśnić, ani nawet zauważyć. Import z BigQuery czyta surowy eksport usługi i zapisuje pojedyncze sesje GA4 wraz ze zdarzeniami, aby było widać, co działo się podczas wizyty, której MousePlayer nie mógł nagrać.
Kategorie osób, których dane dotyczą	Odwiedzający witryny klientów — ci sami ludzie co w A.1, tylko obserwowani przez drugi system pomiarowy. Od A.1 do A.13 odróżnia to pochodzenie: te dane nie zostały zebrane tutaj, lecz leżą już na koncie Google administratora, a MousePlayer je pobiera. Droga przez Data API nie dotyczy zresztą żadnej pojedynczej osoby; zwraca wyłącznie sumy dzienne.
Kategorie danych osobowych	Dla drogi przez Data API: żadne — cztery liczby dziennie (sesje, użytkownicy, odsłony, sesje angażujące) bez jakiegokolwiek odniesienia do osoby. Dla drogi przez BigQuery, na sesję GA4: identyfikator pseudonimowy user_pseudo_id, czyli client_id z ciasteczka _ga; początek, koniec i czas trwania; liczba zdarzeń i odsłon; ścieżka wejścia; kategoria urządzenia i kraj; a także źródło, medium i kampania. Do tego na każdą nazwę zdarzenia licznik, ostatni znacznik czasu oraz, jeśli GA4 go podaje, suma wartości. Żadnego adresu IP, żadnego zrzutu strony, żadnego ruchu myszy — GA4 nie prowadzi niczego z tych rzeczy i nic z nich nie powstaje. Zaimportowanej sesji nie da się więc nigdy odtworzyć.
Gdzie przechowywane	ga4_daily, ga4_sessions i ga4_events (migracja 097) — trzy WŁASNE tabele. Świadomie nie w visitor_sessions, session_pageviews ani session_custom_events. Nie chodzi o porządek: te trzy tabele nie mają kolumny mówiącej, skąd pochodzi wiersz, bo wszystko w nich zmierzono tutaj. Zaimportowany wiersz byłby nie do odróżnienia od zmierzonego, a wraz z tym po cichu zmieniłoby się znaczenie każdej liczby z nich wyprowadzonej: profili zachowań z A.12, wyceny na odwiedzającego, analizy frustracji. Import stoi więc obok danych pomiarowych, tak jak robią to już ai_visitor_value i mp_profile.
Podstawa prawna	Polecenie administratora (art. 28 ust. 3 lit. a), udzielone przez włączenie danej drogi i wprowadzenie własnego konta usługi. Za pierwotne zebranie danych w Google odpowiada administrator, nie MousePlayer: nastąpiło ono, zanim cokolwiek jest tu pobierane, i nie da się go zweryfikować po fakcie. Istnieje mimo to rygiel techniczny — importowane jest wyłącznie to, co ma user_pseudo_id. Przy odmowie zgody GA4 wysyła w trybie Consent Mode trafienia bez ciasteczek, a te go nie mają; odpadają mechanicznie, a nie na mocy zapewnienia. To poszlaka, a nie dowód, i dokładnie tak figuruje wśród luk w sekcji 10.
Kategorie odbiorców	Żadnych nowych. Droga POBIERA, a nie dostarcza: żadna dana odwiedzającego nie opuszcza domu. Odbiorcą jest klient we własnym interfejsie. Google występuje tu nie jako odbiorca, lecz jako ŹRÓDŁO — z konta, które administrator prowadzi sam i którego zawartość sam określa.
Przekazywanie do państw trzecich	Żadnego przekazania danych odwiedzających. Zapytanie kierowane jest do analyticsdata.googleapis.com i do BigQuery; przekazywane są przy tym poświadczenia konta usługi oraz treść zapytania, a nie dane odwiedzających. Dane płyną w przeciwną stronę. To, gdzie dane GA4 leżą w Google i pod jakimi gwarancjami, wynika z konta administratora i jest przedmiotem jego umowy z Google — nie tego rejestru.
Okres przechowywania	180 dni, zakotwiczone w dniu, który wiersz OPISUJE (ga4_daily.tag, ga4_sessions.start_time), a nie w momencie importu. Ten jest aktualizowany przy każdym przebiegu, bo GA4 uzupełnia dane nawet przez 48 godzin i te same dni są pobierane ponownie; termin oparty na nim nigdy by nie upłynął. Egzekwowane przez dzienny przebieg w srv/db_worker.php, zdarzenia przed ich sesjami. Żądanie usunięcia z art. 17 zabiera je od 01.09.2026, o ile wiersz da się przypisać przez identyfikator klienta; taryfowy przebieg usuwania NIE — dane GA4 mają własny zegar, a klient w darmowej taryfie straciłby je inaczej po 7 zamiast po 180 dniach. Wraz z projektem znikają w każdym razie, także wiersze, które nigdy nie należały do żadnej naszej sesji. To, czego to nie obejmuje, opisuje sekcja 10.

A.15 Przewidywanie wyjścia i wyświetlenie oferty

Pole	Wpis
Cel	Oszacowanie na podstawie pierwszych sekund wizyty, jak prawdopodobne jest, że odwiedzający wkrótce opuści stronę bez drugiej odsłony. Administrator może powiązać z tą oceną ofertę wyświetlaną odwiedzającemu na JEGO stronie. Inaczej niż A.8 do A.14 przetwarzanie to nie kończy się analizą dla klienta, lecz oddziałuje z powrotem na odwiedzającego — dlatego stanowi osobny wpis, a nie podpunkt A.8. Ponadto administrator może zlecić zaproponowanie treści i wyglądu takiej oferty: model językowy tworzy ich projekt na podstawie kontekstu jego strony. Propozycja nigdy nie trafia na stronę sama; administrator przejmuje ją wyłącznie część po części.
Kategorie osób, których dane dotyczą	Odwiedzający strony klientów, i to wyłącznie przy PIERWSZEJ odsłonie sesji: późniejsza odsłona nie jest już wejściem i nie podlega ocenie. Nic z tego nie działa bez zgody — ocena znajduje się za tą samą zaporą co nagrywanie.
Kategorie danych osobowych	Szesnaście zmierzonych cech bieżącej wizyty, wszystkie tworzone w przeglądarce: urządzenie (mobilne tak/nie), powracający, kliknięcie płatne, wyszukiwarka, serwis społecznościowy, wejście na stronie głównej, głębokość ścieżki strony wejścia, godzina nocna, liczba ruchów myszy, zdarzeń przewijania i kliknięć w oknie, liczba sekund do pierwszego działania, najgłębsza pozycja przewinięcia w procentach strony, liczba zmian kierunku przewijania, informacja, czy karta straciła fokus, oraz czy nie było żadnego działania. Powstaje z nich JEDNA wartość procentowa i najwyżej trzy powody w zwykłym języku. Żadnych treści, współrzędnych ani wartości pól. Znacznik mp_seen_before w pamięci lokalnej przeglądarki zapisuje, że odwiedzający już tu był; mp_offer_<data> zlicza, ile razy pokazano mu dziś ofertę. Propozycja oferty nie dodaje informacji o poszczególnych odwiedzających, lecz informacje o stronie: tytuł, opis, nagłówki i nawigację z najwyżej dziesięciu obrazów stron, najwyżej 40 adresów, które odwiedzający ludzie otworzyli w ciągu 30 dni co najmniej pięć razy, udział języków stron oraz zmierzone w przeglądarce kolory, zaokrąglenie narożników i czcionkę tła strony i najczęstszego przycisku. W tym celu język zapisywany jest dla każdej odsłony (atrybut lang strony). Adresy i nagłówki mogą zawierać to, co wypisuje sama strona (zob. A.17).
Gdzie przechowywane	MODEL w projects.exit_modell (migracja 100) — wagi, średnie, odchylenia, jakość i czas trenowania; nie zawiera danych osobowych, tylko liczby o zbiorowości. WYNIK dla wizyty jako zdarzenie w session_custom_events: exit_risk z wartością procentową i powodami, a także exit_offer_shown, exit_offer_click i exit_offer_dismiss, gdy pokazano ofertę. Ostatnia wartość znajduje się dodatkowo, ulotnie, w rekordzie połączenia serwera WebSocket (Redis, mp_websockets), aby podgląd na żywo mógł ją pokazać; znika wraz z połączeniem. Propozycja oferty znajduje się w projects.exit_offer_vorschlag (migracja 114), pomiary wyglądu jako ostatnie 60 na kanał w Redis (mp_design:<kanał>), język strony w session_pageviews.lang. Na potrzeby sformułowania kontekst wędruje przez ai_ki_queue do własnych komputerów, na których działa model językowy (rozdział 4).
Podstawa prawna	Polecenie administratora. Trenowanie odbywa się per projekt i wyłącznie na jego własnych sesjach, co najmniej 200; poniżej tego progu model nie powstaje. Zgoda odwiedzającego obejmuje nagranie, z którego pochodzą cechy — ta sama podstawa co w A.8. O tym, czy oferta zostanie wyświetlona, decyduje wyłącznie administrator; za to wyświetlenie na swojej stronie to on jest administratorem, nie my.
Kategorie odbiorców	Klient w swoim panelu. Wartość procentowa i powody trafiają dodatkowo do PRZEGLĄDARKI ODWIEDZAJĄCEGO — powstają tam, a nie są tam wysyłane — i są dostępne dla kodu administratora przez MousePlayer.on('exit_risk') oraz warstwę danych. Ofertę, która się wtedy pojawi, widzi sam odwiedzający. Propozycję oferty widzi wyłącznie administrator w swoim panelu; na stronę trafia dopiero wtedy, gdy ją przejmie. Do osób trzecich nie trafia nic.
Przekazywanie do państw trzecich	Brak. Trenowanie i ocena działają na infrastrukturze w Łodzi albo w przeglądarce odwiedzającego. Propozycję oferty formułuje model językowy na własnym sprzęcie w Łodzi (rozdział 4); do zewnętrznej usługi AI nie trafia nic.
Okres przechowywania	Zdarzenia dzielą okres przechowywania sesji, do której należą (A.7), i znikają wraz z nią. Model jest nadpisywany przy każdym uruchomieniu; historii nie ma. Oba znaczniki leżą w pamięci lokalnej odwiedzającego: mp_seen_before bez terminu, dopóki jej nie wyczyści lub nie wycofa zgody, mp_offer_<data> tylko dla bieżącego dnia (starsze wpisy mp.js usuwa przy następnym zapisie). Ponadto mp_design_sent w pamięci sesji karty zapisuje, że wygląd został już zmierzony. Przy wycofaniu zgody mp.js usuwa wszystkie trzy. Propozycja oferty pozostaje do czasu zastąpienia jej nową; pomiary wyglądu wygasają w Redis po 30 dniach; język strony dzieli okres przechowywania swojej odsłony.

A.16 Wskaźnik odpływu dla powracających odwiedzających

Pole	Wpis
Cel	Oszacowanie na podstawie wcześniejszych wizyt tego samego człowieka, czy się oddala, aby administrator mógł zareagować. Inaczej niż A.15 ocena ta nie patrzy na bieżącą wizytę, lecz na historię.
Kategorie osób, których dane dotyczą	Powracający odwiedzający strony klientów, mający co najmniej 2 sesje. Kto był tylko raz, nie otrzymuje wiersza. Kluczem jest osoba w rozumieniu A.4 — identyfikator klienta ustawiony przez administratora, a w jego braku identyfikator odwiedzającego.
Kategorie danych osobowych	Wartość ryzyka od 0 do 1, najwyżej cztery powody w zwykłym języku z zamkniętej listy (spadające zaangażowanie, krótkie wizyty, tarcie, zaległość; zakup w dwóch ostatnich wizytach obniża wartość), liczba wizyt i czas ostatniej. Żadnych treści ani współrzędnych. To nie jest model uczony, lecz cztery policzalne obserwacje — każda stoi w wierszu jako powód, aby wartość nigdy nie pojawiała się bez uzasadnienia.
Gdzie przechowywane	ai_churn (migracja 100): channelid, person_key, visitor_id, risiko, gruende, sitzungen, letzte_sitzung, berechnet_am. Dodatkowo jedna tablica Redis na kanał, mp_churn:<kanał>, wygasająca po dwóch dniach, z której serwer WebSocket odczytuje przy nawiązaniu połączenia; trafiają tam wyłącznie osoby powyżej progu.
Podstawa prawna	Polecenie administratora; leżące u podstaw sesje opierają się na zgodzie odwiedzającego (A.1). Obliczenia per projekt, nigdy ponad klientami.
Kategorie odbiorców	Klient w swoim panelu. Wartość jest ponadto wysyłana do PRZEGLĄDARKI ODWIEDZAJĄCEGO, gdy tylko się połączy, i jest dostępna dla kodu administratora przez MousePlayer.on('churn_risk'); może on powiązać z nią ofertę. To przekazanie na własne urządzenie osoby, której dane dotyczą, jest powodem, dla którego wpis stoi tutaj, a nie pod A.8. Do osób trzecich nie trafia nic.
Przekazywanie do państw trzecich	Brak.
Okres przechowywania	Wiersz jest zapisywany dla kanału od nowa przy każdym uruchomieniu i znika wraz z sesjami, z których pochodzi. Wpis w Redis wygasa sam po dwóch dniach.

A.17 Zbiorczy raport o odwiedzającym

Pole	Wpis
Cel	Zebranie wszystkich wizyt JEDNEGO człowieka w czytelny raport: skąd przyszedł, za co zapłacono, na czym utknął i czy powstał z tego cel. Ustalenia są obliczane; model językowy najwyżej je przeformułowuje. Raport zamawia albo klient dla konkretnego odwiedzającego, albo powstaje samoczynnie dla najwyżej 5 odwiedzających na projekt i noc — wybierani są odwiedzający z płatnych wizyt bez zakupu.
Kategorie osób, których dane dotyczą	Odwiedzający strony klientów, dla których istnieje więcej niż jedna wizyta. Kluczem jest osoba w rozumieniu A.4.
Kategorie danych osobowych	Najwyżej czternaście obliczonych ustaleń w formie tekstu: liczba wizyt i stron, okres, urządzenia, źródło wraz z kampanią, zakupy i osiągnięte cele, trzy największe wąskie gardła wraz ze ścieżką, ostatnia sesja oraz ETYKIETY klikniętych elementów (do pięciu, po 60 znaków). Do tego wygenerowany tekst. Wartości pól formularzy nie znajdują się wśród nich — nigdy nie opuszczają przeglądarki. Etykiety i ścieżki pochodzą natomiast z tego, co wypisuje sama strona administratora, i mogą zatem zawierać imię, nazwisko lub adres, jeżeli je tam wyświetla albo wpisuje do adresu URL; odnotowane jako luka w sekcji 10.
Gdzie przechowywane	ai_besucher_bericht (migracja 100) z polami channelid, person_key, lang, ustaleniami, ich skrótem, tekstem i nazwą modelu. Na potrzeby sformułowania przez ai_ki_queue wędrują USTALENIA — nie nagranie — do komputerów, na których działa model językowy (własny sprzęt w tej samej sieci lokalnej, zob. rozdział 4). Każdy raport zużywa limit (ai_ki_kontingent na przestrzeń roboczą i miesiąc, 3 w taryfie darmowej, poza tym 200).
Podstawa prawna	Polecenie administratora; leżące u podstaw sesje opierają się na zgodzie odwiedzającego (A.1). Model językowy nie jest trenowany ani zmieniany; wyłącznie formułuje.
Kategorie odbiorców	Klient w swoim panelu. Sam odwiedzający niczego się o tym nie dowiaduje — inaczej niż w A.15 i A.16 nic tu na niego nie oddziałuje.
Przekazywanie do państw trzecich	Brak. Model językowy działa na własnym sprzęcie w Łodzi (rozdział 4); do zewnętrznej usługi AI nie trafia nic.
Okres przechowywania	180 dni od zamówienia, egzekwowane przez przebieg następczy procesu AI. Jeżeli ostatnia sesja odwiedzającego zniknie wcześniej, raport znika wraz z nią.

A.18 Samodzielny wgląd odwiedzającego i żądanie usunięcia

Pole	Wpis
Cel	Pokazanie odwiedzającemu, co jest o nim przechowywane, i umożliwienie usunięcia — wsparcie administratora w realizacji praw osób, których dane dotyczą, zgodnie z art. 28 ust. 3 lit. e RODO. Dostępne pod adresami /moje-dane, /meine-daten i /my-data.
Kategorie osób, których dane dotyczą	Odwiedzający strony klientów, i to wyłącznie ci, którzy przynoszą własny identyfikator. Link musi umieścić administrator; wobec swoich odwiedzających to on jest administratorem, a informacja z art. 13 należy do jego własnej polityki.
Kategorie danych osobowych	Pokazywane są liczba, okres i domeny sesji — żadnych nagrań. Identyfikator jest dowodem na okaziciela; kto zna cudzy, nie powinien zobaczyć zachowania obcej osoby. Z tego samego powodu odpowiedź pozostaje przy URZĄDZENIU i nie łączy przez mp_person_sql() tego, co należy do jednego człowieka: połączenie ujawniłoby WIĘCEJ, a nie mniej. Z żądania usunięcia zapisujemy identyfikator, czas zgłoszenia i czas wykonania.
Gdzie przechowywane	visitor_deletion_requests (visitor_id, requested_at, done_at) — 0 wierszy. Sama strona niczego nie zapisuje; czyta. Żądanie wykonuje worker tym samym łańcuchem usuwania, który uruchamia administrator — druga ścieżka usuwania byłaby drugim miejscem dla tej samej prawdy.
Podstawa prawna	Art. 28 ust. 3 lit. e RODO (wsparcie administratora) oraz jego polecenie. Identyfikator jest sprawdzany co do formy (^v_[a-z0-9]{9}_\d{13}$); wszystko inne jest odrzucane.
Kategorie odbiorców	Sam odwiedzający. Do klienta nie trafia nic — o żądaniu usunięcia dowiaduje się tylko po tym, że sesje znikają.
Przekazywanie do państw trzecich	Brak.
Okres przechowywania	Wiersz pozostaje jako dowód, że i kiedy nastąpiło usunięcie. Nie zawiera danych o zachowaniu. Jeżeli kopia zapasowa zostanie przywrócona, odnotowane żądania są wykonywane ponownie, zanim system wróci do pracy (pkt 24.2 Regulaminu).

A.19 Kontrola następcza wykrywania botów — decyzje operatora jako przykłady uczące

Pole	Wpis
Cel	Sesje, które wykrywanie fal oznaczyło wstecznie jako boty, sprawdza jeszcze raz strażnik, a przypadki wątpliwe zgłasza w Urgent Logs. Operator rozstrzyga tam jednym kliknięciem: Człowiek albo Bot. Każda decyzja staje się przykładem uczącym, z którego przelicza się wagi siedmiu sygnałów — tylko wagi, nie próg, i dopiero od minimalnej liczby decyzji ustawianej w panelu administracyjnym (bot_revision_lern_min). Poniżej obowiązują wartości stałe.
Kategorie osób, których dane dotyczą	Odwiedzający strony klientów, których sesję zgłoszono jako wątpliwą, oraz osoba podejmująca decyzję (pracownicy klienta lub nasi).
Kategorie danych osobowych	Żadnej treści odwiedzającego. Zapisywane są kanał, identyfikator sesji, decyzja, liczba punktów, nazwy sygnałów, które zaszły (np. identyfikator odbiega od fali, jest referrer, adres z sieci prywatnej) i identyfikator decydującego. Wektor cech jest częścią przykładu, ponieważ sama sesja po upływie okresu przechowywania znika, a uczenie wciąż jej potrzebuje.
Miejsce przechowywania	bot_review_labels (migracja 140): jeden wiersz na sesję, kto zmieni zdanie, nadpisuje. Czyta ją cfg/bot_revision_lib.php. Bez tabeli strażnicy działają ze stałymi wagami.
Podstawa prawna	Polecenie administratora; dla samych sesji obowiązuje A.1. Procedura poprawia rozróżnianie botów i ludzi, a tym samym prawidłowość analiz (art. 5 ust. 1 lit. d RODO). Nie zależy od niej żadna decyzja wobec odwiedzającego; zwolnienie uwalnia sesję od oznaczenia, nic więcej.
Kategorie odbiorców	Brak poza interfejsem; przykłady widzi wyłącznie operator.
Przekazanie do państwa trzeciego	Brak.
Okres przechowywania	Domyślnie: brak automatycznego usuwania — przykład jest spseudonimizowany i nie zawiera treści odwiedzającego, a jego wartość rośnie wraz ze zbiorem. Okres ustawia się w latach w panelu administracyjnym (retention_bot_labels_years, 0 = bez limitu); od 1 strażnik statusu (srv/cron_status.php) usuwa wiersze po tylu latach. Nie ma go w żadnym łańcuchu usuwania sesji: gdy sesja znika, przykład zostaje — zamierzone, ale odnotowane jako luka w rozdziale 10.

A.20 Śledzenie elementów — kliknięcia w zaznaczone elementy strony

Pole	Wpis
Cel	W kreatorze elementów administrator zaznacza elementy swoich stron — pojedynczo albo jako grupę podobnych elementów, za pomocą selektora CSS — i otrzymuje dla każdego zaznaczenia kliknięcia, sesje z kliknięciem, odwiedzających i współczynnik kliknięć. Liczenie odbywa się wstecz: srv/element_worker.php przypisuje już zarejestrowane kliknięcia (A.1, mouse_events_analytik) do zaznaczonego elementu w zrzucie ich własnego wyświetlenia strony. Zaznaczenie może być też celem lub krokiem lejka; jego trafienia liczą się wtedy jako osiągnięty cel lub krok.
Kategorie osób, których dane dotyczą	Odwiedzający strony klientów, których kliknięcia zostały zarejestrowane.
Kategorie danych osobowych	Uzupełnienie nagrywania kliknięć (A.1), poza tym brak nowego zbierania: gdy odwiedzający kliknie element, który powstał dopiero po zrzucie (np. rozwinięte menu lub okno wyskakujące), mp.js od 27.09.2026 przesyła dodatkowo jego budowę — znacznik, klasy, kilka atrybutów (role, type, name, ścieżkę linku bez parametrów zapytania, data-*), pozycję wśród rodzeństwa tego samego typu i widoczną etykietę; w obszarach maskowanych tylko znacznik i identyfikator. Leży ona przy zdarzeniach wyświetlenia strony (A.1) i dzieli ich okres przechowywania. Dla każdego trafienia zapisywane są: kanał, identyfikatory sesji i wyświetlenia strony, początek sesji, rodzaj kliknięcia (kliknięcie albo dotknięcie), widoczna etykieta trafionego elementu ze zrzutu — zamaskowana dokładnie tak, jak zawiera ją nagranie — oraz, jeśli administrator tak wybierze, wartość atrybutu tego elementu (np. data-id) do rozbicia. Od 27.09.2026 worker elementów notuje kliknięcia, których celu brakuje w zrzucie i dla których nie przesłano budowy (starsze kliknięcia): kanał, identyfikator sesji i wyświetlenia, czas oraz skrót ze ścieżki strony i etykiety — samej etykiety tam nie ma. Z rozpoznanych kliknięć uczy się dla każdego zaznaczenia, która etykieta na której ścieżce trafia w zaznaczenie (ścieżka, etykieta, dwa liczniki, bez związku z odwiedzającym). Gdy wszystkie obserwacje są zgodne, zanotowane kliknięcie zostaje przypisane jako trafienie — oznaczone jako przeniesione — albo jako brak trafienia. Samo zaznaczenie (nazwa, selektor, obszar stron) i dzienne liczniki pokrycia nie odnoszą się do odwiedzających.
Miejsce przechowywania	mp_element_regeln, mp_element_klicks i mp_element_tag (migracja 152), mp_element_offen i mp_element_muster (migracja 155). Czyta je cfg/element_lib.php.
Podstawa prawna	Polecenie administratora (art. 28 ust. 3 lit. a RODO), wydane przez utworzenie zaznaczenia; dla samych kliknięć obowiązuje A.1. Analiza podsumowuje istniejące nagrania; dochodzi jedynie budowa elementów kliknięcia powstałych po zrzucie (powyżej), która opisuje to samo co zrzut strony. Nie zależy od niej żadna decyzja wobec odwiedzającego.
Kategorie odbiorców	Brak poza interfejsem, dopóki zaznaczenie jest tylko analizowane. Jeśli administrator użyje go jako celu lub kroku lejka, osiągnięte cele i porzucenia lejka trafiają do przekazań, które włączył (4.1) — z identyfikatorem sesji, nazwą celu lub lejka i etykietą klikniętego elementu, i tylko dla kliknięć nie starszych niż ustawione w panelu administracyjnym (domyślnie dwie godziny). Starsze trafienia liczą się w interfejsie, ale nie są przekazywane.
Przekazanie do państwa trzeciego	Brak.
Okres przechowywania	Trafienie znika razem z sesją, z której pochodzi: mp_element_klicks jest w łańcuchu usuwania (mp_sitzungen_loeschen() w srv/db_worker.php), a worker elementów co godzinę usuwa trafienia, których wyświetlenie strony już nie istnieje — a więc także po drogach usuwania spoza tego łańcucha, najpóźniej po godzinie. Zanotowane kliknięcia (mp_element_offen) znikają tymi samymi drogami razem z sesją. Usunięcie zaznaczenia usuwa jego trafienia, liczniki, notatki i wzorce; wzorce nie mają związku z odwiedzającym i znikają też przy zmianie selektora albo po roku bez nowej obserwacji. Celowo nie ma osobnego okresu: byłby dłuższy albo krótszy niż okres nagrania, a jedno i drugie byłoby błędne.

A.21 Ankiety opinii — jedno pytanie do odwiedzającego, odpowiedź obok nagrania

Pole	Wpis
Cel	Administrator zadaje odwiedzającym swojej strony jedno krótkie pytanie — gotowość polecenia od 0 do 10, pięć buziek, tak/nie albo wybór — i na życzenie pytanie uzupełniające z tekstem swobodnym. Odpowiedź jest przypisywana do wizyty, aby mógł obejrzeć nagrania odwiedzających, którzy byli niezadowoleni. Pytanie, moment wyświetlenia, odsetek odwiedzających i język ustala administrator.
Kategorie osób, których dane dotyczą	Odwiedzający strony klientów, którym wyświetlono ankietę — według ustawionej przez administratora próby i najwyżej raz w ustawionym przez niego odstępie — oraz odwiedzający, którzy sami otworzyli ankietę przyciskiem przy krawędzi strony; tam odstęp zaczyna się dopiero od odpowiedzi. Zbierane jest tylko to, co odwiedzający sam wpisze: kto zamknie pytanie, pozostawia wyłącznie informację, że je wyświetlono i zamknięto.
Kategorie danych osobowych	Ocena (liczba albo wybrana opcja) wraz z wydźwiękiem (negatywny, neutralny, pozytywny), czasem i identyfikatorem ankiety jako zdarzenie wizyty (A.7): survey_shown, survey_answer i survey_dismiss. Przy pytaniu uzupełniającym TEKST SWOBODNY o długości najwyżej 500 znaków wraz z językiem strony. Przed wysłaniem mp.js usuwa adresy e-mail, adresy IP i numery telefonów, a worker robi to po raz drugi (mp_umfrage_text_filtern()); pod polem znajduje się prośba, by nie podawać danych osobowych. W przeglądarce odwiedzającego mp_umfrage (localStorage) przechowuje dla każdej ankiety wynik losowania próby i czas ostatniego wyświetlenia, a przy przycisku przy krawędzi strony czas ostatniej odpowiedzi.
Miejsce przechowywania	Ocena w session_custom_events i session_custom_event_params (A.7); tekst swobodny w mp_umfrage_text (migracja 157) — celowo osobno: to najbardziej wrażliwa część ankiety i nie należy do tabeli, z której czytają webhooki i mosty. Same ankiety, czyli wyłącznie tekst administratora, w projects.survey_json.
Podstawa prawna	Polecenie administratora (art. 28 ust. 3 lit. a RODO), wydane przez utworzenie i włączenie ankiety. Odpowiedź jest dobrowolna. Za to, czy dla pytania i pytania uzupełniającego istnieje podstawa prawna i czy są one wymienione w jego polityce prywatności, odpowiada administrator; fragment tekstu dla klientów wymienia ankietę jako osobny punkt. Nie zależy od tego żadna decyzja wobec odwiedzającego.
Kategorie odbiorców	Klient, w widoku wyników i w odtwarzaczu. Ocena jest zdarzeniem niestandardowym i dlatego trafia do przekazań, które administrator włączył dla takich zdarzeń (4.1). Tekst swobodny nie trafia do żadnego mostu: mp_umfrage_text czyta wyłącznie cfg/umfrage_lib.php.
Przekazywanie do państw trzecich	Brak — poza przekazaniem włączonym przez administratora (4.1), i tam tylko ocena.
Okres przechowywania	Razem z sesją: mp_umfrage_text jest częścią mp_sitzungen_loeschen(), ścieżki usuwania w odtwarzaczu, mp_konto_loeschen() oraz usuwania projektu i obszaru roboczego w panelu; ocena znika wraz z session_custom_events. Celowo nie ma własnego terminu — byłby dłuższy albo krótszy niż termin nagrania, a oba warianty byłyby błędne. Klucz mp_umfrage w przeglądarce jest usuwany przy wycofaniu zgody.

A.22 Wyszukiwanie wyświetlonego tekstu — które wizyty miały dany tekst na stronie

Pole	Wpis
Cel	Klient odnajduje wizyty, w których dany tekst był na jego stronie — przy wczytaniu lub wyświetlony później, np. komunikat o błędzie, wskazówka albo „Wyprzedane” — aby obejrzeć ich nagrania. Wyszukiwanie znajduje się w User Explorerze.
Kategorie osób, których dane dotyczą	Odwiedzający strony klientów, których wizyta została nagrana (A.2) i nie została rozpoznana jako zautomatyzowana.
Kategorie danych osobowych	Fragmenty tekstu, które były w zrzucie i zmianach strony (A.2), po jednym na węzeł tekstowy, oraz ich przypisanie do odsłony. Odczytywane jest to, co już zostało nagrane: obszary maskowane i dane wpisane w formularze są tam już zastąpione i nie zostaną znalezione. Jeśli strona sama wyświetla dane osobowe (strona potwierdzenia z imieniem i adresem), są one również tutaj — tak jak w nagraniu.
Miejsce przechowywania	mp_text_block (słownik na projekt, każdy fragment raz), mp_text_pv (która odsłona zawierała który fragment) i mp_text_stand (które odsłony odczytano), migracja 175. Uzupełniane co dziesięć minut przez srv/textsuche_lauf.php na własnym serwerze.
Podstawa prawna	Polecenie administratora (art. 28 ust. 3 lit. a RODO): wyszukiwanie udostępnia to samo nagranie, które zlecił. Nie zależy od tego żadna decyzja wobec odwiedzającego.
Kategorie odbiorców	Klient, jako filtr w User Explorerze. Brak przekazywania, brak mostu.
Przekazywanie do państw trzecich	Brak.
Okres przechowywania	30 dni od rozpoczęcia odsłony, krócej niż nagranie: potem usuwane są przypisanie i stan, a fragment tekstu wraz z jego najnowszą odsłoną. Jeśli sesja zostanie usunięta wcześniej (okres przechowywania, żądanie usunięcia, usunięcie w odtwarzaczu, usunięcie projektu lub konta), przypisanie znika razem z nią — bezpośrednio w mp_sitzungen_loeschen() i przy usuwaniu projektu, na wszystkich innych ścieżkach najpóźniej po dziesięciu minutach przez przebieg, który usuwa przypisania bez odsłony.

4. Część A — odbiorcy, podmioty podprzetwarzające i przekazywanie do państw trzecich

Sama droga nagrywania nie zawiera żadnego wywołania wychodzącego do podmiotów trzecich. Ustalono to 10.08.2026 r. przez przeszukanie cfg/, srv/, class/ i www/ (bez vendor i node_modules) pod kątem curl_init, curl_exec, file_get_contents z http, fsockopen i stream_context_create oraz wszystkich literałów https. Ustalanie lokalizacji odbywa się na podstawie lokalnych plików MaxMind, arkusz stylów interfejsu jest dostarczany jako wcześniej zbudowany plik z własnego serwera, obrazy flag pochodzą z /img/flags/. Od 23.09.2026 r. poczta e-mail jest wysyłana przez SMTP za pośrednictwem Namecheap Private Email (mail.privateemail.com, port 465, TLS) z nadawcą office@mouseplayer.com; funkcja PHP mail() byłaby używana tylko wtedy, gdyby nie skonfigurowano serwera SMTP, co nie ma miejsca. Ograniczenie tego przeszukania: katalogi vendor (Stripe SDK, Google Cloud SDK, PHPMailer, Symfony) nie zostały przeszukane — tam znajdują się punkty końcowe wymienionych niżej usług.

Odbiorca	Rola i co jest przekazywane	Miejsce docelowe	Zabezpieczenie	Status
Stripe	Obsługa płatności dla kont KLIENTÓW. Adres e-mail, imię i nazwisko, adres rozliczeniowy oraz dane płatnicze klientów. www/billing_ajax.php:134 ustawia klucz API; wiersze 381 i 687 przekazują customer_email; wiersz 48 ustawia billing_address_collection='required'; wiersz 54 customer_update dla adresu i nazwiska; wiersze 462/527/672 przekazują metadane. Kanał zwrotny www/api/webhook_stripe.php, tabela stripe_events. Bez danych odwiedzających.	USA	Umowa powierzenia przyjęta 01.08.2026 jako część warunków przyjętych przy zakładaniu konta (oświadczenie administratora). Strona umowy: Stripe Payments Europe, Ltd.; dla przekazań do USA Stripe, Inc. Moduł 2 (administrator do podmiotu przetwarzającego). Wynika to z podziału ról, a nie z odczytu dokumentu: MousePlayer jest administratorem przekazywanych danych konta i rozliczeń, a Stripe w tym zakresie podmiotem przetwarzającym. Samej przyjętej wersji nie sprawdzono; jeśli stanowi inaczej, ma pierwszeństwo.	Stan na 16.10.2026: brak trybu produkcyjnego — oba miejsca na klucze zawierają klucze testowe i nie są przetwarzane żadne rzeczywiste płatności.
VIES (Komisja Europejska)	Weryfikacja podanego numeru identyfikacyjnego VAT KLIENTA przez publiczny interfejs REST systemu wymiany informacji o VAT (cfg/lib.php). Przekazywane są kod kraju i numer VAT; zwracana jest ważność oraz w stosownych przypadkach nazwa i adres przedsiębiorstwa, zapisywane przy koncie (B.1). Brak danych odwiedzających.	UE	Organ publiczny Unii; nie jest podmiotem przetwarzającym, umowa nie jest wymagana. Zapytanie służy weryfikacji danych podatkowych klienta.	W użyciu, gdy tylko klient poda numer VAT.
Telegram	Powiadomienie o zgłoszeniu do wsparcia. Do 11.08.2026 cfg/lib.php przesyłał CAŁE zgłoszenie: status użytkownika wraz z jego identyfikatorem, adres e-mail, temat, 'IP / Kraj' z NIESKRÓCONYM adresem IP, adres URL źródła oraz pełną treść wiadomości. Od 11.08.2026 (commit 02846c2, cfg/lib.php) wychodzi wyłącznie jeden stały ciąg znaków: 'MousePlayer: es liegt eine neue Supportanfrage vor.' Żadnej zmiennej, bez parse_mode, świadomie także bez numeru sprawy i bez odnośnika pochodzącego z żądania. Samo zgłoszenie jest nadal zapisywane bez zmian w support_requests — dane przestały wychodzić na zewnątrz, ale nie zniknęły.	Poza UE	Do 11.08.2026: brak — Telegram nie oferuje umowy powierzenia przetwarzania dla botów. Od 11.08.2026 nie jest ona już potrzebna: powiadomienie nie zawiera danych osobowych, więc Telegram nie jest ani podmiotem przetwarzającym, ani odbiorcą. Decyzja właściciela z 11.08.2026: kanał zostaje, wiadomość zostaje zredukowana do samego sygnału, adres IP został usunięty. Strażnik (ai/pruefstand/test_telegram_signal.php) sprawdza nie wynik, lecz możliwość — które zmienne w ogóle mogą dotrzeć do wiadomości; cztery są dozwolone, 15 cech zakazanych, a tekst musi być ciągiem w apostrofach bez interpolacji.	AKTYWNE, ale bez danych osobowych — rozbrojone 11.08.2026. TELEGRAM_BOT_TOKEN i TELEGRAM_CHAT_ID są nadal ustawione w .env; wychodzi już tylko sygnał.
Google reCAPTCHA	Logowanie, rejestracja, formularz wsparcia, strona rozliczeń. Weryfikacja po stronie serwera w www/login.php:31-45 i cfg/lib.php:6337 wobec https://www.google.com/recaptcha/api/siteverify; po stronie przeglądarki w www/billing.php:1290.	USA	reCAPTCHA pozostaje w produkcji. Warunki przetwarzania danych Google przyjęte 01.08.2026 (oświadczenie administratora). Strona umowy: Google Ireland Limited; dla przekazań do USA Google LLC. W systemie deweloperskim usługa jest wyłączona (mp_recaptcha_aktiv() zwraca !mp_ist_dev()), w produkcji włączona — tam przekazanie następuje przy każdym logowaniu, rejestracji, operacji hasłowej i rozliczeniowej.	Nieaktywne wyłącznie na tej instancji: mp_recaptcha_aktiv() jest zdefiniowana w cfg/config.php:131-133 jako !mp_ist_dev(), a APP_ENV=dev. W produkcji aktywne.
Google BigQuery	Nocny eksport do WŁASNEGO projektu GCP klienta. srv/cron_integration_bigquery.php:95-100 wybiera session_id, channelid, visitor_id, custom_user_id, ip_address, country, referrer, user_agent, screen_width, screen_height, start_time, end_time, duration_seconds, device_type i ładuje je jako NDJSON do visitor_sessions_YYYYMMDD.	Region wybrany przez klienta	Miejscem docelowym jest własny projekt klienta, więc importerem jest klient. Klucz konta usługi jest przechowywany w postaci zaszyfrowanej w projects.bigquery_sa_json (decrypt_sa_key, klucz BIGQUERY_SA_AES_KEY z .env).	NIEAKTYWNE. projects.bigquery_active=0 we wszystkich 7 projektach, bigquery_project_id wszędzie NULL, a proces nie działa.
Webhooki klientów	srv/cron_integration_webhook.php:63-80. Treść budowana w srv/db_worker.php:1313-1323: timestamp, event_type, channel_id, session_id, bezpośredni link do odtwarzacza 'https://<host>/player?id=...&session=...' oraz parametry zdarzenia. Osobne formatowanie dla Slacka i Discorda (mp_format_webhook_body, cfg/lib.php:5978).	Nieokreślone — ustala klient	Miejsce docelowe wybiera klient, leży więc ono w zakresie własnej odpowiedzialności administratora. Tak, cel jest odnotowywany dla każdego klienta (decyzja administratora, 17.08.2026). Znajduje się już przy projekcie; brakuje zapisu, KTO i kiedy go ustawił. Od 17.08.2026 każda zmiana celu webhooka trafia do dziennika zmian (log_audit, akcja update_integrations, pole webhook_host). Odnotowywany jest wyłącznie host, a nie pełny adres: ścieżka webhooka często niesie sekret — Slack i Discord umieszczają klucz w URL — a dziennik zmian jest na to złym miejscem. Dla pytania, dokąd dane zdarzeń opuszczają dom, host wystarczy.	NIEAKTYWNE. projects.webhook_active=0 i webhook_url NULL we wszystkich 7 projektach. Proces wysyłający działa.
Meta (Conversions API)	Tylko jeśli administrator włączy most i zapisze własny token dostępu. Przekazywane są wyłącznie spełnione cele danego projektu: nazwa celu, moment, identyfikator zdarzenia utworzony z sesji i celu na potrzeby deduplikacji, w razie potrzeby wartość i waluta, a także pliki cookie _fbp i _fbc oraz ciąg user agent. Nie są przekazywane imię i nazwisko, adres e-mail, numer telefonu ani adres IP — MousePlayer i tak przechowuje wyłącznie skrócony adres IP, bezużyteczny do dopasowania. Wysyłka następuje wyłącznie dla sesji z consent_state = 'granted'; bez _fbp/_fbc przekazanie w ogóle nie następuje, ponieważ bez klucza dopasowania nie miałoby celu. Kod: mp_capi_meta_ausloesen() i mp_capi_meta_zustellen() w cfg/lib.php, wysyłka przez srv/cron_integration_webhook.php.	USA	Meta nie jest podprzetwarzającym MousePlayera. MousePlayer wykonuje przekazanie na polecenie administratora — poleceniem jest włączenie mostu i zapisanie tokena. Odbiorcą jest konto reklamowe administratora; stosunek umowny z Meta, w tym gwarancje dla przekazania do USA, istnieje między administratorem a Meta, a nie między Meta a MousePlayerem. Meta przetwarza dane we własnych celach i w tym zakresie jako własny administrator.	Most dostępny od 19.08.2026, w stanie dostarczonym włączony w żadnym projekcie.
HubSpot / Pipedrive	Tylko jeśli administrator włączy most i zapisze własny token API. Przekazywany jest identyfikator klienta ustawiony przez samego administratora (setUserId()) w celu odnalezienia kontaktu, a następnie notatka z adresem nagrania sesji. Bez danych behawioralnych i bez treści nagrania. Jeśli wyszukiwanie nie znajdzie kontaktu, operacja kończy się bez dalszego przekazania. Kod: mp_crm_kontakt_suchen() i mp_crm_notiz_anhaengen() w cfg/lib.php.	USA (HubSpot), UE (Pipedrive)	Jak przy Meta: odbiorcą jest konto CRM administratora, a stosunek umowny istnieje między nim a dostawcą. MousePlayer przekazuje na jego polecenie.	Most dostępny od 19.08.2026, w stanie dostarczonym włączony w żadnym projekcie.
Google Cloud Storage (Warszawa)	Kopia zapasowa poza siedzibą, wykonywana codziennie. Udokumentowane w OFFENE_PUNKTE.md rozdział 3.3: 'mysqldump --all_databases' oraz 'tar /var/www/' — wszystkie bazy danych i całe drzewo webowe, w tym każdy plik .env. Lokalnie potwierdzone 653 MB bazy danych i 678 MB plików. Do 11.08.2026 kopia powstawała codziennie o 02:00 i wychodziła bez szyfrowania. Od 11.08.2026 jest szyfrowana na własnym serwerze przed przesłaniem (rclone crypt; zaszyfrowane są także nazwy plików i katalogów), a dwa pliki kluczy leżą na tym samym serwerze z prawami 600 — Google ich nie ma; przebieg planowy odbywa się odtąd o 03:00. Dotychczasowy, nieszyfrowany katalog docelowy z kopiami sprzed 11.08.2026 został usunięty 12.08.2026.	Polska (UE) – zasobnik w regionie europe-central2 (Warszawa), od 05.09.2026. Do tego dnia kopia znajdowała się na prywatnym koncie Google Drive, dla którego nie da się wykupić regionu danych; jako miejsce docelowe należało wskazać USA / cały świat.	Powierzenie przetwarzania na podstawie Warunków przetwarzania danych Google Cloud, przyjętych dla projektu Cloud; strona umowy Google Ireland Limited. Usuwa to odstępstwo, które figurowało tutaj od 17.08.2026 do 05.09.2026: dla prywatnego konta Google warunki te nie są dostępne, a ogólne warunki korzystania nie tworzą powierzenia przetwarzania w rozumieniu art. 28 RODO. Kopia nadal jest szyfrowana przed przesłaniem (rclone crypt, wraz z nazwami plików i katalogów), a klucze znajdują się wyłącznie u administratora — Google widzi bloki bez znaczenia. To odbiera Google treść, nie rolę.	AKTYWNE. Do 11.08.2026 bez szyfrowania i niezweryfikowane po stronie docelowej — proces korzystał z konfiguracji rclone użytkownika root, a skrypt niczego nie protokołował. Od 11.08.2026 szyfrowane; przebiegi z 11.08.2026 (uruchomiony ręcznie) i z 12.08.2026 (planowy, o 03:00) są zaprotokołowane i oba przeszły kontrolę po stronie docelowej (liczba bajtów zrzutu bazy). Codzienna praca jest tym samym wykazana, a nie tylko pierwsza próba. Właściciel sprawdził odszyfrowanie; własnego pomiaru na to nie ma. Dotychczasowy, nieszyfrowany katalog docelowy został usunięty 12.08.2026. Od 05.09.2026 kopia trafia do Google Cloud Storage w Warszawie; kopie przechowywane wcześniej na koncie Drive zostały usunięte 06.09.2026, po sprawdzeniu odtworzenia z nowego miejsca docelowego. Rodzaj konta, region danych i umowa są tym samym rozstrzygnięte. Od 06.10.2026 r. kopia zapasowa obejmuje również archiwum przeniesionych zdarzeń nagrań (/mnt/mouseplayer-dev-archive, A.1); lokalnie archiwum to znajduje się na tym samym dysku co system, a przechowywanie w innym miejscu zapewnia wyłącznie zaszyfrowana kopia. Testy odtworzenia z kopii przeprowadzono 05./06.09.2026 r. oraz 07.10.2026 r. (pełne odtworzenie danych). Kopie dzienne są przechowywane przez 7 dni, kopie tygodniowe przez 364 dni.
Namecheap	Rejestracja domen, autorytatywny DNS, przekierowanie poczty przychodzącej; od 23.09.2026 także wysyłka poczty wychodzącej przez Namecheap Private Email. Dane domenowe; treść i nadawca poczty kierowanej do MousePlayera. Przy poczcie wychodzącej: imię i nazwisko, adres e-mail i treść wiadomości do właściciela konta, przy powiadomieniu o logowaniu dodatkowo adres IP, urządzenie i przybliżona lokalizacja.	USA	Data Processing Addendum przyjęte 01.08.2026 (oświadczenie administratora); obejmuje aktualne standardowe klauzule umowne. Poczta przychodząca stale biegnie przez przekierowanie Namecheap; żaden kolejny dostawca skrzynki nie jest zaangażowany (decyzja administratora, 17.08.2026). Poczta wychodząca od 23.09.2026 wychodzi przez usługę SMTP Namecheap Private Email (TLS): powiadomienia o zmianach umowy, komunikaty dotyczące konta, powiadomienia o logowaniu i alerty strażników.	W użyciu.
Let's Encrypt (ISRG)	Wystawianie i odnawianie certyfikatów TLS. Wyłącznie nazwy domen.	USA	Publiczny urząd certyfikacji; nie przetwarza danych osobowych na nasze zlecenie.	W użyciu.
consented.eu	CMP na WŁASNYCH stronach MousePlayera, ładowany w przeglądarce odwiedzającego: cfg/header.php:48 (stub.js) i wiersz 50 (cmp.js). Dotyczy odwiedzających mouseplayer.com, a nie rejestrowania u klientów.	Miejsce przetwarzania: ten sam serwer co MousePlayer (/var/www/html/ConsentedEU na tej samej maszynie, pomiar 17.08.2026). Podstawa umowna: nie dotyczy — consented.eu prowadzi ten sam podmiot (oświadczenie administratora). Nie występuje przekazanie do osoby trzeciej.	Nie dotyczy z tego samego powodu: brak osoby trzeciej, więc brak umowy.	W użyciu na własnych stronach.

4.1 Odbiorcy włączani przez administratora

Tabela powyżej wymienia odbiorców, których angażuje sam MousePlayer. Obok nich istnieją mosty, które włącza administrator i dla których zapisuje własny dostęp. Nie są oni podprzetwarzającymi MousePlayera; stosunek umowny z nimi istnieje między administratorem a odbiorcą, wraz z gwarancjami dla państw trzecich. Wskazane są kategorie, a nie nazwy — to, którzy dostawcy są dostępni w danej kategorii, zmienia się wraz z zakresem funkcji; rozstrzyga wybór w ustawieniach projektu. Każde przekazanie uruchamiane jest po stronie serwera z srv/cron_integration_webhook.php; wynik trafia do dziennika dostarczeń (A.11).

Kategoria	Co wychodzi	Co to wyzwala
Webhook pod dowolnie wybrany adres	Nazwa zdarzenia, identyfikator kanału i sesji, adres powtórki, parametry zdarzenia. Podpisane HMAC-SHA256 po znaczniku czasu i treści.	zdarzenie subskrybowane przez administratora
System CRM	Identyfikator klienta ustawiony przez samego administratora oraz adres powtórki, dołączone jako notatka do istniejącego kontaktu. Jeśli kontaktu nie ma, nie jest tworzony.	koniec sesji z ustawionym identyfikatorem klienta
Helpdesk i system zgłoszeń	Ta sama informacja jako notatka wewnętrzna przy najnowszym otwartym zgłoszeniu nadawcy. Jeśli nie ma otwartego zgłoszenia, nic się nie dzieje.	koniec sesji z ustawionym identyfikatorem klienta
E-mail i marketing cyklu życia	Identyfikator klienta, nazwa zdarzenia i adres powtórki jako zdarzenie w systemie administratora.	koniec sesji z ustawionym identyfikatorem klienta
Sieci reklamowe (Conversions API)	Identyfikator kliknięcia z własnego pliku cookie sieci reklamowej, nazwa zdarzenia, wartość i waluta. Nie są przekazywane: imię i nazwisko, adres e-mail, numer telefonu ani adres IP.	spełniony cel przy udzielonej zgodzie
Magazyn obiektów i arkusze	Identyfikator klienta, znacznik czasu i adres powtórki jako obiekt albo wiersz we własnym magazynie administratora.	koniec sesji z ustawionym identyfikatorem klienta
Śledzenie błędów i zadań	Tytuł i opis pozycji zawierającej adres powtórki.	sygnał frustracji lub błąd JavaScript
Agenci AI administratora przez serwer MCP	Tylko do odczytu: projekty, wskaźniki, listy sesji z linkiem do odtworzenia, pojedyncze sesje z odsłonami i zdarzeniami, strony, sygnały frustracji i cele — nie zrzut strony. Uwierzytelnianie odbywa się kluczem odczytu REST API administratora.	zapytanie agenta, wyłącznie przy dostępie włączonym dla danego projektu (projects.mcp_active) i w planie płatnym

Przekazanie do państwa trzeciego: nieokreślone. Cel i dostawcę wybiera administrator; gwarancja z rozdziału V RODO spoczywa zatem na nim. W żadnym przypadku nie jest przekazywana zarejestrowana treść strony, ślad myszy ani tekst formularza — mosty niosą identyfikatory i nazwy zdarzeń, a nie powtórkę.

5. Część B — art. 30 ust. 1: czynności wykonywane w charakterze administratora

Administratorem wszystkiego w tej części jest: LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82 lok. 301, 90-437 Łódź, Polska, office@mouseplayer.com. Przedstawiciel nie jest wymagany (jednostka organizacyjna w Unii). Nie wyznaczono inspektora ochrony danych — rozdział 9. Środki techniczne i organizacyjne: rozdział 8.

B.1 Konta klientów, workspace'y i rozliczenia

Pole	Wpis
Cel	Prowadzenie własnych kont klientów MousePlayera, przynależności do workspace'ów i rozliczeń.
Kategorie osób, których dane dotyczą	Użytkownicy klienta. Zmierzone: 4 konta; workspace_users 4 owner, 1 admin, 1 viewer.
Kategorie danych osobowych	Adres e-mail, znormalizowany adres e-mail, imię i nazwisko, rodzaj działalności, rodzaj konta (przedsiębiorca lub konsument, customer_type), język, motyw. Dane firmy: nazwa i adres firmy, kraj i numer identyfikacyjny VAT wraz z wynikiem, czasem i źródłem weryfikacji oraz nazwa i adres według VIES. Logo firmy (nazwa pliku i czas; sam plik poza katalogiem WWW). Hash hasła, tokeny weryfikacji i resetu, termin ważności resetu. Logowanie dwuskładnikowe (TOTP, migracja 132): sekret w postaci zaszyfrowanej, ostatnio użyty krok czasowy, czas konfiguracji i zahaszowane kody odzyskiwania. Przełącznik powiadomienia o logowaniu (login_alert, B.7). Identyfikator urządzenia (device_id), znacznik podejrzenia is_suspicious. Ostatni PEŁNY adres IP, kraj, miasto, numer ASN i organizacja ASN. Dane rozliczeniowe: plan, waluta, identyfikator klienta Stripe, subskrypcja Stripe, okres rozliczeniowy, status, wypowiedzenie na koniec okresu. Czas ostrzeżenia z powodu braku aktywności. Historia adresów IP dla każdego użytkownika.
Miejsce przechowywania	users (user_id, email, normalized_email, device_id, password_hash, first_name, last_name, business_type, customer_type, status, lang, verify_token, reset_token, reset_expires, is_superadmin, is_suspicious, new_email, email_verify_token, last_country, last_city, last_asn_number, last_asn_org, last_ip, created_at, last_login, subscription_tier, stripe_customer_id, stripe_subscription_id, billing_period_end, billing_status, retention_grace_until, retention_grace_days). user_ip_history (user_id, ip_address, asn_number, asn_org, last_seen) — 5 wierszy, 0 z nich skróconych. workspace_users (workspace_id, user_id, role); workspace_invites (token, workspace_id, email, role, invited_by, created_at). W users od tej wersji wymienione dodatkowo: company_name, company_street, company_postcode, company_city, company_country, vat_country, vat_number, vat_valid, vat_checked_at, vat_source, vat_name, vat_address, company_logo, company_logo_at, login_alert, totp_secret, totp_enabled_at, totp_last_step, totp_recovery, theme_mode, cancel_at_period_end, inactive_warned_at, sessions_revoked_at. Liczby wierszy w tym wpisie: stan na 10.08.2026.
Podstawa prawna	Nieudokumentowana w kodzie. Art. 6 ust. 1 lit. b dla wykonania umowy (konto, obszar roboczy, rozliczenia) oraz art. 6 ust. 1 lit. c dla ustawowego przechowywania faktur (decyzja administratora, 17.08.2026). Termin podano w wierszu o przechowywaniu.
Kategorie odbiorców	Stripe (rozliczenia, zob. rozdział 4). VIES Komisji Europejskiej (weryfikacja numeru VAT, rozdział 4). Namecheap Private Email jako usługa wysyłki wiadomości e-mail do posiadacza konta: potwierdzenie konta, reset hasła, zaproszenia, powiadomienie o logowaniu, ostrzeżenie przed usunięciem z powodu braku aktywności, zawiadomienie o zmianie dokumentów umownych, raport tygodniowy, odpowiedzi wsparcia (rozdział 4). Członkowie tej samej przestrzeni roboczej widzą imię i nazwisko, adres e-mail i rolę pozostałych członków oraz rodzaj konta przestrzeni roboczej, czyli jej właściciela (owner) (Warunki korzystania, pkt 6.6), a także logo firmy właściciela; osoba zaproszona widzi to logo przez link zaproszenia, dopóki zaproszenie jest otwarte.
Przekazanie do państwa trzeciego	Stripe (USA) i Namecheap (USA); strony umów i zabezpieczenia w rozdziale 4. VIES znajduje się w Unii.
Okres przechowywania	W całości z chwilą zakończenia konta — a zakończenie następuje także bez działania właściciela. Gdy właściciel uruchomi usunięcie w ustawieniach konta, mp_konto_loeschung_ausfuehren() (cfg/lib.php) usuwa między innymi user_ip_history, live_tokens, login_sessions, remember_tokens, report_subscriptions, liczniki limitu nagrań, api_keys, workspace_invites, workspace_users, workspaces i users; audit_logs, bot_review_labels i wpisy w mp_loesch_archiv zostają pozbawione powiązania z osobą. Od 07.10.2026 (migracja 189) ta ścieżka najpierw archiwizuje: konto zostaje zablokowane, logowania odwołane, własne obszary robocze i projekty ukryte i już nienagrywane; to, co można przywrócić, przechowywane jest w mp_loesch_archiv. Po 30 dniach – lub od razu, jeśli właściciel tak wybierze – db_worker trwale usuwa dane wskazanym łańcuchem, a następnie sprawdza, czy coś pozostało. Trwale usunięte konto nie pozostawia w archiwum ani identyfikatora, ani nazwy. Jeśli właściciel pozostaje bezczynny, codzienny przebieg ostrzega po 24 miesiącach bez logowania i usuwa 30 dni później tym samym łańcuchem. Termin liczy się od ostatniego logowania, a dla konta nigdy nieużywanego — od jego założenia. Usunięcie następuje wyłącznie po doręczonym ostrzeżeniu; jeśli wysyłka się nie powiedzie, termin w ogóle nie zaczyna biec. Obie wartości znajdują się w site_settings i są konfigurowalne w panelu administracyjnym. Faktury i związana z nimi dokumentacja księgowa są przechowywane przez pięć lat, licząc od końca roku kalendarzowego, w którym upłynął termin płatności podatku (oświadczenie administratora, 17.08.2026: „5 lat, licząc od końca roku kalendarzowego, w którym upłynął termin płatności podatku"). Dane faktur są zatem wyłączone z usunięcia konta; pozostałe pola konta znikają wraz z kontem. Od 16.10.2026 r. z powodu braku aktywności ostrzegane i usuwane są wyłącznie konta w planie bezpłatnym: własny plan free i brak członkostwa w przestrzeni roboczej, której właściciel ma plan płatny. To usunięcie nie archiwizuje danych wcześniej, lecz usuwa je bezpośrednio przez wskazany łańcuch. Logo firmy jest usuwane razem z kontem jako ostatni krok usunięcia.
Logo firmy (od 07.10.2026 r.)	Klient może przesłać logo w ustawieniach (PNG, JPEG, WebP). Przechowywany jest nie dostarczony plik, lecz obraz narysowany na nowo na serwerze, poza katalogiem WWW (daten/firmenlogos/, migracja 184). Jest ono widoczne dla samego konta, superadministratora, członków przestrzeni roboczych, których właścicielem jest to konto, oraz osób zaproszonych przez link zaproszenia, dopóki zaproszenie jest otwarte; wszystkie inne żądania otrzymują taką samą odpowiedź jak w przypadku braku logo.
Eksport konta (art. 15 ust. 3, art. 20 RODO)	Posiadacz konta może w ustawieniach, po podaniu hasła, pobrać archiwum ZIP z danymi swojego konta w formacie JSON oraz logo firmy. Tabele są ustalane na podstawie schematu (kolumny odwołujące się do konta); sekrety, takie jak hash hasła, tokeny i sekret TOTP, są pomijane. Nieudane próby są liczone w dzienniku zmian i po pięciu próbach w ciągu 15 minut blokują eksport. Archiwum powstaje wyłącznie jako plik tymczasowy na potrzeby dostarczenia.
Dalsze dane konta (stan na 16.10.2026)	legal_acceptances: akceptacja dokumentów umownych (w tym pouczenia o odstąpieniu i żądania natychmiastowego rozpoczęcia) oraz doręczone zawiadomienia o zmianach, każdorazowo z kontem, pełnym adresem IP, identyfikatorem przeglądarki, językiem, sumami kontrolnymi wersji i pochodzeniem wpisu; najnowsza akceptacja (nie zawiadomienia) istniejącego konta jest zachowywana tak długo, jak istnieje konto, aby można było wykazać, którą wersję zaakceptował bieżący klient (od 16.10.2026 r.); starsze akceptacje, zawiadomienia oraz wiersze usuniętych kont są usuwane 730 dni po danej akceptacji lub zawiadomieniu (kwalifikacja podstawy prawnej przechowywania po zakończeniu konta pozostaje otwarta po stronie administratora). report_subscriptions: subskrypcja raportu tygodniowego z tokenem wypisania i ostatnią wysyłką; znika wraz z kontem. workspace_transfers: przekazanie przestrzeni roboczej na adres e-mail z tokenem i terminem ważności; znika wraz z przestrzenią roboczą. mp_dashboards: własne pulpity konta dla poszczególnych projektów; znikają wraz z kontem lub projektem. Firmowe SSO (sso_providers, sso_identities, sso_requests, sso_assertions, sso_policies, migracje 187 i 188): konfiguracja dostawcy tożsamości wybranego przez właściciela przestrzeni roboczej w postaci zaszyfrowanej, dla każdego konta tylko skrót identyfikatora u dostawcy, żądania logowania ważne przez pięć minut; serwer odpytuje przy tym punkty końcowe tego dostawcy, a odbiorcą jest dostawca wybrany przez klienta. Według stanu na 16.10.2026 żadna przestrzeń robocza nie ma skonfigurowanego dostawcy. Limit nagrań (mp_aufnahme_monat, mp_aufnahme_sitzung, migracja 178): liczniki na właściciela i miesiąc, dla każdej sesji tylko skrót z projektu i identyfikatora sesji; skróty z minionych miesięcy usuwa codzienny przebieg, liczniki znikają wraz z kontem.

B.2 Dzienniki dostępu, bezpieczeństwa i zmian we własnym panelu

Pole	Wpis
Cel	Protokołowanie dostępu, zdarzeń bezpieczeństwa i zmian we własnym panelu MousePlayera.
Kategorie osób, których dane dotyczą	Odwiedzający i użytkownicy mouseplayer.com oraz www.mouseplayer.com.
Kategorie danych osobowych	PEŁNY adres IP, user agent, kompletna ścieżka żądania, kraj, miasto, rodzaj urządzenia, system operacyjny, przeglądarka, ASN. Zdarzenia bezpieczeństwa z częściowo skróconym adresem IP: WSS_CONNECT 1261, url_excluded 71, consent_blocked 24. Dziennik zmian: użytkownik, workspace, akcja, cel, szczegóły w formacie JSON, adres IP.
Miejsce przechowywania	mouseplayer_logs (log_id, ip_address, user_agent, page_url, created_at, country_code, asn_number, asn_org, city, device_type, os_name, browser_name) — 10.08.2026 r. 36409 wierszy, 8,5 MB, bez skróconych wartości IP. Od 17.08.2026 r. log_mouseplayer_traffic() (cfg/lib.php) umieszcza przy każdym wywołaniu tylko jeden surowy wiersz w kolejce Redis queue:traffic_logs; ustalanie lokalizacji GeoIP i ASN, klasyfikację przeglądarki i urządzenia oraz zapis — wraz z users.last_ip i polami lokalizacji konta — wykonuje db_worker. Adres ustala getBestClientIP(); nagłówki są uznawane tylko wtedy, gdy połączenie pochodzi od poprzedzającego nginx. security_access_logs (id, ip_address, user_agent, event_type, details, created_at) — 10.08.2026 r. 1354 wiersze, w tym 350 skróconych. audit_logs (log_id, user_id, workspace_id, action, target_id, details, ip_address, created_at) — 10.08.2026 r. 666 wierszy, nieskróconych. banned_ips (ip_address, scope, reason, banned_at, expires_at).
Podstawa prawna	Nieudokumentowana w kodzie. Jedynym utrwalonym uzasadnieniem jest komentarz w class/Server.class.php:421-425, który odróżnia regułę A (pełny adres, dla BEZPOŚREDNICH wywołań własnej aplikacji) od reguły B (adres skrócony, dla danych odwiedzających). Wyjaśnia to decyzję projektową, ale nie jest podstawą prawną. Art. 6 ust. 1 lit. f. Cel: obrona przed nadużyciami i rozliczalność (potwierdzone przez administratora, 17.08.2026). Test równowagi: bez dziennika nie da się ani wykryć ataku, ani później ustalić, kto dokonał zmiany. Nie ma łagodniejszego środka o tym samym skutku — dziennik zanonimizowany traci właśnie to przypisanie, o które chodzi. Ingerencję ogranicza termin (72 godzin dla dziennika bezpieczeństwa, 60 dni dla dziennika dostępu, 60 dni dla dziennika zmian) oraz to, że dzienniki dotyczą wyłącznie dostępu do samej aplikacji, a nie nagrywanych odwiedzających. Dotyczy to użytkowników klienta, którzy korzystają z usługi świadomie i liczą się z rejestrowaniem swoich czynności administracyjnych.
Kategorie odbiorców	Sam MousePlayer. audit_logs jest dodatkowo widoczna dla superadmina (www/admin.php).
Przekazanie do państwa trzeciego	Brak.
Okres przechowywania	mouseplayer_logs: 60 dni. security_access_logs: 72 godzin. banned_ips: z upływem expires_at; wpisy ustawione ręcznie bez terminu pozostają, dopóki operator ich nie zniesie. audit_logs: 60 dni, nowość od 17.08.2026. user_ip_history: 90 dni od ostatniego wystąpienia adresu, nowość od 24.09.2026; najpóźniej wraz z kontem. Wszystkie wartości znajdują się w site_settings i są konfigurowalne w panelu administracyjnym. To, że dziennik zmian trwa dłużej niż dziennik bezpieczeństwa, jest zamierzone: dziennik dostępu odpowiada na pytanie, kto tu był; dziennik zmian — kto coś zmienił. Ten drugi jest dowodem rozliczalności z art. 5 ust. 2 i musi przetrwać spór, który ujawnia się dopiero po miesiącach.

B.3 Zgłoszenia do wsparcia

Pole	Wpis
Cel	Przyjmowanie i obsługa zgłoszeń do wsparcia. Od 30.09.2026 obejmuje to także przetłumaczenie wiadomości i przygotowanie projektu odpowiedzi przez model językowy na własnym sprzęcie; każdy projekt sprawdza i wysyła człowiek.
Kategorie osób, których dane dotyczą	Osoby zgłaszające, zalogowane albo nie.
Kategorie danych osobowych	Adres e-mail, temat, treść wiadomości. PEŁNY adres IP — REMOTE_ADDR, nadpisany przez HTTP_X_FORWARDED_FOR, bez skracania. User agent, adres URL pochodzenia. Pole kodu kraju jest odczytywane z nagłówka HTTP_CF_IPCOUNTRY; ponieważ przed serwerem nie działa Cloudflare, zawsze zawiera ono wartość zastępczą XX albo jest puste.
Miejsce przechowywania	support_requests (id, user_id, channelid, email, reason, message, status, ip_address, user_agent, source_url, country_code, created_at). Od 30.09.2026 dodatkowo mp_support_ki: jeden wiersz na zadanie (tłumaczenie, projekt, tłumaczenie własnego projektu) z tekstem przygotowanym dla modelu, wynikiem, nazwą modelu i czasem trwania; powiązany ze zgłoszeniem kluczem obcym.
Podstawa prawna	Art. 6 ust. 1 lit. b, o ile osoba pytająca jest klientem, a zapytanie dotyczy wykonania umowy; w pozostałych przypadkach art. 6 ust. 1 lit. f. Na tej samej podstawie opiera się pełny adres IP: służy obronie kanału wsparcia przed nadużyciami. Masowych lub powtarzających się przesyłek, gróźb i innych działań na szkodę nie da się bez niego ani wykryć, ani powstrzymać, a adres skrócony tego rozróżnienia nie niesie. Decyzja administratora z 17.08.2026.
Kategorie odbiorców	Do 11.08.2026: Telegram. cfg/lib.php wysyłał do api.telegram.org status użytkownika, adres e-mail, temat, NIESKRÓCONY adres IP wraz z krajem, adres URL źródła oraz pełną treść wiadomości. Od 11.08.2026: brak. Do api.telegram.org trafia już tylko stały ciąg 'MousePlayer: es liegt eine neue Supportanfrage vor.', bez jakiejkolwiek zmiennej; Telegram nie otrzymuje więc danych osobowych i nie jest odbiorcą. Samo zgłoszenie pozostaje bez zmian w support_requests. Model językowy (od 30.09.2026): brak. Działa na własnych komputerach z kartą graficzną, w tej samej sieci lokalnej i w tym samym miejscu co serwer; pobierają one zadanie przez HTTPS, każde żądanie podpisane własnym sekretem. Otrzymują treść wiadomości, temat, informację, czy osoba zgłaszająca ma konto, oraz ścieżkę strony źródłowej – adresy e-mail i ciągi od sześciu cyfr są wcześniej zastępowane (mp_supki_saeubern() w cfg/support_ki_lib.php), we własnym projekcie odpowiedzi tylko adresy e-mail. Nie adres IP, nie adres e-mail osoby zgłaszającej. Żadnej zewnętrznej usługi AI, także jako rozwiązania awaryjnego.
Przekazanie do państwa trzeciego	Do 11.08.2026: Telegram, poza UE; dla botów nie jest dostępna umowa powierzenia przetwarzania — zob. rozdział 4. Od 11.08.2026: brak. Powiadomienie wysyłane do api.telegram.org nie zawiera już danych osobowych, więc przekazanie do państwa trzeciego nie następuje. Kanał istnieje nadal jako sam sygnał — zob. rozdział 4.
Zautomatyzowane podejmowanie decyzji	Brak. Model jedynie proponuje tekst; nic nie jest wysyłane automatycznie – człowiek czyta projekt, w razie potrzeby go zmienia i sam go wysyła. Nie jest to decyzja w rozumieniu art. 22 RODO.
Okres przechowywania	730 dni, egzekwowane przez codzienny przebieg w srv/db_worker.php; wartość znajduje się w site_settings pod kluczem retention_evidence_days i jest konfigurowalna w panelu administracyjnym. Przy usunięciu konta zapytanie pozostaje, lecz traci powiązanie z kontem (user_id staje się NULL); polityka prywatności mówi o tym wprost. Wiersze w mp_support_ki są usuwane razem ze zgłoszeniem (ON DELETE CASCADE, migracja 168), każdą ścieżką usuwania.

B.4 Akceptacja regionalnych zasad rejestrowania przez klienta

Pole	Wpis
Cel	Wykazanie, że klient zaakceptował regionalne zasady rejestrowania — oświadczenie umowne.
Kategorie osób, których dane dotyczą	Użytkownicy klienta.
Kategorie danych osobowych	Identyfikator użytkownika, e-mail, regiony, wersja tekstu, suma kontrolna tekstu, język. PEŁNY adres IP i user agent — celowo, a powód jest utrwalony w ai/migrations/018_consent.sql: chodzi o akceptację umowy przez partnera handlowego, a nie o dane odwiedzającego.
Miejsce przechowywania	consent_region_acceptances (id, channelid, workspace_id, user_id, user_email, regions, text_version, text_checksum, text_lang, ip_address, user_agent, accepted_at) — 0 wierszy.
Podstawa prawna	Dowód oświadczenia umownego, zgodnie z uzasadnieniem w nagłówku migracji.
Kategorie odbiorców	Sam MousePlayer.
Przekazanie do państwa trzeciego	Brak.
Okres przechowywania	730 dni od akceptacji — ten sam termin co dla pozostałych dowodów (support_requests, legal_acceptances; w legal_acceptances najnowsza akceptacja istniejącego konta jest ponadto zachowywana, zob. B.1), ponieważ odpowiadają na to samo pytanie: kto, na co i kiedy się zgodził. Wartość znajduje się w site_settings pod kluczem retention_evidence_days; egzekwuje ją codzienny przebieg w srv/db_worker.php.

B.5 Odwiedzający naszą własną stronę

Pole	Wpis
Cel	Prowadzenie samej mouseplayer.com: okno zgody, obrona przed dostępem automatycznym, demonstracja na stronie głównej oraz dzienniki serwera WWW.
Kategorie osób, których dane dotyczą	Odwiedzający mouseplayer.com.
Kategorie danych osobowych	Adres IP — w dziennikach serwera nieskrócony —, czas, żądany adres, kod statusu, identyfikacja przeglądarki. Dla demonstracji dodatkowo pozycje kursora i kliknięć, losowo nadany identyfikator sesji oraz kraj wyprowadzony z adresu. Dla reCAPTCHA adres oraz cechy urządzenia i zachowania.
Miejsce przechowywania	Dzienniki dostępu nginx (/var/log/nginx/) i Apache, oba z pełnym adresem, logrotate codziennie z 14 rotacjami. Od 16.08.2026 nginx jest pierwszą warstwą, która widzi adres odwiedzającego; Apache stoi za nim na loopbacku i otrzymuje go przez protokół PROXY względnie X-Forwarded-For. Dane demonstracji nie są przechowywane, lecz tylko przekazywane w danej chwili.
Podstawa prawna	Demonstracja: zgoda, art. 6 ust. 1 lit. a — mechanizm ten działa od 17.08.2026. reCAPTCHA i dzienniki serwera: prawnie uzasadniony interes, art. 6 ust. 1 lit. f. Art. 6 ust. 1 lit. f. Cel: obrona przed nadużyciami i rozliczalność (potwierdzone przez administratora, 17.08.2026). reCAPTCHA: bez ochrony przed dostępem automatycznym logowanie, rejestracja, formularz wsparcia i strona rozliczeń stoją otworem dla ataków. Łagodniejszy środek — samo ograniczenie tempa — działa dodatkowo od 17.08.2026, ale nie zastępuje w pełni oceny punktowej. Dzienniki serwera: pełny adres jest potrzebny, aby przypisać powtarzalny lub masowy dostęp temu samemu nadawcy; adres skrócony tego rozróżnienia nie niesie. Ingerencję ogranicza 14-dniowy termin oraz to, że dzienniki nie są łączone z innymi danymi.
Kategorie odbiorców	Google Ireland Limited (reCAPTCHA) i consented.eu (okno zgody). Przy demonstracji dodatkowo pozostali odwiedzający, którzy w tej samej chwili mają otwartą stronę główną — widzą kursor i kraj, nie adres.
Przekazanie do państwa trzeciego	Stany Zjednoczone poprzez reCAPTCHA; podstawa i data akceptacji zob. sekcja 4.
Okres przechowywania	Dzienniki serwera 14 dni. Demonstracja nic nie przechowuje.

Tego wpisu brakowało do 17.08.2026, mimo że sekcja 4 wymieniała już okno zgody i reCAPTCHA jako odbiorców — odpowiadające im przetwarzanie nie było nigdzie opisane. Publiczna polityka prywatności została tego samego dnia uzupełniona o ten sam przedmiot (jej sekcja 10); oba teksty należy czytać wzajemnie.

B.6 Otwarcia linku udostępniania

Pole	Wpis
Cel	Dowód, jak często i skąd link udostępniania był używany. Taki link otwiera pełne nagranie bez logowania; bez tego rejestru nie da się później ustalić ani ile razy go użyto, ani czy opuścił zamierzony krąg.
Kategorie osób, których dane dotyczą	Osoby otwierające link udostępniania — zwykle pracownicy klienta lub wybrani przez niego odbiorcy. Nie nagrywani odwiedzający; to inne osoby.
Kategorie danych osobowych	Adres IP osoby otwierającej (nieskrócony), identyfikacja przeglądarki, czas, identyfikator linku.
Miejsce przechowywania	share_views (migracja 043), powiązana z session_shares kluczem obcym z ON DELETE CASCADE.
Podstawa prawna	Art. 6 ust. 1 lit. f. Cel: obrona przed nadużyciami — link bez logowania to dokładnie ten rodzaj adresu, który bywa przekazywany dalej. Test równowagi: nie ma łagodniejszego środka: adres skrócony nie niesie pytania, czy dwa otwarcia pochodzą z tego samego miejsca, a bez niego przekazania nie da się ani wykryć, ani wykazać. Ingerencja jest wąsko ograniczona — dotyczy nie osoby nagranej, lecz otwierającej, a wiersz ginie wraz z linkiem. Dotyczy osób otwierających link do cudzego nagrania, które muszą liczyć się z rejestrowaniem tego dostępu. (decyzja administratora, 17.08.2026)
Kategorie odbiorców	Brak. Rejestr nie opuszcza własnej bazy danych.
Przekazanie do państwa trzeciego	Brak.
Okres przechowywania	Wraz z linkiem. Gdy wygaśnie lub zostanie cofnięty, rejestr znika wraz z nim przez klucz obcy. Link żyje najwyżej 90 dni, domyślnie 7 — dłuższego aplikacja nie utworzy.

To, że wiersz ginie wraz z linkiem, nie jest tu wygodą, lecz połową podstawy prawnej: rejestr przeżywający link nie ma już celu, który by go uzasadniał.

B.7 Aktywne logowania i ich odwoływanie

Pole	Wpis
Cel	Pokazanie właścicielowi konta, gdzie jest ono zalogowane, i umożliwienie mu zakończenia pojedynczego urządzenia albo wszystkich pozostałych. Bez tej listy przejętego logowania nie da się ani rozpoznać, ani zakończyć: do 28.08.2026 zmiana hasła unieważniała jedynie ciasteczka „pozostań zalogowany”, podczas gdy trwające sesje żyły dalej jako pliki — zmierzone 24 do 54 minut.
Kategorie osób, których dane dotyczą	Właściciele i członkowie konta klienta. Nie nagrywani odwiedzający; to dwie różne osoby.
Kategorie danych osobowych	Adres IP (nieskrócony), identyfikator przeglądarki, a z niego wyprowadzone: przeglądarka, system operacyjny i rodzaj urządzenia, przybliżona lokalizacja (miasto i kraj) z adresu, czas zalogowania i ostatniej aktywności. Sam identyfikator sesji nie jest zapisywany, tylko jego skrót SHA-256. Do tego odcisk urządzenia — skrót z przeglądarki, systemu operacyjnego, rodzaju urządzenia i zakresu adresów (/24 lub /48, nigdy pełnego adresu), po którym rozpoznawane jest urządzenie już znane.
Gdzie przechowywane	login_sessions (migracja 094), powiązane przez remember_selector z remember_tokens (migracja 037).
Podstawa prawna	Art. 6 ust. 1 lit. b w związku z art. 32. Cel: bezpieczeństwo konta — to przetwarzanie jest środkiem technicznym, a nie jego produktem ubocznym. Wyważenie: nie ma łagodniejszego środka. Skrócony adres nie odpowiada właśnie na to pytanie, dla którego lista istnieje („czy to byłem ja?”), a bez przeglądarki i lokalizacji jednego wiersza nie odróżni się od drugiego. Dane i tak powstają przy każdym logowaniu; nowe jest wyłącznie to, że stają się widoczne i odwoływalne. Widzi je wyłącznie sam właściciel konta.
Kategorie odbiorców	Brak. Lista nie opuszcza naszej bazy danych.
Przekazywanie do państw trzecich	Brak.
Okres przechowywania	90 dni od ostatniej aktywności, a w całości wraz z zakończeniem konta. Zakotwiczone w ostatniej aktywności, a nie w utworzeniu: urządzenie zalogowane od miesięcy, ale używane wczoraj, to logowanie aktualne i należy do listy.

Od 28.08.2026 z tych samych danych powstaje dodatkowo powiadomienie dla właściciela konta, gdy jego konto zostanie otwarte z urządzenia, które dotąd się nie pojawiło. Trafia ono na własny adres osoby, której dane dotyczą, i do nikogo więcej; odbiorca w rozumieniu art. 4 pkt 9 przez to nie dochodzi. Każde konto może je wyłączyć w ustawieniach, nie tracąc samej listy — domyślnie jest włączone, ponieważ powiadomienie bezpieczeństwa, które trzeba najpierw włączyć, nie dociera właśnie do tych, którzy go potrzebują. Odcisk opiera się celowo na zakresie adresów, a nie na pełnym adresie: łącze przy nocnym zestawieniu dostaje inny IP, a z pełnym adresem powiadomienie przychodziłoby co rano — sygnał straciłby wartość, a wraz z nim powiadomienie.

Dwie decyzje wymagają tu wyjaśnienia. Zapisywany jest skrót identyfikatora sesji, a nigdy on sam: w przeciwnym razie zrzut bazy danych wydawałby ważne ciasteczka sesyjne, a zrzut w niepowołanych rękach to dokładnie ten przypadek, przeciwko któremu zbudowano całą tę tabelę. A odwołany wiersz nie jest usuwany, lecz oznaczany jako odwołany — usunięty wiersz byłby dla sprawdzenia wykonywanego przy każdym wywołaniu sesją nieznaną, a nieznana może zostać dopisana z powrotem. Odwołanie samo by się zniosło.

B.8 Komunikaty eksploatacyjne i wstrzymane wiadomości e-mail (urgent_logs)

Pole	Wpis
Cel	Komunikaty eksploatacyjne dla superadministratora: usterki wykryte przez mechanizmy nadzorcze w srv/cron_status.php, przypadki wątpliwe z kontroli botów (A.19), według wyboru superadministratora anomalie projektu zamiast wiadomości e-mail oraz wychodzące wiadomości e-mail wstrzymane przez listę blokad. Blokada zapobiega wysyłaniu wiadomości na wpisane własne adresy lub na zastrzeżone domeny testowe i przykładowe; wstrzymana wiadomość jest tu zapisywana, aby można było ustalić, co zostałoby wysłane.
Kategorie osób, których dane dotyczą	Użytkownicy klientów i inni odbiorcy wstrzymanej wiadomości e-mail; pośrednio odwiedzający, których identyfikator sesji występuje w komunikacie kontroli botów.
Kategorie danych osobowych	Źródło, temat, treść komunikatu, czasy powstania, ostatniego powtórzenia, załatwienia i wysyłki wiadomości. W przypadku wstrzymanej wiadomości e-mail adres odbiorcy i pełna treść wiadomości tekstem jawnym — zależnie od rodzaju na przykład imię i nazwisko oraz adres e-mail, a przy powiadomieniu o logowaniu dodatkowo adres IP, urządzenie i przybliżona lokalizacja.
Gdzie przechowywane	urgent_logs (id, quelle, betreff, meldung, erstellt_am, zuletzt_am, erledigt_am, mail_status, mail_am, stoerung_beendet_am).
Podstawa prawna	Art. 6 ust. 1 lit. f. Cel: bezpieczeństwo eksploatacji i możliwość prześledzenia wysyłki wiadomości e-mail. Komunikaty są dostępne wyłącznie dla superadministratora i po załatwieniu są usuwane w określonym terminie.
Kategorie odbiorców	Superadministrator. Komunikaty o usterkach są dodatkowo wysyłane e-mailem na adres alarmowy operatora (za pośrednictwem Namecheap Private Email, rozdział 4); wstrzymana wiadomość nie trafia do nikogo.
Przekazywanie do państw trzecich	Brak; w zakresie wysyłki na adres alarmowy zob. Namecheap w rozdziale 4.
Okres przechowywania	Wiersz pozostaje do czasu załatwienia — przez mechanizm nadzorczy po usunięciu usterki albo ręcznie; wstrzymana wiadomość e-mail nigdy nie jest załatwiana automatycznie. Załatwione wiersze mechanizm nadzoru stanu usuwa 180 dni po załatwieniu (site_settings.retention_urgent_days, konfigurowalne w panelu administracyjnym, co najmniej 7 dni).

6. Przechowywanie — co obejmuje codzienne usuwanie, a czego nie obejmuje

Automatyczne usuwanie istnieje i od 17.08.2026 r. obejmuje wszystkie tabele z danymi osobowymi, albo przez własny termin, albo przez łańcuch usuwania sesji. Jego rdzeń znajduje się w srv/db_worker.php w bloku oznaczonym DAILY DATA PRUNING i działa wewnątrz stale uruchomionego procesu workera raz na dzień kalendarzowy (sterowane przez $lastPurgeDate). Własne cykle w tym samym procesie mają terminy dla sesji botów (co godzinę), ostateczne usuwanie zarchiwizowanych wpisów (co 30 sekund) oraz żądania usunięcia z samodzielnego wglądu w dane. Od 07.10.2026 r. zaplanowane zadania są uruchamiane z /etc/cron.d/mouseplayer przez srv/cron_run.sh z jedną blokadą na zadanie, w tym przenoszenie zdarzeń do archiwum (co godzinę) i utrzymanie indeksu tekstu (co dziesięć minut); dzienny agregat mapy kliknięć jest budowany w nocy.

Dowód, że działa (stan na 16.10.2026): dziennik workera rejestruje codzienne usuwanie każdego dnia, ostatnio 16.10.2026 r. o 00:00:11 z zakończeniem dziesięć sekund później, oraz cogodzinny termin dla sesji botów z usuniętymi sesjami i wierszami (na przykład o 10:00:18 tego samego dnia 478 sesji z 3294 wierszami). Do tego dnia termin planu nie miał nic do usunięcia: projekty ze starszymi sesjami są w planie enterprise (365 dni), a najstarsze sesje w planie bezpłatnym są młodsze niż jego termin. To, czy zaplanowane uruchomienie się nie powiedzie albo nie nastąpi, sprawdza mechanizm nadzoru crona w srv/cron_status.php i zgłasza to w Urgent Logs (B.8) oraz e-mailem.

6.1 Objęte codziennym usuwaniem

Tabela	Wyzwalacz i termin	Dowód
mouseplayer_logs	Starsze niż 60 dni (site_settings.log_retention_days)	srv/db_worker.php, DAILY DATA PRUNING
security_access_logs	Starsze niż 72 godzin (site_settings.security_log_retention_hours)	srv/db_worker.php, DAILY DATA PRUNING
banned_ips	expires_at przypada w przeszłości; wpisy bez expires_at pozostają do zniesienia przez operatora	srv/db_worker.php, DAILY DATA PRUNING
visitor_sessions i wszystko, co jest z nią powiązane (mouse_events, session_pageviews, session_custom_events wraz z parametrami i pozostałe tabele łańcucha usuwania)	Dla każdej sesji po upływie terminu planu: free 7 dni, small 30, business 90, enterprise IFNULL(enterprise_custom_tiers.retention_days, 365). Przypadek szczególny free + is_suspicious = 24 godziny. Okres ochronny po obniżeniu planu przez GREATEST(...) z users.retention_grace_until i retention_grace_days. Usuwane przez mp_sitzungen_loeschen().	srv/db_worker.php, DAILY DATA PRUNING
payload_blob i mouse_events sesji botów	Nagranie sesji rozpoznanej jako bot jest czyszczone po upływie terminu (site_settings.retention_bot_recording_days, termin w dniach: 1; 0 wyłącza)	srv/db_worker.php, co godzinę
visitor_sessions sesji botów wraz ze wszystkim, co jest z nimi powiązane	14 dni po rozpoczęciu sesji (site_settings.retention_bot_session_days, co najmniej 8; 0 = brak odrębnego terminu)	srv/db_worker.php, co godzinę, mp_sitzungen_loeschen()
mouse_events → pliki archiwum	po 7 dniach przenoszone do skompresowanych plików archiwum dla każdej sesji; pliki są usuwane razem ze swoją sesją	srv/cron_archiv.php (co godzinę), mp_sitzungen_loeschen()

6.2 Co dodatkowo jest objęte od 17.08.2026

W tym miejscu znajdowała się lista trzynastu tabel bez jakiegokolwiek terminu. Sprawa jest załatwiona. Pięć tabel od 12.08.2026 należy do wspólnego łańcucha usuwania mp_sitzungen_loeschen(), sześć kolejnych otrzymało 17.08.2026 własny termin, a dwóch lista w ogóle nie znała: oceny tworzonej na odwiedzającego i dzień oraz generowanych z niej tekstów.

Liczby w poniższej tabeli nie są przepisane. Są odczytywane z site_settings przy wyświetlaniu tej strony — z tego samego wiersza, z którego czyta proces usuwania — i są konfigurowalne w panelu administracyjnym. Przepisana liczba byłaby drugim miejscem dla tej samej prawdy i kiedyś by się rozjechała.

Tabela	Termin	Co go egzekwuje
ai_session_features	wraz z sesją	mp_sitzungen_loeschen()
ai_timelines	wraz z sesją	mp_sitzungen_loeschen()
session_comments	wraz z sesją	mp_sitzungen_loeschen()
session_shares	razem z sesją; sam link wygasa najpóźniej po 90 dniach, domyślnie po 7; wiersz wygasłego lub cofniętego linku jest usuwany po 90 dniach, a dostępy w share_views są usuwane razem z nim	mp_sitzungen_loeschen(), mp_share_erstellen(), codzienne usuwanie
visitor_nicknames	wraz z ostatnią sesją odwiedzającego — od 28.08.2026 dotyczy to również nazwy nadanej przez administratora (A.13), która stoi w tym samym wierszu	mp_sitzungen_loeschen()
ai_visitor_value	60 dni od ocenianego dnia; dla Enterprise termin planu. Dodatkowo wraz z odwiedzającym, gdy nie pozostaje mu żadna sesja	codzienny przebieg, mp_sitzungen_loeschen()
ai_insights (zakres „visitor”)	tak samo	codzienny przebieg, mp_sitzungen_loeschen()
consent_events	730 dni od wycofania zgody — nigdy, dopóki odnosi się do nich jakaś sesja	codzienny przebieg
ip_lifetime_stats	365 dni od first_seen	codzienny przebieg
audit_logs	60 dni	codzienny przebieg
support_requests	730 dni	codzienny przebieg
consent_region_acceptances	730 dni	codzienny przebieg
legal_acceptances	730 dni po akceptacji lub zawiadomieniu; najnowsza akceptacja istniejącego konta pozostaje, dopóki konto istnieje (od 16.10.2026 r.)	codzienny przebieg
user_ip_history	90 dni od ostatniego wystąpienia adresu; najpóźniej wraz z kontem	codzienny przebieg
users (w tym last_ip), workspace_users, workspace_invites	wraz z kontem; bez logowania po 24 miesiącach i terminie ostrzeżenia 30 dni	mp_konto_loeschung_ausfuehren(), codzienny przebieg
heatmap_page_stats	nie dotyczy — tabela została usunięta 18.08.2026 r. (migracja 045)	—
mp_profil_sitzung	180 dni od POCZĄTKU sesji, co najmniej okno obliczeniowe; całkiem bez terminu, gdy tylko samej sesji już nie ma	przebieg dzienny, mp_sitzungen_loeschen()
mp_profile, mp_sequenzmuster	mp_profile, gdy tylko nie zostaje mu żadne przypisanie; mp_sequenzmuster po 180 dniach bez przeliczenia oraz natychmiast, gdy jego kanał nie ma już sesji	przebieg dzienny
ga4_daily, ga4_sessions, ga4_events	180 dni od opisywanego dnia, odpowiednio od początku sesji GA4 — a nie od momentu importu (A.14)	dzienny przebieg
mp_hm_tag, mp_hm_tag_stand	brak własnego terminu: zapisany dzień jest przeliczany z wciąż istniejących sesji najpóźniej 7 dni po ostatnim obliczeniu, przy najbliższym otwarciu listy; dni sprzed najstarszej pozostałej sesji projektu są przy tej okazji usuwane; całość razem z projektem (A.8)	przy otwarciu listy map cieplnych; mp_konto_loeschen()
mp_umfrage_text	razem z sesją (A.21) — celowo bez własnego terminu	mp_sitzungen_loeschen(), ścieżka usuwania w odtwarzaczu, mp_konto_loeschen()
mp_loesch_archiv, mp_loesch_archiv_sitzung	zarchiwizowane konta, obszary robocze, projekty oraz zarchiwizowani odwiedzający lub adresy IP (usunięcie na podstawie RODO): najwyżej 30 dni, potem trwale usunięte. Pozostaje zapis bez nazwy – dla odwiedzających i adresów IP HMAC identyfikatora, aby po odtworzeniu kopii zapasowej można było powtórzyć usunięcie, dla kont żaden identyfikator – który znika po 730 dniach	db_worker, co 30 sekund
mp_hm_klick_tag, mp_hm_ansicht_tag	730 dni od dnia, który opisuje wiersz; natychmiast razem z projektem. Brak usuwania dla poszczególnych osób: wiersze nie zawierają odniesienia do osoby (A.1)	srv/hm_aggregat_lauf.php, mp_konto_loeschen()
mouse_events_analytik	razem z odsłoną – od 07.10.2026 także na każdej ścieżce usuwającej pojedyncze sesje; wcześniej tylko razem z całym projektem (A.8)	mp_sitzungen_loeschen(), ścieżka usuwania w odtwarzaczu, mp_konto_loeschen()
login_sessions	90 dni od ostatniej aktywności; w całości razem z kontem (B.7)	codzienne usuwanie, usunięcie konta
share_views	razem z linkiem udostępniającym, przez klucz obcy z ON DELETE CASCADE (B.6)	klucz obcy
ai_churn	zapisywana od nowa przy każdym przebiegu dla każdego projektu; usuwana razem z sesjami, z których pochodzi wiersz (A.16)	srv/ai_worker.php
ai_besucher_bericht	180 dni od zlecenia; wcześniej razem z ostatnią sesją odwiedzającego (A.17)	przebieg uzupełniający w srv/ai_worker.php
mp_cwv, mp_element_klicks, mp_element_offen	razem z sesją lub odsłoną; wiersze, których odsłona nie istnieje, są usuwane co godzinę (A.7, A.20)	mp_sitzungen_loeschen(), srv/cwv_nachtragen.php, srv/element_worker.php
mp_text_block, mp_text_pv, mp_text_stand	30 dni od rozpoczęcia odsłony; wcześniej razem z sesją (A.22)	srv/textsuche_lauf.php, mp_sitzungen_loeschen()
bot_review_labels	domyślnie: brak automatycznego usuwania; konfigurowalne w latach (retention_bot_labels_years) (A.19)	srv/cron_status.php
urgent_logs	180 dni po załatwieniu (site_settings.retention_urgent_days) (B.8)	srv/cron_status.php
mp_aufnahme_quittung	7 dni (A.1)	srv/db_worker.php
mp_native_apps, mp_native_sessions	do upływu terminu ustalonego dla każdej sesji albo do odwołania; wersja zapoznawcza jest wyłączona i występuje wyłącznie w systemie deweloperskim (A.1)	cfg/native_store.php

Dwie rzeczy zmierzone, a nie założone. Po pierwsze, codzienny przebieg naprawdę działa. Widniało tu przejściowo, że nigdy nie został uruchomiony; przebieg z 17.08.2026 o 17:37:09 jest udokumentowany w dzienniku procesu roboczego. Tego dnia nic nie usunął, ponieważ oba projekty z sesjami są na planie Enterprise, a najstarsza sesja miała 27 dni — to stan zgodny z założeniem, a nie awaria. Po drugie, termin dla wyliczonej oceny jest zakotwiczony w dniu, który opisuje wiersz, a nie w momencie jego wyliczenia. Pomiar: 167 wierszy niosło 28 różnych opisywanych dni, ale tylko 6 różnych momentów wyliczenia, najnowszy sprzed kilku minut — wyliczanie wstępne przelicza ponownie, a każde przeliczenie zresetowałoby termin oparty na nim. Nigdy by nie upłynął i nikt by tego nie zauważył.

6.3 Ustalenia dotyczące łańcucha usuwania (stan na 16.10.2026)

• ŁAŃCUCH DZIAŁA W EKSPLOATACJI. 10.08.2026 r. nie został jeszcze nigdy uruchomiony, dlatego opisano go tu jako niesprawdzony. Od 17.09.2026 r. termin dla sesji botów usuwa co godzinę dane przez ten sam łańcuch usuwania mp_sitzungen_loeschen(), z którego korzystają termin planu i żądanie usunięcia; 16.10.2026 r. na przykład 401 i 478 sesji na przebieg. Sam termin planu do tego dnia nie miał nic do usunięcia (rozdział 6).
• USUNIĘTE PROJEKTY. Wybór sesji do usunięcia według terminu planu nadal łączy visitor_sessions przez INNER JOIN z projektem, przestrzenią roboczą i właścicielem i nie widzi sesji bez projektu. W zwykłym przebiegu taka sesja jednak już nie powstaje: od 07.10.2026 r. projekt jest najpierw archiwizowany, a przy ostatecznym usunięciu usuwany wraz ze wszystkimi sesjami przez usunięcie kanału (mp_kanaele_loeschen()). Stan na 16.10.2026: nie ma sesji bez projektu.
• SIEROTY. To, co wyprowadzono z sesji, należy do łańcucha usuwania albo ma własny termin (rozdział 6.2). Odsłony, których sesja nie istnieje — na przykład po przerwaniu w trakcie usuwania — mechanizm nadzoru stanu zlicza raz dziennie i usuwa automatycznie wraz z ich zdarzeniami, gdy są starsze niż dziesięć minut.
• USUWANIE ZALEŻY OD TEGO, CZY WORKER DZIAŁA. Zatrzymany worker zatrzymuje także usuwanie. Od 19.08.2026 r. mechanizmy nadzorcze zgłaszają awarie e-mailem, od 23.09.2026 r. ta poczta rzeczywiście jest wysyłana przez SMTP, a od 02.10.2026 r. odrębny własny komputer w tej samej sieci lokalnej co minutę sprawdza z zewnątrz, czy baza danych, Redis, serwer WebSocket, procesy stałe i kolejka działają prawidłowo. Należy nadal pamiętać: ActiveState=active nie dowodzi, że worker działa; wiarygodna jest lista procesów.

Ręczne drogi usuwania, dla kompletności: odtwarzacz (delete_session i delete_visitor, ograniczone do channelid, role owner i admin) oraz mp_sitzungen_loeschen() w srv/db_worker.php. Wycofanie zgody powoduje usunięcie tylko tam, gdzie ustawiono projects.consent_delete_on_withdraw; stan na 16.10.2026: wartość ta nie jest ustawiona w żadnym projekcie. Nie ma ON DELETE CASCADE od visitor_sessions w dół: łańcuch przebiega ręcznie przez wszystkie zależne tabele, a miejscem potknięcia jest mouse_events, ponieważ zdarzenia są powiązane z pageview_id, a nie z session_id; od 07.10.2026 r. obejmuje on także kopię kliknięć mouse_events_analytik.

Poza bazą danych: dzienniki dostępu nginx i Apache zawierają pełne adresy IP i są przechowywane w 14 dziennych rotacjach (logrotate). Instancja Redis systemu deweloperskiego nasłuchuje wyłącznie na 127.0.0.1 (port 6381), ma ograniczony dostęp i zapisuje swoje dane na dysku w celu zapewnienia trwałości (AOF i migawki RDB); kolejki zawierają skrócony adres IP, pełny adres URL i ładunek DOM do czasu pobrania przez workera, a mp_autoban: przez czas trwania blokady (24 h) pełny adres zablokowanego nadawcy. Pliki archiwum przeniesionych zdarzeń znajdują się w /mnt/mouseplayer-dev-archive na tym samym dysku co system i od 06.10.2026 r. są objęte kopią zapasową.

7. Zautomatyzowane podejmowanie decyzji, profilowanie i ocena punktowa

Ocena punktowa i klasyfikacja mają miejsce. Nie znaleziono decyzji wywołującej skutki prawne wobec ODWIEDZAJĄCEGO ani w podobny sposób istotnie na niego wpływającej — żadnej decyzji kredytowej, cenowej ani dostępowej, ani ujawnienia ocen komukolwiek poza klientem. W świetle zebranych dowodów art. 22 nie znajduje zastosowania wobec odwiedzających. Istnieją jednak trzy zautomatyzowane następstwa, a dwa z nich zasługują na uwagę większą, niż rejestr zwykle temu poświęca. Trzecie doszło 2 września 2026 r. i jako jedyne oddziałuje z powrotem na ODWIEDZAJĄCEGO: z przewidywania wyjścia (A.15) albo ze wskaźnika odpływu (A.16) może wynikać komunikat na stronie administratora. Pojawia się wyłącznie wtedy, gdy administrator go włączy, jego treść pochodzi od niego samego i da się go zamknąć. Nie wynika z tego skutek prawny ani podobnie istotny wpływ w rozumieniu art. 22 ust. 1 RODO — to wskazówka, a nie rozstrzygnięcie o cenie, dostępie czy zdolności kredytowej. Mimo to należy je nazwać, bo tutaj ocena po raz pierwszy opuszcza panel klienta.

Mechanizm	Co robi	Gdzie
Ocena zaangażowania (engagement score)	Mała liczba całkowita złożona z punktów za głębokość (czas trwania, liczba stron, głębokość przewijania) oraz za zauważalność zachowania (kliknięcia gniewne i puste, powroty, równoległe karty). Boty i sesje trywialne otrzymują 0. Zapisywana w ai_session_features.engagement_score (TINYINT UNSIGNED), indeks idx_engagement. Skutek: kolejność listy rekomendacji w panelu klienta.	ai/features.py:33-70; cfg/project_ai_overview.php:126-136 i 150; cfg/project_live_users.php:190
Jakość sesji	Oddziela sesje, w których niemal nic się nie wydarzyło.	visitor_sessions.session_quality; srv/db_worker.php:706-780 i 1103-1140
Klasyfikacja botów	Ustawia visitor_sessions.is_bot i bot_reason (varchar 32), indeks idx_is_bot. Należy pamiętać, że sprawdzenie bota w mp.js działa PRZED bramką zgody.	srv/db_worker.php:963-1000
Wykrywanie frustracji w przeglądarce	Generuje rage_click, dead_click i mouse_thrashing. Zmierzone: dead_click 355, rage_click 52, mouse_thrashing 5. Przy rage_click skrypt dodatkowo przekazuje znacznik do obcych widgetów czatu obecnych w przeglądarce ODWIEDZAJĄCEGO — Intercom('update', {'mouseplayer_rage_click':'DETECTED_NOW'}) oraz LiveChatWidget.call('set_session_variables', ...). Jest to zautomatyzowane dalsze ujawnienie oceny zachowania systemowi trzeciemu na stronie klienta.	www/mp.js:5786 oraz 5793-5794
Protokół tekstowy sesji	Generowany maszynowo tekst ciągły o przebiegu sesji, tworzony przez ai/build.py. Od 12.08.2026 r. srv/ai_worker.php sam uruchamia budowanie (z katalogiem roboczym i PYTHONPATH); stan na 16.10.2026: działa, a najnowsza oś czasu pochodzi z tego samego dnia. Komunikaty o błędach w ai_build.log pochodzą z wcześniejszego, już usuniętego wywołania i zostały zapisane po raz ostatni 18.08.2026 r.	ai/build.py; srv/ai_worker.php; ai_timelines
is_suspicious przy rejestracji	Ustawiane automatycznie przy rejestracji, między innymi na podstawie device_id i znormalizowanego adresu e-mail. Skutek: dla taryfy free okres przechowywania skraca się do 24 godzin.	www/register.php:159-191; srv/db_worker.php:824
Automatyczna blokada	Ponad 15 połączeń w ciągu 10 sekund, ponad 15 jednoczesnych połączeń z jednego adresu IP, ponad 50 wiadomości na sekundę oraz wiadomości zbyt duże (z wyjątkiem dużego zrzutu strony) lub nieczytelne prowadzą w serwerze WebSocket do blokady na 24 h (site_settings.autoban_stunden, od 1 do 168), przechowywanej w Redis (mp_autoban:) i rejestrowanej bez pełnego adresu. Przed serwerem WWW fail2ban blokuje adres na godzinę, jeśli w ciągu minuty ponad 100 razy przekroczy limit żądań nginx (jail mp-nginx-429). Według stanu kodu na 16.10.2026 wpisy w banned_ips ustawia już wyłącznie operator; wcześniejsze wpisy automatyczne wygasały po 7 dniach.	class/Server.class.php (autoBanIp); /etc/fail2ban/jail.d/mp-nginx-429.conf; /etc/nginx/conf.d/mouseplayer.conf
Profile zachowań — grupowanie wizyt (A.12)	k-średnich po siedmiu cechach na sesję przypisuje każdą wartą obejrzenia wizytę do jednej z co najwyżej ośmiu grup i nazywa ją na podstawie względnego położenia środka grupy. Sesje trywialne i rozpoznane jako boty są wcześniej oddzielane regułą i w ogóle nie są klastrowane. Skutek: WYŚWIETLENIE — zakładka, pigułka filtra i kolejka odtwarzania. Nie wisi na tym żadna decyzja.	ai/profile.py; cfg/project_profiles.php; mp_profil_sitzung
Wskaźnik tarcia i anomalie	Dla każdej sesji wartość od 0 do 100 z ważonych sygnałów frustracji i błędów wraz z powodami (od 26.09.2026 r.); sortuje i filtruje listy, a po osiągnięciu progu może wyzwolić webhook zasubskrybowany przez klienta. Raz dziennie poprzedni dzień każdego projektu jest porównywany z wcześniejszymi tygodniami (sesje, wskaźnik realizacji celów, udział z tarciem lub błędami JavaScript, Web Vitals) i zgłaszana jest anomalia — zliczenia dla projektu, a nie ocena pojedynczych odwiedzających. Nie zależy od tego żadna decyzja dotycząca odwiedzającego.	cfg/reibung_lib.php; cfg/anomalie_lib.php; visitor_sessions.friction_score; mp_anomalie

8. Środki techniczne i organizacyjne (art. 32) — opis ogólny

Ten rozdział jest ogólnym opisem wymaganym przez art. 30 ust. 1 lit. g oraz art. 30 ust. 2 lit. d. Każdy z poniższych środków został zweryfikowany w kodzie albo w konfiguracji; podano plik i numer wiersza, aby czytelnik mógł sprawdzić, zamiast ufać. Luki na końcu tego rozdziału są zweryfikowane tak samo i wymieniono je jednym tchem, ponieważ opis środków, który wylicza wyłącznie to, co istnieje, jest reklamą.

Obszar	Obowiązujący środek	Dowód
Szyfrowanie transportu	Połączenia z internetu są szyfrowane TLS: TLS kończy się w nginx (192.168.20.2:443), a każde żądanie HTTP jest przekierowywane na HTTPS. Serwer WebSocket nasłuchuje wyłącznie na 127.0.0.1:8081 bez własnego TLS i jest osiągalny wyłącznie przez nginx (ścieżka /mp_wss/); podobnie przez HTTPS działają tunel HTTP /mp_wst, przesyłanie dużych zrzutów stron /mp_dom i punkt pomiarowy /mp_wsfail. W obrębie własnej sieci lokalnej w tym samym miejscu połączenia z bazą danych i Redis przebiegają bez szyfrowania (zob. 8.1).	/etc/nginx/conf.d/mouseplayer.conf; srv/server.php (MP_WSS_BIND, MP_WSS_TLS); www/.htaccess
Minimalizacja danych przy zbieraniu — IP	Adres IP odwiedzającego jest skracany bezpośrednio po jego ustaleniu, a więc przed każdym odbiorcą (ostatni oktet IPv4, ostatnia grupa IPv6). 10.08.2026 r. 236 starych wierszy zawierało jeszcze pełne adresy; stan na 16.10.2026: żaden wiersz w visitor_sessions ani ip_lifetime_stats nie zawiera nieskróconego adresu.	class/Server.class.php (reguła B)
Minimalizacja danych przy rejestrowaniu — dane z formularzy	Maskowanie z twardą granicą: na poziomie 0 zastępowany jest każdy znak; niezależnie od poziomu hasła i dane płatnicze są zawsze zastępowane (kategorie password i payment, typy password/email/tel/hidden, wzorce klas i nazw card|cc|cvv|cvc|password|credit|social|pesel|nip). Wszystkie 7 projektów działa z smart_masking=0.	www/mp.js:4818-4853
Minimalizacja danych przy rejestrowaniu — DOM	Wewnątrz data-mp-mask albo .mp-masked każdy znak niebędący spacją zastępowany jest przez '*', a wszystkie atrybuty spoza MASK_KEEP_ATTRS ustawiane są na '[FILTERED]'. Dotyczy również bieżących mutacji.	www/mp.js:3934-3970 oraz 4732-4768
Minimalizacja danych przy rejestrowaniu — nazwy pól	Surowa nazwa name albo id pola formularza nie jest przesyłana; wysyłana jest wyłącznie sklasyfikowana kategoria, ponieważ w wielu sklepach surowa nazwa jest na tyle wymowna, że pozwala zidentyfikować osobę.	www/mp.js:4653-4674
Egzekwowanie zgody	Lista wykluczonych ścieżek oceniana PRZED bramką zgody, dopasowywana do ścieżki, a nie do pełnego adresu URL (71 zablokowanych połączeń). Egzekwowanie po stronie serwera jako druga siatka: przechodzą wyłącznie GRANTED, GRANTED_LATE albo wyraźne zwolnienie regionalne; WITHDRAWN, nieznany kraj i wszystko, co niejasne, prowadzą do close(1008) (24 zablokowane połączenia). Wyłącznik awaryjny site_settings.consent_gate_active=1.	class/Server.class.php:963-975 oraz 977-1004
Minimalizacja dowodu zgody	Ciąg TC nie jest przechowywany jawnie; zapisywany jest wyłącznie jego SHA-256.	visitor_sessions.tcf_hash CHAR(64); ai/migrations/018_consent.sql
Bezpieczeństwo aplikacji	Tokeny CSRF z random_bytes(32) porównywane przez hash_equals(). Cookie sesyjne z httponly=true, samesite='Lax' i secure zależnym od HTTPS. Hasła przechowywane jako skróty i weryfikowane przez password_verify(). Przygotowane zapytania we wszystkich sprawdzonych ścieżkach zapisu. Ograniczenie liczby prób logowania.	cfg/lib.php:118-132 oraz 110-112; www/login.php:60 i 28
Ochrona przed nadużyciami	Automatyczna blokada i ograniczenie połączeń w WebSocket (licznik Redis z wygaśnięciem po 10 s; 15 jednoczesnych połączeń na adres IP; blokada na 24 h w Redis, w dzienniku skrócona). Ograniczenie liczby żądań i limit połączeń na adres w nginx dla stron i nawiązywania połączeń WebSocket. fail2ban z jailem mp-nginx-429: kto w ciągu minuty zostanie odrzucony ponad 100 razy, jest blokowany na godzinę dla HTTP i HTTPS.	class/Server.class.php; /etc/nginx/conf.d/mouseplayer.conf; /etc/fail2ban/jail.d/mp-nginx-429.conf
Kontrola dostępu	Model ról w obrębie workspace (owner / admin / viewer). Usuwanie w odtwarzaczu jest ograniczone do owner i admin, a każde usunięcie jest dodatkowo zawężone do channelid — w kodzie opisane jako właściwa granica bezpieczeństwa.	workspace_users.role; www/player.php:267 oraz 275-282
Protokołowanie zmian	log_audit() zapisuje użytkownika, workspace, akcję, cel, szczegóły i adres IP. 666 wpisów, w tym create_share, revoke_share, delete_comment, player_delete_*, firewall_auto_ban (24) i superadmin_*.	cfg/lib.php:2878-2890
Linki udostępniające	channelid i session_id pochodzą wyłącznie z tokenu; pozostały ciąg zapytania jest ZASTĘPOWANY, a nie ignorowany; user_role pozostaje NULL, więc usuwanie i ponowne udostępnianie odpadają po stronie serwera, a nie tylko w interfejsie; wszystkie trzy punkty końcowe ograniczają się do sesji z tokenu; tokeny wymyślone, wygasłe i cofnięte zwracają tę samą odpowiedź.	www/share.php; www/.htaccess:77
Powierzchnia API	Pełny payload odtwarzania celowo nie jest częścią publicznego API.	www/api/v1_session_detail.php:25
Zarządzanie kluczami	Klucz konta usługi Google jest przechowywany w postaci zaszyfrowanej w projects.bigquery_sa_json i odszyfrowywany przez decrypt_sa_key() kluczem BIGQUERY_SA_AES_KEY z .env; interfejs podaje AES-256.	srv/cron_integration_bigquery.php:57; cfg/lib.php:993
Sekrety poza kontrolą wersji	Potwierdzone na bieżącym indeksie: .gitignore wymienia .env, a git ls-files znajduje wyłącznie .env.example.	git ls-files
Ekspozycja sieciowa	Z internetu osiągalne są wyłącznie porty 80 i 443 przez nginx; dla bazy danych i Redis nie ma przekierowania portów. Instancja Redis systemu deweloperskiego jest powiązana wyłącznie z 127.0.0.1 (port 6381); starsza, wspólnie używana instancja Redis (port 6379) nasłuchuje dodatkowo w sieci lokalnej. MariaDB nasłuchuje na 127.0.0.1 i w sieci lokalnej. Baza danych i Redis mają ograniczony dostęp i są osiągalne wyłącznie z własnej sieci lokalnej. Przed www.mouseplayer.com działa dodatkowe ograniczenie dostępu.	ss -ltn; konfiguracja Redis; www/.htaccess

8.1 Środki, których brak został wykazany

• Brak szyfrowania danych przechowywanych. innodb_encrypt_tables, innodb_encrypt_log i innodb_encrypt_temporary_tables są wyłączone (OFF), a nośnik nie jest szyfrowany (lsblk pokazuje sda1 bez crypt).
• Brak TLS w połączeniach z bazą danych. have_ssl=YES, ale ssl_cert, ssl_key i ssl_ca są puste. MariaDB nasłuchuje na 127.0.0.1 i w sieci lokalnej (192.168.20.2:3306); połączenia z sieci lokalnej przebiegają zatem bez szyfrowania. Mają ograniczony dostęp i nie są osiągalne z internetu (brak przekierowania portów).
• Brak szyfrowania transportu dla Redis. Połączenia z Redis przebiegają bez szyfrowania przez interfejs lokalny lub w sieci lokalnej; obie instancje mają ograniczony dostęp. Instancja systemu deweloperskiego zapisuje swoje dane na dysku w celu zapewnienia trwałości (AOF), w tym kolejki ze skróconym adresem IP, pełnym adresem URL i ładunkiem DOM, a przez czas trwania blokady (24 h) pełny adres zablokowanych nadawców.
• BRAK DZIENNIKA, KTO OGLĄDAŁ KTÓRE NAGRANIE. audit_logs zapisuje wyłącznie akcje zapisu; wywołanie player.php, ajax_get_events.php ani player_theatre.php nie jest protokołowane w ogóle. Po fakcie nie da się zatem ustalić, kto oglądał daną sesję.
• Dzienniki dostępu Apache zawierają pełne adresy IP i są przechowywane przez 14 dni.
• Pliki archiwum przeniesionych zdarzeń nagrań znajdują się na tym samym dysku co system i baza danych. Awaria tego dysku dotyka obu; przechowywanie w innym miejscu zapewnia wyłącznie zaszyfrowana kopia zapasowa, która od 06.10.2026 r. obejmuje archiwum.
• Wszystkie limity chroniące przed przeciążeniem — nginx, fail2ban i blokada w serwerze WebSocket — liczą się dla każdego adresu. Przed atakiem rozproszonym z wielu adresów nie chroni nic, co znajdowałoby się przed serwerem: nie działa przed nim żadna sieć CDN ani usługa filtrująca.
• Bezpieczeństwo fizyczne: Dostęp ma wyłącznie sam administrator. Pomieszczenie jest zamykane na klucz i objęte monitoringiem wizyjnym; inne osoby — w tym wynajmujący czy serwis sprzątający — nie mają dostępu (oświadczenie administratora, 17.08.2026). Dokładny adres celowo nie jest tu podany.
• Monitorowanie i odtwarzanie: od 19.08.2026 r. mechanizmy nadzorcze w srv/cron_status.php zgłaszają usterki, małą ilość wolnego miejsca na dysku, brakujące kopie zapasowe i nieudane zaplanowane uruchomienia w Urgent Logs (B.8) oraz e-mailem; od 23.09.2026 r. ta poczta rzeczywiście jest wysyłana przez SMTP. Od 02.10.2026 r. odrębny własny komputer w tej samej sieci lokalnej co minutę sprawdza przez punkt końcowy stanu (www/health.php) bazę danych, Redis, serwer WebSocket, procesy stałe i kolejkę oraz zgłasza awarię; nie widzi on awarii samego łącza internetowego. Docelowy czas odtworzenia: najwyżej 24 godziny. Testy odtworzenia z kopii przechowywanej poza siedzibą przeprowadzono 05./06.09.2026 r. oraz 07.10.2026 r. (pełne odtworzenie danych); przewidziano je co miesiąc (informacja administratora, 17.08.2026). Dysk USB z kopią zapasową znajduje się w tym samym pomieszczeniu co serwer — pojedyncze zdarzenie w tym miejscu obejmuje więc oba; przechowywanie poza siedzibą zapewnia wyłącznie zaszyfrowana kopia. Oba pliki kluczy są przechowywane w formie wydruku w sejfie, do którego dostęp ma wyłącznie administrator, i dzięki temu przetrwają utratę komputera.

9. Inspektor ochrony danych — ocena według art. 37 RODO

Art. 37 ust. 1 nakazuje wyznaczenie inspektora w trzech przypadkach. Przypadek lit. a, organ lub podmiot publiczny, nie ma zastosowania. Przypadek lit. c, czyli główna działalność polegająca na przetwarzaniu na dużą skalę szczególnych kategorii danych z art. 9 albo danych dotyczących wyroków skazujących z art. 10, nie jest spełniony: żadne dane szczególnych kategorii nie są przetwarzane celowo. Na tym jednak sprawa się nie kończy — jak odnotowano w A.2, migawka DOM zapisuje to, co wyświetla strona klienta, więc dane szczególnych kategorii mogą trafić do nagrania ubocznie na stronie o tematyce zdrowotnej albo finansowej. Uboczne zebranie nie jest główną działalnością polegającą na takim przetwarzaniu, więc lit. c nie zostaje uruchomiona; ryzyko jest jednak realne i jego miejsce jest w procesie wdrażania klienta, a nie w wybielającym zdaniu w tym dokumencie.

Rozstrzygający jest przypadek lit. b, który ma dwa człony. Pierwszy — główna działalność polegająca na przetwarzaniu wymagającym REGULARNEGO I SYSTEMATYCZNEGO MONITOROWANIA osób, których dane dotyczą — jest spełniony bezdyskusyjnie. Odtwarzanie sesji to ciągła, zautomatyzowana obserwacja zachowania pojedynczych osób; nie jest dodatkiem do działalności, ono JEST tą działalnością. Kto czyta ten rejestr i czuje pokusę, by podważać pierwszy człon, niech tego zaniecha: jest spełniony, a spór o niego zużywa wiarygodność potrzebną przy drugim.

Drugim członem jest DUŻA SKALA i to tutaj odpowiedź wypada dziś przecząco. Wytyczne Grupy Roboczej Art. 29 ważą cztery czynniki: liczbę osób, których dane dotyczą, ilość i zakres danych, czas trwania lub trwałość przetwarzania oraz zasięg geograficzny. Zmierzone 10.08.2026: 706 sesji odwiedzających, 329 odrębnych rekordów odwiedzających, 7 projektów, 4 konta klientów. Pod względem liczby osób nie zbliża się to nawet do dużej skali — a są to przy tym liczby z instancji deweloperskiej. Stan na 16.10.2026: 3514 różnych identyfikatorów odwiedzających zakwalifikowanych jako człowiek w ostatnich 30 dniach we wszystkich projektach, nadal daleko poniżej progu z konsekwencji 2.

Dwa z czterech czynników wskazują jednak w przeciwną stronę i rejestr powinien to powiedzieć, zamiast opierać się na tym wygodnym. ZAKRES danych przypadających na osobę jest wyjątkowo szeroki: pełny kod HTML strony wraz z tym, co strona wyświetla, dane z formularzy na poziomie pojedynczych znaków, zachowanie ruchu i kliknięć, wyprowadzona ocena behawioralna oraz prozatorska relacja z przebiegu sesji. CZAS TRWANIA jest długi: nagrania pozostają zależnie od planu do 365 dni, a w kopii zapasowej do 364 dni dłużej, choć od sierpnia 2026 r. terminy usunięcia istnieją i są stosowane dla wszystkich tabel (rozdział 6). Poniżej progu utrzymuje ocenę wyłącznie liczba osób, a to właśnie ta wielkość nie podlega kontroli MousePlayera: wyznacza ją ruch na stronie każdego klienta. Jeden średniej wielkości klient z branży e-commerce mógłby sam przesunąć produkt przez próg, bez podejmowania tutaj jakiejkolwiek decyzji.

• Konsekwencja 1 — zapisać ocenę wraz z datą. Art. 5 ust. 2 czyni rozliczalność obowiązkiem; ocena negatywna, której nigdy nie utrwalono, jest nie do odróżnienia od oceny, której nigdy nie dokonano.
• Konsekwencja 2 — określić wyzwalacz, który otwiera ocenę na nowo. Rozsądnym wyzwalaczem jest liczba monitorowanych odwiedzających miesięcznie u wszystkich klientów łącznie, uzupełniona o przegląd przy każdym nowym kliencie o istotnej wielkości. Próg i częstotliwość: Ocena z art. 37 jest powtarzana, gdy tylko łącznie u wszystkich klientów obserwowanych jest ponad 100000 użytkowników końcowych miesięcznie, a w każdym razie corocznie. Odpowiedzialny: Lukas Wójcik, właściciel. (decyzja administratora, 17.08.2026) Wdrożono 19.08.2026: liczba różnych użytkowników końcowych obserwowanych w ostatnich 30 dniach zliczana jest raz dziennie przez proces czujnika i zestawiana z tym progiem oraz z datą ostatnio utrwalonej oceny; przekroczenie któregokolwiek z nich powoduje wysłanie ostrzeżenia pocztą elektroniczną. Próg i data są ustawieniami odczytywanymi z tego samego wiersza, który cytuje niniejsze zdanie, dzięki czemu dokument i pomiar nie mogą się rozejść. Wyzwalacz, którego nikt nie mierzy, jest notatką, a nie zabezpieczeniem – taka była luka, którą ten akapit opisywał i której już nie opisuje.
• Konsekwencja 3 — sprawdzić prawo krajowe. Art. 37 ust. 4 pozwala, by prawo Unii albo prawo państwa członkowskiego wymagało wyznaczenia inspektora w dalszych przypadkach. do uzupełnienia: potwierdzenie polskiego doradcy prawnego, czy prawo polskie wymaga inspektora ochrony danych w przypadkach wykraczających poza art. 37 ust. 1
• Konsekwencja 4 — dobrowolne wyznaczenie pozostaje otwarte. Jeżeli inspektor zostanie wyznaczony dobrowolnie, art. 37 do 39 stosuje się w pełni, łącznie z publikacją i zawiadomieniem o danych kontaktowych. To decyzja, a nie stan domyślny.
• Konsekwencja 5 — sprawa odrębna, choć sąsiednia: ocena skutków dla ochrony danych na podstawie art. 35 jest bardzo prawdopodobnie wymagana od każdego KLIENTA jako administratora, wobec systematycznego monitorowania połączonego z oceną i punktacją. Jako podmiot przetwarzający MousePlayer ma obowiązek pomocy na podstawie art. 28 ust. 3 lit. f. Ocena skutków na poziomie produktu istnieje - jest nią ta opublikowana pod nazwą „Ocena skutków dla ochrony danych”. Odrębny egzemplarz nie jest wydawany klientom (decyzja administratora, 17.08.2026). Wsparcie z art. 28 ust. 3 lit. f udzielane jest na żądanie i opiera się na dokumentach publicznie dostępnych: niniejszym rejestrze, opublikowanej ocenie skutków, środkach technicznych i organizacyjnych oraz liście podmiotów podprzetwarzających.

10. Znane luki

Wszystko poniżej jest wykazane, a nie przypuszczane. Ten rozdział istnieje, ponieważ rejestr czynności przetwarzania jest narzędziem pracy: chodzi o to, by widzieć punkty otwarte, a nie o to, by przedstawić czystą kartę. Pozycje uszeregowano według tego, jak źle wypadłyby podczas kontroli, a nie według trudności naprawy.

Luka	Co zostało wykazane	Dlaczego to ma znaczenie
Pełne adresy IP w dziennikach własnej aplikacji	Stan na 16.10.2026: stary zasób w visitor_sessions i ip_lifetime_stats jest skrócony (10.08.2026 r. odpowiednio 236 i 291 nieskróconych wierszy). Celowo nieskrócone pozostają mouseplayer_logs, audit_logs, user_ip_history, login_sessions, share_views i support_requests (część B) oraz dzienniki dostępu nginx i Apache	W części B pełny adres jest uzasadniony (B.2–B.7) i ograniczony terminami. Mimo to jest tu wymieniony, ponieważ tabele te trafiają do każdej kopii zapasowej.
Stary zasób z danymi formularzy tekstem jawnym	10.08.2026 r. 173 wiersze w mouse_events przy event_type='input' zawierały niezamaskowane wartości z okresu od 2026-07-21 do 2026-07-27, w tym imiona i nazwiska. Wiersze zostały usunięte 17.08.2026 r., przed wprowadzeniem plików archiwum 18.08.2026 r.; stan na 16.10.2026: żaden z nich nie znajduje się w mouse_events	Bieżące wiersze są maskowane, a więc kontrola działa. Stare wartości nie mogą znajdować się w archiwum ani w dzisiejszej kopii zapasowej; nie jest znana żadna kopia zapasowa sprzed 17.08.2026 r., jednak jej brak nie został szczegółowo wykazany.
Linki udostępniające całkowicie omijają logowanie	/s/<40-znakowy token hex> prowadzi bezpośrednio do player.php?share=<token>; token stanowi całą barierę	Link można przekazać każdemu, dlatego kategoria odbiorców dla A.1, A.2, A.3 i A.9 jest faktycznie otwarta. Ogranicza to maksymalny okres ważności (domyślnie 7 dni, najwyżej 90), możliwość cofnięcia w każdej chwili oraz dziennik dostępów (B.6).
Brak dziennika, kto oglądał nagranie	audit_logs zapisuje wyłącznie akcje zapisu; wywołania player.php, ajax_get_events.php i player_theatre.php nie są protokołowane	Po incydencie nie da się ustalić, kto oglądał którą sesję. To pojedynczy środek, którego brak najtrudniej wytłumaczyć organowi nadzorczemu.
Cały serwer jest codziennie przenoszony poza siedzibę	srv/backup-crypt.sh codziennie wykonuje kopię wszystkich baz danych i całego drzewa WWW wraz z każdym plikiem .env, a od 06.10.2026 r. także archiwum zdarzeń nagrań; kopia jest szyfrowana na własnym serwerze przed przesłaniem (rclone crypt) i od 05.09.2026 r. przechowywana w zasobniku Google Cloud Storage w Warszawie, objętym warunkami przetwarzania danych Google Cloud (rozdział 4)	To, co codziennie opuszcza siedzibę, to nie tylko kopia nagrań sesji, lecz cały serwer wraz z produkcyjnymi sekretami kilku systemów. Szyfrowanie odbiera Google treść, a nie zakres. Jeśli oba pliki kluczy zostaną utracone, kopia zapasowa jest nie do odzyskania; dlatego są one dodatkowo przechowywane w formie wydruku w sejfie (rozdział 8.1).
To, czy kopia zapasowa dociera, jest monitorowane	Do 11.08.2026 r. bez dowodu. Od tego czasu przebieg zapisuje dziennik i sprawdza miejsce docelowe; od 19.08.2026 r. mechanizm nadzorczy porównuje ostatni udany przebieg z terminem i zgłasza brak w Urgent Logs oraz e-mailem	Luka z tego wiersza została zamknięta. Pozostaje on wymieniony, aby można było ustalić, że do 11.08.2026 r. kopia zapasowa działała bez dowodu.
Stare skrypty kopii zapasowej	Stare skrypty kopii zapasowej zostały usunięte 16.10.2026 r. Żaden z nich nie był już uruchamiany; codzienna kopia zapasowa od 11.08.2026 r. działa przez srv/backup-crypt.sh	Luka z tego wiersza jest zamknięta. Pozostaje on wymieniony, aby można było ustalić, że do 11.08.2026 r. kto przejął konto SSH pi, uzyskiwał o 02:00 uprawnienia root.
Brak szyfrowania w spoczynku, brak TLS w połączeniach z bazą danych i Redis	innodb_encrypt_* wszystkie OFF, brak zaszyfrowanego nośnika; ssl_cert/ssl_key/ssl_ca puste, MariaDB osiągalna także w sieci lokalnej; Redis z ograniczonym dostępem, ale bez szyfrowania i z trwałym zapisem na dysku (AOF)	Nagrania — w tym ładunek DOM w kolejce Redis i pliki archiwum — są czytelne dla każdego, kto ma dostęp do systemu plików; w sieci lokalnej połączenia z bazą danych przebiegają tekstem jawnym. Żadna z tych dróg nie jest osiągalna z internetu.
Część dowodów zgody to dane testowe	10.08.2026 r. 671 z 706 sesji miało consent_source='testdata' przy consent_ts IS NULL, ustawione przez ai/devdata/001_altsitzungen_markieren.sql; stan na 16.10.2026: nadal 566 takich sesji	W przypadku tych sesji protokół zgody nie może służyć jako dowód. Jest to artefakt systemu deweloperskiego, ale to samo zapytanie w środowisku produkcyjnym wymagałoby tej samej kontroli.
Wycofanie zgody niczego nie usuwa	Stan na 16.10.2026: projects.consent_delete_on_withdraw nie jest ustawione w żadnym projekcie (oceniane w gałęzi consent_withdrawn w srv/db_worker.php)	Wycofanie zgody zatrzymuje dalsze nagrywanie — czego wymaga art. 7 ust. 3 — ale klient, który zakłada, że usuwa ono także wcześniejsze nagranie, myli się. To rozróżnienie musi być opisane w dokumentacji dla klientów.
Wszystko tutaj zmierzono na instancji deweloperskiej	APP_ENV=dev; w liczbach uwzględniono projekt testowy mpconsenttest01 i dane testowe s_mptest_	Struktura tego rejestru przenosi się na produkcję; liczby nie. Produkcję trzeba zmierzyć, zanim ten rejestr zostanie użyty na zewnątrz.
Poszukiwanie wywołań wychodzących nie było wyczerpujące	Przeszukano cfg/, srv/, class/ i www/ pod kątem curl_init, curl_exec, file_get_contents z http, fsockopen, stream_context_create oraz wszystkich literałów https; katalogów vendor nie przeszukano	W drzewach vendor znajdują się punkty końcowe Stripe, Google Cloud, PHPMailer i Symfony. Usługi te są wymienione w rozdziale 4, ale stwierdzenie „nie istnieje żadne inne wywołanie wychodzące” jest ograniczone zakresem przeszukania.
Brak przełącznika na projekt dla profili zachowań	profile_aktiv jest globalnym ustawieniem operatora. mp_ki_module_katalog() w cfg/lib.php wymienia dziewięć odznaczalnych sekcji AI i żadną z nich nie są profile — projects.ki_module nie obejmuje więc tej zakładki; wpis nawigacyjny w www/project.php stoi bezwarunkowo. Pomiar 27.08.2026.	Klient, który nie chce grupowania wizyt swoich odwiedzających, nie może tego wyłączyć. Nagrywanie ma pod kontrolą, wyprowadzenia z niego już nie. Każdą inną sekcję pochodną można odznaczyć na projekt — ta jest wyjątkiem. Luka w przechowywaniu, która stała tu do 27.08.2026, jest zamknięta: mp_profile i mp_sequenzmuster mają teraz własne terminy, zob. 6.2.
Żądanie usunięcia sięga zaimportowanych sesji GA4 tylko przy włączonym mostku analitycznym	Od 01.09.2026 mp_sitzungen_loeschen() przy żądaniu z art. 17 zabiera także ga4_sessions i ga4_events, powiązane przez ga4_sessions.user_pseudo_id = visitor_sessions.custom_user_id i ograniczone do kanału. To powiązanie istnieje jednak tylko wtedy, gdy klient włączył mostek analityczny GA4 — to on zapisuje tam client_id z ciasteczka _ga. Jeśli zamiast tego wypełnia custom_user_id przez setUserId() własnym identyfikatorem, nie prowadzi żadna droga od odwiedzającego do jego zaimportowanego wiersza. Przypadek ma własny test (test_ga4_import.php, sekcja J), żeby nie poszedł w zapomnienie.	Dla tych klientów zaimportowany wiersz zostaje po żądaniu usunięcia, dopóki nie usunie go termin z A.14. Jest pseudonimowy i dla nas nieprzypisywalny — właśnie dlatego nie da się go usunąć celowo. Droga usunięcia przez samą usługę GA4 należy do administratora, który ją prowadzi.
Zgody dla zaimportowanych wierszy nie da się wykazać, można ją tylko domniemywać	Importowane jest to, co ma user_pseudo_id; trafienia bez ciasteczek przy odmowie zgody go nie mają i odpadają (A.14). Dla tych wierszy nie istnieje dowód porównywalny z consent_events — GA4 nie podaje w eksporcie atrybutu zgody, który dałoby się tu zapisać.	Dla własnych nagrań MousePlayer potrafi wykazać na sesję, na czym się opierają; dla sesji zaimportowanej nie potrafi. Rygiel jest mechaniczny i działa, ale wykazuje jedynie, że ciasteczko było ustawione — a nie na co odwiedzający przystał. Odpowiada za to administrator, który steruje zbieraniem danych w Google.
Własna nazwa odwiedzającego to niesprawdzany dowolny tekst	A.13, od 28.08.2026. mp_besucher_label_setzen() skraca do 64 znaków, usuwa złamania wiersza i sprawdza, czy odwiedzający należy do projektu — TREŚCI nie sprawdza nic i nie ma wytycznej, jakiego ma być rodzaju.	Administrator może wpisać tam szczególne kategorie z art. 9 („Pan X, wózek inwalidzki“), a żadna blokada ani ostrzeżenie się nie pojawi. Za zgodność odpowiada on, nie podmiot przetwarzający — ale podmiot przetwarzający, który udostępnia pole dowolnego tekstu i o tym milczy, stworzył sposobność. Kontrola techniczna nie jest możliwa: nazwiska nie da się maszynowo odróżnić od informacji o zdrowiu. Możliwa byłaby natomiast wskazówka przy polu.
Przykłady kontroli następczej botów bez terminu usunięcia	Jeden spseudonimizowany wektor cech na rozstrzygniętą sesję (bot_review_labels, A.19) pozostaje po sesji, dopóki nie ustawiono okresu. Domyślna wartość retention_bot_labels_years to 0 (bez limitu); operator może ustawić ją w latach.	Nie są treścią odwiedzającego, ale niosą identyfikator sesji. Czy ustawić okres, rozstrzyga operator.
Tekst swobodny ankiety jest filtrowany tylko zgrubnie	A.21, od 27.09.2026. mp_umfrage_text_filtern() zastępuje adresy e-mail, adresy IP i numery telefonów, w przeglądarce i ponownie w workerze. Nie rozpoznaje imion i nazwisk, adresów pocztowych, numerów klientów ani informacji o zdrowiu.	Odwiedzający może wpisać w pytanie uzupełniające cokolwiek, także szczególne kategorie danych z art. 9. Informacja pod polem prosi, by tego nie robić; nie jest blokadą. Podobnie jak przy własnej nazwie odwiedzającego (A.13) treści nie da się niezawodnie sklasyfikować maszynowo.

11. Prowadzenie tego rejestru

Art. 30 ust. 1 i 2 wymagają, by rejestr był prowadzony w formie pisemnej i udostępniany organowi nadzorczemu na żądanie. To czyni koniecznymi dwie rzeczy, których w samym dokumencie nie ma: osobę, która za niego odpowiada, oraz odstęp czasu, w którym jest sprawdzany wobec systemu, a nie wobec własnej poprzedniej wersji.

• Odpowiedzialność i odstęp przeglądu: Odpowiedzialny: Lukas Wójcik, właściciel. Przegląd corocznie oraz przy każdej zmianie przetwarzania. Datowane wersje przechowywane są w systemie kontroli wersji w katalogu ai/cms/. (decyzja administratora, 17.08.2026)
• Zdarzenia wymuszające aktualizację niezależnie od odstępu: nowy podmiot podprzetwarzający albo zmiana miejsca docelowego; nowa tabela z danymi osobowymi; zmiana łańcucha usuwania mp_sitzungen_loeschen() albo codziennego usuwania w srv/db_worker.php; włączenie eksportu do BigQuery albo webhooków u któregokolwiek klienta; zmiana domyślnych ustawień maskowania; pierwszy klient, którego strona wyświetla dane szczególnych kategorii.
• Metoda: każda liczba w tym rejestrze pochodzi z pomiaru na kodzie, schemacie albo bazie danych w podanym dniu. Przegląd, który jedynie ponownie czyta tekst, niczego nie przejrzał — liczby trzeba zmierzyć ponownie, a symbole zastępcze albo wypełnić, albo wyraźnie przenieść dalej wraz z uzasadnieniem.
• Ten rejestr nie zastępuje listy podmiotów podprzetwarzających, dokumentu środków technicznych i organizacyjnych, umowy powierzenia przetwarzania ani informacji o ochronie danych. Tam, gdzie te dokumenty i ten rejestr się rozchodzą, rozbieżność jest ustaleniem, a nie kwestią formatowania.