Comprender los errores de envío
- Se aplica a:
- Campaign v8 Client Console
Creado para:
- Principiante
- Intermedio
- Usuario
Las devoluciones son el resultado de un intento de entrega y un error en el que el ISP proporciona avisos de error de devolución. El procesamiento de la manipulación de devoluciones es una parte esencial del estado de la lista. Una vez que un correo electrónico determinado ha rebotado varias veces, este proceso indica su supresión.
Este proceso evita que los sistemas continúen enviando direcciones de correo electrónico no válidas. Las devoluciones son uno de los datos clave que los ISP utilizan para determinar la reputación de la IP. Es importante estar atento a esta métrica. "Entregado" frente a "devuelto" es probablemente la forma más común de medir el envío de mensajes de marketing: cuanto mayor sea el porcentaje de entrega, mejor.
Si no es posible enviar un mensaje a un perfil, el servidor remoto envía automáticamente un mensaje de error a Adobe Campaign. Este error sirve para determinar si la dirección de correo electrónico, el número de teléfono o el dispositivo deben ponerse en cuarentena. Consulte Administración de correos rechazados.
Una vez enviado un mensaje, puede ver el estado de envío de cada perfil y el tipo y el motivo de error asociado en los registros de envío.
Cuando una dirección de correo electrónico está en cuarentena, o si un perfil está a la lista de bloqueados, el destinatario se excluye en el paso de preparación de la entrega. Los mensajes excluidos se muestran en el panel de entrega.
¿Por qué ha fallado la entrega del mensaje?
Existen dos tipos de error cuando falla un mensaje. Cada tipo de error de entrega determina si una dirección se envía a cuarentena o no.
-
Devoluciones graves
Las devoluciones duras son errores permanentes generados después de que un ISP determine que un intento de envío a una dirección de suscriptor no se puede entregar. En Adobe Campaign, las devoluciones graves de mensajes clasificados como no aptos para entrega se añaden a la lista de cuarentena, lo que significa que no se volverán a enviar. Hay algunos casos en los que se ignoran los mensajes devueltos no válidos si se desconoce la causa del error.Estos son algunos ejemplos comunes de devoluciones graves: La dirección no existe, Cuenta deshabilitada, Sintaxis incorrecta, Dominio incorrecto
-
devoluciones leves
Las devoluciones leves de mensajes son errores temporales que los ISP generan cuando tienen dificultades para enviar correos. Los errores leves se volverán a intentar varias veces (con variación según el uso de la configuración de envío personalizada o predeterminada) para intentar una entrega correcta. Las direcciones de mensajes devueltos no entregados que reboten de forma continua no se añadirán a la cuarentena hasta que se haya intentado el número máximo de reintentos (que varía en función de la configuración).Algunas causas comunes de las devoluciones leves son las siguientes: Buzón lleno, Recepción del servidor de correo electrónico caído, Problemas de reputación del remitente
Se sabe que el tipo de error Ignorado es temporal, como "Fuera de la oficina", o un error técnico, por ejemplo, si el tipo de remitente es "Administrador de correo".
El bucle de comentarios funciona como los correos electrónicos rechazados: cuando un usuario clasifica un correo electrónico como correo no deseado, puede configurar las reglas de correo electrónico en Adobe Campaign para bloquear todas las entregas a este usuario. Incluir en la lista de bloqueados Las direcciones de estos usuarios se aunque no hayan hecho clic en el vínculo de baja. Las direcciones se agregan a la tabla de cuarentena (NmsAddress) y no a la tabla de destinatarios (NmsRecipient) con el estado Denylisted. Obtenga más información acerca del mecanismo de bucle de comentarios en la Guía de prácticas recomendadas de entrega de Adobes.
Errores sincrónicos y asíncronos
Una entrega de mensajes puede fallar inmediatamente, en ese caso se clasifica como un error sincrónico. Si el envío de mensajes falla o más tarde, después de enviarlos, el error es asincrónico.
Estos tipos de errores se administran de la siguiente manera:
-
Error sincrónico: el servidor remoto contactado mediante el servidor de entrega de Adobe Campaign devuelve inmediatamente un mensaje de error. No se permite realizar la entrega al servidor del perfil. El Agente de transferencia de correo (MTA) determina el tipo de rechazo y clasifica el error, y envía esa información a Campaign para determinar si las direcciones de correo electrónico correspondientes deben ponerse en cuarentena. Consulte Cualificación de correo rechazado.
-
Error asíncrono: el servidor receptor reenvía más tarde un correo electrónico de rechazo o una SR. Este error se califica con una etiqueta relacionada con el error. Pueden producirse errores asíncronos hasta una semana después de mandar la entrega.
NOTEClasificación del correo rechazado
La forma en que se gestiona la calificación de correo rechazado en Adobe Campaign depende del tipo de error:
-
Errores sincrónicos: El MTA determina el tipo de devolución y calificación, y envía esa información a Campaign. Las cualificaciones de rechazo de la tabla Delivery log qualification no se utilizan para los mensajes de error de envío sincrónico.
-
Errores asincrónicos: Las reglas utilizadas por Campaign para calificar los errores de entrega asincrónicos se enumeran en el nodo Administration > Campaign Management > Non deliverables Management > Delivery log qualification. Las devoluciones asincrónicas son calificadas por el proceso inMail a través de las reglas Inbound email. Para obtener más información, consulte Documentación de Adobe Campaign Classic v7.
Administración de reintentos
Si la entrega de mensajes falla tras un error temporal (Soft o Ignored), Campaign reintenta la entrega. Estos reintentos se pueden realizar hasta el final de la duración de la entrega.
Los reintentos de rebote suave y el periodo entre ellos están determinados por el MTA en función del tipo y la gravedad de las respuestas de devoluciones procedentes del dominio de correo electrónico del mensaje.
NOTEPeríodo de validez
La configuración del período de validez de los envíos de Campaign está limitada a 3,5 días o menos. Para una entrega, si define un valor superior a 3,5 días en Campaign, no se tendrá en cuenta.
Por ejemplo, si el periodo de validez se establece en el valor predeterminado de 5 días en Campaign, los mensajes de rebote suave se incluirán en la cola de reintentos de MTA y se volverán a intentar durante un máximo de 3,5 días a partir de la fecha en que el mensaje llegue al MTA. En ese caso, no se utilizará el valor establecido en Campaign.
Una vez que un mensaje ha estado en la cola de MTA durante 3,5 días y no se ha podido entregar, se agotará el tiempo de espera y se actualizará su estado de Sent a Failed en los registros de envío.
Para obtener más información sobre el período de validez, consulte la documentación de Adobe Campaign Classic v7.
Tipos de error de correo electrónico
Para el canal de correo electrónico, a continuación se enumeran los posibles motivos de un error de entrega.
Este tipo de error se administra mediante un proceso de limpieza; la dirección se establece en un estado válido después de 30 días.
Advertencia: para que la dirección se elimine automáticamente de la lista de direcciones en cuarentena, debe iniciarse el flujo de trabajo técnico para limpieza de bases de datos.
Tipos de error de notificaciones push
Para el canal de aplicaciones móviles, los posibles motivos de un error de entrega se enumeran a continuación.
Cuarentena de iOS
El protocolo HTTP/V2 permite los comentarios y el estado directo para cada notificación remota. Si se utiliza el conector de protocolo HTTP/V2, el flujo de trabajo mobileAppOptOutMgt ya no se comunica con el servicio de comentarios. Un token de dispositivo se considera no registrado cuando se desinstala o se vuelve a instalar una aplicación móvil.
Sincrónicamente, si APNS devuelve el estado “no registrado” para un mensaje, el token de destino se pone inmediatamente en cuarentena.
el usuario ha eliminado la aplicación o el token ha caducado
.
Cuarentena de Android
Para Android V1
Para cada notificación, Adobe Campaign recibe los errores sincrónicos directamente desde el servidor FCM. Adobe Campaign los gestiona sobre la marcha y genera errores graves o leves según la gravedad de los errores y los reintentos que se puedan realizar:
- Longitud de la carga útil excedida, problema de conexión, problema de disponibilidad del servicio: con reintento, error leve, el motivo del error es Refused.
- Se ha superado la cuota de dispositivo: sin reintento, error leve, el motivo del error es Refused.
- Token inválido o no registrado, error inesperado, problema con la cuenta del remitente: sin reintento, error grave, el motivo del error es Refused.
El flujo de trabajo mobileAppOptOutMgt se ejecuta cada 6 horas para actualizar la tabla de AppSubscriptionRcp. En el caso de los tokens declarados no registrados o ya no válidos, el campo Deshabilitado se establece en Verdadero y la suscripción vinculada a ese token de dispositivo se excluye automáticamente de futuros entregas.
Durante el análisis de la entrega, todos los dispositivos excluidos del destino se añaden automáticamente a la tabla excludeLogAppSubRcp.
NOTE- Problema de conexión al principio del envío: tipo de error Undefined, motivo del error Unreachable, con reintento.
- Se ha perdido la conexión durante un envío: error de software, motivo del error Refused, con reintento.
- Error sincrónico devuelto por Baidu durante el envío: error de hardware, motivo del error Refused, sin reintento.
Para Android V2
El mecanismo de cuarentena de Android V2 utiliza el mismo proceso que Android V1; lo mismo se aplica a las suscripciones y a la actualización de las exclusiones. Para obtener más información, consulte la sección de Android V1.
.
.
.
Cuarentenas de SMS
Para conectores estándar
Las particularidades del canal SMS se enumeran a continuación.
NOTEPara el conector SMPP genérico extendido
Al utilizar el protocolo SMPP para enviar mensajes SMS, la administración de errores se gestiona de forma distinta.
El conector SMPP recupera los datos del mensaje de SR (informe de estado) que se devuelve utilizando expresiones regulares (regex) para filtrar su contenido. Estos datos se corresponden con la información que se encuentra en la tabla Delivery log qualification (disponible a través del menú Administration > Campaign Management > Non deliverables Management).
Antes de que se clasifique un nuevo tipo de error, el motivo del error se establece siempre como Rechazado de forma predeterminada.
NOTEEjemplo de mensaje generado:
SR Generic DELIVRD 000|#MESSAGE#
-
Todos los mensajes de error empiezan por SR para distinguir entre los códigos de error de los SMS y códigos de error de los correos electrónicos.
-
La segunda parte (Generic en este ejemplo) del mensaje de error hace referencia al nombre de la implementación de SMSC, como se define en el campo SMSC implementation name de la cuenta externa de SMS.
Dado que el mismo código de error puede tener un significado diferente para cada proveedor, este campo permite saber qué proveedor genera el código de error. Después se puede buscar el error en la documentación del proveedor correspondiente.
-
La tercera parte (DELIVRD en este ejemplo) del mensaje de error corresponde al código de estado recuperado del SR mediante las regex de extracción de estado definidas en la cuenta externa de SMS.
Esta regex se especifica en la pestaña SMSC specificities de la cuenta externa.
De manera predeterminada, la regex extrae el campo stat: como se define en la sección Apéndice B de la especificación de SMPP 3.4. -
La cuarta parte (000 en este ejemplo) del mensaje de error corresponde al código de error extraído del SR mediante la regex de extracción de código de error definida en la cuenta externa de SMS.
Esta regex se especifica en la pestaña SMSC specificities de la cuenta externa.
De manera predeterminada, la regex extrae el campo err: tal y como se define en la sección Apéndice B de la especificación de SMPP 3.4.
-
Todo lo que aparece después del símbolo de barra vertical (|) se muestra solo en la columna First text de la tabla Delivery log qualification. Este contenido siempre se sustituye por #MESSAGE# después de normalizar el mensaje. Este proceso evita tener varias entradas para errores similares y funciona igual que para los correos electrónicos.
El conector genérico extendido SMPP aplica un método heurístico para buscar valores predeterminados coherentes: si el estado comienza con DELIV, se considera un éxito porque coincide con los estados comunes utilizados por la mayoría de los proveedores DELIVRD o DELIVERED. Cualquier otro estado conlleva un error grave.