Privacy tecnica e archiviazione

Questa guida descrive il tracker del browser attuale. Consulta l’informativa sulla privacy per la policy del servizio Seean e configura il flusso di consenso del tuo sito in base ai tuoi requisiti. Un’installazione tecnica non è una valutazione di conformità legale.

Archiviazione nel browser

Il tracker predefinito non imposta cookie e non conserva alcun identificatore di misurazione del visitatore o della sessione in localStorage o sessionStorage. Il suo stato di navigazione temporaneo vive in memoria. La preferenza di opt-out del browser seean_ignore può restare in localStorage.

Il collettore deriva un hash pseudonimo del visitatore da un segreto del server, dal sito web, dalla data UTC, dall’ambito del dominio del sito web, dall’indirizzo IP e dallo user agent. Indirizzi IP grezzi e user agent non vengono memorizzati nei record degli eventi analitici. L’hash cambia a mezzanotte UTC e differisce tra i siti web. Cambi di rete o reti condivise possono dividere o unire visitatori apparenti; questi conteggi non sono conteggi esatti di persone. Quando non è disponibile alcun IP, lo sostituisce il nonce temporaneo del documento, quindi la continuità dopo un ricaricamento non è garantita.

Le sessioni sono assegnate dal collettore. L’attività dello stesso visitatore giornaliero continua una sessione fino a 30 minuti di inattività, un timestamp a ritroso o una campagna con tag diversa (campi UTM o il nome di un parametro click-id pubblicitario; i valori dei click-id non vengono mai letti né memorizzati). I record degli eventi portano anche il titolo della pagina (200 caratteri), la dimensione dello schermo e il primo tag Accept-Language del browser; la stringa di query in sé non viene raccolta. Il tracker rimuove la vecchia archiviazione _seean_v e _seean_session quando si inizializza normalmente. Gli identificatori raccolti in precedenza, i report salvati e gli ordini restano intatti; questa transizione non re-identifica i visitatori storici.

Origini e domini

Il dominio del sito web configurato e i suoi sottodomini condividono l’identità giornaliera quando usano lo stesso token e gli stessi metadati della richiesta. I domini non correlati restano in ambiti separati. Il passaggio cross-domain opzionale usa un token casuale valido per la giornata nei link e in sessionStorage; il server lo sottopone a hash separatamente per ogni sito web e giorno UTC. È disattivo a meno che non venga attivato su entrambi i siti tramite lo snippet Explicit o la configurazione Minimal nella dashboard. Nessun passaggio in arrivo viene adottato prima che quella configurazione abbia successo. Il token di passaggio grezzo non viene memorizzato nei record analitici.

Dati inviati dal tracker

I payload di raccolta contengono il token pubblico del sito, un nonce di sessione temporaneo, il fuso orario del browser quando disponibile, hostname, pathname e i valori UTM source, medium, campaign, term e content. La raccolta cross-domain opt-in invia anche il suo token di passaggio. Il collettore restituisce l’hash giornaliero del visitatore per l’attribuzione opzionale del checkout. Le visualizzazioni di pagina includono il referrer di ingresso della sessione del documento. I Web Vitals inviano misurazioni e ID delle metriche; gli eventi personalizzati possono includere le proprietà fornite dalla tua applicazione.

Il campo pagina usa location.pathname, non l’URL completo. Tuttavia i valori UTM vengono letti separatamente e il referrer di ingresso può contenere informazioni dell’URL consentite dalla referrer policy del browser. Non inserire password, token privati o dettagli personali in percorsi, campagne o proprietà degli eventi personalizzati. Omettere l’URL completo della pagina non sanifica automaticamente quei campi.

Il server di raccolta riceve anche i normali metadati della richiesta. Questo elenco di campi del browser non afferma che le richieste di rete nascondano l’IP del mittente all’infrastruttura di hosting.

Presenza nel browser

Mentre una pagina tracciata è visibile, un segnale di presenza ogni 30 secondi invia gli stessi input di identità giornaliera limitata al sito, il pathname e il referrer di ingresso usati dal tracker. Non ispeziona il contenuto della pagina, non registra clic e non identifica un account. La presenza rispetta gli stessi segnali di privacy, le stesse esclusioni e la stessa disponibilità della raccolta. Non aggiunge visualizzazioni di pagina, eventi personalizzati o utilizzo e non estende le sessioni analitiche.

Il collettore conserva solo l’ultimo stato di presenza per sito web e visitatore giornaliero, con metadati approssimativi di posizione/dispositivo per Tempo reale. È separato dalla cronologia degli eventi grezzi. Uno stato scade dalla finestra online dopo due minuti; una pulizia limitata viene eseguita ogni cinque minuti. Anche il reset e l’eliminazione del sito web lo cancellano. Le copie di ripristino cifrate esistenti seguono la policy di conservazione dei backup.

Segnali di privacy e opt-out

Il tracker sopprime la raccolta per Global Privacy Control (true), valori Do Not Track supportati (1 o yes), automazione del browser (navigator.webdriver === true) o seean_ignore in localStorage impostato a true. Controlla questi segnali prima di inizializzare lo stato del visitatore e prima di inviare attività successive. L’archiviazione esistente non viene eliminata automaticamente quando una preferenza cambia.

Una pagina inizialmente ignorata espone metodi del tracker senza effetto; l’esistenza di window.seean non dimostra la raccolta. Se un opt-out iniziale viene rimosso, ricarica la pagina per inizializzare il tracciamento. Un tracker già attivo controlla le modifiche successive dell’opt-out prima di inviare altri dati. Vedi Esclusioni per il controllo nel browser e le regole lato server per pathname/hostname.

Consenso e verifica

Seean non fornisce un banner di consenso né un’API generale di gestione del consenso. Se il tuo sito richiede un permesso prima delle analisi, il tuo sistema di consenso deve controllare quando lo script si carica e cosa succede quando il permesso cambia. data-local abilita solo i test su localhost; non sovrascrive le preferenze di privacy. Un trigger del tag manager non è di per sé un permesso del visitatore.

Verifica gli stati di consenso che il tuo sito supporta, inclusi il rifiuto e l’accettazione successiva, insieme ai controlli di installazione. Non interpretare un download riuscito dello script o una risposta 204 vuota come prova che un evento sia stato memorizzato.

Utenti identificati (opt-in)

Il proprietario di un sito web può attivare Identify users (Identifica utenti) in Settings → Installation (Impostazioni → Installazione) e chiamare seean.identify(id) per gli utenti autenticati del proprio sito. Il collettore memorizza quindi quell’identificatore fornito dal cliente come colonna uid nei record degli eventi del sito web; mentre l’opzione è disattiva, qualsiasi id in un payload viene scartato prima dell’archiviazione. Seean non deriva né indovina mai questo identificatore, e l’hash giornaliero del visitatore non ne è influenzato. L’id è conservato nella memoria del tracker solo per la pagina aperta, mai in cookie o nell’archiviazione del browser. I record identificati seguono la stessa conservazione di tre anni, compaiono nel CSV degli eventi del proprietario, possono essere eliminati per persona dalla dashboard e non sono mai inclusi nelle dashboard condivise, nei widget incorporati, nella demo pubblica o nell’API analitica. Vedi Persone e retention.

Rimozione

Rimuovi lo script da ogni posizione di installazione e pubblica la modifica per fermare la raccolta futura nelle pagine caricate di nuovo. Una pagina già aperta può conservare lo script caricato finché non viene ricaricata o chiusa. Rimuovere lo script non cancella l’archiviazione del browser né i report raccolti in precedenza. Consulta la gestione del sito web per le azioni di gestione dei dati disponibili.

Archiviazione sul server e nuovi tentativi

Gli eventi grezzi e i Web Vitals usano lo store analitico. I record accettati restano in coda durante un errore temporaneo di trasferimento dell’archiviazione e vengono ritentati automaticamente. I nuovi tentativi di archiviazione mantengono l’identità di un record accettato: copiare lo stesso record tra gli store di Seean non aggiunge un’altra visita né un altro campione Web Vitals. Un valore accettato successivamente per lo stesso ID di metrica Web Vitals aggiorna quel campione, anche quando un tracker più vecchio omette la sua sequenza di aggiornamento. Richieste di visualizzazione di pagina in arrivo separate restano eventi separati; questa non è una garanzia che la tua integrazione possa reinviare richieste di raccolta arbitrarie senza contarle di nuovo.

Con l’archiviazione grezza in coda, un’identità Web Vitals sconosciuta o scaduta deve essere controllata prima che un campione sia accettato. Quel controllo non attende eventi in coda non correlati né uno snapshot di ripristino. Ogni misurazione nota mantiene disponibile il suo ultimo valore accettato finché quello specifico aggiornamento non ha raggiunto lo store analitico; un’identità scaduta e completamente trasferita può essere pulita indipendentemente dal traffico degli altri siti web. Se lo store analitico stesso non è disponibile, un controllo di identità a freddo restituisce 503 senza aggiungere il campione né addebitarlo alla quota. Le visualizzazioni di pagina e gli aggiornamenti la cui identità è già nota possono comunque essere accettati in coda. Dopo il reset di un sito web, la ricerca dell’identità considera solo le misurazioni al confine di quel reset o successive. Il tracker del browser non garantisce il reinvio delle richieste rifiutate; le misurazioni mancanti non sono punteggi pari a zero.

Un piccolo riepilogo dell’attività per sito web memorizza i primi e gli ultimi orari degli eventi preparati e l’orario dell’ultima visualizzazione di pagina per gli stati di attesa e lo stato della configurazione. Non contiene proprietà degli eventi né identificatori dei visitatori e segue il reset e l’eliminazione del sito web.

La raccolta continua anche durante gli snapshot di ripristino. I record appena accettati possono attendere brevemente nella coda di trasferimento, quindi un report può restare nello stato di preparazione finché quei record non sono disponibili; i lettori che ne hanno bisogno richiedono il trasferimento immediatamente, e solo uno snapshot di ripristino in esecuzione lo rinvia.

Visualizzazioni di pagina, eventi, Web Vitals e ordini seguono la policy di conservazione mobile di tre anni di calendario. La pulizia usa un limite di calendario UTC con precisione al millisecondo. Reimpostare o eliminare un sito web si applica anche ai record in attesa di trasferimento dell’archiviazione; un nuovo tentativo interno ritardato non può ripristinarli nei report. Le copie di ripristino cifrate seguono la policy separata di conservazione dei backup.

La pulizia dei dati grezzi viene eseguita in batch limitati in background. I marcatori di eliminazione conservano solo le chiavi necessarie a impedire che un nuovo tentativo interno più vecchio ricrei un record rimosso; proprietà degli eventi, percorsi e valori delle misurazioni vengono rimossi dalla versione attiva. Le parti di archiviazione sostituite e le copie di ripristino cifrate vengono recuperate secondo le loro pianificazioni di archiviazione separate. Non si tratta di una cancellazione sicura immediata di ogni copia fisica.

Se la conservazione dei dati sorgente rimuove record necessari al dettaglio su richiesta di una Panoramica più vecchia, aggiorna l’analisi prima di aprire quell’elenco. I risultati dei report salvati restano invariati; il sistema non mescola totali conservati con dettagli ricalcolati da un dataset diverso.

Qualcosa non è chiaro? Contatta il supporto.