
Show HN: we open sourced our Django drip email app - bryanh
https://github.com/zapier/django-drip
======
bryanh
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/>

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

~~~
sudonim
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>

~~~
WadeF
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...](https://zapier.com/blog/2012/10/14/when-you-should-build-not-buy/)

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.

~~~
twakefield
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...](http://documentation.mailgun.net/user_manual.html#events-webhooks) [2]
<http://documentation.mailgun.net/api-campaigns.html>

~~~
WadeF
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.

------
patio11
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.

------
WadeF
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.

~~~
bryanh
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.

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

------
marcrosoft
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.

~~~
zalew
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...](https://groups.google.com/forum/#!topic/django-
developers/EI-ihJ4CLqw) 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...](https://github.com/freakboy3742/django/blob/t3011/docs/topics/auth.txt#L1761)
models.ForeignKey(settings.AUTH_USER_MODEL)), you will just have to make sure
you include the fields referenced by django-drip.

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

------
Jarshwah
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.

~~~
bryanh
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).

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

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

~~~
bryanh
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>

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

~~~
bryanh
Absolutely, you have full Django templating abilities.

------
bedspax
It would be cool if Drip support also custom Profiles

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

------
almost
Thanks guys, this looks great!

------
bussiere
Thanks a lot.

Bussiere

