[Também se aplica ao v8]{class="badge positive" title="Também se aplica ao Campaign v8"}

Entender o gerenciamento de quarentena understanding-quarantine-management

O Adobe Campaign gerencia uma lista de endereços em quarentena. Os destinatários cujo endereço está em quarentena são excluídos por padrão durante a análise de entrega e não serão direcionados. Um endereço de e-mail pode ser colocado em quarentena, por exemplo, quando a caixa de correio está cheia ou se o endereço não existe. Em qualquer caso, o procedimento de quarentena está em conformidade com as regras específicas descritas abaixo.

NOTE
Esta seção se aplica aos canais online: email, SMS, notificação por push.

Otimizar sua entrega por meio do gerenciamento de quarentena optimizing-your-delivery-through-quarantines

Os perfis cujos endereços de email ou número de telefone estão em quarentena são excluídos automaticamente durante a preparação da mensagem (consulte Identificar endereços em quarentena para uma entrega). Isso irá acelerar as entregas, pois a taxa de erro tem um efeito significativo na velocidade da entrega.

Alguns provedores de acesso à Internet consideram automaticamente emails como spam se a taxa de endereços inválidos é muito alta. A quarentena, portanto, evita que você seja adicionado à lista de bloqueios por esses provedores.

Além disso, a quarentena ajuda a reduzir os custos de envio de SMS, excluindo números de telefone incorretos das entregas.

Para obter mais informações sobre as práticas recomendadas para proteger e otimizar suas entregas, consulte esta página.

Quarentena versus Lista de bloqueios quarantine-vs-denylist

A quarentena e a lista de bloqueios não se aplicam ao mesmo objeto:

  • A quarentena se aplica somente a um endereço (ou número de telefone etc.), não ao próprio perfil. Por exemplo, um perfil cujo endereço de email esteja em quarentena pode atualizar seu perfil e inserir um novo endereço, podendo então ser direcionado em ações de entrega novamente. Da mesma forma, se dois perfis tiverem o mesmo número de telefone, ambos serão afetados se o número estiver em quarentena.

    Os endereços em quarentena ou os números de telefone são exibidos nos logs de exclusão (para uma entrega) ou na lista de quarentena (para toda a plataforma).

  • Por outro lado, com a inclusão na lista de bloqueios, o perfil não será mais direcionado pela entrega, por exemplo, depois de um cancelamento de inscrição (recusa de participação) de um determinado canal. Por exemplo, se um perfil na lista de bloqueios para o canal de email tiver dois endereços de email, ambos os endereços serão excluídos da entrega.

    Você pode verificar se um perfil está na lista de bloqueios de um ou mais canais na seção No longer contact da guia General do perfil. Consulte esta seção.

NOTE
A quarentena inclui um status Denylisted, que se aplica quando os destinatários marcam sua mensagem como spam ou respondem a uma mensagem SMS com uma palavra-chave, como “PARAR”. Nesse caso, o endereço do perfil envolvido ou o número de telefone é enviado para quarentena com o status Denylisted. Para obter mais informações sobre como gerenciar mensagens SMS PARAR, consulte esta seção.

Identificar endereços em quarentena identifying-quarantined-addresses

Os endereços em quarentena podem ser listados para uma entrega específica ou para toda a plataforma.

Identificar endereços em quarentena para uma entrega identifying-quarantined-addresses-for-a-delivery

Os endereços em quarentena para uma entrega específica são listados durante a fase de preparação da entrega, nos logs da entrega do painel de entrega (consulte Histórico e logs da entrega).

Identificar endereços em quarentena para toda a plataforma identifying-quarantined-addresses-for-the-entire-platform

Os administradores podem listar os endereços em quarentena para toda a plataforma do nó Administration > Campaign Management > Non deliverables Management > Non deliverables and addresses.

NOTE
Este menu lista os elementos colocados em quarentena para os canais de email, SMS e notificação por push .

As seguintes informações estão disponíveis para cada endereço:

NOTE
O aumento no número em quarentena é um efeito normal, relacionado ao "desgaste" do banco de dados. Por exemplo, se o tempo de vida de um endereço de email for considerado três anos e a tabela de destinatários aumentar em 50% todo ano, o aumento da quarentena poderá ser calculado da seguinte maneira:
Fim do Ano 1: (1*0,33)/(1+0,5)=22%.
Fim do ano 2: ((1,22*0,33)+0,33)/(1,5+0,75)=32,5%.

Identificar endereços em quarentena nos relatórios da entrega identifying-quarantined-addresses-in-delivery-reports

Os seguintes relatórios fornecem informações sobre os endereços em quarentena:

  • Para cada entrega, o relatório Delivery summary mostra o número de endereços em quarentena no target da entrega. Ele exibe:

    • O número de endereços colocados em quarentena durante a análise de entrega,

    • O número de endereços colocados em quarentena após a ação de entrega.

  • O relatório Non-deliverables and bounces exibe informações sobre os endereços em quarentena, os tipos de erro encontrados e etc., além de um detalhamento de falha por domínio.

Você pode visualizar essas informações para todas as entregas da plataforma (Home page > Reports) ou para uma entrega específica. Você também pode criar relatórios personalizados e selecionar as informações a serem exibidas.

Identificar endereços em quarentena para um destinatário identifying-quarantined-addresses-for-a-recipient

Você pode consultar o status do endereço de email de qualquer destinatário. Para fazer isso, selecione o perfil do destinatário e clique na guia Deliveries. Para todas as entregas para esse destinatário, você pode descobrir se o endereço falhou, estava em quarentena durante a análise, etc. Para cada pasta, é possível exibir apenas os destinatários cujo endereço de email está em quarentena. Para fazer isso, use o filtro de aplicação Quarantined email address.

Condições para enviar um endereço para quarentena conditions-for-sending-an-address-to-quarantine

O Adobe Campaign gerencia a quarentena de acordo com o tipo de falha da entrega e o motivo atribuído durante a qualificação de mensagens de erro (consulte Qualificação de emails de devolução e os tipos e motivos de falha de entrega).

  • Erro ignorado: os erros ignorados não enviam um endereço para quarentena.
  • Erro grave: o endereço de email correspondente é enviado imediatamente para quarentena.
  • Erro suave: erros suaves não enviam um endereço imediatamente para quarentena, mas incrementam um contador de erros. Para obter mais informações, consulte Gerenciamento de erros leves.

Se um usuário qualificar um email como spam (loop de feedback), a mensagem será automaticamente redirecionada para uma caixa de entrada técnica gerenciada pela Adobe. Em seguida, o endereço de email do usuário será enviado automaticamente para quarentena com o status Denylisted. Esse status se refere apenas ao endereço. O perfil não é incluído na lista de bloqueio para que o usuário continue recebendo mensagens SMS e notificações por push.

NOTE
A quarentena no Adobe Campaign diferencia maiúsculas de minúsculas. Certifique-se de importar endereços de email em letras minúsculas, para que não sejam redirecionados posteriormente.

Na lista de endereços em quarentena (consulte Identificação de endereços em quarentena para toda a plataforma), o campo Error reason indica por que o endereço selecionado foi colocado em quarentena.

Gerenciamento de erros leves soft-error-management

Ao contrário de erros graves, os erros recuperáveis não enviam um endereço imediatamente para quarentena, mas incrementam um contador de erros.

As tentativas serão executadas no decorrer da duração da entrega. Quando o contador de erros atinge o limite da cota, o endereço vai para a quarentena. Para obter mais informações, consulte Tentativas após uma falha temporária de entrega.

O contador de erros será reinicializado se o último erro significativo ocorrer há mais de 10 dias. O status do endereço é alterado para Válido e excluído da lista de quarentenas pelo workflow de limpeza do banco de dados.

Para instalações hospedadas ou híbridas, se você tiver atualizado para o MTA aprimorado, o número máximo de tentativas a efetuar em caso de status Erroneous, e o atraso mínimo entre tentativas agora se baseiam no desempenho histórico e atual de um IP em um determinado domínio.

Para instalações no local e instalações hospedadas/híbridas usando o MTA herdado do Campaign, você pode modificar o número de erros e o período entre dois erros. Para fazer isso, altere as configurações correspondentes no assistente de implantação (Email channel > Advanced parameters) ou no nível da entrega.

Remover um endereço da quarentena removing-a-quarantined-address

Atualizações automáticas unquarantine-auto

Os endereços que correspondem a condições específicas são automaticamente excluídos da lista de quarentena pelo fluxo de trabalho de Limpeza do banco de dados.

Os endereços são removidos automaticamente da lista de quarentena nos seguintes casos:

  • Os endereços em um status With errors serão removidos da lista de quarentena após uma entrega bem-sucedida.
  • Os endereços em um status With errors serão removidos da lista de quarentena se o último retorno de erro tiver ocorrido há mais de 10 dias. Para obter mais informações sobre o gerenciamento de erros de software, consulte esta seção.
  • Os endereços em um status With errors que tiverem retornado com o erro Mailbox full serão removidos da lista de quarentena após 30 dias.

O status muda então para Valid.

IMPORTANT
Os destinatários com um endereço em um status Quarantine ou Denylisted nunca serão removidos, mesmo se receberem um email.

Atualizações manuais unquarantine-manual

Também é possível cancelar a quarentena de um endereço manualmente. Para remover manualmente um endereço da lista da quarentena, altere seu status para Valid do nó Administration > Campaign Management > Non deliverables Management > Non deliverables and addresses.

Atualizações em massa unquarantine-bulk

Talvez seja necessário executar atualizações em massa na lista de quarentena. Por exemplo, no caso de uma interrupção de ISP. Nesse caso, os emails são marcados incorretamente como rejeições porque não podem ser entregues com êxito ao destinatário. Esses endereços devem ser removidos da lista de quarentena.

Para fazer isso, crie um fluxo de trabalho e adicione uma atividade Query na tabela de quarentena para filtrar todos os destinatários afetados. Uma vez identificados, eles podem ser removidos da lista de quarentena e incluídos em entregas de email futuros do Campaign.

Abaixo estão as diretrizes recomendadas para esta consulta:

  • Para ambientes do Campaign Classic v7 com informações de regra de email de entrada no campo Error text da lista de quarentena:

    • O texto de erro (texto de quarentena) contém “Momen_Code10_InvalidRecipient”
    • Domínio de email (@domain) igual a domain1.com OU Domínio de email (@domain) igual a domain2.com OU Domínio de email (@domain) igual a domain3.com
    • Atualizar status (@lastModified)  em ou depois de MM/DD/YYYY HH:MM:SS AM
    • Atualizar status (@lastModified)  em ou antes de MM/DD/YYYY HH:MM:SS PM
  • Para instâncias do Campaign Classic v7 com informações de resposta de rejeição SMTP no campo Error text da lista de quarentena:

    • O texto de erro (texto de quarentena) contém “550-5.1.1” E o texto de erro (texto de quarentena) contém “support.ISP.com”,

    onde “support.ISP.com” pode ser “support.apple.com” ou “support.google.com”, por exemplo

    • Atualizar status (@lastModified)  em ou depois de MM/DD/YYYY HH:MM:SS AM
    • Atualizar status (@lastModified)  em ou antes de MM/DD/YYYY HH:MM:SS PM

Depois de ter a lista de destinatários afetados, adicione uma atividade Update data para definir seu status de endereço de email como Valid para que eles sejam removidos da lista de quarentena pelo fluxo de trabalho Database cleanup. Também é possível excluí-los da tabela de quarentena.

Quarentenas de notificação por push push-notification-quarantines

O mecanismo de quarentena para notificações por push é globalmente igual ao processo geral. No entanto, certos erros são gerenciados de forma diferente para notificações por push. Por exemplo, para determinados erros suaves, nenhuma tentativa é executada na mesma entrega. As especificidades para notificação por push estão listadas abaixo. O mecanismo de tentativa (número de tentativas, frequência) é igual ao dos emails.

Os itens colocados em quarentena são tokens de dispositivo.

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 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 conexão de teste com problema de 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 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 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 .

NOTE
Para clientes que usam o conector Baidu, aqui estão os diferentes tipos de erros:
  • 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.
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 sms-quarantines

Para conectores padrão

O mecanismo de quarentena para mensagens SMS é globalmente igual ao processo geral. Consulte Sobre quarentenas. As especificidades para SMS estão listadas abaixo.

NOTE
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. Para obter mais informações sobre o conector SMPP genérico estendido, consulte esta página.

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.

NOTE
Os tipos de falha e os motivos para falha são os mesmos dos emails. Consulte Tipos e motivos de falha de entrega.
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 entrega.

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. Consulte esta página.

    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. Consulte esta página.

    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. Consulte esta página.

    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. Para obter mais informações, consulte Qualificação de email de devolução.

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.

recommendation-more-help
601d79c3-e613-4db3-889a-ae959cd9e3e1