You added Matomo to your store, the pageviews and visits look healthy, and then you open the Ecommerce reports and there's nothing there. No orders, no products, or the Ecommerce menu isn't even in the sidebar. On a Magento shop it usually surfaces as "I can see general statistics, but nothing about products or orders." Your tracking isn't broken in the way it looks. One of the two halves of Matomo Ecommerce is missing, and you almost certainly only have the other one in place.
Matomo Ecommerce is two things wearing one name: a per-site setting that makes the reports exist, and the tracking calls that fill them, and most stores only have the setting (Magento and Adobe Commerce ship with no Ecommerce tracking, so Orders and Products read zero). Turn Ecommerce on under Administration → Websites, then make the store actually fire the calls through an extension, Matomo Tag Manager, or your own code. If you write the calls yourself, push setEcommerceView before trackPageView on product pages, since it attaches to the next pageview and records nothing if the snippet already fired one. To confirm it works, place a test order and watch it land in Visitors → Visits Log rather than waiting on the reports, which lag behind archiving.
That's the thing to get straight before you change anything. Matomo Ecommerce is really two systems with one name:
- Enabling Ecommerce on the site. A per-site setting that makes the Ecommerce reports exist.
- Sending Ecommerce tracking calls. The JavaScript (or server-side) events that report product views, cart updates, and completed orders.
The standard Matomo snippet you pasted into your store only does one thing: it sends pageviews. It has no concept of a product or an order. Unless something on the page explicitly fires the Ecommerce calls, those reports stay empty even with the setting switched on. And here's the part that catches Magento stores in particular: Magento 2 and Adobe Commerce ship with no built-in Matomo Ecommerce tracking. So the reports look broken straight out of the box, when really nothing was ever wired up to feed them.
The root causes, in the order worth checking
- Ecommerce isn't enabled for the site. If the setting is off, the Ecommerce menu doesn't appear at all, which is the "statistics not found" version of the problem.
- No Ecommerce calls are being sent. Your snippet tracks pageviews only; nothing fires
addEcommerceItemortrackEcommerceOrder. This is the usual Magento case. - The order call never fires on the success page. Cart updates work, but
trackEcommerceOrderdoesn't run on the "thank you" page. A cached confirmation page, a redirect, or a checkout that loads the page over AJAX will all break it. - Reports haven't been archived yet. The data is arriving, Matomo just hasn't processed it into reports.
- An ad blocker or consent tool is silently dropping the request while you test.
The fix
1. Turn Ecommerce on for the site
Go to Administration → Websites → Manage, click the edit (pencil) icon for your site, scroll to the Ecommerce dropdown, and switch it from "Not an Ecommerce site" to "Ecommerce enabled". Pick your currency in the dropdown that follows, then save. An Ecommerce item now appears in the left-hand navigation.
If you don't see the menu after saving, you almost always saved the setting on the wrong site. Each site (idSite) is configured on its own, so double-check you edited the one your tracker actually reports to before assuming something deeper is wrong. If you run several stores or domains off one Matomo, our note on organising multiple sites and measurables is worth a glance.
2. Make your store actually send the Ecommerce calls
This is the half almost everyone is missing. Pick one of three routes.
An extension. The widely used JaJuMa "Matomo Analytics" extension for Magento 2 wires up product views, cart updates, and order conversions for you, and it has a server-side PHP tracking mode for more accurate order numbers. One thing worth being plain about, since people ask: the JaJuMa module listed on the Adobe Commerce Marketplace is commercial, so check its current pricing and editions before you commit. You're not forced to buy it. Matomo's Ecommerce reporting is free on its own; the extension only saves you from writing the tracking code yourself.
Matomo Tag Manager. If your store already pushes ecommerce events to a data layer (or you add an extension that does), Matomo Tag Manager can read those events and fire the Ecommerce calls without hard-coding tracking into every template. With no data layer in place, this still needs developer work to populate one. Serving the container first-party also dodges some of the ad-blocker problems that quietly eat tracking requests.
Custom code in your theme. If you have dev resources, add the calls yourself. That's step 3.
3. If you wire the calls yourself, get the signatures right
Matomo's Ecommerce JavaScript API is small, but parameter order and types matter, and so does when each call fires. On a product or category page, set the Ecommerce view, then fire the pageview it belongs to:
// productSKU is required; the rest are optional
_paq.push(['setEcommerceView', productSKU, productName, categoryName, price]);
_paq.push(['trackPageView']);setEcommerceView doesn't send anything on its own; it attaches product data to the next pageview. If the standard snippet already fired trackPageView higher up the page, pushing setEcommerceView after it records nothing for that view. On product and category pages, push the Ecommerce view first, then call the pageview.
On add-to-cart or the cart page, list each item, then update the cart total:
_paq.push(['addEcommerceItem',
productSKU, // required
productName, // recommended
categoryName, // optional
price, // optional
quantity // optional, defaults to 1
]);
_paq.push(['trackEcommerceCartUpdate', cartGrandTotal]); // cart total, requiredOn the order confirmation page, add every line item, then track the order:
// one addEcommerceItem per line, then:
_paq.push(['trackEcommerceOrder',
orderId, // required, unique
grandTotal, // required, total incl. tax/shipping/discount
subTotal, // optional
tax, // optional
shipping, // optional
discount // optional
]);Two things trip people up here. First, only orderId and grandTotal are required on the order call; the rest are optional, but if you do supply them, get the order right. Second, every monetary value has to be a number, not a string: 19.90, not "19.90". Matomo's docs are explicit that price, grandTotal, subTotal, tax, shipping, and discount must be integers or floats, and passing strings is the most common reason totals come out wrong or missing.
Unlike the product view, the cart-update and order calls aren't bound to a pageview. They fire on their own when the cart changes or the order completes, so they can run after the page's normal trackPageView.
4. Confirm the reports are archiving
If the data is arriving but the reports still say "No data," the problem is archiving, not tracking. Under Administration → System → General Settings, Matomo decides whether reports get processed when you open them in the browser, or only by a scheduled job. Browser-triggered archiving is fine for a low-traffic test site; for production you want a cron job so reports stay fresh without hammering the UI. If you haven't set that up yet, here's how to set up Matomo cron archiving.
Verify it actually worked
Don't wait on the reports to tell you whether tracking is live; they lag behind archiving. Instead:
- Place a test order.
- Open Visitors → Visits Log for Today.
A correctly tracked order shows an Ecommerce icon and the order value right on that visit, the moment the call arrives, independent of archiving. That's your ground truth. If the order shows up in the Visits Log but the Ecommerce → Sales / Products report is empty, your problem is archiving (step 4), not tracking. If the order doesn't show up in the Visits Log at all, the call isn't firing, so go back to the success-page integration.
If you'd rather watch the wire, open DevTools → Network and filter for matomo.php. A tracked order sends a request carrying idgoal=0, the order id in ec_id, the total in revenue, and the line items in ec_items. No request, no order.
One more thing: run the test in a clean browser with ad blockers off and any consent banner dismissed or accepted. Otherwise you'll spend an afternoon debugging tracking code when the real culprit was a blocked request. If consent turns out to be a live concern rather than a test artifact, that's its own topic.
Keeping it from breaking again
Order tracking breaks quietly, and almost always on the success page. After any change to your Magento theme or checkout (a new payment method, a redirect tweak, a caching layer on the confirmation page), re-run a single test order and check the Visits Log. Thirty seconds of work that catches the regression before a month of orders goes missing.
If ad blockers or consent opt-outs are measurably costing you order data, move order tracking server-side. On the server you'd call the PHP tracker's doTrackEcommerceOrder() (the mode JaJuMa's extension exposes), or send a Tracking HTTP API request with idgoal=0, ec_id, revenue, and ec_items. Either one fires from your server when the order is actually placed, so it can't be blocked in the browser and doesn't depend on a JavaScript event surviving a redirect.
What we'd actually do
If you're on Magento and don't want to touch code, the JaJuMa extension is the fastest path; just go in knowing it's a paid extension, not a free add-on. If you'd rather not pay for one, Matomo Tag Manager gets you there without a license, and where there's already a data layer to read from, it's the route we'd reach for first. Either way, fire the order call server-side for anything that matters, because browser-side order tracking is the part that silently breaks.
And whichever route you take, the check is the same, and it's the habit worth keeping: place a test order, watch it land in the Visits Log, then trust the reports.
Martez connects Matomo with Meta Ads and Google Ads so ROAS, CLV, and attribution sit next to your web analytics instead of in a separate spreadsheet. It's in private beta. Join the waitlist if that's relevant.
Empty Ecommerce reports almost never mean Matomo is broken. They mean nobody's feeding it yet.