Hello Patrick,
On Nov 11, 1:53 am, "Patrick J. Anderson" <[EMAIL PROTECTED]>
wrote:
>
> Some of the main requirements are:
>
> * Personalised HTML/text messages
> * Manual delivery twice a week
> * Message logging/archiving
> * Amount of newsleter issues: ~50
> * Amount of subscribers: 500-5000
We (as company) has created 6 different versions of Newsletter for our
customers. They are
all commercial, but we plan to release some non-commercial version
too, as part of our e-commerce
solution, djWarehouse.
What about the Newsletter, I can explain the architecture for you, so
you would not fall into problems which had us to rewrite our
Newsletter 6 times until we get satisfied with results.
We have the following models:
Newsletter (name, added, sent, status (NEW, READY, SCHEDULING,
SENDING, SENT)
MessageSet (name, newsletter, category, status (same as in
newsletter))
Message (messageset foreign key, marker_tag, subject, from name, from
email, format, message)
MessageCopy(user, messageset, message)
MessageResponse(message, url, count)
This newsletter is used on some of our sites, with thousands of
subscribers. (100000-200000). The logick is the following:
customers are subscribed to some specific categories on site. We have
choice to send general newsletter to all customers, or customize
messages by categories. MesageSet - a number of messages sent to
specific category[ies]. Every newsletter can contain a few message
sets. Why so complicated? Because we need to know what information is
more interesting to end users. Counting the results in MessageResponse
we find out how many customers clicked the links in one or another
newsletter, and know what customers are more interested in - this data
is used for next monthly newsletter from the site.
Now, the process of sending newsletter. That is one of the most
difficult parts of the process, since the SMTP protocol and message
daemons are not allowing to do many things, so we have to organize
things ourself. For example, since our sites have such a large users
base, Yahoo, Gmail, and specifically Hotmail were blocking our legal
newsletter every time, because from a few hundreds thousands
subscribers, a large part belongs to those online services (a few
thousands) and those services will automatically put you in "block
list" as soon as you try to send messages too quick.
That is why, we don't just send mails out via SMTP. The process of
sending is the following:
1. When admin press "send" newsletter button, this only triggers the
process to save data to MesageCopy.
2. An external program, run in 'daemon' mode, watches the table, and
maintains the list
of exeternal web services (Yahoo, MSN, etc). This daemon controls
that SMTP send out rate should
not exceed some specific amount for specific service.
So far, this architecture works out the best. We are using this 6th
version of improved newsletter for last 1.5 years, without any
problems.
I can not post the whole code here because the program is commercial,
but... some smaller version will be released soon. Anyway, most of
customers need to only send mails to a few thousands customers, not a
few hundreds thousands, so some advanced functions are just not needed
for an average customer.
Hope that information is useful.
Best Regards.
Alex
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
