For independent WordPress plugin and theme developers, understanding the financial health of your business requires checking at least four separate data points: total revenue (to understand overall traction), MRR (to understand recurring revenue momentum), average order value (to evaluate pricing effectiveness), and per-product performance (to identify which plugins deserve more investment). In Freemius’ native developer dashboard, these data points are spread across multiple pages and require manual aggregation if you have more than one product.

The Sales Analytics Dashboard in Freemius Checkout for WooCommerce consolidates all four data points — plus refund tracking, purchase counts, and per-plugin comparative analysis — into a single React-powered screen inside your WordPress admin. The data is fetched live from the Freemius PHP SDK on every dashboard load, ensuring you always see current numbers without stale cache artifacts.

Why Freemius Developers Need a WordPress Analytics Dashboard

If you run your plugin marketing site on WordPress — as most independent developers do — your workflow lives in the WordPress admin. Switching to freemius.com to check revenue numbers, then back to WordPress to write a blog post, then back to freemius.com to create a coupon for a promotion, creates constant context-switching overhead that interrupts creative and business work.

More practically: having revenue metrics visible inside WordPress encourages more frequent monitoring. Developers who check their numbers daily in the same environment where they manage content and marketing make faster, better-informed decisions about pricing adjustments, promotion timing, and product prioritization.

Core Dashboard Metrics Explained

How MRR Is Calculated from Freemius Subscription Data

MRR calculation requires careful handling of mixed billing cycles. The plugin fetches all subscriptions via /plugins/{id}/subscriptions.json and applies this normalization logic:

Only subscriptions meeting all three criteria are included in MRR:

• Not cancelled (canceled_at field is empty)
• Not expired (is_expired is false)
• Not in sandbox/test mode (environment field is 0)
• Both amount_per_cycle and renewal_amount are greater than zero (subscriptions with $0 renewal amounts are excluded)

This produces a conservative, accurate MRR figure that reflects only currently active, paying subscriptions — not trial users, not cancelled subscribers still within their paid period, and not test accounts. The resulting MRR is the “live” recurring revenue number you’d use when evaluating business health or discussing your business with investors or acquirers.

Gross Revenue vs Net Revenue: Refund Tracking

Freemius payment records include both positive gross amounts (sales) and negative gross amounts (refunds). The analytics engine handles both:

• Positive gross amounts: Added to plugin gross revenue and purchase count (renewal payments are excluded from purchase count to avoid inflating the orders metric)
• Negative gross amounts or payments of type ‘refund’: Added to the refunds total and excluded from gross revenue
• Net Revenue = Gross − Refunds: The “real” revenue figure after honoring refund obligations

Displaying refund data separately (rather than just showing net revenue) is a deliberate design choice — it allows you to see your refund rate clearly and act on it. A rising refund trend that’s invisible in a net revenue-only view could indicate a product quality issue or misleading feature claims that warrant immediate attention.

Average Order Value: The Pricing Health Signal

Average Order Value (AOV) is calculated as Gross Revenue ÷ Total New Purchases. It is one of the most actionable metrics for a WordPress plugin developer because it directly reflects your pricing architecture’s effectiveness:

The per-plugin AOV in the Plugin Breakdown Table is particularly useful — comparing AOV across products tells you which products have pricing architectures that successfully guide customers to higher tiers vs. which are leaving revenue on the table at the entry-level.

Plugin-by-Plugin Breakdown Table

Below the aggregate metric cards, the dashboard renders a detailed Plugin Breakdown Table that shows every product in your Freemius developer account with its individual financial metrics side-by-side. Columns displayed for each product:

This comparative view is the most actionable analytical output for multi-product plugin developers. It immediately answers the question: “Which product should I focus my next marketing effort on?” — usually the one with the highest MRR (most traction to build on) or the one with the highest purchase count but lowest AOV (pricing optimization opportunity).

Sandbox Transaction Filtering

During plugin development and testing, Freemius allows sandbox/test transactions that generate payment records in the API but don’t represent real revenue. Including these in analytics produces misleadingly inflated numbers.

The analytics engine explicitly checks the environment field on each payment and subscription record and skips any record where environment !== 0. Environment 0 indicates a live production transaction. Environment 1 indicates a sandbox test transaction. This filtering happens at the data ingestion layer before any metric calculation — ensuring that your dashboard always reflects only real customer revenue, regardless of how much test purchasing you’ve done during development.

WordPress Plugin Dashboard vs. Freemius Native Dashboard

Vs. Lemon Squeezy & Paddle: Why WordPress-Native Analytics Wins

Both Lemon Squeezy and Paddle are increasingly considered as freemius alternatives for WordPress plugin monetization. One genuine advantage both have over Freemius is a more modern analytics dashboard on their own platforms — Lemon Squeezy in particular has excellent revenue charting and subscription metrics in its dashboard.

However, neither Lemon Squeezy nor Paddle offers a WordPress plugin that brings their analytics into the WordPress admin. For WordPress developers who spend most of their working hours inside WordPress, having your revenue data in the same environment where you write content, manage plugins, and build marketing pages is a significant productivity advantage that no external dashboard can replicate.

Additionally, Freemius’ deeper WordPress integration — native update API, in-plugin freemium flows, per-site license enforcement — gives it structural advantages over both Lemon Squeezy and Paddle for WordPress-specific products that this analytics dashboard builds upon rather than replaces.

API Architecture: How Data Is Fetched

The analytics data flow works as follows:

1. The React dashboard makes a GET request to the WordPress REST API endpoint: /wp-json/freemius-checkout/v1/stats
2. The REST handler instantiates Freemius_API_Service using the stored credentials
3. The service calls get_stats() which fetches /plugins.json to get all products
4. For each product, it calls /plugins/{id}/payments.json?count=100 (payments) and /plugins/{id}/subscriptions.json?count=100 (for MRR)
5. Metrics are calculated server-side in PHP and returned as a structured JSON response
6. The React dashboard renders the metric cards and breakdown table from the JSON response

The current implementation fetches up to 100 payments and subscriptions per product per API call. For high-volume products with very large transaction histories, this represents the most recent 100 records. Future versions may implement pagination or date range filtering for larger catalogues.

Frequently Asked Questions