Como construir um sistema de recomendação sem rastrear utilizadores

É possível construir um sistema de recomendação genuinamente útil sem rastrear um único utilizador. O truque está em deixar de tentar perceber quem é a pessoa ao longo de várias visitas e, em vez disso, ordenar um catálogo finito usando aquilo que os próprios itens contêm, mais o punhado de sinais que a sessão atual oferece de graça. Perde-se os últimos pontos de precisão que vêm da criação de perfis cruzados entre utilizadores. Para a maioria dos produtos, essa perda não compensa uma responsabilidade de vigilância.

O que significa, de facto, "um sistema de recomendação sem rastreamento"

Um recomendador sem rastreamento de utilizadores é um sistema de ordenação que produz sugestões com aparência personalizada sem construir um perfil persistente e cruzado de uma pessoa identificável. Sem cookie que o persiga, sem impressão digital do dispositivo, sem ID de utilizador costurado entre visitas, sem dados comportamentais enviados a terceiros. O modelo nunca precisa de responder a "quem é isto?" — apenas a "dados estes itens e o que acabou de acontecer nesta sessão, o que devo mostrar a seguir?".

Vale a pena ser preciso, porque a indústria confunde isto de propósito. Há três grandes famílias de recomendadores:

• Filtragem colaborativa — "pessoas como você também gostaram de X". É esta que exige rastreamento: só funciona se tiver um histórico longo e ligado à identidade de muitos utilizadores para encontrar os seus vizinhos.
• Baseada em conteúdo — "este item parece-se com coisas com que está a interagir agora". Pontua os itens pelas suas próprias características, pelo que não precisa de histórico de outras pessoas nem de um perfil de longo prazo seu.
• Baseada em conhecimento/regras — "dadas estas restrições, estes candidatos são válidos e ordenados". Lógica de domínio pura, zero dados comportamentais.

A recomendação que põe a privacidade em primeiro lugar vive quase inteiramente na segunda e terceira famílias, coladas com aquilo que a sessão ao vivo revela legitimamente. É todo o espaço de design, e é maior do que se supõe.

A versão curta

• Ordene um catálogo finito e próprio — você escreveu os itens, por isso pode descrevê-los com riqueza.
• Personalize a partir de sinais locais à sessão: o caminho atual, os itens tocados nesta visita, o idioma declarado, o contexto grosseiro. Tudo descartado quando o separador fecha.
• Pontue com características de conteúdo e um modelo pequeno e explicável — não com um histórico cruzado de utilizadores.
• Mantenha qualquer estado aprendido no dispositivo ou agregado para lá de um limiar de privacidade antes de tocar num servidor.
• Aceite um pequeno custo de precisão em troca de não haver banner de consentimento, dor de cabeça com DPA, e de ter um sistema que se explica a um regulador.

1. Recomendar é, sobretudo, ordenar; e ordenar é, sobretudo, conteúdo

Defendemos isto em detalhe no nosso argumento a favor de ML em vez de IA: a maioria das "funcionalidades de IA" são listas de sugestões ordenadas disfarçadas de chatbot. O mesmo reenquadramento dissolve o problema da privacidade. Se o trabalho é "ordenar este conjunto conhecido de itens", então o sinal mais rico disponível é quase sempre os próprios itens — não um dossiê sobre o utilizador.

Veja a Delicious Diamonds, a casa de chocolate de luxo para quem trabalhamos. O "também poderá gostar" numa página de praliné não precisa de conhecer o seu histórico de compras por toda a web aberta. Precisa de saber que o praliné que está a ver é de origem única de Madagáscar, 72% de cacau, na faixa de preço de presente, com nota cítrica — e que outros três itens do catálogo partilham a maioria desses atributos. É uma procura de vizinhos baseada em conteúdo sobre algumas centenas de SKU. Corre num milissegundo e está correta numa primeira visita, com um pote de cookies vazio, para um navegador sem sessão iniciada atrás de uma VPN.

A filtragem colaborativa cruzada é a forma cara e invasiva de aproximar algo que as características de conteúdo muitas vezes dão diretamente. Quando o catálogo é pequeno e bem descrito, não precisa da multidão.

Construir características de conteúdo sem vigilância

O trabalho passa da recolha de dados para a descrição de dados. Para cada item guarda-se um vetor de características construído a partir de coisas que já possui:

• Atributos estruturados — categoria, etiquetas, faixa de preço, origem, dificuldade, duração, peso da evidência.
• Embeddings de texto do título e da descrição, calculados uma vez no momento da publicação com um modelo local pequeno. Usamos um modelo de embedding de frases no servidor; sem inferência por pedido, sem API externa.
• Sinais editoriais — "combina com", "faz parte da coleção", peso do curador.

A semelhança é então a distância de cosseno sobre esses vetores, opcionalmente reponderada por regras de negócio. Nada disto faz referência a uma pessoa. Calcula-se quando o conteúdo muda, guarda-se em cache, e servem-se os vizinhos pré-calculados como uma procura estática.

2. Sinais locais à sessão: personalização que esquece de propósito

A semelhança de conteúdo pura é impessoal. O meio-termo honesto é a sessão — a única unidade de contexto que pode usar sem se tornar um rastreador, porque começa e acaba com a visita.

Dentro de uma única sessão sabe legitimamente: as páginas visitadas nesta visita, os itens adicionados ao carrinho ou marcados como favoritos, os termos de pesquisa escritos, o idioma de interface declarado, e contexto grosseiro como classe de viewport ou hora do dia. A partir daí pode manter um vetor de interesse da sessão — uma média corrente dos vetores de características dos itens com que o visitante interagiu nesta visita — e ordenar candidatos pela proximidade a ele. Navegue por três tabletes intensas e ricas em cacau e a página inclina-se discretamente para a intensidade em vez da doçura, sem fazer ideia de quem é e sem se lembrar de si amanhã.

A disciplina que torna isto orientado à privacidade em vez de rastreamento com outro nome:

• Sem identificador persistente. A sessão é indexada por um token efémero em sessionStorage (morre com o separador) ou um cookie de sessão de primeira parte sem valor de longo prazo — nunca um ID de utilizador costurado.
• Sem junção entre sessões. Deliberadamente não ligamos esta visita à anterior. Voltar amanhã é uma folha em branco. Isso é uma funcionalidade, não um defeito.
• O estado fica do lado do cliente sempre que possível. Na Jofit, a nossa app de bem-estar, o vetor de interesse da sessão vive no navegador e é enviado ao ordenador como um vetor curto e opaco, não como um registo de eventos retido pelo servidor.

Isto espelha como gerimos o site que está a ler. Como escrevemos em não rastreamos utilizadores, a nossa analítica é um único beacon anónimo por sessão sem retenção de IP para lá de sete dias. O recomendador segue a mesma regra: a sessão é a unidade, e nada lhe sobrevive.

3. Abordagens no dispositivo e agregadas para os casos mais difíceis

Por vezes conteúdo mais sessão genuinamente não chega — quer que o modelo aprenda. Há duas formas de obter aprendizagem sem construir dossiês por utilizador num servidor.

Personalização no dispositivo

Envie o ordenador para o cliente e deixe que o estado pessoal nunca o abandone. Os vetores de características do catálogo são públicos; os pesos de preferência do utilizador são calculados e guardados localmente (IndexedDB, armazenamento no dispositivo) e aplicados no momento da renderização. O servidor envia o mesmo conjunto neutro de candidatos a toda a gente; o dispositivo reordena-o. É exatamente assim que o ordenador da Jofit consegue adaptar-se ao histórico de adesão de uma pessoa — esse histórico é da própria pessoa, no seu próprio dispositivo, e os nossos servidores nunca veem o rasto.

O custo é real e deve nomeá-lo: não consegue calcular, a partir de um único dispositivo, coisas que exigem a população, como tendências verdadeiras ou predefinições de arranque a frio. Essas derivam-se de agregados.

Sinais apenas agregados

Pode usar a multidão sem rastrear indivíduos se só ler a multidão em agregado, e só acima de um limiar. "Este item foi visto por sessões distintas suficientes esta semana para contar como popular" é um sinal global seguro para a privacidade, desde que guarde contadores, não eventos — incremente uma contagem, nunca uma linha ligada a uma identidade. Tudo abaixo de uma contagem mínima (digamos, menos de 50 sessões distintas) é suprimido, para que nenhum agregado possa singularizar uma pessoa. É o mesmo instinto de k-anonimato que torna segura a nossa analítica por beacon.

Para equipas que querem ir mais longe, a aprendizagem federada e a privacidade diferencial formalizam isto: treinar no dispositivo, enviar apenas atualizações de modelo com ruído, nunca comportamento bruto. Recorreríamos a isso num grande produto B2C. Para um site de estúdio ou uma loja de algumas centenas de SKU, é sobre-engenharia — conteúdo mais sessão mais agregados com limiar já lhe dá 90% da qualidade percebida.

4. O compromisso de precisão, dito com honestidade

Eis a parte que a maioria dos fornecedores não imprime. Abdicar do rastreamento cruzado custa-lhe precisão, e o tamanho do custo depende inteiramente do seu catálogo.

O que abdica:

• A serendipidade da filtragem colaborativa — "quem comprou berbequins também comprou esta coisa sem relação". Os recomendadores baseados em conteúdo ficam mais perto do que já está a ver; é menos provável que o surpreendam com o salto entre categorias que uma enorme matriz comportamental faz emergir.
• Personalização verdadeiramente de longo prazo — um modelo que se lembra de si ao longo de meses e estações. O esquecimento local à sessão significa que cada visita reaprende do zero.
• Otimização à escala da população sobre dados ao nível individual — o tipo de aperto que move uma métrica uma fração de ponto percentual à escala de milhares de milhões de eventos.

O que mantém, ou ganha:

• Correção na primeira visita. Os recomendadores de conteúdo e sessão não têm problema de arranque a frio ao nível do utilizador — funcionam para alguém nunca antes visto, que é a maioria do seu tráfego.
• Explicabilidade. "Recomendado porque partilha origem e percentagem de cacau com o que está a ver" é uma frase que pode mostrar ao utilizador e defender perante um regulador. Um embedding de filtragem colaborativa não é.
• Sem porta de consentimento no caminho crítico. Como nada é rastreado, o recomendador corre antes de qualquer banner de cookies ser respondido. Sob o RGPD, a criação de perfis que usa rastreamento geralmente exige consentimento; ordenar um catálogo pelos seus próprios atributos mais estado de sessão efémero não. É uma vantagem legal e de UX, não apenas ética.
• Menor custo e latência. Vizinhos pré-calculados e um pequeno vetor de sessão são baratos. Sem feature store de históricos de utilizador, sem re-treino noturno sobre um lago comportamental.

A regra de decisão que usamos: se o catálogo é pequeno e bem descrito, o baseado em conteúdo vence em definitivo e a diferença de precisão é negligenciável. Quanto maior e mais insípido o catálogo, e quanto mais a sua margem depende de espremer o último ponto percentual de conversão, mais a filtragem colaborativa lhe teria dado — e mais honestamente tem de pesar isso contra a responsabilidade de dados que cria.

5. Uma arquitetura de referência que pode lançar este sprint

Concretamente, na nossa stack — PHP 8.3, Cockpit CMS, sem passo de build, renderizado no servidor — um recomendador que põe a privacidade em primeiro são três peças modestas:

1. Construção de características offline. Na publicação de conteúdo, calcule o vetor de características de cada item (atributos + embedding de texto) e os top-N vizinhos de conteúdo. Guarde-os como JSON ao lado do conteúdo. Sem custo em tempo de execução, sem junção de base de dados no caminho quente.
2. Vetor de sessão. Um pequeno acumulador do lado do cliente mantém uma média corrente dos vetores de características dos itens tocados nesta visita, em sessionStorage. É enviado ao endpoint de ordenação como um array curto e opaco — { session_vec: [...], context: { lang, viewport } } — nunca um registo de eventos.
3. Ordenador. Um endpoint de servidor combina semelhança de conteúdo, proximidade de sessão e popularidade agregada com limiar numa só pontuação, aplica regras de negócio rígidas, e devolve a lista ordenada. Sem estado. Não regista nada ligado a identidade.

É isto. Cabe num sprint, corre em alojamento partilhado, e não há nenhuma parte que o deixasse desconfortável a explicar numa política de privacidade.

A conclusão

A maioria dos produtos não precisa de rastrear utilizadores para recomendar bem — precisa de descrever bem o seu catálogo e respeitar a fronteira da sessão. Recorra à filtragem colaborativa apenas quando o seu catálogo for demasiado grande e genérico para as características de conteúdo aguentarem a carga, e apenas depois de ter contabilizado a vigilância que exige. Para todos os outros, um ordenador baseado em conteúdo e local à sessão é mais rápido de construir, mais barato de operar, legal sem a dança do consentimento, e honesto o suficiente para se explicar à pessoa que serve. Os poucos pontos de precisão que deixa em cima da mesa são o seguro mais barato que alguma vez comprará.