Présentation des diffusions en échec delivery-failures
Les rebonds sont le résultat d’une tentative de diffusion ayant échoué pour laquelle le FAI renvoie des avis d’échec. Le traitement de la gestion des rebonds est un aspect essentiel de l’hygiène des listes. Une fois qu’un e-mail donné a été rejeté plusieurs fois de suite, ce processus le signale pour qu’il soit supprimé.
Ce processus empêche les systèmes de continuer à envoyer des e-mails à des adresses e-mail non valides. Les rebonds sont l’un des éléments clés des données que les FAI utilisent pour déterminer la réputation des adresses IP. Il est important de garder un œil sur cette mesure. La mesure « Diffusé » vis-à-vis de « Rebond » constitue probablement le moyen le plus courant de mesurer la diffusion des messages marketing : plus le pourcentage de diffusion est élevé, mieux c’est.
Si un message ne peut pas être envoyé à un profil, le serveur distant envoie automatiquement un message d'erreur à Adobe Campaign. Cette erreur est qualifiée pour déterminer si l'adresse e-mail, le numéro de téléphone ou l'appareil doit être mis en quarantaine. Pour plus d’informations, consultez la section Gestion des e-mails rejetés.
Une fois un message envoyé, vous pouvez visualiser l'état de la diffusion pour chaque profil, le type d'échec et la raison associés dans les logs de diffusion.
Lorsqu'une adresse e-mail est mise en quarantaine ou qu'un profil est en liste bloquée, le destinataire est exclu à l'étape de préparation des diffusions. Les messages exclus sont répertoriés dans le tableau de bord de la diffusion.
Pourquoi la diffusion du message a-t-elle échoué ? delivery-failure-reasons
Deux types d'erreur sont liés à un message en échec. Chaque type d'échec de diffusion détermine si une adresse est envoyée en quarantaine ou non.
-
Rebonds définitifs
Les rebonds définitifs sont des échecs permanents générés lorsqu’un FAI détermine qu’une tentative de publipostage vers une adresse d’abonné n’est pas livrable. Dans Adobe Campaign, les rebonds définitifs indiqués comme non diffusables sont ajoutés à la liste de quarantaine, ce qui signifie qu’ils ne feront pas l’objet d’une nouvelle tentative. Dans certains cas, un rebond définitif peut être ignoré si la cause de l’échec est inconnue.Voici quelques exemples courants de rebonds définitifs : adresse inexistante, compte désactivé, syntaxe incorrecte, domaine incorrect.
-
Rebonds temporaires
Les rebonds temporaires sont des échecs temporaires que les FAI génèrent lorsqu’ils ont des difficultés à diffuser des e-mails. Les échecs de type soft feront l'objet de plusieurs reprises (avec des variations selon l'utilisation de paramètres de diffusion personnalisés ou prêts à l'emploi) afin de tenter une diffusion réussie. Les adresses qui continuent à provoquer des rebonds temporaires ne seront pas mises en quarantaine tant que le nombre maximum de tentatives n’aura pas été effectué (qui varie encore selon les paramètres).Voici quelques causes courantes des rebonds temporaires : boîte pleine, serveur de messagerie de réception en panne, problèmes de réputation de l’expéditeur
Le type d'erreur ignoré est une erreur temporaire, par exemple « Absent du bureau », ou une erreur technique, par exemple si l'expéditeur est de type « postmaster ».
La boucle des retours fonctionne comme les e-mails rebonds : lorsqu'un utilisateur qualifie un e-mail de spam, vous pouvez configurer des règles de messagerie dans Adobe Campaign pour bloquer toutes les diffusions à cet utilisateur. Les adresses de ces utilisateurs figurent sur la liste bloquée même s'ils n'ont pas cliqué sur le lien de désinscription. Les adresses sont ajoutées à la table des quarantaines (NmsAddress) et non à la table des destinataires (NmsRecipient), avec le statut Placée sur la liste bloquée. En savoir plus sur sur le mécanisme de feedback loop dans le guide des bonnes pratiques en matière de délivrabilité d’Adobe.
Erreurs synchrones et asynchrones synchronous-and-asynchronous-errors
Une diffusion de message peut échouer immédiatement. Dans ce cas, nous qualifions cela d'erreur synchrone. Si l'envoi du message échoue ou si l'envoi échoue plus tard, une fois qu'il a été envoyé, l'erreur est asynchrone.
Ces types d'erreurs sont gérés comme suit :
-
Erreur synchrone : le serveur distant contacté par le serveur de diffusion Adobe Campaign retourne immédiatement un message d'erreur. L'envoi de la diffusion au serveur du profil n'est pas autorisé. Le MTA (Mail Transfer Agent) détermine le type de rebond et qualifie l’erreur, puis renvoie ces informations à Campaign afin de déterminer si les adresses e-mail concernées doivent être mises en quarantaine. Voir Qualification des e-mails rejetés.
-
Erreur asynchrone : un e-mail rejeté ou un SR est renvoyé plus tard par le serveur de réception. Cette erreur est qualifiée avec un libellé associé à l'erreur. Les erreurs asynchrones peuvent se produire jusqu'à une semaine après l'envoi d'une diffusion.
Qualification des e-mails rebonds bounce-mail-qualification
Actuellement, le traitement de la qualification des e-mails rejetés dans Adobe Campaign dépend du type d’erreur :
-
Erreurs synchrones : le MTA détermine le type et la qualification du rebond, puis renvoie ces informations à Campaign. Les qualifications de mails rebonds dans la table Qualification des logs de diffusion ne sont plus utilisées pour les messages d'erreur relatifs aux échecs des diffusions synchrones.
-
Erreurs asynchrones : les règles utilisées par Campaign pour qualifier les diffusions en échec asynchrones sont répertoriées dans le nœud Administration > Gestion de campagne > Gestion des échecs > Qualification des logs de diffusion. Les rebonds asynchrones restent qualifiés par le processus inMail grâce aux règles E-mail entrant. Pour en savoir plus, consultez la documentation d’Adobe Campaign Classic v7.
Gestion des reprises retries
Si la diffusion d'un message échoue suite à une erreur temporaire (Soft ou Ignoré), Campaign réalise une nouvelle tentative d'envoi. Ces reprises peuvent être effectuées jusqu'à la fin de la durée de diffusion.
Les reprises de rebonds temporaires et l’intervalle qui les sépare sont déterminés par le MTA en fonction du type et de la gravité des réponses des rebonds provenant du domaine de l’e-mail du message.
Période de validité valid-period
Le paramètre de la période de validité dans vos diffusions Campaign est limité à 3,5 jours ou moins. Si vous définissez une valeur supérieure à 3,5 jours pour une diffusion dans Campaign, elle ne sera pas prise en compte.
Par exemple, si la période de validité est définie sur la valeur par défaut de 5 jours dans Campaign, les messages soft bounce seront placés dans la file d’attente de reprises du MTA et ne feront l’objet d’une reprise que pendant 3,5 jours à compter du moment où ils ont atteint le MTA. Dans ce cas, la valeur définie dans Campaign ne sera pas utilisée.
Une fois qu’un message figure dans la file d’attente du MTA depuis 3,5 jours et qu’il n’a pas été diffusé, il expire et son statut est mis à jour de Envoi à Échec dans les logs de diffusion.
Pour plus d’informations sur la période de validité, consultez la documentation d’Adobe Campaign Classic v7.
Types d'erreur e-mail email-error-types
Pour le canal e-mail, les raisons possibles d'un échec de diffusion sont répertoriées ci-dessous.
Types d'erreur des notifications push push-error-types
Pour le canal des applications mobiles, les raisons possibles d'un échec de diffusion sont répertoriées ci-dessous.
Quarantaine iOS ios-quarantine
Le protocole HTTP/V2 permet des retours et un état directs pour chaque diffusion push. Si le connecteur de protocole HTTP/V2 est utilisé, le service des retours n'est plus appelé par le workflow mobileAppOptOutMgt. Un jeton est considéré comme non enregistré lorsqu'une application mobile est désinstallée ou réinstallée.
Si l'APNS renvoie de manière synchrone un statut "désinscrit" pour un message, le jeton cible est immédiatement mis en quarantaine.
Quarantaine Android android-quarantine
Pour Android V1
Pour chaque notification, Adobe Campaign reçoit les erreurs synchrones directement du serveur FCM. Adobe Campaign les gère à la volée et génère des erreurs hard ou soft selon la gravité des erreurs. Des reprises peuvent être effectuées :
- Dépassement de la longueur de la payload, problème de connexion, problème lié à la disponibilité du service : reprise effectuée, erreur soft, raison de l'échec : Refusés.
- Dépassement du quota d'appareils : aucune reprise, erreur soft, raison de l'échec : Refusés.
- Jeton non valide ou désinscrit, erreur inattendue, problème lié au compte de l'expéditeur : aucune reprise, erreur hard, raison de l'erreur : Refusés.
Le workflow mobileAppOptOutMgt s’exécute toutes les 6 heures pour mettre à jour le tableau AppSubscriptionRcp. Pour les jetons déclarés comme non enregistrés ou comme n’étant plus valides, le champ Désactivé est défini sur True et l’abonnement associé à ce jeton de périphérique est automatiquement exclu des diffusions ultérieures.
Pendant l'analyse de la diffusion, tous les appareils qui sont exclus de la cible sont automatiquement ajoutés à la table excludeLogAppSubRcp.
- Problème de connexion au début de la diffusion : type d'échec Indéfini, raison d'échec Inatteignable, reprise effectuée.
- Perte de connexion pendant une diffusion : erreur soft, raison d'échec Refusés, reprise effectuée.
- Erreur synchrone renvoyée par Baidu pendant l'envoi : erreur hard, raison d'échec Refusés, aucune reprise.
Pour Android V2
Le mécanisme de mise en quarantaine d'Android V2 utilise le même processus qu'Android V1. Il en va de même pour la mise à jour des abonnements et des exclusions. Pour en savoir plus, consultez la section Android V1.
Quarantaines des SMS sms-quarantines
Pour les connecteurs standards
Les spécificités du canal SMS sont énumérées ci-dessous.
Pour le connecteur SMPP générique étendu
Lors de l'utilisation du protocole SMPP pour envoyer des SMS, la gestion des erreurs est traitée différemment.
Le connecteur SMPP récupère les données du message de rapport de statut (SR) renvoyé à l’aide d’expressions régulières (regex) pour filtrer son contenu. Ces données sont ensuite comparées aux informations trouvées dans le tableau Qualification des logs de diffusion (disponible à partir du menu Administration > Gestion de campagne > Gestion des NP@I).
Avant qu’un nouveau type d’erreur ne soit qualifié, la raison de l’échec est toujours définie sur Refusé par défaut.
Exemple de message généré :
SR Generic DELIVRD 000|#MESSAGE#
-
Tous les messages d'erreur commencent par SR pour faire la distinction entre les codes d'erreur SMS et les codes d'erreur email.
-
La seconde partie (Generic, dans cet exemple) du message d'erreur fait référence au nom de l'implémentation du SMSC comme défini dans le champ Nom de l'implémentation du SMSC du compte externe SMS.
Comme un même code d'erreur peut avoir une signification différente pour chaque prestataire, ce champ vous permet de déterminer quel prestataire a généré le code d'erreur. Vous pouvez alors rechercher l'erreur dans la documentation du prestataire adéquat.
-
La troisième partie (DELIVRD, dans cet exemple) du message d'erreur correspond au code d'état récupéré du SR à l'aide de la regex d'extraction de code d'état définie dans le compte externe SMS.
Cette regex est spécifiée dans l'onglet Spécificités du SMSC du compte externe.
Par défaut, la regex extrait le champ stat: comme défini dans la section Appendix B de la spécification SMPP 3.4. -
La quatrième partie (000, dans cet exemple) du message d'erreur correspond au code d'erreur extrait du SR à l'aide de la regex d'extraction de code d'erreur définie dans le compte externe SMS.
Cette regex est spécifiée dans l'onglet Spécificités du SMSC du compte externe.
Par défaut, la regex extrait le champ err: comme défini dans la section Appendix B de la spécification SMPP 3.4.
-
Tout ce qui se trouve après la barre verticale (|) s’affiche uniquement dans la colonne Premier texte du tableau Qualification des logs de diffusion. Ce contenu est toujours remplacé par #MESSAGE# une fois le message normalisé. Ce processus évite d’avoir plusieurs entrées pour des erreurs similaires et est identique à celui des e-mails.
Le connecteur SMPP générique étendu applique une méthode heuristique pour rechercher des valeurs par défaut cohérentes : si le statut commence par DELIV, il est considéré comme une réussite, car il correspond aux statuts DELIVRD ou DELIVERED courants, utilisés par la plupart des prestataires. Tout autre statut correspond à un échec définitif.