Show Menu
TÓPICOS×

Noções básicas sobre gestão de quarentena

Sobre a quarentena

O Adobe Campaign gerencia uma lista de endereços em quarentena. Os recipients cujo endereço está em quarentena são excluídos por padrão durante a análise de delivery 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.
Esta seção se aplica aos canais online: email, SMS, notificação por push.

Otimização do seu delivery por meio da quarentena

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 Identificação de endereços em quarentena para um delivery ). Isso irá acelerar os deliveries, pois a taxa de erro tem um efeito significativo na velocidade do delivery.
Alguns provedores de acesso à Internet consideram automaticamente emails como spam se a taxa de endereços inválidos for muito alta. A quarentena, portanto, permite que você evite ser adicionada à lista de bloqueios por esses provedores.
Além disso, a quarentena ajuda a reduzir os custos de envio do SMS, excluindo números de telefone incorretos dos deliveries. Para obter mais informações sobre as práticas recomendadas para proteger e otimizar seus deliveries, consulte esta página .

Quarentena vs lista de bloqueios

A quarentena se aplica somente a um endereço, não ao próprio perfil. Isso significa que, se dois perfis tiverem o mesmo endereço de email, eles serão afetados se o endereço estiver em quarentena.
Da mesma forma, um perfil cujo endereço de email está em quarentena poderia atualizar seu perfil e inserir um novo endereço e pode ser alvo de ações de delivery novamente.
Being on the denylist , on the other hand, will result in the profile no longer being targeted by any delivery, for example after an unsubscription (opt-out).
Quando um usuário responde a uma mensagem SMS com uma palavra-chave como "PARAR" para recusar delivery SMS, seu perfil não é adicionado à lista de bloqueios como no processo de recusa por email. O número de telefone do perfil é enviado para quarentena, para que o usuário continue recebendo mensagens de email.

Identificação de endereços em quarentena

Os endereços em quarentena podem ser listados para um delivery específico ou para a plataforma inteira.

Identificação de endereços em quarentena para um delivery

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

Identificação de endereços em quarentena para toda a plataforma

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 .
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:
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 recipients 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%.

Identificação de endereços em quarentena nos relatórios de delivery

Os seguintes relatórios fornecem informações sobre os endereços em quarentena:
  • Para cada delivery, o relatório Delivery summary mostra o número de endereços em quarentena no target do delivery. Ele exibe:
    • O número de endereços colocados em quarentena durante a análise de delivery,
    • O número de endereços colocados em quarentena após a ação de delivery.
  • 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 todos os deliveries da plataforma ( Home page > Reports ) ou para um delivery específico. Você também pode criar relatórios personalizados e selecionar as informações a serem exibidas.

Identificação de endereços em quarentena para um recipient

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

Remoção de um endereço em quarentena

Caso necessário, você pode remover manualmente um endereço da lista da quarentena. Além disso, os endereços que correspondem a condições específicas são automaticamente excluídos da lista de quarentena pelo workflow Database cleanup .
Para remover manualmente um endereço da lista da quarentena:
  • É possível alterar seu status para Valid a partir do nó Administration > Campaign Management > Non deliverables Management > Non deliverables and addresses .
  • Você também pode alterar o status para Allowlisted . Nesse caso, o endereço permanece na lista da quarentena, mas será direcionado sistematicamente, mesmo que um erro seja encontrado.
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 um delivery bem-sucedido.
  • 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 .
Os recipients com um endereço em um status Quarantine ou On denylist nunca serão removidos, mesmo se receberem um email.
Você pode alterar 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 ). Para obter mais informações sobre o assistente de implantação, consulte esta seção .

Condições para colocar um endereço na quarentena

O Adobe Campaign gerencia a quarentena de acordo com o tipo de falha do delivery e o motivo atribuído durante a qualificação de mensagens de erro (consulte Qualificação de email de devolução ) e os tipos e motivos de falha de delivery .
  • 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 um spam ( Loop de feedback ), a mensagem será automaticamente redirecionada para uma caixa de entrada técnica gerenciada pela Adobe. O endereço de email do usuário é enviado automaticamente para quarentena.
Na lista de endereços em quarentena, o campo Error reason indica por que o endereço selecionado foi colocado em quarentena. 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.

Gerenciamento de erros leves

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.
  • Quando o contador de erros atinge o limite, o endereço vai para a quarentena.
  • Na configuração padrão, o limite é definido em cinco erros, onde dois erros são significativos se ocorrerem pelo menos em 24 horas de intervalo. O endereço é colocado em quarentena no quinto erro.
  • O limite do contador de erros pode ser modificado. Para obter mais informações, consulte Tentativas após uma falha temporária de delivery .
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 .

Notificação por push em quarentena

O mecanismo de quarentena para notificações por push é globalmente igual ao processo geral. Consulte Sobre quarentenas . No entanto, certos erros são gerenciados de forma diferente para notificações por push. Por exemplo, para determinados erros suaves, nenhuma tentativa é executada no mesmo delivery. 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

Para iOS - conector binário
Para cada notificação, o Adobe Campaign recebe os erros síncronos e assíncronos do servidor APNS. Para os seguintes erros síncronos, o Adobe Campaign gera erros suaves:
  • Problemas de comprimento da carga: sem tentativa, o motivo da falha é Unreachable .
  • Problemas de expiração de certificado: sem tentativa, o motivo da falha é Unreachable .
  • A conexão perdida durante o delivery: tentativa executada, o motivo da falha é Unreachable .
  • Problema de configuração de serviço (certificado inválido, senha de certificado inválida, sem certificado): sem tentativa, o motivo da falha é Unreachable .
O servidor APNS notifica de forma assíncrona o Adobe Campaign que um token de dispositivo teve o registrado cancelado (quando o aplicativo móvel foi desinstalado pelo usuário). O workflow mobileAppOptOutMgt é executado a cada 6 horas para contatar os serviços de feedback APNS e atualizar a tabela AppSubscriptionRcp . Para todos os tokens desativados, o campo Desativado é definido como Verdadeiro e a subscrição vinculada a esse token de dispositivo será excluída automaticamente de deliveries futuros.
Para iOS - conector HTTP/2
O protocolo http/2 permite um feedback direto e status para cada delivery push. Se o conector do protocolo http/2 for usado, o serviço de feedback não será mais chamado pelo workflow mobileAppOptOutMgt . Os tokens não registrados são tratados de forma diferente entre o conector binário do iOS e o conector http/2 do iOS. 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 target 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 com o 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: Unregistration the user has removed the application or the token has expired 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 .
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

SMS em quarentena

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