Níveis de confiança

Nem todo evento merece a mesma confiança. Uma write key pública viaja no código-fonte da sua página; tudo o que um navegador afirma, o dono do navegador pode forjar. O Kilden torna o nível de confiança de cada evento explícito em vez de fingir que ele não existe.

Os três níveis

Nível	Como se estabelece	verified
Client	Write key pública, sem prova de identidade	Eventos anônimos: false por convenção — não há identidade a verificar, e nada os trata como suspeitos. Eventos identificados sem um token válido: false, significando não comprovado
Verified client	Write key pública + um JWT de verificação de identidade válido assinado pelo seu backend (sub = o distinct_id do evento)	true
Server	Write key secreta, apenas do seu backend	true — a key secreta é a autenticação

A verificação é sempre computada, em todo evento identificado, independentemente do modo de enforcement do projeto — assim o modo monitor mede exatamente o que enforce bloquearia.

Quais features se importam

• Analytics: tudo conta. Eventos não verificados são mantidos (verified: false), nunca descartados nem reescritos — são dados, apenas não confiáveis.
• Gatilhos de campanhas: pessoas identificadas precisam estar verificadas para iniciar uma jornada. Eventos anônimos passam. Eventos de saída sempre passam (sair é a direção segura).
• Mutações de identidade ($identify, $set, $set_once): governadas pelo modo do projeto — em enforce, mutações não verificadas de usuários identificados não podem criar nem alterar pessoas.
• Leituras de mensagens (messenger in-app, em breve): verificação exigida sempre, em todos os modos — ler a thread de mensagens de alguém não é um risco do tipo “monitor”.

Duas classes de write keys

• Key pública — segura para embutir em navegadores e apps mobile. Identifica o projeto, não autentica nada. Pode ser restringida com origens permitidas.
• Key secreta — apenas backend, nunca embutida em um cliente. Eventos enviados com ela são fatos do servidor. A API de decide rejeita keys secretas de imediato (403), para que ninguém se sinta tentado a colocá-las em código frontend.

Regra de bolso: dados que precisam ser verdade vão pelo lado do servidor. Receita, estado da assinatura, qualquer coisa que dispare dinheiro ou mensageria — envie do seu backend com a key secreta. Use o navegador para comportamento, o backend para fatos, e a verificação de identidade para tornar a identidade do navegador confiável.