Hé les gens !

Je vous signale quand même qu’avant de désinscrire un subscriber, on attends 3 
échecs consécutifs.

Ça signifie donc qu’ici pendant 3 semaines de suite une nouvelle newsletter a 
été envoyée sans s’inquiéter le moins du monde que les semaines précédentes 
tous les envois avaient été en echec (100% fail).

On a donc déjà un feedback dans l’interface, le temps de voir et de réagir, et 
si on arrive à ce genre de « catastrophe » c’est bien parce que des 
utilisateurs ont continué à pousser sur le bouton « envoyer » sans se poser la 
moindre question.

Moi je dis vous devriez être content : sans la disparition des inscriptions les 
utilisateurs n’auraient pas réagis et continueraient à envoyer dans un trou 
noir leur newsletter toutes les semaines :)

Cela dit, et pour être plus constructif :

 - les erreurs documentées en cas d’erreur d’envoi ne sont pas exhaustives, et 
ne contiennent pas forcément tous les cas d’erreur. Du coup difficile de gérer 
ces cas là sans risquer d’ignorer des erreurs gênantes. D’autant plus quand il 
s’agit du changement de politique commerciale d’un opérateur, pas sur qu’ils 
aient utilisé une erreur standard
 - mais on pourrait au moins prévoir un 3ème type de réponse type « hors quota 
» qui ne serait pas pris en compte pour les désinscription, avec la possibilité 
de compléter la gestion d’erreur des prestataire au fur et à mesure. Pour info 
vos logs doivent contenir la réponse des prestataire, donc n’hésitez pas à 
faire un feedback constructif avec des exemples d’erreur non gérés :)
Cela dit c’est non trivial, ça suppose aussi l’ajout d’un statut du type « 
envoi impossible » qui n’est pas un fail, dans la table de suivi des envois

 - plus prosaiquement et facilement, on pourrait, quand un envoi se finit avec 
100% en echec
  - lever un flag qui dit « envois suspendus » et bloc tout nouvel envoi 
automatique
  - envoyer un mail au webmestre pour l’avertir
  - Afficher un gros message d’erreur qui dit « 100% du dernier envoi a échoué, 
résolvez le problème » et demande une validation si jamais on veut faire un 
nouvel envoi

Donc comme tout logiciel on peut améliorer, mais de là à protester que le 
plugin vous a perdu vos inscriptions, je dis non. Il a pris un certain nombre 
de précautions avant de faire ça et l’inattention totale des utilisateurs en 
est la raison principale.

Et donc oui, je pense que c’est rendre service que de faire comprendre aux gens 
que l’envoi en masse d’emails ne va pas de soi.

Et pousser sur le bouton « envoyer » automatiquement, sans se préoccuper de 
savoir si les mails arrivent ni de la qualité du listing, est aussi mauvais et 
nuisible a long terme que de remplir sa poubelle de déchets et la mettre toutes 
les semaines devant sa porte sans réfléchir en se disant que tout ça disparait 
magiquement :)

Spammeurs, pollueurs, même combat et c’est trop facile de se défausser sur le 
fait qu’il y a des plus gros qui font pire à côté pour ne pas faire d’effort.
(et si ça peut vous rassurer je tiens le même discours aux utilisateurs finaux 
du plugin que je gère en direct)

Des bises renouvelables,

--
Cédric
Le 3 déc. 2019 à 00:23 +0100, Pascal JPM <pas...@editions-jpm.fr>, a écrit :
> +1 pour la réponse de RASTA.
>
> Merci Cédric pour le camouflet (au départ, je voulais écrire "insulte"), je
> suis donc un GROS VILAIN SPAMMEUR avec mes petites associations qui n'ont
> pas, par moment, les moyens financiers qu'elles souhaiteraient et envers
> lesquelles je lutte régulièrement pour que la RGPD s'applique à la Lettre...
> Merci, c'est super cool !
>
> Ne pourrait-on pas "simplement" être averti qu'il y a eu un problème
> "technik" avant de sortir la pelleteuse pour enterrer tout le monde ?
>
> Cordialement,
> Pascual
>
>
> -----Message d'origine-----
> De : RastaPopoulos <rastapopou...@spip.org>
> Envoyé : lundi 2 décembre 2019 15:23
> À : spip-zone@rezo.net
> Objet : Re: [SPIP Zone] Mailshot, limite Sparkpost et mauvaises
> désinscriptions automatiques
>
> Le 02/12/2019 à 14:52, Cerdic a écrit :
> > Plus prosaïquement je veux dire : l�envoi propre d�email c�est assez la
> merde comme ça pour qu�en plus on se fasse pas des cheveux blancs pour
> absolument simplifier la vie des spammeurs qui font pas le moindre effort
> (ici donc s�assurer que son service mail fonctionne toujours).
>
> Mmmh : on parle de gens qui, un par un, ont CHOISI de s'inscrire, pour
> recevoir un email par semaine avec dedans des informations d'une assoc, dont
> ils sont membres ou qui les intéresse. Je vois donc mal à quel moment on
> peut appeler ça du spam, faut pas abuser. (D'autant plus que 900 c'est
> tellement que dalle, la limite la plus basse de Mailjet payant est 30000
> on
> en est tellement loin
> )
>
> Il me semble que les prestataires d'envoi ont bien l'information, et ne
> disent pas la même chose quand il s'agit d'un email qui n'existe pas, qui
> est erroné, et quand il s'agit simplement qu'on a atteint la limite d'envoi
> et que le prestataire refuse d'envoyer plus. Ça n'a vraiment strictement
> rien à voir.
>
> Et donc, non, je vois pas pourquoi des échecs qui sont dus à la limite
> d'envoi du prestataire devrait désinscrire les gens, ya aucun rapport.
>
> On va essayer de les aider à récupérer à la main, ok, je ne vois que ça.
> Mais c'est clairement un bug du plugin, pour les prochaines fois ou les
> autres gens qui atteignent une limite d'envoi (par exemple quand on est une
> assoc sans beaucoup d'argent et qu'on avait pas encore souscrit à un truc
> payant), aucune raison de pénaliser artificiellement ces gens.
>
> --
> RastaPopoulos
>
> ----
> spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone
>
> ----
> spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

Répondre à