Just the other day I looked at a team member and said, "You know what would be great? A Mixpanel API so I can just pull out the data I need on a regular basis and put in on a dashboard so we are always looking at the same metrics"
I don't really get it. Disclosure that I work at Looker which is an analytics company, though not really in the same space as Mixpanel. But I'm just confused about this latest trend of "you can get your data out!" from analytics providers that excel at one type of analysis (as Mixpanel does with funnels).
In my mind, the whole value of these providers is that they make that one kind of analysis really easy and pretty. But if you feel like you're outgrowing that and want to slice your data in new ways, I don't think you'd choose Mixpanel for their data capture alone, right? So is it just that the cost of Mixpanel is sunk and so might as well get the data they're already recording out?
(Disclaimer: I work for Treasure Data. That said, there's also an open source way to do this with Embulk + many common SQL databases. See https://github.com/embulk)
> For instance, a multi-step funnel, segmented on a couple of columns, would extend to several screenfuls of complex SQL, which is cumbersome to write and difficult to reason about.
The only thing I loathe about SQL is its lack of re-usability. It is hard to write reusable parts and pass them around in functions. Need ten filters which you may / may not use? Write ten queries!
Thankfully, the problem is solved by ORMs ( SQLAlchemy, in my case ). Certainly, in many cases, the mental mapping of map, filter and reduce makes more sense but in the most, I have been more comfortable with using a powerful ORM layer and SQL.
Views and WITH statements help out quite a bit for this, though it does depend on the database. In general, basic views are well-supported across all RDBMS. If your database supports it, Materialized Views are amazing for the caching of certain complex queries and reusability, and that's something SQLAlchemy can't do by itself.
Totally agree and the "write-only" nature of SQL is something that makes me crazy. Sounds like you're more of a dev. I'm an analyst, but same problem. For any analytic SQL I wrote more than a couple weeks ago, I end up throwing it out and starting from scratch because it's so hard to understand anything I wrote.
ORMs were a huge step forward for devs, but there wasn't really anything similar for analysts. Looker (where I now work after three years as a customer) is, in many ways, the equivalent of an ORM for analytics.
// it's great feature but i'm not sure that javascript is the right language. just because sql is not the best way to run analytic queries such as funnel and retention, it doesn't mean that we need a replacement. you basically expect all data analysts to learn javascript instead of sql.
[+] [-] halayli|10 years ago|reply
[+] [-] rco8786|10 years ago|reply
[+] [-] ranman|10 years ago|reply
[+] [-] dudifordMann|10 years ago|reply
https://confluence.atlassian.com/jira/advanced-searching-179...
[+] [-] jtmarmon|10 years ago|reply
[+] [-] pj_mukh|10 years ago|reply
BAM.
[+] [-] dwmintz|10 years ago|reply
In my mind, the whole value of these providers is that they make that one kind of analysis really easy and pretty. But if you feel like you're outgrowing that and want to slice your data in new ways, I don't think you'd choose Mixpanel for their data capture alone, right? So is it just that the cost of Mixpanel is sunk and so might as well get the data they're already recording out?
[+] [-] ktamura|10 years ago|reply
(Disclaimer: I work for Treasure Data. That said, there's also an open source way to do this with Embulk + many common SQL databases. See https://github.com/embulk)
[+] [-] ffumarola|10 years ago|reply
e.g.
https://amplitude.com/sql-queries
https://segment.com/redshift
etc
[+] [-] rch|10 years ago|reply
https://mixpanel.com/docs/api-documentation/data-export-api
[+] [-] shubhamjain|10 years ago|reply
The only thing I loathe about SQL is its lack of re-usability. It is hard to write reusable parts and pass them around in functions. Need ten filters which you may / may not use? Write ten queries!
Thankfully, the problem is solved by ORMs ( SQLAlchemy, in my case ). Certainly, in many cases, the mental mapping of map, filter and reduce makes more sense but in the most, I have been more comfortable with using a powerful ORM layer and SQL.
[+] [-] batbomb|10 years ago|reply
[+] [-] dwmintz|10 years ago|reply
ORMs were a huge step forward for devs, but there wasn't really anything similar for analysts. Looker (where I now work after three years as a customer) is, in many ways, the equivalent of an ORM for analytics.
[+] [-] cheez|10 years ago|reply
[+] [-] buremba|10 years ago|reply
while(true) {
// it's great feature but i'm not sure that javascript is the right language. just because sql is not the best way to run analytic queries such as funnel and retention, it doesn't mean that we need a replacement. you basically expect all data analysts to learn javascript instead of sql.
}
}
[+] [-] developit|10 years ago|reply
[+] [-] tdumitrescu|10 years ago|reply