zendesk-messaging-conversation-merge
Written by
eesel Team
Last edited 24 fevereiro 2026
{
"title": "União de conversas no Zendesk Messaging: Um guia técnico completo",
"slug": "zendesk-messaging-conversation-merge",
"locale": "pt",
"date": "2026-02-20",
"updated": "2026-02-20",
"template": "default",
"excerpt": "Um guia abrangente para entender e implementar a união de conversas no Zendesk Messaging, incluindo fluxos de autenticação e comportamento de múltiplas conversas.",
"categories": [
"Blog Writer AI"
],
"tags": [
"Zendesk",
"Messaging",
"Customer Support",
"User Management",
"API"
],
"readTime": 10,
"author": 16,
"reviewer": 14,
"seo": {
"title": "União de conversas no Zendesk Messaging: Um guia técnico completo",
"description": "Um guia abrangente para entender e implementar a união de conversas no Zendesk Messaging, incluindo fluxos de autenticação e comportamento de múltiplas conversas.",
"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": "Imagem do banner para união de conversas no Zendesk Messaging: Um guia técnico completo",
"coverImageWidth": 1920,
"coverImageHeight": 1080,
"faqs": {
"heading": "Perguntas Frequentes",
"type": "blog",
"answerType": "html",
"faqs": [
{
"question": "Como o processo de união de conversas do Zendesk Messaging lida com conflitos de metadados?",
"answer": "Quando os perfis de usuário são unidos, os metadados do usuário descartado têm precedência em conflitos. No entanto, há um limite de tamanho total de 4 KB. Se os metadados combinados excederem esse limite, o Zendesk remove os campos individuais um por um até que caibam. O webhook user:merge inclui informações sobre quaisquer metadados descartados para que seus sistemas possam lidar com isso adequadamente."
},
{
"question": "Você pode desabilitar o comportamento de união de conversas do Zendesk Messaging depois que múltiplas conversas são habilitadas?",
"answer": "Não. Habilitar múltiplas conversas é irreversível. Uma vez ativado, os registros de usuário ainda são unidos durante a autenticação, mas os históricos de conversas permanecem separados. Você não pode reverter para o modo de conversa única, onde as conversas se combinam em um único tópico. Planeje cuidadosamente e teste completamente antes de habilitar este recurso."
},
{
"question": "O que acontece com as sessões ativas quando ocorre uma união de conversas do Zendesk Messaging?",
"answer": "Depende do tipo de união. Para uniões de API envolvendo usuários do SDK, os tokens de sessão não autenticados são revogados quando unidos a usuários autenticados. O usuário precisa de um novo JWT para continuar. Para uniões de eventos de login, as conexões websocket ativas recebem tokens de sessão atualizados automaticamente. As uniões de transferência de canal normalmente mantêm a continuidade da sessão, pois o usuário está participando ativamente da transferência."
},
{
"question": "Por que a união de conversas do Zendesk Messaging cria tickets duplicados em alguns cenários?",
"answer": "Tickets duplicados ocorrem com múltiplas conversas habilitadas quando os usuários se autenticam no meio da conversa. O perfil do usuário é unido, mas a conversa ativa permanece separada das anteriores, criando vários tickets para o mesmo problema subjacente. Autentique os usuários antes de iniciarem a mensagem para evitar isso."
},
{
"question": "Como solucionar problemas quando a união de conversas do Zendesk Messaging não se vincula a usuários existentes?",
"answer": "Primeiro, verifique se o seu JWT inclui o external_id correto que corresponde aos seus registros de usuário do Zendesk. Verifique se o usuário tem uma identidade de e-mail verificada. Revise as configurações do seu Admin Center para confirmar se 'Usar apenas e-mails verificados' não está bloqueando a vinculação legítima. Finalmente, verifique os logs do webhook user:merge para obter detalhes do erro."
},
{
"question": "Quais riscos de segurança existem com a funcionalidade de união de conversas do Zendesk Messaging?",
"answer": "O principal risco é a representação de e-mail. Sem as configurações de identidade de e-mail verificada, qualquer pessoa que inserir o endereço de e-mail de outra pessoa pode ter sua conversa vinculada ao perfil dessa pessoa. Sempre use a configuração 'Usar apenas e-mails verificados' para segurança. Além disso, lide com os eventos de webhook de união com segurança e valide se as operações de união são legítimas em seus logs de sistema."
}
],
"supportLink": null
}
}
---
Quando seus clientes entram em contato por meio de vários canais, eles esperam que você se lembre de quem eles são. Mas no Zendesk Messaging, as identidades dos usuários podem se fragmentar. Um cliente pode começar no seu site, continuar no WhatsApp e dar seguimento por e-mail, criando três perfis de usuário separados. É aqui que a união de conversas se torna essencial.
Entender como o Zendesk lida com a união de usuários e conversas ajuda você a construir uma experiência de suporte perfeita. Vamos detalhar como o processo funciona, quando ele é acionado e o que você precisa saber para gerenciá-lo de forma eficaz.
## O Que É União de Conversas no Zendesk Messaging?
A união de conversas no [Zendesk Messaging](https://www.zendesk.com/messaging) é o processo de combinar perfis de usuário separados e seus históricos de conversas associados em um único registro unificado. Isso é importante porque, sem a união adequada, seus agentes veem interações fragmentadas com os clientes. Um cliente recorrente pode aparecer como três pessoas diferentes, forçando os agentes a procurar em vários tickets para entender o contexto completo.
É importante distinguir entre dois conceitos relacionados:
**União de usuários** combina dois perfis de usuário em um. O usuário "sobrevivente" retém a identidade unida, enquanto o usuário "descartado" é excluído. Todos os dados do perfil, metadados e históricos de conversas são transferidos para o usuário sobrevivente.
**União de conversas** refere-se especificamente à combinação de tópicos de conversa separados em um único histórico. Isso acontece automaticamente em alguns cenários, mas não em outros, dependendo da sua configuração.
O processo de união afeta vários pontos de dados. Quando os usuários são unidos, suas informações de perfil são combinadas, com os valores do usuário descartado tendo precedência em conflitos. Os metadados também são unidos, mas permanecem dentro de um limite de tamanho de 4 KB. As listas de clientes e dispositivos são desduplicadas e combinadas. Mais importante, os históricos de conversas são unidos em um único tópico ou permanecem separados, dependendo se você tem múltiplas conversas habilitadas.
## Quando o Zendesk Une Conversas?
As uniões não acontecem aleatoriamente. O Zendesk as aciona por meio de três mecanismos específicos, cada um atendendo a diferentes casos de uso.
### Uniões por Chamada de API
Às vezes, você precisa combinar usuários manualmente. A [API Sunshine Conversations](https://docs.smooch.io/rest/) permite que você acione uniões programaticamente, especificando um ID de usuário sobrevivente e um ID de usuário descartado. Isso é útil para:
- Limpar usuários duplicados após importações de dados
- Corrigir problemas de identidade descobertos pela sua equipe de suporte
- Implementar lógica de união personalizada com base nas suas regras de negócios
Aqui está um exemplo básico de como uma chamada de união de API se parece:
POST /v1.1/apps/{app_id}/appusers/merge { "surviving": {"_id": "user_a_id"}, "discarded": {"_id": "user_b_id"} }
Tenha cuidado com as uniões de API em usuários do SDK. Se um usuário não autenticado for unido a um usuário autenticado, seu token de sessão será revogado. Eles precisarão de um novo JWT para continuar. Dois usuários autenticados sendo unidos criam complicações com IDs externos. Na maioria dos casos, deixar o Zendesk lidar com as uniões automaticamente por meio da autenticação é mais seguro.
### Uniões por Transferência de Canal
As transferências de canal ocorrem quando os clientes desejam continuar as conversas em diferentes plataformas. Imagine que um cliente começa a conversar no widget do seu site, mas precisa sair. Eles escolhem continuar no WhatsApp. Essa transferência pode acionar uma união se o Zendesk determinar que ambas as identidades representam a mesma pessoa.
Essas uniões acontecem por meio de dois fluxos:
**Transferências iniciadas pela empresa** acontecem quando seu sistema oferece proativamente a troca de canais. Por exemplo, um cliente fornece seu número de telefone durante um bate-papo na web e você oferece continuar via SMS. Quando o cliente confirma a propriedade desse número de telefone, o Zendesk une os perfis de usuário da web e SMS.
**Transferências iniciadas pelo usuário** ocorrem quando os clientes escolhem continuar as conversas sozinhos. Um cliente conversando no seu site clica em "Continuar no Messenger", autentica sua conta do Facebook e o Zendesk reconhece a conexão entre as duas sessões.
### Uniões por Evento de Login
O gatilho de união mais comum é a autenticação. Quando um usuário não autenticado faz login no seu aplicativo ou site, e esse login corresponde a um perfil de usuário existente por meio de [ID externo](https://developer.zendesk.com/documentation/conversations/messaging-platform/users/intro-to-users/), o Zendesk une os perfis.
Isso permite uma continuidade de conversa perfeita. Um cliente pode navegar no seu site anonimamente, iniciar um bate-papo de suporte e, em seguida, fazer login na sua conta no meio da conversa. Após a autenticação, eles veem todo o seu histórico de conversas e quaisquer tickets anteriores, tudo em um só lugar.
O usuário sobrevivente nas uniões de login é sempre o usuário criado primeiro. Isso preserva o registro de usuário estabelecido enquanto incorpora dados da sessão mais recente e não autenticada.
## Como o Processo de União Funciona
Entender a mecânica ajuda você a lidar com casos extremos e construir integrações adequadas. Veja o que acontece passo a passo quando o Zendesk une usuários:
**Passo 1: Eleição do sobrevivente**
Antes de mais nada, o Zendesk determina qual usuário sobrevive. Para uniões de API, você especifica isso. Para transferências de canal, o usuário que inicia a transferência se torna o sobrevivente. Para eventos de login, a conta de usuário mais antiga vence.
**Passo 2: Consolidação do perfil**
Os campos de perfil do usuário descartado são unidos ao usuário sobrevivente. Se ambos os perfis tiverem valores conflitantes para o mesmo campo (como nomes diferentes), o valor do usuário descartado tem precedência. Para o timestamp signedUpAt, a data mais antiga é mantida.
**Passo 3: União de metadados**
Os metadados do usuário são combinados, com os valores descartados vencendo os conflitos. No entanto, há um limite de 4 KB no tamanho dos metadados. Se os metadados unidos excederem esse limite, o Zendesk descarta os campos individuais um por um até que caibam. O evento de webhook informa quais metadados foram descartados.
**Passo 4: Consolidação de clientes e dispositivos**
Os clientes conectados (canais de mensagens) e dispositivos de ambos os usuários são unidos em uma única lista desduplicada. O usuário sobrevivente agora tem acesso a todos os canais e dispositivos de ambos os usuários originais.
**Passo 5: Tratamento da conversa**
Esta etapa varia significativamente com base na sua configuração de múltiplas conversas. Com múltiplas conversas desabilitadas, os históricos de conversas são unidos em um único tópico classificado por timestamp. Com ele habilitado, as conversas permanecem separadas mesmo após a união do usuário.
**Passo 6: Notificação de webhook**
O Zendesk dispara um [webhook user:merge](https://developer.zendesk.com/documentation/conversations/messaging-platform/users/merging-users/) contendo IDs de objetos sobreviventes e descartados, além de quaisquer metadados descartados. Seu sistema deve ficar atento a esses eventos para atualizar seus próprios registros de usuário de acordo.
## Entendendo Múltiplas Conversas e União
O [recurso de múltiplas conversas](https://support.zendesk.com/hc/en-us/articles/8008427696410) muda fundamentalmente como a união funciona. Essa configuração é irreversível, portanto, entender suas implicações antes de habilitá-la é fundamental.
### Sem Múltiplas Conversas (Padrão)
No modo de conversa única, quando um usuário se autentica no meio da conversa, tanto os perfis de usuário QUANTO suas conversas são unidos. A conversa não autenticada se junta ao histórico de conversas do usuário autenticado como um tópico contínuo. Isso cria uma visão limpa e linear de todas as interações com o cliente.
### Com Múltiplas Conversas Habilitadas
Quando múltiplas conversas estão ativas, a união de usuários ainda ocorre, mas as conversas permanecem separadas. O perfil de usuário autenticado absorve o perfil não autenticado, mas a conversa permanece distinta. Isso pode criar tickets duplicados para o mesmo problema subjacente.
Aqui está o risco: se um usuário inicia uma conversa antes de fazer login e, em seguida, se autentica, você acaba com dois tickets para o que deveria ser uma interação de suporte. Seus agentes devem identificar e unir manualmente esses tickets.
Há também um limite de capacidade. Embora os usuários não autenticados possam ter tickets ativos ilimitados, os usuários autenticados são limitados a 100 tickets ativos por vez. Se um usuário autenticado exceder esse limite, o Zendesk prioriza quais conversas exibem o ícone de marca de seleção verde com base na atividade recente.
### Prática Recomendada: Autentique Cedo
Para evitar cenários de tickets duplicados, autentique os usuários ANTES que eles iniciem a mensagem sempre que possível. Se seu site ou aplicativo exigir login, acione a autenticação imediatamente quando o widget de mensagens for carregado, não depois que a conversa começar.
## Autenticação, Identidade e o Fluxo de E-mail Verificado
Um dos maiores pontos problemáticos no Zendesk Messaging é a criação de usuários duplicados. Por anos, os administradores lutaram com usuários autenticados criando novos perfis em vez de se vincularem aos existentes. O Zendesk resolveu isso por meio da identidade de e-mail verificada.
### O Problema: Risco de Identidade Não Verificada
Anteriormente, se um usuário não autenticado inserisse um endereço de e-mail correspondente a um perfil existente, o Zendesk vincularia essa conversa ao usuário existente. Isso criou uma vulnerabilidade de segurança. Qualquer pessoa poderia se passar por outro cliente simplesmente inserindo seu endereço de e-mail.
### A Solução: Identidade de E-mail Verificada
O Zendesk agora distingue entre identidades de e-mail verificadas e não verificadas. Um e-mail verificado significa que o usuário se autenticou por meio de JWT e provou a propriedade desse endereço de e-mail. Os agentes veem uma marca de seleção verde ao lado dos usuários verificados, indicando que podem confiar na identidade.
### Os 48+ Cenários de Fluxo Simplificados
Uma [análise especializada](https://internalnote.com/messaging-authentication-identify-and-merge-existing-users/) mapeou aproximadamente 48 permutações diferentes de fluxo de autenticação. Embora a matriz completa seja complexa, a maioria dos cenários do mundo real se resume a dois resultados:
**Autenticado + Verificado = Perfil Vinculado**
Quando um usuário se autentica via JWT com um external_id correspondente a um usuário Zendesk existente, e esse usuário tem um e-mail verificado, a conversa é vinculada ao perfil existente. Os agentes veem a marca de seleção verde e o histórico completo de conversas.
**Todos os Outros Cenários = Novo Perfil Criado**
Usuários não autenticados ou usuários autenticados sem external_ids correspondentes criam novos perfis de usuário. Esses perfis não têm o status de verificação de marca de seleção verde.
### Opções de Configuração
No seu Admin Center em Messaging > Settings > Advanced, você encontrará opções de identidade de e-mail:
- **"Usar apenas e-mails verificados"** (novo padrão): Segurança máxima. Apenas usuários verificados e autenticados se vinculam a perfis existentes.
- **"Usar e-mails verificados e não verificados"** (comportamento legado): Menos seguro, mas permite que usuários não autenticados se vinculem por meio da correspondência de e-mail.
Novas contas do Zendesk são padronizadas para a opção segura. As contas existentes podem precisar de ajuste manual.
## Práticas Recomendadas para Gerenciar Uniões de Conversas
Depois de trabalhar nos detalhes técnicos, aqui estão as recomendações práticas para sua implementação:
**Autentique cedo e consistentemente.** Acione a autenticação JWT quando seu widget de mensagens for inicializado, não depois que a conversa começar. Isso evita completamente o problema de tickets duplicados.
**Lide com webhooks user:merge.** Crie lógica para receber e processar eventos de união. Atualize seus registros de usuário internos quando o Zendesk notificar você sobre uma união para manter a consistência dos dados entre os sistemas.
**Planeje a limpeza de duplicados.** Se você usar múltiplas conversas, treine os agentes para identificar e unir manualmente os tickets criados pela autenticação atrasada. Considere regras de automação para ajudar a sinalizar possíveis duplicados.
**Teste os fluxos de união em staging.** Antes de entrar em operação, simule cenários de união no seu ambiente de staging. Verifique se a autenticação aciona a vinculação adequada, as transferências de canal funcionam sem problemas e seus manipuladores de webhook respondem corretamente.
**Documente suas decisões de autenticação.** A complexidade das configurações de identidade de e-mail significa que sua equipe precisa de documentação clara sobre qual configuração você escolheu e por quê. Inclua etapas de solução de problemas para problemas de identidade comuns.
**Considere abordagens alternativas.** Embora o Zendesk forneça poderosos recursos de união, algumas equipes descobrem que as plataformas de suporte alimentadas por IA lidam com a resolução de identidade entre canais de forma mais integrada. Soluções como [eesel AI](https://www.eesel.ai/integration/zendesk-ai) unificam automaticamente o contexto do cliente entre os canais sem exigir lógica de união complexa ou implementações de JWT.
## Implementando a União de Conversas na Sua Configuração do Zendesk
Pronto para colocar isso em prática? Aqui está sua lista de verificação de implementação:
**Antes de habilitar múltiplas conversas:**
- Confirme se o seu fluxo de autenticação funciona corretamente
- Verifique se os tokens JWT incluem external_id correspondente ao seu banco de dados de usuários
- Teste a experiência do usuário com cenários de autenticação atrasada
- Documente a decisão (lembre-se: você não pode reverter)
**Lista de verificação de integração de API:**
- Implemente o manipulador de webhook user:merge
- Crie lógica para consultar usuários existentes antes de criar novos
- Adicione monitoramento para erros relacionados à união
**Armadilhas comuns a evitar:**
- Não confie apenas na correspondência de e-mail para identidade (risco de segurança)
- Não autentique usuários no meio da conversa sem entender as implicações do ticket
- Não ignore o limite de metadados de 4 KB durante as uniões
- Não se esqueça de atualizar seus próprios sistemas quando as uniões ocorrerem
Recursos para leitura adicional:
- [Documentação do Desenvolvedor do Zendesk para União de Usuários](https://developer.zendesk.com/documentation/conversations/messaging-platform/users/merging-users/)
- [Autenticando Usuários no Seu Aplicativo](https://developer.zendesk.com/documentation/conversations/messaging-platform/users/authenticating-users-your-app/)
- [Guia de Configuração de Múltiplas Conversas](https://support.zendesk.com/hc/en-us/articles/8008427696410)
Compartilhe esta postagem
Article by
