Re:Mixpanel: Introducing JQL, a query language to analyze an...
by pj_mukh on Thursday April 14, 2016 @05:28PM
(#11500483)
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"
Re:Mixpanel: Introducing JQL, a query language to analyze an...
by dwmintz on Friday April 15, 2016 @12:54PM
(#11505785)
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?
Re:Mixpanel: Introducing JQL, a query language to analyze an...
by pj_mukh on Saturday April 16, 2016 @11:25AM
(#11510916)
It is simpler than that. I'm not slicing the data in different ways, I'm just centralizing what my whole team is looking at. We've spent too much time saying,
"Hey look at the retention numbers, its so high!",
"For when? I'm seeing it go low!"
You are what you measure, this had made it easy for us to centralize our data.
(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)
Re:Mixpanel: Introducing JQL, a query language to analyze an...
by shubhamjain on Thursday April 14, 2016 @03:20PM
(#11499583)
> 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.
Re:Mixpanel: Introducing JQL, a query language to analyze an...
by batbomb on Thursday April 14, 2016 @03:51PM
(#11499816)
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.
Re:Mixpanel: Introducing JQL, a query language to analyze an...
by dwmintz on Friday April 15, 2016 @12:51PM
(#11505745)
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.
Re:Mixpanel: Introducing JQL, a query language to analyze an...
by buremba on Thursday April 14, 2016 @04:55PM
(#11500273)
function main() {
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.
https://confluence.atlassian.com/jira/advanced-searching-179...
BAM.
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?
You are what you measure, this had made it easy for us to centralize our data.
(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)
e.g.
https://amplitude.com/sql-queries
https://segment.com/redshift
etc
https://mixpanel.com/docs/api-documentation/data-export-api
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.
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.
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.
}
}