7 ms·
Show HN: we open sourced our Django drip email app
- bryanh 14y agoIn 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/ https://django-drip.readthedocs.org/en/latest/ [2] http://djangodrip.com/ http://djangodrip.com/
- yesimahuman 14y agoJust wanted to add Customer.io, which is a similar service we have been evaluating. It'll be interesting comparing this with that.
- jmathai 14y agoI was just going to make a comment regarding Customer.io. We've been using them for a few months and are very pleased.
- sudonim 14y agoThanks guys. Colin, co-founder of http://Customer.io 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 https://github.com/customerio/customerio-python
- WadeF 14y agoWhile 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-buy/ 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.
- SoftwareMaven 14y agoJust wanted to say "Thanks". I'm building out a web application right now and this was on my feature list.
- eupharis 14y agoSeconded! This looks perfect.
- jtchang 14y agoThank you so much for releasing this. I can definitely see a use for it and will look into it in the near future.
- WadeF 14y agoThe 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 14y agoThe 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.
- yesimahuman 14y agoThis is so damn timely! Thank you so much, I will definitely be using this.
- marcrosoft 14y agoHow 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 14y agosoon to be released Django 1.5 (currently in alpha 1) will have custom user models https://groups.google.com/forum/#!topic/django-developers/EI-ihJ4CLqw 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/topics/auth.txt#L1761 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.
- bryanh 14y agoDrip will definitely have support for Django 1.5's custom User models.
- bdunn 14y agoI wrote this a few months back: https://github.com/brennandunn/dripper https://github.com/brennandunn/dripper It depends on resque-scheduler, but let's you setup a drip campaign against an ActiveRecord model pretty easily.
- cmer 14y agoThis 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?
- patio11 14y agoAwesome, 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.
- mrharrison 14y agoI'm guessing I can put html into the fields, since you have the mustaches in?
- bryanh 14y agoAbsolutely, you have full Django templating abilities.
- antihero 14y agoBah, just built something to do this, though it's more event-driven (based on signups and orders and whatnot) so integrated in that.
- bryanh 14y agoWe 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 https://github.com/zapier/django-drip/issues/1
- almost 14y agoThanks guys, this looks great!
- Jarshwah 14y agoI 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 14y agoTotally 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).
- bedspax 14y agoIt would be cool if Drip support also custom Profiles
- bryanh 14y agoIt does, at least filtering and accessing them if they have a ForeignKey to User.
- bussiere 14y agoThanks a lot. Bussiere