Cookie e analytics: scegli tu.

Quando l’invio pubblico di una richiesta o l’avvio del checkout è attivo, Rinoma usa Cloudflare Turnstile come controllo anti-abuso strettamente necessario. Non è analytics o marketing e non dipende dalle due scelte facoltative qui sotto. Quando il modulo arriva alla fase in cui può essere inviato, lo script e il riquadro Turnstile comunicano direttamente con challenges.cloudflare.com: Cloudflare tratta segnali tecnici come indirizzo IP, impronta TLS, user agent, site key e origine, oltre a segnali dell’ambiente browser/dispositivo e dell’eventuale interazione. Rinoma non invia a Cloudflare email, contenuto del modulo, dati fiscali, dati Stripe o l’identificatore casuale in chiaro; usa soltanto un’impronta SHA-256 per legare il token temporaneo alla richiesta e non aggiunge l’IP del visitatore alla verifica server.

Il token Turnstile e la risposta del fornitore non vengono conservati da Rinoma. Per riconoscere una verifica recente, Redis conserva per non più di 25 ore soltanto l’impronta SHA-256 non reversibile dell’identificatore casuale del modulo o dell’ordine, senza dati del modulo o segnali Cloudflare. La modalità di pre-clearance è disattivata, quindi Rinoma non richiede il cookie cf_clearance; ciò non equivale a dichiarare che il servizio non usi alcuna memoria tecnica. Cookie, segnali e tempi applicati dal fornitore seguono la sua informativa specifica Turnstile e la configurazione contrattuale che il titolare deve verificare prima dell’attivazione. Se script o verifica non sono disponibili, il modulo non viene accettato e può essere ritentato; navigazione, informative e preferenze restano accessibili.

La misurazione interna del funnel, Google Analytics 4 e la misurazione Meta tramite Pixel e API Conversions sono facoltativi e restano disattivati finché non autorizzi separatamente la relativa finalità. Se rifiuti, navigazione e acquisto restano disponibili senza queste tecnologie.

Con il consenso, Google Analytics registra le pagine visitate e informazioni tecniche come tipo di dispositivo, browser e area geografica approssimativa. Rinoma non invia a Google email, contenuto dei moduli o dati della carta. Abbiamo disattivato Google Signals e la personalizzazione pubblicitaria.

Con il consenso marketing, Meta Pixel registra le pagine pubbliche visitate, la visualizzazione del report esempio, i clic sulle call to action, l’avvio dell’onboarding e il tentativo di avvio del checkout. Prima di inizializzare il Pixel o inviare un evento rimuoviamo parametri e frammenti dall’indirizzo pubblico; le richieste del browser rivelano comunque a Meta l’indirizzo IP di rete e normali informazioni tecniche di browser e dispositivo. Se Stripe conferma il pagamento, il server invia inoltre tramite API Conversions un evento Purchase con data e ora, prodotto fisso “Report Visibilità AI”, importo di 55 euro, valuta EUR, un identificatore evento casuale, gli identificatori Meta _fbp e/o _fbc, lo user agent limitato del browser e il solo URL fisso, senza parametri, della pagina di conferma. Serve ad attribuire e ottimizzare le campagne Meta. Nel payload server non impostiamo client_ip_address e non inseriamo email, contenuto dei moduli, nomi, identificativi fiscali, dati della carta, identificativi dell’ordine, parametri dell’URL o identificativi Stripe. Il Pixel nel browser resta escluso dalle pagine di checkout, conferma, amministrazione e report privati.

Google Analytics può impostare cookie come _ga e _ga_*, con durata massima ordinaria di due anni. Meta Pixel può impostare identificatori come _fbp e, quando provieni da un annuncio, _fbc: nel browser durano di norma fino a 90 giorni e possono essere rinnovati da una nuova attività compatibile. Se l’acquisto non avviene, la copia destinata all’API, inclusi user agent e URL fisso, raggiunge il termine dopo 48 ore; un pagamento confermato soltanto dopo questo termine resta valido ma non viene attribuito a Meta. Dopo un pagamento tenta l’invio per non più di sette giorni. Questi dati vengono cancellati dalla copia Rinoma subito dopo l’accettazione di Meta, la revoca, la soppressione o la scadenza; il solo audit pseudonimo di consenso e consegna raggiunge il termine dopo 90 giorni. Le cancellazioni al raggiungimento di 48 ore o 90 giorni avvengono nel ciclo giornaliero successivo, normalmente entro meno di altre 24 ore, salvo un errore operativo che viene monitorato e deve essere recuperato. Per coprire l’intera validità massima di 180 giorni del consenso e il giorno di confine successivo, e impedire che un consenso precedente riapra la misurazione dopo una revoca, conserviamo per non più di 181 giorni soltanto l’impronta crittografica non reversibile dell’identificatore casuale dell’ordine. Meta conserva e usa gli eventi secondo finalità, funzionalità e obblighi descritti nelle proprie informative. I fornitori sono Google Ireland Limited e Meta Platforms Ireland Limited; consulta le informative di Google, Meta e la Cookie Policy Meta.

Google, Meta e le rispettive società del gruppo possono trattare alcuni dati fuori dallo Spazio Economico Europeo usando i meccanismi di trasferimento indicati nelle loro informative. I fornitori usati per produrre il report non dipendono da questi consensi: ricevono soltanto il contesto dell’attività e le domande necessarie all’esecuzione dell’ordine, come descritto nell’informativa privacy.

Le due scelte, con versione, data e un’epoca casuale quando concesse, vengono salvate separatamente nella memoria locale del browser per non più di 180 giorni; l’epoca serve soltanto a distinguere autorizzazioni successive tra schede e non viene inviata al server, a Google o a Meta. Un record scaduto, malformato o di una versione non più valida viene eliminato. Un rifiuto o una revoca può essere protetto anche da un cookie tecnico distinto per finalità, limitato al sito, privo di identificatori e valido al massimo 180 giorni: contiene soltanto il diniego e prevale sempre su un’autorizzazione locale finché una nuova autorizzazione non viene salvata e verificata. Puoi cambiare le scelte in qualsiasi momento; accettazione e rifiuto hanno lo stesso rilievo e “Revoca tutto” interrompe entrambe le finalità con un solo clic. Se il browser impedisce sia la modifica della memoria locale sia quella del cookie tecnico, la misurazione viene fermata nella scheda corrente e il controllo segnala che la scelta non è stata salvata: prima di ricaricare occorre abilitare o cancellare i dati del sito e riprovare. Global Privacy Control o Do Not Track impostato a 1 prevalgono su una scelta salvata. Prima di rendere visibile una nuova autorizzazione positiva tra schede, un giornale tecnico locale valido al massimo 10 minuti registra identificatore casuale della transazione, finalità, fase, copie canoniche della precedente e nuova preferenza e presenza del cookie di diniego, oltre a data e scadenza. Non contiene identificatori di ordine o sessione né dati del modulo e viene eliminato dopo completamento o recupero.

Per ogni revoca analytics o Meta non confermata, prima di modificare la cache condivisa salviamo, tra al massimo 64, una voce locale distinta sotto chiave casuale con tipo, identificatore casuale di ordine o sessione, scadenza originaria, data tecnica di inserimento, eventuale epoca browser e un indicatore numerico di conferma inizialmente pari a zero. Una risposta 2xx del server cambia nello stesso record soltanto tale indicatore da zero a uno, senza allocare una nuova chiave. Un’ancora locale priva di identificatori conserva versione e data del consenso, data di avvio e scadenza; il cookie tecnico degli ordini conserva la prima scadenza necessaria a coordinare le schede, mentre la memoria temporanea della sessione conserva scadenza ed epoca ma non l’identificatore. Cache e cookie sono aiuti di consegna, non prova di completamento. Nessun tentativo o conferma rinnova la scadenza originaria. In condizioni ordinarie le voci sono eliminate dopo la conferma applicabile o entro il termine massimo di 181 giorni. Se il browser resta offline o il suo orologio è incoerente mentre manca la conferma, gli esatti byte già creati possono rimanere oltre la data nominale, con la misurazione bloccata, soltanto fino alla prima conferma 2xx e alla pulizia locale; la scadenza server non viene estesa. Cancellare i dati del sito rimuove tali byte ma può rimuovere anche la capacità di ritentare una revoca non sincronizzata, quindi usa prima questo controllo mentre sei online. Una nuova autorizzazione vale soltanto per misurazioni future in una nuova sessione; per le fasi di un ordine revocato serve un nuovo report.

Separatamente, soltanto quando una copia di attribuzione Meta è stata effettivamente acquisita o una revoca è stata registrata, Redis conserva un’impronta crittografica non reversibile dell’identificatore casuale dell’ordine per non più di 181 giorni. Serve unicamente a riconoscere e limitare una successiva richiesta di revoca prima di interrogare il database; non contiene il token in chiaro, non contiene dati del modulo e non viene inviata a Meta.

Per la revoca analytics, PostgreSQL conserva per non più di 181 giorni l’ambito ordine o sessione, la relativa impronta crittografica non reversibile, la data della revoca e la scadenza. Inoltre, dal primo evento o attribuzione consentiti conserva un registro tecnico di idoneità alla revoca: tipo di capacità, impronta non reversibile, data del consenso e scadenza. La data dell’ultima pubblicazione in Redis è registrata soltanto come stato operativo interno. Il registro serve a mantenere la revoca accessibile anche sotto traffico anonimo e a ricostruire in modo completo i marcatori dopo un ripristino o riavvio Redis. Non contiene UUID o token in chiaro, dati del modulo o identificatori dei fornitori e non supera 181 giorni dal primo consenso; un nuovo evento o tentativo non rinnova la scadenza. Redis conserva per il solo tempo residuo la stessa capacità tipizzata, senza token in chiaro. In una richiesta di accesso comunichiamo il tipo di capacità, la data del consenso e la scadenza, ma non l’impronta interna né lo stato operativo di pubblicazione. Una cancellazione ammissibile non elimina in anticipo le righe ancora attive, che restano esclusivamente come controllo temporaneo di soppressione e sicurezza fino alla scadenza; il ciclo giornaliero elimina poi le righe PostgreSQL scadute e Redis le fa scadere automaticamente.

Solo dopo il consenso analytics, la misurazione interna del funnel usa un identificatore casuale e la prima pagina pubblica conservati nella memoria della singola scheda, senza creare un profilo tra siti o sessioni. La provenienza viene ridotta subito a categorie predefinite — per esempio accesso diretto, ricerca organica, assistente AI, social o campagna a pagamento — e a un fornitore predefinito. Non inviamo né conserviamo referrer o domini grezzi, parametri URL, nomi o termini di campagna, click ID o testo libero. Sul server la prima pagina viene accettata una sola volta per quell’identificatore e gli eventi sono eliminati secondo il termine indicato nell’informativa privacy.

Se la consegna di un evento interno consentito fallisce o il server risponde con un errore, la memoria temporanea della sola scheda può conservare per un massimo effettivo di 24 ore una coda di al massimo 32 eventi. Ogni voce contiene soltanto l’identificatore evento casuale usato per l’idempotenza, l’identificatore casuale della sessione, il nome evento e il percorso pubblico ammessi, le sole proprietà grossolane in liste predefinite, nonché versione e data del consenso. Non accetta testo o campi ulteriori. La coda viene eliminata al successo, alla scadenza, alla revoca o al rifiuto analytics, con Global Privacy Control o Do Not Track attivi, oppure quando è in corso il recupero di una revoca; la chiusura della scheda elimina comunque la memoria temporanea.

La stessa memoria temporanea conserva la bozza dell’onboarding, così puoi tornare dal pagamento senza reinserire i dati. Partita IVA e codice fiscale non vengono inclusi nella bozza. La bozza viene rimossa dopo la conferma del pagamento o alla chiusura della scheda.

Per impedire che modifiche, nuove schede o il cambio di data aprano due pagamenti per lo stesso ordine, salviamo inoltre nella memoria locale un identificatore casuale strettamente necessario. Non contiene dati del modulo; oltre all’idempotenza del checkout, può essere usato come ambito di soppressione per fasi analytics e Meta differite. Il puntatore corrente contiene identificatore, data di creazione, scadenza e gli eventuali indicatori booleani di revoca; una distinta copia di recupero sotto chiave casuale contiene anche la data tecnica di inserimento. Gli indicatori scompaiono con la sostituzione verificata di quell’esatto ordine. L’identificatore viene sostituito quando scegli “Avvia un nuovo report”, dopo una richiesta informativa accettata senza pagamento o dopo il ritorno da un pagamento confermato; la sostituzione non apre Stripe né annulla una sessione esistente. Prima di pubblicare un consenso, capacità locali con tipo, identificatore, scadenza, data tecnica ed eventuale epoca browser vengono lette nuovamente. Durante l’invio del modulo restano al massimo 16 autorizzazioni locali distinte con identificatore d’ordine, data di inserimento e scadenza fissa di 10 minuti: bloccano una rotazione concorrente e non si rinnovano.

Prima di aprire la pagina Stripe impostiamo inoltre un cookie tecnico essenziale con prefisso rinoma_checkout_return_, distinto per ogni tentativo, limitato al percorso della conferma, non accessibile agli script del browser e valido al massimo 30 minuti. Contiene soltanto la capacità con cui il server verifica la sessione Checkout e aggiorna lo stato dell’ordine; non viene usato per analytics o marketing. Nell’indirizzo di ritorno compare soltanto un identificatore tecnico opaco, privo di dati personali e inutilizzabile senza il cookie abbinato: l’identificativo della sessione Stripe non viene inserito nell’indirizzo.

Stripe può utilizzare tecnologie strettamente necessarie sulla propria pagina di pagamento per sicurezza, prevenzione delle frodi ed esecuzione della transazione. Consulta l’informativa di Stripe.