Añadiste un widget de chat con IA a tu producto. Responde a partir de tu centro de ayuda, se ocupa de una buena parte de las consultas antes de que se conviertan en tickets y todas las transcripciones están ahí, en una lista. Las lees los viernes por la tarde.
Y todas dicen Anónimo.
Ves que alguien preguntó tres veces en una tarde cómo cambiar su correo de facturación. No ves que era la misma persona, que está en tu plan más alto y que se rindió y canceló el lunes.
Ese es el hueco que cierra la identidad.
Lo que un registro anónimo puede decirte y lo que no
Una transcripción anónima sirve de mucho. Te dice qué pregunta la gente, qué preguntas no responde tu documentación y qué páginas la confunden. Es la base del ciclo de escribir el artículo que falta, y funciona sin conocer ni un solo nombre.
Lo que no puede hacer es conectar una conversación con nada más de lo que sabes.
Frecuencia por persona, no por sesión. Diez conversaciones sobre la misma función pueden ser diez usuarios confundidos o uno muy insistente. Esas dos situaciones piden respuestas completamente distintas, y un registro anónimo no las distingue.
A quién afecta. «Tres personas preguntaron por el límite de peticiones de la API» se lee distinto cuando una de ellas es tu cuenta más grande.
El seguimiento. Un agente de soporte que abre un ticket no ve lo que la IA le dijo a ese cliente hace una hora, así que el cliente lo explica todo dos veces.
La señal de cancelación. Las preguntas frustradas que se repiten desde una misma cuenta en las dos semanas antes de que cancele son una de las señales más claras que vas a recibir. Sin identidad, no se ven.
La idea obvia y por qué es peligrosa
Lo obvio es decirle al widget quién ha iniciado sesión. Tu aplicación ya lo sabe.
KookeeChat.identify({ id: user.id, email: user.email, name: user.name });El peligro está en lo que haces después. Es muy tentador razonar así: el widget ya sabe quién es, así que el asistente puede responder preguntas sobre su cuenta. Sus facturas. Su consumo. Sus tickets abiertos.
No lo hagas. Todo lo que envía el navegador lo puede cambiar la persona que está en ese navegador. Abre las herramientas de desarrollo, llama a identify() con el correo de otra persona y, si el asistente confía en ese campo, habrás construido una fuga de datos con una interfaz de chat encima.
Este tipo de error no es hipotético. Es el mismo fallo que confiar en un id de usuario que envía el cliente en una petición a la API, y se arregla igual.
Identidad para etiquetar, autenticación para los datos
La salida es separar dos cosas que parecen una sola.
La identidad es una etiqueta. Dice a quién pertenece probablemente la conversación, para que puedas agrupar, buscar y leer tus transcripciones. No está verificada y no decide nada.
La autenticación es otra cosa, y ya existe. Tu aplicación autentica a los usuarios. Tu API comprueba las sesiones. Nada de eso cambia porque haya aparecido un widget de chat.
Así que cuando el asistente de verdad necesita datos privados, no debe leerlos del campo de identidad. Debe llamar a una función que se ejecuta en el navegador del propio visitante, con su propia cookie de sesión, contra tu propia API:
KookeeChat.init({
apiKey: 'YOUR_API_KEY',
visitor: { id: user.id, email: user.email }, // una etiqueta, para tu panel
tools: [
{
name: 'get_my_invoices',
description: "Look up the signed-in customer's recent invoices.",
parameters: { type: 'object', properties: {} },
handler: () => fetch('/api/my/invoices', { credentials: 'include' }).then((r) => r.json()),
},
],
});Léelo con atención. Lo que hace esto seguro no es el campo visitor, sino credentials: 'include'. Tu servidor recibe una petición autenticada normal y aplica las mismas reglas que en cualquier otro sitio. Si alguien falsea identify(), sigue recibiendo sus propias facturas, porque quien decide es la cookie.
En ese fragmento, el campo de identidad hace algo mucho más modesto: pone un nombre en una fila de tu panel.
Lo que todos olvidan: cerrar sesión
Este es el error que vas a publicar si solo implementas el camino feliz.
Alguien inicia sesión en un equipo de una biblioteca, le hace al asistente tres preguntas sobre su cuenta y cierra sesión. La siguiente persona se sienta, abre el chat y la conversación anterior sigue ahí, porque el widget la guardó en el navegador y nadie le avisó de que algo había cambiado.
La identidad no es solo algo que configuras una vez. Cambia, y el cambio es el evento importante:
// al iniciar sesión
KookeeChat.identify({ id: user.id, email: user.email, name: user.name });
// al cerrar sesión: no te saltes esto
KookeeChat.reset();Un widget de chat que admite identidad tiene que tratar el cambio de persona como un límite estricto: descartar la transcripción, empezar una sesión nueva, no conservar nada. En Kookee eso pasa automáticamente cuando la identidad cambia a otra persona o a nadie. Pero el widget solo puede reaccionar a lo que le dices, así que la llamada a reset() al cerrar sesión la escribes tú.
Hay un detalle que conviene conocer, porque afecta incluso a quien hace bien la llamada al cerrar sesión. La mayoría de las aplicaciones no saben quién es el usuario en el primer renderizado. Piden la sesión y solo entonces pueden identificar a alguien. Si para el widget «todavía no lo sé» y «no hay nadie con sesión iniciada» son lo mismo, cada carga de página tira la conversación antes de que termine tu comprobación de sesión. Por eso hay que poder distinguirlos: deja el valor en undefined mientras cargas y pasa un null explícito cuando sepas que la respuesta es nadie.
Qué enviar
Menos de lo que crees.
Necesitas algo estable para agrupar. Un id de usuario de tu propia base de datos cumple esa función a la perfección y no le dice nada a nadie que no tenga tu base de datos. Un correo es más útil en soporte, porque es lo que buscas cuando un cliente te escribe, pero también es un dato personal, con su plazo de conservación.
Un punto de partida razonable:
Envía siempre el id. Es la clave para agrupar y es opaco.
Envía el correo si tu proceso de soporte busca por él. La mayoría lo hace.
Envía el nombre para que se lea mejor. Con él, el panel se recorre de un vistazo.
No envíes nada más. El plan, el rol y la antigüedad de la cuenta parecen útiles, pero van en el contexto que le das al asistente, no en la etiqueta de identidad. Si mezclas las dos cosas, acabas con un almacén de datos personales que no tenías intención de construir.
Y déjalo por escrito en tu política de privacidad. Las transcripciones de chat ya son datos personales; añadirles un correo no cambia la categoría, pero sí lo evidente que resulta para un regulador y para tus usuarios.
¿Debe el asistente saber el nombre?
Aquí aparece una idea atractiva: si el widget sabe que quien visita es Alicia, el asistente podría empezar con «Hola, Alicia».
Kookee no lo hace, a propósito. La identidad se guarda con la conversación y nunca se envía al modelo. Los datos personales no entran en una petición al modelo a menos que tú lo decidas.
Si quieres el saludo, puedes tenerlo, pero tienes que pedirlo de forma explícita con el campo de contexto aparte, pensado para lo que el asistente debe saber:
KookeeChat.init({
apiKey: 'YOUR_API_KEY',
visitor: { id: user.id, email: user.email, name: user.name }, // tu panel
appContext: { firstName: user.firstName, plan: user.plan }, // el asistente
});Dos campos, dos destinatarios. Parece una duplicación hasta el día en que alguien pregunta qué datos personales salen de tu infraestructura y puedes responder con precisión.
Lo que ganas
Cuando las conversaciones llevan identidad, puedes responder preguntas corrientes.
Busca el correo de un cliente en tus transcripciones antes de una llamada de renovación y sabrás qué lo confundió este trimestre. Si ves que la misma cuenta pregunta lo mismo cuatro veces, has encontrado un hueco en la documentación o en el onboarding. Pasa a un agente de soporte la conversación con la IA que precedió al ticket y el cliente deja de repetirse.
Nada de eso exige que el asistente sea más listo. Exige que el registro deje de decir Anónimo.
El widget de chat con IA de Kookee admite la identidad del visitante tanto en el paquete de React como en la etiqueta script simple. Consulta Identificar quién está chateando para ver todas las reglas, incluido el momento exacto en que se descarta una conversación.