Registro delle attività di trattamento (art. 30 GDPR)

1. Come leggere questo registro

Questo è un documento interno di responsabilizzazione ai sensi dell’art. 30 GDPR. Non è un’informativa sulla privacy, non è scritto per informare gli interessati, anche se viene pubblicato, e non è scritto per fare bella figura. Il suo unico compito è consentire a un’autorità di controllo — o alla prossima persona che dovrà rispondere a una domanda — di vedere che cosa viene effettivamente trattato, dove risiede e per quanto tempo rimane.

Tre regole hanno guidato la redazione. Primo: si formula un’affermazione soltanto se è supportata dal codice, dallo schema o da una misurazione. Se manca una voce, un segnaposto indica la lacuna anziché una frase plausibile. Una lacuna onesta supera un audit; un’ipotesi ben formulata no. Secondo: se il codice documenta il proprio ragionamento, tale ragionamento viene citato con file e riga, così che un lettore successivo possa verificarlo invece di fidarsi di questo documento. Terzo: la conservazione è indicata due volte — una per le tabelle coperte dall’eliminazione giornaliera, una per quelle non coperte. Un registro che dichiara un periodo di eliminazione valido per metà delle tabelle è peggiore di uno che indica la lacuna, perché è proprio la lacuna a essere verificata.

2. Il soggetto e perché questo registro ha due parti

Campo	Contenuto
Soggetto giuridico	LW IT Solutions Company Lukas Wójcik
Indirizzo	al. Tadeusza Kościuszki 80/82 lok. 301, 90-437 Lodz, Polonia
Identificazione fiscale	NIP: PL7252266190
Contatto	office@mouseplayer.com (nessun numero di telefono pubblicato)
Prodotto	MousePlayer — session replay, mappe di calore, analisi comportamentale
Rappresentante ai sensi dell’art. 27	Non applicabile. Il soggetto è stabilito nell’Unione (Polonia).
Responsabile della protezione dei dati	Non designato. Si veda la sezione 9 per la valutazione ai sensi dell’art. 37.

MousePlayer occupa due posizioni diverse nei confronti di due gruppi diversi di persone e confonderle produce un registro inutile per entrambi. Per i dati dei VISITATORI dei siti web dei clienti, MousePlayer è un responsabile del trattamento e il cliente è il titolare — si applica l’art. 30(2). Per i dati dei CLIENTI di MousePlayer (account, fatturazione, assistenza, log degli accessi al portale), MousePlayer è il titolare del trattamento — si applica l’art. 30(1).

Non è una comodità redazionale. La distinzione è già implementata nel codice e comporta una conseguenza tecnica diversa per ciascuna parte: class/Server.class.php:416 dichiara "REGEL B ... Hier sind wir AUFTRAGSVERARBEITER" e le righe 421-425 separano "Regel A (volle Adresse) fuer DIREKTE Zugriffe auf die eigene Anwendung" dalla Regola B (troncata) per i dati dei visitatori. L’indirizzo IP di un visitatore viene troncato in class/Server.class.php:432-435; l’indirizzo IP di un utente cliente viene conservato per intero. Il sistema si comporta quindi già come se questo registro esistesse.

• Parte A (sezione 3) — art. 30(2): ventidue attività di trattamento (da A.1 ad A.22) svolte per conto dei titolari del trattamento.
• Parte B (sezione 5) — art. 30(1): otto attività di trattamento (da B.1 a B.8) svolte sotto la responsabilità di MousePlayer.
• Le sezioni da 6 a 8 sono comuni a entrambe le parti: conservazione, processo decisionale automatizzato e descrizione generale delle misure tecniche e organizzative.
• La sezione 10 elenca le lacune di cui è provata l’esistenza. Un registro è uno strumento di lavoro, non un certificato.

3. Parte A — art. 30(2): attività svolte per conto dei titolari del trattamento

A.0 Parti

Campo	Contenuto
Responsabile del trattamento	LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82 lok. 301, 90-437 Lodz, Polonia. office@mouseplayer.com
Titolari del trattamento	I clienti che gestiscono i siti web su cui è installato il tag MousePlayer (www/mp.js). Ogni titolare è identificato nel sistema tramite projects.channelid; i recapiti sono conservati in users e workspaces, l’appartenenza e il ruolo in workspace_users. Misurato sull’istanza di sviluppo: 7 progetti, 4 account cliente, ruoli 4 owner / 1 admin / 1 viewer.
Elenco dei titolari del trattamento facente fede	Conservato nel sistema, non duplicato qui. L’elenco viene generato, non trascritto: nell’area amministrativa, sotto “Registro delle attività di trattamento (art. 30)”, un pulsante lo produce su richiesta in formato CSV — per area di lavoro, il proprietario con nome, e-mail, ragione sociale, indirizzo, partita IVA, piano e domini interessati. Responsabile della produzione: Lukas Wójcik, titolare; viene estratto a ogni riesame di questo registro, cioè annualmente e a ogni modifica del trattamento. Ogni recupero compare nel log delle modifiche (export_controllers). Un elenco trascritto qui sarebbe un secondo luogo per la stessa verità e diventerebbe obsoleto con ogni nuovo cliente senza che nessuno se ne accorga. (decisione del titolare del trattamento, 17/08/2026)
Rappresentante del responsabile del trattamento	Non applicabile (stabilito in Polonia).
Responsabile della protezione dei dati	Non designato — si veda la sezione 9.
Misure tecniche e organizzative	La sezione 8 si applica a ogni attività della Parte A e non viene ripetuta per ciascuna attività.

A.1 Session replay — acquisizione degli eventi comportamentali

Campo	Contenuto
Origine degli eventi	Due percorsi. (1) Il browser del visitatore tramite www/mp.js, dove la macchina a stati mpEinw applica tecnicamente il consenso. mp.js trasmette tramite HTTPS a nginx, dove termina TLS: normalmente tramite il WebSocket all’indirizzo /mp_wss/; se il WebSocket non si connette mai, dall’11/10/2026 tramite un tunnel HTTP all’indirizzo /mp_wst, al quale si applicano gli stessi controlli del server WebSocket (consenso, rilevamento dei bot, origine, quota); le istantanee di pagina grandi dal 07/10/2026 come caricamento HTTP all’indirizzo /mp_dom con accesso firmato e a validità limitata (conservate in Redis per un massimo di 120 secondi, poi trattate come un’istantanea ordinaria). Il punto di misurazione /mp_wsfail conteggia soltanto le connessioni WebSocket fallite per progetto, motivo, famiglia del browser e tipo di dispositivo, senza un ID visitatore; l’indirizzo IP vi è soltanto sottoposto a hash e conservato per un massimo di un’ora per la deduplicazione. (2) Lato server tramite www/api/capi_ingest.php da un sistema gestito dal cliente; tale percorso richiede una firma (HMAC-SHA256 su marca temporale e corpo, finestra di cinque minuti) e una dichiarazione esplicita per ogni trasmissione che il consenso esiste — senza di essa la richiesta viene rifiutata con 403. MousePlayer non può verificare tecnicamente il consenso su tale percorso; il cliente, in qualità di titolare del trattamento, lo garantisce (DPA sezione 2). Il percorso è attivabile tramite site_settings.capi_ingest_aktiv; era disattivato fino al 18/08/2026 ed è attivo da allora. Esiste inoltre un’anteprima di un SDK per app native (Android) con un proprio percorso di acquisizione (www/api/native_ingest.php, tabelle mp_native_apps e mp_native_sessions); esiste soltanto sull’istanza di sviluppo ed è disattivato (native_preview_enabled = 0; al 16/10/2026 nessuna sessione conservata).
Finalità	Registrare il comportamento dei visitatori sui siti web dei clienti — movimento del mouse, clic, scorrimento, tocchi, cambi di scheda — così che il cliente possa riprodurre e analizzare la sessione.
Categorie di interessati	Visitatori dei siti web dei clienti MousePlayer.
Categorie di dati personali	Coordinate del movimento, scarto temporale, posizione di scorrimento, altezza del documento; tipo di evento; dimensioni dell’area visibile e dello schermo; identificativi di sessione e visualizzazione di pagina. Distribuzione misurata degli eventi: 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. In visitor_sessions inoltre: referrer, parametri UTM, ID clic di una rete pubblicitaria con il relativo tipo, percorso di ingresso, canale di traffico, flag del browser in-app, identificativo del browser (user agent), flag bot con motivo, qualità della sessione e, dal 26/09/2026, un punteggio di attrito con motivi (friction_score, friction_gruende). La distribuzione degli eventi sopra riportata è stata misurata il 10/08/2026.
Dove sono conservati	mouse_events (event_id, pageview_id, event_type, time_offset_ms, x, y, scroll_y, scroll_x, doc_height, target_selector) — 225892 righe, 322,6 MB, la tabella più grande dello schema. 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 righe: una copia ridotta degli eventi CLICK e di contesto, da cui legge il livello dei clic della mappa di calore. È indicata separatamente perché la sua conservazione differisce da quella di mouse_events — questi vengono spostati nell’archivio dopo 7 giorni, mentre la copia rimane e mantiene quindi la mappa dei clic per tutta la cronologia. Da essa viene costruito ogni notte un aggregato giornaliero, mp_hm_klick_tag con mp_hm_ansicht_tag (dal 07/10/2026): per giorno, indirizzo, tipo di dispositivo, classe dello schermo, bersaglio e cella di 8 px soltanto un conteggio, senza sessione, ID visitatore o visualizzazione di pagina. La mappa dei clic lo utilizza per i giorni le cui sessioni non esistono più. L’eliminazione di singole sessioni o persone non lo modifica, perché nessuna riga può essere attribuita a una persona. Da ottobre 2026 inoltre mp_aufnahme_quittung: per messaggio in ingresso un identificativo e uno stato; per un messaggio che non può essere elaborato, anche il contenuto grezzo e il motivo. Le righe vengono eliminate dopo 7 giorni (srv/db_worker.php). Conteggi delle righe di questa voce privi di data: al 10/08/2026.
Base giuridica (determinata dal titolare del trattamento)	Consenso. Motivato in ai/migrations/018_consent.sql: la registrazione è osservazione del comportamento (considerando 24 GDPR) e accesso all’apparecchiatura terminale (par. 25 TDDDG); richiede il consenso e non può basarsi sul legittimo interesse. Tutti i 7 progetti sono impostati su projects.consent_mode='required'. Applicazione lato server in class/Server.class.php:977-1004; interruttore di disattivazione site_settings.consent_gate_active=1.
Categorie di destinatari	(a) Il rispettivo cliente — membri dell’area di lavoro con ruolo owner, admin o viewer. (b) Chiunque possieda un link di condivisione, SENZA accesso: /s/<40-hex-token> indirizza a player.php?share=..., tabella session_shares. (c) Facoltativamente il cliente tramite API REST v1 con una propria chiave API, soltanto con un livello a pagamento; al 16/10/2026 non esiste alcuna chiave API. (d) Facoltativamente gli agenti IA del cliente tramite il server MCP (/mcp): accesso in lettura con una chiave di lettura dell’API REST, da abilitare separatamente per progetto (projects.mcp_active, disattivato per impostazione predefinita); sono disponibili progetti, indicatori, elenchi di sessioni con link di riproduzione, singole sessioni con visualizzazioni di pagina ed eventi, pagine, segnali di frustrazione e obiettivi — non l’istantanea della pagina. Al 16/10/2026 non è abilitato per alcun progetto. (e) Il cliente come file: esportazione CSV dell’elenco delle sessioni e delle risposte ai sondaggi dalla propria interfaccia, con limite (csv_export_max_zeilen); ogni esportazione viene registrata nel log delle modifiche (csv_export).
Trasferimento verso paesi terzi	Nessuno nel percorso di registrazione. Non è stata trovata alcuna chiamata in uscita; la geolocalizzazione utilizza file MaxMind locali. Si veda la sezione 4.
Conservazione	Dipendente dal livello, applicata dall’eliminazione giornaliera in srv/db_worker.php (sezione 6.1) tramite la catena di eliminazione mp_sitzungen_loeschen(): Gratuito 7 giorni, Small 30, Business 90, Enterprise secondo il livello concordato (predefinito 365). Le sessioni riconosciute come automatizzate (bot) hanno periodi propri e più brevi: la loro registrazione (istantanea della pagina ed eventi) viene rimossa una volta trascorso retention_bot_recording_days (periodo in giorni: 1) e la riga della sessione con tutto ciò che vi è associato viene eliminata una volta trascorso retention_bot_session_days (periodo in giorni: 14); entrambi sono configurabili nell’area amministrativa e 0 disattiva il periodo separato, così che si applichi quello del livello. Dopo 7 giorni gli eventi passano da mouse_events a file di archivio compressi per sessione (srv/cron_archiv.php); condividono il periodo della propria sessione, vengono eliminati insieme a essa e dal 06/10/2026 fanno parte del backup giornaliero (sezione 4). Se un cliente elimina un progetto, un’area di lavoro o il proprio account oppure viene avviata un’eliminazione per indirizzo IP o visitatore, dal 07/10/2026 i dati vengono prima archiviati — nascosti, senza ulteriori registrazioni, ripristinabili — e infine eliminati al più tardi dopo 30 giorni (sezione 6.2, mp_loesch_archiv).

A.2 Acquisizione dei contenuti delle pagine — istantanea DOM e mutazioni DOM

Campo	Contenuto
Finalità	Registrare i contenuti della pagina per riprodurre la sessione così come l’ha vista il visitatore.
Categorie di interessati	Visitatori dei siti web dei clienti e, indirettamente, ogni persona i cui dati sono visualizzati dalla pagina del cliente — ad esempio una conferma d’ordine che mostra un indirizzo postale.
Categorie di dati personali	L’HTML completo della pagina visitata, compresi testo, URL delle immagini e metadati, così come visualizzato dal browser, senza script e con il mascheramento descritto in A.3. Inoltre, frammenti HTML serializzati di ogni modifica DOM successiva, conservati nel campo target_selector degli eventi mutation. Dal 30/09/2026 inoltre: il contenuto delle shadow root aperte dei componenti web insieme ai relativi fogli di stile (le shadow root chiuse non vengono registrate); elementi canvas come immagine fissa nell’istantanea e, quando cambiano, continuamente come immagine (al massimo una volta per intervallo di un secondo, con limite per visualizzazione di pagina; non nelle aree mascherate né per elementi canvas contenenti immagini cross-origin); iframe same-origin con i relativi contenuti e, dal 02/10/2026, le interazioni al loro interno (puntatore, clic, dati inseriti, scorrimento); iframe cross-origin soltanto come segnaposto senza contenuti.
Dove sono conservati	session_pageviews.payload_blob (longtext), conservato compresso dal 14/08/2026 (prefisso MPZ1:, gzip, Base64); al 16/10/2026 tutte le righe popolate utilizzano questo formato. session_pageviews.has_recording è una colonna ordinaria, non generata: il worker la imposta quando scrive l’istantanea e la reimposta quando la svuota; lo stesso vale per hat_interaktion, hat_scroll e scroll_max_y. mouse_events.target_selector dove event_type='mutation', compresi i contenuti di shadow root, canvas e iframe; dopo 7 giorni nei file di archivio (A.1). session_pageviews.html_path esiste ma, al 16/10/2026, non è impostato su alcuna riga.
Base giuridica (determinata dal titolare del trattamento)	Consenso, come A.1.
Categorie di destinatari	Il cliente, tramite www/player.php, www/ajax_get_events.php e www/player_theatre.php. Chiunque possieda un link di condivisione. NON tramite l’API REST — www/api/v1_session_detail.php:25 documenta l’esclusione deliberata del contenuto della riproduzione.
Trasferimento verso paesi terzi	Nessuno nel percorso di registrazione.
Conservazione	Come A.1: con la sessione tramite l’eliminazione giornaliera e mp_sitzungen_loeschen(); per le sessioni riconosciute come bot l’istantanea viene rimossa dopo il periodo indicato in A.1 (retention_bot_recording_days, periodo in giorni: 1). Si veda la sezione 6.
Nota sulla portata del mascheramento	Il mascheramento si applica soltanto ALL’INTERNO delle aree contrassegnate data-mp-mask o .mp-masked (www/mp.js:3934-3970). Tutto l’altro HTML della pagina viene conservato senza modifiche. Qualsiasi contenuto visualizzato dalla pagina del cliente è quindi nella registrazione e nessuna impostazione di mascheramento lo raggiunge.

A.3 Acquisizione dei dati inseriti nei moduli

Campo	Contenuto
Finalità	Registrare i dati inseriti nei moduli, carattere per carattere, per riprodurre l’interazione con un modulo.
Categorie di interessati	Visitatori dei siti web dei clienti.
Categorie di dati personali	Valori inseriti negli elementi input, textarea e select — completamente mascherati, parzialmente mascherati o in chiaro a seconda del livello di mascheramento. Stato delle caselle di controllo e dei pulsanti di opzione (true/false), che non viene MAI mascherato (www/mp.js:4810-4811). Categoria del campo derivata da classifyFieldName() (www/mp.js:4657-4674): email, password, phone, payment, address, name, search, coupon, quantity, other.
Dove sono conservati	mouse_events.target_selector dove event_type='input', formato {"t":"<data-mp-id>","v":"<value>"} — 599 righe.
Base giuridica (determinata dal titolare del trattamento)	Consenso, come A.1.
Categorie di destinatari	Il cliente (lettore); chiunque possieda un link di condivisione.
Trasferimento verso paesi terzi	Nessuno nel percorso di registrazione.
Conservazione	Nessun periodo proprio; come A.1, con la sessione (periodo del livello, per i bot i periodi di A.1), dopo 7 giorni nei file di archivio.
Salvaguardie in vigore	Limite minimo inderogabile per password e dati di pagamento indipendentemente dal livello (www/mp.js:4831-4837). Mascheramento completo al livello 0 (www/mp.js:4818-4819). Tutti i 7 progetti sono impostati su projects.smart_masking=0, che è l’impostazione PIÙ RIGOROSA nonostante l’etichetta.
Constatazione sui dati pregressi	Il 10/08/2026, 173 righe in mouse_events contenevano dati inseriti in chiaro NON MASCHERATI dal 21/07/2026 al 27/07/2026, compresi nomi di persone; le righe da quel giorno in poi sono mascherate. Al 16/10/2026 non rimane alcun dato inserito non mascherato in mouse_events (misurato con la stessa query). Le righe interessate sono state eliminate il 17/08/2026 (valutazione d’impatto, R2), cioè prima dell’introduzione dei file di archivio il 18/08/2026; non possono quindi trovarsi nei file di archivio né nel backup che li include dal 06/10/2026. Le copie cifrate di quel periodo su Google Drive sono state eliminate il 06/09/2026; non è noto alcun backup residuo precedente al 17/08/2026, ma la sua assenza non è stata verificata in dettaglio.

A.4 Riconoscimento del visitatore tra sessioni

Campo	Contenuto
Finalità	Riconoscere un visitatore tra sessioni e visualizzazioni di pagina.
Categorie di interessati	Visitatori dei siti web dei clienti.
Categorie di dati personali	Identificativo visitatore pseudonimo, generato e conservato nel localStorage del visitatore sotto 'mp_visitor_id' (www/mp.js:5056-5059). Un identificativo in chiaro impostato dal cliente — ID di accesso o numero cliente — tramite MousePlayer.setUserId() (www/mp.js:4909-4913, localStorage 'mp_user_id') e automaticamente dal percorso dataLayer 'uid' (www/mp.js:3585-3637). Soprannome e nome del browser per visitatore, conservati TRASVERSALMENTE ai progetti (UNIQUE su visitor_id).
Dove sono conservati	visitor_sessions.visitor_id (varchar 64), custom_user_id (varchar 128, indice proprio idx_custom_user_id), nickname_key. visitor_nicknames (visitor_id, nickname_key, browser_name, city, created_at) — 329 righe; la colonna city è vuota in tutte le 329. consent_events.visitor_id.
Base giuridica (determinata dal titolare del trattamento)	Consenso, come A.1.
Categorie di destinatari	Il cliente. Tramite custom_user_id, l’unione con le registrazioni dei clienti del cliente stesso è un utilizzo esplicitamente previsto.
Trasferimento verso paesi terzi	Nessuno nel percorso di registrazione.
Conservazione	Con l’ultima sessione del visitatore. mp_sitzungen_loeschen() (srv/db_worker.php) verifica dopo ogni eliminazione se rimangano sessioni per quel visitatore e, in caso contrario, rimuove il soprannome; il percorso di eliminazione nel lettore fa lo stesso. L’eliminazione giornaliera in base al livello chiama la stessa funzione, quindi non può più crearsi un dato orfano. Non esiste un periodo separato e non è necessario: la voce non sopravvive mai alle sessioni a cui si riferisce.

A.5 Dati di rete e posizione approssimativa

Campo	Contenuto
Finalità	Determinare la rete e la posizione approssimativa del visitatore e la regione per il controllo del consenso.
Categorie di interessati	Visitatori dei siti web dei clienti.
Categorie di dati personali	Indirizzo IP (troncato nel percorso di registrazione, si veda sotto), codice paese di due caratteri, città (determinata dall’indirizzo troncato, non da quello completo), numero ASN e nome del fornitore, codice regione.
Dove sono conservati	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 righe.
Base giuridica (determinata dal titolare del trattamento)	Consenso per la registrazione. La determinazione del paese viene deliberatamente effettuata lato server affinché nessun terzo venga contattato prima che esista il consenso (class/Server.class.php:941-944).
Categorie di destinatari	Nessun destinatario esterno. La geolocalizzazione utilizza file MaxMind LOCALI sotto cfg/maxmind/ (GeoLite2-City e GeoLite2-ASN; letti in class/IP2CityLite.class.php e class/Server.class.php), che srv/geoip_update.sh scarica regolarmente da MaxMind; nel processo non viene trasmesso alcun dato dei visitatori. I valori ricavati sono conservati in visitor_sessions e sono visibili al cliente come il resto della registrazione della sessione.
Trasferimento verso paesi terzi	Nessuno. Nessuna chiamata in uscita nel percorso di registrazione.
Troncamento	Il server WebSocket (class/Server.class.php, regola B) sostituisce l’ultimo ottetto IPv4 con 'xxx' e l’ultimo gruppo IPv6 con ':xxxx', immediatamente dopo aver determinato l’indirizzo della connessione (dietro nginx da X-Forwarded-For, considerato attendibile soltanto dal peer locale) e quindi prima di qualsiasi componente che lo utilizzi. L’indirizzo completo esiste soltanto temporaneamente nella memoria del server WebSocket, nei contatori Redis che scadono dopo pochi secondi e — per gli indirizzi che attivano un blocco automatico — per la durata del blocco (24 h) in Redis (mp_autoban:); l’istanza Redis scrive i propri dati su disco per la persistenza (AOF). Al 16/10/2026 nessuna riga in visitor_sessions o ip_lifetime_stats contiene un indirizzo non troncato.
Conservazione e constatazione sui dati pregressi	365 giorni da first_seen per ip_lifetime_stats, applicati dall’esecuzione giornaliera in srv/db_worker.php; il valore risiede in site_settings sotto retention_ip_stats_days ed è configurabile nell’area amministrativa. visitor_sessions rientra nell’eliminazione in base al livello. La constatazione sui dati pregressi è chiusa: misurato il 17/08/2026, 267 su 267 indirizzi in ip_lifetime_stats sono stati troncati e 881 su 901 in visitor_sessions. I restanti 20 contengono 0.0.0.0 e provengono dai dati di prova dell’analisi dei moduli (s_mptest_form_) — non sono indirizzi di visitatori.

A.6 Registrazioni del consenso

Campo	Contenuto
Finalità	Dimostrare il consenso e ogni sua modifica (art. 7(1) GDPR).
Categorie di interessati	Visitatori dei siti web dei clienti.
Categorie di dati personali	Stato (GRANTED, GRANTED_LATE, withdrawn, region_exempt), fonte, marca temporale; nome e versione della CMP; SHA-256 della stringa TC — deliberatamente non la stringa stessa; segnale GPC; codice regione; versione della configurazione del progetto.
Dove sono conservati	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 righe. visitor_sessions.consent_state, consent_source, consent_ts, cmp_name, cmp_version, tcf_hash, gpc_signal, region_code, consent_config_version, recording_offset_ms.
Base giuridica	Obbligo di dimostrazione, motivato in ai/migrations/018_consent.sql: l’onere della prova di un consenso valido spetta al titolare del trattamento e senza un log non vi è nulla da mostrare in una controversia.
Categorie di destinatari	Il cliente.
Trasferimento verso paesi terzi	Nessuno.
Conservazione	730 giorni, conteggiati da the withdrawal. Sia il periodo sia il riferimento iniziale risiedono in site_settings (consent_evidence_days, consent_evidence_anchor) e sono configurabili nell’area amministrativa; applicati dall’esecuzione giornaliera in srv/db_worker.php. All’eliminazione della sessione, la prova non viene ancora eliminata ma spersonalizzata: deve rimanere dimostrabile che sia stata presa una decisione (art. 5(2)), non chi l’abbia presa. Vengono eliminate soltanto le registrazioni a cui nessuna sessione fa più riferimento — mentre esiste la registrazione della sessione deve esistere la sua prova, altrimenti la registrazione rimarrebbe senza autorizzazione.
Qualità dei dati	671 sessioni su 706 hanno consent_source='testdata' con consent_ts IS NULL, impostati da ai/devdata/001_altsitzungen_markieren.sql. NON sono prove autentiche di consenso. Registrazioni autentiche: 27 (api), 5 (gcm), 2 GRANTED_LATE (api), 1 withdrawn (gcm).
Eliminazione alla revoca	Facoltativa e disattivata ovunque: projects.consent_delete_on_withdraw=0 per tutti i 7 progetti, valutata in srv/db_worker.php:1067-1070. Una revoca interrompe quindi le registrazioni successive ma non elimina nulla.

A.7 Eventi personalizzati, segnali di frustrazione ed errori JavaScript

Campo	Contenuto
Finalità	Registrare gli eventi definiti dal cliente, i segnali di frustrazione e gli errori JavaScript che si verificano sulla pagina del cliente.
Categorie di interessati	Visitatori dei siti web dei clienti.
Categorie di dati personali	Nome dell’evento — misurato: 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. Valori dei parametri — 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. Due di essi contengono più di quanto suggerisca il nome: 'snippet' su text_copied e text_selected è il testo della pagina che il visitatore ha selezionato o copiato; 'filename' contiene URL completi ed è stato trovato contenere un indirizzo moz-extension://, che è un identificativo di estensione del browser specifico del dispositivo.
Dove sono conservati	session_custom_events (event_id, session_id, pageview_id, event_name, created_at) — 823 righe. session_custom_event_params (param_id, event_id, param_key, param_string_value, param_int_value, param_float_value) — 1264 righe.
Base giuridica (determinata dal titolare del trattamento)	Consenso, come A.1.
Categorie di destinatari	Il cliente. Facoltativamente tramite webhook a un URL liberamente scelto dal cliente — si veda la sezione 4.
Trasferimento verso paesi terzi	Tramite il webhook la destinazione è indeterminata e quindi potenzialmente in un paese terzo. Attualmente inattivo: projects.webhook_active=0 e webhook_url NULL per tutti i 7 progetti.
Conservazione	Con la sessione tramite l’eliminazione giornaliera e mp_sitzungen_loeschen() (periodo del livello, per i bot i periodi di A.1); session_custom_event_params dipende da session_custom_events mediante FOREIGN KEY ON DELETE CASCADE. Eventi della console, della rete e Web Vitals in mouse_events come A.1; mp_cwv viene eliminato con la propria visualizzazione di pagina (pulizia ogni ora).
Messaggi della console e richieste di rete (dal 30/09/2026)	Ciò che la pagina scrive nella console del browser (il livello è impostato dal gestore, predefinito: errori e avvisi) e le richieste effettuate dalla pagina che falliscono o richiedono più tempo di una soglia configurata: metodo, indirizzo, codice di stato e durata. Mai intestazioni né corpo di richieste o risposte, mai contenuti di oggetti registrati nei log, soltanto il loro tipo. I testi attraversano un filtro prima dell’invio (indirizzi e-mail, indirizzi IP, lunghe sequenze di cifre, token di accesso); dagli indirizzi vengono rimossi i valori dei parametri con nomi sensibili. Le richieste a MousePlayer stesso non vengono acquisite. Conservati come evento del mouse in mouse_events (event_type con o net), con la stessa conservazione e catena di eliminazione della registrazione (A.1); mostrati nel lettore accanto alla timeline.
Tempi di caricamento e risposta (Web Vitals, dal 02/10/2026)	La rapidità con cui la pagina si carica e reagisce per il visitatore, misurata nel browser per visualizzazione di pagina: Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift, First Contentful Paint e Time to First Byte. Inoltre una breve descrizione dell’elemento visibile più grande e dell’elemento dell’interazione più lenta, come per un clic (tipo, identificativo, testo visibile; nelle aree mascherate soltanto il tipo). Nessun dato inserito, nessun contenuto delle richieste. Conservati come evento del mouse in mouse_events (event_type cwv) e per visualizzazione di pagina in mp_cwv, con la stessa conservazione e catena di eliminazione della registrazione (A.1); mostrati nella scheda Web Vitals e nell’intestazione del lettore.

A.8 Caratteristiche derivate e timeline delle sessioni generate automaticamente

Campo	Contenuto
Finalità	Derivare caratteristiche per sessione e resoconti testuali generati automaticamente — attribuzione di punteggi di rilevanza e attenzione.
Categorie di interessati	Visitatori dei siti web dei clienti.
Categorie di dati personali	Vettore di caratteristiche: durata, numero di pagine, profondità di scorrimento / mediana / inversioni, pause, efficienza del percorso, velocità massima, clic di rabbia e clic a vuoto, tocchi, zoom, fonte e campagna, tempo di permanenza per ruolo dell’elemento (role_dwell_json), comportamento delle schede. Valutazioni: engagement_score (0-255), session_quality, is_bot. Una timeline della sessione in testo continuo — esempio: 't=0.0 landing / src=(direct) kanal=direct attr=direct mode=unknown motion=unavailable viewport=1699x935 / t=2.0 session ende'.
Dove sono conservati	ai_session_features — 4043 righe (una riga per sessione E builder_version, quindi una sessione compare una volta per versione). ai_timelines (timeline_id, session_id, channelid, builder_version, input_mode, line_count, char_count, pageviews, duration_s, text come mediumtext, built_at) — 3203 righe, 5,5 MB. mp_session_ziel (channelid, session_id, goal_id, tag, ziel_fp, gebaut_am) — 628 righe: quale sessione ha raggiunto quale obiettivo, calcolato una volta anziché a ogni richiesta. ziel_fp è l’impronta della regola dell’obiettivo; se il titolare del trattamento la modifica, la mappatura viene ricostruita anziché riutilizzata senza segnalarlo. mp_hm_tag (channelid, tag, url_md5, url, titel, ansichten, engagiert) e mp_hm_tag_stand (channelid, tag, berechnet_am), dal 24/09/2026 (migrazione 148): per ogni progetto, giorno e indirizzo di pagina, il numero di visualizzazioni di pagina e di visualizzazioni coinvolte, da cui viene fornito l’elenco delle mappe di calore delle pagine. Soltanto conteggi e indirizzi — nessun identificativo visitatore o sessione; il numero di visitatori per indirizzo viene ancora conteggiato dalle sessioni stesse.
Base giuridica	Non documentata nel codice. Derivata dalla registrazione e quindi coperta indirettamente dal consenso ottenuto per essa. Istruzione: sorge con la registrazione del Cliente e viene eseguita non appena installa lo script sul proprio sito e vengono registrati visitatori (dichiarazione del titolare del trattamento, 17/08/2026). La derivazione di caratteristiche, timeline e fasce di valore fa parte del servizio commissionato. Si distinguono due parti. Le fasce di valore sono impostate dal Cliente sul proprio progetto; ogni modifica viene registrata (log_audit, save_wertregeln). Le sintesi scritte dal modello linguistico fino al 17/08/2026 dipendevano esclusivamente da un’impostazione globale nell’area amministrativa — il Cliente non poteva influirvi e quindi non si basavano sulla sua istruzione. Dalla migrazione 041 projects.ki_texte_aktiv decide inoltre, attivata per impostazione predefinita; il Cliente può disattivarla in qualsiasi momento nella scheda delle impostazioni e ogni modifica compare come ki_texte_changed nel registro delle modifiche. L’interruttore non è l’istruzione, ma il mezzo per limitarla: attivato per impostazione predefinita significa che il Cliente non lo ha attivato, ma si è soltanto astenuto dal disattivarlo.
Categorie di destinatari	Il cliente (cfg/project_ai_overview.php).
Trasferimento verso paesi terzi	Nessuno. Le frasi generate sono formulate dal modello linguistico sul nostro hardware a Łódź (sezione 4); nulla viene inviato a un servizio di IA esterno.
Conservazione	Con la sessione. ai_session_features e ai_timelines fanno parte di mp_sitzungen_loeschen() (srv/db_worker.php) dal 12/08/2026 e vengono quindi rimossi sia in caso di eliminazione esplicita sia mediante l’eliminazione giornaliera in base al livello. Questa cella affermava in precedenza il contrario; quello era lo stato prima di tale modifica. L’attribuzione di punteggi per visitatore e giorno che ne deriva (ai_visitor_value) e i testi generati (ai_insights) hanno inoltre un proprio periodo di conservazione — si veda la sezione 6.2.

A.9 Collaborazione sulla riproduzione — commenti e link di condivisione

Campo	Contenuto
Finalità	Commentare una riproduzione in corrispondenza di un marcatore temporale e condividere una riproduzione tramite link.
Categorie di interessati	Utenti del Cliente (gli autori) e, indirettamente, i visitatori registrati.
Categorie di dati personali	Testo del commento (fino a 2000 caratteri), scostamento temporale, autore. Token di condivisione (40 caratteri esadecimali), creatore, scadenza, revoca, numero di accessi, ultimo accesso.
Dove sono conservati	session_comments (comment_id, channelid, session_id, user_id, time_offset_ms, body, created_at, updated_at) — 12 righe. session_shares (share_id, channelid, session_id, token, created_by, expires_at, revoked_at, last_seen, view_count, created_at) — 9 righe.
Base giuridica	Non documentata nel codice. Istruzione: il Cliente consente espressamente la condivisione, anche al di fuori della propria organizzazione, e ne assume la responsabilità (decisione del titolare del trattamento, 17/08/2026). L’istruzione è documentata dall’atto stesso: il link viene creato da un membro autorizzato dell’area di lavoro del Cliente e la sua creazione viene registrata (log_audit, azione create_share; revoca come revoke_share). MousePlayer mette a disposizione la funzione; la scelta dei destinatari e la liceità della comunicazione spettano al Cliente. Limiti tecnici: ogni link scade — dopo 7 giorni per impostazione predefinita, al massimo 90 — e può essere revocato in qualsiasi momento.
Categorie di destinatari	Chiunque sia in possesso di un link di condivisione, SENZA autenticazione (www/.htaccess:77). Token inventati, scaduti e revocati restituiscono tutti la stessa risposta, in modo che non sia possibile sondare i token per ottenere informazioni.
Trasferimento verso paesi terzi	Indeterminato per scelta progettuale — un link può essere inoltrato ovunque. Si tratta di una proprietà della funzione, non di un incidente.
Conservazione	Con la sessione: session_comments e session_shares fanno parte di mp_sitzungen_loeschen() dal 12/08/2026 e vengono eliminati con la sessione. Indipendentemente da ciò, i link di condivisione hanno una propria durata massima: session_shares.expires_at è NOT NULL, mp_share_erstellen() (cfg/lib.php) prevede 7 giorni per impostazione predefinita e un massimo di 90. L’applicazione non può creare un link senza scadenza. Una volta che un link è scaduto o è stato revocato, l’eliminazione giornaliera ne elimina la riga 90 giorni dopo; gli accessi in share_views vengono eliminati insieme ad essa tramite la chiave esterna (B.6).

A.10 Vista dal vivo — osservare una sessione mentre si svolge

Campo	Contenuto
Finalità	Osservazione di una sessione in corso in tempo reale: elenco dal vivo dei visitatori presenti, modalità segui con un’istantanea della pagina riprodotta in modo speculare, posizione del puntatore trasmessa e, dal 16/08/2026, stato di hover ricostruito (:hover).
Categorie di interessati	Visitatori dei siti web del Cliente (osservati), utenti del Cliente (osservatori).
Categorie di dati personali	Le stesse categorie di A.1 e A.2 — posizioni del puntatore e di scorrimento, clic, eventi di inserimento, l’istantanea della pagina e le sue mutazioni — ma nel momento in cui si producono. Inoltre l’identificativo della sessione, affinché l’osservatore segua la sessione corretta.
Dove sono conservati	Non conservati. Il flusso passa attraverso il server WebSocket (class/Server.class.php) e viene inoltrato all’interno del processo agli osservatori connessi. Il token di accesso è conservato nella tabella del database live_tokens (identificativo, progetto, ID utente, ove applicabile la sessione seguita, momento dell’ultima conferma). Dal 17/09/2026 anche il lettore di una sessione in corso si collega a questo flusso con un proprio accesso (identificativo con il prefisso pl_, vincolato alla sessione seguita) per visualizzarne gli eventi senza ritardo. La registrazione della stessa sessione viene creata indipendentemente tramite A.1 e A.2.
Base giuridica	Istruzione: l’osservazione viene avviata da un membro autorizzato dell’area di lavoro del Cliente; l’accesso avviene tramite un token a durata limitata in live_tokens vincolato al suo ID utente. L’utente finale non viene avvisato separatamente al momento dell’osservazione (decisione del titolare del trattamento, 17/08/2026). L’informazione viene fornita in anticipo: attraverso il consenso che precede qualsiasi registrazione e attraverso l’informativa sulla privacy, che dal 17/08/2026 dichiara espressamente che una sessione in corso può essere seguita in tempo reale. Fino ad allora menzionava la vista dal vivo soltanto come funzione in un elenco — la decisione si basava quindi su una frase che ancora non esisteva.
Categorie di destinatari	Il Cliente, limitatamente ai membri autorizzati dell’area di lavoro.
Trasferimento verso paesi terzi	Nessuno.
Conservazione	Il flusso stesso non viene conservato. Il server WebSocket rimuove una riga in live_tokens dopo la fine della visualizzazione, con un breve periodo di tolleranza per un ricaricamento; un accesso che non viene più confermato perde efficacia dopo breve tempo e viene rimosso successivamente.

Questa voce mancava nel registro fino al 17/08/2026. Deve essere tenuta separata da A.1 e A.2 anche se vengono trasmessi gli stessi dati: in quei casi la riproduzione avviene successivamente, qui una persona osserva nel momento in cui il visitatore agisce. Questa simultaneità è precisamente la caratteristica su cui si fonda l’art. 35(3) nel definire il monitoraggio sistematico, e su di essa la valutazione d’impatto sulla protezione dei dati fonda la propria necessità.

A.11 Registro delle consegne delle integrazioni

Campo	Contenuto
Finalità	Documentazione e risoluzione dei problemi per le trasmissioni elencate al punto 4.1. Senza di esso il titolare del trattamento non può sapere se un connettore funziona — dal suo lato un errore passerebbe inosservato.
Categorie di interessati	Visitatori dei siti web dei clienti, nella misura in cui il titolare del trattamento ha impostato per loro un ID cliente. In assenza di un ID impostato, la voce non contiene alcun riferimento personale.
Categorie di dati personali	Marca temporale, tipo di connettore, un identificativo (l’ID cliente fornito dal titolare del trattamento tramite setUserId, la rete pubblicitaria o il nome dell’evento), esito positivo o negativo, durata in millisecondi, numero del tentativo e la risposta del destinatario o il testo che descrive l'errore. Tale testo può contenere un ID di registrazione del sistema di terzi. Nessun dato comportamentale, nessun contenuto della pagina, nessun indirizzo IP.
Dove sono conservati	Redis, chiave mp_webhook_log:<channelid>. Le ultime 25 voci per progetto; le più vecchie vengono rimosse tramite lTrim. Non nel database e quindi nemmeno nel backup giornaliero.
Base giuridica (determinata dal titolare del trattamento)	Come A.1. La voce viene creata soltanto se il titolare del trattamento ha attivato un connettore — costituisce la registrazione dell’esecuzione della sua stessa istruzione.
Categorie di destinatari	Il titolare del trattamento, tramite le impostazioni del progetto (scheda Integrazioni). Nessuna ulteriore comunicazione.
Trasferimento verso paesi terzi	Nessuno. La voce non lascia il nostro server.
Conservazione	30 giorni. Impostata come scadenza Redis al momento della scrittura; inoltre limitata a 25 voci per progetto. Scade autonomamente e non richiede un’esecuzione di cancellazione. Il valore risiede in site_settings.retention_intlog_days ed è modificabile nell’area amministrativa.

A.12 Profili comportamentali — raggruppamento automatizzato delle visite

Campo	Contenuto
Finalità	Raggruppamento automatizzato delle VISITE registrate in base al loro svolgimento, affinché il titolare del trattamento non debba esaminare una sessione dopo l’altra, ma veda gruppi — e possa riprodurre una visita tipica per gruppo. Inoltre, sequenze ricorrenti di pagine ed eventi all’interno della finestra di calcolo.
Categorie di interessati	Visitatori dei siti web dei clienti. Vengono raggruppate VISITE, non persone: la stessa persona con due visite può finire in due gruppi e l’interfaccia è formulata in questi termini. Non viene calcolato un profilo per PERSONA — richiederebbe l’identificativo cliente fornito tramite setUserId, e 0 sessioni su 4226 ne hanno uno (misurato il 27/08/2026).
Categorie di dati personali	Nessuna nuova categoria. Il vettore delle caratteristiche di A.8, limitato alle sette caratteristiche con un tasso di compilazione superiore al 90 %: durata, numero di pagine, punteggio di attenzione, pause, clic di rabbia, clic a vuoto, cambi di scheda. Da queste vengono derivati: il gruppo a cui appartiene una sessione e la sua distanza dal centro del gruppo. Per ogni gruppo, inoltre, l’ID di sessione della visita più tipica e di quella meno tipica, affinché entrambe possano essere riprodotte. Per le sequenze: la catena di percorsi e nomi di eventi che forma il modello ricorrente e fino a tre ID di sessione come esempi. Nessun contenuto della pagina, nessun indirizzo IP, nessun dato inserito nei moduli.
Dove sono conservati	mp_profile — una riga per canale e gruppo (dimensione, quota, centro, indicatori, nome calcolato, nome assegnato autonomamente, rappresentante, caso anomalo); 15 righe. mp_profil_sitzung — associazione della sessione al gruppo e distanza; 4226 righe. mp_sequenzmuster — catena, supporto, lift, fino a tre esempi; 115 righe. Tutte e tre sono DERIVAZIONI: possono andare perdute ed essere ricalcolate in qualsiasi momento e non contengono alcun dato grezzo che non esista anche altrove. Dal 06/09/2026 mp_profil_sitzung contiene inoltre la chiave della persona (person_key, migrazione 112): una copia della chiave di A.4 (ID cliente, altrimenti ID visitatore), che l’esecuzione dei profili aggiorna quotidianamente; da essa viene calcolato l’elenco dei visitatori di ritorno. Numero di righe in questa voce: al 27/08/2026.
Base giuridica	Come A.8. Derivata dalla registrazione e quindi coperta indirettamente dal consenso ottenuto per essa. Istruzione: fa parte del servizio commissionato; sorge con l'iscrizione del cliente e viene eseguita non appena vengono registrati visitatori. Occorre indicare due limiti. Il raggruppamento è CALCOLATO, non generato: il gruppo a cui appartiene una visita viene determinato mediante k-means sulle sette caratteristiche in ai/profile.py, e i nomi dei gruppi derivano dalla posizione relativa del centro, non da un testo. Quando un modello linguistico scrive una frase su un gruppo, riceve soltanto gli indicatori del GRUPPO — percentuali e medie — mai un ID di sessione o visitatore, e la stessa protezione di A.8 rifiuta qualsiasi numero che non rientri in tali indicatori. Tuttavia, non esiste un interruttore per progetto: profile_aktiv è un’impostazione globale del gestore e la selezione delle sezioni IA per progetto (projects.ki_module) non copre questa scheda. Registrato come lacuna nella sezione 10.
Categorie di destinatari	Il cliente, tramite la scheda Profili comportamentali (cfg/project_profiles.php). Nessun trasferimento a terzi: l’appartenenza a un gruppo non viene trasmessa a nessuno dei connettori del punto 4.1. Verificato cercando profil_key in cfg/, srv/, www/ e class/ — compare soltanto nel percorso di lettura e nel lettore, né in www/mp.js né in class/Server.class.php, per cui non raggiunge nemmeno l'istanza del browser del visitatore.
Trasferimenti verso paesi terzi	Nessuno. Il calcolo viene eseguito sulla stessa macchina (ai/profile.py, avviato da srv/ai_worker.php). La frase facoltativa per gruppo viene formulata dal modello linguistico su una delle nostre macchine con scheda grafica nella stessa rete locale (si veda la sezione 4), che recupera soltanto gli indicatori del gruppo, tramite HTTPS. Nulla viene inviato a un servizio di IA esterno.
Conservazione	Con la sessione: mp_profil_sitzung fa parte di mp_sitzungen_loeschen(). Oltre a ciò 180 giorni, decorrenti dall’INIZIO DELLA SESSIONE e non dal momento del calcolo — l’esecuzione giornaliera aggiorna quest’ultimo a ogni passaggio, per cui un periodo basato su di esso non scadrebbe mai e nessuno se ne accorgerebbe. Le righe la cui sessione non esiste più vengono rimosse senza alcun periodo, perché ogni periodo si riferirebbe a una riga che non esiste più. Il valore risiede in site_settings.retention_profile_days, è modificabile nell’area amministrativa e viene portato almeno alla durata della finestra di calcolo, affinché l’esecuzione di eliminazione non rimuova ciò che l’esecuzione dei profili ha scritto nello stesso giorno. mp_profile viene eliminato non appena non rimane più alcuna assegnazione che vi faccia riferimento, nella stessa esecuzione notturna — per questo tale affermazione segue le due precedenti. mp_sequenzmuster viene eliminato dopo 180 giorni senza un ricalcolo e immediatamente quando il suo canale non ha più alcuna sessione. Qui il riferimento temporale È il momento del calcolo, e correttamente: a differenza di un’assegnazione, un modello ricorrente descrive la finestra ATTUALE e viene riscritto integralmente per canale a ogni esecuzione, per cui una marca temporale aggiornata significa davvero „descrive l'insieme dei dati di oggi“.

A.13 Nome personalizzato per un visitatore — assegnato dal titolare del trattamento

Campo	Contenuto
Finalità	Il titolare del trattamento assegna a un singolo visitatore un nome di propria scelta per riconoscerlo negli elenchi e nelle registrazioni. Il nome sostituisce il soprannome generato di A.4 ovunque questo comparirebbe altrimenti. L’occasione è il caso di assistenza: „questo è il cliente che ha chiamato“.
Categorie di interessati	Visitatori dei siti web dei clienti — nello specifico, singoli visitatori scelti dal titolare del trattamento. A differenza di A.1–A.12, questo trattamento non si verifica autonomamente quando qualcuno apre la pagina; richiede un inserimento deliberato. Senza tale inserimento non esiste alcuna riga: il 28/08/2026, 0 visitatori su 3830 hanno un nome personalizzato.
Categorie di dati personali	TESTO LIBERO di al massimo 64 caratteri, oltre al momento e all’account utente dell’assegnazione. Il riferimento è l’identificativo visitatore di A.4. Il contenuto non è né prescritto né controllato — può trattarsi di un numero di contratto, di un soprannome o di un nome in chiaro insieme a un reparto. Questo distingue il trattamento da tutti gli altri della Parte A: in quei casi i dati provengono dal visitatore o sono calcolati a partire dal suo comportamento, qui li digita il titolare del trattamento. Segnalato come lacuna nella sezione 10.
Dove sono conservati	visitor_nicknames.custom_label, label_set_at, label_set_by (migrazione 093) — la stessa riga che contiene già il soprannome generato, una per visitatore, 3830 righe. Volutamente senza una tabella separata: il nome sostituisce esattamente il soprannome lì conservato, dipende dalla stessa chiave e viene quindi eliminato insieme ad esso senza ulteriori interventi. Una tabella separata costituirebbe un quinto punto nella catena di eliminazione, che potrebbe essere dimenticato.
Base giuridica	Istruzione del titolare del trattamento (art. 28(3)(a)), impartita mediante l’inserimento stesso — nessuna operazione programmata e nessuna impostazione predefinita crea un nome. MousePlayer non può valutare se esista una base giuridica per il contenuto inserito: il titolare del trattamento sceglie il testo e conosce il contesto da cui proviene. Il suggerimento nel campo di inserimento indica quindi la finalità („solo il Suo team vede questo nome“) e non soltanto il campo.
Categorie di destinatari	Il cliente, nei propri elenchi e nel lettore. Nessuna comunicazione a terzi: il campo non viene trasmesso a nessuno dei connettori del punto 4.1 — verificato mediante una ricerca di custom_label in cfg/, srv/, www/ e class/; non compare né in www/mp.js né in class/Server.class.php e quindi non raggiunge mai nemmeno il browser del visitatore. Il link di condivisione (B.6) volutamente NON lo mostra, ma mostra invece il soprannome generato: inoltrare un link che non richiede autenticazione condivide una registrazione, non l’identità che vi sta dietro. La stessa considerazione di www/selbstauskunft.php.
Trasferimenti verso paesi terzi	Nessuno. Il campo lascia il database soltanto per entrare nell’interfaccia del cliente autenticato.
Conservazione	Con l’ultima sessione del visitatore, come la riga che lo contiene: mp_sitzungen_loeschen() rimuove tale riga non appena non esiste più alcuna sessione per questo identificativo visitatore — attraverso entrambi i percorsi, l’esecuzione giornaliera di eliminazione e l’eliminazione dell’account. Nessun proprio periodo di calendario, e questo è intenzionale: un periodo applicato al nome significherebbe eliminarlo mentre il visitatore è ancora presente e continua a essere registrato. Il titolare del trattamento può rimuoverlo in qualsiasi momento; un campo vuoto lo elimina e torna a essere utilizzato il soprannome generato.

A.14 Importazione da Google Analytics 4 — indicatori e sessioni dall’account del titolare del trattamento

Campo	Contenuto
Finalità	Il titolare del trattamento fa recuperare in MousePlayer dati dal proprio account Google Analytics 4. Due percorsi, ciascuno attivato separatamente: la Data API restituisce soltanto totali giornalieri e risponde alla domanda sulla copertura — GA4 conta 3.000 sessioni per un giorno, MousePlayer ne ha registrate 40 e, senza questo dato di riferimento, la differenza non può essere né spiegata né rilevata. L’importazione BigQuery legge l’esportazione grezza della proprietà e conserva singole sessioni GA4 con i relativi eventi, affinché diventi visibile ciò che è accaduto durante una visita che MousePlayer non ha potuto registrare.
Categorie di interessati	Visitatori dei siti web dei clienti — le stesse persone di A.1, osservate però da un secondo sistema di misurazione. Ciò che distingue questo trattamento da A.1–A.13 è l’origine: questi dati non sono stati raccolti qui. Si trovano già nell’account Google del titolare del trattamento e MousePlayer li recupera. Il percorso Data API, inoltre, non riguarda affatto singole persone; restituisce soltanto totali giornalieri.
Categorie di dati personali	Per il percorso Data API: nessuna — quattro numeri al giorno (sessioni, utenti, visualizzazioni di pagina, sessioni coinvolte) senza alcun riferimento personale. Per il percorso BigQuery, per ogni sessione GA4: l’identificativo pseudonimo user_pseudo_id, ossia l’ID client del cookie _ga; inizio, fine e durata; numero di eventi e visualizzazioni di pagina; percorso di ingresso; categoria del dispositivo e paese; inoltre fonte, mezzo e campagna. In aggiunta, per ogni nome di evento, un contatore, l’ultima marca temporale e, ove GA4 ne riporti uno, un valore sommato. Nessun indirizzo IP, nessuna istantanea della pagina, nessun movimento del mouse — GA4 non contiene nessuno di questi dati e non ne vengono generati. Una sessione importata non può quindi mai essere riprodotta.
Dove sono conservati	ga4_daily, ga4_sessions e ga4_events (migrazione 097) — tre tabelle SEPARATE. Volutamente non in visitor_sessions, session_pageviews o session_custom_events. Non è una questione di ordine: quelle tre tabelle non hanno una colonna che indichi l’origine di una riga, perché tutto ciò che contengono è stato misurato qui. Una riga importata sarebbe indistinguibile da una misurata e, di conseguenza, il significato di ogni indicatore derivato cambierebbe senza che ciò sia visibile — i profili comportamentali di A.12, la valutazione per visitatore, l’analisi dell’attrito. L’importazione è quindi conservata accanto ai dati misurati, come avviene già per ai_visitor_value e mp_profile.
Base giuridica	Istruzione del titolare del trattamento (art. 28(3)(a)), impartita attivando il rispettivo percorso e fornendo un account di servizio dedicato. La raccolta originaria presso Google è responsabilità del titolare del trattamento, non di MousePlayer: è avvenuta prima che qualsiasi dato venga recuperato qui e non può essere verificata a posteriori. Esiste comunque una barriera tecnica — vengono importate soltanto righe che contengono un user_pseudo_id. Quando il consenso è negato, GA4 invia hit senza cookie in modalità Consent Mode e questi non lo contengono; vengono esclusi meccanicamente, anziché sulla base di una dichiarazione. Questo è un indizio, non una prova, ed è registrato come tale tra le lacune nella sezione 10.
Categorie di destinatari	Nessuna nuova categoria. Il percorso RECUPERA, non consegna: nessun dato dei visitatori lascia la nostra infrastruttura. Il destinatario è il cliente, nella propria interfaccia. Google compare qui come FONTE, non come destinatario — da un account gestito dal titolare del trattamento e di cui questi determina i contenuti.
Trasferimento verso paesi terzi	Nessun trasferimento di dati dei visitatori. La richiesta viene inviata a analyticsdata.googleapis.com e a BigQuery; vengono trasmessi la credenziale dell’account di servizio e il testo della query, nessun dato dei visitatori. I dati fluiscono nella direzione opposta. Dove risiedano i dati GA4 presso Google e con quali garanzie dipende dall’account del titolare del trattamento ed è una questione relativa al suo contratto con Google, non a questo registro.
Conservazione	180 giorni, decorrenti dal giorno DESCRITTO dalla riga (ga4_daily.tag, ga4_sessions.start_time) e non dal momento dell’importazione. Quest’ultimo viene aggiornato a ogni esecuzione, perché GA4 integra retroattivamente dati per un massimo di 48 ore e vengono quindi recuperati nuovamente gli stessi giorni; un periodo basato su di esso non scadrebbe mai. Applicato dall’esecuzione giornaliera in srv/db_worker.php, gli eventi prima delle rispettive sessioni. Una richiesta di cancellazione ai sensi dell’art. 17 li comprende dal 01/09/2026, nella misura in cui la riga possa essere attribuita tramite l’identificativo cliente; l’eliminazione in base al livello NON li comprende — i dati GA4 seguono un proprio calendario e altrimenti un cliente del livello gratuito li perderebbe dopo 7 anziché 180 giorni. Con il progetto vengono comunque eliminati, comprese le righe che non sono mai appartenute a una delle nostre sessioni. Ciò che questa eliminazione non raggiunge è esposto nella sezione 10.

A.15 Previsione di uscita e offerta che può attivare

Campo	Contenuto
Finalità	Stimare, a partire dai primi secondi di una visita, quanto sia probabile che il visitatore se ne vada a breve senza una seconda visualizzazione di pagina. Il titolare del trattamento può associare a tale stima un’offerta, mostrata al visitatore sul PROPRIO sito web. A differenza di A.8–A.14, questo trattamento non si conclude con un’analisi per il cliente, ma produce effetti sul visitatore — per questo ha una propria voce anziché essere una sottovoce di A.8. Inoltre, il titolare del trattamento può farsi proporre il testo e l’aspetto di tale offerta: un modello linguistico li redige sulla base del contesto del suo sito web. Una proposta non viene mai pubblicata automaticamente; viene adottata dal titolare del trattamento soltanto parte per parte.
Categorie di interessati	Visitatori dei siti web dei clienti, e soltanto alla PRIMA visualizzazione di pagina di una sessione: una visualizzazione successiva non costituisce più un arrivo e non riceve un punteggio. Nulla di tutto ciò viene eseguito senza consenso — l’attribuzione del punteggio si trova dietro la stessa barriera della registrazione.
Categorie di dati personali	Sedici caratteristiche misurate della visita in corso, tutte formate nel browser: dispositivo (mobile sì/no), visitatore di ritorno, clic a pagamento, motore di ricerca, rete sociale, ingresso sulla pagina iniziale, profondità del percorso della pagina di ingresso, ora notturna, numero di movimenti del mouse, eventi di scorrimento e clic nella finestra, secondi fino al primo inserimento, posizione di scorrimento più profonda in percentuale della pagina, numero di inversioni dello scorrimento, eventuale perdita del focus della scheda ed eventuale totale assenza di inserimenti. Da queste deriva UNA percentuale e fino a tre motivazioni in linguaggio comune. Nessun contenuto, nessuna coordinata, nessun valore dei campi. Il marcatore mp_seen_before nella memoria locale del browser registra che il visitatore è già stato qui; mp_offer_<date> conta quante volte gli è stata mostrata un’offerta oggi. La proposta di offerta non aggiunge informazioni su singoli visitatori, ma sul sito web: titolo, descrizione, intestazioni e navigazione da al massimo dieci istantanee di pagina, al massimo 40 indirizzi aperti da visitatori umani almeno cinque volte in 30 giorni, quota delle lingue delle pagine e colori, arrotondamento degli angoli e carattere dello sfondo della pagina e del pulsante più frequente, misurati nel browser. A questo scopo viene registrata la lingua per ogni visualizzazione di pagina (l’attributo lang della pagina). Indirizzi e intestazioni possono contenere tutto ciò che il sito web stesso produce (si veda A.17).
Dove sono conservati	Il MODELLO in projects.exit_modell (migrazione 100) — pesi, medie, deviazioni, qualità e momento dell’addestramento; non contiene dati personali, soltanto indicatori sulla popolazione. Il RISULTATO per visita come evento in session_custom_events: exit_risk con la percentuale e le motivazioni, oltre a exit_offer_shown, exit_offer_click e exit_offer_dismiss quando è stata mostrata un’offerta. Il valore più recente è inoltre conservato temporaneamente nella registrazione della connessione del server WebSocket (Redis, mp_websockets) affinché la vista dal vivo possa mostrarlo; scompare con la connessione. La proposta di offerta è conservata in projects.exit_offer_vorschlag (migrazione 114), le misurazioni dell’aspetto come le ultime 60 per canale in Redis (mp_design:<channel>), la lingua della pagina in session_pageviews.lang. Per la formulazione, il contesto passa attraverso ai_ki_queue alle nostre macchine che eseguono il modello linguistico (sezione 4).
Base giuridica	Istruzione del titolare del trattamento. L’addestramento avviene per progetto e soltanto sulle sessioni di quel progetto, almeno 200; al di sotto di tale soglia non viene creato alcun modello. Il consenso del visitatore copre la registrazione da cui provengono le caratteristiche — la stessa base di A.8. Spetta esclusivamente al titolare del trattamento decidere se mostrare un’offerta; per tale visualizzazione sul suo sito web è lui il titolare del trattamento, non noi.
Categorie di destinatari	Il cliente nella propria interfaccia. La percentuale e le motivazioni raggiungono inoltre il BROWSER DEL VISITATORE — vengono formate lì, anziché essere inviate lì — e sono disponibili al codice del titolare del trattamento tramite MousePlayer.on('exit_risk') e il livello dati. Un’offerta che successivamente compare viene vista dal visitatore stesso. Una proposta di offerta è visibile soltanto al titolare del trattamento nella propria interfaccia; raggiunge il sito web soltanto quando questi la adotta. Nulla viene inviato a terzi.
Trasferimento verso paesi terzi	Nessuno. L’addestramento e l’attribuzione dei punteggi vengono eseguiti sull’infrastruttura a Łódź o nel browser del visitatore. La proposta di offerta viene formulata dal modello linguistico sul nostro hardware a Łódź (sezione 4); nulla viene inviato a un servizio di IA esterno.
Conservazione	Gli eventi condividono il periodo di conservazione della sessione a cui appartengono (A.7) e vengono eliminati con essa. Il modello viene sovrascritto a ogni esecuzione; non esiste una cronologia. I due marcatori risiedono nella memoria locale del visitatore: mp_seen_before senza scadenza finché non la cancella o revoca il consenso, mp_offer_<date> soltanto per il giorno corrente (mp.js rimuove le voci precedenti la volta successiva che ne imposta una). Inoltre, mp_design_sent nella memoria di sessione della scheda registra che l’aspetto è già stato misurato. Alla revoca mp.js rimuove tutti e tre. La proposta di offerta rimane finché una nuova non la sostituisce; le misurazioni dell’aspetto scadono in Redis dopo 30 giorni; la lingua della pagina condivide il periodo di conservazione della rispettiva visualizzazione di pagina.

A.16 Indicatore di abbandono per i visitatori di ritorno

Campo	Contenuto
Finalità	Stimare dalle visite precedenti della stessa persona se si stia allontanando, affinché il titolare del trattamento possa reagire. A differenza di A.15, questa valutazione considera la cronologia e non la visita in corso.
Categorie di interessati	Visitatori di ritorno dei siti web dei clienti con almeno 2 sessioni. Chi è venuto una sola volta non riceve alcuna riga. La chiave è la persona ai sensi di A.4 — l’identificativo cliente impostato dal titolare del trattamento, altrimenti l’identificativo visitatore.
Categorie di dati personali	Un valore di rischio compreso tra 0 e 1, fino a quattro motivazioni in linguaggio comune da un elenco fisso (coinvolgimento in calo, visite brevi, attrito, ritardo; un acquisto nelle ultime due visite riduce il valore), il numero di visite e il momento dell’ultima. Nessun contenuto, nessuna coordinata. Non è un modello appreso, ma quattro osservazioni conteggiabili — ciascuna compare nella riga come motivazione, affinché un valore non compaia mai senza una di esse.
Dove sono conservati	ai_churn (migrazione 100): channelid, person_key, visitor_id, risiko, gruende, sitzungen, letzte_sitzung, berechnet_am. Inoltre un hash Redis per canale, mp_churn:<channel>, con scadenza dopo due giorni, da cui il server WebSocket legge alla connessione; vi vengono inseriti soltanto quelli superiori alla soglia.
Base giuridica	Istruzione del titolare del trattamento; le sessioni sottostanti si basano sul consenso del visitatore (A.1). Calcolato per progetto, mai tra clienti diversi.
Categorie di destinatari	Il cliente nella propria interfaccia. Il valore viene inoltre inviato al BROWSER DEL VISITATORE non appena questi si connette ed è disponibile al codice del titolare del trattamento tramite MousePlayer.on('churn_risk'); questi può associarvi un’offerta. Questo trasferimento al dispositivo dell’interessato stesso è il motivo per cui la voce compare qui e non sotto A.8. Nulla viene inviato a terzi.
Trasferimento verso paesi terzi	Nessuno.
Conservazione	La riga viene riscritta per il canale a ogni esecuzione e viene eliminata con le sessioni da cui deriva. La voce Redis scade autonomamente dopo due giorni.

A.17 Report riepilogativo su un visitatore

Campo	Contenuto
Finalità	Riunire tutte le visite di UNA persona in un report leggibile: da dove è arrivata, per cosa è stato pagato, dove ha incontrato ostacoli e se ne è derivato un obiettivo raggiunto. Le risultanze vengono calcolate; un modello linguistico al massimo le riformula. Un report viene richiesto dal cliente per un determinato visitatore oppure automaticamente per al massimo 5 visitatori per progetto e notte — scelti tra le visite a pagamento senza acquisto.
Categorie di interessati	Visitatori dei siti web dei clienti per i quali esiste più di una visita. La chiave è la persona ai sensi di A.4.
Categorie di dati personali	Al massimo quattordici risultanze calcolate in forma testuale: numero di visite e pagine, periodo, dispositivi, fonte compresa la campagna, acquisti e obiettivi raggiunti, i tre maggiori punti critici con il relativo percorso, l’ultima sessione e le ETICHETTE degli elementi cliccati (fino a cinque, ciascuna di 60 caratteri). Inoltre il testo generato. I valori dei campi dei moduli non vi rientrano — non lasciano mai il browser. Le etichette e i percorsi, invece, provengono da ciò che il sito web del titolare del trattamento stesso produce e possono quindi contenere un nome o un indirizzo se questi li visualizza lì o li scrive nell’URL; registrato come lacuna nella sezione 10.
Dove sono conservati	ai_besucher_bericht (migrazione 100) con channelid, person_key, lang, le risultanze, il loro hash, il testo e il nome del modello. Per la formulazione, le RISULTANZE — non la registrazione — passano attraverso ai_ki_queue alle macchine che eseguono il modello linguistico (hardware proprio nella stessa rete locale, si veda la sezione 4). Ogni report consuma una quota (ai_ki_kontingent per area di lavoro e mese, 3 nel piano gratuito, altrimenti 200).
Base giuridica	Istruzione del titolare del trattamento; le sessioni sottostanti si basano sul consenso del visitatore (A.1). Il modello linguistico non viene né addestrato né modificato; si limita a formulare il testo.
Categorie di destinatari	Il cliente nella propria interfaccia. Il visitatore non ne viene informato — a differenza di A.15 e A.16, nulla qui produce effetti su di lui.
Trasferimento verso paesi terzi	Nessuno. Il modello linguistico viene eseguito sul nostro hardware a Łódź (sezione 4); nulla viene inviato a un servizio di IA esterno.
Conservazione	180 giorni dalla richiesta, applicati dal passaggio successivo del processo IA. Se l’ultima sessione del visitatore viene eliminata prima, il report viene eliminato con essa.

A.18 Accesso autonomo del visitatore e richiesta di cancellazione

Campo	Contenuto
Finalità	Mostrare a un visitatore ciò che è conservato su di lui e consentirgli di farlo cancellare — assistenza al titolare del trattamento nell’esercizio dei diritti degli interessati ai sensi dell’art. 28(3)(e) GDPR. Raggiungibile su /my-data, /meine-daten e /moje-dane.
Categorie di interessati	Visitatori dei siti web dei clienti, e soltanto quelli che presentano il proprio identificativo. Il titolare del trattamento deve inserire il link; è lui il titolare del trattamento per i propri visitatori e l’informativa ai sensi dell’art. 13 deve trovarsi nella sua informativa.
Categorie di dati personali	Vengono mostrati il numero, il periodo e i domini delle sessioni — nessuna registrazione. L’identificativo è un token al portatore; chi conosce quello di un’altra persona non dovrebbe poter vedere il comportamento di un estraneo. Per lo stesso motivo la risposta resta limitata al DISPOSITIVO e non utilizza mp_person_sql() per riunire ciò che appartiene a una persona: l’aggregazione rivelerebbe DI PIÙ, non di meno. Della richiesta di cancellazione conserviamo l’identificativo, il momento della richiesta e il momento dell’esecuzione.
Dove sono conservati	visitor_deletion_requests (visitor_id, requested_at, done_at) — 0 righe. La pagina stessa non conserva nulla; legge. La richiesta viene eseguita dal worker attraverso la stessa catena di eliminazione attivata dal titolare del trattamento — un secondo percorso di eliminazione costituirebbe un secondo punto per la stessa verità.
Base giuridica	Art. 28(3)(e) GDPR (assistenza al titolare del trattamento) e sua istruzione. La forma dell’identificativo viene verificata (^v_[a-z0-9]{9}_\d{13}$); qualsiasi altro formato viene rifiutato.
Categorie di destinatari	Il visitatore stesso. Nulla viene inviato al cliente — viene a conoscenza di una richiesta di cancellazione soltanto perché le sessioni scompaiono.
Trasferimento verso paesi terzi	Nessuno.
Conservazione	La riga rimane come prova che la cancellazione è avvenuta e di quando è avvenuta. Non contiene dati comportamentali. Se viene ripristinato un backup, le richieste registrate vengono eseguite nuovamente prima che il sistema torni in esercizio (clausola 24.2 dei Termini di servizio).

A.19 Riesame del rilevamento dei bot — decisioni del gestore come esempi di apprendimento

Campo	Contenuto
Finalità	Le sessioni che il rilevamento delle ondate ha contrassegnato retroattivamente come bot vengono controllate nuovamente da un watchdog e i casi dubbi vengono segnalati negli Urgent Logs. Lì il gestore decide con un clic: Essere umano o Bot. Ogni decisione diventa un esempio di apprendimento da cui vengono ricalcolati i pesi dei sette segnali — soltanto i pesi, non la soglia, e soltanto a partire da un numero minimo di decisioni impostabile nell’area amministrativa (bot_revision_lern_min). Al di sotto di tale numero si applicano valori fissi.
Categorie di interessati	Visitatori dei siti web dei clienti la cui sessione è stata segnalata come caso dubbio e la persona che ha deciso (personale del cliente o nostro).
Categorie di dati personali	Nessun contenuto dei visitatori. Vengono conservati il canale, l’identificativo della sessione, la decisione, il punteggio, i nomi dei segnali applicabili (ad esempio: identificativo diverso da quello dell’ondata, referrer presente, indirizzo di una rete privata) e l’identificativo di chi decide. Il vettore delle caratteristiche fa parte dell’esempio perché la sessione stessa non esiste più dopo il suo periodo di conservazione e l’apprendimento ne ha ancora bisogno.
Dove sono conservati	bot_review_labels (migrazione 140): una riga per sessione; chi cambia idea la sovrascrive. Viene letta da cfg/bot_revision_lib.php. Senza la tabella i watchdog funzionano con pesi fissi.
Base giuridica	Istruzione del titolare del trattamento; alle sessioni stesse si applica A.1. La procedura migliora la distinzione tra bot ed esseri umani e quindi l’esattezza delle analisi (art. 5(1)(d) GDPR). Nessuna decisione sul visitatore dipende da essa; uno sblocco rimuove la marcatura da una sessione, nulla di più.
Categorie di destinatari	Nessuno al di fuori dell’interfaccia; gli esempi sono visibili soltanto al gestore.
Trasferimento verso paesi terzi	Nessuno.
Conservazione	Impostazione predefinita: nessuna eliminazione automatica — un esempio è pseudonimo e non contiene contenuti del visitatore, e il suo valore aumenta con la quantità di esempi disponibili. Il periodo può essere impostato in anni nell’area amministrativa (retention_bot_labels_years, 0 = illimitato); a partire da 1, il watchdog di stato (srv/cron_status.php) elimina le righe dopo quel numero di anni. Non rientra in alcuna catena di eliminazione delle sessioni: quando la sessione viene eliminata, l’esempio rimane — intenzionalmente, ma registrato come lacuna nella sezione 10.

A.20 Tracciamento degli elementi — clic sugli elementi di pagina contrassegnati

Campo	Contenuto
Finalità	Nella procedura guidata per gli elementi, il titolare del trattamento contrassegna elementi delle proprie pagine — singolarmente o come gruppo di elementi simili, tramite selettore CSS — e riceve, per ogni contrassegno, clic, sessioni con un clic, visitatori e tasso di clic. Il conteggio è retroattivo: srv/element_worker.php assegna i clic già registrati (A.1, mouse_events_analytik) all’elemento contrassegnato nell’istantanea della rispettiva visualizzazione di pagina. Un contrassegno può anche essere un obiettivo o un passaggio di funnel; le relative corrispondenze contano allora come obiettivo o passaggio raggiunto.
Categorie di interessati	Visitatori dei siti web dei clienti i cui clic sono stati registrati.
Categorie di dati personali	Un’integrazione della registrazione dei clic (A.1), altrimenti nessuna nuova raccolta: quando un visitatore clicca un elemento comparso soltanto dopo l’istantanea (ad esempio un menu aperto o un pop-up), mp.js dal 27/09/2026 invia anche la sua struttura — tag, classi, alcuni attributi (role, type, name, percorso del link senza query, data-*), posizione tra gli elementi fratelli dello stesso tipo ed etichetta visibile; nelle aree mascherate soltanto tag e identificativo. Viene conservata con gli eventi della visualizzazione di pagina (A.1) e ne condivide il periodo di conservazione. Per ogni corrispondenza vengono conservati: identificativi di canale, sessione e visualizzazione di pagina, inizio della sessione, tipo di clic (clic o tocco), etichetta visibile dell’elemento colpito, tratta dall’istantanea — mascherata esattamente come nella registrazione — e, se il titolare del trattamento lo sceglie, il valore di un attributo di quell’elemento (ad esempio data-id) per la suddivisione. Dal 27/09/2026 il worker degli elementi annota i clic il cui bersaglio manca nell’istantanea e per i quali non è stata inviata alcuna struttura (clic più vecchi): identificativo di canale, sessione e visualizzazione di pagina, momento e hash del percorso di pagina e dell’etichetta — l’etichetta stessa non viene conservata lì. Dai clic risolti apprende, per ogni contrassegno, quale etichetta su quale percorso di pagina corrisponda al contrassegno (percorso, etichetta, due contatori, nessun collegamento a un visitatore). Quando tutte le osservazioni concordano, un clic annotato viene assegnato come corrispondenza — contrassegnata come trasferita — oppure come mancata corrispondenza. Il contrassegno stesso (nome, selettore, area della pagina) e i contatori giornalieri di copertura non contengono riferimenti a un visitatore.
Dove sono conservati	mp_element_regeln, mp_element_klicks e mp_element_tag (migrazione 152), mp_element_offen e mp_element_muster (migrazione 155). Letti da cfg/element_lib.php.
Base giuridica	Istruzione del titolare del trattamento (art. 28(3)(a) GDPR), impartita creando un contrassegno; ai clic stessi si applica A.1. La valutazione riepiloga registrazioni esistenti; l’unica aggiunta è la struttura dei bersagli dei clic creati dopo l’istantanea (sopra), che descrive le stesse cose dell’istantanea della pagina. Nessuna decisione sul visitatore dipende da essa.
Categorie di destinatari	Nessuno al di fuori dell’interfaccia finché il contrassegno viene soltanto valutato. Se il titolare del trattamento lo utilizza come obiettivo o passaggio di funnel, gli obiettivi raggiunti e gli abbandoni dei funnel vengono inclusi nelle trasmissioni che ha attivato (4.1) — con l’identificativo della sessione, il nome dell’obiettivo o del funnel e l’etichetta dell’elemento cliccato, e soltanto per clic non più vecchi di quanto impostato nell’area amministrativa (due ore per impostazione predefinita). Le corrispondenze più vecchie vengono conteggiate nell’interfaccia ma non trasmesse.
Trasferimento verso paesi terzi	Nessuno.
Conservazione	Una corrispondenza viene eliminata con la sessione da cui proviene: mp_element_klicks fa parte della catena di eliminazione (mp_sitzungen_loeschen() in srv/db_worker.php) e il worker degli elementi rimuove ogni ora le corrispondenze la cui visualizzazione di pagina non esiste più — quindi anche dopo percorsi di eliminazione esterni a tale catena, al più tardi entro un’ora. I clic annotati (mp_element_offen) vengono eliminati con la sessione attraverso gli stessi percorsi. L’eliminazione di un contrassegno elimina le relative corrispondenze, contatori, annotazioni e modelli ricorrenti; questi ultimi non contengono collegamenti a un visitatore e vengono eliminati anche quando cambia il selettore o dopo un anno senza nuove osservazioni. Volutamente non esiste un periodo separato: sarebbe più lungo o più breve di quello della registrazione ed entrambi sarebbero errati.

A.21 Sondaggi di feedback — una domanda al visitatore, la risposta accanto alla registrazione

Campo	Contenuto
Finalità	Il titolare del trattamento pone ai visitatori del proprio sito una breve domanda — probabilità di raccomandazione da 0 a 10, cinque faccine, sì/no o una scelta — e, se lo desidera, una domanda successiva a testo libero. La risposta viene associata alla visita affinché possa guardare le registrazioni dei visitatori insoddisfatti. Domanda, momento, quota di visitatori e lingua vengono impostati dal titolare del trattamento.
Categorie di interessati	Visitatori dei siti web dei clienti a cui è stato mostrato un sondaggio — secondo un campionamento impostato dal titolare del trattamento e al massimo una volta per intervallo impostato dal titolare del trattamento — e visitatori che hanno aperto autonomamente un sondaggio tramite un pulsante sul bordo della pagina; in questo caso l’intervallo inizia soltanto con una risposta. Viene raccolto soltanto ciò che il visitatore inserisce: chi chiude la domanda lascia soltanto il fatto che sia stata mostrata e chiusa.
Categorie di dati personali	La valutazione (un numero o l’opzione scelta) con il relativo sentiment (negativo, neutro, positivo), momento e identificativo del sondaggio come evento della visita (A.7): survey_shown, survey_answer e survey_dismiss. Per una domanda successiva, un TESTO LIBERO di al massimo 500 caratteri con la lingua della pagina. Prima dell’invio, mp.js rimuove indirizzi e-mail, indirizzi IP e numeri di telefono e il worker lo fa una seconda volta (mp_umfrage_text_filtern()); sotto il campo si chiede ai visitatori di non inserire dati personali. Nel browser in uso all’interessato, mp_umfrage (localStorage) conserva, per ogni sondaggio, l’estrazione del campione e il momento dell’ultima visualizzazione, per il pulsante sul bordo della pagina il momento dell’ultima risposta.
Dove sono conservati	La valutazione in session_custom_events e session_custom_event_params (A.7); il testo libero in mp_umfrage_text (migrazione 157) — volutamente separato: è la parte più sensibile di un sondaggio e non appartiene alla tabella letta da webhook e connettori. I sondaggi stessi, ossia soltanto il testo di cui il titolare del trattamento è l’autore, in projects.survey_json.
Base giuridica	Istruzione del titolare del trattamento (art. 28(3)(a) GDPR), impartita creando e attivando un sondaggio. Rispondere è volontario. Spetta al titolare del trattamento valutare l’esistenza di una base giuridica per la domanda e la domanda successiva e se siano menzionate nella propria informativa sulla privacy; il modulo di testo per i clienti indica il sondaggio come voce separata. Nessuna decisione sul visitatore dipende da esso.
Categorie di destinatari	Il cliente, nella vista dei risultati e nel lettore. La valutazione è un evento personalizzato e viene quindi inclusa nei trasferimenti che il titolare del trattamento ha attivato per tali eventi (4.1). Il testo libero non viene inviato a nessun connettore: mp_umfrage_text viene letto soltanto da cfg/umfrage_lib.php.
Trasferimento verso paesi terzi	Nessuno — salvo attraverso un trasferimento attivato dal titolare del trattamento (4.1), e in quel caso soltanto la valutazione.
Conservazione	Con la sessione: mp_umfrage_text fa parte di mp_sitzungen_loeschen(), il percorso di eliminazione dall’interno del lettore, mp_konto_loeschen() e l’eliminazione del progetto e dell’area di lavoro nella dashboard; la valutazione viene eliminata con session_custom_events. Volutamente non esiste un periodo proprio — sarebbe più lungo o più breve di quello della registrazione ed entrambi sarebbero errati. La chiave mp_umfrage nel browser viene rimossa alla revoca.

A.22 Ricerca del testo visualizzato — quali visite mostravano un determinato testo sulla pagina

Campo	Contenuto
Finalità	Il cliente trova le visite in cui un determinato testo era presente sulla propria pagina — al caricamento o visualizzato successivamente, ad esempio un messaggio di errore, un avviso o “Esaurito” — per guardarne le registrazioni. La ricerca si trova nello User Explorer.
Categorie di interessati	Visitatori dei siti web dei clienti la cui visita è stata registrata (A.2) e non è riconosciuta come automatizzata.
Categorie di dati personali	Le porzioni di testo presenti nell’istantanea e nelle modifiche della pagina (A.2), una per nodo di testo, oltre alla loro associazione alla visualizzazione di pagina. Ciò che viene letto è già stato registrato: le aree mascherate e i dati inseriti nei moduli sono già sostituiti e non vengono trovati. Se una pagina stessa mostra dati personali (una pagina di conferma con nome e indirizzo), essi si trovano anche qui — come nella registrazione.
Dove sono conservati	mp_text_block (dizionario per progetto, ogni porzione di testo una sola volta), mp_text_pv (quale visualizzazione di pagina conteneva quale porzione) e mp_text_stand (quale visualizzazione è stata letta), migrazione 175. Compilati ogni dieci minuti da srv/textsuche_lauf.php sul nostro server.
Base giuridica	Istruzione del titolare del trattamento (art. 28(3)(a) GDPR): la ricerca rende accessibile la stessa registrazione commissionata dal titolare del trattamento. Nessuna decisione sul visitatore dipende da essa.
Categorie di destinatari	Il cliente, come filtro nello User Explorer. Nessun trasferimento, nessun connettore.
Trasferimento verso paesi terzi	Nessuno.
Conservazione	30 giorni dall’inizio della visualizzazione di pagina, un periodo più breve rispetto alla registrazione: successivamente vengono rimossi l’associazione e lo stato, una porzione di testo con la sua visualizzazione più recente. Se la sessione viene eliminata prima (periodo di conservazione, richiesta di cancellazione, eliminazione nel lettore, eliminazione del progetto o dell’account), l’associazione viene eliminata con essa — direttamente in mp_sitzungen_loeschen() e nell’eliminazione del progetto, in tutti gli altri percorsi al più tardi dopo dieci minuti tramite l’esecuzione che rimuove le associazioni senza una visualizzazione di pagina.

4. Parte A — destinatari, sub-responsabili e trasferimenti verso paesi terzi

Il percorso di registrazione stesso non contiene chiamate in uscita a terzi. Ciò è stato accertato il 10/08/2026 cercando in cfg/, srv/, class/ e www/ (esclusi vendor e node_modules) curl_init, curl_exec, file_get_contents con http, fsockopen e stream_context_create, nonché tutti i valori letterali https. La risoluzione geografica utilizza file MaxMind locali, il foglio di stile dell’interfaccia viene servito come file precompilato dal nostro server e le immagini delle bandiere provengono da /img/flags/. Dal 23/09/2026 le e-mail vengono inviate tramite SMTP attraverso Namecheap Private Email (mail.privateemail.com, porta 465, TLS) con il mittente office@mouseplayer.com; la funzione PHP mail() verrebbe utilizzata soltanto se non fosse configurato alcun server SMTP, il che non avviene. Limite di questa ricerca: le directory vendor (Stripe SDK, Google Cloud SDK, PHPMailer, Symfony) non sono state esaminate — è lì che si trovano gli endpoint dei servizi indicati di seguito.

Destinatario	Ruolo e dati trasferiti	Destinazione	Garanzia	Stato
Stripe	Elaborazione dei pagamenti per gli account dei CLIENTI. E-mail, nome, indirizzo di fatturazione e dati di pagamento dei clienti. www/billing_ajax.php:134 imposta la chiave API; le righe 381 e 687 trasmettono customer_email; la riga 48 imposta billing_address_collection='required'; la riga 54 customer_update per indirizzo e nome; le righe 462/527/672 trasmettono metadata. Canale di ritorno www/api/webhook_stripe.php, tabella stripe_events. Nessun dato dei visitatori.	USA	Accordo sul trattamento dei dati accettato il 01/08/2026 nell’ambito dei termini accettati all’apertura dell’account (dichiarazione del titolare del trattamento). Parte contrattuale: Stripe Payments Europe, Ltd.; per i trasferimenti negli USA, Stripe, Inc. Modulo 2 (da titolare del trattamento a responsabile del trattamento). Questo deriva dall’assegnazione dei ruoli, anziché da una consultazione: MousePlayer è il titolare del trattamento per i dati degli account e di fatturazione trasmessi, Stripe il responsabile del trattamento per tale parte. La versione accettata non è stata esaminata; se differisce, prevale.	Al 16/10/2026 non in esercizio: entrambi gli slot delle chiavi contengono chiavi di prova e non vengono elaborati pagamenti reali.
VIES (Commissione europea)	Verifica di un numero di identificazione IVA fornito da un CLIENTE tramite l’interfaccia REST pubblica del VAT Information Exchange System (cfg/lib.php). Vengono trasmessi il codice paese e il numero IVA; vengono restituiti la validità e, ove disponibili, il nome e l’indirizzo dell’impresa, conservati con l’account (B.1). Nessun dato dei visitatori.	UE	Organismo pubblico dell’Unione; non è un responsabile del trattamento, non è richiesto alcun contratto. La richiesta serve a verificare i dati fiscali del cliente.	In uso non appena un cliente inserisce un numero IVA.
Telegram	Notifica di assistenza. Fino all’11/08/2026 cfg/lib.php trasmetteva l’INTERA richiesta di assistenza: stato dell’utente compreso l’ID utente, indirizzo e-mail, oggetto, 'IP / Kraj' con l’indirizzo IP NON TRONCATO, URL di origine e testo completo del messaggio. Dall’11/08/2026 (commit 02846c2, cfg/lib.php) viene inviata una sola stringa fissa e nient’altro: 'MousePlayer: es liegt eine neue Supportanfrage vor.' Nessuna variabile, nessun parse_mode e, deliberatamente, nessun numero di pratica e nessun link tratto dalla richiesta. La richiesta stessa continua a essere conservata invariata in support_requests — i dati non vengono più inviati all’esterno, non scompaiono.	Al di fuori dell’UE	Fino all’11/08/2026: nessuno — Telegram non offre un accordo sul trattamento dei dati per i bot. Dall’11/08/2026 non è più necessario: la notifica non contiene dati personali, quindi Telegram non è né responsabile del trattamento né destinatario. Decisione del proprietario dell’11/08/2026: il canale rimane, il messaggio viene ridotto a un semplice segnale, l’indirizzo IP viene rimosso. Una protezione (ai/pruefstand/test_telegram_signal.php) verifica non il risultato, ma la possibilità — quali variabili possano raggiungere il messaggio; quattro sono consentite, 15 attributi sono vietati e il testo deve essere una stringa tra apici singoli senza interpolazione.	ATTIVO, ma senza dati personali — reso innocuo l’11/08/2026. TELEGRAM_BOT_TOKEN e TELEGRAM_CHAT_ID sono ancora impostati in .env; viene inviato soltanto il segnale.
Google reCAPTCHA	Accesso, registrazione, modulo di assistenza, pagina di fatturazione. Verifica lato server in www/login.php:31-45 e cfg/lib.php:6337 tramite https://www.google.com/recaptcha/api/siteverify; lato browser in www/billing.php:1290.	USA	reCAPTCHA rimane in produzione. Termini di Google sul trattamento dei dati accettati il 01/08/2026 (dichiarazione del titolare del trattamento). Parte contrattuale: Google Ireland Limited; per i trasferimenti negli USA, Google LLC. Sul sistema di sviluppo il servizio è disattivato (mp_recaptcha_aktiv() restituisce !mp_ist_dev()), in produzione è attivo — lì il trasferimento avviene a ogni operazione di accesso, registrazione, password e fatturazione.	Inattivo soltanto su questa istanza: mp_recaptcha_aktiv() è definito in cfg/config.php:131-133 come !mp_ist_dev() e APP_ENV=dev. Attivo in produzione.
Google BigQuery	Esportazione notturna nel progetto GCP del CLIENTE STESSO. srv/cron_integration_bigquery.php:95-100 seleziona 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 e li carica come NDJSON in visitor_sessions_YYYYMMDD.	Regione scelta dal cliente	La destinazione è il progetto del cliente stesso, quindi il cliente è l’importatore. La chiave dell’account di servizio è conservata cifrata in projects.bigquery_sa_json (decrypt_sa_key, chiave BIGQUERY_SA_AES_KEY da .env).	INATTIVO. projects.bigquery_active=0 per tutti i 7 progetti, bigquery_project_id NULL ovunque e il processo non è in esecuzione.
Webhook dei clienti	srv/cron_integration_webhook.php:63-80. Corpo costruito in srv/db_worker.php:1313-1323: timestamp, event_type, channel_id, session_id, un link diretto al lettore 'https://<host>/player?id=...&session=...' e i parametri dell’evento. Formattazione speciale per Slack e Discord (mp_format_webhook_body, cfg/lib.php:5978).	Indeterminato — impostato dal cliente	La destinazione viene scelta dal cliente e rientra quindi nella responsabilità del titolare del trattamento. Sì, la destinazione viene registrata per ogni Cliente (decisione del titolare del trattamento, 17/08/2026). È già presente nel progetto; manca la registrazione di CHI l’abbia impostata e quando. Dal 17/08/2026 ogni modifica della destinazione del webhook compare nel registro delle modifiche (log_audit, azione update_integrations, campo webhook_host). Viene registrato soltanto l’host, non l’indirizzo completo: il percorso di un webhook contiene spesso un segreto — Slack e Discord inseriscono la chiave nell’URL — e un registro delle modifiche è il posto sbagliato per conservarlo. Per sapere verso dove i dati degli eventi lasciano la nostra infrastruttura, l’host è sufficiente.	INATTIVO. projects.webhook_active=0 e webhook_url NULL per tutti i 7 progetti. Il processo di smistamento è in esecuzione.
Meta (Conversions API)	Soltanto se il titolare del trattamento attiva il connettore e conserva il proprio token di accesso. Vengono trasmessi esclusivamente gli obiettivi raggiunti del progetto interessato: nome dell’obiettivo, marca temporale, identificativo dell’evento derivato da sessione e obiettivo per la deduplicazione, valore e valuta ove impostati, oltre ai cookie _fbp e _fbc e alla stringa user agent. Nome, indirizzo e-mail, numero di telefono e indirizzo IP non vengono trasmessi — MousePlayer dispone comunque soltanto di un IP troncato, che sarebbe inutile per la corrispondenza. L’invio avviene esclusivamente per sessioni con consent_state = 'granted'; senza _fbp/_fbc la trasmissione viene omessa completamente, perché senza una chiave di corrispondenza non avrebbe alcuno scopo. Codice: mp_capi_meta_ausloesen() e mp_capi_meta_zustellen() in cfg/lib.php, invio tramite srv/cron_integration_webhook.php.	USA	Meta non è un sub-responsabile di MousePlayer. MousePlayer esegue la trasmissione su istruzione del titolare del trattamento — tale istruzione consiste nell’attivazione del connettore e nella conservazione del token. Il destinatario è l’account pubblicitario del titolare del trattamento; il rapporto contrattuale con Meta, comprese le garanzie per il trasferimento negli USA, esiste tra il titolare del trattamento e Meta, non tra Meta e MousePlayer. Meta tratta i dati per finalità proprie e, in tale misura, come titolare autonomo del trattamento.	Connettore disponibile dal 19/08/2026, attivato per nessun progetto nella configurazione fornita.
HubSpot / Pipedrive	Soltanto se il titolare del trattamento attiva il connettore e conserva il proprio token API. Viene trasmesso l’identificativo cliente impostato dal titolare del trattamento stesso (setUserId()), utilizzato per individuare il contatto, seguito da una nota contenente l’URL della riproduzione della sessione. Nessun dato comportamentale, nessun contenuto della registrazione. Se la ricerca non trova alcun contatto, l’operazione termina senza ulteriori trasmissioni. Codice: mp_crm_kontakt_suchen() e mp_crm_notiz_anhaengen() in cfg/lib.php.	USA (HubSpot), UE (Pipedrive)	Come per Meta: il destinatario è l’account CRM del titolare del trattamento e il rapporto contrattuale esiste tra questi e il fornitore. MousePlayer trasmette su sua istruzione.	Connettore disponibile dal 19/08/2026, attivato per nessun progetto nella configurazione fornita.
Google Cloud Storage (Varsavia)	Copia esterna del backup giornaliero. Documentata in OFFENE_PUNKTE.md sezione 3.3: 'mysqldump --all_databases' e 'tar /var/www/' — ogni database e l’intero albero web, compreso ogni .env. Riscontrati localmente 653 MB di database e 678 MB di file. Fino all’11/08/2026 il backup veniva eseguito ogni giorno alle 02:00 e inviato senza cifratura. Dall’11/08/2026 viene cifrato sul nostro server prima del trasferimento (rclone crypt; vengono cifrati anche i nomi di file e directory) e i due file delle chiavi sono conservati sullo stesso server con modalità 600 — Google non ne dispone; da allora l’esecuzione programmata avviene alle 03:00. La precedente cartella di destinazione non cifrata contenente le copie anteriori all’11/08/2026 è stata eliminata il 12/08/2026.	Polonia (UE) – bucket nella regione europe-central2 (Varsavia), dal 05/09/2026. Fino ad allora la copia era conservata in un account Google Drive privato per il quale non è possibile prenotare una regione dei dati; la destinazione doveva essere indicata come USA / tutto il mondo.	Trattamento per nostro conto ai sensi del Google Cloud Data Processing Addendum, accettato per il progetto Cloud; parte contrattuale Google Ireland Limited. Questo elimina lo scostamento indicato qui dal 17/08/2026 al 05/09/2026: tali termini non sono disponibili per un account Google privato e le condizioni generali d’uso non costituiscono un trattamento per conto altrui ai sensi dell’art. 28 GDPR. La copia continua a essere cifrata prima del trasferimento (rclone crypt, compresi i nomi di file e directory) e le chiavi sono conservate esclusivamente dal titolare del trattamento — Google vede blocchi privi di significato. Questo sottrae il contenuto a Google, non il ruolo.	ATTIVO. Fino all’11/08/2026 senza cifratura e senza verifica a destinazione — l’esecuzione utilizzava la configurazione rclone di root e lo script non registrava nulla. Dall’11/08/2026 cifrato; le esecuzioni dell’11/08/2026 (avviata manualmente) e del 12/08/2026 (programmata, alle 03:00) sono registrate ed entrambe hanno superato una verifica a destinazione (numero di byte del dump del database). Il funzionamento giornaliero è quindi comprovato, non soltanto il primo tentativo. Il gestore ha verificato la decifratura; non esiste una nostra misurazione al riguardo. La precedente cartella di destinazione non cifrata è stata eliminata il 12/08/2026. Dal 05/09/2026 la copia viene inviata a Google Cloud Storage a Varsavia; le copie precedentemente conservate nell’account Drive sono state eliminate il 06/09/2026, dopo la verifica di un ripristino dalla nuova destinazione. Tipo di account, regione dei dati e contratto sono quindi chiariti. Dal 06/10/2026 il backup contiene anche l’archivio degli eventi di registrazione trasferiti fuori dal sistema (/mnt/mouseplayer-dev-archive, A.1); localmente questo archivio si trova sullo stesso disco del sistema e soltanto la copia cifrata assicura la conservazione in un altro luogo. Le prove di ripristino dalla copia sono state eseguite il 05/09/2026 e il 06/09/2026 e il 07/10/2026 (ripristino completo dei dati). I backup giornalieri vengono conservati per 7 giorni, quelli settimanali per 364 giorni.
Namecheap	Registrazione del dominio, DNS autoritativo, inoltro delle e-mail in entrata; dal 23/09/2026 anche invio delle e-mail in uscita tramite Namecheap Private Email. Dati del dominio; contenuto e mittente delle e-mail indirizzate a MousePlayer. Per le e-mail in uscita: nome, indirizzo e-mail e contenuto del messaggio al titolare dell’account, per la notifica di accesso anche indirizzo IP, dispositivo e posizione approssimativa.	USA	Data Processing Addendum accettato il 01/08/2026 (dichiarazione del titolare del trattamento); comprende le attuali clausole contrattuali tipo. La posta in entrata passa permanentemente attraverso l’inoltro di Namecheap; non è coinvolto alcun altro fornitore di caselle e-mail (decisione del titolare del trattamento, 17/08/2026). Dal 23/09/2026 la posta in uscita viene inviata tramite il servizio SMTP di Namecheap Private Email (TLS): comunicazioni contrattuali, comunicazioni relative all’account, notifiche di accesso e avvisi dei monitor.	In uso.
Let's Encrypt (ISRG)	Emissione e rinnovo dei certificati TLS. Soltanto nomi di dominio.	USA	Autorità di certificazione pubblica; non tratta dati personali per nostro conto.	In uso.
consented.eu	CMP sulle pagine di MousePlayer STESSO, caricata nel browser del visitatore: cfg/header.php:48 (stub.js) e riga 50 (cmp.js). Riguarda i visitatori di mouseplayer.com, non la registrazione presso i clienti.	Luogo del trattamento: lo stesso server di MousePlayer (/var/www/html/ConsentedEU sulla stessa macchina, misurato il 17/08/2026). Base contrattuale: non applicabile — consented.eu è gestito dalla stessa persona giuridica (dichiarazione del titolare del trattamento). Non avviene alcun trasferimento a terzi.	Non applicabile per lo stesso motivo: nessun terzo, quindi nessun accordo.	In uso sulle proprie pagine.

4.1 Destinatari attivati dal titolare del trattamento

La tabella precedente elenca i destinatari incaricati da MousePlayer stesso. Accanto a essi esistono connettori che il titolare del trattamento attiva e per i quali conserva le proprie credenziali. Non sono sub-responsabili di MousePlayer; il rapporto contrattuale con essi esiste tra il titolare del trattamento e il destinatario, comprese le garanzie per i paesi terzi. Vengono indicate categorie anziché fornitori — i fornitori disponibili all’interno di una categoria cambiano con l’insieme delle funzioni; fa fede la selezione nelle impostazioni del progetto. Ogni trasmissione viene attivata lato server da srv/cron_integration_webhook.php; l’esito viene registrato nel registro delle consegne (A.11).

Categoria	Dati inviati	Evento che lo attiva
Webhook verso un indirizzo liberamente scelto	Nome dell’evento, ID di canale e sessione, URL della riproduzione, parametri dell’evento. Firmato con HMAC-SHA256 sulla marca temporale e sul corpo.	un evento a cui il titolare del trattamento si è iscritto
Sistema di gestione delle relazioni con i clienti (CRM)	L’ID cliente impostato dal titolare del trattamento per il visitatore, oltre all’URL della riproduzione, allegato come nota a un contatto esistente. Se non esiste alcun contatto, non ne viene creato nessuno.	fine della sessione con un ID cliente impostato
Helpdesk e gestione dei ticket	Lo stesso elemento come nota interna sul ticket aperto più recente di cui il mittente è l'autore. Se non esiste alcun ticket aperto, non accade nulla.	fine della sessione con un ID cliente impostato
Marketing via e-mail e lungo il ciclo di vita del cliente	ID cliente, nome dell’evento e URL della riproduzione come evento nell'ambiente del titolare del trattamento.	fine della sessione con un ID cliente impostato
Reti pubblicitarie (Conversions API)	L’ID clic tratto dall'apposito cookie della rete pubblicitaria, nome dell’evento, valore e valuta. Nome, indirizzo e-mail, numero di telefono e indirizzo IP non vengono trasmessi.	un obiettivo raggiunto per il quale è stato prestato il consenso
Archiviazione di oggetti e fogli di calcolo	ID cliente, marca temporale e URL della riproduzione come oggetto o riga nell'archivio del titolare del trattamento stesso.	fine della sessione con un ID cliente impostato
Gestione dei problemi e delle attività	Titolo e descrizione di un elemento contenente l’URL della riproduzione.	un segnale di frustrazione o un errore JavaScript
Gli agenti IA del titolare del trattamento tramite il server MCP	Sola lettura: progetti, indicatori, elenchi di sessioni con link alla riproduzione, singole sessioni con visualizzazioni di pagina ed eventi, pagine, segnali di frustrazione e obiettivi — non l’istantanea della pagina. L’autenticazione utilizza una chiave di lettura dell’API REST del titolare del trattamento.	una richiesta dell’agente, soltanto quando l’accesso è abilitato per il progetto (projects.mcp_active) e su un livello a pagamento

Trasferimento verso paesi terzi: indeterminato. Il titolare del trattamento sceglie la destinazione e il fornitore; le garanzie ai sensi del capo V GDPR spettano quindi a lui. In nessun caso vengono trasmessi il contenuto registrato della pagina, il tracciato del mouse o il testo dei moduli — i connettori trasportano identificativi e nomi di eventi, non la riproduzione.

5. Parte B — Art. 30(1): attività svolte in qualità di titolare del trattamento

Titolare del trattamento per tutto quanto rientra in questa parte: LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82 lok. 301, 90-437 Lodz, Polonia, office@mouseplayer.com. Nessun rappresentante richiesto (stabilito nell’Unione). Nessun responsabile della protezione dei dati designato — sezione 9. Misure tecniche e organizzative: sezione 8.

B.1 Account dei clienti, aree di lavoro e fatturazione

Campo	Contenuto
Finalità	Gestire gli account dei clienti di MousePlayer, l’appartenenza alle aree di lavoro e la fatturazione.
Categorie di interessati	Utenti dei clienti. Misurati: 4 account; workspace_users 4 owner, 1 admin, 1 viewer.
Categorie di dati personali	E-mail, e-mail normalizzata, nome e cognome, tipo di attività, tipo di account (impresa o consumatore, customer_type), lingua, tema. Dati aziendali: denominazione e indirizzo dell’impresa, paese e numero di identificazione IVA insieme a risultato, momento e fonte della verifica e a denominazione e indirizzo secondo VIES. Logo aziendale (nome del file e momento; il file stesso al di fuori della directory web). Hash della password, token di verifica e reimpostazione, scadenza della reimpostazione. Accesso a due fattori (TOTP, migrazione 132): segreto in forma cifrata, ultimo intervallo temporale utilizzato, momento della configurazione e codici di recupero sottoposti a hash. Interruttore per la notifica di accesso (login_alert, B.7). Identificativo del dispositivo (device_id), indicatore di sospetto is_suspicious. Ultimo indirizzo IP COMPLETO, paese, città, numero ASN e organizzazione ASN. Dati di fatturazione: livello, valuta, ID cliente Stripe, abbonamento Stripe, periodo di fatturazione, stato, disdetta alla fine del periodo. Momento di un avviso di inattività. Cronologia IP per utente.
Dove sono conservati	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 righe, di cui 0 troncate. workspace_users (workspace_id, user_id, role); workspace_invites (token, workspace_id, email, role, invited_by, created_at). Inoltre indicati in users da questa versione: 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. Numero di righe in questa voce: al 10/08/2026.
Base giuridica	Non documentata nel codice. Art. 6(1)(b) per l’esecuzione del contratto (account, area di lavoro, fatturazione) e art. 6(1)(c) per la conservazione delle fatture prescritta dalla legge (decisione del titolare del trattamento, 17/08/2026). Il periodo è indicato nella riga relativa alla conservazione.
Categorie di destinatari	Stripe (fatturazione, si veda la sezione 4). VIES della Commissione europea (verifica del numero IVA, sezione 4). Namecheap Private Email come servizio di invio delle e-mail al titolare dell’account: conferma dell’account, reimpostazione della password, inviti, notifica di accesso, avviso prima dell’eliminazione per inattività, comunicazione di modifiche ai documenti contrattuali, report settimanale, risposte dell’assistenza (sezione 4). I membri della stessa area di lavoro vedono nome, indirizzo e-mail e ruolo degli altri membri, nonché il tipo di account dell’area di lavoro, ossia quello del suo proprietario (Termini di servizio, clausola 6.6), e il logo aziendale del proprietario; una persona invitata vede questo logo tramite il link di invito finché l’invito è aperto.
Trasferimento verso paesi terzi	Stripe (USA) e Namecheap (USA); parti contrattuali e garanzie nella sezione 4. VIES si trova nell’Unione.
Conservazione	Integralmente alla cessazione dell’account — e questo cessa anche senza intervento del proprietario. Se il proprietario avvia l’eliminazione nelle impostazioni dell’account, mp_konto_loeschung_ausfuehren() (cfg/lib.php) rimuove, tra gli altri, user_ip_history, live_tokens, login_sessions, remember_tokens, report_subscriptions, i contatori della quota di registrazione, api_keys, workspace_invites, workspace_users, workspaces e users; audit_logs, bot_review_labels e le voci in mp_loesch_archiv vengono depersonalizzati. Dal 07/10/2026 (migrazione 189) questo percorso prima archivia: l’account viene sospeso, gli accessi vengono revocati, le aree di lavoro e i progetti propri vengono nascosti e non vengono più registrati; ciò che può essere ripristinato è conservato in mp_loesch_archiv. Dopo 30 giorni – o immediatamente se il proprietario lo sceglie – db_worker cancella definitivamente attraverso la catena indicata sopra e poi conta se rimane qualcosa. Un account cancellato definitivamente non lascia né identificativo né nome nell’archivio. Se il proprietario rimane inattivo, l’esecuzione giornaliera invia un avviso dopo 24 mesi senza accesso e lo elimina 30 giorni dopo attraverso la stessa catena. Il tempo decorre dall’ultimo accesso o dall’iscrizione per un account mai utilizzato. L’eliminazione segue soltanto un avviso che sia stato consegnato; se l’invio fallisce, il periodo non inizia mai. Entrambi i valori risiedono in site_settings e sono configurabili nell’area amministrativa. Le fatture e le registrazioni contabili associate vengono conservate per cinque anni, decorrenti dalla fine dell’anno civile in cui è scaduto il termine per il pagamento dell’imposta (dichiarazione del titolare del trattamento, 17/08/2026: "5 lat, licząc od końca roku kalendarzowego, w którym upłynął termin płatności podatku"). I dati delle fatture sono quindi esclusi dall’eliminazione dell’account; gli altri campi dell’account vengono eliminati con esso. Dal 16/10/2026 soltanto gli account del livello gratuito ricevono avvisi e vengono eliminati per inattività: livello proprio free e nessuna appartenenza a un’area di lavoro il cui proprietario abbia un livello a pagamento. Questa eliminazione non archivia prima, ma elimina direttamente attraverso la catena indicata sopra. Il logo aziendale viene eliminato con l’account, come ultimo passaggio dell’eliminazione.
Logo aziendale (dal 07/10/2026)	Il cliente può caricare un logo nelle impostazioni (PNG, JPEG, WebP). Viene conservato non il file fornito, ma un’immagine ridisegnata sul server, al di fuori della directory web (daten/firmenlogos/, migrazione 184). È visibile all’account stesso, al superadmin, ai membri delle aree di lavoro di proprietà dell’account e alle persone invitate tramite il link di invito finché l’invito è aperto; tutte le altre richieste ricevono la stessa risposta prevista per un logo mancante.
Esportazione dell’account (art. 15(3), art. 20 GDPR)	Dopo aver inserito la password, il titolare dell’account può scaricare nelle impostazioni un archivio ZIP contenente i dati del proprio account in formato JSON e il logo aziendale. Le tabelle vengono determinate dallo schema (colonne che fanno riferimento all’account); i segreti come hash della password, token e segreto TOTP vengono esclusi. I tentativi falliti vengono conteggiati nel registro delle modifiche e bloccano l’esportazione dopo cinque tentativi entro 15 minuti. L’archivio viene creato soltanto come file temporaneo per la consegna.
Ulteriori dati dell’account (al 16/10/2026)	legal_acceptances: accettazione dei documenti contrattuali (comprese l’informativa sul recesso e la richiesta di inizio immediato) e comunicazioni di modifica consegnate, ciascuna con account, indirizzo IP completo, identificativo del browser, lingua, somme di controllo delle versioni e origine della voce; l’accettazione più recente (non le comunicazioni) di un account esistente viene conservata per tutta la durata dell’account, affinché si possa dimostrare quale versione abbia accettato un cliente attuale (dal 16/10/2026); le accettazioni precedenti, le comunicazioni e le righe degli account eliminati vengono eliminate 730 giorni dopo la rispettiva accettazione o comunicazione (qualificazione della base giuridica per la conservazione dopo la cessazione dell’account ancora da definire da parte del titolare del trattamento). report_subscriptions: iscrizione al report settimanale con token di disiscrizione e ultimo invio; eliminata con l’account. workspace_transfers: trasferimento di un’area di lavoro a un indirizzo e-mail con token e scadenza; eliminato con l’area di lavoro. mp_dashboards: dashboard proprie di un account per progetto; eliminate con l’account o il progetto. SSO Enterprise (sso_providers, sso_identities, sso_requests, sso_assertions, sso_policies, migrazioni 187 e 188): configurazione cifrata del fornitore di identità scelto dal proprietario dell’area di lavoro, per ogni account soltanto un hash dell’identificativo presso il fornitore, richieste di accesso valide per cinque minuti; il server chiama gli endpoint di tale fornitore, il destinatario è il fornitore scelto dal cliente. Al 16/10/2026 nessuna area di lavoro ha un fornitore configurato. Quota di registrazione (mp_aufnahme_monat, mp_aufnahme_sitzung, migrazione 178): contatori per proprietario e mese, per ogni sessione soltanto un hash del progetto e dell’identificativo della sessione; un’esecuzione giornaliera elimina gli hash dei mesi trascorsi, i contatori vengono eliminati con l’account.

B.2 Accesso al portale, sicurezza e registri di audit

Campo	Contenuto
Finalità	Registrazione degli accessi, della sicurezza e delle modifiche per il portale di MousePlayer.
Categorie di interessati	Visitatori e utenti di mouseplayer.com e www.mouseplayer.com.
Categorie di dati personali	Indirizzo IP COMPLETO, user agent, percorso completo della richiesta, paese, città, tipo di dispositivo, sistema operativo, browser, ASN. Eventi di sicurezza con IP parzialmente troncati: WSS_CONNECT 1261, url_excluded 71, consent_blocked 24. Registro delle modifiche: utente, area di lavoro, azione, bersaglio, dettagli in JSON, IP.
Dove sono conservati	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) — al 10/08/2026 36409 righe, 8,5 MB, senza valori IP troncati. Dal 17/08/2026 log_mouseplayer_traffic() (cfg/lib.php) inserisce soltanto una riga grezza per richiesta nella coda Redis queue:traffic_logs; la risoluzione GeoIP e ASN, la classificazione del browser e del dispositivo e la scrittura — compresi users.last_ip e i campi di posizione dell’account — vengono eseguite dal db_worker. L’indirizzo viene determinato da getBestClientIP(); gli header vengono considerati attendibili soltanto quando la connessione proviene da nginx a monte. security_access_logs (id, ip_address, user_agent, event_type, details, created_at) — al 10/08/2026 1354 righe, di cui 350 troncate. audit_logs (log_id, user_id, workspace_id, action, target_id, details, ip_address, created_at) — al 10/08/2026 666 righe, non troncate. banned_ips (ip_address, scope, reason, banned_at, expires_at).
Base giuridica	Non documentata nel codice. L’unica motivazione registrata è il commento in class/Server.class.php:421-425, che distingue la Regola A (indirizzo completo, per accessi DIRETTI alla nostra applicazione) dalla Regola B (troncato, per i dati dei visitatori). Questo spiega la decisione progettuale, ma non costituisce una base giuridica. Art. 6(1)(f). Finalità: difesa dagli abusi e responsabilizzazione (confermate dal titolare del trattamento, 17/08/2026). Bilanciamento: senza registri non è possibile né rilevare un attacco né accertare successivamente chi abbia apportato una modifica. Non esiste un mezzo meno invasivo che ottenga lo stesso risultato — un registro anonimizzato perde proprio l’attribuzione in questione. L’ingerenza è limitata dai periodi (72 ore per il registro di sicurezza, 60 giorni per il registro degli accessi, 60 giorni per il registro delle modifiche) e dal fatto che i registri riguardano soltanto gli accessi all’applicazione stessa, non i visitatori registrati. Gli interessati sono utenti del Cliente che utilizzano deliberatamente il servizio e si aspettano che le proprie azioni amministrative vengano registrate.
Categorie di destinatari	MousePlayer stesso. audit_logs è inoltre visibile al superadmin (www/admin.php).
Trasferimento verso paesi terzi	Nessuno.
Conservazione	mouseplayer_logs: 60 giorni. security_access_logs: 72 ore. banned_ips: alla scadenza di expires_at; le voci impostate manualmente senza scadenza rimangono finché il gestore non le revoca. audit_logs: 60 giorni, nuovo dal 17/08/2026. user_ip_history: 90 giorni dall’ultima volta che un indirizzo è stato osservato, nuovo dal 24/09/2026; al più tardi con l’account. Tutti i valori risiedono in site_settings e sono configurabili nell’area amministrativa. Che il registro delle modifiche sopravviva a quello di sicurezza è deliberato: il registro degli accessi risponde a chi fosse presente, quello delle modifiche a chi abbia cambiato qualcosa. Quest’ultimo è il registro della responsabilizzazione ai sensi dell’art. 5(2) e deve sopravvivere a una controversia che emerga soltanto mesi dopo.

B.3 Richieste di assistenza

Campo	Contenuto
Finalità	Ricevere e gestire richieste di assistenza. Dal 30/09/2026 questo comprende la traduzione di un messaggio e la preparazione di una bozza di risposta da parte di un modello linguistico sul nostro hardware; una persona esamina ogni bozza e la invia.
Categorie di interessati	Persone che presentano una richiesta, autenticate o meno.
Categorie di dati personali	Indirizzo e-mail, oggetto, testo libero del messaggio. Indirizzo IP COMPLETO — REMOTE_ADDR, sovrascritto con HTTP_X_FORWARDED_FOR, senza troncamento. User agent, URL di origine. Il campo per il codice paese viene letto dall’header HTTP_CF_IPCOUNTRY; poiché non è presente Cloudflare a monte, contiene sempre il valore di ripiego XX o nulla.
Dove sono conservati	support_requests (id, user_id, channelid, email, reason, message, status, ip_address, user_agent, source_url, country_code, created_at). Dal 30/09/2026 anche mp_support_ki: una riga per operazione (traduzione, bozza, traduzione della nostra bozza) con il testo preparato per il modello, il risultato, il nome del modello e la durata; collegata alla richiesta tramite una chiave esterna.
Base giuridica	Art. 6(1)(b) quando chi presenta la richiesta è un cliente e la richiesta riguarda l’esecuzione del contratto; altrimenti art. 6(1)(f). L’indirizzo IP completo si basa sullo stesso fondamento: serve a difendere il canale di assistenza dagli abusi. Invii massivi o ripetuti, minacce e altri pregiudizi non possono essere né rilevati né impediti senza di esso, e un indirizzo troncato non consente tale distinzione. Decisione del titolare del trattamento, 17/08/2026.
Categorie di destinatari	Fino all’11/08/2026: Telegram. cfg/lib.php inviava stato dell’utente, indirizzo e-mail, oggetto, indirizzo IP NON TRONCATO con paese, URL di origine e testo completo del messaggio ad api.telegram.org. Dall’11/08/2026: nessuno. Ad api.telegram.org arriva soltanto la stringa fissa 'MousePlayer: es liegt eine neue Supportanfrage vor.', senza alcuna variabile; Telegram quindi non riceve dati personali e non è un destinatario. La richiesta stessa rimane invariata in support_requests. Modello linguistico (dal 30/09/2026): nessuno. Viene eseguito sulle nostre macchine con scheda grafica, nella stessa rete locale e nello stesso sito del server; recuperano l’operazione tramite HTTPS, ogni richiesta firmata con un proprio segreto. Ricevono testo del messaggio, oggetto, indicazione se il richiedente abbia un account e percorso della pagina di origine – indirizzi e-mail e sequenze numeriche di sei o più cifre vengono sostituiti preventivamente (mp_supki_saeubern() in cfg/support_ki_lib.php), nella nostra bozza soltanto gli indirizzi e-mail. Non l’indirizzo IP, non l’indirizzo e-mail del richiedente. Nessun servizio di IA esterno, nemmeno come ripiego.
Trasferimento verso paesi terzi	Fino all’11/08/2026: Telegram, al di fuori dell’UE; non è disponibile alcun accordo sul trattamento dei dati per i bot — si veda la sezione 4. Dall’11/08/2026: nessuno. La notifica ad api.telegram.org non contiene più dati personali, quindi non avviene alcun trasferimento verso un paese terzo. Il canale continua a esistere come semplice segnale — si veda la sezione 4.
Decisione automatizzata	Nessuna. Il modello propone soltanto testi; nulla viene inviato automaticamente – una persona legge la bozza, la modifica ove necessario e la invia. Non si tratta di una decisione ai sensi dell’art. 22 GDPR.
Conservazione	730 giorni, applicati dall’esecuzione giornaliera in srv/db_worker.php; il valore risiede in site_settings sotto retention_evidence_days ed è configurabile nell’area amministrativa. All’eliminazione dell’account la richiesta rimane, ma perde il collegamento all’account (user_id diventa NULL); l’informativa sulla privacy lo dichiara espressamente. Le righe in mp_support_ki vengono eliminate con la rispettiva richiesta (ON DELETE CASCADE, migrazione 168), attraverso ogni percorso di eliminazione.

B.4 Accettazione da parte del cliente delle regole regionali di registrazione

Campo	Contenuto
Finalità	Documentare l’accettazione da parte del cliente delle regole regionali di registrazione — una dichiarazione contrattuale.
Categorie di interessati	Utenti dei clienti.
Categorie di dati personali	ID utente, e-mail, regioni, versione del testo, somma di controllo del testo, lingua. Indirizzo IP COMPLETO e user agent — deliberatamente, e il motivo è registrato in ai/migrations/018_consent.sql: si tratta dell’accettazione di un contratto da parte di una controparte commerciale, non di dati dei visitatori.
Dove sono conservati	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 righe.
Base giuridica	Prova di una dichiarazione contrattuale, secondo la motivazione nell’intestazione della migrazione.
Categorie di destinatari	MousePlayer stesso.
Trasferimento verso paesi terzi	Nessuno.
Conservazione	730 giorni dall’accettazione — lo stesso periodo degli altri documenti di consenso ai termini (support_requests, legal_acceptances; per legal_acceptances l’accettazione più recente di un account esistente viene conservata oltre tale periodo, si veda B.1), perché rispondono alla stessa domanda: chi ha accettato cosa e quando. Il valore risiede in site_settings sotto retention_evidence_days; applicato dall’esecuzione giornaliera in srv/db_worker.php.

B.5 Visitatori del nostro sito web

Campo	Contenuto
Finalità	Gestione di mouseplayer.com stesso: finestra di consenso, difesa dagli accessi automatizzati, dimostrazione sulla pagina iniziale e registri del server web.
Categorie di interessati	Visitatori di mouseplayer.com.
Categorie di dati personali	Indirizzo IP — non troncato nei registri del server —, momento, indirizzo richiesto, codice di stato, identificativo del browser. Per la dimostrazione, inoltre, posizioni del puntatore e dei clic, identificativo di sessione assegnato casualmente e paese derivato dall’indirizzo. Per reCAPTCHA, l’indirizzo oltre a caratteristiche del dispositivo e del comportamento.
Dove sono conservati	Registri degli accessi di nginx (/var/log/nginx/) e Apache, entrambi con l’indirizzo completo, logrotate giornaliero con 14 rotazioni. Dal 16/08/2026 nginx è il primo livello che vede l’indirizzo di un visitatore; Apache si trova dietro di esso sul loopback e lo riceve tramite il protocollo PROXY o X-Forwarded-For. I dati della dimostrazione non vengono conservati, ma soltanto inoltrati sul momento.
Base giuridica	Dimostrazione: consenso, art. 6(1)(a) — la relativa barriera è presente dal 17/08/2026. reCAPTCHA e registri del server: legittimo interesse, art. 6(1)(f). Art. 6(1)(f). Finalità: difesa dagli abusi e responsabilizzazione (confermate dal titolare del trattamento, 17/08/2026). reCAPTCHA: senza protezione dagli accessi automatizzati, le pagine di accesso, registrazione, modulo di assistenza e fatturazione sono esposte agli attacchi. Il mezzo meno invasivo — un semplice limite alla frequenza delle richieste — è inoltre presente dal 17/08/2026, ma non sostituisce completamente l’attribuzione del punteggio. Registri del server: l’indirizzo non troncato è necessario per attribuire accessi ripetuti o massivi allo stesso mittente; un indirizzo troncato non consente tale distinzione. L’ingerenza è limitata dal periodo di 14 giorni e dal fatto che i registri non vengono combinati con altri dati.
Categorie di destinatari	Google Ireland Limited (reCAPTCHA) e consented.eu (finestra di consenso). Per la dimostrazione, inoltre, gli altri visitatori che hanno aperta la pagina iniziale nello stesso momento — vedono il puntatore e il paese, non l’indirizzo.
Trasferimento verso paesi terzi	Stati Uniti tramite reCAPTCHA; per la base e la data di accettazione si veda la sezione 4.
Conservazione	Registri del server 14 giorni. La dimostrazione non conserva nulla.

Questa voce mancava fino al 17/08/2026, sebbene la sezione 4 indicasse già la finestra di consenso e reCAPTCHA come destinatari — il trattamento corrispondente non compariva da nessuna parte. L’informativa pubblica sulla privacy è stata ampliata lo stesso giorno per coprire lo stesso argomento (sezione 10); i due testi devono essere letti l’uno in relazione all’altro.

B.6 Accessi a un link di condivisione

Campo	Contenuto
Finalità	Prova di quante volte e da dove è stato utilizzato un link di condivisione. Tale link apre una registrazione completa senza autenticazione; senza questo registro non è possibile accertare successivamente quante volte sia stato utilizzato o se abbia oltrepassato la cerchia prevista.
Categorie di interessati	Persone che aprono un link di condivisione — solitamente il personale del Cliente o destinatari da questi scelti. Non i visitatori registrati; si tratta di persone diverse.
Categorie di dati personali	Indirizzo IP della persona che accede (non troncato), identificativo del browser, momento, identificativo del link.
Dove sono conservati	share_views (migrazione 043), collegato a session_shares tramite una chiave esterna con ON DELETE CASCADE.
Base giuridica	Art. 6(1)(f). Finalità: difesa dagli abusi — un link senza autenticazione è esattamente il tipo di indirizzo che viene inoltrato. Bilanciamento: non esiste un mezzo meno invasivo: un indirizzo troncato non consente di stabilire se due accessi provengano dallo stesso luogo e, senza di esso, l’inoltro non è né rilevabile né dimostrabile. L’ingerenza è strettamente limitata — non riguarda la persona registrata ma chi accede, e la riga viene eliminata con il link. Gli interessati sono persone che aprono un link alla registrazione di qualcun altro, che devono aspettarsi che tale accesso venga registrato. (decisione del titolare del trattamento, 17/08/2026)
Categorie di destinatari	Nessuno. Il registro non lascia il nostro database.
Trasferimento verso paesi terzi	Nessuno.
Conservazione	Con il link. Quando scade o viene revocato, il registro viene eliminato con esso tramite la chiave esterna. Un link dura al massimo 90 giorni, 7 per impostazione predefinita — l’applicazione non può crearne uno di durata superiore.

Il fatto che la riga venga eliminata con il link non è qui una comodità, ma metà della base giuridica: un registro che sopravvive al link non ha più una finalità che lo giustifichi.

B.7 Accessi attivi e loro revoca

Campo	Contenuto
Finalità	Mostrare al titolare dell’account dove il proprio account è connesso e consentirgli di terminare l’accesso di un singolo dispositivo o di tutti gli altri. Senza questo elenco un accesso compromesso non può essere né individuato né terminato: fino al 28/08/2026 una modifica della password invalidava soltanto i cookie “resta connesso”, mentre le sessioni in corso continuavano a esistere come file — misurato tra 24 e 54 minuti.
Categorie di interessati	Titolari e membri di un account cliente. Non i visitatori registrati; si tratta di due persone diverse.
Categorie di dati personali	Indirizzo IP (non abbreviato), user agent e, da esso derivati, browser, sistema operativo e tipo di dispositivo, posizione approssimativa (città e paese) dall’indirizzo, momento dell’accesso e dell’ultima attività. L’identificativo della sessione stesso non viene conservato, soltanto il suo hash SHA-256. Accanto a esso un’impronta del dispositivo — un hash di browser, sistema operativo, tipo di dispositivo e intervallo di indirizzi (/24 o /48, mai l’indirizzo completo), mediante il quale viene riconosciuto un dispositivo già noto.
Dove sono conservati	login_sessions (migrazione 094), collegato tramite remember_selector a remember_tokens (migrazione 037).
Base giuridica	Art. 6(1)(b) in combinato disposto con l’art. 32. Finalità: sicurezza dell’account — questo trattamento è la misura tecnica, non un suo sottoprodotto. Bilanciamento: non esiste un mezzo meno invasivo. Un indirizzo abbreviato non consente di rispondere proprio alla domanda per cui esiste l’elenco (“ero io?”) e, senza browser e posizione, una riga non può essere distinta dall’altra. I dati si producono comunque a ogni accesso; la novità è soltanto che diventano visibili e revocabili. Sono visibili soltanto al titolare dell’account.
Categorie di destinatari	Nessuno. L’elenco non lascia il nostro database.
Trasferimento verso paesi terzi	Nessuno.
Conservazione	90 giorni dall’ultima attività, e integralmente alla cessazione dell’account. Il riferimento è l’ultima attività anziché la creazione: un dispositivo connesso da mesi ma utilizzato ieri costituisce un accesso attuale e appartiene all’elenco.

Dal 28/08/2026 gli stessi dati producono inoltre una notifica al titolare dell’account quando il suo account viene aperto da un dispositivo mai comparso prima. Viene inviata all’indirizzo registrato dell’interessato stesso e a nessun altro; non aggiunge alcun destinatario ai sensi dell’art. 4(9). Ogni account può disattivarla nelle impostazioni senza perdere l’elenco stesso — l’impostazione predefinita è attiva, perché una notifica di sicurezza che deve prima essere abilitata non raggiunge proprio chi ne ha bisogno. L’impronta si basa deliberatamente sull’intervallo di indirizzi anziché sull’indirizzo completo: un’utenza domestica riceve un IP diverso alla riconnessione notturna e, con l’indirizzo completo, arriverebbe una notifica ogni mattina — il segnale sarebbe inutile e con esso la notifica.

Due decisioni richiedono qui una spiegazione. Viene conservato l’hash dell’identificativo della sessione e mai l’identificativo stesso: altrimenti un dump del database fornirebbe cookie di sessione validi e un dump nelle mani sbagliate è esattamente il caso contro cui è costruita questa tabella. E una riga revocata non viene eliminata, ma contrassegnata come revocata — una riga eliminata sarebbe una sessione sconosciuta per il controllo eseguito a ogni richiesta, e una sconosciuta può essere riscritta. La revoca si annullerebbe da sola.

B.8 Avvisi operativi ed e-mail trattenute (urgent_logs)

Campo	Contenuto
Finalità	Avvisi operativi per il superadmin: guasti rilevati dai watchdog in srv/cron_status.php, casi dubbi dal riesame dei bot (A.19), a scelta del superadmin anomalie di un progetto anziché un’e-mail, ed e-mail in uscita trattenute da un elenco di blocco. Il blocco impedisce l’invio di e-mail agli indirizzi propri elencati o a domini riservati per test ed esempi; l’e-mail trattenuta viene conservata qui affinché rimanga tracciabile ciò che sarebbe stato inviato.
Categorie di interessati	Utenti dei clienti e altri destinatari di un’e-mail trattenuta; indirettamente visitatori il cui ID di sessione compare in un avviso di riesame dei bot.
Categorie di dati personali	Fonte, oggetto, testo dell’avviso, momenti di creazione, ultima ripetizione, risoluzione e invio dell’e-mail. Per un’e-mail trattenuta, indirizzo del destinatario e testo completo dell’e-mail in chiaro — a seconda del tipo, ad esempio nome e indirizzo e-mail e, per una notifica di accesso, anche indirizzo IP, dispositivo e posizione approssimativa.
Dove sono conservati	urgent_logs (id, quelle, betreff, meldung, erstellt_am, zuletzt_am, erledigt_am, mail_status, mail_am, stoerung_beendet_am).
Base giuridica	Art. 6(1)(f). Finalità: sicurezza operativa e tracciabilità dell’invio di e-mail. Gli avvisi sono accessibili soltanto al superadmin e vengono eliminati entro un periodo stabilito dopo la risoluzione.
Categorie di destinatari	Il superadmin. Gli avvisi di guasto vengono inoltre inviati via e-mail all’indirizzo di allarme del gestore (tramite Namecheap Private Email, sezione 4); un’e-mail trattenuta non viene inviata a nessuno.
Trasferimento verso paesi terzi	Nessuno; per l’invio all’indirizzo di allarme si veda Namecheap nella sezione 4.
Conservazione	Una riga rimane finché non viene risolta — dal watchdog una volta cessato il guasto oppure manualmente; un’e-mail trattenuta non viene mai risolta automaticamente. Il watchdog di stato elimina le righe risolte 180 giorni dopo la risoluzione (site_settings.retention_urgent_days, configurabile nell’area amministrativa, almeno 7 giorni).

6. Conservazione — cosa copre l’eliminazione giornaliera e cosa non copre

Esiste un’eliminazione automatica e dal 17/08/2026 copre tutte le tabelle contenenti dati personali, tramite un periodo proprio oppure attraverso la catena di eliminazione della sessione. Il suo nucleo si trova in srv/db_worker.php nel blocco contrassegnato DAILY DATA PRUNING e viene eseguito all’interno del processo worker permanentemente attivo una volta per giorno civile (controllato da $lastPurgeDate). I periodi per le sessioni bot (ogni ora), l’eliminazione definitiva delle voci archiviate (ogni 30 secondi) e le richieste di cancellazione dall’accesso autonomo hanno cicli propri nello stesso processo. Dal 07/10/2026 le attività programmate vengono eseguite da /etc/cron.d/mouseplayer tramite srv/cron_run.sh con un blocco per attività, tra cui il trasferimento degli eventi nell’archivio (ogni ora) e la manutenzione dell’indice testuale (ogni dieci minuti); l’aggregato giornaliero della mappa dei clic viene creato ogni notte.

Prova del funzionamento (al 16/10/2026): il registro del worker documenta l’esecuzione giornaliera ogni giorno, da ultimo il 16/10/2026 alle 00:00:11, completata dieci secondi dopo, e il periodo orario per le sessioni bot con sessioni e righe eliminate (ad esempio alle 10:00:18 dello stesso giorno 478 sessioni con 3294 righe). Fino a quel giorno il periodo del livello non aveva nulla da eliminare: i progetti con sessioni più vecchie hanno il livello enterprise (365 giorni) e le sessioni più vecchie del livello gratuito sono più recenti del relativo periodo. L’eventuale fallimento o mancata esecuzione di un’attività programmata viene controllato dal watchdog cron in srv/cron_status.php, che lo segnala negli Urgent Logs (B.8) e via e-mail.

6.1 Coperto dall’eliminazione giornaliera

Tabella	Condizione di attivazione e periodo	Prova
mouseplayer_logs	Più vecchi di 60 giorni (site_settings.log_retention_days)	srv/db_worker.php, DAILY DATA PRUNING
security_access_logs	Più vecchi di 72 ore (site_settings.security_log_retention_hours)	srv/db_worker.php, DAILY DATA PRUNING
banned_ips	expires_at è nel passato; le voci senza expires_at rimangono finché il gestore non le revoca	srv/db_worker.php, DAILY DATA PRUNING
visitor_sessions e tutto ciò che vi è collegato (mouse_events, session_pageviews, session_custom_events con parametri e le altre tabelle della catena di eliminazione)	Per sessione, una volta scaduto il periodo del livello: free 7 giorni, small 30, business 90, enterprise IFNULL(enterprise_custom_tiers.retention_days, 365). Caso speciale free + is_suspicious = 24 ore. Periodo di tolleranza dopo un passaggio a un livello inferiore tramite GREATEST(...) con users.retention_grace_until e retention_grace_days. Eliminazione tramite mp_sitzungen_loeschen().	srv/db_worker.php, DAILY DATA PRUNING
payload_blob e mouse_events delle sessioni bot	La registrazione di una sessione riconosciuta come bot viene rimossa una volta trascorso il periodo (site_settings.retention_bot_recording_days, periodo in giorni: 1; 0 lo disattiva)	srv/db_worker.php, ogni ora
visitor_sessions delle sessioni bot con tutto ciò che vi è collegato	14 giorni dall’inizio della sessione (site_settings.retention_bot_session_days, almeno 8; 0 = nessun periodo separato)	srv/db_worker.php, ogni ora, mp_sitzungen_loeschen()
mouse_events → file di archivio	trasferiti in file di archivio compressi per sessione dopo 7 giorni; i file vengono eliminati con la relativa sessione	srv/cron_archiv.php (ogni ora), mp_sitzungen_loeschen()

6.2 Ulteriori elementi coperti dal 17/08/2026

Questa sezione elencava in precedenza tredici tabelle senza alcun periodo. La questione è risolta. Cinque tabelle fanno parte della catena di eliminazione condivisa mp_sitzungen_loeschen() dal 12/08/2026, ad altre sei è stato assegnato un periodo proprio il 17/08/2026 e due non erano affatto nell’elenco: l’attribuzione di punteggi per visitatore e giorno e i testi generati da essa.

I valori della tabella seguente non sono trascrizioni. Vengono letti da site_settings quando questa pagina viene servita — dalla stessa riga letta dall’eliminazione automatica — e sono configurabili nell’area amministrativa. Un numero trascritto costituirebbe un secondo punto per la stessa verità e alla fine i due divergerebbero.

Tabella	Periodo	Meccanismo di applicazione
ai_session_features	con la sessione	mp_sitzungen_loeschen()
ai_timelines	con la sessione	mp_sitzungen_loeschen()
session_comments	con la sessione	mp_sitzungen_loeschen()
session_shares	con la sessione; il link stesso scade dopo al massimo 90 giorni, 7 per impostazione predefinita; la riga di un link scaduto o revocato viene eliminata 90 giorni dopo e gli accessi in share_views vengono eliminati con essa	mp_sitzungen_loeschen(), mp_share_erstellen(), esecuzione giornaliera
visitor_nicknames	con l’ultima sessione del visitatore — dal 28/08/2026 questo comprende anche il nome assegnato dal titolare del trattamento (A.13), che si trova nella stessa riga	mp_sitzungen_loeschen()
ai_visitor_value	60 giorni dal giorno valutato; per Enterprise, il periodo di conservazione del livello. Inoltre con il visitatore non appena non rimane più alcuna sua sessione	esecuzione giornaliera, mp_sitzungen_loeschen()
ai_insights (scope “visitor”)	analogamente	esecuzione giornaliera, mp_sitzungen_loeschen()
consent_events	730 giorni da the withdrawal — mai finché una sessione vi fa ancora riferimento	esecuzione giornaliera
ip_lifetime_stats	365 giorni da first_seen	esecuzione giornaliera
audit_logs	60 giorni	esecuzione giornaliera
support_requests	730 giorni	esecuzione giornaliera
consent_region_acceptances	730 giorni	esecuzione giornaliera
legal_acceptances	730 giorni dall’accettazione o dalla comunicazione; l’accettazione più recente di un account esistente viene conservata per tutta la durata dell’account (dal 16/10/2026)	esecuzione giornaliera
user_ip_history	90 giorni dall’ultima osservazione dell’indirizzo; al più tardi con l’account	esecuzione giornaliera
users (compreso last_ip), workspace_users, workspace_invites	con l’account; in assenza di accessi dopo 24 mesi più un periodo di preavviso di 30 giorni	mp_konto_loeschung_ausfuehren(), esecuzione giornaliera
heatmap_page_stats	non applicabile — la tabella è stata rimossa il 18/08/2026 (migrazione 045)	—
mp_profil_sitzung	180 giorni dall’INIZIO della sessione, almeno la finestra di calcolo; senza alcun periodo non appena la sessione stessa non esiste più	esecuzione giornaliera, mp_sitzungen_loeschen()
mp_profile, mp_sequenzmuster	mp_profile non appena non rimane più alcuna assegnazione che vi faccia riferimento; mp_sequenzmuster dopo 180 giorni senza un ricalcolo e immediatamente quando il suo canale non ha più alcuna sessione	esecuzione giornaliera
ga4_daily, ga4_sessions, ga4_events	180 giorni dal giorno descritto, rispettivamente dall’inizio della sessione GA4 — non dal momento dell’importazione (A.14)	esecuzione giornaliera
mp_hm_tag, mp_hm_tag_stand	nessun periodo proprio: un giorno conservato viene ricalcolato dalle sessioni ancora esistenti al più tardi 7 giorni dopo l’ultimo calcolo, alla successiva apertura dell’elenco; in tale occasione vengono rimossi i giorni precedenti alla sessione più vecchia rimasta del progetto; tutto insieme al progetto (A.8)	all’apertura dell’elenco delle mappe di calore; mp_konto_loeschen()
mp_umfrage_text	con la sessione (A.21) — volutamente nessun periodo proprio	mp_sitzungen_loeschen(), percorso di eliminazione dall’interno del lettore, mp_konto_loeschen()
mp_loesch_archiv, mp_loesch_archiv_sitzung	account, aree di lavoro, progetti archiviati e visitatori o indirizzi IP archiviati (cancellazione GDPR): al massimo 30 giorni, poi cancellati definitivamente. Rimane una registrazione senza nome – per visitatori e indirizzi IP un HMAC dell’identificativo, affinché la cancellazione possa essere ripetuta dopo il ripristino di un backup, per gli account nessun identificativo – che viene rimossa dopo 730 giorni	db_worker, ogni 30 secondi
mp_hm_klick_tag, mp_hm_ansicht_tag	730 giorni dal giorno descritto dalla riga; immediatamente con il progetto. Nessuna eliminazione per persona: le righe non contengono riferimenti personali (A.1)	srv/hm_aggregat_lauf.php, mp_konto_loeschen()
mouse_events_analytik	con la visualizzazione di pagina – dal 07/10/2026 anche attraverso ogni percorso che elimina singole sessioni; prima soltanto insieme all’intero progetto (A.8)	mp_sitzungen_loeschen(), percorso di eliminazione dall’interno del lettore, mp_konto_loeschen()
login_sessions	90 giorni dall’ultima attività; integralmente con l’account (B.7)	esecuzione giornaliera, eliminazione dell’account
share_views	con il link di condivisione, tramite la chiave esterna con ON DELETE CASCADE (B.6)	chiave esterna
ai_churn	riscritta per progetto a ogni esecuzione; eliminata con le sessioni da cui deriva la riga (A.16)	srv/ai_worker.php
ai_besucher_bericht	180 giorni dalla richiesta; prima con l’ultima sessione del visitatore (A.17)	esecuzione successiva in srv/ai_worker.php
mp_cwv, mp_element_klicks, mp_element_offen	con la sessione o la visualizzazione di pagina; le righe la cui visualizzazione di pagina manca vengono rimosse ogni ora (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 giorni dall’inizio della visualizzazione di pagina; prima con la sessione (A.22)	srv/textsuche_lauf.php, mp_sitzungen_loeschen()
bot_review_labels	impostazione predefinita: nessuna eliminazione automatica; configurabile in anni (retention_bot_labels_years) (A.19)	srv/cron_status.php
urgent_logs	180 giorni dopo la risoluzione (site_settings.retention_urgent_days) (B.8)	srv/cron_status.php
mp_aufnahme_quittung	7 giorni (A.1)	srv/db_worker.php
mp_native_apps, mp_native_sessions	fino alla scadenza del periodo impostato per sessione o fino alla revoca; l’anteprima è disattivata ed esiste soltanto sull’istanza di sviluppo (A.1)	cfg/native_store.php

Due punti misurati anziché presunti. Primo, l’esecuzione giornaliera avviene davvero. Questo documento affermava in passato che non fosse mai avvenuta; l’esecuzione del 17/08/2026 alle 17:37:09 è documentata nel registro del worker. Quel giorno non ha eliminato nulla perché entrambi i progetti contenenti sessioni hanno il livello Enterprise e la sessione più vecchia aveva 27 giorni — è lo stato previsto, non un guasto. Secondo, il periodo per i punteggi derivati decorre dal giorno descritto dalla riga, non dal momento in cui sono stati calcolati. Alla misurazione, 167 righe contenevano 28 giorni descritti distinti ma soltanto 6 momenti di calcolo distinti, il più recente pochi minuti prima: il precalcolo ricalcola e ogni ricalcolo avrebbe azzerato un periodo basato su di esso. Non sarebbe mai scaduto e nessuno se ne sarebbe accorto.

6.3 Constatazioni sulla catena di eliminazione (al 16/10/2026)

• LA CATENA VIENE ESEGUITA IN ESERCIZIO. Il 10/08/2026 non era mai stata eseguita, per questo era descritta qui come non verificata. Dal 17/09/2026 il periodo per le sessioni bot elimina ogni ora attraverso la stessa catena di eliminazione mp_sitzungen_loeschen() utilizzata anche dal periodo del livello e dalle richieste di cancellazione; il 16/10/2026, ad esempio, 401 e 478 sessioni per esecuzione. Il periodo del livello stesso non aveva nulla da eliminare fino a quel giorno (sezione 6).
• PROGETTI ELIMINATI. La selezione del periodo del livello continua a collegare visitor_sessions mediante INNER JOIN con progetto, area di lavoro e proprietario e non vede le sessioni senza progetto. Nel processo regolare, tuttavia, una sessione del genere non si produce più: dal 07/10/2026 un progetto viene prima archiviato e, all’eliminazione definitiva, rimosso con tutte le sue sessioni tramite l’eliminazione del canale (mp_kanaele_loeschen()). Al 16/10/2026 non esiste alcuna sessione senza progetto.
• ORFANI. Tutto ciò che deriva da una sessione fa parte della catena di eliminazione o ha un periodo proprio (sezione 6.2). Le visualizzazioni di pagina la cui sessione manca — ad esempio dopo un’interruzione a metà di un’eliminazione — vengono conteggiate una volta al giorno dal watchdog di stato e rimosse automaticamente con i relativi eventi una volta trascorsi più di dieci minuti.
• L’ELIMINAZIONE AUTOMATICA DIPENDE DAL FUNZIONAMENTO DEL WORKER. Un worker fermo arresta anche l’eliminazione. Dal 19/08/2026 i watchdog segnalano i guasti via e-mail, dal 23/09/2026 questa posta viene effettivamente inviata tramite SMTP e dal 02/10/2026 una nostra macchina separata nella stessa rete locale verifica ogni minuto dall’esterno se database, Redis, server WebSocket, processi permanenti e coda siano in ordine. Resta da osservare che ActiveState=active non prova che il worker sia vivo; l’elenco dei processi è affidabile.

Percorsi di eliminazione manuale, per completezza: il lettore (delete_session e delete_visitor, limitati al channelid, ruoli owner e admin) e mp_sitzungen_loeschen() in srv/db_worker.php. Una revoca elimina soltanto se projects.consent_delete_on_withdraw è impostato; al 16/10/2026 il valore non è impostato per nessun progetto. Non esiste ON DELETE CASCADE da visitor_sessions verso il basso: la catena viene eseguita manualmente attraverso tutte le tabelle dipendenti e l’ostacolo è mouse_events, perché gli eventi dipendono da pageview_id anziché da session_id; dal 07/10/2026 comprende anche la copia dei clic mouse_events_analytik.

Al di fuori del database: i registri degli accessi di nginx e Apache contengono indirizzi IP completi e vengono conservati per 14 rotazioni giornaliere (logrotate). Redis dell’istanza di sviluppo ascolta soltanto su 127.0.0.1 (porta 6381), ha accesso limitato e scrive i dati su disco per la persistenza (AOF e istantanee RDB); le code contengono l’IP troncato, l’URL completo e il payload DOM finché il worker non li preleva, e mp_autoban: contiene l’indirizzo completo di un mittente bloccato per la durata del blocco (24 h). I file di archivio degli eventi trasferiti fuori dal sistema si trovano sotto /mnt/mouseplayer-dev-archive sullo stesso disco del sistema e sono inclusi nel backup dal 06/10/2026.

7. Decisioni automatizzate, profilazione e attribuzione di punteggi

Vengono effettuate attribuzioni di punteggi e classificazioni. Non è stata riscontrata alcuna decisione che produca effetti giuridici su un VISITATORE o incida su di lui in modo analogamente significativo — nessuna decisione su credito, prezzi o accesso e nessuna comunicazione delle valutazioni a soggetti diversi dal cliente. Sulla base delle evidenze, l’art. 22 non si applica ai visitatori. Esistono tre conseguenze automatizzate e due di esse meritano un esame più attento di quanto normalmente offra un registro. La terza è stata aggiunta il 02/09/2026 ed è l’unica che produce effetti sul VISITATORE: la previsione di uscita (A.15) o l’indicatore di abbandono (A.16) può portare a una sovrimpressione sul sito web del titolare del trattamento. Compare soltanto se questi la attiva, il contenuto è il suo e può essere chiusa. Non ne deriva alcun effetto giuridico o impatto analogamente significativo ai sensi dell’art. 22(1) GDPR — è un invito, non una decisione su prezzo, accesso o merito creditizio. Deve comunque figurare nel registro, perché qui una valutazione lascia per la prima volta il pannello del cliente.

Meccanismo	Cosa fa	Dove
Punteggio di coinvolgimento	Un piccolo intero composto da punti per profondità (durata, numero di pagine, profondità di scorrimento) e comportamenti insoliti (clic di rabbia e a vuoto, ritorni indietro, schede parallele). Bot e sessioni banali ricevono 0. Conservato in ai_session_features.engagement_score (TINYINT UNSIGNED), indice idx_engagement. Effetto: ordinamento dell’elenco dei suggerimenti nel pannello del cliente.	ai/features.py:33-70; cfg/project_ai_overview.php:126-136 e 150; cfg/project_live_users.php:190
Qualità della sessione	Separa le sessioni in cui non è accaduto quasi nulla.	visitor_sessions.session_quality; srv/db_worker.php:706-780 e 1103-1140
Classificazione dei bot	Imposta visitor_sessions.is_bot e bot_reason (varchar 32), indice idx_is_bot. Si noti che il controllo dei bot in mp.js viene eseguito PRIMA della barriera del consenso.	srv/db_worker.php:963-1000
Rilevamento della frustrazione nel browser	Genera rage_click, dead_click e mouse_thrashing. Misurati: dead_click 355, rage_click 52, mouse_thrashing 5. In caso di rage_click lo script trasmette inoltre un indicatore ai widget di chat di terzi presenti nel browser del VISITATORE — Intercom('update', {'mouseplayer_rage_click':'DETECTED_NOW'}) e LiveChatWidget.call('set_session_variables', ...). Si tratta di una comunicazione ulteriore automatizzata di una valutazione comportamentale a un terzo sistema sulla pagina del cliente.	www/mp.js:5786 e 5793-5794
Registro testuale della sessione	Testo generato automaticamente sullo svolgimento della sessione, prodotto da ai/build.py. Dal 12/08/2026 srv/ai_worker.php richiama direttamente il processo di generazione (con directory di lavoro e PYTHONPATH); al 16/10/2026 funziona e la timeline più recente risale allo stesso giorno. I messaggi di errore in ai_build.log provengono dall’invocazione precedente, nel frattempo rimossa, e sono stati scritti per l’ultima volta il 18/08/2026.	ai/build.py; srv/ai_worker.php; ai_timelines
is_suspicious alla registrazione	Impostato automaticamente alla registrazione utilizzando, tra gli altri segnali, device_id e l’e-mail normalizzata. Conseguenza: per il livello gratuito il periodo di conservazione viene ridotto a 24 ore.	www/register.php:159-191; srv/db_worker.php:824
Blocco automatico	Più di 15 connessioni entro 10 secondi, più di 15 connessioni simultanee da un IP, più di 50 messaggi al secondo e messaggi troppo grandi (salvo un’istantanea di pagina di grandi dimensioni) o illeggibili comportano un blocco di 24 h nel server WebSocket (site_settings.autoban_stunden, da 1 a 168), conservato in Redis (mp_autoban:) e registrato senza l’indirizzo completo. Davanti al server web, fail2ban blocca un indirizzo per un’ora se supera il limite di frequenza di nginx più di 100 volte entro un minuto (jail mp-nginx-429). Secondo il codice al 16/10/2026, le voci in banned_ips vengono ora impostate soltanto dal gestore; le precedenti voci automatiche scadevano dopo 7 giorni.	class/Server.class.php (autoBanIp); /etc/fail2ban/jail.d/mp-nginx-429.conf; /etc/nginx/conf.d/mouseplayer.conf
Profili comportamentali — raggruppamento delle visite (A.12)	k-means su sette caratteristiche per sessione assegna ogni visita riproducibile a uno di al massimo otto gruppi e lo denomina dalla posizione relativa del centro del gruppo. Le sessioni banali e quelle riconosciute come bot vengono separate preventivamente mediante una regola e non vengono affatto raggruppate. Effetto: una VISUALIZZAZIONE — una scheda, un pulsante filtro e una coda di riproduzione. Non vi dipende alcuna decisione.	ai/profile.py; cfg/project_profiles.php; mp_profil_sitzung
Punteggio di attrito e anomalie	Per sessione un valore da 0 a 100 derivato da segnali ponderati di frustrazione ed errore, insieme alle motivazioni (dal 26/09/2026); ordina e filtra gli elenchi e, al raggiungimento di una soglia, può attivare un webhook a cui il cliente si è iscritto. Una volta al giorno, il giorno precedente di ciascun progetto viene confrontato con le settimane antecedenti (sessioni, tasso di raggiungimento degli obiettivi, quota con attrito o errori JavaScript, Web Vitals) e viene segnalata un’anomalia — conteggi sull’intero progetto, non una valutazione dei singoli visitatori. Nessuna decisione sul visitatore dipende da esso.	cfg/reibung_lib.php; cfg/anomalie_lib.php; visitor_sessions.friction_score; mp_anomalie

8. Misure tecniche e organizzative (art. 32) — descrizione generale

Questa sezione costituisce la descrizione generale richiesta dagli art. 30(1)(g) e 30(2)(d). Ogni misura seguente è stata verificata nel codice o nella configurazione; sono indicati file e riga affinché il lettore possa controllare anziché fidarsi. Anche le lacune alla fine di questa sezione sono verificate e dichiarate contestualmente, perché una descrizione delle misure tecniche e organizzative che elenca soltanto ciò che esiste è pubblicità.

Ambito	Misura in vigore	Prova
Cifratura del trasporto	Le connessioni da Internet sono cifrate con TLS: TLS termina in nginx (192.168.20.2:443) e ogni richiesta HTTP viene reindirizzata a HTTPS. Il server WebSocket ascolta soltanto su 127.0.0.1:8081 senza TLS proprio ed è raggiungibile esclusivamente tramite nginx (percorso /mp_wss/); analogamente il tunnel HTTP /mp_wst, il caricamento di istantanee di pagina di grandi dimensioni /mp_dom e il punto di misurazione /mp_wsfail funzionano tramite HTTPS. All’interno della nostra rete locale nello stesso sito, le connessioni a database e Redis non sono cifrate (si veda 8.1).	/etc/nginx/conf.d/mouseplayer.conf; srv/server.php (MP_WSS_BIND, MP_WSS_TLS); www/.htaccess
Minimizzazione dei dati alla raccolta — IP	L’indirizzo IP del visitatore viene troncato immediatamente dopo la sua determinazione e quindi prima di qualsiasi componente che lo utilizzi (ultimo ottetto IPv4, ultimo gruppo IPv6). Il 10/08/2026, 236 righe pregresse contenevano ancora indirizzi completi; al 16/10/2026 nessuna riga in visitor_sessions o ip_lifetime_stats contiene un indirizzo non troncato.	class/Server.class.php (regola B)
Minimizzazione dei dati all’acquisizione — dati inseriti nei moduli	Mascheramento con una soglia minima inderogabile: al livello 0 viene sostituito ogni carattere; indipendentemente dal livello, password e dati di pagamento vengono sempre sostituiti (categorie password e payment, tipi password/email/tel/hidden, schemi di classi e nomi card|cc|cvv|cvc|password|credit|social|pesel|nip). Tutti i 7 progetti funzionano con smart_masking=0.	www/mp.js:4818-4853
Minimizzazione dei dati all’acquisizione — DOM	All’interno di data-mp-mask o .mp-masked, ogni carattere non di spaziatura viene sostituito con '*' e tutti gli attributi al di fuori di MASK_KEEP_ATTRS vengono impostati a '[FILTERED]'. Si applica anche alle mutazioni in corso.	www/mp.js:3934-3970 e 4732-4768
Minimizzazione dei dati all’acquisizione — nomi dei campi	Il nome o id grezzo di un campo di inserimento non viene trasmesso; viene inviata soltanto la categoria classificata, perché in molti negozi il nome grezzo è sufficientemente descrittivo da identificare la persona.	www/mp.js:4653-4674
Applicazione del consenso	Elenco di esclusione dei percorsi valutato PRIMA della barriera del consenso, con corrispondenza sul percorso anziché sull’URL completo (71 connessioni bloccate). Applicazione lato server come seconda rete di protezione: passano soltanto GRANTED, GRANTED_LATE o un’esenzione regionale esplicita; WITHDRAWN, paese sconosciuto e qualsiasi situazione incerta comportano close(1008) (24 connessioni bloccate). Interruttore generale site_settings.consent_gate_active=1.	class/Server.class.php:963-975 e 977-1004
Minimizzazione delle prove del consenso	La stringa TC non viene conservata in chiaro; viene conservato soltanto il suo SHA-256.	visitor_sessions.tcf_hash CHAR(64); ai/migrations/018_consent.sql
Sicurezza dell’applicazione	Token CSRF da random_bytes(32) confrontati con hash_equals(). Cookie di sessione con httponly=true, samesite='Lax' e secure condizionato a HTTPS. Password conservate come hash e verificate con password_verify(). Query preparate in tutti i percorsi di scrittura sottoposti ad audit. Limitazione della frequenza degli accessi.	cfg/lib.php:118-132 e 110-112; www/login.php:60 e 28
Prevenzione degli abusi	Blocco automatico e limite delle connessioni nel WebSocket (contatore Redis con scadenza di 10 s; 15 connessioni simultanee per IP; blocco di 24 h in Redis, troncato nel registro). Limitazione della frequenza e numero massimo di connessioni per indirizzo in nginx per pagine e handshake WebSocket. fail2ban con il jail mp-nginx-429: chi viene rifiutato più di 100 volte entro un minuto viene bloccato su HTTP e HTTPS per un’ora.	class/Server.class.php; /etc/nginx/conf.d/mouseplayer.conf; /etc/fail2ban/jail.d/mp-nginx-429.conf
Controllo degli accessi	Modello di ruoli per area di lavoro (owner / admin / viewer). L’eliminazione nel lettore è limitata a owner e admin e ogni eliminazione è inoltre circoscritta al channelid — descritto nel codice come il vero confine di sicurezza.	workspace_users.role; www/player.php:267 e 275-282
Registrazione delle modifiche	log_audit() registra utente, area di lavoro, azione, bersaglio, dettagli e IP. 666 voci, comprese create_share, revoke_share, delete_comment, player_delete_*, firewall_auto_ban (24) e superadmin_*.	cfg/lib.php:2878-2890
Link di condivisione	channelid e session_id provengono esclusivamente dal token; la restante stringa di query viene SOSTITUITA anziché ignorata; user_role rimane NULL, per cui eliminazione e ricondivisione vengono escluse lato server, non soltanto nell’interfaccia; tutti e tre gli endpoint si limitano alla sessione del token; token inventati, scaduti e revocati restituiscono la stessa risposta.	www/share.php; www/.htaccess:77
Superficie API	Il payload completo della riproduzione non fa deliberatamente parte dell’API pubblica.	www/api/v1_session_detail.php:25
Gestione delle chiavi	La chiave dell’account di servizio Google viene conservata cifrata in projects.bigquery_sa_json e decifrata tramite decrypt_sa_key() con BIGQUERY_SA_AES_KEY da .env; l’interfaccia indica AES-256.	srv/cron_integration_bigquery.php:57; cfg/lib.php:993
Segreti al di fuori del controllo di versione	Confermato sull’indice attuale: .gitignore elenca .env e git ls-files trova soltanto .env.example.	git ls-files
Esposizione di rete	Da Internet sono raggiungibili soltanto le porte 80 e 443 tramite nginx; non esiste inoltro di porte per database o Redis. Redis dell’istanza di sviluppo è associato soltanto a 127.0.0.1 (porta 6381); un’istanza Redis precedente e condivisa (porta 6379) ascolta inoltre nella rete locale. MariaDB ascolta su 127.0.0.1 e nella rete locale. Database e Redis hanno accesso limitato e sono raggiungibili soltanto dalla nostra rete locale. Un’ulteriore restrizione di accesso protegge www.mouseplayer.com.	ss -ltn; configurazione Redis; www/.htaccess

8.1 Misure dimostrabilmente NON presenti

• Nessuna cifratura dei dati a riposo. innodb_encrypt_tables, innodb_encrypt_log e innodb_encrypt_temporary_tables sono tutti OFF e non esiste un volume cifrato (lsblk mostra sda1 senza crypt).
• Nessun TLS sulle connessioni al database. have_ssl=YES, ma ssl_cert, ssl_key e ssl_ca sono vuoti. MariaDB ascolta su 127.0.0.1 e nella rete locale (192.168.20.2:3306); le connessioni dalla rete locale non sono quindi cifrate. Hanno accesso limitato e non sono raggiungibili da Internet (nessun inoltro di porte).
• Nessuna cifratura del trasporto per Redis. Le connessioni a Redis non sono cifrate sull’interfaccia locale o nella rete locale; entrambe le istanze hanno accesso limitato. L’istanza di sviluppo scrive i dati su disco per la persistenza (AOF), comprese le code con IP troncato, URL completo e payload DOM e, per la durata del blocco (24 h), l’indirizzo completo dei mittenti bloccati.
• NESSUN REGISTRO DI CHI ABBIA VISUALIZZATO QUALE REGISTRAZIONE. audit_logs registra soltanto azioni di scrittura; una chiamata a player.php, ajax_get_events.php o player_theatre.php non viene affatto registrata. È quindi impossibile rispondere a posteriori a chi abbia guardato una determinata sessione.
• I registri degli accessi di Apache contengono indirizzi IP completi, conservati per 14 giorni.
• I file di archivio degli eventi di registrazione trasferiti fuori dal sistema si trovano sullo stesso disco del sistema e del database. Un guasto di questo disco colpisce entrambi; soltanto la copia cifrata del backup, che contiene l’archivio dal 06/10/2026, assicura la conservazione in un altro luogo.
• Tutti i limiti contro il sovraccarico — nginx, fail2ban e il blocco nel server WebSocket — conteggiano per indirizzo. Nessun sistema a monte della macchina protegge da un attacco distribuito da molti indirizzi: non è presente alcuna CDN né alcun servizio di filtraggio a monte.
• Sicurezza fisica: l’accesso è riservato esclusivamente al titolare del trattamento. Il locale è chiuso a chiave e videosorvegliato; nessun’altra persona — compresi locatori o servizi di pulizia — ha accesso (dichiarazione del titolare del trattamento, 17/08/2026). L’indirizzo preciso è deliberatamente omesso qui.
• Monitoraggio e ripristino: dal 19/08/2026 i watchdog in srv/cron_status.php segnalano guasti, spazio su disco insufficiente, backup mancanti ed esecuzioni programmate fallite negli Urgent Logs (B.8) e via e-mail; dal 23/09/2026 questa posta viene effettivamente inviata tramite SMTP. Dal 02/10/2026 una nostra macchina separata nella stessa rete locale controlla ogni minuto database, Redis, server WebSocket, processi permanenti e coda tramite un endpoint di stato (www/health.php) e segnala un guasto; non può rilevare un’interruzione della connessione Internet stessa. Tempo obiettivo di ripristino: al massimo 24 ore. Prove di ripristino dalla copia esterna sono state effettuate il 05/09/2026 e il 06/09/2026 e il 07/10/2026 (ripristino completo dei dati); sono previste mensilmente (dichiarazione del titolare del trattamento, 17/08/2026). Il disco USB di backup si trova nello stesso locale del server — un singolo evento in tale luogo colpisce quindi entrambi; soltanto la copia cifrata assicura la conservazione esterna. I due file delle chiavi sono conservati stampati in una cassaforte accessibile soltanto al titolare del trattamento e sopravvivono quindi alla perdita della macchina.

9. Responsabile della protezione dei dati — valutazione ai sensi dell’art. 37 GDPR

L’art. 37(1) richiede la designazione in tre casi. Il caso (a), autorità o organismo pubblico, non si applica. Il caso (c), attività principali consistenti nel trattamento su larga scala di categorie particolari ai sensi dell’art. 9 o di dati relativi a condanne penali ai sensi dell’art. 10, non è soddisfatto: non vengono trattati intenzionalmente dati di categorie particolari. Questo non esaurisce il punto — come osservato in A.2, l’istantanea DOM conserva tutto ciò che la pagina del cliente mostra, per cui dati di categorie particolari possono entrare incidentalmente in una registrazione su un sito sanitario o finanziario. L’acquisizione incidentale non è un’attività principale consistente in tale trattamento, quindi non attiva il caso (c); ma l’esposizione è reale e va affrontata nell’inserimento dei clienti, anziché essere liquidata qui per iscritto.

Il caso (b) è quello rilevante e ha due componenti. La prima — attività principali consistenti in trattamenti che richiedono il MONITORAGGIO REGOLARE E SISTEMATICO degli interessati — è soddisfatta senza discussione. La riproduzione delle sessioni è un’osservazione continua e automatizzata del comportamento individuale; non è accessoria all’attività, È l’attività. Chi legge questo registro ed è tentato di contestare la prima componente dovrebbe fermarsi: è soddisfatta e contestarla spreca la credibilità necessaria per la seconda.

La seconda componente è la LARGA SCALA ed è qui che la risposta risulta attualmente negativa. Gli orientamenti del Gruppo di lavoro Articolo 29 ponderano quattro fattori: numero di interessati, volume e varietà dei dati, durata o permanenza del trattamento ed estensione geografica. Misurato il 10/08/2026: 706 sessioni di visitatori, 329 registrazioni distinte di visitatori, 7 progetti, 4 account cliente. In termini di numero di interessati, non si è affatto vicini alla larga scala — e per di più si tratta di numeri dell’istanza di sviluppo. Al 16/10/2026: 3514 ID visitatore distinti classificati come umani negli ultimi 30 giorni su tutti i progetti, ancora molto al di sotto della soglia nella conseguenza 2.

Due dei quattro fattori indicano comunque la direzione opposta e il registro dovrebbe dichiararlo anziché affidarsi a quello rassicurante. La VARIETÀ dei dati per persona è eccezionalmente ampia: HTML completo della pagina, compreso tutto ciò che mostra, dati inseriti nei moduli a livello di singolo tasto, comportamento di movimento e clic, punteggi comportamentali derivati e descrizione in prosa della sessione. La DURATA è lunga: a seconda del livello, le registrazioni rimangono fino a 365 giorni e nel backup fino a ulteriori 364 giorni, sebbene da agosto 2026 esistano e vengano applicati periodi di eliminazione per tutte le tabelle (sezione 6). Soltanto il numero di persone mantiene la valutazione al di sotto della soglia e questo è precisamente il valore che MousePlayer non controlla: viene determinato dal traffico ricevuto dal sito web di ogni cliente. Un solo cliente di commercio elettronico di medie dimensioni potrebbe da solo portare il prodotto oltre la soglia, senza alcuna decisione presa qui.

• Conseguenza 1 — documentare la valutazione con la relativa data. L’art. 5(2) impone la responsabilizzazione; una valutazione negativa mai registrata è indistinguibile da una mai effettuata.
• Conseguenza 2 — definire l’evento che ne impone la riapertura. L’evento ragionevole è il numero di visitatori monitorati al mese su tutti i clienti, oltre a un riesame per ogni nuovo cliente di dimensioni significative. Soglia e frequenza: la valutazione ai sensi dell’art. 37 viene ripetuta non appena vengono osservati più di 100000 utenti finali al mese su tutti i Clienti, e comunque ogni anno. Responsabile: Lukas Wójcik, proprietario. (decisione del titolare del trattamento, 17/08/2026) Attuato il 19/08/2026: il numero di utenti finali distinti osservati negli ultimi 30 giorni viene conteggiato una volta al giorno dal processo di monitoraggio e confrontato con questa soglia e con la data dell’ultima valutazione registrata; il superamento dell’una o dell’altra genera un avviso via e-mail. Soglia e data sono impostazioni lette dalla stessa riga citata in questa frase, per cui documento e misurazione non possono divergere. Un evento di attivazione che nessuno misura è un’annotazione, non un controllo – questa era la lacuna descritta da questo paragrafo, che ora non la descrive più.
• Conseguenza 3 — verificare il diritto nazionale. L’art. 37(4) consente al diritto dell’Unione o degli Stati membri di richiedere la designazione in ulteriori casi. da completare: conferma da un legale polacco se il diritto polacco richieda un responsabile della protezione dei dati in ulteriori casi oltre all’art. 37(1)
• Conseguenza 4 — rimane aperta la designazione volontaria. Se un responsabile della protezione dei dati viene designato volontariamente, gli art. 37–39 si applicano integralmente, comprese la pubblicazione e la comunicazione dei recapiti. È una decisione, non un’impostazione predefinita.
• Conseguenza 5 — distinta ma adiacente: è molto probabile che per ogni CLIENTE in qualità di titolare del trattamento sia richiesta una valutazione d’impatto sulla protezione dei dati ai sensi dell’art. 35, dato il monitoraggio sistematico combinato con valutazione e attribuzione di punteggi. In qualità di responsabile del trattamento, MousePlayer deve prestare assistenza ai sensi dell’art. 28(3)(f). Esiste una valutazione d’impatto a livello di prodotto — è quella pubblicata sotto “Valutazione d’impatto sulla protezione dei dati”. Una copia separata non viene consegnata ai Clienti (decisione del titolare del trattamento, 17/08/2026). L’assistenza ai sensi dell’art. 28(3)(f) viene fornita su richiesta e si basa sui documenti pubblicamente disponibili: questo registro, la valutazione d’impatto pubblicata, le misure tecniche e organizzative e l’elenco dei sub-responsabili.

10. Lacune note

Tutto ciò che segue è dimostrato, non sospettato. Questa sezione esiste perché un registro delle attività di trattamento è uno strumento di lavoro: lo scopo è poter vedere i punti aperti, non presentare un quadro privo di problemi. Le voci sono ordinate in base a quanto sarebbero critiche in un audit, non alla difficoltà di risolverle.

Lacuna	Cosa è dimostrato	Perché è rilevante
Indirizzi IP completi nei registri della nostra applicazione	Al 16/10/2026 i dati pregressi in visitor_sessions e ip_lifetime_stats sono troncati (il 10/08/2026, rispettivamente 236 e 291 righe non troncate). mouseplayer_logs, audit_logs, user_ip_history, login_sessions, share_views e support_requests (parte B), nonché i registri degli accessi di nginx e Apache, rimangono deliberatamente non troncati	Per la parte B l’indirizzo completo è giustificato (B.2–B.7) e limitato da periodi. È comunque elencato qui perché queste tabelle entrano in ogni backup.
Dati pregressi con dati dei moduli in chiaro	Il 10/08/2026, 173 righe in mouse_events con event_type='input' contenevano valori non mascherati dal 21/07/2026 al 27/07/2026, compresi nomi di persone. Le righe sono state eliminate il 17/08/2026, prima dell’introduzione dei file di archivio il 18/08/2026; al 16/10/2026 nessuna di esse si trova in mouse_events	Le righe attuali sono mascherate, quindi il controllo funziona. I vecchi valori non possono trovarsi nell’archivio o nel backup di oggi; non è noto alcun backup anteriore al 17/08/2026, ma la sua assenza non è stata verificata in dettaglio.
I link di condivisione aggirano completamente l’autenticazione	/s/<40-hex-token> porta direttamente a player.php?share=<token>; il token costituisce l’intera barriera	Il link può essere inoltrato a chiunque, per questo la categoria di destinatari per A.1, A.2, A.3 e A.9 è di fatto aperta. Questo è limitato dalla durata massima (7 giorni per impostazione predefinita, al massimo 90), dalla revoca in qualsiasi momento e dal registro degli accessi (B.6).
Nessun registro di chi abbia visualizzato una registrazione	audit_logs registra soltanto azioni di scrittura; le chiamate a player.php, ajax_get_events.php e player_theatre.php non vengono registrate	Dopo un incidente è impossibile accertare chi abbia guardato quale sessione. Questa è la singola misura la cui assenza è più difficile da spiegare a un’autorità di controllo.
L’intero server viene copiato ogni giorno in un luogo esterno	srv/backup-crypt.sh salva ogni giorno tutti i database e l’intero albero web, compreso ogni .env, e dal 06/10/2026 anche l’archivio degli eventi di registrazione; la copia viene cifrata sul nostro server prima del trasferimento (rclone crypt) e dal 05/09/2026 conservata in un bucket presso Google Cloud Storage a Varsavia, coperto dai termini di Google Cloud sul trattamento dei dati (sezione 4)	Ciò che lascia ogni giorno i locali non è soltanto una copia delle registrazioni delle sessioni, ma il server completo, con i segreti di produzione di diversi sistemi. La cifratura sottrae il contenuto a Google, non l’estensione della copia. Se entrambi i file delle chiavi vanno perduti, il backup è irrecuperabile; per questo sono conservati anche stampati nella cassaforte (sezione 8.1).
L’arrivo del backup viene monitorato	Non comprovato fino all’11/08/2026. Da allora l’esecuzione scrive un registro e verifica a destinazione; dal 19/08/2026 un watchdog controlla l’ultima esecuzione riuscita rispetto a un termine e segnala un’esecuzione mancante negli Urgent Logs e via e-mail	La lacuna di questa riga è chiusa. Rimane elencata affinché sia tracciabile che il backup è stato eseguito senza prova fino all’11/08/2026.
Vecchi script di backup	I vecchi script di backup sono stati rimossi il 16/10/2026. Nessuno dei due veniva ancora eseguito; dall’11/08/2026 il backup giornaliero viene eseguito tramite srv/backup-crypt.sh	La lacuna di questa riga è chiusa. Rimane elencata affinché sia tracciabile che fino all’11/08/2026 chiunque ottenesse l’account SSH pi disponeva di root alle 02:00.
Nessuna cifratura dei dati a riposo, nessun TLS sulle connessioni a database e Redis	innodb_encrypt_* tutti OFF, nessun volume cifrato; ssl_cert/ssl_key/ssl_ca vuoti, MariaDB raggiungibile anche nella rete locale; Redis con accesso limitato ma senza cifratura e con persistenza su disco (AOF)	Le registrazioni — compresi il payload DOM nella coda Redis e i file di archivio — sono leggibili da chiunque abbia accesso al file system; nella rete locale le connessioni al database avvengono in chiaro. Nessuno di questi percorsi è raggiungibile da Internet.
Una parte delle registrazioni di consenso è costituita da dati di test	Il 10/08/2026, 671 sessioni su 706 contenevano consent_source='testdata' con consent_ts IS NULL, impostato da ai/devdata/001_altsitzungen_markieren.sql; al 16/10/2026 esistono ancora 566 sessioni di questo tipo	Per queste sessioni il registro del consenso non può fungere da prova. È un artefatto del sistema di sviluppo, ma la stessa query in produzione richiederebbe lo stesso controllo.
La revoca non elimina nulla	Al 16/10/2026 projects.consent_delete_on_withdraw non è impostato per nessun progetto (valutato nel ramo consent_withdrawn in srv/db_worker.php)	La revoca interrompe le ulteriori registrazioni — come richiesto dall’art. 7(3) — ma un cliente che presume che elimini anche la registrazione precedente si sbaglia. Questa distinzione deve essere indicata nella documentazione rivolta ai clienti.
Tutto quanto riportato qui è misurato sull’istanza di sviluppo	APP_ENV=dev; il progetto di test mpconsenttest01 e le fixture s_mptest_ sono inclusi nei conteggi	La struttura di questo registro è trasferibile alla produzione; i numeri no. La produzione deve essere misurata prima di fare affidamento su questo registro nei rapporti esterni.
La ricerca delle chiamate in uscita non era esaustiva	In cfg/, srv/, class/ e www/ sono stati cercati curl_init, curl_exec, file_get_contents con http, fsockopen, stream_context_create e tutti i valori letterali https; le directory vendor non sono state esaminate	Gli alberi vendor contengono gli endpoint di Stripe, Google Cloud, PHPMailer e Symfony. Tali servizi sono indicati nella sezione 4, ma l’affermazione 'non esiste alcun’altra chiamata in uscita' è limitata dall’ambito della ricerca.
Nessun interruttore per progetto per i profili comportamentali	profile_aktiv è un’impostazione globale del gestore. mp_ki_module_katalog() in cfg/lib.php elenca nove sezioni IA selezionabili e nessuna di esse è quella dei profili, per cui projects.ki_module non copre questa scheda; la voce di navigazione in www/project.php è incondizionata. Misurato il 27/08/2026.	Un cliente che non desideri che le visite dei propri visitatori siano raggruppate non può disattivare l'operazione. Controlla la registrazione, ma non la derivazione da essa. Ogni altra sezione derivata può essere deselezionata per progetto — questa è l’eccezione. La lacuna di conservazione presente qui fino al 27/08/2026 è chiusa: mp_profile e mp_sequenzmuster hanno ora periodi propri, si veda 6.2.
Una richiesta di cancellazione raggiunge le sessioni GA4 importate soltanto se il connettore di analisi è attivo	Dal 01/09/2026 mp_sitzungen_loeschen() comprende ga4_sessions e ga4_events in una richiesta ai sensi dell’art. 17, collegate tramite ga4_sessions.user_pseudo_id = visitor_sessions.custom_user_id e circoscritte al canale. Tale collegamento esiste soltanto quando il cliente ha attivato il connettore di analisi GA4 — è questo che vi scrive l’ID client del cookie _ga. Se invece compila custom_user_id tramite setUserId() con un proprio identificativo, non esiste alcun percorso da un visitatore alla sua riga importata. Il caso è coperto da un test specifico (test_ga4_import.php, sezione J) affinché non venga dimenticato.	Per tali clienti la riga importata rimane dopo una richiesta di cancellazione finché non viene eliminata dal periodo di A.14. È pseudonima e non attribuibile da noi — proprio per questo non può essere eliminata in modo mirato. Un percorso di cancellazione attraverso la proprietà GA4 stessa è una questione che spetta al titolare del trattamento che la gestisce.
Il consenso per le righe importate non può essere comprovato, ma soltanto dedotto	Vengono importati i dati che contengono un user_pseudo_id; gli hit senza cookie in caso di consenso negato non lo contengono e vengono esclusi (A.14). Per queste righe non esiste una registrazione paragonabile a consent_events — GA4 non fornisce nell’esportazione alcun attributo di consenso che possa essere conservato qui.	Per le proprie registrazioni MousePlayer può dimostrare per ogni sessione su cosa si basi; per una sessione importata non può farlo. La barriera è meccanica e funziona, ma prova soltanto che è stato impostato un cookie — non a cosa il visitatore abbia acconsentito. La responsabilità spetta al titolare del trattamento, che governa la raccolta presso Google.
Il nome personalizzato del visitatore è testo libero non controllato	A.13, dal 28/08/2026. mp_besucher_label_setzen() tronca a 64 caratteri, rimuove le interruzioni di riga e verifica che il visitatore appartenga al progetto — nulla controlla il CONTENUTO e non esiste alcuna specifica su di quale tipo dovrebbe essere.	Il titolare del trattamento può inserirvi categorie particolari ai sensi dell’art. 9 („Signor X, sedia a rotelle“) senza alcuna barriera o avvertenza. La conformità è una sua responsabilità, non del responsabile del trattamento — ma un responsabile del trattamento che offre un campo di testo libero senza dire nulla al riguardo ha creato l’opportunità. Un controllo tecnico non è possibile: una macchina non può distinguere un nome da un dettaglio sanitario. Sarebbe invece possibile un avviso accanto al campo.
Esempi di riesame dei bot senza periodo di eliminazione	Un vettore pseudonimo di caratteristiche per ogni sessione oggetto di decisione (bot_review_labels, A.19) rimane dopo la sessione finché non viene impostato un periodo. L’impostazione predefinita di retention_bot_labels_years è 0 (illimitato); il gestore può impostarla in anni.	Non sono contenuti dei visitatori, ma contengono l’identificativo della sessione. La scelta di impostare un periodo spetta al gestore.
Il testo libero di un sondaggio viene filtrato soltanto in modo approssimativo	A.21, dal 27/09/2026. mp_umfrage_text_filtern() sostituisce indirizzi e-mail, indirizzi IP e numeri di telefono, nel browser e nuovamente nel worker. Non riconosce nomi, indirizzi postali, numeri cliente o informazioni sanitarie.	Un visitatore può scrivere qualsiasi cosa nella risposta successiva, comprese categorie particolari ai sensi dell’art. 9. L’avviso sotto il campo chiede di non farlo; non è un blocco. Come per il nome del visitatore di cui il titolare del trattamento è l’autore (A.13), il contenuto non può essere classificato in modo affidabile da una macchina.

11. Manutenzione di questo registro

Gli art. 30(1) e 30(2) richiedono che il registro sia tenuto in forma scritta e messo a disposizione dell’autorità di controllo su richiesta. Questo rende necessarie due cose che non si trovano nel documento stesso: qualcuno che ne abbia la responsabilità e un intervallo con cui venga confrontato con il sistema anziché con la propria versione precedente.

• Titolare della manutenzione e intervallo di riesame: Responsabile: Lukas Wójcik, proprietario. Riesaminato annualmente e a ogni modifica del trattamento. Le versioni datate sono conservate nel controllo di versione sotto ai/cms/. (decisione del titolare del trattamento, 17/08/2026)
• Eventi che impongono un aggiornamento indipendentemente dall’intervallo: un nuovo sub-responsabile o una modifica della destinazione; una nuova tabella contenente dati personali; una modifica alla catena di eliminazione mp_sitzungen_loeschen() o all’eliminazione giornaliera in srv/db_worker.php; attivazione dell’esportazione BigQuery o dei webhook per qualsiasi cliente; una modifica alle impostazioni predefinite del mascheramento; il primo cliente il cui sito mostri dati di categorie particolari.
• Metodo: ogni valore di questo registro deriva da una misurazione sul codice, sullo schema o sul database in una data indicata. Un riesame che si limita a rileggere il testo non ha riesaminato nulla — i numeri devono essere misurati nuovamente e i segnaposto devono essere compilati oppure riportati esplicitamente con una motivazione.
• Questo registro non sostituisce l’elenco dei sub-responsabili, il documento sulle misure tecniche e organizzative, l’accordo sul trattamento dei dati o l’informativa sulla privacy. Quando tali documenti e questo registro sono in disaccordo, la discrepanza è una constatazione, non un problema di formattazione.