If company already subscribed to MailChimp do they need also Mandril to send transactional emails such as app welcome, invites to join or befriend, password recovery etc.
Can one send password recovery or welcome email as one person campaign programmatically using MailChimp alone? Or is it too expensive or too cumbersome?
I've been using Mailchimp for a while and what you are seeking can be partially managed with a featured called automation within Mailchimp. It allows you to:
Set up any number of emails as chained emails (so to say) which are triggered individually when something happens within the Mailchimp list. For example if someone joins your list, it triggers a welcome message. This automation requires in some cases no code and can be done relatively easy. You can see more automation examples here (of course you can use their API for more cool stuff).
For password changes notifications, email verifications and such transactional emails you could use Mandrill, but as an add-on within Mailchimp which has a separate pricing, where you can start free for the first 2000 emails.
I believe the automation on Mailchimp + a good use of their API to make changes on the list, could easily be put to good use to your advantage (haven't tried this combination yet but will do in the future, let me know if you find out something).
To answer more directly your question, yes, you can achieve a certain degree of automation with the automation part of Mailchimp (which is relatively new), but for a more granular control you definitely could use Mandrill as an add-on within Mailchimp.
Techically, you could create single person campaigns via the Mailchimp API.
But, Mailchimp has developed it's own anti-spam AI (Omnivore) that kicks in every time the campaign is ready to be sent, which analyzes the campaign and list data.
Since I had Omnivore block some of my campaigns for trivial reasons, I think it would be a matter of time before it finds a pattern in your workaround.
Related
I am a bit confused with Mailchimp and Mandrill, what I need to do seems to need both, let me explain:
A social network needs to send at 1am everyday a notification email to their users that have not logged in during the last 24 hours. Emails have to be personalised.
On the top of that, there are different campaigns for different list of users.
My first thought is to use the mandrill API, but I need to be able to see who unsubscribe from what campaign (a user might want to unsubscribe to one campaign but stay subscribed on another one). I cannot seem to find something that fits the bill with Mandrill... Subaccount? Tags?
Thanks!
I'm not 100% sure this will answer the question, but let me try:
Mandrill actually belongs to MailChimp, and was created for interfacing with it. You can use the "mandrill-api" gem - https://mandrillapp.com/api/docs/ - to interface with many of the Mandrill and MailChimp features to do the things you wanted.
A lot of times if you are attempting to do so, and run into errors such as "XXXX not found", you have to send it FROM MailChimp TO Mandrill. For instance, when you create a template in MailChimp, click the dropdown menu next to the template, and click "Send to Mandrill". You should be good from there.
Other than that, I wish you luck. While the mandrill-api gem can do everything, it has absolutely abysmal documentation. There are multiple third-party gems that provide similar functions (mandrill-rails is a popular one) that you might have better luck with, but I have not used them myself.
Notifications = Mandrill = 1:1 emails
Campaigns = MailChimp = 1:many emails
Typically, notifications are 1:1 emails - your system sends a single user an email as a result of some trigger within the system. The trigger might match multiple users at the same time, but emails are sent to them each individually - probably via a loop in your code. Mandrill supports templates to personalise these emails if required.
Campaigns are sent to mailing list members in bulk, where the same (personalised) email is sent to multiple users at the same time. This is either triggered by hand (you manually create and send a campaign) or is based on a scheduled trigger (eg autoresponders or scheduled campaign mailing).
Notifications are generally system-related emails and while you do have the technical ability to let users unsubscribe from them in Mandrill, typically I would consider that a configuration option you'd give them in their personal control panel on your site.
Campaigns are something you MUST allow users to unsubscribe from to comply with anti-spam laws, so will contain unsubscribe links in the footer of every email.
I have a database as part of my web app that stores user emails, age, gender, etc. Is there a way, through the API to send a bulk email to a lsit of users? Previously I've used their API to create new entries from my database in MailChimp's system, and then we'd segment our users through MailChimp's web application. The issue is that sending your data to MailChimp has so many issues. For example, to store a user's age in MailChimp, you have to create an individual "group title" for each age when done thru the API. You can't just specify that the field "age" is a number and then add whatever you like. Also, each user selects a city when they sign up through us, and if we add another city to our selection list, you have to manually add it on MailChimp, otherwise you get an error.
So the simplest solution would be if we could do the segmenting on our side and send an email through the API, unless there is another, easy way to do this. I know that Amazon SES let's you email through an API, but I want other features of MailChimp, such as sent email history, analytics and providing and easy unsubscribe feature for users - Amazon SES doesn't do any of that.
Is there an answer to my conundrum?
Have you checked out Mandrill? It's a newer service from MailChimp that works like SES, but has those incredible MailChimp marketing sensibilities you know and love (open/click tracking, email audit log, plus lots of new stuff.)
It won't connect directly to your data in MailChimp (yet), but it sounds like you've got all the relevant data in your own DB already and can do the segmentation and content generation yourself.
Bonus: you'll also get a discount if you're already a paying MailChimp customer.
With regards an OMS, what is the best method to send a confirmation email? The 2 options I have so far are;
A script on the order page sends an email once the record is written to the database.
A scheduled task on the server, send the email, polling the database every-so-often to find new entries.
Which method do systems currently use?
For e-commerce websites, it might be better to think about the best user experience.
Given that, you would want to send the email as soon as the order is received so the user knows that they have purchased the item. The sooner it gets into their inbox, the sooner they will be happy that they have made their purchase.
I agree with Digbyswift that sending the confirmation email once the record is written to the database is the least scalable. But I would argue that if your system has gotten to the point that you are taking so many orders that your system cannot keep up, you have a wonderful problem on your hands that you now probably have resources to handle.
At PostageApp, we handle the emails of a few e-commerce websites, so perhaps you would benefit from an arrangement with an email service provider to off-load this task so that all of your resources can be spent on keeping your site up and your databases running.
Here are some great alternatives if PostageApp is not your style:
Sendgrid
Postmark
Mailjet
This is a question of scalability. Sending a confirmation email once the record is written to the database is the least scalable. The more orders that are taken , the more emails are sent potentially tying up resources.
A scheduled task is certainly better as emails can be queued up and can be sent in a separate process.
A further option which you could consider is using neither and delegating the responsibility of sending emails to a 3rd party dedicated emailing service, i.e. via an API. This is much better since your hosting does not have to consider the load and you can utilise any reporting offered by the 3rd party. Plus many services offer a free quota up to a certain threshold. This will allow you OMS and business to scale appropriately.
If you apply a message based architecture; you could just publish an order created message and have any number of subscribers respond to that event. You could create a listener that sends the email in house (bespoke option) or another listener that called the API of a 3rd party emailer to send the email on your behalf (as per #Digbyswift)
What I've always liked about this approach is
You can have any number of listeners live at any one time.
You can create a new listener and change how you send the email without needing to change/redeploy the OMS application itself.
You can take the listener(s) off line and stop / delay the sending of the email without losing any notifications or affecting the OMS itself.
if I wanted to create an "email list" along the lines of google groups (and eventually integrate with a web site), what services should I look into? I haven't really dealt with email before so I'm not 100% sure how it all works. I do know I need to be careful about being blacklisted, etc. Do I use something like sendgrid/mailman? I imagine all emails go to my server when a user hits "reply all" and on my end I push that email as though it came from the user but really it came from my "mail" server? It seems a user doesn't need to "reply all" to send to the list and there is no quick way to reply to just one user (which is a good thing for this app).
So the way I imagine this working:
1) I use something like sendgrid to "listen" for emails coming to list#mywebsite.com
2) When emails come (i.e from userx) I do some filtering for spam, etc and then push them all out to "all users/subscribers"
3) All users get something that is "from user x" (but it's really from my server, on google groups it says "via googlegroups") and the "reply to" is list#mywebsite.com
I imagine this is how it all works but I'm not 100% sure this is correct or if sendgrid will allow me to do this (and if it will cost too much).
Thanks
It really depends on what your needs and skills are. For simple mailing lists there is some very established software such as ListServ or MajorDomo
If you're not running a Unix variant, or you're not confident setting up this kind of software they might not be suitable though.
You can use SendGrid to handle your incoming email, but you will have to re-assemble the message before sending it out since it will be posted to your incoming parse URL in a, well, parsed way. The good news is that SendGrid can handle the spam check for you.
SendGrid currently doesn't charge for inbound parsing, but of course that may change. So as far as your cost goes, you would only use credits for the mail you send. Keep in mind that SendGrid only provides the Parse API to silver ($80/mo) customers or customers on the free (200 emails/day) plan, but there are plans to add a lower tier package that also has access to all APIs.
You can also use SendGrid to handle unsubscribes, but if you are using another solution for list management that's probably superfluous.
Googling for "mailing list hosting" brings up a wealth of sites, some of them free at least under some conditions. Many of them will use something like Mailman / Majordomo / Listserv; certainly you can run Mailman or Majordomo on your own server if you like, as well, so your question doesn't really make sense from that point of view. Yahoo Groups / Google Groups can also happily host a list for you. Do you need the list to be visible to subscribers only? Google Groups and Yahoo Groups will host private lists, too.
A mailing list basically works like Bcc: mail. You send to the mailing list's submission address; it then replaces some of the headers (often the Sender: and perhaps Reply-To:) and then redistributes the message to all the subscribers. Behind the scenes, it might rewrite some headers to make sure bounce messages come back to the list software for further handling (for example, to automatically unsubscribe addresses which consistently return a bounce), and often, it distributes the message with some delay in order not to saturate the outgoing bandwidth and/or choke a receiving server; though some parts of this are also handled by the regular mail transport agent (MTA -- Postfix or Sendmail or what have you).
You might look at ezmlm
EZmlm-idx is a nice mailing list add-on to Qmail. When we install Qmailadmin later on, you'll see that EZmlm-idx integrates seamlessly into Qmailadmin to provide a very user friendly mailing list management interface. As an added bonus, Vpopmail (which we will install as well) will let you control what users can and cannot use mailing lists!
Quoted from qmailrocks
You do not need to worry about sendgrid. Just get a cheap vps,configure DNS and, install MTA(postfix,qmail,sendmail) imap(courier,dovecot), a modern listserve, and let it do it's magic! On the lists where I am subscribed , I have the option to reply to a post, or the whole group.
Can someone help me understand what SendGrid actually adds to an application architecture? Is it's role really as limited as being an alternative delivery engine (SMTP) and post-send analytics? I was hoping that it would do more for transactional email, but everything that I see/read indicates that this is the limit.
My primary use case is for transactional email (new registrations, contact requests, etc.). I'd really like to hear how others have deployed SendGrid within the context of their own web applications. Your experiences may help me better understand how I can best deploy it within my own.
Thanks.
I implemented SendGrid at my last job, and shortly after left that job to go work at SendGrid. At the time, I simply set it up as an SMTP relay, and it took less than 5 minutes.
Scott's answer nailed it, though. We do a lot more than transactional messaging though. We have a newsletter product that you can plug into. A common use case is when a user registers on your site, you send them a transactional Email and fire off an API call to us to add them to one or more mailing lists based on their opt-in preferences. Then, whenever you want to send an Email to your users, you send us a single message via API with the name of the list, and we take care of delivering it on your behalf. We also help with unsubscribes -- eg. if a user unsubscribes from any message, we can use that event to trigger a call back to your site so you can handle anything on your end as well like un-selecting an opt-in checkbox the next time they view their user profile. I know several small businesses run by friends who do this exactly, including my last job who set this up after I left that company.
Another common setup is having one IP address for your transactional Email, and another IP for newsletters. This way if users flag a newsletter as spam (because they're too lazy to click an unsubscribe link, for example), it won't hurt the reputation of the transactional Emails getting through.
Don't hesitate to contact us with questions. We love to help!
If your primary use case is for transactional email, then SendGrid is the right solution for you. It is essentially a drop in replacement for your SMTP, but will scale way better than you could building something yourself from the ground up. It takes time to setup your own SMTP and time to make sure it's not falling over and sending out emails that never get to their destination.
All SendGrid does is email, so all the heavy lifting and boilerplate tedious setup is done for you. You mention transactional email, that is SendGrid's sweet spot. They make sure email gets where it's supposed to go. The big bonus is they give you a lot of tracking goodies along with making sure your email gets where it's supposed to go. There are a number of large companies that said the 15 minutes they spent switching to SendGrid upped their delivery rates substantially.
Unless you love running an SMTP server, instead of building your own product, I'd highly recommend offloading delivery to someone else.