How to build Stigg monetization dashboards in Metabase

# Stigg (remote, X-API-KEY header)
claude mcp add --transport http stigg https://mcp.stigg.io \
  --header "X-API-KEY: <YOUR_STIGG_SERVER_API_KEY>"

{
  "mcpServers": {
    "stigg": {
      "url": "https://mcp.stigg.io",
      "headers": {
        "X-API-KEY": "<YOUR_STIGG_SERVER_API_KEY>"
      }
    }
  }
}

{
  "mcpServers": {
    "stigg": {
      "command": "npx",
      "args": ["-y", "@stigg/typescript-mcp"],
      "env": { "STIGG_API_KEY": "<YOUR_STIGG_SERVER_API_KEY>" }
    }
  }
}

# Install the Metabase CLI
npm install -g @metabase/cli

# Log in (opens your browser; requires Metabase v62+)
mb auth login --url https://your-metabase.example.com

# Load a Stigg CSV export — creates a table AND a model
mb upload csv --file stigg-subscriptions.csv --collection root

# Refresh that same table later from a new export
mb upload replace <table-id> --file stigg-subscriptions.csv

Create a polished Metabase dashboard for Stigg monetization analytics.
Work end to end: get the data into Metabase if it isn't there yet, then build.

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

Step 1 — Find or load the data:
- First, check what already exists in Metabase (search for Stigg tables and
  models). If durable Stigg data is already present — synced from a warehouse or
  uploaded earlier — use it and skip to Step 2.
- If nothing is there, pull it with the Stigg MCP server using a server API key:
  customers, subscriptions, plans, add-ons, features, entitlements, and usage
  measurements. Write each result to a CSV, then load it with the Metabase CLI —
  run "mb upload csv --file <export>.csv" so each upload creates a table and a
  ready-to-query model. Use "mb upload replace <table-id> --file <export>.csv" to
  refresh an existing table instead of creating duplicates.

Step 2 — Inspect before querying:
Do not assume exact table names. Map the available raw tables 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. Inspect
the actual tables and column names first.

Important:
- Build on whatever data is present; don't claim Metabase connects natively to
  Stigg — it reads a database or CLI-uploaded tables.
- 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.
- Only build a card if its underlying column/metric exists in the data.
- A single CSV is a point-in-time snapshot: plan migrations and cohorts need
  history, so build trend cards only if a warehouse sync or multiple uploads
  provide it.

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.

Reuse the models Metabase auto-created from uploaded CSVs, or (for a warehouse)
create reusable 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 data. Keep it practical, dense,
and executive-readable. Avoid vanity metrics.

Plan adoption and the revenue behind it.

-- 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;

Metered entitlements at 80%+ of their limit — upgrade candidates.

-- 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;

Plan-change direction over the last year.

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;