Dashboard

What goes in a course revenue dashboard?

A course revenue dashboard answers the question every creator platform's own reporting dodges: what did you actually keep? Gross sales, minus the platform's cut, minus payment processing, minus refunds and chargebacks, reconciled against the money that landed in your bank account. Everything else on the dashboard — product mix, offer performance, payment-plan revenue — hangs off that spine.

For: Course creators, digital product businesses, and the finance or ops person behind them. Refresh: daily; payouts reconcile on the platform's settlement schedule. Source: modeled tables in a Metabase-connected database.

Which cards belong on this dashboard?

  • Gross revenue vs. net revenue after all fees, by month
  • Effective fee rate: platform plus payment fees as a share of gross
  • Revenue by product or course, top 15
  • New purchases vs. payment-plan installments vs. renewals
  • Refund rate by product and by weeks since purchase
  • Revenue by offer, coupon, or traffic source
  • Average order value and its trend
  • Payout reconciliation: net revenue recognized vs. payouts received

What data does this dashboard need?

  • An order or transaction table at the charge grain, with gross amount, currency, and timestamp
  • A fee breakdown per transaction: platform fee, payment processing fee, tax collected
  • A product table with type (course, membership, download, coaching) and price
  • Refunds and chargebacks as their own rows or columns, dated when they occurred
  • Payout records with settlement date and the transaction IDs each payout covers

How do you build it?

  1. Land the source data in a database — via a managed connector, scheduled API pulls, or a CSV loaded with mb upload csv — keeping raw IDs, timestamps, currencies, and fee lines intact.
  2. Build models at the grain this dashboard needs, with gross, fee, tax, and net amounts as explicit columns rather than per-card arithmetic.
  3. Create one saved question per card and certify the shared models so every dashboard downstream inherits the same definitions.
  4. Add dashboard filters for Date range, product or course, offer or coupon, traffic source, currency.
  5. Show data freshness on the dashboard — these sources lag, and every viewer should see by how much.

Example card SQL

Gross-to-net revenue by month with the effective fee ratePostgreSQL
WITH monthly AS (
  SELECT
    date_trunc('month', o.ordered_at)::date AS month,
    SUM(o.gross_amount_usd) AS gross,
    SUM(o.platform_fee_usd) AS platform_fees,
    SUM(o.payment_fee_usd) AS payment_fees,
    SUM(o.refund_amount_usd) AS refunds,
    COUNT(*) AS orders,
    COUNT(*) FILTER (WHERE o.refund_amount_usd > 0) AS refunded
  FROM creator_orders o
  WHERE o.ordered_at >= date_trunc('month', CURRENT_DATE)
      - INTERVAL '12 months'
  GROUP BY 1
), net AS (
  -- Refunds are subtracted in the month they happened, not the
  -- month of the original sale, so this is a cash-style view.
  SELECT
    m.*,
    gross - platform_fees - payment_fees - refunds AS net_revenue
  FROM monthly m
)
SELECT
  month,
  ROUND(gross, 2) AS gross_revenue,
  ROUND(net_revenue, 2) AS net_revenue,
  ROUND(
    100.0 * (platform_fees + payment_fees) / NULLIF(gross, 0), 1
  ) AS effective_fee_rate_pct,
  ROUND(100.0 * refunded / NULLIF(orders, 0), 1) AS refund_rate_pct,
  ROUND(gross / NULLIF(orders, 0), 2) AS average_order_value,
  ROUND(
    100.0 * (
      net_revenue / NULLIF(LAG(net_revenue) OVER (ORDER BY month), 0) - 1
    ), 1
  ) AS net_mom_growth_pct
FROM net
ORDER BY month;

Dashboards

Integrations

Metrics

Analytics

FAQ

Why doesn't net revenue match what hit my bank account?
Timing. Platforms settle on a delay — often 2 to 14 days, longer for new accounts or high-refund products — so a month of recognized net revenue and a month of payouts never line up. Reconcile by joining payouts back to the transactions they cover rather than comparing monthly totals, and keep the platform fee rate as its own card so a pricing change on the platform side is visible immediately.
Should payment-plan installments count as revenue up front?
For cash reporting, no — count each installment when it is charged, because that's when the money (and the fees) move. For a customer-value view, attribute the whole plan to the original purchase and track completion rate separately; plans default, and a dashboard that books the full amount on day one overstates every cohort.
Can Metabase pull this from Kajabi or Teachable directly?
Metabase queries SQL databases and warehouses, not SaaS APIs. Get the platform's order, fee, and payout exports into Postgres, BigQuery, Snowflake, or a similar store — via a sync tool, a scheduled export job, or CSV upload — and point Metabase at the modeled tables. Once the data lands, the same models feed related metrics like average order value and repeat purchase rate.