Analítica conforme o RGPD sem cookies: o que construímos e porque não há banner

A analítica conforme o RGPD sem cookies só é possível quando não se recolhem dados pessoais nem se grava qualquer identificador no dispositivo do visitante. Acerte nestes dois pontos e a base legal para um banner de cookies desaparece — não há nada a consentir. É este o caminho que seguimos em todos os sites que lançamos, incluindo este. A seguir explicamos exatamente o que isto significa, o que se pode e não se pode medir, e o tracker first-party que construímos para nos mantermos do lado certo da linha.

O que significa realmente "analítica conforme o RGPD sem cookies"

A expressão é usada de forma vaga, por isso vamos defini-la. A analítica é verdadeiramente sem cookies e isenta de consentimento quando satisfaz, em simultâneo, dois testes legais independentes:

• O teste da ePrivacy (a lei dos cookies). O artigo 5.º, n.º 3, da Diretiva ePrivacy — a tal "lei dos cookies" — regula o armazenamento ou a leitura de informação no dispositivo do utilizador. Não se limita aos cookies. Abrange localStorage, IndexedDB, fingerprinting do dispositivo e qualquer equivalente. Se não escrever nem ler no dispositivo nada que não seja estritamente necessário para entregar a página pedida, fica fora do artigo 5.º, n.º 3, e não precisa de consentimento.
• O teste do RGPD (a lei dos dados pessoais). O RGPD regula o tratamento de dados pessoais — tudo o que possa identificar uma pessoa direta ou indiretamente, incluindo um endereço IP (o TJUE decidiu-o no acórdão Breyer, C-582/14). Se não tratar dados pessoais, todo o mecanismo de consentimento e base de licitude do RGPD deixa, em larga medida, de se aplicar.

Passe nos dois e conquistou aquilo que toda a equipa de marketing secretamente deseja: sem banner, sem fluxo de consentimento e com analítica que continua a funcionar para 100% dos visitantes em vez dos ~60% que clicam em "aceitar". A maioria das ferramentas "sem cookies" do mercado passa no primeiro teste e falha discretamente no segundo, porque continua a fazer hash de um IP e de um user agent para gerar um ID de visitante diário. Isso é um identificador derivado do dispositivo e, pelo raciocínio do Breyer, é muito provavelmente um dado pessoal.

A versão curta

• Sem cookies, sem localStorage, sem fingerprint. Não escrevemos nada no dispositivo, logo o artigo 5.º, n.º 3, não se aplica.
• Sem dados pessoais, sem armazenamento de IP, sem ID entre sites. Não tratamos dados pessoais, logo a questão do consentimento do RGPD nunca surge.
• Um beacon anónimo por visualização de página, guardado first-party no nosso próprio servidor. Nenhum terceiro vê o visitante.
• Resultado: sem banner de cookies e contagens que cobrem todos os visitantes, não um subconjunto que consentiu.

O que se pode medir sem cookies (e o que não se pode)

Aqui a honestidade importa mais do que o argumento de venda, porque o compromisso é real. A analítica sem cookies e sem identificadores é apenas agregada. Está a contar eventos, não a seguir pessoas.

O que pode responder com clareza:

• Quantas visualizações teve /work ontem, esta semana, este mês.
• Quais os caminhos mais populares e a forma aproximada do tráfego ao longo do tempo.
• De onde vêm as visitas ao nível da origem — google.com, linkedin.com, direto — e não o URL de referência completo com a sua query string.
• Contexto grosseiro do dispositivo: escalão de largura da viewport, idioma preferido. O suficiente para saber se o layout móvel importa.

O que não pode responder, e não deve fingir que responde:

• Visitantes únicos e recorrentes. Não há um ID estável, por isso "únicos" não é um número que se possa produzir honestamente. Quem lhe vende "visitantes únicos" sem cookies está a reconstruir um identificador algalgures.
• Funis de vários passos ligados a uma pessoa. Pode contar quantas sessões chegaram ao passo 1 e ao passo 2; não pode provar que foi o mesmo ser humano a percorrer o caminho.
• Percursos entre dispositivos ou entre sites. Desaparecem por desenho. É esse precisamente o objetivo.

Para um site de estúdio, um site de marketing, um portefólio ou a maioria dos negócios de conteúdo, a visão agregada chega para decidir. Se o seu modelo de negócio precisar genuinamente de atribuição por utilizador — um funil de e-commerce de alta velocidade, por exemplo — então precisa de consentimento, e deve pedi-lo com honestidade através de um banner verdadeiro em vez de disfarçar o tracking de "privacy-first". Foi exatamente isto que dissemos à Delicious Diamonds para os seus fluxos de comércio exclusivos a membros: o site de marketing público corre sem cookies, e o percurso de compra autenticado usa dados de sessão first-party que o cliente já aceitou ao iniciar sessão.

Como o construímos: um beacon, nenhuma identidade

A nossa stack é deliberadamente aborrecida — PHP 8.3 em alojamento partilhado, Cloudflare à frente, sem build step, renderizada no servidor. O tracker segue essa filosofia. Não há script de terceiros, nem SDK, nem dependência npm. São umas linhas de JavaScript puro e um endpoint PHP.

O cliente dispara um único POST cerca de três segundos após o carregamento (tempo suficiente para ignorar a maioria das saídas e dos bots) e esquece que alguma vez aconteceu:

// sem cookies, sem localStorage, sem identidade
navigator.sendBeacon('/api/hit', JSON.stringify({
  path: location.pathname,
  referrer_origin: document.referrer
    ? new URL(document.referrer).origin
    : null,
  lang: navigator.language.slice(0, 2),
  screen_w: window.innerWidth,
  ts: Date.now()
}));

Leia esta carga com atenção, porque a garantia de privacidade vive naquilo que está ausente. Não há user agent. Não há IP — e, crucialmente, o servidor está configurado para nunca registar nem persistir o IP de ligação nestes pedidos. Não há UUID, nem hash de coisa nenhuma, nem token de sessão. referrer_origin retira deliberadamente o caminho e a query string do referrer, por isso ficamos a saber que veio do LinkedIn mas não de que publicação ou de que rasto de UTM. O idioma é truncado a dois caracteres. Nenhum destes campos, sozinho ou combinado, individualiza uma pessoa.

No servidor, o endpoint acrescenta uma linha de JSON a um ficheiro mensal:

// /api/hit -- apenas append, sem IP, sem identidade
$line = json_encode([
    'path'     => $clean['path'],
    'ref'      => $clean['referrer_origin'],
    'lang'     => $clean['lang'],
    'w'        => (int) $clean['screen_w'],
    't'        => time(),
]) . "\n";

file_put_contents(
    __DIR__ . '/../storage/hits/' . date('Y-m') . '.jsonl',
    $line,
    FILE_APPEND | LOCK_EX
);

O diretório storage/hits/ está fechado ao nível do servidor web com um .htaccess que leva Require all denied, por isso os logs em bruto nunca são acessíveis por HTTP. Um pequeno painel em PHP, protegido por autenticação básica HTTP, lê esses ficheiros JSON-lines, agrega por dia e mostra seis números e um gráfico de barras. Tudo corre no servidor; nenhum dado sai da nossa infraestrutura e nenhum terceiro — nem Google, nem fornecedor de analítica — toca no visitante.

Porque é que isto significa não haver banner de cookies

Voltemos aos dois testes.

Artigo 5.º, n.º 3: não guardamos nada no dispositivo e não lemos nada de volta. O sendBeacon é um pedido HTTP de disparar-e-esquecer; não define cookie e não toca em armazenamento. Não há "acesso a informação armazenada no equipamento terminal", logo a exigência de consentimento da lei dos cookies não é acionada. Não há nada a perguntar.

RGPD: não tratamos dados pessoais. Nenhum IP é guardado, nenhum identificador é derivado, e nenhum dos campos retidos — um caminho, uma origem de referência, um idioma de duas letras, uma largura de viewport, um carimbo temporal — identifica uma pessoa singular, individualmente ou em combinação. Sem dados pessoais no âmbito, não há base de licitude do artigo 6.º a estabelecer nem consentimento a recolher.

Dois testes passados, zero banners necessários. A conclusão jurídica não é um truque esperto; é a consequência direta de não haver, genuinamente, nada a declarar. O banner existe para obter consentimento para o armazenamento e para o tratamento de dados pessoais. Não faça nenhum dos dois e o banner deixa de ter função.

Perguntas frequentes

O Google Analytics pode alguma vez ser conforme o RGPD sem banner?

Não. O GA4 define cookies e trata identificadores e dados derivados do IP, o que aciona tanto o teste ePrivacy como o do RGPD. Exige consentimento na UE, e várias autoridades de proteção de dados (Áustria, França, Itália) declararam ilegais configurações padrão do GA devido a transferências de dados para os EUA. Se usa GA, precisa de banner e de fluxo de consentimento.

E ferramentas "sem cookies" como o Plausible ou o Fathom?

São uma grande melhoria e evitam cookies, mas a maioria gera um hash de visitante diário a partir do IP e do user agent para estimar únicos. Esse hash é um identificador derivado do dispositivo e, na sequência do Breyer, é discutivelmente um dado pessoal. Respeitam a privacidade e são muitas vezes defensáveis sem banner, mas é uma linha jurídica mais ténue do que "não guardamos nem derivamos nada", que foi a linha onde escolhemos ficar.

Não perdem dados importantes?

Perde-se dados por utilizador. Mantém-se todos os números agregados que realmente informam uma decisão de conteúdo ou de design, e mantêm-se para todos os visitantes em vez da minoria que aceita um banner — o que muitas vezes torna o retrato agregado mais exato, não menos.

A Cloudflare não quebra a promessa de não haver dados pessoais?

A Cloudflare está à frente como CDN e vê IPs ao nível da rede, como qualquer alojamento. A distinção que importa juridicamente é que nós não registamos, guardamos nem tratamos esses IPs na nossa analítica; a carga do beacon não contém IP e o endpoint nunca regista o endereço de ligação. O trânsito ao nível da rede não é o mesmo que recolher dados pessoais para um conjunto de dados de analítica.

Se quiser isto

O padrão é portável. Qualquer stack renderizada no servidor o consegue lançar: um único beacon, uma carga que remove tudo, um armazenamento first-party apenas de append, sem terceiros, sem identificador. A parte difícil não é o código — é a disciplina de não recolher os dados que tornam o banner obrigatório. Construímos sites assim por defeito porque é mais rápido, mais leve e significa que a primeira coisa que um visitante vê é o trabalho, não uma caixa de consentimento. Se quer analítica que possa defender sem uma equipa de privacidade e uma revisão jurídica, é esta a sua forma.