Steep vs Mitzu: Governed Metrics and AI Analytics on Your Warehouse, Compared

Use this comparison if you are choosing a governed-metrics platform with an AI agent for your warehouse: how Steep and Mitzu define metrics, build KPI reports and answer questions, and what Mitzu adds on the same definitions.

Steep and Mitzu both replace dashboard sprawl with governed metrics on the warehouse and an LLM agent that answers from them. For KPI reporting and self-service, they compete for the same job. They differ in three places: how metric definitions are created and maintained, who writes the SQL behind an answer, and what else runs on the same definitions. Steep publishes a metrics catalog built on dbt, Cube or its own semantic layer, with reports and Steep AI on top. Mitzu uses one set of definitions, governed by the data team, for KPI dashboards, product analytics (funnels, retention, journeys) and experiment analysis, and its agent hands the SQL to a deterministic engine. The rest of this post compares the two and says when each fits.

What is Steep?

Steep positions itself as "AI analytics for faster insights and zero chaos", a modern alternative to traditional dashboard-based BI. The product's core idea is that organizations should ship a governed metrics catalog, not a sprawl of duplicate dashboards. Three pillars: built on metrics, powered by AI, designed for engagement. Customers cited on the homepage include Framer, Voi, Juni, Bounce and Philadelphia Inquirer.

The semantic layer is the foundation. Teams either define metrics in dbt MetricFlow via dbt Cloud, or in Cube, and Steep publishes them to end users. Metrics, dimensions and entities are modeled once and reused across reports and the AI agent. Steep also has its own semantic layer, where metrics can be defined in code or managed in the app, for teams that don't want to maintain MetricFlow or Cube directly.

Steep AI is the agent surface. The product blog describes it as helping teams "move from question to answer faster while staying grounded in the semantic model defined by your data team." The agent can "connect metrics and dimensions, compare segments and time periods, and return clear answers grounded in the business logic" the data team established. The Steep API exposes metric metadata and a query endpoint so external LLMs and agents can use the same governed definitions, and Steep's homepage also announces MCP access.

• Metrics catalog: a central place for metric, dimension and entity definitions, governed by the data team.
• dbt and Cube integrations: bring an existing semantic layer, or define metrics directly in Steep's own layer.
• Steep AI: a natural-language agent grounded in the semantic model, with metric links, reasoning steps and clarifying questions shown in the chat.
• Reports and exploration: interactive reporting over governed metrics, ad-hoc breakdowns, time-period comparisons, targets and a Cohorts view.
• Metrics API: metadata and query endpoints so an LLM, agent or downstream app can use the same metric definitions.
• Permissions, caching, SSO and SCIM: user roles and report permissions on every plan, with private metrics, SAML SSO, row-level security and SCIM on the higher tiers.

Pricing (at time of writing): Pro $15 per seat per month (free up to 3 seats), Business $25 per seat per month, Enterprise custom. The Steep Agent is available on paid workspaces. Steep is positioned as a BI replacement: fewer dashboards, a metrics catalog and an agent instead.

What is Mitzu?

Mitzu is an analytics platform on your data warehouse for BI, product analytics and experiment analysis, where the data team governs the metrics and everyone uses them through dashboards, an AI agent, Slack and their own AI assistants. It queries the warehouse in place (Snowflake, BigQuery, Databricks, Redshift, ClickHouse, PostgreSQL, Athena, Trino, Firebolt or Microsoft Fabric) and copies nothing out.

The data team defines metrics such as net revenue, orders, average order value and margin once, on its own fact and dimension tables. Mitzu can draft those definitions from the warehouse and dbt models for the data team to review, and a Configuration Agent scans the warehouse for event and dimension tables, identifiers and property values. Every KPI dashboard, insight, agent answer and scheduled agent reuses the same definitions. Business users build dashboards by clicking or by asking the agent. The same definitions also run funnels, retention, journeys and A/B test analysis: Mitzu reads the exposures your experimentation tool writes to the warehouse and reports lift, a 95% interval, p-values corrected for multiple comparisons, guardrail metrics and health checks.

People reach Mitzu in the app, by mentioning @mitzu in Slack, and through its MCP server from Claude, ChatGPT, Cursor, GitHub Copilot and other MCP clients. Scheduled monitoring agents review a dashboard or KPIs on the days and times you pick and email the team on every run, or only when a condition you describe in plain English is met, with the analysis attached. On every surface, each person sees only the data their Mitzu role allows.

The trust differentiator: Mitzu's agent does not write SQL. It assembles structured analysis specifications (a metric and its breakdown, funnel steps with a conversion window, retention cohorts and return events, segmentation filters with sampled property values, journey definitions) and a deterministic query engine turns those specifications into SQL. The same specification produces the same SQL every time. Methodology errors that LLMs reliably make, such as a funnel without a window, a retention chart that double-counts or a cohort defined wrong, are prevented by the engine rather than by prompt engineering.

Steep vs Mitzu: side-by-side

SQL examples: the same question, two paths

A governed KPI question such as "What was net revenue last quarter?" works in both tools once the metric is defined. The difference shows on the product question that usually comes next: "What is our 7-day signup-to-activation conversion rate, broken down by acquisition channel, for the last 30 days?"

Steep: SQL composed through the semantic layer

Steep's agent grounds itself in metric and dimension definitions. To answer this question, the metrics catalog would need at least two metrics, signups and activations_within_7d_of_signup, and a channel dimension on the user (or signup) entity. Once those exist, the agent composes a query roughly like:

-- The shape of query a metrics-first agent composes against
-- a BI semantic layer once the right metrics and dimensions exist.
WITH signups AS (
  SELECT user_id,
         min(event_time)            AS signup_at,
         any(properties['channel']) AS channel
  FROM events
  WHERE event_name = 'signup'
    AND event_time >= now() - INTERVAL 30 DAY
  GROUP BY user_id
),
activations_7d AS (
  SELECT s.user_id, s.channel
  FROM signups s
  WHERE EXISTS (
    SELECT 1 FROM events a
    WHERE a.user_id    = s.user_id
      AND a.event_name = 'activated'
      AND a.event_time BETWEEN s.signup_at AND s.signup_at + INTERVAL 7 DAY
  )
)
SELECT s.channel,
       count(*)                                                 AS signups,
       (SELECT count(*) FROM activations_7d a
         WHERE a.channel = s.channel)                           AS activated_7d,
       round(activated_7d / nullIf(signups, 0) * 100, 1)        AS conv_pct
FROM signups s
GROUP BY s.channel
ORDER BY signups DESC;

Three things to notice. First: the question depends on metric definitions that someone has to author and maintain in MetricFlow, Cube or Steep's own layer, including a metric for activation within a window. Second: dbt MetricFlow and Cube are BI-shaped semantic layers. They express metrics, dimensions and joins; MetricFlow can express a two-step conversion metric with a window, but multi-step funnels, retention by cohort and journeys are not first-class concepts, so the data team carries that methodology as derived metrics.

Third: when a new question arrives, such as changing the window from 7 days to 14 or splitting by week-of-signup cohort, somebody may have to author another metric. Methodology lives upstream in code.

Mitzu: SQL from a deterministic engine

The Mitzu agent does not write the SQL. It assembles a funnel specification, roughly { first_event: "signup", subsequent_events: ["activated"], conversion_window: "7d", breakdown: "channel", date_range: "last_30_days" }, and the deterministic engine emits the same SQL every time:

-- Engine output for a 2-step funnel with a 7-day conversion window,
-- broken down by channel, for the last 30 days. Same spec → same SQL.
WITH step_1 AS (
  SELECT user_id,
         min(event_time)             AS step_1_at,
         any(properties['channel'])  AS channel
  FROM events
  WHERE event_name = 'signup'
    AND event_time >= now() - INTERVAL 30 DAY
    AND event_time <  now()
  GROUP BY user_id
),
step_2 AS (
  SELECT s1.user_id,
         s1.channel,
         min(e.event_time) AS step_2_at
  FROM step_1 s1
  INNER JOIN events e
    ON e.user_id = s1.user_id
   AND e.event_name = 'activated'
   AND e.event_time >  s1.step_1_at
   AND e.event_time <= s1.step_1_at + INTERVAL 7 DAY
  GROUP BY s1.user_id, s1.channel
)
SELECT s1.channel                                AS channel,
       count(DISTINCT s1.user_id)                AS step_1_users,
       count(DISTINCT s2.user_id)                AS step_2_users,
       round(count(DISTINCT s2.user_id)
             / nullIf(count(DISTINCT s1.user_id), 0) * 100, 1) AS conv_pct
FROM step_1 s1
LEFT JOIN step_2 s2 USING (user_id)
GROUP BY channel
ORDER BY step_1_users DESC;

The conversion window is enforced strictly: activation must happen after signup and within 7 days. Distinct users prevent double-counting. Channel comes from the signup row, so attribution is consistent. Change the window to 14 days, or break down by week-of-signup cohort, and the agent re-assembles the specification; there is no new metric to author.

The same deterministic engine has been generating this shape of SQL in Mitzu's UI for years, and the funnel can sit on the same dashboard as the revenue KPI it explains.

Retention and journeys: where the methodology lives

"Week-by-week return rate for users who signed up in each of the last eight weeks." A classic cohort retention question. Steep added a Cohorts view in 2024 that tracks how groups of users behave over time, built from existing tables or from tables created for cohort analysis, so the answer depends on how the data team models the cohort and the return event upstream. dbt MetricFlow has no retention primitive of its own, and Cube's data model is similar in shape. In Mitzu, the agent sets the cohort event, the return event and the period in a specification, and the engine produces the SQL:

-- Engine output for cohort retention: weekly cohorts, weekly return,
-- 8 cohorts back, ClickHouse-flavoured SQL. Same spec → same SQL.
WITH cohorts AS (
  SELECT user_id,
         toMonday(min(event_time)) AS cohort_week
  FROM events
  WHERE event_name = 'signup'
    AND event_time >= toMonday(now()) - INTERVAL 56 DAY
  GROUP BY user_id
),
returns AS (
  SELECT c.cohort_week,
         c.user_id,
         dateDiff('week', c.cohort_week, toMonday(e.event_time)) AS week_n
  FROM cohorts c
  INNER JOIN events e
    ON e.user_id = c.user_id
   AND e.event_time >= c.cohort_week
   AND e.event_name IN ('session_start','core_action')
  GROUP BY c.cohort_week, c.user_id, week_n
)
SELECT cohort_week,
       count(DISTINCT user_id) FILTER (WHERE week_n = 0) AS week_0,
       count(DISTINCT user_id) FILTER (WHERE week_n = 1) AS week_1,
       count(DISTINCT user_id) FILTER (WHERE week_n = 2) AS week_2,
       count(DISTINCT user_id) FILTER (WHERE week_n = 3) AS week_3,
       count(DISTINCT user_id) FILTER (WHERE week_n = 4) AS week_4
FROM returns
GROUP BY cohort_week
ORDER BY cohort_week;

The same applies to journey trees (top paths from event A within N steps), churn analysis (users present in week N and absent in N+1), impact analysis (before and after a release, campaign or pricing change) and deep dives ("why did week-2 retention drop in November?", broken into many analyses and returned as one report). These are first-class in Mitzu's specification model. In a metrics-and-dimensions semantic layer, each one is a derived metric, a purpose-built table or a notebook outside the tool.

Experiments and monitoring on the same metrics

Two more jobs run on Mitzu's definitions. Experiment analysis reads the exposures that Optimizely, VWO, LaunchDarkly or an in-house assignment writes to the warehouse, and reports each test on the metrics the business already reports, with lift against control, a 95% interval, p-values corrected for multiple comparisons, guardrail metrics and health checks such as traffic split and users seen in several variants. Your experimentation tool keeps assigning users. Monitoring agents review a dashboard on a schedule, explain what moved and why, and email the team.

Steep's public materials list Slack report subscriptions and targets; they do not list experiment analysis or agent-based monitoring.

Advantages and trade-offs

Steep

Mitzu

Capability scorecard

Where each tool stands on governed metrics and KPI reporting, on product analytics and experiment analysis, and on how people reach the agent.

UI differences in practice

Steep's interface is metric-catalog-first: a sidebar of governed metrics, a report canvas for breakdowns and comparisons, and a chat surface for Steep AI. The chat shows the reasoning steps, the metrics and dimensions it referenced, and a clarifying question when the prompt is ambiguous. Mitzu's workspace puts KPI dashboards, insights (funnels, retention, segmentation, journeys), experiment results and the analytics agent side by side on one set of definitions. Each agent reply renders a chart or table that can go straight onto a shared dashboard, with the SQL the engine generated one click away.

The difference follows from the products: Steep is a metrics catalog with an agent on top; Mitzu is KPI reporting, product analytics and experiment analysis on the same governed definitions, with the agent as one of several ways in.

When to choose Steep, Mitzu, or both?

For governed KPI reporting and self-service, the two are direct alternatives. The deciding question is what else your teams need to run on the same definitions.

• Choose Steep when the job is a governed metrics catalog with reports and an agent across the business (revenue, MRR and ARR, marketing performance, operational KPIs), your team already maintains a dbt or Cube semantic layer it wants Steep to publish, and product analytics and experiment analysis are handled elsewhere or not needed.
• Choose Mitzu when you want KPI dashboards plus funnels, retention, journeys and A/B test results on one set of definitions the data team governs; an agent that explains why a number moved, with SQL from a deterministic engine; and the same answers in Slack, in your team's AI assistants and in scheduled monitoring emails.
• Run both during a migration, or when Steep already serves finance and operations reporting and you add Mitzu for product analytics and experiments on the same warehouse. The cost is two sets of definitions to keep in sync.

FAQ

Does Steep do product analytics out of the box?

Steep answers metric questions on event data once those metrics are defined in MetricFlow, Cube or its own semantic layer, and it has a Cohorts view for tracking groups of users over time. Funnels with conversion windows, journey trees, segmentation with sampled property values and impact analysis are not native primitives of a metrics-and-dimensions semantic layer; they have to be expressed as derived metrics or handled outside the tool. In Mitzu they sit next to the KPI dashboards, on the same definitions.

Can Mitzu replace Steep for finance and ops dashboards?

For KPI dashboards and self-service reporting on governed metrics such as revenue, orders, average order value and margin, yes: many teams use Mitzu instead of a separate BI tool. Teams with heavy pixel-perfect or financial reporting (board packs, P&L, FP&A) often keep a BI tool for that and use Mitzu for everything that needs product data or an answer to why.

Both tools talk about a semantic layer. Aren't they the same?

They overlap. A BI semantic layer (dbt MetricFlow, Cube, LookML, what Steep relies on) expresses metrics, dimensions, entities and joins. Mitzu's semantic layer holds the same kind of governed metrics, defined on fact and dimension tables, and also the events, event properties, entities, dimension properties and sampled property values that funnel, retention, journey and experiment questions need. Mitzu drafts these definitions from the warehouse and dbt models; the data team reviews and owns them.

What warehouses does each tool support?

Steep advertises connectors to all major databases on its pricing page, with multiple data sources and custom connectors on the Enterprise tier. Mitzu supports Snowflake, BigQuery, Databricks, Redshift, ClickHouse, PostgreSQL, Athena, Trino, Firebolt and Microsoft Fabric. Both keep queries running in the customer's warehouse, and neither requires data egress.

Does Mitzu have a metrics API like Steep?

Mitzu exposes its analytics agent through a remote MCP server (Model Context Protocol). Claude, ChatGPT, Cursor, GitHub Copilot and any other MCP client can ask it a question and get an answer built on your governed metrics, with the SQL behind it and the asker's Mitzu permissions applied. It is not a generic metrics API in the Steep shape, but it covers the main use case: bringing governed answers into another tool.

Can Mitzu analyze our A/B tests?

Yes. Mitzu reads A/B test exposures from your warehouse and reports lift, confidence intervals, guardrails and health checks on the same metrics your business reports. Your experimentation tool, such as Optimizely, VWO, LaunchDarkly or an in-house system, keeps assigning users and setting up variants.

Related reading

• Agentic Analytics Platforms Compared
• ClickHouse AI vs Mitzu
• Agentic Analytics and the Semantic Layer
• BI vs Product Analytics
• AI Analytics Hallucinations and SQL Transparency
• Mitzu BI and Warehouse Metrics
• Mitzu Experiment Analysis
• Mitzu Semantic Layer
• Mitzu Product Analytics

References

• Steep: product homepage
• Steep: pricing
• Steep blog: Introducing Steep AI
• Steep blog: dbt MetricFlow integration
• Steep blog: Cube integration
• Steep blog: Cohorts
• Steep blog: Metrics API
• Mitzu documentation (docs.mitzu.io)