Use apenas os dados de que você precisa

Uma boa maneira de reduzir riscos para os usuários é não manter dados sensíveis sobre eles que você não precisa e que afetem a privacidade deles. Há uma quantidade surpreendente de maneiras de fazer isso e, ao mesmo tempo, atingir suas metas de negócios, e vale a pena considerar todas elas. Faça o seguinte:

  • Explique para o que você precisa dos dados.
  • Coletar dados com granularidade mais baixa.
  • Remova os dados depois que eles forem usados.
  • Não coletá-lo em primeiro lugar.

Cada uma dessas abordagens pode ajudar seus usuários a se sentirem mais confortáveis com o que você faz e por quê, e isso contribui muito para seu relacionamento com eles. Transparência gera confiança e, o mais importante, confiança pode ser um ponto de venda único para você. Muitas pessoas supõem que os usuários e clientes confiam neles por padrão, mas os consumidores estão constantemente avaliando produtos e serviços, e esse pode não ser o caso. Se você criar uma relação com seus usuários em que eles confiam em você para lidar com os dados deles e suas interações com respeito, pode oferecer uma vantagem competitiva para seu projeto ou empresa: é algo que seus concorrentes podem não corresponder, um diferencial genuíno.

Vamos analisar as abordagens acima em ordem de implementação: da mais eficiente (mas também impactante) para a menos eficaz, mas menos disruptiva.

Não colete-o.

A maneira mais óbvia de não comprometer os dados dos seus usuários é não coletá-los. Algumas coletas de dados são necessárias para fornecer serviços, mas há mais lugares em que você pode evitar a coleta de dados do que você imagina. Considere, por exemplo, a opção de comprar sem login. Quando os usuários compram algo usando seu app da Web, você pode exigir que eles se inscrevam em uma conta porque assim você já capturou dados pessoais para mais tarde: eles podem ser adicionados à lista de e-mails, já estão pré-qualificados como clientes interessados e assim por diante. No entanto, os clientes reconhecem e não gostam disso: em 2021, um estudo descobriu que uma em cada quatro vendas abandonadas ocorre porque o site exigia que o usuário criasse uma conta. Se você não precisar de uma conta, a probabilidade de manter esses clientes será maior. Possibilitar a conclusão de uma compra sem se inscrever oferece melhores opções aos usuários e também significa que você não tem muitos dados para proteger.

"Fuzz" seus dados

Obviamente, evitar a coleta de dados pode não ser uma opção. É importante coletar dados para fornecer serviços e tomar decisões de negócios sensatas. Também pode ser útil criar comunicações de marketing no contexto de uma relação de confiança. No entanto, também é importante perceber que as decisões tomadas de maneira agregada (ou seja, que afetam muitos usuários de uma vez) são tomadas sobre dados agregados (ou seja, sobre propriedades coletivas dos dados).

Por exemplo, às vezes é útil conhecer as informações demográficas do seu público: em que faixas etárias eles se enquadram, localização e assim por diante. Isso pode mudar sua mensagem ou abordagem. Mas isso não significa que você precisa coletar a idade exata de cada usuário do serviço. O que você procura com frequência são tendências e propriedades gerais. Se a decisão que você quer alcançar é afetada pela maior parte do seu público-alvo ser do "grupo demográfico principal de 18 a 34 anos", a única pergunta que você precisa fazer é se os usuários fazem parte desse grupo demográfico. Isso os reúne em dois "buckets": nesse grupo e não nesse grupo. Pode haver situações em que você precise de dados mais granulares do que isso, mas é totalmente razoável pegar a lista de informações demográficas que você usa para tomar decisões e pedir que seus usuários se classifiquem com essa lista.

Exemplo

Portanto, se for útil saber como sua base de usuários se divide entre as categorias de idade "18 a 34", "35 a 49", "49 a 64" e "65+", peça aos usuários que escolham em qual dessas categorias se enquadram. É tentador solicitar dados extremamente granulares, pessoais e personalizados e classificar seus usuários por conta própria, já que isso evita a necessidade de fazer a mesma pergunta novamente com mais detalhes posteriormente. Por exemplo, solicitar idade e data de nascimento exatas e usar essas informações para produzir suas próprias listas de quantos usuários estão na categoria "35 a 49". No entanto, é importante perceber como isso funciona: como o curso já foi abordado e abordará novamente, solicitar níveis detalhados de dados pode deixar as pessoas desconfortáveis e reduzir a confiança do usuário em sua organização, além de aumentar o risco.

Também é importante considerar suas necessidades de dados. Às vezes, a "necessidade" de dados mais granulares é especulativa, um requisito apenas por caso. Talvez só precisemos classificar usuários nessas quatro faixas etárias, mas no futuro podemos querer restringir isso e, portanto, devemos coletar dados muito detalhados agora para manter essa opção aberta para mais tarde. Pode valer a pena considerar a frequência com que os dados mais granulares foram realmente usados no passado para orientar as decisões. Pedir dados considerados invasivos em relação ao serviço oferecido necessariamente resulta em uma diminuição do nível de confiança dos usuários na organização. Se esses dados estiverem sendo coletados por motivos "apenas por precaução", talvez você não esteja apenas trocando a confiança do usuário por melhores decisões de negócios, mas apenas trocando-os pela possibilidade de alguma decisão teórica futura que pode não existir e que, ao mesmo tempo, aceite requisitos de segurança para essas informações.

Há maneiras mais detalhadas de reduzir a granularidade dos dados coletados. Métodos de resposta aleatórios significam que os dados são coletados com um grau ajustável de imprecisão e têm sido usados há décadas nas ciências sociais na coleta de dados potencialmente invasivos ou sensíveis, mantendo a confidencialidade do respondente. O método de coleta de dados acima envolve ampliar as respostas do usuário (de modo que "quantos anos você tem" se torna "em qual das seguintes faixas etárias você se enquadra"), em que a resposta aleatória envolve ter uma certa proporção de usuários sobre as respostas. Se a proporção de usuários que responderam incorretamente for conhecida, conclusões significativas ainda poderão ser tiradas dos dados coletados, mas a privacidade do usuário individual não será comprometida porque os dados coletados podem estar incorretos. Nesse caso, se 80% do seu público ainda afirma que se enquadra na faixa etária de 18 a 34 anos, você pode estar relativamente confiante de que essa ainda é a maior parcela, mesmo que 10% deles estejam deliberadamente fornecendo respostas incorretas. O grau de incorreção também pode ser alterado de maneira programática, quando respostas corretas são sempre solicitadas, mas o software altera uma determinada porcentagem das respostas antes da transmissão. Esse processo e as consequências dele também podem ser explicados aos usuários quando os dados são coletados: significa que os usuários não precisam confiar que você não vai abusar dos dados coletados, porque os dados individuais não são confiáveis.

Um processo semelhante, mas mais tecnicamente envolvido é a privacidade diferencial. Esse método usa técnicas matemáticas para alterar o armazenamento de dados para que as propriedades agregadas dos dados ainda estejam presentes, mas não é possível saber se um indivíduo específico até forneceu dados ou se foram fornecidos. Assim como a resposta aleatória, ela protege os dados dos usuários até mesmo contra você e demonstra uma intenção clara da sua parte: não é possível usar os dados dos usuários se eles não estiverem disponíveis.

Essas e abordagens semelhantes também oferecem maior segurança contra violações e vazamentos de dados, já que os dados coletados reduzem os comprometimentos à privacidade do usuário, até mesmo a você, e também o nível de comprometimento se os dados vazarem. No entanto, se você estiver aplicando técnicas de privacidade diferencial no servidor (para que seus usuários enviem dados não agregados e você use as técnicas para agregá-los), ainda será necessário proteger esses dados brutos do usuário e excluí-los após o processamento. Além disso, é necessário ter e seguir políticas claras para confirmar que você não as está usando antes da agregação (ou para que você está usando esses dados).

Retenção: colete e remova dados depois que eles forem usados

É útil lembrar que os dados coletados têm um ciclo de vida: eles são coletados, usados para ajudar você a tomar decisões de negócios e, em algum momento, precisam ser removidos. Elas são, novamente, compensações: quando você faz perguntas aos usuários, armazena informações sobre outros sites visitados ou rastreia quais itens eles acessaram e por quanto tempo para fazer previsões sobre as preferências deles, esses dados são concedidos a você para uma finalidade específica, não como uma concessão aberta para que o desenvolvedor use como achar melhor. Quando esses dados não são mais necessários para esse propósito, às vezes depois de um minuto ou depois de muitos anos, eles precisam ser excluídos.

Ao coletar informações sobre seus usuários, é preciso saber para que você vai usar esses dados (confira abaixo) e saber quando e por que parar de armazená-los. Isso pode acontecer quando o usuário opta por excluí-la ou ao sair, após um período específico ou após a ocorrência de um evento específico. Uma excelente maneira de criar confiança na relação é esclarecer aos usuários como eles podem controlar os dados sobre eles, incluindo, sempre que possível, uma recusa unilateral. O que é preciso fazer para excluir os dados? O que ele deve fazer para excluir a conta? Além de ajudar a construir essa relação, é uma prática recomendada armazenar dados pelo tempo que for necessário processá-los e não mais, e que deve haver uma maneira de seus usuários verem e removerem os dados que você coleta deles ou em nome deles. Pode até mesmo haver legislação sobre esse ponto nos territórios em que você opera.

Nessa área, é possível definir metas técnicas claras, o que ajuda os usuários com o autoatendimento. Se eles puderem desativar o data warehouse sem precisar pedir permissão, eles se sentirão muito mais confortáveis e não precisarão de recursos de suporte para isso.

É importante reconhecer a importância de recusas fáceis e padrão: "Para gerar confiança e reconhecimento, as empresas podem começar com um contrato social em que se comprometem a respeitar o público em cada ponto de contato, atender às necessidades e responder de acordo", afirma a IAPP. Segundo o Nielsen Norman Group, os usuários "precisam de uma "saída de emergência" claramente marcada para sair da ação indesejada sem ter que passar por um processo estendido. Todos sabem que é mais fácil assinar do que cancelar. No entanto, como diz Nielsen Norman, oferecer aos usuários a capacidade de escapar sem ter que passar pelos obstáculos, "promove uma sensação de liberdade e confiança". Estudos acadêmicos apoiam isso e dão a isso o nome de "princípio da revogabilidade", afirmando: "A interface precisa permitir que o usuário revogue facilmente as autoridades concedidas pelo usuário sempre que possível a revogação. Os usuários precisam ter a opção de revogar esse consentimento e, assim, reduzir o acesso das autoridades aos recursos se possível." Consulte Yee e Iacono para ver alguns exemplos.

O período de retenção de dados e quais dados devem ser retidos é um assunto que difere muito entre organizações e projetos, mas há algumas diretrizes comuns a serem consideradas.

O que fazer

Aqui, é útil permitir que os usuários excluam contas (e quaisquer dados associados, quando possível) e que limpem regularmente (por exemplo, ao sair) os dados temporários e armazenados localmente ao sair com o cabeçalho Clear-Site-Data.

Forneça um cabeçalho Clear-Site-Data para remover alguns ou todos os dados do usuário armazenados no lado do cliente (em cookies, localStorage, IndexedDB ou no cache do navegador), quando razoável. O caso de uso óbvio para o Clear-Site-Data é quando um usuário faz logout, mas também pode ser usado após incidentes de segurança para garantir que uma conta potencialmente comprometida não tenha rastreamentos persistentes de dados comprometidos armazenados no cliente.

Adicionar suporte a Clear-Site-Data envolve o envio de um cabeçalho HTTP, Clear-Site-Data, quando o usuário sair (ou outras vezes em que você quiser limpar o armazenamento do lado do cliente) na página que confirma o status de logout (https://your-site/logout ou semelhante). Esse cabeçalho pode ter alguns ou todos os valores a seguir ou "*" para todos:

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

Esses valores limpam, respectivamente, páginas em cache (e outros recursos HTTP armazenados em cache), cookies armazenados e localStorage, IndexedDB e similares. Você pode ver referência a outra opção, executionContexts, mas ela não é compatível com muitos navegadores. Usar o cabeçalho Clear-Site-Data provavelmente será mais fácil do que excluir individualmente todos os recursos criados, porque ele não exige que o código JavaScript seja executado no cliente (e é a única maneira oficial de limpar o cache do navegador), mas não é compatível com todos os navegadores.

Observação de uso: se você estiver limpando o cache (enviando Clear-Site-Data: cache), o cabeçalho Clear-Site-Data não deve ser enviado na página real de saída, mas em algum outro recurso a página é carregada. Isso ocorre porque, em um computador mais lento com um cache grande, a página será bloqueada enquanto limpa o cache, impedindo a navegação. Isso pode levar minutos, o que vai frustrar o usuário. É improvável que isso aconteça, mas é difícil de testar. Portanto, é uma prática recomendada ter isso em mente.

Explique para o que você precisa dos dados

A importância da confiança no relacionamento dos usuários com seu serviço foi mencionada repetidamente, porque aumenta a longevidade do usuário. Também proporciona vantagem competitiva. Uma maneira de aumentar esse nível de confiança é com a transparência de seus processos, e uma boa maneira de ser transparente é explicar para que você quer dados. Você aprendeu anteriormente que para cada item coletado, você deve saber quando o item será excluído. Para saber isso, você precisa saber por que quer esses dados, quais perguntas específicas precisam deles para encontrar respostas e quais decisões serão orientadas pela coleta deles. Depois de saber por que você precisa desses dados dos quais você pediu para o usuário desistir, será útil explicar isso a esses usuários para gerar confiança. Na sua Política de Privacidade ou ao fazer perguntas sobre a criação da conta, descreva por que você precisa de uma resposta para essa pergunta específica, o que você fará com esses dados e quando e como eles podem ser removidos.

Essas explicações são muito mais visíveis quando apresentadas inline. Ocultar explicações em um denso documento de política em outro lugar do site pode parecer uma tentativa de ocultá-las. Um formulário de inscrição, finalização de compra ou solicitação pode apresentar os motivos para coletar dados junto com a própria coleção. Muitas vezes, um campo de formulário pode ter um asterisco (*) para indicar que ele é obrigatório. Formulários complicados geralmente têm um link de informações (i) para explicar o que o campo significa. Considere adicionar a essas explicações uma descrição do motivo pelo qual os dados estão sendo coletados. Uma frase usada com frequência é "Por que precisamos disso?" ao lado de um campo de formulário, que, quando clicado, mostra uma explicação em pop-up.

Alguns exemplos de HTML podem ter a seguinte aparência, e o CSS e o JavaScript ocultariam o <aside> e o mostrariam como um pop-up quando o link fosse clicado. Confirme a acessibilidade do formulário que você criou para seu site. A maneira exata como fazê-lo depende dos seus estilos e abordagens, mas o ponto principal aqui é associar diretamente a coleta de dados a uma explicação do motivo pelo qual esses dados estão sendo coletados. Isso não é necessário para todos os campos. Ninguém precisa de uma explicação sobre por que é necessário escolher uma senha no momento da inscrição. No entanto, decorar cada solicitação de dados pessoais e de contato com a forma como você planeja usá-los e mantê-los pode ajudar a deixar claro para os usuários que você investe na proteção dos dados deles.

<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>

Passar por esse processo com tudo o que você coletar sobre um usuário também pode ajudar em processos e discussões internos. Anteriormente, você viu como pode haver a tentação de coletar dados "por precaução". Quando você é transparente sobre os motivos para a coleta, pode ser bastante óbvio que isso está acontecendo. Se você estiver relutante em anotar publicamente o que quer fazer com os dados do usuário porque ele não vai gostar da explicação, isso pode ser um sinal de que vale a pena repensar a coleta de dados. Isso se aplica se a explicação desagradável for muito invasiva ("usaremos isso para rastrear onde você visita a cada hora"), ampla demais ("não sabemos para o que vamos usar isso ainda, mas queremos que isso seja feito caso pensemos em algo para isso") ou muito evasiva ("vamos usar isso para fins internos não divulgados"). Isso não é simplesmente uma questão de moralidade. As pessoas são inteligentes o suficiente para reconhecer isso, como já descrito, e há a expectativa dos usuários de que fazer experimentos com algo não é o início de um compromisso a longo prazo. É comum no design de experiência do usuário tornar a inscrição o mais simples e sem atrito possível, porque, nos estágios iniciais, o usuário (por definição) não investe muito no seu serviço. Por isso, é importante permitir que eles se envolvam mais facilmente quando ainda têm pouca inclinação a fazer isso. Se for tão fácil sair novamente, testar o serviço será um compromisso a longo prazo, e não um compromisso não intencional. Como antes, é paradoxal, mas verdade que a melhor maneira de gerar confiança é não exigir que os usuários confiem em você se não quiserem.

As pessoas têm boas razões para não compartilhar dados ou para compartilhar mínimos dados. No início do seu relacionamento com essa pessoa, ela pode não ter um motivo para confiar em você e não deveria ter. Seu objetivo é demonstrar por que eles deveriam.

O que fazer

  • Decida todos os dados que você planeja coletar, por que você os deseja e por quanto tempo os manterá.
  • Ao solicitar esses dados, explique aos usuários por que você os está coletando.
  • Exclua-o dos bancos de dados do servidor depois de usá-lo.
  • Use o cabeçalho Clear-Site-Data para permitir que os usuários excluam contas que criaram e limpe os dados armazenados no armazenamento.

Por quê?

Criar uma relação com seus usuários é sobre confiança, e confiança é sobre abertura. Se você conseguir demonstrar que não está apenas coletando o máximo possível de dados sobre seus usuários e ocultando seus usos para eles, isso ajudará a criar confiança, o que pode ser uma vantagem competitiva sobre seus concorrentes menos escrupulosos.