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.
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?
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!).
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.