Cette histoire remonte à quelques années. À l’époque, j’ai face à moi un client particulièrement exigeant… pour ne pas dire… pointilleux. Le soupçon pèse lourd sur les résultats d’une campagne emailing, ce qui m’oblige à générer rapports sur rapports.
L’annonceur en question ayant la possibilité de vérifier lui-même l’ensemble des interactions, il me remonte un problème qui selon lui prouve que nos rapports sont faux : Il y a un bounce qui a généré un clic !
Le doute s’installe
Oui, là, en effet, la pression était déjà grande, mais le doute s’installe. Je vérifie dans la base de donnée, et l’adresse en question a bien généré une erreur (et une erreur du genre permanente, pas du soft). Je pousse les investigations un peu plus loin et en effet des bounces cliquent régulièrement sur les campagnes (ça reste un volume extrêmement réduit tout de même).
Pas si étrange
Ces bounces actifs (un comble) ont une caractéristique en commun. Ce sont toujours les adresses qui ont été envoyées en premier lors d’une campagne.
Besoin d'aide ?
Lire du contenu ne fait pas tout. Le mieux, c’est d’en parler avec nous.
Qu’est-ce que ça veut dire ? Simplement que certaines destinations (FAI, Webmails, …) font passer les tous premiers messages d’une campagne déterminée dans leurs filtres anti-spam… que ce soit des adresses actives ou non. Et comme vous devez le savoir, de nos jours, les filtres anti-spam ne se contentent pas d’analyser le contenu de vos emails. Ces filtres cliquent et vérifient les différentes redirections qui s’opèrent derrière vos liens et ouvrent la page d’atterrissage finale.
Cette analyse des liens permet par exemple de vérifier si certaines URL ne sont pas référencées dans des listes noires dédiées (URIBL, SURBL, …), de vérifier le nombre de redirections (trop de redirections vous fait resembler à un spammeur) et d’analyser la cohérence de votre identité d’expéditeur (sujet sur lequel il faudra que Badsender revienne dans les prochaines semaine).
Remettre le mort-vivant dans son cercueil
Du coup, autre effet de bord (même si son volume sera très limité), vérifiez que vos programmes de gestion des actifs/inactifs ne remettent pas votre bounce sur le devant de la scène, par exemple en augmentant la pression marketing vers celui-ci. Une erreur permanente doit généré une désactivation définitive de l’adresse… dans tous les cas !
7 réponses
Bonjour Jonathan,
Une petite faute s’est glissée : « LA doute s’intalle » dans le 1er sous-titre ;),
Bonne journée !
Tu as aussi le cas de tous ces emails enterrés vivants, parce que leur serveur est mal configuré et renvoie de mauvais codes qui font que la plate forme, professionnelle, les classe en NPAI Hard et les enterre… alors que le client échange tous les jours avec eux par email. gloups !
Lucie > Merci, c’est corrigé !
Ce qui nous arrive fréquemment c’est un destinataire qui redirige vers plusieurs adresses et qu’une de ces adresses ne soit plus valide. Du coup, le destinataire initial passe en hard bounce (adresse inexistante) … et génère des ouverture et des clics… Pas facile à expliquer aux clients 🙂
Bonne journée
Alain > C’est bien pour ça que j’adore l’emailing 😉 On ne peut jamais se reposer sur nos lauriers !
Alain > bizarre, si l’adresse initiale n’est pas en bounce, pourquoi le bounce remonte jusqu’à vous ? C’est à la première adresse (celle qui redispatche) que cela doit remonter non ?
Par contre le coup tordu c’est quand il y a des alias comme chez Wanadoo/Orange. Le client désabonne bien son email orange mais celui en wanadoo fonctionne toujours et est reroutée sur son email orange. Il a beau s’être désabonné 15 fois sur son adresse orange, il reste toujours un abonnement effectif sur son adresse wanadoo 🙂 Donc il continue à recevoir les mails, râle et finit par vous déclarer en spam alors que techniquement c’est injustifié 😉
Dans ce cas, c’est avec les id de tracking qu’on peut remonter à l’adresse initiale et finalement la désabonner 🙂
Charles> C’est dans mon traitement des bounces, j’intercepte les dialogues smtp entre les serveurs et du coup j’ai ce type de message :
Mar 7 10:10:05 cerapoda postfix/cleanup[10298]: 8C33F2542A2: message-id=
Mar 7 10:10:05 cerapoda postfix/qmgr[14891]: 8C33F2542A2: from=, size=93554, nrcpt=1 (queue active)
Mar 7 10:10:07 cerapoda postfix/smtp[10307]: 8C33F2542A2: to=, relay=smtp-in.orange.fr[80.12.242.9]:25, conn_use=27, delay=1.7, delays=0.16/0.35/0.01/1.2, dsn=5.1.1, status=bounced (host smtp-in.orange.fr[80.12.242.9] said: 550 5.1.1 Adresse d au moins un destinataire invalide. Invalid recipient. OFR_416 [416] (in reply to RCPT TO command))
Mar 7 10:10:07 cerapoda postfix/bounce[10508]: 8C33F2542A2: sender non-delivery notification: 504922542A5
Mar 7 10:10:07 cerapoda postfix/qmgr[14891]: 8C33F2542A2: removed
Comme je fais mon traitement sur » Invalid recipient », ça passe en hard bounce… Je vais devoir traiter plutôt le « Adresse d au moins un destinataire invalide » et le passer en soft…
Concernant les désinscriptions, je n’ai pas ce genre de souci car je m’appuie sur l’adresse du destinataire de départ. Mais effectivement, si le destinataire n’utilise pas le liens de désinscription et me demande de le désinscrire (lors d’une redirection), si je n’ai pas le message de départ, je suis un peu embêté 🙂