This is probably a good time to ask about how people handle transactional email generally.
I had a play with Mailgun a while back (and others, Mailgun felt nicest to me) but there was a feature that seemed to be missing from them all.
How do you handle rules between outgoing emails?
For example, say there's an email that gets sent out on a user action, but you only want to send it out once a day. It feels to me like I should be able to set rules within Mailgun to say, only send out this email every x minutes, or, don't allow it to go out if another type of email has gone out before etc.
Is there a way of dealing with that? At the moment we have to put all those rules into our app, and it seems like something the app shouldn't have to deal with.
This strikes me as somewhat of an edge case - to add a full rules engine for what is essentially a very app-specific set of behaviours.
One main reason the application is the best place to manage these rules is that it's rarely just the email content that dictates the engagement pipeline. Whether a user has interacted with a component, or logged in, etc, are all app-side variables which may affect whether or not you wish to send a given email.
That said, one method some of our customers use at PostageApp to simplify some of the logic is to pass a UID to the API based on the unique parameter sets - e.g. recipient + template + hour - and rely on the engine to discard the duplicate API calls.
Agreed. This kind of domain logic doesn't really belong in a generalized mail API. It should be easy enough to build in to your app by recording the last email date/time
I think in the basic example I gave, that's fine, but it quickly becomes unwieldy.
Take for example the A/B testing of pricing. I'd like to offer some customers an infinite free trial while others only get a month free after which time they have to upgrade. The email flow for each of these types of customers would be quite different over the first couple of months. Different actions would trigger different emails at different times. That logic is not really something you want deep in your app (as I say, that's more marketing logic than app logic).
Looking through the other links provided in the sibling posts I'm starting to think the right way of doing this is using an event tracking system (Mixpanel type idea, but maybe storing that information internally). Then you have a rules engine outside of the app to send out the emails. It then becomes trivial to segment as in my a/b testing example, or to not send out more than one of a certain type of email a day etc.
Thanks for all the thoughts on it though - it's helped to push me in the right direction.
IronWorker (our product from Iron.io) has scheduling capabilities and can be combined easily with SendGrid/Mailgun to provide any type of rules engine.
In it's most simple form, you can use it like cron in the cloud.
I had a play with Mailgun a while back (and others, Mailgun felt nicest to me) but there was a feature that seemed to be missing from them all.
How do you handle rules between outgoing emails?
For example, say there's an email that gets sent out on a user action, but you only want to send it out once a day. It feels to me like I should be able to set rules within Mailgun to say, only send out this email every x minutes, or, don't allow it to go out if another type of email has gone out before etc.
Is there a way of dealing with that? At the moment we have to put all those rules into our app, and it seems like something the app shouldn't have to deal with.