SaaS Revenue Analytics and MRR Tracking

Use-case evidence path

SaaS Revenue Analytics with SQL: from implementation to decision

A complete saas revenue analytics with sql measurement loop connects one owned workflow, a bounded event contract, a controlled fixture, and a question someone can act on.

1
Set the boundary
Document the source of truth for subscriptions, invoices, entitlements, and account identity.
2
Capture the outcome
Begin with subscription_revenue_moved, invoice_payment_completed, invoice_payment_failed and document the grain of each event.
3
Prove the rows
Join reviewed revenue movements to product outcomes only after validating account identity and cohort windows.
4
Make the decision
How much MRR came from new, expansion, contraction, churn, and reactivation movements?

Scope and neighboring use cases

Choose this page for the right measurement boundary

Use this page for subscription revenue movements and revenue retention, not raw payment volume alone.
Use usage-based billing analytics for meter, quota, entitlement, and invoice-input correctness.
Use product analytics and retention for behavioral cohorts that do not require an accounting-style revenue reconciliation.

Agent prompt

Paste this into your coding agent

Replace YOUR_API_KEY after signup, then ask the agent to run the product flow and verify the first events.

agent prompt

SaaS Revenue Analytics with SQL setup prompt

text

Instrument SaaS revenue analytics with Telemetry.

Use /skill.md and this Telemetry API key: YOUR_API_KEY

Create immutable subscription_revenue_moved events for new, expansion, contraction, churn, and reactivation movements. Include account_id, subscription_id, movement_type, prior_mrr_minor, new_mrr_minor, movement_mrr_minor, currency, effective_at, plan, billing_interval, reason_category, source_event_id, and schema_version.

Add invoice payment and entitlement outcome events with stable provider identifiers so a closed period can be reconciled without counting webhook retries twice. Connect product outcomes using the same approved account_id.

Create SQL for MRR movement, gross and net revenue retention, payment-failure recovery, expansion by activation cohort, and revenue at risk after reliability incidents.

Keep money in integer minor units, preserve currency, document the reporting timezone and cohort window, and do not log card data, invoice PDFs, customer names, email addresses, or unrestricted provider payloads.

Setup steps

1Document the source of truth for subscriptions, invoices, entitlements, and account identity.
2Emit immutable revenue-movement events with currency, effective time, prior value, new value, and reason category.
3Reconcile a closed billing period against the provider export before publishing MRR or retention metrics.
4Join reviewed revenue movements to product outcomes only after validating account identity and cohort windows.

Events to capture

subscription_revenue_movedinvoice_payment_completedinvoice_payment_failedentitlement_changedaccount_product_outcome_completed

Questions unlocked

How much MRR came from new, expansion, contraction, churn, and reactivation movements?
Which activation and adoption patterns precede retained or expanded revenue?
Which failed payments, reliability incidents, or entitlement changes put recurring revenue at risk?

Event schema starting points

Review the row grain, emit boundary, required types, privacy classes, example payload, and validation checklist before adapting a query or snippet to production.

Product lifecycle7 fields