One of the first things teams notice after moving to a headless setup is that the familiar admin dashboard is gone. Shopify and similar platforms bundle in built in analytics, order trends, conversion funnels, product performance, all visible the moment you log in. Medusa.js does not ship that layer by default, because it is not trying to be an all in one platform, it is trying to be a flexible commerce backend. That means the analytics dashboard becomes something your team has to design and build on purpose.
This guide walks through what data is actually available inside a Medusa.js store, which metrics are worth tracking first, and a practical architecture pattern for turning raw order and event data into a dashboard your operations and growth teams will actually use.
Why Headless Stores Do Not Come With Analytics Built In
A headless commerce backend like Medusa.js is built around modular commerce primitives, products, orders, customers, pricing, fulfillment, exposed through clean APIs rather than a bundled admin UI with charts baked in. That is the whole appeal for teams that want custom checkout logic or multiple storefronts running off one backend, but it also means reporting is left entirely to you. There is no default revenue chart waiting on day one.
Talk to our Medusa engineers
Lets TalkWhere This Data Actually Lives In Medusa.js
Most of what a dashboard needs already exists inside Medusa's data model, it just is not aggregated anywhere yet. Orders, line items, payments, and fulfillment records live in the core database and are reachable through the admin API. Storefront behaviour, things like product views, cart additions, and checkout drop off, is not something Medusa tracks natively, so this part usually comes from a frontend analytics layer such as a lightweight event tracker sending data to your own warehouse or a tool like Google Analytics running on the storefront.
The practical approach most teams land on is treating Medusa as the source of truth for anything transactional, orders, refunds, fulfillment status, while treating the storefront as the source of truth for behavioural data, page views, add to cart events, search queries. Both feeds then get combined at the reporting layer rather than trying to force one system to hold everything.
A Practical Architecture For The Dashboard
A pattern that scales well without overengineering the first version looks like this. Order and fulfillment events are pushed from Medusa into a lightweight warehouse, this can be as simple as a scheduled job pulling from the admin API into a Postgres analytics schema, or an event driven setup using Medusa's subscriber hooks for near real time updates. Storefront behavioural events get sent separately into the same warehouse or a connected analytics tool.
From there, a dashboard layer, whether that is a custom internal admin panel built with a charting library or a business intelligence tool pointed at the warehouse, reads from the combined data set. Keeping the raw transactional data in Medusa and the aggregated reporting data in a separate warehouse avoids putting analytical query load on the same database that is handling live checkout traffic.
Common Pitfalls Teams Run Into
Double counting orders is the most frequent bug, usually caused by counting both the order creation event and a later status update event as separate sales. Timezone mismatches between the warehouse, the storefront, and the reporting tool are another common source of numbers that quietly do not match what operations sees in the Medusa admin. Cart abandonment tracking is often skipped entirely in the first version of a dashboard, even though it is one of the more actionable metrics for a growth team trying to improve conversion.
Building analytics for a headless store takes more upfront work than flipping on a built in dashboard, but the payoff is a reporting layer that actually matches how your business measures success, rather than being boxed into whatever metrics a platform decided to expose. If your team is scoping this kind of build, our Medusa.js development team has put together this exact kind of reporting layer for stores moving off traditional platforms.