Resposta direta: pergunte quando a preferência muda materialmente a experiência, o cliente consegue respondê-la com pouco esforço e o custo do erro é relevante. Observe quando existe comportamento repetido, contextual e identificável. Infira apenas quando a decisão é de baixo impacto, reversível e útil apesar da incerteza. No CRM, guarde escolha declarada, evento observado e hipótese inferida como objetos diferentes; aplique validade e precedência; e nunca deixe uma inferência sobrescrever silenciosamente o que a pessoa afirmou.
Para uma empresa de médio porte, isso é uma decisão de implementação, não uma discussão abstrata sobre privacidade. A mesma stack costuma misturar cadastro, click, compra, segmento e score em um campo chamado “preferência”. O resultado é personalização confiante e errada: o presente que alguém comprou vira “gosto pessoal”, um clique acidental vira afinidade, a ausência de resposta vira rejeição e a escolha antiga continua valendo depois que o contexto mudou.
Use a Matriz Perguntar–Observar–Inferir
- Pergunte quando a resposta é estável o bastante para ser útil, fácil de explicar e de atualizar, e quando o erro gera fricção ou desperdício. Tamanho, canal preferido, idioma, tema de interesse e objetivo atual podem justificar uma escolha explícita — desde que a empresa realmente a use.
- Observe quando o sinal tem timestamp, contexto, identidade e repetição: categorias vistas em sessões diferentes, reposição recorrente, uso de produto ou resposta a uma sequência. Um evento isolado continua sendo evidência fraca.
- Infira quando há benefício real em ordenar opções, a ação pode ser revertida e existe fallback genérico. Recomendação de conteúdo pode admitir hipótese; bloquear uma oferta, definir elegibilidade ou mudar termos exige evidência e governança muito mais fortes.
- Não personalize quando identidade, permissão, catálogo, disponibilidade, estado de atendimento ou capacidade operacional tornam a recomendação inadequada. Às vezes a melhor decisão é mostrar uma opção neutra e pedir confirmação.
A documentação de recomendações do Google distingue feedback explícito de feedback implícito. A AWS também trata impressões explícitas e implícitas separadamente e documenta precedência do explícito quando há conflito. Esses mecanismos não definem a política da sua empresa, mas sustentam uma regra prática: comportamento é evidência; não é uma declaração equivalente.
Escreva o Contrato de Evidência de Preferência
- Domínio e valor — o que está sendo preferido, quais opções existem e qual decisão consumirá o dado.
- Sujeito e contexto — pessoa, conta, household, mercado, marca, dispositivo, sessão ou ocasião; uma preferência pode não atravessar todos esses níveis.
- Classe de evidência — declarada, observada, inferida, restrição operacional ou desconhecida; nunca colapse as classes em um booleano.
- Origem e tempo — formulário, conversa, compra, evento, modelo ou regra, com timestamp do acontecimento e da ingestão.
- Confiança e explicação — força do padrão, quantidade e diversidade de eventos, versão da regra ou modelo e motivo legível.
- Vigência e expiração — data efetiva, meia-vida, condição de renovação e caminho para correção ou remoção.
- Uso permitido — decisões e canais autorizados, impacto máximo, exclusões e fallback.
- Conflito e resultado — precedência, revisão, ação executada, feedback posterior e outcome maduro.
A escolha declarada costuma prevalecer dentro do mesmo domínio e contexto. Isso não significa que uma resposta de dois anos atrás seja eterna. Registre quando foi pedida, permita correção e defina expiração. Um comportamento recente pode sugerir que vale perguntar de novo; não deve apagar a preferência anterior sem evidência. A camada de permissão em https://makinai.co/insights/pt/ia-camada-permissoes-consentimento-preferencias-crm continua separada: gostar de um tema não equivale a autorizar um canal ou finalidade.
Exemplo: presente, preferência ou ocasião?
Imagine um e-commerce brasileiro em que uma cliente compra um tênis infantil no Pix, visita três páginas de corrida e escolhe receber alertas apenas por email. O sistema atual define “interesse: infantil”, “esporte: corrida” e “canal: WhatsApp” porque o click rate histórico nessa plataforma é maior.
O contrato separa: compra infantil observada, possivelmente ligada a uma ocasião; afinidade por corrida inferida a partir de três sessões; email declarado como canal; WhatsApp não autorizado para essa finalidade; e disponibilidade por tamanho como restrição. A próxima ação pode mostrar conteúdo de corrida no site com uma opção de ajustar interesses, manter email como canal e evitar afirmar que ela tem filhos. Se ela corrige a preferência, a hipótese perde precedência e o modelo recebe o erro como feedback.
Pilote uma decisão, não um perfil universal
- Semana 1 — escolha uma única decisão, como ordenar três módulos de conteúdo, e registre baseline, fallback e contramétricas.
- Semana 2 — inventarie campos, eventos, formulários, consentimento, identidade, contexto, atrasos e destinos; amostre conflitos reais.
- Semana 3 — implemente o Contrato, estados desconhecidos, precedência, expiração e uma tela simples de correção.
- Semana 4 — produza três versões comparáveis: regra genérica, sinal observado e inferência; rode em sombra sem mudar comunicação externa.
- Semana 5 — libere para coorte pequena, baixa consequência e revisão amostral; registre exposição, correção e outcome.
- Semana 6 — compare utilidade, erro, esforço, custo e confiança; ampliar, perguntar melhor, manter genérico ou encerrar.
Entregáveis: mapa de preferência e contexto, dicionário de eventos, contrato versionado, regra de conflito, política de expiração, testes, integração de retorno, painel, fila de revisão, runbook, rollback e decisão de escala. Um loop mínimo em https://makinai.co/insights/pt/cdp-ia-marketing-loop-minimo-dados-clientes-receita pode bastar; não compre uma CDP apenas para armazenar mais hipóteses.
Custos e escolhas de arquitetura
O custo cresce com domínios de preferência, países, marcas, identidades, pontos de captura, volume, histórico, latência, modelos, canais, interface de correção, idiomas, permissão, experimentação e suporte. Regras e campos do CRM bastam para poucas escolhas estáveis. Uma camada de features em batch atende recomendações diárias. Streaming e modelo próprio só fazem sentido quando a atualização rápida muda uma experiência de valor e a empresa consegue operar monitoramento, replay, incidentes e fallback.
Marketing define a experiência e o impacto aceitável. CRM e dados preservam classes, origem e vigência. Produto cria pergunta e correção sem atrito. Tecnologia integra e monitora. Atendimento e vendas devolvem contexto. Privacidade e jurídico validam finalidade, aviso e limites por mercado. Merchandising ou operação mantém disponibilidade e elegibilidade. O fornecedor pode calcular afinidade; não deve decidir sozinho qual evidência vence.
Meça correção e decisão, não apenas clique
Meça cobertura declarada, observada, inferida e desconhecida; conflitos por domínio; idade da preferência; taxa de correção; inferências revertidas; itens indisponíveis recomendados; uso do fallback; tempo de propagação; reclamações; e custo por decisão executada. Depois, acompanhe descoberta, conversão, margem, retenção ou redução de serviço no horizonte adequado.
Um lift de click não prova que a preferência estava correta nem que a personalização criou valor incremental. Posição, oferta, disponibilidade, novidade e seleção de público interferem. Compare com fallback e, quando possível, use um desenho controlado. A próxima melhor ação em https://makinai.co/insights/pt/ia-proxima-melhor-acao-crm-personalizacao precisa consumir evidência, identidade em https://makinai.co/insights/pt/ia-resolucao-identidade-clientes-crm-duplicados e restrições — não apenas um score.
Se a empresa já possui campos de interesse, eventos e um motor de personalização, leve à MAKINAI, em https://makinai.co/services/pt/consultoria-crm-ecommerce-commerce, um domínio de preferência, uma amostra anônima de conflitos e a decisão que deveria melhorar. Podemos delimitar o menor piloto que separa escolha, observação e hipótese antes de ampliar a stack.
As fontes descrevem capacidades e limites de produtos e um framework voluntário. Elas não provam que uma preferência é verdadeira na sua base, não substituem validação jurídica e não garantem receita. A Matriz, o Contrato, o piloto, os thresholds e a divisão de responsabilidades são recomendações editoriais da MAKINAI para teste local.