-- You're doing analytics wrong -- AMA w/ CEO of Metabase

@vamsi_peri I'd say the most important target to hit if you're looking for a large, growing open source project is to grow the core set of people who are using you in production (ideally happily). Walking that backwards, you'd also want to keep track of the number of installations, and the rough number of people trying you out (from the number of downloads or docker hub pulls). Github exposes some of these metrics, Dockerhub another set, and you'll probably want to host releases on your own servers so you get accurate counts there as well.

If you're an application, then some kind of (opt-in) FE client tracking is also ideal so you get a sense of what in the world people are doing inside the application.

@ramiro__nd The most straight forward thing is that since NLP is basically a solved problem, we'd lean heavily on natural language for querying (note: we're doing this now with our "Metabot").

Bigger picture, I'd have build at least an "preview" paid version of Metabase much earlier and validated it. Making a successful open source project is hard, making a commerical software company is hard, doing both is significantly more annoying. I think understanding how you'll commercialize (read: testing out approaches and validating them) is something you really need to have sorted out really early in the process. We got lucky in that a couple of our early big bets there ended up working, but those could have easily not worked out.

@catt_marroll This question is a really common one, and was the bane of our existence early on.

Metabase goes on top of a database and lets you run queries, make charts, dashboards, set up alerts, etc on the data inside the database. Plausible (and Google Analytics, Mixpanel, etc) are a combination of a front-end library to instrument your application, storage and much simpler querying tools to do what is called "event" or "usage" analytics. Think of it as a fairly specialized use case, while with Metabase you can slice and dice any data you have lying around.

@hervelabas Today, the extremely sloppy intern in the analytics department whose work needs to be triple checked.

In a few foundational model generations, I think it should end up replacing human analysts in the "I have a question" -> "here's the answer" loop, and probably in the "this thing is confusing, can you dig into what's happening?" problem as well.

@maxzhengx Fundamentally, I think we're a lazier option than all the alternatives. If you do a bit of front-loaded work on sorting out what the customer facing schema should look like, you can get something in front of your customer in a week or two. Most people agonize over pixels and completely ignore the shape of their data, and we think (and nudge you in the product) to do the inverse.

@_roman How often the thing that determines whether a given customer manages to ship, how long it takes them to ship, and then whether their customers use the in-app reporting hinges on the data schema and whether the average user of the application understand what they're looking at. Too often analysts or data engineers design schemas for other data practitioners, and don't really understand the frame of mind of a normal user of their application.

@aojedal Database (or data warehouse) load isn't a magical thing we're going to solve in Metabase itself. At some point, you need to figure out what data sets to expose, what specific forms of questions you expect your users to ask, the indexing patterns of the row level per-customer data controls, etc.

At very low scale, having customers hit the application database probably makes sense. But at any realistic customer volume, you really should provision a separate database dedicated strictly to serving customer-facing analytics. Caching will help you for a bit, but it's a long term dead-end.

We strongly suggest treating in-app analytics as a customer facing feature. For customer facing features, performance is really important, and you should optimize the DB schema to support that. This almost certainly means moving away from your main application database and creating custom tables that map more closely to how your customers think about the objects in your application.

@steveb Fundamentally, you're giving away software that will cost you a lot to build in exchange for increased exposure, third parties that will be invested in your project and help (code or otherwise), and an increased amount of trust.

It's a difficult equation to balance, and historically most people came up negative.

For us, being Open Source has given us a lot in terms of credibility, talented engineers excited to work on the project and breadth of exposure. One thing that's made it all work is that there was a somewhat clear vision on what we were going to sell from early on. I do think you have to either be fully committed to being OSS or not at all. I haven't seen a lot of people who've waffled between the two (especially in the early years) succeed. There are a lot of pivotal early decisions you should be making very differently if you're Open vs Closed source (eg, with regards to user feature requests, support, etc)

@vamsi_peri I mentioned in another comment that the jump from "I'll just add this one chart" to realizing you need to hand generic queries is the biggest jump in complexity.

The two other main difficult things are getting the schema you present to end users right and making the whole experience performant enough that it's not a punishment to your users.

@isha_nasir The biggest headache is that typically after putting in a single chart or two, you start getting requests from your customers about what data they need. It's extremely common for these requests to be extremely different, and all "urgent". At some point, you need to accept that you need to build a generic querying interface and this tends to be a really big jump in complexity and headaches.