logo
abonnez go
Revue de presse
Archives Revue de presse
 
 
Accueil du site  > Tribune libre > L’enjeu des NPAI

L’enjeu des NPAI (2 juin 2005)

Cet article a pour but d’expliquer les enjeux marketing liés à l’interprétation des erreurs de routage lors d’une campagne d’email marketing.

Au sommaire
 Ne pas confondre NPAI et Bounce
 La distinction NPAI Hard et Soft, pas si simple
 Des enjeux variables suivant la nature des bases
 Le cas des éditeurs de solution d’emailing
 En synthèse

Ne pas confondre NPAI et Bounce

Une des raisons de l’intérêt de l’emailing réside dans la gestion intégrée et automatisée des NPAI (N’habite Plus A l’Adresse Indiquée) et des bounces.
Pour ceux qui ont connu les campagnes postales classique, la gestion des NPAI est parfois un cauchemar et le traitement manuel des adresses incorrectes est très lourd.

Avec l’emailing la gestion des erreurs devient simple : retour d’un fichier Excel par le routeur ou une mise à jour instantanée de la base suivant le niveau d’interconnexion avec la base d’envoi. Gain de temps évident, fiabilité de gestion, rapidité de retour d’information, des arguments qui rendent le canal email très séduisant.

Toutefois derrière cette apparente simplicité, la gestion des erreurs de routage demeure une fonctionnalité sensible qui différencie fortement les différents prestataires et routeurs du marché.

Pour le comprendre, intéressons-nous aux aspects techniques de l’envoi d’un email.
Tous les envois d’email s’effectuent grâce au réseau Internet et à un serveur de mail qui correspond avec le serveur gérant la boite du destinataire. Cela se réalise grâce à un protocole appelé le SMTP. Le S de STMP est d’ailleurs une des causes du SPAM car il signifie ’Simple’. Protocole trop simple diront nombre de gestionnaire de réseau et beaucoup de fraudes sont possible.

En cas d’adresse ou de serveur inconnu, 2 types d’erreur sont retournés
 les erreurs dues au réseau internet : les Bounces. Ce sont les serveurs introuvables, les noms de domaines incorrects ...
 les erreurs dues au serveur de mail destinataire (NPAI). Elles sont normalement standardisées par une norme Internet (RFC 821 et 822 pour nos amis techniciens)

Un code désignant le type d’erreur associé à un libellé est retournée au serveur d’envoi sous forme d’un email ou d’une chaîne de caractères. Le serveur d’envoi n’a plus qu’à analyser le contenu de ce code qui est standardisé par une trentaine de type d’erreur.
Malheureusement la nomenclature du code n’est pas respectée par les gestionnaires de boite aux lettres électroniques pour diverses raisons (manque de temps, contexte spécifique du Spam ... ).

La distinction NPAI Hard et Soft, pas si simple

L’enjeu pour l’émetteur du courrier est alors de cerner si son adresse est définitivement (NPAI Hard) ou temporairement (NPAI Soft) incorrecte.

Pour affiner cette identification, certains routeurs (pas tous) ont mis en place des outils d’analyse syntaxique des libellés des emails retournés. Au lieu de se baser sur le code, on analyse le contenu du libellé associé. Ces outils sont basés sur des dictionnaires ’maison’ permettant d’associer un type de NPAI à un ensemble de terme descriptif.

Par exemple pour une erreur de type ’boite pleine’, les mots clefs associés sont : full box, overload box ...
Associé à un programme plus ou moins élaboré (de type logique floue), le système est efficace s’il est maintenu à jour.En effet les règles d’analyse peuvent être amenées à changer avec le temps car les gestionnaires de boites mail (notamment FAI et Webmail) peuvent modifier la nature des messages retournée.

Exemple :
Suite à une attaque massive sur ses serveurs de messagerie, un FAI connu, décide de changer les messages de retour. Il a constaté que les spammeurs utilisent les codes d’erreur pour cerner si la boite aux lettres existe (avant de l’inonder de message). Le code d’erreur est donc changé (voir supprimé) pour brouiller les pistes.

Enfin certains cas délicats doivent aussi être gérés.
Il est devenu fréquent dans des environnements professionnels, de programmer sur sa boîte mail, une réponse automatique vers l’expéditeur du message (congés parental, déplacement à l’étranger ... ). Lors d’un envoi sur cette adresse, le message est retourné avec un libellé d’erreur qui peut être :
’Je suis en congés parental, et de retour le 16 mars 2005’
’Je suis en déplacement jusqu’au 16 mars 2005, en cas de problème merci de contacter mon collaborateur ’

Le système d’analyse doit pouvoir classer correctement cette réponse et la considérer comme temporairement incorrecte. Bien sur dans un environnement international, l’analyse multilingue est nécessaire et la complexité d’identification et de classement augmente.

Exemple d’analyse sur des plate-formes ASP

Des enjeux variables suivant la nature des bases

Le changement des codes NPAI est effectué sans prévenir les routeurs du monde Internet.
Si ceux-ci ne sont pas attentifs à la nature des codes retournée et l’évolution des NPAI par Fai ou Webmail, l’adresse en erreur peut passer pour définitivement incorrecte alors que celle-ci l’est temporairement.
Les enjeux ? Ils peuvent être conséquent pour un gestionnaire de base d’email.

D’un routeur à l’autre, le nombre de NPAI sur une même base et un même envoi peut varier fortement suivant la finesse d’analyse des NPAI. Parfois les NPAI soft sont surestimés (et les adresses sont routées de nouveau), parfois les NPAI Hard sont exagérés et la base perd des adresses potentiellement récupérables.

On constate chez les routeurs une forte différence de moyens humains et techniques employés pour gérer correctement les NPA (et aussi le SPAM mais ce sera le cas d’un autre article). Certains y affectent un technicien à mi temps avec des dispositifs d’alerte sophistiqués (pager ...) et une analyse syntaxique développée, d’autres y consacre 1 ou 2 heures parfois au gré des incidents et base la classification Soft et Hard suivant le seul code d’erreur retourné par le serveur.

Bien sur tout cela a un coût et la différence se traduit par une qualité de routage et d’analyse des retours. Pour certain annonceur, cette qualité de routage n’a que peu d’enjeux, pour d’autres (base de fidélisation client, propriétaire de base louée .. ), elle est importante.

 En BtoB ou les adresses des FAI et Webmail sont rares, des règles d’analyse syntaxique de bases associées à une surveillance moyenne de l’évolution semblent suffisantes.

 A l’inverse en BtoC, la présence forte de FAI (Wanadoo, Free ...) qui peuvent changer, sans prévenir, les règles de gestion, nécessite une gestion attentive des NPAI.

Un cas spécifique : celui des éditeurs de solution d’emailing

En effet, comment les éditeurs de solutions d’emailing envisage t’il le suivi du traitement des NPAI ? Souvent les prestataires ASP argumentent leur supériorité dans ce domaine par rapport aux ASP en évoquant la fourniture de ce service intégré :

Neolane, un éditeur français de logiciel de gestion de campagne multicanaux, qui a initialement développé le canal email, fournit un module d’analyse syntaxique de base, avec des règles de base qui sont prédéfinies. Un développement assez lourd (plusieurs mois d’ingénieur) que l’éditeur a réalisé il y a plus de 2 ans. Il reste à faire vivre ces règles si nécessaires. Toutefois en discutant avec certains acteurs de la chaîne de routage, on s’aperçoit qu’il y a eu peu de changement auprès des grands Webmail et FAI du marché ces derniers 6 mois. La situation serait donc relativement stable.

En synthèse

La qualification des NPAI soft (temporaire) ou hard (définitif) constitue un enjeux pour
 l’annonceur s’il souhaite maintenir la qualité de sa base client ou commercialisé
 le routeur en terme de coût de développement technique et de suivi des évolutions des erreurs de routage du marché

Elle constitue un facteur important pour la sélection d’une solution de gestion de campagne d’emailing et il importe de bien vérifier les moyens mis en place pour évaluer la qualité de routage.

Comment l’évaluer ? Bien sur questionner votre prestataire sur le moyens mis en œuvre, mais pourquoi ne pas réaliser un test entre quelques routeurs sur une base homogène ?

Bruno Florence
http://www.florenceconsultant.com