Revenue Dashboard Design Done Right: 5 KPIs and Templates by Business Model

"We built a revenue dashboard, but staring at it doesn't tell us what to do next." This is one of the most common frustrations I hear when talking with EC operators. The more charts, metrics, and filters you stack on, the more impressive the screen looks—but decisions actually get slower. A dashboard isn't about information density; it's a screen for deciding your next move in one minute, every week.

This article walks through the right way to think about revenue dashboard design, organized around a single principle: place the 5 KPIs by working backward from the revenue decomposition formula. We cover the recommended layout, templates by business model, common pitfalls, and how to choose between GA4 and BI tools (Looker Studio / Tableau / Power BI), all from a hands-on perspective. The design thinking itself is something you can grasp by reading. The genuinely hard part isn't the blueprint—it's keeping the screen in a state where, every week, you can break revenue out by channel and by new vs. returning, exclude bots, smooth over the unknown-source traffic, and decide your next move in one minute. We close with that.

This article in brief#

• All you need on a revenue dashboard is the 5 KPIs plus a channel-level RPS table. Revenue / AOV / RPS / CVR / Sessions across the top, with channel-level RPS stacked below—this layout moves your decision speed the most.
• Design isn't "add more metrics"; it's the act of cutting. BI tools let you put anything on screen, which is exactly why dashboards balloon to 20 metrics. Ask of every metric, "if this moves, does next week's plan change?" and keep only the ones you can answer yes to.
• You can build it. The weight is in re-assembling it every week. You can build it once in GA4 or a BI tool. But re-gathering the data by channel and by new vs. returning, excluding bots, and smoothing the unknown-source traffic by hand—week after week—piles up. We close by laying out that "keep it running" cost.

1. What a revenue dashboard is#

In short, the purpose of a revenue dashboard is not "observing" but "acting." If you only want to look at information, a report is enough; a dashboard is the screen that turns it into your next move.

A sales dashboard (or revenue dashboard) is defined as "a screen for making marketing and EC-operations decisions in one minute." For EC operators, the revenue dashboard that genuinely drives decisions is built on a layout of the following 5 KPIs plus channel-level RPS.

With this layout, one minute of glancing should reveal "which channel has the highest improvement priority this week." When you're tempted to add another metric, ask "if this metric moves, does next week's plan change?" and drop anything you can't answer yes to. That single rule dramatically tightens dashboard density.

For the definitions and relationships of the 5 KPIs themselves, see the separate article How to Design Marketing KPIs: 5 Metrics Derived from Revenue. This article focuses on how to lay those 5 KPIs out on a screen.

1.1 A dashboard exists to decide the next move in one minute#

The first thing to agree on in dashboard design is who uses it, in how many minutes, to decide what. In the EC field, three patterns are typical.

• Marketing lead: a weekly 30-minute review to identify the channels with the highest improvement priority
• EC operations staff: 5 minutes each morning to check yesterday's revenue and any anomalies
• Executives: a monthly check of the overall health of the business

The three differ in the time horizon and granularity they want to see. Cram all three people's needs into one dashboard and you get a screen nobody uses. Ideally you split into three screens by user, but if you're building the first one, a "weekly review screen" for the marketing lead works as the greatest common denominator.

1.2 "Showing numbers" and "deciding actions" are different functions#

A dashboard exists to decide actions, but in the field, "screens that only show numbers" get mass-produced. The two have different functions.

• A screen that shows numbers (a report): answers "what was last month's CVR?" Centered on aggregation and display
• A screen that decides actions (a dashboard): decides "which channel do we push next week?" Centered on comparison and anomaly detection

If you only need to show numbers, a spreadsheet is enough. A screen that decides actions must always have the comparison targets (prior week, prior month, other channels) co-located on screen. A "screen where only big absolute values are displayed" is a number-showing screen, not an action-deciding one.

2. The 5 KPIs to place on the dashboard#

In short, the metrics to place follow naturally from the decomposition "Revenue = Sessions × CVR × AOV." Making it a rule that you must articulate a reason whenever you place a metric that doesn't appear in this formula keeps the quality up.

2.1 The order of the KPI cards (5 cards)#

The 5 KPI cards are ideally arranged so that the reader can follow the logic of revenue decomposition by reading left to right.

Arranged in this order, the logic of decomposition lands in your head: from revenue (the outcome) to the size of an order (AOV), efficiency per visit (RPS), conversion rate (CVR), and visit volume (Sessions). Change the order and the meaning of the dashboard changes, so it's a design decision to agree on internally.

2.2 The channel-level RPS table—comparison is the heart of the dashboard#

The 5 KPI cards show "the overall temperature," but what decides action is comparison across channels. The channel-level RPS table is the de facto heart of a revenue dashboard.

The goal is to read this table as "Email's RPS is 3× the others, yet Email only has 3,100 sessions. Strengthening email is next week's priority"—so that a next-move candidate surfaces within one minute. A 20-column table makes that impossible to see.

One thing to watch here is attribution (which channel you assign revenue to). Aggregate with the last-click model alone and Direct or Organic Search show abnormally high RPS, while the contribution of awareness paths like Paid Social becomes invisible. That's because in a journey of "first awareness via Meta ads → return via search → purchase," last-click assigns 100% of the revenue to the final search. The safe approach for a channel-level RPS table is to compare two models, last-click and data-driven (or linear). The basics of attribution are covered in the separate articles GA4 Attribution Blind Spots and The Last-Click Trap.

2.3 The time-series chart is just two lines: revenue and RPS#

Plot all 5 KPIs on a time-series chart and the density gets so high you can't read anything. In practice, narrowing to two lines—revenue and RPS—is the greatest common denominator.

• Revenue: the outcome metric. The overall sense of the trend
• RPS: the leading indicator of site efficiency. It often moves ahead of revenue

CVR and AOV lead to action better in the channel-level table than in a time series. The time-series chart is a tool for reading "what happened in the last 4 weeks" and "is this year's seasonal peak coming again." Load more onto it and you only add noise.

2.4 Anomaly-detection thresholds—automating the health KPIs#

Placing "health-KPI alerts" along the top edge of the dashboard makes the weekly review more efficient.

• Bounce rate > 60% → warning
• Direct/(none) traffic > 30% of the total → warning
• A given channel's sessions drop > 30% week-over-week → warning

Switch the health KPIs to a "discuss only when an anomaly appears" workflow and you can concentrate on just the 5 KPIs. You can implement this with GA4's "Insights" feature or with conditional formatting in BI tools (Looker Studio / Tableau / Power BI). For why Direct/(none) grows in GA4, see the separate article 5 Causes of Rising GA4 Direct/(none) and How to Fix Them.

Note: read ROAS and gross margin on a "separate axis" If you're running ads, ROAS (revenue against ad spend) is on your mind too. But ROAS of 100% is not the break-even point. At a gross margin of 30%, break-even ROAS is 333% (formula: 1 ÷ gross margin), so even ROAS of 300% loses money. Japan's SMB EC (apparel / cosmetics / food D2C) clusters at gross margins of 30–50%, putting break-even ROAS at 200–333%. This is a separate "ad profitability" axis from the 5 KPIs, so rather than cramming it into the dashboard body, it's cleaner to read it on a separate panel when you look at ads. ROAS in detail is covered in the separate article The Complete Guide to the ROAS Formula.

3. Common pitfalls in dashboard design#

In short, a dashboard is a design artifact where the "narrow it down" step is overwhelmingly harder than the "build it" step. Here are the 4 patterns most common in the EC field.

3.1 Collecting too many metrics until it can't be read in one minute#

The most common failure. Out of a sense that "we should be data-driven," designs that cram 20–30 metrics plus 10 kinds of charts onto one screen get mass-produced. The moment you have to scroll to see the whole thing, you've left the dashboard's purpose (decide an action in one minute). The problem is that the more metrics you add, the vaguer "where do we start" becomes.

Remedy: Place the 5 KPIs plus channel-level RPS at the center, and carve everything else out into a separate "auxiliary-metrics tab." Make it a two-tier structure where the default screen shows only the 5 KPIs, and you open the tab only when you want to dig deeper.

3.2 Placing GA4's metrics on screen as-is#

You often see dashboards that just line up GA4's behavior metrics, as if someone pasted in GA4's report screen. GA4 is powerful, but by default it's optimized for behavior metrics (sessions, PV, bounce rate, time on page); revenue metrics (RPS, channel-level revenue efficiency) need separate design.

Put bounce rate or time on page on a revenue dashboard's KPI cards and next week's plan won't change even if they move. "Metrics you can measure" and "metrics that decide action" are different things.

Remedy: Demote GA4's behavior metrics to the "auxiliary-metrics tab." Keep the main screen to Revenue / AOV / RPS / CVR / Sessions only. RPS, which GA4 doesn't provide, you aggregate from your own session logs. GA4's limits and how to make up for them are organized in the separate article The Wall You Hit Even After Fully Utilizing GA4.

3.3 Last-click-biased channel breakdown#

When you build the channel-level RPS table, aggregating with the last-click model alone distorts your judgment. The typical pattern: Direct and Organic Search show abnormally high RPS, while the contribution of awareness paths like Paid Social disappears. Looking only at the channel-level RPS table leads you to the mistaken conclusion that "we should strengthen search only."

Remedy: In the channel-level RPS table, display two models—last-click and data-driven (or linear)—side by side. Channels where the two diverge significantly are evidence of large awareness contribution, so be cautious in your judgment.

3.4 Prioritizing a "good-looking screen" and making it hard to read#

A pattern where BI tools' (Tableau / Power BI / Looker Studio) high degree of freedom backfires. 3D pie charts, colorful heatmaps, ornate gauge charts. These look impressive but make comparison hard and numbers hard to read, so they're unsuited to deciding actions.

Remedy: Limit the basic elements to just 4 types—number cards, bar charts, line charts, and tables. Cap colors at 3—"warning (red)," "healthy (green)," "neutral (gray)." Document your legibility rules, like "row height 80px, key numbers in bold."

4. Dashboard templates by business model#

In short, the 5 KPIs and the basic layout are common to all EC operators, but the business model changes the arrangement and weighting. Here are the 3 representative patterns.

4.1 D2C / direct EC (Shopify / BASE / STORES)#

For D2C brands, the channel-level RPS table becomes the star of the screen. Because most traffic comes via ads, a layout that lines up RPS by channel is essential.

In D2C, the phenomenon that "if ad-driven RPS is lower than organic RPS, the site's overall revenue efficiency actually drops" occurs frequently. Maximizing the channel-level RPS table makes this structural pitfall visible on screen.

4.2 Subscription#

In subscription models, on top of the initial conversion, retention (churn rate) dominates business outcomes, so in addition to the 5 KPIs, show churn rate as an auxiliary metric on a monthly panel.

In subscription, the discerning point is "channels where you can get the ad conversion, but churn is high and it doesn't last." Comparing RPS against retention lets you evaluate ad quality on two axes: "short-term revenue efficiency" and "long-term stickiness."

4.3 Single-purchase (food, gifts, seasonal goods)#

In business types centered on single purchases, the efficiency of acquiring new customers is at the heart of business outcomes. Because the weight of AOV and Sessions is higher than in other types, the dashboard reflects that.

For single purchases, seasonal demand decides more than half of business outcomes, so always include year-over-year comparison on the dashboard. Week-over-week alone makes you misread the seasonal factor.

5. Tool comparison: GA4 and BI tools#

In short, the options for building a revenue dashboard split broadly into two families (GA4 + Looker Studio / general-purpose BI tools), and while both "can build it," the cost of "re-assembling it every week" remains.

5.1 The strengths and limits of GA4 + Looker Studio#

GA4 + Looker Studio is the go-to free combination. But to build a revenue dashboard, three extra tasks are needed every time.

1. Fixing the channel classification: GA4's default channel grouping isn't optimized for EC, and Direct/(none) tends to swell
2. Calculating RPS by hand: GA4 has no RPS metric, so you build "Revenue ÷ Sessions" with a calculated field in Looker Studio
3. Choosing the attribution: you need to consciously switch between last-click and data-driven every time

From setup to practical use, it takes 1–2 weeks if you have someone well-versed in design, and months of trial and error if you don't. And it doesn't end there. Even after you build it, this re-assembly continues every week.

5.2 The strengths and limits of BI tools (Tableau / Power BI)#

Tableau and Power BI have overwhelming expressive power and can implement complex aggregations and branching logic. But they carry the structural weakness that the load of designing from scratch is large, and they easily become person-dependent.

• When the BI person changes, the handover cost is large
• "I just want to add a metric" turns into a one-week wait on an engineer request
• License costs grow linearly with the number of users

For mid-sized-and-up EC operators with a full-time BI person, it's the strongest option, but for SMBs (¥100M–1B in annual revenue) the operational load is often too heavy—that's the sense on the ground. For a comparison of heatmap and analytics tools, the separate article Complete Comparison of Heatmap Tools covers a similar theme.

5.3 The shared wall isn't "building" but "keeping it running"#

With either tool, you can build the dashboard once. The real wall is whether you can keep re-assembling it every week at the same quality. Concretely, this manual work piles up every week.

• Re-aggregate revenue and sessions by channel and by new vs. returning
• Exclude automated-program (bot) traffic (skip it and RPS looks better than reality)
• Smooth the revenue mixed into the unknown source (Direct/Unattributed) so it becomes visible
• Switch between last-click and data-driven to check the attribution distortion

Keeping a person turning this by hand every week is heavier work than you'd imagine. Between "you can build it" and "you can keep it in a state where, re-assembled every week, you can produce the next move without hesitation," there's a big step down.

RevenueScope — the solution

As we've seen, the blueprint itself—the 5 KPIs plus channel-level RPS—isn't hard. You "can build it" in GA4 or a BI tool. The real wall is in keeping a single screen running where, every week, you can produce the next move without hesitation by channel × revenue. The weekly re-assembly by hand, RPS distorted by bot contamination, being undervalued because revenue is buried in the unknown source—this is what's structurally heavy.

RevenueScope takes over that "keeping it running." It breaks out the 5 KPIs—Revenue, AOV, RPS, CVR, Sessions—by channel, by new vs. returning, and by device, excludes bots, carves out the unknown source (Unattributed), and puts it all on one screen (figures shown are demo data). Switching the attribution model (last-click ⇄ data-driven) can also be done on screen.

What's worth reading in this table is that Email's RPS (¥420) is the highest yet its sessions are only 3,100, and that ¥1,440,000 of revenue is buried in "unknown source." RevenueScope separates out this unknown source, excludes bots, and tidies it into revenue order—and re-assembles it every week. Instead of a "built 20 metrics that nobody looks at" state, or a "built it but can't re-assemble it weekly and it stalls" state, this is a screen for keeping you in a state where you look at the 5 KPIs every week and the next move gets decided.

What RevenueScope re-assembles every week is the 5 KPIs—Revenue, AOV, RPS, CVR, Sessions—broken out by channel, by new vs. returning, and by device. Because it specializes in revenue-based metrics, it delivers a single screen sorted by revenue—bots excluded, the unknown source carved out—consistently, week after week. Connect your ad spend and it carries straight through to the actual measured ROAS, saturation, and a budget-allocation guide. RevenueScope puts the material for your next move in your hands, re-assembled every week.

FAQ#

Frequently asked questions#

Q. Can I build a revenue dashboard with just GA4 and Looker Studio?

A. You can. Connect GA4's data to Looker Studio, fix the channel classification, build RPS as a calculated field with "Revenue ÷ Sessions," and you can build the 5-KPI screen. But the hard part isn't building it—it's "re-assembling it every week." Every week you re-aggregate the data by channel, exclude bots, smooth the unknown source, and switch between last-click and data-driven to check. This manual work gets heavier with each round.

Q. Aren't more metrics on a dashboard better?

A. It's the opposite. The more metrics you add, the vaguer "where do we start" becomes, and decision speed drops. The criterion is "if this metric moves, does next week's plan change?" Any metric you can't answer yes to gets pulled off the main screen and demoted to an auxiliary tab. Start by narrowing to the 5 KPIs—Revenue, AOV, RPS, CVR, Sessions—plus channel-level RPS, which leads to action the most.

Q. My channel revenue skews toward Direct and unknown source. What should I do?

A. When the unknown source (Direct/Unattributed) swells, revenue that another channel actually generated gets buried, and your RPS comparison distorts. The cause is often broken UTMs or attribution settings, so the basics start with tidying up the channel classification and UTMs. On top of that, you need to carve out the unknown-source portion, smooth it, exclude bots, and arrange it in revenue order. Turning this "carve-out" by hand every week is the heavy part, and one option is to use an analytics tool that assembles it automatically.

Conclusion#

What belongs on a revenue dashboard is the 5 KPIs—Revenue, AOV, RPS, CVR, Sessions—plus channel-level RPS. The more metrics you add, the slower decisions get, so the essence of design is "the act of cutting." The order and weighting shift by business model, but the goal—"decide the next move in one minute"—is common.

And here's the most important part. The blueprint itself is something you can grasp by reading. You can build it once in GA4 or a BI tool. But what's genuinely hard is keeping it in a state where, every week, you re-assemble the data by channel and by new vs. returning, exclude bots, smooth the unknown source into revenue order, and produce the next move without hesitation. The reason so many dashboards stall after being built is that there's a step down right here. First build a single screen narrowed to the 5 KPIs, then watch whether the operation of re-assembling it every week actually runs. Once that starts running, the dashboard changes from a "screen you stare at" into a "screen where, every week, the next move gets decided."

References#

• [1] Google Analytics Help "Default channel group" (2024)
• [2] Google "Looker Studio overview" (2024)
• [3] Tableau "What is a dashboard? A complete overview" (2024)
• [4] Microsoft "Power BI documentation - Dashboards" (2024)
• [5] Harvard Business Review "Identify the Marketing Metrics That Actually Matter" (2015)