zendesk-messaging-conversation-merge
Written by
eesel Team
Last edited 24 febrero 2026
{
"title": "Fusión de conversaciones de mensajería de Zendesk: Una guía técnica completa",
"slug": "zendesk-messaging-conversation-merge",
"locale": "es",
"date": "2026-02-20",
"updated": "2026-02-20",
"template": "default",
"excerpt": "Una guía completa para comprender e implementar la fusión de conversaciones en Zendesk Messaging, incluidos los flujos de autenticación y el comportamiento de múltiples conversaciones.",
"categories": [
"Blog Writer AI"
],
"tags": [
"Zendesk",
"Messaging",
"Customer Support",
"User Management",
"API"
],
"readTime": 10,
"author": 16,
"reviewer": 14,
"seo": {
"title": "Fusión de conversaciones de mensajería de Zendesk: Una guía técnica completa",
"description": "Una guía completa para comprender e implementar la fusión de conversaciones en Zendesk Messaging, incluidos los flujos de autenticación y el comportamiento de múltiples conversaciones.",
"image": "https://wmeojibgfvjvinftolho.supabase.co/storage/v1/object/public/public_assets/blog-gen/banner-c0661eef-0cd2-480b-9a48-944e529417ed"
},
"coverImage": "https://wmeojibgfvjvinftolho.supabase.co/storage/v1/object/public/public_assets/blog-gen/banner-c0661eef-0cd2-480b-9a48-944e529417ed",
"coverImageAlt": "Imagen del banner para la fusión de conversaciones de mensajería de Zendesk: Una guía técnica completa",
"coverImageWidth": 1920,
"coverImageHeight": 1080,
"faqs": {
"heading": "Preguntas Frecuentes",
"type": "blog",
"answerType": "html",
"faqs": [
{
"question": "¿Cómo maneja el proceso de fusión de conversaciones de mensajería de Zendesk los conflictos de metadatos?",
"answer": "Cuando se fusionan los perfiles de usuario, los metadatos del usuario descartado tienen prioridad en los conflictos. Sin embargo, hay un límite de tamaño total de 4 KB. Si los metadatos combinados exceden este límite, Zendesk elimina los campos individuales uno por uno hasta que quepan. El webhook user:merge incluye información sobre cualquier metadato descartado para que sus sistemas puedan manejarlo adecuadamente."
},
{
"question": "¿Se puede deshabilitar el comportamiento de fusión de conversaciones de mensajería de Zendesk una vez que se habilitan las múltiples conversaciones?",
"answer": "No. Habilitar las múltiples conversaciones es irreversible. Una vez activado, los registros de usuario aún se fusionan durante la autenticación, pero los historiales de conversación permanecen separados. No puede volver al modo de conversación única donde las conversaciones se combinan en un solo hilo. Planifique cuidadosamente y pruebe a fondo antes de habilitar esta función."
},
{
"question": "¿Qué sucede con las sesiones activas cuando se produce una fusión de conversaciones de mensajería de Zendesk?",
"answer": "Depende del tipo de fusión. Para las fusiones de API que involucran a usuarios de SDK, los tokens de sesión no autenticados se revocan cuando se fusionan con usuarios autenticados. El usuario necesita un nuevo JWT para continuar. Para las fusiones de eventos de inicio de sesión, las conexiones websocket activas reciben automáticamente tokens de sesión actualizados. Las fusiones de transferencia de canal normalmente mantienen la continuidad de la sesión, ya que el usuario participa activamente en la transferencia."
},
{
"question": "¿Por qué la fusión de conversaciones de mensajería de Zendesk crea tickets duplicados en algunos escenarios?",
"answer": "Los tickets duplicados ocurren con las múltiples conversaciones habilitadas cuando los usuarios se autentican a mitad de la conversación. El perfil de usuario se fusiona, pero la conversación activa permanece separada de las anteriores, creando múltiples tickets para el mismo problema subyacente. Autentique a los usuarios antes de que comiencen a enviar mensajes para evitar esto."
},
{
"question": "¿Cómo se soluciona cuando la fusión de conversaciones de mensajería de Zendesk no se vincula a los usuarios existentes?",
"answer": "Primero, verifique que su JWT incluya el external_id correcto que coincida con sus registros de usuario de Zendesk. Compruebe que el usuario tenga una identidad de correo electrónico verificada. Revise la configuración de su Centro de administración para confirmar que 'Usar solo correos electrónicos verificados' no esté bloqueando la vinculación legítima. Finalmente, revise los registros del webhook user:merge para obtener detalles del error."
},
{
"question": "¿Qué riesgos de seguridad existen con la funcionalidad de fusión de conversaciones de mensajería de Zendesk?",
"answer": "El principal riesgo es la suplantación de identidad por correo electrónico. Sin la configuración de identidad de correo electrónico verificada, cualquiera que ingrese la dirección de correo electrónico de otra persona podría tener su conversación vinculada al perfil de esa persona. Utilice siempre la configuración 'Usar solo correos electrónicos verificados' por seguridad. Además, maneje los eventos de webhook de fusión de forma segura y valide que las operaciones de fusión sean legítimas en sus registros del sistema."
}
],
"supportLink": null
}
}
---
Cuando sus clientes se ponen en contacto a través de múltiples canales, esperan que usted recuerde quiénes son. Pero en Zendesk Messaging, las identidades de los usuarios pueden fragmentarse. Un cliente podría comenzar en su sitio web, continuar en WhatsApp y hacer un seguimiento por correo electrónico, creando tres perfiles de usuario separados. Aquí es donde la fusión de conversaciones se vuelve esencial.
Comprender cómo Zendesk maneja la fusión de usuarios y conversaciones le ayuda a construir una experiencia de soporte perfecta. Analicemos cómo funciona el proceso, cuándo se activa y qué necesita saber para gestionarlo eficazmente.
## ¿Qué es la fusión de conversaciones en Zendesk Messaging?
La fusión de conversaciones en [Zendesk Messaging](https://www.zendesk.com/messaging) es el proceso de combinar perfiles de usuario separados y sus historiales de conversación asociados en un único registro unificado. Esto es importante porque sin una fusión adecuada, sus agentes ven interacciones fragmentadas con los clientes. Un cliente que regresa podría aparecer como tres personas diferentes, lo que obliga a los agentes a buscar en múltiples tickets para comprender el contexto completo.
Es importante distinguir entre dos conceptos relacionados:
La **fusión de usuarios** combina dos perfiles de usuario en uno. El usuario "superviviente" conserva la identidad fusionada, mientras que el usuario "descartado" se elimina. Todos los datos del perfil, los metadatos y los historiales de conversación se transfieren al usuario superviviente.
La **fusión de conversaciones** se refiere específicamente a la combinación de hilos de conversación separados en un solo historial. Esto sucede automáticamente en algunos escenarios, pero no en otros, dependiendo de su configuración.
El proceso de fusión afecta a múltiples puntos de datos. Cuando los usuarios se fusionan, su información de perfil se combina, y los valores del usuario descartado tienen prioridad en los conflictos. Los metadatos también se fusionan, pero se mantienen dentro de un límite de tamaño de 4 KB. Las listas de clientes y dispositivos se desduplican y combinan. Lo más importante es que los historiales de conversación se fusionan en un solo hilo o permanecen separados, dependiendo de si tiene habilitadas las múltiples conversaciones.
## ¿Cuándo fusiona Zendesk las conversaciones?
Las fusiones no ocurren al azar. Zendesk las activa a través de tres mecanismos específicos, cada uno de los cuales sirve para diferentes casos de uso.
### Fusiones de llamadas API
A veces necesita combinar usuarios manualmente. La [API de Sunshine Conversations](https://docs.smooch.io/rest/) le permite activar fusiones programáticamente especificando un ID de usuario superviviente y un ID de usuario descartado. Esto es útil para:
- Limpiar usuarios duplicados después de las importaciones de datos
- Solucionar problemas de identidad descubiertos por su equipo de soporte
- Implementar lógica de fusión personalizada basada en sus reglas de negocio
Aquí hay un ejemplo básico de cómo se ve una llamada de fusión de API:
POST /v1.1/apps/{app_id}/appusers/merge { "surviving": {"_id": "user_a_id"}, "discarded": {"_id": "user_b_id"} }
Tenga cuidado con las fusiones de API en usuarios de SDK. Si un usuario no autenticado se fusiona con un usuario autenticado, su token de sesión se revoca. Necesitarán un nuevo JWT para continuar. Dos usuarios autenticados que se fusionan crean complicaciones con los ID externos. En la mayoría de los casos, es más seguro dejar que Zendesk maneje las fusiones automáticamente a través de la autenticación.
### Fusiones de transferencia de canal
Las transferencias de canal ocurren cuando los clientes quieren continuar las conversaciones a través de diferentes plataformas. Imagine que un cliente comienza a chatear en el widget de su sitio web pero necesita irse. Eligen continuar en WhatsApp en su lugar. Esta transferencia puede desencadenar una fusión si Zendesk determina que ambas identidades representan a la misma persona.
Estas fusiones ocurren a través de dos flujos:
Las **transferencias iniciadas por la empresa** ocurren cuando su sistema ofrece proactivamente el cambio de canal. Por ejemplo, un cliente proporciona su número de teléfono durante un chat web y usted se ofrece a continuar a través de SMS. Cuando el cliente confirma la propiedad de ese número de teléfono, Zendesk fusiona los perfiles de usuario web y SMS.
Las **transferencias iniciadas por el usuario** ocurren cuando los clientes eligen continuar las conversaciones por sí mismos. Un cliente que chatea en su sitio web hace clic en "Continuar en Messenger", autentica su cuenta de Facebook y Zendesk reconoce la conexión entre las dos sesiones.
### Fusiones de eventos de inicio de sesión
El activador de fusión más común es la autenticación. Cuando un usuario no autenticado inicia sesión en su aplicación o sitio web, y ese inicio de sesión coincide con un perfil de usuario existente a través de [ID externo](https://developer.zendesk.com/documentation/conversations/messaging-platform/users/intro-to-users/), Zendesk fusiona los perfiles.
Esto permite una continuidad de conversación perfecta. Un cliente puede navegar por su sitio de forma anónima, iniciar un chat de soporte y luego iniciar sesión en su cuenta a mitad de la conversación. Después de la autenticación, ven su historial de conversación completo y cualquier ticket anterior, todo en un solo lugar.
El usuario superviviente en las fusiones de inicio de sesión es siempre el usuario creado primero. Esto preserva el registro de usuario establecido al tiempo que incorpora datos de la sesión más reciente no autenticada.
## Cómo funciona el proceso de fusión
Comprender la mecánica le ayuda a manejar los casos límite y a construir integraciones adecuadas. Esto es lo que sucede paso a paso cuando Zendesk fusiona usuarios:
**Paso 1: Elección del superviviente**
Antes que nada, Zendesk determina qué usuario sobrevive. Para las fusiones de API, usted especifica esto. Para las transferencias de canal, el usuario que inicia la transferencia se convierte en el superviviente. Para los eventos de inicio de sesión, la cuenta de usuario más antigua gana.
**Paso 2: Consolidación del perfil**
Los campos del perfil del usuario descartado se fusionan en el usuario superviviente. Si ambos perfiles tienen valores conflictivos para el mismo campo (como nombres diferentes), el valor del usuario descartado tiene prioridad. Para la marca de tiempo signedUpAt, se conserva la fecha anterior.
**Paso 3: Fusión de metadatos**
Los metadatos del usuario se combinan, y los valores descartados ganan los conflictos. Sin embargo, hay un límite de 4 KB en el tamaño de los metadatos. Si los metadatos fusionados exceden este límite, Zendesk descarta los campos individuales uno por uno hasta que quepan. El evento webhook le dice qué metadatos se descartaron.
**Paso 4: Consolidación de clientes y dispositivos**
Los clientes conectados (canales de mensajería) y los dispositivos de ambos usuarios se fusionan en una sola lista desduplicada. El usuario superviviente ahora tiene acceso a todos los canales y dispositivos de ambos usuarios originales.
**Paso 5: Manejo de la conversación**
Este paso varía significativamente según su configuración de múltiples conversaciones. Con las múltiples conversaciones deshabilitadas, los historiales de conversación se fusionan en un solo hilo ordenado por marca de tiempo. Con él habilitado, las conversaciones permanecen separadas incluso después de la fusión del usuario.
**Paso 6: Notificación de webhook**
Zendesk dispara un [webhook user:merge](https://developer.zendesk.com/documentation/conversations/messaging-platform/users/merging-users/) que contiene los ID de los objetos supervivientes y descartados, más cualquier metadato descartado. Su sistema debe escuchar estos eventos para actualizar sus propios registros de usuario en consecuencia.
## Comprender las múltiples conversaciones y la fusión
La [función de múltiples conversaciones](https://support.zendesk.com/hc/en-us/articles/8008427696410) cambia fundamentalmente la forma en que funciona la fusión. Esta configuración es irreversible, por lo que es fundamental comprender sus implicaciones antes de habilitarla.
### Sin múltiples conversaciones (predeterminado)
En el modo de conversación única, cuando un usuario se autentica a mitad de la conversación, tanto los perfiles de usuario COMO sus conversaciones se fusionan. La conversación no autenticada se une al historial de conversación del usuario autenticado como un hilo continuo. Esto crea una vista limpia y lineal de todas las interacciones con los clientes.
### Con múltiples conversaciones habilitadas
Cuando las múltiples conversaciones están activas, la fusión de usuarios aún ocurre, pero las conversaciones permanecen separadas. El perfil de usuario autenticado absorbe el perfil no autenticado, pero la conversación permanece distinta. Esto puede crear tickets duplicados para el mismo problema subyacente.
Aquí está el riesgo: si un usuario comienza una conversación antes de iniciar sesión, luego se autentica, termina con dos tickets para lo que debería ser una interacción de soporte. Sus agentes deben identificar y fusionar manualmente estos tickets.
También hay un límite de capacidad. Si bien los usuarios no autenticados pueden tener tickets activos ilimitados, los usuarios autenticados están limitados a 100 tickets activos a la vez. Si un usuario autenticado excede este límite, Zendesk prioriza qué conversaciones muestran el icono de marca de verificación verde en función de la actividad reciente.
### Mejor práctica: Autenticar temprano
Para evitar escenarios de tickets duplicados, autentique a los usuarios ANTES de que comiencen a enviar mensajes siempre que sea posible. Si su sitio web o aplicación requiere inicio de sesión, active la autenticación inmediatamente cuando se cargue el widget de mensajería, no después de que comience la conversación.
## Autenticación, identidad y el flujo de correo electrónico verificado
Uno de los mayores puntos débiles en Zendesk Messaging es la creación de usuarios duplicados. Durante años, los administradores lucharon con usuarios autenticados que creaban nuevos perfiles en lugar de vincularse a los existentes. Zendesk abordó esto a través de la identidad de correo electrónico verificada.
### El problema: Riesgo de identidad no verificada
Anteriormente, si un usuario no autenticado ingresaba una dirección de correo electrónico que coincidía con un perfil existente, Zendesk vinculaba esa conversación al usuario existente. Esto creó una vulnerabilidad de seguridad. Cualquiera podía hacerse pasar por otro cliente simplemente ingresando su dirección de correo electrónico.
### La solución: Identidad de correo electrónico verificada
Zendesk ahora distingue entre identidades de correo electrónico verificadas y no verificadas. Un correo electrónico verificado significa que el usuario se autenticó a través de JWT y demostró la propiedad de esa dirección de correo electrónico. Los agentes ven una marca de verificación verde junto a los usuarios verificados, lo que indica que pueden confiar en la identidad.
### Los 48+ escenarios de flujo simplificados
Un [análisis experto](https://internalnote.com/messaging-authentication-identify-and-merge-existing-users/) mapeó aproximadamente 48 permutaciones de flujo de autenticación diferentes. Si bien la matriz completa es compleja, la mayoría de los escenarios del mundo real se reducen a dos resultados:
**Autenticado + Verificado = Perfil vinculado**
Cuando un usuario se autentica a través de JWT con un external_id que coincide con un usuario de Zendesk existente, y ese usuario tiene un correo electrónico verificado, la conversación se vincula al perfil existente. Los agentes ven la marca de verificación verde y el historial de conversación completo.
**Todos los demás escenarios = Nuevo perfil creado**
Los usuarios no autenticados, o los usuarios autenticados sin external_ids coincidentes, crean nuevos perfiles de usuario. Estos perfiles carecen del estado de verificación de la marca de verificación verde.
### Opciones de configuración
En su Centro de administración en Mensajería > Configuración > Avanzado, encontrará opciones de identidad de correo electrónico:
- **"Usar solo correos electrónicos verificados"** (nuevo valor predeterminado): Máxima seguridad. Solo los usuarios verificados y autenticados se vinculan a los perfiles existentes.
- **"Usar correos electrónicos verificados y no verificados"** (comportamiento heredado): Menos seguro, pero permite que los usuarios no autenticados se vinculen a través de la coincidencia de correo electrónico.
Las nuevas cuentas de Zendesk tienen como valor predeterminado la opción segura. Es posible que las cuentas existentes necesiten un ajuste manual.
## Mejores prácticas para gestionar las fusiones de conversaciones
Después de trabajar en los detalles técnicos, aquí hay recomendaciones prácticas para su implementación:
**Autentique de forma temprana y consistente.** Active la autenticación JWT cuando se inicialice su widget de mensajería, no después de que comience la conversación. Esto previene por completo el problema de los tickets duplicados.
**Maneje los webhooks user:merge.** Construya lógica para recibir y procesar eventos de fusión. Actualice sus registros de usuario internos cuando Zendesk le notifique una fusión para mantener la coherencia de los datos en todos los sistemas.
**Planifique la limpieza de duplicados.** Si utiliza múltiples conversaciones, capacite a los agentes para que identifiquen y fusionen manualmente los tickets creados por la autenticación retrasada. Considere las reglas de automatización para ayudar a marcar posibles duplicados.
**Pruebe los flujos de fusión en el entorno de pruebas.** Antes de ponerlo en marcha, simule escenarios de fusión en su entorno de pruebas. Verifique que la autenticación active la vinculación adecuada, que las transferencias de canal funcionen sin problemas y que sus controladores de webhook respondan correctamente.
**Documente sus decisiones de autenticación.** La complejidad de la configuración de identidad de correo electrónico significa que su equipo necesita documentación clara sobre qué configuración eligió y por qué. Incluya pasos de solución de problemas para problemas de identidad comunes.
**Considere enfoques alternativos.** Si bien Zendesk proporciona potentes capacidades de fusión, algunos equipos encuentran que las plataformas de soporte impulsadas por IA manejan la resolución de identidad entre canales de manera más fluida. Soluciones como [eesel AI](https://www.eesel.ai/integration/zendesk-ai) unifican automáticamente el contexto del cliente a través de los canales sin requerir una lógica de fusión compleja o implementaciones de JWT.
## Implementación de la fusión de conversaciones en su configuración de Zendesk
¿Listo para poner esto en práctica? Aquí está su lista de verificación de implementación:
**Antes de habilitar las múltiples conversaciones:**
- Confirme que su flujo de autenticación funcione correctamente
- Verifique que los tokens JWT incluyan external_id que coincida con su base de datos de usuarios
- Pruebe la experiencia del usuario con escenarios de autenticación retrasada
- Documente la decisión (recuerde: no puede revertir)
**Lista de verificación de integración de API:**
- Implemente el controlador de webhook user:merge
- Construya lógica para consultar a los usuarios existentes antes de crear otros nuevos
- Agregue monitoreo para errores relacionados con la fusión
**Errores comunes que se deben evitar:**
- No confíe únicamente en la coincidencia de correo electrónico para la identidad (riesgo de seguridad)
- No autentique a los usuarios a mitad de la conversación sin comprender las implicaciones del ticket
- No ignore el límite de metadatos de 4 KB durante las fusiones
- No olvide actualizar sus propios sistemas cuando se produzcan fusiones
Recursos para lectura adicional:
- [Documentación para desarrolladores de Zendesk para fusionar usuarios](https://developer.zendesk.com/documentation/conversations/messaging-platform/users/merging-users/)
- [Autenticación de usuarios en su aplicación](https://developer.zendesk.com/documentation/conversations/messaging-platform/users/authenticating-users-your-app/)
- [Guía de configuración de múltiples conversaciones](https://support.zendesk.com/hc/en-us/articles/8008427696410)
Compartir esta entrada
Article by
