Entender as falhas de entrega delivery-failures
As rejeições são o resultado de uma tentativa de entrega e falha em que o ISP fornece avisos de falha. O processamento do tratamento de rejeição é uma parte essencial da higiene das listas. Depois que um determinado email é rejeitado várias vezes consecutivas, esse processo o sinaliza para supressão.
Esse processo impede que os sistemas continuem enviando endereços de email inválidos. As rejeições são um dos dados principais que os ISPs usam para determinar a reputação do IP. É importante acompanhar essa métrica. "Entregue" versus "rejeitado" é provavelmente a maneira mais comum de medir a entrega de mensagens de marketing: quanto maior a porcentagem entregue, melhor.
Se uma mensagem não puder ser enviada a um perfil, o servidor remoto enviará automaticamente uma mensagem de erro ao Adobe Campaign. Esse erro é qualificado para determinar se o endereço de email, o número de telefone ou o dispositivo deve ir para a quarentena. Consulte Gerenciamento de emails de devolução.
Depois que uma mensagem for enviada, você poderá visualizar o status do delivery para cada perfil, o tipo de falha e o motivo associados nos logs do delivery.
Quando um endereço de email está em quarentena ou se um perfil está na inclui na lista de bloqueios, o recipient é excluído na etapa de preparação do delivery. As mensagens excluídas são listadas no painel de entrega.
Por que a entrega da mensagem falhou? delivery-failure-reasons
Há dois tipos de erros quando uma mensagem falha. Cada tipo de falha de entrega determina se um endereço será enviado para a quarentena ou não.
-
Devoluções permanentes
As rejeições permanentes são falhas permanentes geradas depois que um ISP determina uma tentativa de envio por email para um endereço de assinante como não entregue. No Adobe Campaign, as rejeições permanentes categorizadas como não entregues são adicionadas à lista de quarentena, o que significa que elas não terão nova tentativa. Há alguns casos em que uma rejeição permanente é ignorada se a causa da falha for desconhecida.Estes são alguns exemplos comuns de rejeições permanentes: Endereço não existe, Conta desabilitada, Sintaxe incorreta, Domínio inválido
-
Rejeições temporárias
As rejeições temporárias são falhas temporárias que os ISPs geram quando têm dificuldade em entregar emails. As falhas leves serão repetidas várias vezes (com variação dependendo do uso de configurações de entrega personalizadas ou predefinidas) para tentar uma entrega bem-sucedida. Os endereços que continuamente emitem rejeição não serão adicionados à quarentena até que o número máximo de tentativas tenha sido atingido (o que novamente varia de acordo com as configurações).Algumas causas comuns de rejeições temporárias incluem: Caixa de entrada cheia, Servidor de email de recebimento inativo, Problemas de reputação do remetente
O tipo de erro Ignorado é conhecido como temporário, como "Ausente", ou um erro técnico, por exemplo, se o tipo de remetente for "postmaster".
O loop de feedback funciona como emails de devolução: quando um usuário qualifica um email como spam, você pode configurar regras de email no Adobe Campaign para bloquear todos os deliveries a esse usuário. Incluir na lista de bloqueios Os endereços desses usuários são classificados mesmo que não tenham clicado no link de cancelamento de subscrição. Os endereços são adicionados à tabela de quarentena (NmsAddress) e não à tabela de recipient (NmsRecipient) com o status Denylisted. Saiba mais sobre o mecanismo de loop de comentários no Manual de práticas recomendadas de capacidade de entrega do Adobe.
Erros síncronos e assíncronos synchronous-and-asynchronous-errors
Um delivery de mensagem pode falhar imediatamente, nesse caso, qualificamos isso como um erro síncrono. Se o envio da mensagem falhar ou depois, depois de ter sido enviado, o erro será assíncrono.
Esses tipos de erros são gerenciados da seguinte maneira:
-
Erro síncrono: o servidor remoto contatado pelo servidor de entrega do Adobe Campaign retorna imediatamente uma mensagem de erro. O delivery não tem permissão para ser enviado ao servidor do perfil. O Mail Transfer Agent (MTA) determina o tipo de rejeição e qualifica o erro e envia essas informações para o Campaign para determinar se os endereços de email devem ser colocados em quarentena. Consulte Qualificação de email de devolução.
-
Erro assíncrono: um email de devolução ou um Relatório de Status será reenviado posteriormente pelo servidor receptor. Esse erro é qualificado com um rótulo relacionado ao erro. Podem ocorrer erros assíncronos até uma semana depois da entrega.
Qualificação de email de rejeição bounce-mail-qualification
A maneira como a qualificação de emails rejeitados é tratada no Adobe Campaign depende do tipo de erro:
-
Erros síncronos: o MTA determina o tipo de rejeição e a qualificação e retorna essas informações ao Campaign. As qualificações de rejeição na tabela Delivery log qualification não são usadas para mensagens de erro de falha de entrega síncrona.
-
Erros assíncronos: as regras usadas pelo Campaign para qualificar falhas de entrega assíncronas estão listadas no nó Administration > Campaign Management > Non deliverables Management > Delivery log qualification. As rejeições assíncronas são qualificadas pelo processo do InMail por meio das regras Inbound email.
Gerenciamento de tentativas retries
Se a entrega da mensagem falhar após um erro temporário (Soft ou Ignored), o Campaign tentará enviar novamente. Essas tentativas podem ser executadas até o final da duração do delivery.
As tentativas de rejeição temporária e o tempo entre elas são determinados pelo MTA com base no tipo e na gravidade das respostas de rejeição que retornam do domínio de email da mensagem.
Período de validade valid-period
A configuração do período de validade em seus deliveries do Campaign é limitada a 3,5 dias ou menos. Para um delivery, se você definir um valor superior a 3,5 dias no Campaign, ele não será considerado.
Por exemplo, se o período de validade for definido como o valor padrão de 5 dias no Campaign, as mensagens com rejeição temporária entrarão na fila de tentativas do MTA e serão repetidas apenas por até 3,5 dias a partir do momento em que a mensagem chegar ao MTA. Nesse caso, o valor definido no Campaign não será usado.
Quando uma mensagem estiver na fila do MTA por 3,5 dias e não for entregue, o tempo limite expirará, e seu status será atualizado de Sent para Failed nos logs de entrega.
Tipos de erro de email email-error-types
Para o canal de email, os possíveis motivos para uma falha de delivery estão listados abaixo.
| table 0-row-4 1-row-4 2-row-4 3-row-4 4-row-4 5-row-4 6-row-4 7-row-4 8-row-4 9-row-4 10-row-4 11-row-4 12-row-4 13-row-4 14-row-4 15-row-4 16-row-4 17-row-4 18-row-4 19-row-4 20-row-4 html-authored no-header | |||
|---|---|---|---|
| Rótulo de erro | Tipo de erro | Valor técnico | Descrição |
| Conta desabilitada | Suave/Grave | 4 | A conta vinculada ao endereço não está mais ativa. Quando o Fornecedor de Acesso à Internet (IAP) detecta um longo período de inatividade, ele pode fechar a conta do usuário. As entregas ao endereço do usuário serão impossíveis. Se a conta estiver temporariamente desabilitada devido a seis meses de inatividade e ainda puder ser ativada, o status Com erros será atribuído e a conta terá nova tentativa até que o contador de erro atinja 5. Se o erro indicar que a conta está desativada permanentemente, ela será enviada diretamente à quarentena. |
| Endereço em quarentena | Grave | 9 | O endereço foi colocado em quarentena. |
| Endereço não especificado | Grave | 7 | Nenhum endereço é fornecido para o destinatário. |
| Endereço Bad-quality | Ignored | 14 | A classificação de qualidade deste endereço é muito baixa. |
| Endereço na lista de bloqueios | Grave | 8 | O endereço foi adicionado à lista de bloqueios no momento do envio. Esse status é usado para importar dados de listas externas e sistemas externos para a lista de quarentena do Adobe Campaign. |
| Endereço de controle | Ignored | 127 | O endereço do destinatário faz parte do grupo de controle. |
| Duplo | Ignored | 10 | O endereço do destinatário já estava nessa entrega. |
| Erro ignorado | Ignored | 25 | O endereço está na lista de permissões. O erro é então ignorado e um email será enviado. |
| Excluído após arbitragem | Ignored | 12 | O destinatário foi excluído por uma regra de tipologia de 'arbitragem' de campanha. |
| Excluído por uma regra SQL | Ignored | 11 | O destinatário foi excluído por uma regra de tipologia de campanha do tipo "SQL". |
| Domínio inválido | Suave | 2 | O domínio do endereço de email está incorreto ou não existe mais. Este perfil será alvo novamente até que a contagem de erros chegue a 5. Após isso, o registro será definido como Status de Quarentena e não haverá nenhuma tentativa nova. |
| Caixa de entrada cheia | Suave | 5 | A caixa de entrada deste usuário está cheia e não pode receber mais mensagens. Este perfil será alvo novamente até que a contagem de erros chegue a 5. Após isso, o registro será definido como Status de Quarentena e não haverá nenhuma tentativa nova. Esse tipo de erro é gerenciado por um processo de limpeza, o endereço é definido como um status válido após 30 dias. Aviso: para que o endereço seja removido automaticamente da lista de endereços em quarentena, o fluxo de trabalho técnico de Limpeza do banco de dados deve ser iniciado. |
| Não conectado | Ignored | 6 | O telefone celular do destinatário está desligado ou não conectado à rede quando a mensagem é enviada. |
| Não definido | Não definido | 0 | O endereço está em qualificação porque o erro ainda não foi incrementado. Esse tipo de erro ocorre quando uma nova mensagem de erro é enviada pelo servidor: pode ser um erro isolado, mas se ocorrer novamente, o contador de erros aumentará, o que alertará as equipes técnicas. Em seguida, eles podem realizar a análise de mensagens e qualificar esse erro, por meio do nó Administration / Campainha Management / Non deliverables Management na estrutura da árvore. |
| Não se qualifica para as ofertas | Ignored | 16 | O destinatário não foi qualificado para as ofertas na entrega. |
| Recusado | Suave/Grave | 20 | O endereço foi colocado em quarentena devido a um feedback de segurança como um relatório de spam. De acordo com o erro, haverá nova tentativa ao endereço até que o contador de erros atinja 5, ou ele será enviado diretamente para a quarentena. |
| Target limitado em tamanho | Ignored | 17 | O tamanho máximo de entrega foi atingido para o destinatário. |
| Endereço não qualificado | Ignored | 15 | O endereço postal não foi qualificado. |
| Inacessível | Suave/Grave | 3 | Ocorreu um erro na cadeia de entrega de mensagens. Pode ser um incidente na retransmissão SMTP, um domínio que está temporariamente inacessível, etc. De acordo com o erro, haverá nova tentativa ao endereço até que o contador de erros atinja 5, ou ele será enviado diretamente para a quarentena. |
| Usuário desconhecido | Grave | 1 | O endereço não existe. Não haverá mais tentativas de entrega para este perfil. |
Tipos de erro de notificações por push push-error-types
Para o canal de aplicativo móvel, os possíveis motivos para uma falha de delivery estão listados abaixo.
Quarentena do iOS ios-quarantine
O protocolo HTTP/V2 permite um feedback e status direto para cada entrega por push. Se o conector do protocolo HTTP/V2 for usado, o serviço de feedback não será mais chamado pelo fluxo de trabalho mobileAppOptOutMgt. Um token é considerado não registrado quando um aplicativo móvel é desinstalado ou reinstalado.
Em sincronia, se o APNs retornar um status "não registrado" para uma mensagem, o token do público alvo será colocado imediatamente em quarentena.
| table 0-row-6 1-row-6 2-row-6 3-row-6 4-row-6 5-row-6 6-row-6 7-row-6 8-row-6 9-row-6 html-authored no-header | |||||
|---|---|---|---|---|---|
| Cenário | Status | Mensagem de erro | Tipo de falha | Motivo da falha | Tentativa |
| Dispositivo alvo ligado | Ok | ||||
| Dispositivo alvo desligado | Ok | ||||
| O usuário desabilita notificações para o aplicativo | Ok | ||||
| Fase de análise/criação de mensagens - carga muito grande | Falha | Carga muito longa | Suave | Recusado | Não |
| Fase de análise/criação de mensagens – problema inesperado de formato de conteúdo | Falha | Várias mensagens de erro de acordo com o erro | Suave | Indefinido | Não |
| Problema de certificado (senha, corrupção, etc.) e teste de conexão para problema APNs | Falha | Várias mensagens de erro de acordo com o erro | Suave | Recusado | Não |
| Conexão de rede perdida durante o envio | Falha | Erro de conexão | Indefinido | Inacessível | Sim |
| Rejeição da mensagem APNs: cancelamento de registro o usuário removeu o aplicativo ou o token expirou |
Falha | Registro cancelado | Grave | Usuário desconhecido | Não |
| Rejeição de mensagem APNs: todos os outros erros | Falha | A causa de rejeição do erro será exibida na mensagem de erro | Suave | Recusado | Não |
Quarentena do Android android-quarantine
Para Android V1
A cada notificação, o Adobe Campaign recebe os erros síncronos diretamente do servidor FCM. O Adobe Campaign os trata dinamicamente e gera erros graves ou suaves, de acordo com a gravidade do erro, e tentativas podem ser executadas:
- Comprimento de carga excedido, problema de conexão, problema de disponibilidade de serviço: tentativa executava, erro leve, o motivo da falha é Refused.
- Cota de dispositivo excedida: sem tentativa, erro leve, o motivo da falha é Refused.
- Token inválido ou não registrado, erro inesperado, problema da conta do remetente: sem tentativa, erro grave, o motivo de falha é Refused.
O fluxo de trabalho mobileAppOptOutMgt é executado a cada 6 horas para atualizar a tabela AppSubscriptionRcp. Para os tokens declarados não registrados ou inválidos, o campo Desabilitado é definido como Verdadeiro e a subscrição vinculada a esse token de dispositivo será excluída automaticamente das entregas futuras.
Durante a análise de entrega, todos os dispositivos excluídos do target são automaticamente adicionados à tabela excludeLogAppSubRcp .
- Problema de conexão no início da entrega: falha do tipo Undefined, razão da falha Unreachable, a tentativa é executada.
- Perda de conexão durante uma entrega: erro leve, razão da falha Refused, a tentativa é executada.
- Erro síncrono retornado pelo Baidu durante o envio: erro grave, motivo da falha Refused, não haverá nova tentativa.
Para Android V2
O mecanismo de quarentena do Android V2 usa o mesmo processo que o Android V1, o mesmo se aplica à atualização de assinaturas e exclusões. Para obter mais informações, consulte a seção Android V1
| table 0-row-6 1-row-6 2-row-6 3-row-6 4-row-6 5-row-6 6-row-6 7-row-6 8-row-6 9-row-6 10-row-6 11-row-6 12-row-6 13-row-6 14-row-6 15-row-6 16-row-6 17-row-6 18-row-6 19-row-6 20-row-6 21-row-6 22-row-6 23-row-6 24-row-6 html-authored no-header | |||||
|---|---|---|---|---|---|
| Cenário | Status | Mensagem de erro | Tipo de falha | Motivo da falha | Tentativa |
| Fase de análise/criação de mensagens: palavras-chave ilegais usadas nos campos personalizados | Falha | As seguintes palavras-chave não podem ser usadas: {1} | Suave | Não | |
| Fase de análise/criação de mensagens: carga muito grande | Falha | A notificação é muito pesada: {1} bits, enquanto apenas {2} estão autorizados | Suave | Recusado | Não |
| Conexão de rede perdida durante o envio | Falha | Nenhuma resposta do serviço Firebase Cloud Messaging no endereço: {1} | Suave | Inacessível | Sim |
| Rejeição da mensagem FCM: o servidor FCM está temporariamente indisponível (por exemplo, com tempos limites). | Falha | O serviço Firebase Cloud Messaging está temporariamente indisponível | Suave | Inacessível | Sim |
| Rejeição da mensagem FCM: erro ao autenticar a conta do remetente | Falha | Falha ao identificar a conta do desenvolvedor, verifique seu ID e senha | Suave | Recusado | Não |
| Rejeição da mensagem FCM: cota do dispositivo excedida | Falha | Suave | Recusado | Sim | |
| Rejeição da mensagem FCM: registro inválido/não registrado | Falha | Grave | Usuário desconhecido | Não | |
| Rejeição da mensagem FCM: todos os outros erros | Falha | O servidor Firebase Cloud Messaging retornou um código de erro inesperado: {1} | Recusado | Não | |
| Rejeição da mensagem FCM: argumento inválido | Falha | INVALID_ARGUMENT | Ignorado | Indefinido | Não |
| Rejeição da mensagem FCM: erro de autenticação de terceiros | Falha | THIRD_PARTY_AUTH_ERROR | Ignorado | Recusado | Sim |
| Rejeição da mensagem FCM: incompatibilidade de ID do remetente | Falha | SENDER_ID_MISMATCH | Suave | Usuário desconhecido | Não |
| Rejeição da mensagem FCM: não registrado | Falha | REGISTRO CANCELADO | Grave | Usuário desconhecido | Não |
| Rejeição da mensagem FCM: interno | Falha | INTERNO | Ignorado | Recusado | Sim |
| Rejeição da mensagem FCM: indisponível | Falha | INDISPONÍVEL | Ignorado | Recusado | Sim |
| Rejeição da mensagem FCM: código de erro inesperado | Falha | código de erro inesperado | Ignorado | Recusado | Não |
| Autenticação: problema de conexão | Falha | Impossível conectar-se ao servidor de autenticação | Ignorado | Recusado | Sim |
| Autenticação: cliente ou escopo não autorizado na solicitação. | Falha | unauthorized_client | Ignorado | Recusado | Não |
| Autenticação: o cliente não está autorizado a recuperar tokens de acesso usando este método ou o cliente não está autorizado para nenhum dos escopos solicitados. | Falha | unauthorized_client | Ignorado | Recusado | Não |
| Autenticação: acesso negado | Falha | access_denied | Ignorado | Recusado | Não |
| Autenticação: email inválido | Falha | invalid_grant | Ignorado | Recusado | Não |
| Autenticação: JWT inválido | Falha | invalid_grant | Ignorado | Recusado | Não |
| Autenticação: assinatura JWT inválida | Falha | invalid_grant | Ignorado | Recusado | Não |
| Autenticação: escopo Oauth inválido ou público-alvo de token de ID fornecido | Falha | unauthorized_client | Ignorado | Recusado | Não |
| Autenticação: cliente OAuth desabilitado | Falha | disabled_client | Ignorado | Recusado | Não |
Quarentenas de SMS sms-quarantines
Para conectores padrão
As especificidades do canal SMS estão listadas abaixo.
| table 0-row-5 1-row-5 2-row-5 3-row-5 4-row-5 5-row-5 html-authored no-header | ||||
|---|---|---|---|---|
| Cenário | Status | Mensagem de erro | Tipo de falha | Motivo da falha |
| Enviado para o provedor | Sent | |||
| Recebido no celular | Recebido | |||
| Erro retornado pelo provedor | Falha | Erro ao receber dados (SR ou MO) | Suave | Inacessível |
| Confirmação MT inválida | Falha | Erro '{1}' ao processar quadro de confirmação para enviar query | Suave | Inacessível |
| Erro ao enviar o MT | Falha | Erro ao enviar mensagens | Suave | Inacessível |
Para o conector SMPP genérico estendido
Ao usar o protocolo SMPP para enviar mensagens SMS, a gestão de erros é tratada de forma diferente.
O conector SMPP recupera dados da mensagem SR (Relatório do Status) que é retornada usando expressões regulares (regexes) para filtrar seu conteúdo. Esses dados são comparados com as informações encontradas na tabela Delivery log qualification (disponível no menu Administration > Campaign Management > Non deliverables Management).
Antes de um novo tipo de erro ser qualificado, o motivo da falha é sempre definido como Refused por padrão.
Exemplo de uma mensagem gerada:
SR Generic DELIVRD 000|#MESSAGE#
-
Todas as mensagens de erro começam com SR para distinguir códigos de erro de SMS de códigos de erro de email.
-
A segunda parte (Generic neste exemplo) da mensagem de erro refere-se ao nome da implementação SMSC, como definido no campo SMSC implementation name da conta externa do SMS.
Como o mesmo código de erro pode ter um significado diferente para cada provedor, esse campo permite que você saiba qual provedor gerou o código de erro. Você pode então encontrar o erro na documentação do provedor relevante.
-
A terceira parte (DELIVRD neste exemplo) da mensagem de erro corresponde ao código de status recuperado do SR usando a extração de status regex definido na conta externa do SMS.
Este regex está especificado na guia SMSC specificities da conta externa.
Por padrão, o regex extrai o campo stat: conforme definido pela seção Apêndice B da especificação 3.4 SMPP. -
A quarta parte (000 neste exemplo) da mensagem de erro corresponde ao código de erro extraído do SR usando a extração de código de erro regex definida na conta externa do SMS.
Este regex está especificado na guia SMSC specificities da conta externa.
Por padrão, o regex extrai o campo err: conforme definido pela seção Apêndice B da especificação 3.4 SMPP.
-
Tudo que vem após o símbolo da barra vertical (|) é exibido somente na coluna First text da tabela Delivery log qualification. Este conteúdo é sempre substituído por #MESSAGE# após a mensagem ser normalizada. Esse processo evita ter várias entradas para erros semelhantes e é igual ao dos emails.
O conector SMPP genérico estendido aplica uma heurística para encontrar valores padrão adequados: se o status começar com DELIV, é considerado um sucesso porque ele corresponde aos status comuns DELIVRD ou DELIVERED usados pela maioria dos provedores. Qualquer outro status gera uma falha grave.
Solução de problemas de falhas de delivery troubleshooting
Esta seção fornece orientação sobre como diagnosticar e resolver problemas comuns de falha do delivery.
Status de falha com erros de personalização personalization-errors
Se o status de uma entrega de email for Failed, ela poderá ser vinculada a um problema com blocos de personalização. Os blocos de personalização em um delivery podem gerar erros quando os schemas não correspondem ao mapeamento do delivery.
Os logs da entrega são fundamentais para saber por que uma entrega falhou. Este é um erro comum que você pode encontrar:
Se as mensagens do destinatário falharem com uma declaração de erro "Inacessível":
Error while compiling script 'content htmlContent' line X: `[table]` is not defined. JavaScript: error while evaluating script 'content htmlContent
Causa: a personalização na HTML está tentando chamar uma tabela ou campo que não foi definido ou mapeado no direcionamento de upstream ou no target mapping da entrega.
Solução: revise o fluxo de trabalho e o conteúdo da entrega para determinar especificamente qual personalização está tentando chamar a tabela em questão. Em seguida, remova a chamada para esta tabela no HTML ou corrija o mapeamento para o delivery.
Saiba mais sobre a personalização em esta seção.
Erro de múltiplos valores de personalização multiple-values-error
Quando uma entrega falha, o seguinte erro pode aparecer nos logs de entrega:
DLV-XXXX The count of message prepared (123) is greater than the number of messages to send (111). Please contact support.
Causa: há um campo ou bloco de personalização no email com mais de um valor para o destinatário. Um bloco de personalização está sendo usado e está buscando mais de um registro para um determinado destinatário.
Solução: verifique os dados de personalização usados e verifique o destino para destinatários que tenham mais de uma entrada para qualquer um desses campos. Você também pode usar uma atividade Deduplication no fluxo de trabalho de direcionamento antes da atividade de entrega para garantir que haja apenas um campo de personalização por vez. Para obter mais informações sobre desduplicação, consulte a documentação sobre fluxo de trabalho.
Manuseio de resposta automática auto-reply-handling
Alguns deliveries podem falhar com um erro "Inacessível" informando:
Inbound email bounce (rule 'Auto_replies' has matched this bounce).
Explicação: significa que a entrega foi bem-sucedida, mas o Adobe Campaign recebeu uma resposta automática do destinatário (por exemplo, uma resposta "Ausente") que correspondia às regras de email de entrada 'Respostas_automáticas'.
O email de resposta automática é ignorado pelo Adobe Campaign e o endereço do recipient não será enviado para a quarentena. Esse é um comportamento esperado e não indica uma falha de delivery.
Tópicos relacionados
Status de entrega explica os diferentes status que uma entrega pode ter durante seu ciclo de vida.
Monitorar entregas na interface do Campaign fornece orientação sobre como usar o painel de entrega para rastrear o desempenho da entrega e diagnosticar problemas.
Gerenciamento de quarentena explica como o Campaign gerencia endereços em quarentena para proteger sua reputação de envio.
Monitorar sua capacidade de entrega fornece orientação sobre como manter uma boa capacidade de entrega e a reputação do remetente.
Práticas recomendadas de entrega aborda as práticas recomendadas para criar e enviar entregas no Campaign.