Développeur Web avant tout…
Starting Open Mailing project
Lors des changements du site EXinsidePHP j’ai fait quelques annonces dont une au sujet d’un gros projet Open Source. Il est l’heure aujourd’hui de faire un peu de teasing et de lever le voile sur ce projet. Comme vous pouvez le constater il se nomme « Open Mailing » et vous devez déjà vous douter un peu de ce dont il va s’agir…
En matière de gestion de mailing il y a deux écoles :
- Passer par une société spécialisée comme EmailVision
- Gérer les envois via des outils internes
Après quelques observations je me suis rendu compte de plusieurs choses, tout d’abord les sociétés spécialisées travaillent uniquement sur des gros volumes, il est alors difficile pour pas mal d’entreprises de franchir le cap surtout lorsque l’on a un projet non transactionnel. Faire un tel investissement sans savoir les retours financiers n’est pas donné à toutes les entreprises et certaines (voir beaucoup) n’en ont surtout pas les moyens. Il faut avouer que ces société de mailing font payer leur qualité au prix d’or.
Ainsi en discutant avec mes relations dans le milieu du web on remarque que beaucoup d’entreprises envoient leur mailing de façon « artisanale ». Certaines ont développé des outils internes plus ou moins complets, mais bien souvent cela se limite à des envois massifs sans avoir les moyens de savoir exactement ce qui se passe par la suite :
- Les mails sont ils bien arrivés à destination ?
- Est ce que les mails arrivent bien dans la boite de réception et non en Spam ?
- Combien de personnes ont cliqué ?
- Les mails sont ils bien affichés sur les webmails ?
- Qu’ont fait les internautes après avoir cliqué sur un lien du mail ?
- Le mail était il ciblé ?
- Et bien d’autres choses encore….
Le problème des solutions développées en interne lorsque l’on souhaite un outil complet est de la maintenir et cela à évidemment un coût en homme et donc comptable.
Bien souvent on trouve des outils Open Source qui répondent à nos besoin, par exemple si vous voulez créer une boutique e-commerce vous avez Prestashop ou encore Magento. Ainsi après quelques recherches au niveau de la gestion de mailing, il n’existe pour ainsi dire rien en Open Source.
C’est ainsi que le projet Open Mailing est né, j’en ai longtemps discuté avec mes contacts pour valider mes observations et évaluer le besoin à ce niveau. Tous sont en accord avec mes observations et il y a un vrai besoin qui est d’avoir un outil complet de gestion de leurs newsletters. Même si la délivrabilité est un point important, beaucoup souhaitent avoir un tel outil pour commencer tout en sachant qu’il n’auront pas la délivrabilité d’un société telle qu’EmailVision qui a des accords particuliers de routing. Il faut considérer qu’Open Mailing permettra de gérer de façon avancé ses newsletter à moindre coup le temps d’avoir les moyens de se payer les services d’une société spécialisée.
Aujourd’hui le projet a une existence officielle et la réflexion est en cours pour définir exactement quelles fonctionnalités il devra intégrer. Un plan avec des versions datées sera sans doute bientôt annoncé. D’ailleurs si vous avez des idées de fonctionnalités n’hésitez pas à les formuler en commentaire de cet article.
Pour ce qui est de son mode de diffusion je vais reprendre le principe du projet Prestashop :
- Une application de base qui sera diffusée gratuitement
- Un boutique de modules complémentaires, ceux-ci seront payant et permettront un accès à des fonctionnalités avancées.
Voilà pour commencer, je vous tiendrais évidemment au courant des avancées du projet. C’est tout, pour le moment…
| Imprimer l'article | Cette entrée a été posté par Steuf le 12 avril 2010 à 10 h 49 min, et placée dans Les projets EXinsidePHP, Open Mailing. Vous pouvez suivre les réponses à cette entrée via RSS 2.0. Vous pouvez laisser une réponse, ou bien un trackback depuis votre site. |
about 3 years ago
J’ai demarrer ce projet de mon coté avec une version alpha qui fonctionne tres biens mais le VRAI probleme d’authentifier le server d’expedition comme un expediteur de confiance reste LE soucis de l’envoie de masse
about 3 years ago
En effet, je vois mal comment faire une authentification du type Sender ID, SPF, Domain Keys ou encore DKIM en PHP.
Il va te falloir un serveur SMTP, non ? Ou bien chacun devra utiliser son serveur SMTP (donc celui de son FAI dans la plupart des cas).
Ton projet est tout à fait honorable mais vas tu modérer les envois ? Car ton outil pourrait tomber entre de mauvaises mains. Pour un FAI ou un filtre, comment séparer le bon grain de l’ivraie (un courrier non sollicité n’est pas que de la pub pour les petites pilules bleues). Je pense que rapidement, ta plateforme va être identifiée/identifiable et les mailings seront pénalisés de base.
Et pour finir, il y a d’autres solutions emailing professionnelles à prix abordable, je pense notamment à Sarbacane.
L’email est un canal de communication comme un autre. Comme tout autre poste, je pense qu’il doit être budgété. Une entreprise qui démarre doit elle / peut elle communiquer par ce biais ? Normalement sa base d’adresses est presque vide.
La location ou l’achat de base peut poser de réels soucis car il existe très peu de base à jour dont les destinataires sont ok (optin) pour tout type de publicité.
Bien souvent, un destinataire donne son accord puis veut se désabonner. Mais entre temps, la base a été vendue/louée une quinzaine de fois. Les 15 désinscriptions n’affecteront pas le listing originel. C’est le spam commercial, « propre » mais non sollicité.
about 3 years ago
Attention ne pas confondre outil et méthode d’envoi des mails. Open Mailing sera un outils permettant de gérer les newsletter et permettra par exemple :
- La segmentation de la base de contacts
- Possibilité d’envoi par paquet à des horaires définis suivant la segmentation de la base
- Envoi des mails via le ou les serveurs définis dans la configuration
- Statistiques et suivi, taux de clique, ROI, les pages consultées par les contacts etc etc
- Test des campagnes via des modules par exemple pour vérifier le bon affichage de celle-ci dans les principale webmail ou encore un envois de test pour vérifier si le mail arrive bien à destination.
Je fournis donc une application permettant de gérer les mailing mais en aucun cas je ne prend en charge les envois des emails. Cette partie restera à la charge des personnes qui utiliseront l’application PHP et devront donc avoir un serveur (ou plusieurs) en leur possession ou qu’ils auront loués (sur smtp.com par exemple). L’application sera capable de faire des tests sur des boites mails courantes (gmail,hotmail etc) et indiquera si le mail de test arrive en spam ou non permettant de détecter des problèmes de configuration et agir en conséquence sur la configuration de leurs serveurs.
Sinon oui une entreprise commence généralement avec une base de donnée vide (quoique pas toujours) mais il existe de nombreux sites qui ont peu de revenus, beaucoup de membres, et pas les moyens de se payer EmailVision à 1000€/Mois
.
Je pense en fait que tu n’as pas saisi ce qu’est OpenMailing (Je pensais que c’était clair pourtant).
about 3 years ago
En effet, je n’avais pas bien saisi le fonctionnement d’OpenMailing mais j’apportais aussi une réponse à jarodxxx.
Pour rebondir sur ta réponse, je serai curieux de savoir comment remonter l’information du filtrage en spam ou non sur les webmails.
Donc je te rejoins finalement sur l’existence d’un outil semblable en open source.
Hâte de voir le résultat.
about 3 years ago
Quelle plus value / phplist?
about 3 years ago
Les plus valus par rapport à PHPList par exemple :
- Au niveau des statistiques, avec des statistiques graphiques, pouvoir exporter un rapport en PDF, exporter des statistiques en CSV etc. Avec des statiques allant plus loin que les simples statistiques Visualisations/Clics j’ai notamment parlé de ROI soit combien de personnes de ma newsletter ont acheté le produit que j’ai mis en valeur etc…
- Mise en place d’une API permettant d’interfacer le site et l’application, pour permettre les statistiques sur les ventes et de savoir exactement les actions de l’utilisateur sur le site, quelles pages à t’il vu, qu’a t’il acheté ?
- Une interface clair et simple (Celle de phplist est assez ergonomique et fouillis)
- Un projet suivi (Pas une mise à jour mineur par an (PHPList)
- La possibilité de segmenter les listes et de par exemple planifier les envois à des horaires différent par segment de la liste (les marketeux comprendront)
- L’envoi de test plus poussé : Ne se limitant pas à l’envoi de l’adresse email de l’administrateur, mais par exemple en faisant des envois au webmails les plus connues (hotmail, gmail, aol and co) et connaitre les statistiques de dérivabilité
- Un système de Plungin permettant à la communauté de créer des plugins pour ajouter des fonctionnalités
Etc etc etc… Les idées et fonctionnalités manquantes ne manques pas par rapport à PHPList qui reste un outils « basique ».
about 3 years ago
Pourquoi tu te base pas sur un framework ? style ZF ?
about 3 years ago
Si j’en utilise un ExFramework… Alors pourquoi pas Zend ? Je ne suis ni pro ni anti framework (j’utilise d’ailleurs Zend au boulo) mais pour moi un Framework s’utilise et se CHOISIT en fonction des besoins. On utilise pas ZF ou SF à toutes les sauces, ils ne sont pas fait pour ça.
Une première raison pour laquelle ici Zend n’a pas été choisi c’est que Zend c’est lourd. Dès que l’on commence à faire quelque chose avec on monte facilement à 4Mo de ram utilisé pour générer la page. Donc exit Zend s’il n’est pas couplé à Xcache et certaines configurations serveur. Ceci dit ce n’est pas une critique c’est inhérent à toute sur-couche… De plus si les frameworks sont mal utilisés ton application sera un mammouth plutôt qu’un guépard. Ce que j’appelle le syndrome J2EE.
Secondo, dans un projet Open Source on évite d’avoir trop de dépendance, j’ai bien avoir la maîtrise sur l’ensemble du projet, dès qu’il y a un problème je peut être très réactif. De la même façon tous les développeurs branchés performance et optimisation te diront qu’il vaut mieux un code spécifique répondant à tes besoins plutôt que d’utiliser tout un bardage de librairie génériques qui rendent ton code beaucoup moins performant.
Sachez d’ailleurs qu’on peut très bien développer rapidement et proprement sans utiliser de Framework
Donc ici c’est pour cela qu’ici je préfère utiliser un framework léger et offrant les outils VRAIMENT indispensables pour simplifier le développement et comme c’est l’esprit d’ExFramework et que j’en maitrise tous les aspects j’utilise donc ce que j’ai déjà créé.
about 3 years ago
Hello,
pour Zend je suis pas d’accord avec toi, j’utilise ZF sur tous mes projets notamment sur http://fr.audiofanzine.com (700 000 pages vue par jours et plus de 515 000 membres) et zend répond bien et monte pas a 4Mo par page lol effectivement il faut un système de cache style APC et memcache pour les donnée (pour soulagé mysql),
puis sur mon site perso j’utilise ZF et niveau perf. c’est correcte 165ms environ pour la génération de la page (en mode MVC) sinon pour mes requests ajax j’utilise pas le MVC je passe par une page ajax.php qui fait appèle au classes Zend et la je tombe a 45ms donc je vois pas ou est le problème des perf. Zend est un gros framework, il pourrais faire 1Go c’est pas ça qui vais faire perdre des perf. a ton projet tu appèle pas tous les classes du framework en mem temps lol
puis
« tous les développeurs branchés performance et optimisation te diront qu’il vaut mieux un code spécifique répondant à tes besoins plutôt que d’utiliser tout un bardage de librairie génériques qui rendent ton code beaucoup moins performant. »
Zend répond a tous les besoin c’est pas un CMS, effectivement on choisit sa technologie en fonction du projet, on vas pas codé un bot d’indexation a la googlebot en php (quoi que c’est possible mais pas du tout performant), tu utilise bien Swift Maler alors pour quoi pas Zend_Mail ?
moi aussi je préféré codé tout moi meme j’avais une maitrise de mon projet, mais avec le temps on apprends vite que rien ne sert de réinventé la roue et c’est pour ça que j’utilise Zend dans tous mes projets
about 3 years ago
Hello,
Pour te répondre juste un petit bench au boulo :
Memory used : 4456448 octets – Memory allocated : 4718592 octets
Ce qui est utilisé sur Zend, Pdo_Mysql, Zend_Cache, Firebug via Zend… Et ceci sur un test unitaire d’un classe du projet qui fait 5-6 requêtes SQL. Un peu de lecture au sujet de la consommation mémoire de Zend :
http://www.wowww.ch/index.php?post/2009/03/23/Zend-Framework-Analyse-des-performances-et-benchmarks
http://www.rvdavid.net/test-results-on-memory-usage-of-zend-framework-and-doctrine-with-apc/
Etc etc etc… Pour ce qui est de Xcache oui c’est comme APC et ça permet justement de pallier à la surconsommation de ram de Zend. Les performances d’un site ne se limite pas au temps qu’il met à générer la page que tu veux, ça se mesure aussi en consommation de ressources sur ton serveur… Entre un application qui ne me permet que 500 connexions simultanées sous zend et une qui me permet 1000 connexions simultanées mon choix est vite fait…
Après je ne critique en aucun cas Zend, j’apprécie certaines choses de ce Framework. Alors pourquoi Zwift Mail au lieu de Zend Mail ? Tout simplement parce que dès que tu utilise quelque chose sur Zend il t’inclut je ne sais combien de dépendances permettant de gérer tous les cas de figures et dont les 3/4 je n’en ai pas besoin. J’appelle ça du gaspillage.
Donc non je persiste et je signe, Zend c’est bien pour gagner du temps, ça ne l’est pas quand tu vise la performance et performance ça ne veut seulement pas dire temps de génération de ta page…