Niveles de confianza

No todos los eventos merecen la misma confianza. Una write key pública viaja en el código fuente de tu página; cualquier cosa que un navegador afirme, el dueño de ese navegador puede falsificarla. Kilden hace explícito el nivel de confianza de cada evento en vez de fingir que no existe.

Los tres niveles

Nivel	Cómo se establece	verified
Cliente	Write key pública, sin prueba de identidad	Eventos anónimos: false por convención — no hay identidad que verificar, y nada los trata como sospechosos. Eventos identificados sin token válido: false, es decir no probado
Cliente verificado	Write key pública + un JWT de verificación de identidad válido firmado por tu backend (sub = el distinct_id del evento)	true
Servidor	Write key secreta, solo desde tu backend	true — la secret key es la autenticación

La verificación se computa siempre, en cada evento identificado, sin importar el modo de enforcement del proyecto — así el modo monitor mide exactamente lo que enforce bloquearía.

Qué features lo tienen en cuenta

• Analytics: todo cuenta. Los eventos no verificados se conservan (verified: false), nunca se descartan ni se reescriben — son datos, solo que no confiables.
• Triggers de campañas: las personas identificadas deben estar verificadas para iniciar un journey. Los eventos anónimos pasan. Los eventos de salida siempre pasan (salir es la dirección segura).
• Mutaciones de identidad ($identify, $set, $set_once): gobernadas por el modo del proyecto — en enforce, las mutaciones no verificadas de usuarios identificados no pueden crear ni cambiar personas.
• Lecturas de mensajería (el messenger in-app que viene): verificación requerida siempre, en todos los modos — leer el hilo de mensajes de alguien no es un riesgo de tipo “monitor”.

Dos clases de write keys

• Key pública — segura de incrustar en navegadores y apps móviles. Identifica el proyecto, no autentica nada. Puede acotarse con orígenes permitidos.
• Key secreta — solo backend, nunca incrustada en un cliente. Los eventos enviados con ella son hechos del servidor. La API de decide directamente rechaza las secret keys (403) para que nunca haya tentación de meterlas en código frontend.

Regla práctica: los datos que deben ser verdad van server-side. Revenue, estado de la suscripción, cualquier cosa que dispare dinero o mensajería — envíalo desde tu backend con la secret key. Usa el navegador para el comportamiento, el backend para los hechos, y la verificación de identidad para hacer confiable la identidad del navegador.