Hoje todo fornecedor de analytics diz sem cookies. Poucos explicam o que sua implementação realmente faz, e quase nenhum diz o que ela não pode fazer. Este artigo explica a nossa, incluindo a parte que não funciona, porque se você vai confiar nos números de uma ferramenta, deveria saber exatamente como esses números são produzidos.

Por que não queríamos nada no dispositivo

Quando começamos a construir a Zenovay, tomamos uma decisão cedo: deveria existir um modo de rastreamento que não armazena nada no navegador. Sem cookies, sem localStorage, sem IndexedDB, nada que sobreviva à aba. É uma configuração por site e, em sites recém-criados, vem ligada por padrão. Só ao desligá la o rastreador passa a usar um cookie próprio e armazenamento do navegador. Se a ausência de armazenamento importa para você, confira a chave em vez de presumir.

Não porque armazenamento seja ruim. Porque armazenamento é um compromisso. No momento em que você escreve um identificador no dispositivo de alguém, você assume obrigações de retenção e exclusão, e normalmente um banner. Queríamos um modo em que não houvesse nada armazenado para excluir. Isso não faz a questão da base legal desaparecer. Se uma visita exige consentimento é uma regra separada de uma lei separada, ela continua valendo, e ela pertence ao proprietário do site e não a nós.

Essa decisão parece limpa até você tentar responder à pergunta mais básica de analytics: esta visualização de página vem da mesma pessoa que a de cinco minutos atrás? Sem um identificador armazenado, a resposta honesta é que você tem que adivinhar. Então a verdadeira pergunta de design é: como adivinhar bem, e como fazer o palpite expirar?

A função de identidade

Aqui está todo o mecanismo. Quando um evento chega ao nosso edge, o servidor calcula:

visitor_key = sha256(
  ip_subnet      // not the full IP
  + user_agent   // the browser's own header
  + daily_salt   // rotates at midnight UTC
)

As sessões são uma janela de 30 minutos sobre essa chave. O hash é calculado no servidor, no Cloudflare Workers, antes da persistência dos registros analíticos. No modo sem cookies, o rastreador envia IDs aleatórios de visitante e sessão, limitados à janela, para agrupar os eventos da aba aberta. Esses IDs não são armazenados no navegador e, antes da persistência, a ingestão substitui a identidade do visitante pelo hash diário do servidor. Nenhum cookie nem registro em localStorage ou IndexedDB é criado no dispositivo.

Três ingredientes, cada um escolhido por um motivo.

A sub rede IP, não o IP completo. Usar o endereço completo tornaria a chave mais precisa e mais invasiva ao mesmo tempo. A sub rede é deliberadamente imprecisa. Ela também absorve parte da variação das redes móveis, onde o último octeto pode mudar entre as requisições enquanto a sub rede permanece igual.

O user agent. Ele separa as duas pessoas atrás de um roteador doméstico melhor do que nada. Sozinho é um sinal fraco, e tudo bem. É uma de três entradas.

O sal diário. O sal muda à meia noite UTC, portanto uma chave vale apenas para o dia em que foi criada, e ela está limitada a um único site. Combinado a um segredo do lado do servidor que nunca sai da nossa infraestrutura, isso significa que ninguém com uma cópia do banco de dados consegue transformar um identificador de volta em uma pessoa. E agora o limite, dito com precisão: a rotação deriva da data, não de um valor aleatório que destruímos, portanto nós mesmos poderíamos recalcular uma chave antiga se quiséssemos. Preferiríamos que a frase mais forte fosse verdadeira, então estamos mudando a rotação para um valor diário aleatório que é descartado. Até isso entrar em produção, esta é a descrição correta.

A falha

Essa rotação do sal também é uma falha, e queremos ser precisos sobre ela em vez de escondê la em uma nota de rodapé.

À meia noite UTC, toda chave de visitante do planeta muda. A mesma pessoa, na mesma rede, no mesmo navegador, se torna um visitante totalmente novo. O que significa:

  • As contagens de visitantes únicos em intervalos de vários dias são superestimadas. Um leitor diário aparece como sete pessoas em uma visão semanal.
  • Uma taxa de visitantes recorrentes ao longo dos dias não é algo que possamos calcular honestamente no modo sem cookies, então não fingimos que sim.
  • Uma jornada de consideração de cinco dias, em que alguém lê sua página de preços na segunda e se cadastra na sexta, parece duas pessoas sem relação.

Linha do tempo mostrando um visitante antes das 00:00 UTC se tornando um novo visitante desconhecido após a rotação do sal à meia noite

Se o seu negócio depende da estabilidade do visitante entre os dias, este design vai incomodar você. Não é um relatório de bug que possamos corrigir. É o preço da propriedade descrita acima, e achamos que o preço merece ser dito com clareza.

O que ainda funciona, e por que a atribuição de receita sobrevive

Tudo o que acontece dentro de um dia funciona normalmente: sessões, jornadas, funis, visão ao vivo e atribuição de canal para a visita que está acontecendo agora.

O caso interessante é a receita. Se a identidade morre à meia noite, como podemos dizer qual canal produziu um cliente pagante três semanas após a primeira visita?

Porque na conversão, os palpites param. Quando alguém se cadastra ou paga, se identifica ao seu produto, e seu produto pode nos dizer. A partir desse momento a jornada fica ancorada a uma conta real, e a pergunta de atribuição volta a ter resposta, de trás para frente a partir da conversão. A fase anterior à conversão permanece pseudônima. A fase paga é precisa. Achamos que esse é o lugar certo para a fronteira: a precisão chega exatamente quando uma pessoa escolhe um relacionamento com você.

O que rejeitamos

Um fingerprinting mais pesado. Entropia de canvas, enumeração de fontes, peculiaridades do contexto de áudio. Isso tornaria a chave mais estável e nos tornaria uma empresa de vigilância com uma página inicial mais bonita. Não.

Um sal semanal. Melhor continuidade, história de privacidade mais suave. Uma vez que você gira toda semana, está a uma mudança de configuração do mensal, e a mais uma do nunca. Diário é uma linha clara, e linhas claras sobrevivem à pressão do produto.

Um fallback em localStorage. Armazenar uma chave apenas quando uma heurística decide que está tudo bem significaria que a frase honesta na nossa página inicial precisa de um asterisco. A frase vale mais do que a continuidade.

Colisões, porque a honestidade vale nos dois sentidos

A falha acima divide uma pessoa em muitas. Duas assinaturas idênticas de navegador e de rede se fundindo em um único visitante por um dia

A falha oposta também existe: duas pessoas no mesmo escritório, na mesma sub rede, com versões idênticas de navegador, podem se fundir em um único visitante por um dia. Nós aceitamos isso. Subcontagem e supercontagem são ambas distorções, mas são limitadas, expiram diariamente, e nenhuma delas exige escrever no dispositivo de ninguém.

Se você precisa de estabilidade entre dias mesmo assim

Sem cookies é um modo, não um dogma, e cada site na Zenovay tem uma chave. Em sites recém-criados ela vem ligada por padrão. Desligue e o rastreamento passa a usar um cookie próprio, os visitantes ficam estáveis entre dias, e as obrigações de consentimento que vêm com isso são suas, como seriam com qualquer ferramenta. Repetição de sessão, mapas de calor e rastreamento entre domínios são recursos separados, com armazenamento próprio e implicações de consentimento próprias. Ativá los não é o mesmo que operar neste modo.

O ponto

Escrevemos isto porque a maioria das afirmações sem cookies são frases de marketing, e frases de marketing não têm modos de falha. Mecanismos reais têm. O nosso divide pessoas à meia noite UTC, funde alguns colegas de escritório, e se recusa a responder perguntas que não consegue responder com honestidade. Sabendo disso, você pode decidir o que nossos números significam.

Se você já construiu sistemas de identidade e enxerga um compromisso mais afiado que deixamos passar, queremos muito ouvir.