Show HN: we open sourced our Django drip email app | Hacker News Reader

Show HN: we open sourced our Django drip email app

github.com

126 pointsbryanh33 comments

In the spirit of GetVero, Intercom.io and Mixpanel, here is our done-is-better-than-perfect take on drip campaigns. Definitely check out the docs [1] and the demo [2] for a better idea of what it does (and doesn't do).

My favorite feature is the ability to view "scheduled" emails. Hope the services out there add that feature!

[1] https://django-drip.readthedocs.org/en/latest/ [2] http://djangodrip.com/

Just wanted to add Customer.io, which is a similar service we have been evaluating. It'll be interesting comparing this with that.

I was just going to make a comment regarding Customer.io. We've been using them for a few months and are very pleased.

Thanks guys. Colin, co-founder of http://Customer.io here.

The build vs. buy decision for people is always an interesting one. Taking a quick look at the app, if you're using Django, it's for sure worth a try.

Some of the questions you may want to ask:

* How do you know if your emails are working?

* Which emails has randomuser@gmail.com received?

* How do you handle unsubscribes?

We take care of those as well as answering many other questions. And we're working full time on improving the product for you.

So, how much is an hour of your time worth? And how many hours will you spend building your answers to the questions above?

If you want to hack around with a system for fun or curiosity, do it. Otherwise, whether you use us or someone else, you're better off buying.

P.S. For pythonistas, an awesome customer built python bindings for us that I just pulled in: https://github.com/customerio/customerio-python

While I typically agree that buying is better than building this was one case where building still made the most sense for us. See the post below:

https://zapier.com/blog/2012/10/14/when-you-should-build-not...

Here's a portion of an email I wrote to another email company about why we built this:

I've run email for multiple companies now, and the biggest problem I've always faced is a disconnect between what data the third party holds vs. what data is in my internal database.

There's also a bit of an issue with us (Zapier) that a lot of things happen on when a user isn't on site so we have to use the API to constantly push data to the third party if we want it to work. This requires us to either 1) figure out what data we should be pushing or 2) push everything.

The first part is annoying because it's hard to predict what is needed and developers hate getting requests to add just one more piece of data to the email service.

The second part is not great because now we spend a bunch of resources sending everything and the third party can essentially replicate our database or we push so much data that it becomes cost prohibitive.

So we just built a simple logic builder around MailGun that handles sending email. It's not perfect (i.e. we don't have great analytics and all our emails go out at the same time ever day), but we can literally segment on anything. Every single table in our database. And for a service with use cases all over the place this saves me from sending stupid generic emails or from sending an email about sales to developers or an email about github to a marketer.

edit: my hope is still that a 3rd party service figures this out because I'd much rather pay someone for this than build it. But if building is the only way you get features you need, then build you must.

P.S. I think Bryan might have spent a weekend hacking on this. So not a ton of resources lost especially considering that you can't spend all your brain waves hacking on your core product or you'll go mad.

Again, we would like to reiterate: we would have loved to buy this. But Wade outlined the reasons we couldn't scratch our itch with products like yours (or your competitors).

Sorry it seems I came across as critical. I wasn't suggesting you guys should do anything differently. It was more to outline things to consider for others reading.

Out of curiosity, is the main thing for you Database level integration? Like what RJMetrics does with analytics?

No worries, we love the ideas around your product.

To be honest, its not even a direct need of "database level integration", that is just where it ends up. Going to the DB level removes the "crap, now we have to get all the data into X service..." every time we want to key off of some new metric. Backfilling data is doubly painful.

Most services just do an API or a JS include to do this, but those require special coding as well to replicate our data into services like yours. Its just annoying and is a negative experience when you want to start using your product more.

In my opinion, someone should build a more affordable Marketo that ties directly to your data source instead of replicating it. But I can understand the major hurdles in customer adoption at a lower price point (hey, gives us the db access and pay us $30/mo!).

This is really fantastic, great job. This is exactly the type of stuff we love seeing built and used with Mailgun.

Regarding analytics, we do provide detailed data either in push (webhooks [1]) or pull (campaigns api [2]). Did you just not have time to integrate that or is there something else that we could have offered to make it easer for you?

[1] http://documentation.mailgun.net/user_manual.html#events-web... [2] http://documentation.mailgun.net/api-campaigns.html

Just haven't had the time to build it yet. Part of why a 3rd party solution is preferred. But custom needs call for custom solutions.

Does customer.io also support drip campaigns based on event-data?

I've evaluated a number of solutions and started looking at build vs buy because we need to start a drip campaign after receiving e.g. a send_interview event and follow up with emails like 'Your interview '{{interview.title}}' is about to expire.'

From what I can tell nobody supports that yet...

Just wanted to say "Thanks". I'm building out a web application right now and this was on my feature list.

Seconded! This looks perfect.

Awesome, was literally talking to a Python-using startup in the UK about their options for doing this less than an hour ago. I'll tell them about it.

The key things I love about an Drip vs. commercial options is that since it's a django app it hooks right into our database and I can dynamically schedule an email based on anything.

This is incredibly powerful for segmenting emails.

The mechanism for doing this is a total hack on Django's ORM. We build a bigass list of all possible JOINs and concat them together:

    some_model__another__title
    some_model__another__date
    some_model__another__description

You select which fields and values to use, and then we can just dump them into a queysets' filter or exclude method using python's lovely kwarg expansion.

Thank you so much for releasing this. I can definitely see a use for it and will look into it in the near future.

How difficult would it be to tie this to an arbitrary user model.

I am thinking along the lines of using this on a rails app.

soon to be released Django 1.5 (currently in alpha 1) will have custom user models https://groups.google.com/forum/#!topic/django-developers/EI... I guess then you could just replicate your rails user model in django, of course if django-drip by will be upgraded to support those custom models (https://github.com/freakboy3742/django/blob/t3011/docs/topic... models.ForeignKey(settings.AUTH_USER_MODEL)), you will just have to make sure you include the fields referenced by django-drip.

Drip will definitely have support for Django 1.5's custom User models.

I wrote this a few months back: https://github.com/brennandunn/dripper

It depends on resque-scheduler, but let's you setup a drip campaign against an ActiveRecord model pretty easily.

This is great! Thanks for open sourcing it.

What do you use to track conversion? For example, % of emails opened, % of users who engaged in a certain action after going to the site from the email?

I love this mainly for the crafting of the query. It would probably be worth extracting that piece out into a separate application of its own, so other Admin models are able to build out filtering in a similar manner.

Totally agree, it is crazy useful! Also agree it would be nice if it could be based off of something besides User (Django's ContentType framework might be the right bet there).

This is so damn timely! Thank you so much, I will definitely be using this.

Bah, just built something to do this, though it's more event-driven (based on signups and orders and whatnot) so integrated in that.

We have an open issue to work off of signals [1]. What would definitely make it more event driven, but might make it a lot less efficient.

[1] https://github.com/zapier/django-drip/issues/1

I'm guessing I can put html into the fields, since you have the mustaches in?

Absolutely, you have full Django templating abilities.

It would be cool if Drip support also custom Profiles

It does, at least filtering and accessing them if they have a ForeignKey to User.

Thanks guys, this looks great!

Thanks a lot.

Bussiere

Reply on news.ycombinator.com