Recommander un système de publipostage flexible pour ce numéro

Question

1200 abonnés sont envoyés par e-mail chaque jour. Le profil de chaque utilisateur peut varier en fonction de ses intérêts, qu'il s'agisse de la zone géographique, du secteur du marché ou même du type de produit.

Chaque jour, jusqu'à 20 nouveaux rapports sont créés par les chercheurs et les utilisateurs reçoivent un e-mail quotidien avec les préfaces des rapports qui les intéressent (avec un lien vers un site Web affichant le rapport complet).

[Les rapports sont également classés par zone géographique, secteur du marché et le type de produit]

Les e-mails sont actuellement diffusés via un serveur smtp. Chaque utilisateur a son email construit selon la correspondance entre son profil et les catégories de rapport.

Existe-t-il un système de publipostage flexible qui peut remplacer le serveur smtp? Si oui, que recommandent les gens?

Nous utilisons la technologie dotNet. Il est peu probable que le nombre d'abonnés soit supérieur à 5000. Je suis sous pression pour intégrer cela aux autres systèmes de publipostage utilisés par la société. Ils ne sont pas heureux avec smpt. Cette société emploie 30k dans le monde entier. L'application décrite ci-dessus est un service de nouvelles personnalisé et non un système de marketing. Ils standardisent sur Solaris/Java/etc mais sont heureux de garder la technologie actuelle (à part le bit smtp).

Answer 1

Vous ne vous trompez pas. Pas mon idée d'utiliser smtp. Pas mon idée de fournir ce degré de flexibilité dans la conception du profil de l'utilisateur.

Cette application appartenait à une petite entreprise qui a été rachetée par le plus grand. Le système utilisé à l'origine smpt (et le fait toujours). Les systèmes de publipostage que j'ai vus [Lyris. Pure360] ne semble pas construire d'emails par login et semble orienté vers le marketing (pas de reportage personnalisé). La seule façon dont j'imagine que cela est fait est d'avoir une propriété utilisateur (une liste d'identifiants des rapports qu'un utilisateur recevra ce jour-là) et de mettre cette propriété de l'utilisateur à jour juste avant l'emailing.

Je ne paierai pas la logique (pour le publipostage) qui détermine quel utilisateur obtient quels rapports.