How to build Stigg monetization dashboards in Metabase

Stigg is a pricing, packaging, and entitlement platform: it defines your plans, gates features, and meters usage. Metabase is where you turn that into shared, trustworthy monetization dashboards — plan adoption, entitlement usage, and upgrade paths — and join it with product and billing data. Because Metabase reads from SQL databases, the reliable way to connect them is a small pipeline: sync Stigg into a database or warehouse on a schedule, then point Metabase at it. This guide walks through that path end to end — including a free option with no paid connector.

How do you connect Stigg to Metabase?

Metabase connects to SQL databases and warehouses — not to SaaS APIs directly, and there's no native Stigg connector. So connecting Stigg to Metabase means one thing: run a small pipeline that copies Stigg data into a database on a schedule, then connect Metabase to that database. Once the data lands, the models, metrics, and SQL later in this guide all work.

The good news: this doesn't require a paid tool. Use a managed connector if you want zero maintenance, or a free, code-based sync you host yourself — both are covered in Build the pipeline below, and in more depth in our guide to building a data pipeline.

What can you analyze from Stigg data in Metabase?

• Plan adoption — active subscriptions and MRR by plan
• Packaging — add-on attach rates and plan mix over time
• Entitlement usage — usage against limits, by feature and plan
• Upgrades and downgrades — migration paths and expansion MRR
• Paywall conversion — trial/free-to-paid and feature-gate-driven upgrades
• At-risk accounts — customers hitting limits or downgrading

Which Stigg dashboards should you build in Metabase?

How do you build the Stigg → Metabase pipeline?

For dashboards that need history and reliability, land Stigg data in a database first, then connect Metabase to that database.

Connector options

• Stigg API (free, raw) — pull customers, subscriptions, plans, and entitlements into your own pipeline.
• Webhooks (free, events) — stream subscription and entitlement events into a table for near-real-time dashboards.
• Your billing provider — Stigg drives billing through a provider like Stripe; sync that for hard revenue and join on the customer/subscription id.

Notes

• Land raw tables first, then build clean models on top.
• Keep a stable customer id that maps across Stigg and your billing provider.
• Distinguish metered (usage) entitlements from boolean/config ones — they chart differently.
• MRR by plan is derived from active subscriptions and plan prices.

Can you generate a Stigg dashboard with AI?

Yes — and once Stigg data is synced into a database, this is the fastest way to a strong first draft. First give an AI assistant a way to read your Metabase schema and create questions and dashboards, then paste the prompt below. It builds the dashboard from your database tables and tells the agent to skip metrics the schema can't support instead of faking them.

Two ways to let an assistant query and build in Metabase

Both connect to a Metabase instance that's already pointed at your synced database — the pipeline above moves the data; these just let the assistant read and write Metabase. Pick whichever fits your setup:

Set up the Metabase MCP server

Enable it under Admin → AI → MCP, then point your client at the endpoint:

# Metabase built-in MCP (replace with your instance URL)
claude mcp add --transport http metabase https://your-metabase.example.com/api/metabase-mcp

{
  "mcpServers": {
    "metabase": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://your-metabase.example.com/api/metabase-mcp"]
    }
  }
}

Clients with native remote support can use a "url" field instead of the mcp-remote bridge. Confirm the current endpoint in the Metabase MCP docs.

Set up the Metabase CLI

Install it globally, then authenticate once (the binary is mb):

# Install the CLI (the binary is `mb`)
npm install -g @metabase/cli

# Authenticate once — opens your browser on Metabase v62+, or use an API key
mb auth login --url https://your-metabase.example.com
mb auth status

On Metabase v62+ mb auth login opens your browser; older servers fall back to an API key. A terminal-based assistant can then inspect your schema (mb db schemas, mb table get --include fields) and create content (mb card create, mb dashboard create) against the synced tables.

Prompt: build the Stigg Monetization Overview dashboard

With MCP or the CLI connected, paste this into your assistant to generate the dashboard:

Create a polished Metabase dashboard for Stigg monetization analytics using the
available Stigg tables in this database.

Goal: Help product and monetization leaders understand plan adoption, packaging,
entitlement usage, upgrades/downgrades, and paywall conversion from Stigg data.

First, inspect the schema and identify the available Stigg tables. Do not assume
exact table names. Map the raw data into these analytical concepts where
possible: Customers, Subscriptions, Plans, Add-ons, Features, Entitlements, and
Usage measurements. If billing amounts live in a separate billing provider table
(e.g. Stripe), join to it for revenue.

Important:
- Build the dashboard from durable database/warehouse tables (Stigg API/webhooks).
- Compute MRR by plan from active subscriptions and plan prices, normalized to a
  monthly amount; if hard revenue lives in the billing provider, prefer that and
  say so.
- Show entitlement usage against its limit, not raw usage alone.
- Separate metered (usage-based) features from boolean/config entitlements.
- Do not claim Metabase connects natively to Stigg unless that is explicitly true
  in this environment.

Dashboard title: Stigg Monetization Overview

Sections:
1. Executive summary (KPI cards): Active subscriptions; MRR; Net new MRR; Upgrade
   rate; Free/trial-to-paid conversion; Customers near a usage limit.
2. Plans & packaging: Subscriptions and MRR by plan and add-on; Plan mix over
   time; Add-on attach rate.
3. Entitlement usage: Usage vs. limit by feature; Customers approaching a limit;
   Metered consumption over time.
4. Upgrades & downgrades: Migration paths; Expansion MRR; Time-on-plan before
   upgrade.
5. Paywalls & conversion: Trial/free-to-paid conversion; Paywall conversion by
   plan; Feature-gate hits that led to upgrades.

Filters: Plan, Add-on, Feature, Billing period, Date range.

Before finalizing, create or recommend reusable Metabase models:
modeled_stigg_subscriptions, modeled_stigg_entitlement_usage, and
modeled_stigg_mrr (a monthly per-subscription MRR model by plan).

Output: Build the dashboard if you have permission; otherwise provide the exact
questions, SQL, model definitions, and layout. Include caveats for any metric
that cannot be calculated from the available schema. Keep it practical, dense,
and executive-readable. Avoid vanity metrics.

How should you model Stigg data in Metabase?

Core tables

Modeling advice

• Build a modeled_stigg_mrr table by plan — one row per subscription per month with a normalized monthly amount.
• Model entitlement usage as usage-vs-limit so "80% of limit" is a first-class column.
• Track plan changes as an event stream so upgrade/downgrade paths are queryable.
• Join to your billing provider on a shared customer id when you need audited revenue.
• Reconcile MRR by plan against your billing provider's totals.

Which Stigg metrics should you track in Metabase?

What SQL powers Stigg dashboards in Metabase?

These assume the modeled tables above (PostgreSQL dialect). Adjust identifiers to match your schema.

-- Requires a monthly MRR model built from Stigg subscriptions + plan prices
SELECT
  plan_name,
  COUNT(*)                 AS active_subscriptions,
  ROUND(SUM(mrr), 2)       AS mrr,
  ROUND(SUM(mrr) * 12, 2)  AS arr
FROM modeled_stigg_mrr
WHERE month = date_trunc('month', CURRENT_DATE)
GROUP BY plan_name
ORDER BY mrr DESC;

-- Customers close to hitting a metered entitlement limit
SELECT
  c.customer_id,
  f.feature_name,
  e.usage_limit,
  u.current_usage,
  ROUND(100.0 * u.current_usage / NULLIF(e.usage_limit, 0), 1) AS pct_of_limit
FROM entitlement_usage u
JOIN entitlements e ON e.id = u.entitlement_id
JOIN features f     ON f.id = e.feature_id
JOIN customers c    ON c.customer_id = u.customer_id
WHERE e.usage_limit IS NOT NULL
  AND u.current_usage >= 0.8 * e.usage_limit
ORDER BY pct_of_limit DESC;

SELECT
  date_trunc('month', changed_at) AS month,
  COUNT(*) FILTER (WHERE change_type = 'upgrade')   AS upgrades,
  COUNT(*) FILTER (WHERE change_type = 'downgrade') AS downgrades
FROM subscription_changes
WHERE changed_at >= CURRENT_DATE - INTERVAL '12 months'
GROUP BY 1
ORDER BY 1;

What are common mistakes when analyzing Stigg in Metabase?

Related

Related analytics

Related metrics

Related integrations

FAQ