Utilizza solo i dati che ti servono

Un buon modo per ridurre i rischi per gli utenti è non conservare dati sensibili che non ti servono e che incidono sulla loro privacy. Ci sono molti modi per farlo, pur raggiungendo i tuoi obiettivi commerciali, e vale la pena considerarli tutti. Potresti:

  • Spiega per cosa ti servono i dati.
  • Raccogli i dati con una granularità inferiore.
  • Rimuovi i dati una volta utilizzati.
  • Non raccoglierli del tutto.

Ognuno di questi approcci può aiutare i tuoi utenti a sentirsi più a proprio agio con ciò che stai facendo e perché, con un grande contributo per migliorare il tuo rapporto con loro. La trasparenza crea fiducia e, soprattutto, può essere un tuo punto di forza. Molte persone ritengono che gli utenti e i clienti si fidino di loro per impostazione predefinita, ma i consumatori valutano costantemente prodotti e servizi e questo potrebbe non essere il caso. Se costruisci una relazione con i tuoi utenti in cui si fidano di te e della gestione dei loro dati e delle tue interazioni con rispetto, potresti ottenere un vantaggio competitivo per il progetto o per l'azienda: si tratta di un aspetto che i tuoi concorrenti potrebbero non corrispondere, un vero e proprio elemento di differenziazione.

Analizziamo gli approcci sopra descritti in ordine di efficacia (ma anche di maggiore impatto sulla tua attività) e meno efficaci, ma meno invasivi da implementare.

Non collezionarli prima di tutto

Il modo più ovvio per evitare di compromettere i dati degli utenti è non raccoglierli. La raccolta di dati è necessaria per fornire servizi, ma ci sono più modi in cui puoi evitarla di quanto pensi. Prendi in considerazione, ad esempio, il pagamento senza registrazione. Quando gli utenti acquistano qualcosa utilizzando la tua app web, potresti richiedere loro di creare un account. In seguito, hai acquisito i dettagli personali per l'evasione successiva: possono essere aggiunti alla mailing list, sono già prequalificati come clienti interessati e così via. Tuttavia, i clienti lo riconoscono e non ci piacciono: nel 2021, uno studio ha rilevato che una vendita su quattro abbandonata era dovuta al fatto che il sito richiedeva all'utente di creare un account. Se non hai bisogno di un account, è più probabile che questi clienti rimangano. Consentire agli utenti di completare un acquisto senza registrarsi offre agli utenti opzioni migliori e non ha molti dati da proteggere.

"Fuzz" i tuoi dati

Naturalmente, evitare del tutto la raccolta dei dati potrebbe non essere la soluzione. È importante raccogliere dati per fornire servizi e prendere decisioni aziendali sensate. Può essere utile anche creare comunicazioni di marketing nel contesto di un rapporto di fiducia. Tuttavia, è anche importante capire che le decisioni prese in forma aggregata (ovvero, che interessano molti utenti contemporaneamente) vengono prese sui dati in forma aggregata (ovvero sulle proprietà collettive dei dati).

Ad esempio, a volte è utile avere un'idea dei dati demografici del tuo pubblico: fascia di età a cui appartiene, località e così via. Questo potrebbe cambiare il tuo messaggio o il tuo approccio. Ma questo non significa che devi raccogliere l'età esatta per ogni utente del tuo servizio. Quello che cerchi spesso sono le tendenze e le proprietà generali. Se la decisione che vuoi raggiungere dipende dal fatto che la maggior parte del tuo pubblico appartenga al "gruppo demografico chiave di 18-34 anni", l'unica domanda che devi effettivamente porti è se i tuoi utenti appartengono a quel gruppo demografico. In questo modo i bucket vengono raggruppati in due "bucket": in quel gruppo e non in quel gruppo. Potrebbero verificarsi situazioni in cui hai bisogno di dati più granulari di questo, ma è del tutto ragionevole prendere delle decisioni prendendo l'elenco dei dati demografici che utilizzi per prendere decisioni e chiedere agli utenti di classificarsi con questo elenco.

Esempio

Pertanto, se ti è utile sapere in che modo la tua base utenti si divide nelle categorie "18-34", "35-49", "49-64" e "65+", puoi chiedere agli utenti di scegliere a quale categoria appartengono. Si è tentati di chiedere dati estremamente granulari, personali e personalizzati per poi classificare personalmente gli utenti, in modo da evitare di dover ripetere la stessa domanda in modo più dettagliato in seguito; ad esempio, chiedere l'età e la data di nascita esatte e poi utilizzare queste informazioni per generare i propri elenchi di quanti utenti rientrano nella categoria "35-49". Ma è importante capire che aspetto ha: poiché il corso è già stato trattato e tratterà di nuovo, chiedere livelli dettagliati di dati può mettere a disagio le persone e quindi riduce la fiducia degli utenti nella tua organizzazione, aumentando al contempo i rischi.

È anche importante considerare le tue esigenze di dati. A volte, la "necessità" di dati più granulari è speculativa, un requisito "solo nel caso". Forse per il momento dobbiamo solo classificare gli utenti in queste quattro fasce d'età, ma in futuro potremmo voler restringere questo limite e quindi dovremmo raccogliere dati molto dettagliati ora per tenere aperta questa opzione per un secondo momento. Potrebbe essere opportuno considerare con quale frequenza in passato sono stati effettivamente utilizzati dati più granulari per prendere decisioni. Chiedere dati percepiti come invasivi rispetto al servizio offerto si traduce necessariamente in una diminuzione del livello di fiducia degli utenti nella tua organizzazione. Se i dati vengono raccolti per motivi "solo per caso", potresti non limitarti a perdere la fiducia degli utenti per decisioni aziendali migliori, ma semplicemente scambiarli con la possibilità di una decisione teorica futura che potrebbero non esistere, rispettando al contempo i requisiti di sicurezza per quelle informazioni.

Esistono anche metodi algoritmici più dettagliati per ridurre la granularità dei dati raccolti. I metodi di risposta casuali indicano che i dati vengono raccolti con un grado di imprecisione regolabile e vengono utilizzati per decenni nelle scienze sociali per raccogliere dati potenzialmente invasivi o sensibili, mantenendo al contempo la riservatezza di chi risponde. Il suddetto metodo di raccolta dei dati comporta l'ampliamento delle risposte dell'utente (quindi "Quanti anni hai?" diventa "in quale delle seguenti fasce d'età rientri"), in cui la risposta randomizzata prevede che una determinata percentuale di utenti mentisca sulle proprie risposte. Se è nota la proporzione di utenti che rispondono in modo errato, è comunque possibile trarre conclusioni significative dai dati raccolti, ma la privacy dei singoli utenti non viene compromessa perché i dati raccolti potrebbero essere errati. In questo caso, se l'80% del tuo pubblico continua a dichiarare di rientrare nel gruppo demografico di 18-34 anni, puoi avere la certezza che si tratti ancora della quota maggiore, anche se il 10% di loro fornisce deliberatamente risposte errate. Il grado di inesattezze può anche essere modificato in modo programmatico, dove si richiedono sempre risposte corrette ma il software modifica una determinata percentuale di risposte prima di trasmettere. Questo processo e le relative conseguenze possono essere spiegati agli utenti quando vengono raccolti i dati: ciò significa che gli utenti non devono fidarsi del fatto che non abusate dei loro dati raccolti, perché i dati individuali sono inaffidabili.

Un processo simile, ma più tecnicamente coinvolto, è quello della privacy differenziale. Questo utilizza tecniche matematiche per modificare l'archiviazione dei dati in modo che le proprietà aggregate dei dati siano ancora presenti, ma non è nemmeno possibile dire se un determinato individuo ha persino fornito dati o quali dati ha fornito. Come per la risposta casuale, questa misura protegge i dati degli utenti anche da te e dimostra un chiaro intento da parte tua: non puoi utilizzare i dati degli utenti se non disponi di questi dati.

Questi approcci e altri approcci simili forniscono anche una maggiore sicurezza contro violazioni e fughe di dati, in quanto i dati raccolti riducono le compromissioni della privacy dell'utente, anche a te, e ridurranno anche il livello di compromissione in caso di divulgazione dei dati. Tuttavia, ricorda che se applichi tecniche di privacy differenziale sul server (in modo che i tuoi utenti ti inviino dati non aggregati e poi utilizzi le tecniche per aggregarli), devi comunque proteggere i dati utente non elaborati e poi eliminarli dopo l'elaborazione. Inoltre, devi avere e seguire norme chiare per confermare che non li usi prima dell'aggregazione (o che sia chiaro per cosa lo usi).

Conservazione: consente di raccogliere i dati e rimuoverli una volta utilizzati

È utile ricordare che i dati raccolti hanno un ciclo di vita: vengono raccolti, vengono utilizzati per aiutarti a prendere decisioni aziendali e, a un certo punto, dovrebbero essere rimossi. Si tratta, ancora una volta, di compromessi: quando fai domande agli utenti, memorizzi informazioni su altri siti web che hanno visitato oppure monitori gli aspetti che hanno visitato e per quanto tempo per fare previsioni sulle loro preferenze. Si tratta dei dati che ti vengono concessi per uno scopo specifico, non come donazione aperta che lo sviluppatore può usare come meglio credono. Quando quei dati non sono più necessari per questo scopo, a volte dopo un minuto o dopo molti anni, dovrebbero essere eliminati.

Ogni volta che raccogli informazioni sui tuoi utenti, devi sapere per cosa utilizzerai tali dati (vedi di seguito), nonché quando e perché smetterai di conservarli. ad esempio quando l'utente sceglie di eliminarlo, quando si disconnettono, dopo un determinato periodo di tempo o dopo che si è verificato un evento specifico. Un modo eccellente per creare fiducia nella relazione è chiarire agli utenti come possono controllare i loro dati, inclusa, ove possibile, una disattivazione unilaterale. Come fanno a eliminare i propri dati? Come fanno a eliminare il proprio account? Oltre a favorire la creazione di questa relazione, la best practice prevede di archiviare i dati per tutto il tempo necessario a elaborarli e per non più tempo e che gli utenti abbiano un modo di visualizzare e rimuovere i dati che raccogli da loro o per loro conto. Potrebbe esistere persino una legislazione al riguardo nei territori in cui operi.

In questa è un'area in cui puoi definire obiettivi tecnici chiari, che aiutano gli utenti con il self-service. Se i tuoi utenti possono disattivare il data warehouse senza dover chiedere l'autorizzazione, si sentiranno molto più a proprio agio con l'attivazione e non saranno necessarie risorse di assistenza per farlo.

È importante riconoscere l'importanza di una disattivazione semplice e predefinita: "Per creare fiducia e riconoscimento, le aziende possono iniziare accettando un contratto sociale in cui si impegnano a rispettare il proprio pubblico in ogni singolo touchpoint, ascoltando le loro esigenze e rispondendo di conseguenza", afferma IAPP. Secondo Nielsen Norman Group, gli utenti "hanno bisogno di un'uscita di emergenza chiaramente contrassegnata per evitare l'azione indesiderata senza dover eseguire un processo esteso". Tutti sanno che è più facile iscriversi che annullare l'iscrizione. Tuttavia, come afferma Nielsen Norman, offrire agli utenti la possibilità di fuggire senza dover fare salti da gigante, "promuove un senso di libertà e sicurezza". Studi accademici lo confermano e lo definiscono il "principio di revoca", dichiarando: "L'interfaccia deve consentire all'utente di revocare facilmente le autorità concesse dall'utente ovunque sia possibile la revoca. Gli utenti dovrebbero essere in grado di revocare questo consenso e quindi ridurre le autorità ad accedere alle loro risorse, se possibile." Vedi Yee e Iacono per alcuni esempi.

Il tempo e i dati da conservare sono un argomento molto diverso da un'organizzazione all'altra e da un progetto all'altro; tuttavia, ci sono alcune linee guida comuni da considerare.

Che cosa fare

È utile consentire agli utenti di eliminare gli account (e tutti i dati associati, se possibile) e di cancellare regolarmente (ad esempio all'uscita) i dati temporanei e memorizzati localmente all'uscita con l'intestazione Clear-Site-Data.

Fornisci un'intestazione Clear-Site-Data per rimuovere alcuni o tutti i dati utente archiviati sul lato client (nei cookie, in localStorage o IndexedDB oppure nella cache del browser), quando è ragionevole. Il caso d'uso più ovvio di Clear-Site-Data è quando un utente si disconnette, ma può essere utilizzato anche dopo gli incidenti di sicurezza, per garantire che un account potenzialmente compromesso non abbia tracce persistenti di dati compromessi archiviati sul client.

L'aggiunta del supporto per Clear-Site-Data comporta l'invio di un'intestazione HTTP, Clear-Site-Data, quando l'utente esce (o in altri momenti in cui vuoi liberare lo spazio di archiviazione lato client) sulla pagina che conferma lo stato di disconnessione (https://your-site/logout o simile). Questa intestazione può avere alcuni o tutti i seguenti valori oppure "*" per tutti:

Clear-Site-Data: "cache", "cookies", "storage"

Questi valori cancellano, rispettivamente, le pagine memorizzate nella cache (e altre risorse memorizzate nella cache HTTP), i cookie archiviati, localStorage, IndexedDB e simili. Potresti vedere un riferimento a un'altra opzione, executionContexts, che però non è supportata da molti browser. Tieni presente che l'utilizzo dell'intestazione Clear-Site-Data è probabilmente più semplice rispetto all'eliminazione automatica di tutte le risorse create, poiché non richiede l'esecuzione di codice JavaScript sul client (ed è l'unico modo ufficiale per svuotare la cache del browser), ma non è supportato da tutti i browser.

Nota di utilizzo: se svuota la cache (inviando Clear-Site-Data: cache), l'intestazione Clear-Site-Data non dovrebbe essere inviata nella pagina di uscita effettiva, ma la pagina viene caricata in altre risorse. Questo perché su un computer più lento con una cache di grandi dimensioni la pagina si blocca mentre svuota la cache ed impedisce la navigazione. Questa operazione può richiedere alcuni minuti e frustrazione degli utenti. È improbabile che ciò accada, ma è difficile da testare e quindi è buona norma tenerlo a mente.

Spiega per cosa servono i dati

L'importanza della fiducia nella relazione degli utenti con il servizio è stata ripetuta più volte, perché ne aumenta la longevità. Inoltre, offre un vantaggio competitivo. Un modo per aumentare questo livello di fiducia è la trasparenza dei processi, mentre un buon modo per essere trasparenti è spiegare per cosa vuoi i dati. In precedenza hai imparato che per ogni elemento raccolto devi sapere quando verrà eliminato. Per saperlo, devi sapere perché vuoi questi dati, per quali domande specifiche ne hanno bisogno per trovare le risposte e quali decisioni verranno guidate dalla loro raccolta. Una volta stabilito il motivo per cui hai bisogno di questi dati che hai chiesto all'utente di rinunciare, contribuisce a instaurare un rapporto di fiducia spiegandogli a questi utenti. Nelle norme sulla privacy o quando fai domande sulla creazione dell'account, descrivi perché hai bisogno di rispondere a questa domanda specifica, cosa farai con i dati e quando e come possono essere rimossi.

Queste spiegazioni sono molto più visibili quando sono presentate in linea. Seppellire le spiegazioni in un fitto documento di norme altrove sul sito web può sembrare un tentativo di nasconderle. Un modulo di registrazione, pagamento o richiesta può indicare i motivi per cui raccogliere dati insieme alla raccolta stessa. Spesso, un campo di un modulo può avere un asterisco (*) per indicare che un campo è obbligatorio; i moduli complicati spesso hanno un link alle informazioni (i) che spiega il significato dei campi. Ti consigliamo di aggiungere a queste spiegazioni una descrizione del motivo per cui i dati vengono raccolti. Una frase di uso frequente è "Perché ne abbiamo bisogno?" accanto al campo di un modulo. Se l'utente fa clic sul pulsante, viene visualizzata una spiegazione popup.

Alcuni esempi di codice HTML potrebbero avere il seguente aspetto: CSS e JavaScript si occuperanno di nascondere <aside> e di mostrarlo come popup quando viene fatto clic sul link. Assicurati di verificare l'accessibilità del modulo che crei per il tuo sito. La modalità esatta di calcolo dipende dagli stili e dagli approcci, ma l'aspetto principale è associare direttamente la raccolta dei dati a una spiegazione del motivo per cui i dati vengono raccolti. Non è necessario per tutti i campi. Nessuno ha bisogno di spiegazioni sul motivo per cui si richiede la scelta di una password al momento della registrazione. Tuttavia, decorare ogni richiesta di dati personali e di contatto indicando il modo in cui intendi utilizzarli e conservarli può aiutare a chiarire agli utenti che hai investito nella protezione dei loro dati.

<div>
    <label for="email">Email address*</label>
    <input id="email" type="email" name="email" required aria-describedby="whyemail">
    <a href="#whyemail">Why do we need this?</a>
    <aside id="whyemail">We need this information as a unique identifier for you, and if you forget your password we can send you a reminder. We will use your email address to send you regular updates on the service if you choose, and will delete your email address from any mailing lists if you delete your account.</aside>
</div>

Completare questa procedura con tutto ciò che raccogli su un utente può essere utile anche per le discussioni e i processi interni. In precedenza hai visto come potrebbe esserci la tentazione di raccogliere dati "per ogni evenienza". Se spieghi in modo trasparente i motivi per cui raccogliere i contenuti, può essere chiaro che sta succedendo. Se sei riluttante a scrivere pubblicamente cosa vuoi fare con i dati utente perché a questi utenti la spiegazione non piace, questo potrebbe indicare che vale la pena riconsiderare la raccolta dei dati. Ciò vale se la spiegazione sgradevole è troppo invasiva ("lo useremo per tenere traccia dei luoghi che visiti ogni ora"), troppo ampia ("Non sappiamo per cosa la useremo, ma vogliamo farlo nel caso in cui dovessimo trovare qualcosa a sua disposizione") o troppo evasiva ("lo utilizzeremo per scopi interni non comunicati"). Non si tratta solo di una questione di moralità; le persone sono abbastanza esperti da riconoscerlo, come già descritto, e gli utenti si aspettano che sperimentare qualcosa non sia l'inizio di un impegno a lungo termine. Poiché la progettazione dell'esperienza utente è molto comune per semplificare il più possibile la procedura di registrazione, poiché nelle fasi iniziali l'utente non è (per definizione) molto coinvolto nel servizio, è importante fare in modo che gli utenti investano più facilmente quando non sono in grado di farlo. Come prima, è paradossale ma vero che il modo migliore per instaurare un clima di fiducia è non obbligare gli utenti a fidarsi di te se non vogliono.

Le persone hanno buone ragioni per non condividere dati o per condividere solo una quantità minima di dati. All'inizio del rapporto con loro, potrebbero non avere un motivo per fidarsi di te, e non dovrebbero esserlo. Il tuo obiettivo è dimostrare perché dovrebbero farlo.

Che cosa fare

  • Scegli quali dati vuoi raccogliere e per quanto tempo li conserverai.
  • Quando chiedi questi dati, spiega agli utenti il motivo per cui li raccogli.
  • Eliminalo dai database del tuo server dopo averlo utilizzato.
  • Consenti agli utenti di eliminare gli account creati da loro e di cancellare i dati archiviati dal loro spazio di archiviazione con l'intestazione Clear-Site-Data.

Perché

Costruire un rapporto con gli utenti implica la fiducia, mentre la fiducia riguarda l'apertura. Se riesci a dimostrare che non stai solo raccogliendo il maggior numero possibile di dati sui tuoi utenti e nascondendo i relativi usi, ciò ti aiuterà a instaurare un rapporto di fiducia, che può essere un vantaggio competitivo per te rispetto a rivali meno scrupolosi.