Entender as falhas de delivery

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 tiver retornado 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 manter um olho nessa métrica. "Entregue" versus "devolvido" é 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 para a Adobe Campaign. Esse erro está qualificado para determinar se o endereço de email, o número de telefone ou o dispositivo devem ser colocados em quarentena. Consulte Gerenciamento de emails de devolução.

Depois que uma mensagem é enviada, você pode visualizar o status do delivery para cada perfil e o tipo e motivo da falha associados nos logs do delivery.

Quando um endereço de email é colocado em quarentena, ou se um perfil está em lista de bloqueios, o recipient é excluído na etapa de preparação do delivery. As mensagens excluídas são listadas no painel de delivery.

Por que o delivery de mensagem falhou

Há dois tipos de erros quando uma mensagem falha. Cada tipo de falha de delivery determina se um endereço é enviado para 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 e-mail para um endereço de assinante como não entregável. No Adobe Campaign, as devoluções permanentes categorizadas como não entregues são adicionadas à lista de quarentena, o que significa que elas não seriam tentadas novamente. Há alguns casos em que uma devolução permanente seria ignorada se a causa da falha fosse desconhecida.

    Estes são alguns exemplos comuns de devoluções permanentes: Endereço não existe, Conta desabilitada, Sintaxe incorreta, Domínio incorreto

  • Rejeições suaves
    As devoluções temporárias são falhas temporárias que os ISPs geram quando têm dificuldade em entregar emails. Falhas leves resultarão tentar novamente várias vezes (com variação dependendo do uso de configurações de delivery personalizadas ou predefinidas) para tentar um delivery bem-sucedido. Os endereços que repetidamente 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 dependendo das configurações).

    Algumas causas comuns de devoluções temporárias incluem o seguinte: Caixa de entrada cheia, servidor de email de recebimento desativado, problemas de reputação do remetente

O Ignorado o tipo de erro é conhecido como temporário, como "Ausência temporária", ou um erro técnico, por exemplo, se o tipo de remetente for "postmaster".

O loop de comentários 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. Os endereços desses usuários são incluir na lista de bloqueios mesmo que não cliquem no link de cancelamento de subscrição. Os endereços são adicionados ao (NmsAddress) e não para a (NmsRecipient) tabela de recipients com o Denylisted status. Saiba mais sobre o mecanismo de loop de comentários na Guia de práticas recomendadas de capacidade de entrega do Adobe.

Erros síncronos e assíncronos

Um delivery de mensagem pode falhar imediatamente, nesse caso, qualificamos isso como um erro síncrono. Se o envio da mensagem falhar ou for posterior, após o envio, 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 da 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 em questão 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 é reenviado posteriormente pelo servidor receptor. Esse erro é qualificado com um rótulo relacionado ao erro. Podem ocorrer erros assíncronos até uma semana depois do envio.

OBSERVAÇÃO

Como usuário do Managed Services, a configuração da caixa de entrada de devolução é executada pelo Adobe.

Qualificação de email de rejeição

A maneira como a qualificação de email de devolução é tratada no Adobe Campaign depende do tipo de erro:

  • Erros síncronos: O MTA determina o tipo de devolução e a qualificação e envia essas informações para o Campaign. As qualificações de rejeição na variável Delivery log qualification tabela não é usada para síncrono mensagens de erro de falha de delivery.

  • Erros assíncronos: As regras usadas pelo Campaign para qualificar falhas de delivery assíncronas são listadas na variável Administration > Campaign Management > Non deliverables Management > Delivery log qualification nó . As rejeições assíncronas são qualificadas pelo processo do InMail por meio do Inbound email regras. Para obter mais informações, consulte Documentação do Adobe Campaign Classic v7.

Gerenciamento de tentativas

Se o delivery de mensagem falhar após um erro temporário (Suave ou Ignorado), o Campaign tenta enviar novamente. Essas tentativas podem ser executadas até o fim da duração do delivery.

As tentativas de rejeição em modo suave e o tempo entre elas são determinados pelo MTA com base no tipo e na gravidade das respostas de rejeição provenientes do domínio de email da mensagem.

OBSERVAÇÃO

As configurações de nova tentativa nas propriedades de delivery não são usadas pelo Campaign.

Período de validade

A configuração do período de validade nos deliveries do Campaign está 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 estiver definido com o valor padrão de 5 dias no Campaign, as mensagens de rejeição temporária entrarão na fila de tentativas do MTA e serão repetidas por até 3,5 dias a partir do momento em que a mensagem chegou 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 do delivery.

Para obter mais informações sobre o período de validade, consulte Documentação do Adobe Campaign Classic v7.

Tipos de erro de email

Para o canal de email, os possíveis motivos para uma falha de delivery são listados abaixo.

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. Os deliveries 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 recipient.
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 Ignorado 127 O endereço do recipient faz parte do grupo de controle.
Duplo Ignorado 10 O endereço do recipient já estava nesse delivery.
Erro ignorado Ignorado 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 Ignorado 12 O recipient foi excluído por uma regra de tipologia de 'arbitragem' de campanha.
Excluído por uma regra SQL Ignorado 11 O recipient 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 workflow técnico de limpeza do banco de dados deve ser iniciado.
Não conectado Ignorado 6 O telefone celular do recipient 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 Ignorado 16 O recipient não foi qualificado para as ofertas no delivery.
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 Ignorado 17 O tamanho máximo de delivery foi atingido para o recipient.
Endereço não qualificado Ignorado 15 O endereço postal não foi qualificado.
Inacessível Suave/Grave 3 Ocorreu um erro na cadeia de delivery 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 delivery para este perfil.

Tipos de erro de notificações por push

Para o canal de aplicativo móvel, os possíveis motivos para uma falha de delivery são listados abaixo.

Quarentena do iOS

O protocolo HTTP/V2 permite um feedback e status direto para cada delivery por push. Se o conector do protocolo HTTP/V2 for usado, o serviço de feedback não será mais chamado pelo workflow 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.

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

Para Android V1

A cada notificação, o Adobe Campaign recebe os erros síncronos diretamente do servidor FCM. O Adobe Campaign os trata instantaneamente 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 workflow mobileAppOptOutMgt é executado a cada 6 horas para atualizar a tabela AppSubscriptionRcp. Para os tokens declarados não registrados ou não mais válidos, o campo Desativado é definido como Verdadeiro e a subscrição vinculada a esse token de dispositivo será excluída automaticamente dos deliveries futuros.

Durante a análise de delivery, todos os dispositivos excluídos do target são automaticamente adicionados à tabela excludeLogAppSubRcp .

OBSERVAÇÃO

Para clientes que usam o conector Baidu, aqui estão os diferentes tipos de erros:

  • Problema de conexão no início do delivery: falha do tipo Undefined, razão da falha Unreachable, a tentativa é executada.
  • Perda de conexão durante um delivery: 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.

O Adobe Campaign contata o servidor Baidu a cada 10 minutos para recuperar o status da mensagem enviada e atualiza os broadlogs. Se uma mensagem for declarada como enviada, o status da mensagem nos broadlogs será definido como Received. Se o Baidu declarar um erro, o status será definido como Failed.

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

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 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

Para conectores padrão

As especificidades para o canal SMS estão listadas abaixo.

OBSERVAÇÃO

A tabela Delivery log qualification não se aplica ao conector SMPP genérico estendido.

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.

OBSERVAÇÃO

Os tipos de falha e os motivos para falha são os mesmos dos emails.

Peça ao seu provedor uma lista de códigos e status de erros para definir os tipos apropriados de falhas e os motivos para falha na tabela de qualificação de log de delivery.

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.

    Esse regex é 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.

    Esse regex é 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.

Nesta página