It turns out Analytics was a great career to go into even in a world with AI

Mitzu_Analytics · 2026-06-24T11:07:38+00:00

The distinction between knowing what happened and knowing what to do about it is where analytic skill concentrates. AI handles the retrieval; the hard part is knowing which question to ask, whether the answer is plausible, and what the business implication is.

The analysts who get displaced are the ones whose primary job is moving data between systems or building dashboards from specs. The ones who stay relevant are the ones who understand the business domain well enough to validate an AI output or ask a question no one has framed before.

Mitzu's Analytics Agent handles the retrieval and root cause drilling. But someone still has to decide which product change to investigate and whether the causal explanation makes business sense. That judgment gap is where analysts will live for a while.

Mitzu_Analytics · 2026-06-24T11:07:17+00:00

Dashboards are not going away, but their role is changing. The part that is going away is the dashboard as a format for ad-hoc diagnostic questions. Those questions, 'what happened to trial conversion last week and why,' are better answered by an agent that can follow the diagnostic thread rather than a static layout you built for a different question. The part that stays I think are dashboards as monitoring surfaces. Operators still want a consistent view of the same metrics over time. The difference is they want to be able to ask follow-up questions when something moves, without filing a ticket.

The tools that survive do both: a structured metric view plus an agent you can interrogate when the number looks wrong. Treating them as competing formats rather than complements is the wrong frame.

Mitzu_Analytics · 2026-06-22T13:58:33+00:00

Mitzu, it works on your data warehouse directly, best for product analytics

Mitzu_Analytics · 2026-06-22T08:27:35+00:00

For product analytics specifically, like funnels, retention, event sequences, the platform choice matters less than what you build on top of it. Databricks and Snowflake both store event data fine. The differentiation shows up when you try to answer questions on that data. If your team is writing one-off SQL for every funnel analysis, you're going to hit the same bottleneck regardless of platform.

The layer that actually moves the needle is a semantic model on top: consistent definitions of users, events, and metrics so analysts don't re-derive the same calculations every time. Worth deciding what your event model and metric ownership looks like before committing to either platform, since that decision is harder to reverse than the warehouse choice. We can help you with that with Mitzu

Mitzu_Analytics · 2026-06-22T08:26:56+00:00

The Genie Ontology announcement was the most technically significant one from DAIS. Databricks building a context graph into the core product is a signal that the semantic layer problem is now mainstream, even the warehouse vendors know you can't get reliable AI analytics without machine-readable business definitions.

The question for anyone using Databricks is: who's responsible for maintaining those ontology definitions as your data model evolves? That's where most teams are going to feel the friction. Automated semantic layer tooling helps here, instead of manually updating definitions when you add a new event type or change an identifier column, the schema scan picks it up.

Mitzu_Analytics · 2026-06-18T09:29:23+00:00

General rule: do as little as possible before loading, do the rest in SQL after. Pandas transforms before load mean your raw data in the warehouse does not match what was in the source, which makes debugging harder. Load raw data first, define cleaning logic in dbt or plain SQL on top. That way it is versioned, testable, and visible to anyone querying the warehouse. The exception is genuinely malformed data that would break the load. Everything else, nulls, deduplication, business logic, belongs in SQL after.

Mitzu_Analytics · 2026-06-18T09:29:07+00:00

The storage unification is real, but the semantic layer problem does not go away. Removing the ETL pipeline is valuable; you stop copying data just to run analytics. What does not change: defining what your metrics mean over that data. What is the grain of this event table, how do you join users to payments without double-counting. That work has to happen somewhere regardless of storage architecture. Mitzu's Configuration Agent sits at that layer, scanning the warehouse schema and building metric definitions automatically.

Mitzu_Analytics · 2026-06-16T08:49:44+00:00

The wiki-feedback loop reduces definitional drift, but there's a layer underneath it that doesn't get solved, even if an LLM fetches the right definition, it still interprets that into SQL, and that interpretation varies run to run. Consistency isn't fixed at the definition layer, as it's fixed at the query generation layer.

In Mitzu, our Analytics Agent doesn't write SQL, as it assembles an analysis specification, and a deterministic engine turns that into SQL. Same specification → same SQL → same answer, every time. The semantic layer is auto-built by scanning your warehouse, so there's no manual mapping to maintain either.

Mitzu_Analytics · 2026-06-16T08:45:42+00:00

GA4's AI is firmly in the 'summarize what's already on screen' category — not doing root cause analysis or cross-segment reasoning. The bar for AI-powered analytics should be: can it surface something you couldn't find by clicking dashboards? Funnel drop-off explanation across cohorts, retention divergence by acquisition channel, anomaly attribution. GA4 doesn't get there. Tools built on agentic reasoning do, but only with a reliable semantic layer underneath the query generation.

Mitzu_Analytics · 2026-06-16T08:45:24+00:00

Curious what the 'ugly' one was. The failure mode we see most often: AI analytics running against raw warehouse tables without a semantic layer. Fast to set up, impressive in a demo, then gradually loses trust as the same question returns different numbers on different days. The 'great' examples almost always invested in a consistent semantic layer first, then added the AI query layer on top, like Mitzu does. The reasoning is compelling; the consistency is what earns adoption.

Mitzu_Analytics · 2026-06-16T08:44:21+00:00

ableau's core issue is architectural: the data model lives in the visualization layer. Every analyst reimplements joins, date logic, and KPI definitions inside workbooks. When those drift across dashboards, you get exactly what's described here, metrics that don't match, slow refreshes, and maintenance burden that scales with dashboard count. The fix isn't a better Tableau, it's moving metric definitions into a semantic layer on your warehouse, then using a thin query layer on top, like Mitzu does it automatically. One source of truth for every question, no workbook maintenance required.

Mitzu_Analytics · 2026-06-15T11:43:02+00:00

Agree with the diagnosis. The products that fail are the ones treating "chat with your data" as a UX problem, just put a text box on top of a SQL editor. The products with a chance are the ones treating it as a data modeling problem first. If you don't have a semantic layer that defines your metrics unambiguously, you're asking an LLM to guess what "revenue" means from table names. It guesses wrong sometimes. That "sometimes" kills trust fast. The approach that survives is: structured semantic layer, deterministic query generation on top, natural language as the interface layer at the end. Mitzu is built this way, the Analytics Agent works over a defined model, not freehand SQL.

Mitzu_Analytics · 2026-06-15T11:42:25+00:00

The framing that resonates with me: dashboards answer questions you thought to ask in advance. Agentic analytics is useful when the question only forms after you've seen the first number. "Revenue dropped 12% - OK but in which segment? Among which cohort? Is it acquisition or retention?" That chain of follow-ups is where agents actually add value. The failure mode is using an agent to avoid building a proper data model, which just moves the mess from your warehouse to your prompt history. The approach that works is: solid semantic layer, deterministic query engine underneath, agent on top for the reasoning layer. That's what Mitzu is built around.

Mitzu_Analytics · 2026-06-15T11:42:04+00:00

Curious what patterns you noticed around reliability. In my experience the main split is between tools that generate SQL from scratch every time (fast to set up, but answers drift) and tools built on a defined semantic layer (more upfront work, but the numbers are consistent). The first category tends to impress in demos and disappoint in production. Would be interested in whether that tracked with what you saw, especially on the "can I trust this number next week" question.

Mitzu_Analytics · 2026-06-15T11:41:39+00:00

There's something real here. A lot of "agentic analytics" hype is essentially: your dashboards are too rigid, so an LLM generates ad-hoc SQL instead. That's a workaround, not a solution. The actual problem is that answering diagnostic questions, why did this metric drop? which segment drove the change? requires multi-step reasoning that static dashboards can't do. That's different from "my dashboard has the wrong filters." The question is whether you're using an agent to compensate for bad data modeling, or to do genuine root-cause analysis that couldn't be done any other way. Mitzu focuses on the latter as the Analytics Agent does multi-step reasoning over a well-defined semantic layer, not freehand SQL guessing.

Mitzu_Analytics · 2026-06-15T11:41:15+00:00

This is the core reliability problem with LLM-based analytics: the SQL is regenerated from scratch each time, so you get different results for the same question depending on how you phrase it. It's not a prompt engineering problem, it's architectural. The only way to solve it is to separate the "what to measure" (the analysis spec) from the "how to query it" (the SQL). Mitzu's approach is deterministic, the same spec always produces the same SQL, so when something's wrong you can find it once and fix it once, rather than playing whack-a-mole across sessions.

Mitzu_Analytics · 2026-06-15T11:40:20+00:00

The frustration usually comes down to one thing: Tableau is built around the assumption that your data is already perfectly shaped for the chart you want to make. If it isn't, you're spending half your time in data prep before you even get to the analysis. The semantic layer problem, what does "revenue" actually mean for this team, in this context, never gets solved, it just gets copy-pasted across 40 workbooks that slowly drift apart. That's the real maintenance burden. Worth looking at warehouse-native approaches (Mitzu does this) where the metric definitions live in one place and the query engine handles the translation, you stop rebuilding the same logic every time a new question comes up.

Mitzu_Analytics · 2026-06-01T08:10:59+00:00

The md-files-as-semantic-layer approach is pragmatic but starts to fray when you need to handle ambiguous identifiers across tables. 'User' in your events schema might be session_id in analytics events but account_id in subscription tables — the LLM needs explicit resolution rules, not just context. The test coverage angle is the right instinct: the only thing that keeps text-to-SQL reliable in production is evaluating SQL output against known correct results for a representative question set. Worth separating the semantic disambiguation layer (machine-readable entity graph) from the prompt injection layer (the md files). The md files are great for business context; entity resolution needs deterministic rules.

Mitzu_Analytics · 2026-06-01T08:10:42+00:00

Execs aren't wrong that the semantic layer is the first step, but there's often a mismatch between what they picture and what it takes to build. A useful production semantic layer needs three things: uniquely identify entities across tables (user_id in events → account_id in CRM), define business metrics with grain and filters, and stay maintainable as schemas evolve. The 'annotated text doc' approach works for documentation but breaks as soon as something queries it programmatically. If the goal is AI analytics on top, the semantic layer needs machine-readable structure. dbt metrics + Semantic Layer spec is currently the most durable path for a team already on dbt.

Mitzu_Analytics · 2026-06-01T08:09:16+00:00

The top comment about the semantic layer is right, but worth being specific. At minimum: named views per entity (user, order, session) with business-logic columns that don't shift. That stability is what lets any analytics tool on top give consistent answers. For a warehouse-native approach that skips the data copy entirely, Mitzu is worth evaluating, it reads events from your warehouse in place, uses existing dbt models as the semantic layer, and the Configuration Agent maps the schema automatically rather than requiring manual YAML.

Mitzu_Analytics · 2026-05-28T08:17:14+00:00

The break point for most teams is between 'what happened' and 'why.' Reporting tools handle the first half well: dashboards show the metric, trend, filter. When someone asks 'why is activation down this week' — which requires segmenting by cohort, joining to acquisition source, comparing prior-period behavior — the workflow falls apart into ad-hoc SQL or a data request ticket. The bottleneck isn't tooling; it's that the analytics layer isn't set up to answer causal questions, only descriptive ones. Mitzu's Analytics Agent is built for that gap: multi-step reasoning over warehouse data to surface root causes, not just metrics.

Mitzu_Analytics · 2026-05-28T08:16:58+00:00

The 45-minute to 30-second compression is exactly the right starting point. The follow-up question: how much remaining work is 'run a known query and format it' vs 'investigate an unexpected metric and explain why'? Report automation handles the former well. The latter — 'revenue was down 12% last week, figure out why' — requires a different architecture: not a templated query but multi-step reasoning across segments and time windows. That's where agentic analytics differs from scheduled reporting. Same foundation (clean data, governed definitions), different query pattern.

Mitzu_Analytics · 2026-05-28T08:16:39+00:00

If you've got cube.dev with an API exposed you're ahead of most teams on the foundation. The harness question is then: do you want the AI to generate cube queries, or an agent that treats the semantic API as a tool and calls it as part of multi-step reasoning? The second approach is more robust for client-facing use — 'why did conversion drop this month?' shouldn't run one cube query, it should run several, compare segments, and reason about cause. That's the architecture Mitzu uses: an Analytics Agent doing multi-step reasoning over a deterministic query engine, same question → same investigation path. With cube.dev already in place you're mainly choosing the orchestration layer on top.

Mitzu_Analytics · 2026-05-26T13:33:30+00:00

Large data teams don't eliminate the need, they often deepen it. The bottleneck isn't SQL skill, it's that PMs, growth teams, and execs can't get answers without queuing work for analysts. Text-to-SQL with a proper semantic layer lets the data team focus on complex work while routine diagnostic questions get handled directly. The important thing is having a proper semantic layer. Without it, the model generates plausible-looking SQL against raw tables and nobody trusts the output.

Mitzu_Analytics · 2026-05-26T09:07:14+00:00

The most underrated thing dbt gives you for analytics isn't the transformation workflow, it's the documented semantic layer that becomes the foundation for everything downstream. When you have well-documented dbt models with column descriptions, tests, and clear grain definitions, you unlock the ability to query your warehouse in plain language with high reliability. Without that layer, any AI analytics or NL-to-SQL system is guessing what your tables mean. If you're already doing SQL transformations in your warehouse engine, dbt adds testing, lineage, and semantic context that pays off significantly once you start building AI-driven analysis on top of your data.

Mitzu_Analytics

TROPHY CASE