An ecommerce analytics dashboard is only useful if it shortens the distance between a number and a decision. Most store dashboards fail that test: they show twenty widgets, all of them technically accurate, and none of them tell you whether the problem this week is demand, visibility, the page itself, the checkout, or stock.
This guide sets out a structure that works in practice. Instead of a metric list, it treats a dashboard as six layers, and each layer answers one question. You will also see what each metric genuinely proves and where it goes quiet.
Start with the question, not the metric
Before choosing metrics, decide what the dashboard is for. Three common purposes need different views:
- Direction. Is the store growing, and where is the growth coming from? Weekly or monthly, few metrics, long time frames.
- Diagnosis. Something changed, where did it start? Layered metrics, shorter time frames, comparison against the previous period.
- Prioritisation. With limited capacity, what deserves work next? Page and product level, commercial context included.
A single screen rarely serves all three well. If your dashboard is currently a compromise between them, that is usually why nobody looks at it.
The six layers of a store dashboard
1. Demand: what people are searching for
Source: Search Console query data, plus keyword research where available.
What it tells you: whether interest in a product family exists and how it moves seasonally.
What it does not tell you: whether you can win it, or whether it converts. Impressions are not an audience you own.
2. Organic visibility: whether you are present
Metrics: impressions, clicks, click through rate and average position for key pages and query groups.
Read these together. A category with rising impressions and flat clicks is often a relevance or snippet problem rather than a ranking problem. Two practical constraints shape this layer: the Performance report holds 16 months of history, and the data is about two days behind, so a same day answer is not available here. Average position is an average, so treat a change of a few tenths as noise unless it persists.
3. Behaviour: what visitors do
Source: GA4. Metrics: sessions by landing page, engagement, product views, add to cart rate.
This layer explains whether the traffic you earned found what it expected. It is also where you catch the difference between a page that ranks and a page that works.
Two GA4 limits matter when you design this layer. On a standard property, event data retention is either 2 or 14 months, and 2 months is the default, so a year on year comparison is impossible unless somebody changed the setting. A standard property also allows up to 500 distinct event names, which is why loose event naming eventually breaks a dashboard.
If page experience is part of the story, use the published Core Web Vitals thresholds rather than an opinion: a good experience is a Largest Contentful Paint of 2.5 seconds or less, an Interaction to Next Paint of 200 milliseconds or less, and a Cumulative Layout Shift of 0.1 or less, measured at the 75th percentile.
One practical note: Search Console clicks and GA4 sessions will not match, and they are not supposed to. Different systems, different counting rules, consent handling and attribution windows. Use each for what it measures rather than trying to reconcile them.
4. Conversion: whether intent turns into orders
Metrics: conversion rate by landing page and by device, cart abandonment, checkout completion.
Segment it. A site wide conversion rate hides the fact that branded and non branded traffic behave very differently, and that a category page and a blog post are not supposed to convert at the same rate.
5. Revenue: what the business actually earned
Metrics: revenue, orders, average order value, revenue by product and category, and where possible margin.
Revenue is the anchor for prioritisation, but be careful with attribution. Organic search is often the first touch and the last touch for different customers, and a strong sales week can come from email or paid activity.
6. Stock and readiness: whether action makes sense
Metrics: stock status, restock timing, discontinued products, and products with variant coverage problems.
This is the layer most dashboards forget, and the one that prevents wasted work. Investing in visibility for a product you cannot ship is an expensive way to disappoint a customer.
Reading layers together: two short examples
Example one. A category has high revenue and weak organic visibility. That combination may indicate a real SEO opportunity: the products prove commercial value, but search is not contributing much. It is worth investigating before you assume causation, because the revenue may come almost entirely from paid traffic and repeat buyers.
Example two. A product page has strong impressions, weak click through rate and healthy conversion once people arrive. The bottleneck is probably presentation in search results, not the page itself. Titles, structured data and snippet relevance are the cheaper experiment here.
Both examples share a pattern: no single layer produced the insight. The comparison did.
Dashboard design mistakes worth avoiding
- Averaging everything. Site wide averages hide the segments where the money is.
- Mixing metrics that measure different things into one score, then trusting the score.
- No comparison period. A number without a reference point cannot signal change.
- Too many widgets. If a review takes an hour, it will not happen weekly.
- Vanity completeness. A dashboard is not a data warehouse. Leave the deep analysis to drill down views.
- No owner. A dashboard nobody is responsible for reviewing is documentation, not a workflow.
From dashboard to decision
A dashboard tells you something changed. A workflow decides what to do about it. The gap between the two is where most store teams lose time, because the dashboard is in one tool, the search data in another, and the commercial context in the store admin.
This is the problem Vistobi is built around. Search data tells you what people are looking for, analytics shows what visitors do, and commerce data shows what they buy. Vistobi connects those signals and prepares a prioritised shortlist for review, with the reasoning attached, so a human decides the action. Search Console and GA4 connect on every plan, and WooCommerce store context is part of the Commerce plan. You can see the exact scope in the plan comparison or in the Vistobi product overview.
If your next question is which pages to act on rather than which numbers to watch, the companion guide on what an ecommerce SEO tool should actually do covers the prioritisation side.
Actionable takeaways
- Decide whether your dashboard exists for direction, diagnosis or prioritisation, and build separate views if you need all three.
- Keep the six layers separate: demand, visibility, behaviour, conversion, revenue and stock. Comparison across layers is where insight comes from.
- Never expect Search Console and GA4 numbers to match, and never blend them into a single figure.
- Add stock readiness to your review. It is the cheapest way to avoid working on opportunities you cannot fulfil.
- Give the dashboard an owner and a fixed review slot, and keep it short enough that the slot is realistic.
More guides on connecting search, analytics and sales data are in the resources hub.