Para saber se uma página converte, não é preciso saber quem a visitou. O servidor registra o fato no momento em que ele acontece, o pedido pago ou o cadastro confirmado, e soma numa tabela agregada por dia. Sem cookie, sem identificador, sem banner. O que não é coletado não precisa de base legal, e essa é uma vantagem que nenhum pixel oferece.
O caminho padrão é o oposto. Instala-se um script de analytics, ele grava um identificador no navegador e passa a seguir o visitante de página em página. Quando esse rastro pode ser ligado a alguém, a LGPD o trata como dado pessoal, e dado pessoal cobra base legal, aviso e, na prática, o banner de consentimento que ninguém lê. Minha leitura: para a pergunta que o dono do produto faz todo dia, "essa página está convertendo?", esse aparato inteiro é desproporcional.
A fronteira dá para desenhar no schema. De um lado, um identificador por visitante. Do outro, um número por dia:
sql
create table conversions (
event text not null, -- "sign_up" | "purchase"
day date not null, -- agregado por dia, nunca por visitante
count integer not null default 0,
primary key (event, day)
);
A escrita é um upsert de uma linha:
ts
export async function recordConversion(event: string) {
const day = new Date().toISOString().slice(0, 10);
await sql`
insert into conversions (event, day, count)
values (${event}, ${day}, 1)
on conflict (event, day)
do update set count = conversions.count + 1
`;
}
A chamada fica no ponto em que o fato vira verdade: o handler do webhook de pagamento, a rota que confirma o cadastro. Nunca no navegador. O painel lê a soma e responde "quantos converteram ontem". A pergunta "quem converteu" ele recusa por construção, porque a coluna não existe.
Anonimizar depois de coletar ainda é coletar
A conta que muda tudo é outra: o que nunca vira dado individual não entra no escopo do consentimento. "Anonimizado no cliente" chegou identificado ao script de alguém antes de virar número.
O caso que parece impossível sem rastreador é a atribuição: saber de qual campanha veio a venda. O detalhe que o pixel esconde é que ele também falha exatamente aí. O webhook de pagamento não tem navegador. Um PIX confirma horas depois, num servidor do banco, e nenhum script está presente naquele momento. A saída server-side é capturar a origem uma única vez, quando o checkout começa, e gravar junto do pedido:
Custo de campanha de um lado, receita de pedido do outro, ligados pelo próprio pedido. A decisão de verba fecha com duas tabelas e nenhum consentimento envolvido, porque quem está sendo medido é a campanha, não a pessoa.
O que se perde nessa troca, e é honesto dizer: o funil por visitante, o remarketing, o mapa de calor. Se a pergunta é "quem abandonou no passo três", este mecanismo não responde, e não finge responder. Nos sistemas que construo, essa pergunta quase nunca precisa de resposta; a que precisa é "quanto custou e quanto voltou", e ela fecha com o que está acima.
Quando a pergunta "quem" aparecer de verdade, ela é um requisito novo: finalidade declarada, base legal própria, aviso ao usuário. O erro que este texto quer evitar é outro, o de herdar a vigilância por padrão porque o script de terceiro era fácil de instalar.
Medir é contar fatos que o sistema já conhece: pedido pago, cadastro confirmado, campanha na linha do pedido. Isso cabe numa tabela de duas colunas e não pede consentimento de ninguém. Rastrear pessoas é outra atividade, com outro custo, e deveria ser uma decisão consciente. Nunca o padrão de fábrica.