How Dashboards Turn Questions into Data Analysis for Business Decisions

Dashboards are useful when working through large amounts of data, but they’re not just a collection of metrics for their own sake. 

They’re a way to visualize data and make sense of it by answering specific questions. A network NOC dashboard answers very different questions than a product team’s Mixpanel dashboard, which in turn differs from a financial dashboard. There isn’t a single “right” dashboard, metric, or visualization – they’re tools used to answer questions in meaningful ways.

Well-designed dashboards surface assumptions, expose trade-offs, and constrain conclusions while decisions are still being formed. With the arrival of dashboards in the March release of gdotv, it’s time to discuss why they’re important but also to dissect what makes a dashboard an effective data analysis tool.

This post uses the Northwind dataset in Neo4j to demonstrate how dashboards can be used to reason through a business question step by step. Rather than starting with a predefined answer or a complex model, the goal is to show how a small number of carefully chosen visuals can narrow uncertainty, challenge intuition, and guide decision-making as the analysis unfolds.

We begin with a simple question: “When does adding a discount increase total revenue and when does it not?”

git clone https://github.com/storbeck/neo4j-northwind
cd neo4j-northwind

cp .env.example .env
# edit .env and set NEO4J_PASSWORD=yourpassword
docker compose up -d

MATCH (o:Order)-[od:ORDERS]->(p:Product)
RETURN o,od,p
LIMIT 10

MATCH (o:Order)-[od:ORDERS]->(:Product)
WITH
  o.orderID AS orderID,
  sum(toFloat(od.unitPrice) * toInteger(od.quantity) * (1 - toFloat(coalesce(od.discount,'0')))) AS netRevenue,
  max(CASE WHEN toFloat(coalesce(od.discount,'0')) > 0 THEN 1 ELSE 0 END) AS hasDiscount
RETURN
  CASE WHEN hasDiscount = 1 THEN 'Discounted' ELSE 'No Discount' END AS orderType,
  avg(netRevenue) AS avgNetRevenuePerOrder
ORDER BY orderType;

MATCH (o:Order)-[od:ORDERS]->(:Product)
WITH
  o.orderID AS orderID,
  sum(toInteger(od.quantity)) AS totalUnits,
  max(CASE WHEN toFloat(coalesce(od.discount,'0')) > 0 THEN 1 ELSE 0 END) AS hasDiscount
RETURN
  CASE WHEN hasDiscount = 1 THEN 'Discounted' ELSE 'No Discount' END AS orderType,
  avg(totalUnits) AS avgUnitsPerOrder
ORDER BY orderType;

MATCH (o:Order)-[od:ORDERS]->(:Product)
WITH
  o.orderID AS orderID,
  toFloat(coalesce(od.discount,'0')) AS d,
  sum(toInteger(od.quantity)) AS totalUnits
WITH
  CASE
    WHEN d = 0 THEN '0%'
    WHEN d <= 0.05 THEN '5%'
    WHEN d <= 0.10 THEN '10%'
    WHEN d <= 0.15 THEN '15%'
    WHEN d <= 0.20 THEN '20%'
    ELSE '25%+'
  END AS discountLevel,
  CASE
    WHEN d = 0 THEN 0
    WHEN d <= 0.05 THEN 5
    WHEN d <= 0.10 THEN 10
    WHEN d <= 0.15 THEN 15
    WHEN d <= 0.20 THEN 20
    ELSE 25
  END AS sortOrder,
  totalUnits
WITH discountLevel, sortOrder, avg(totalUnits) AS avgUnitsPerOrder
ORDER BY sortOrder
RETURN discountLevel, avgUnitsPerOrder;
 

By comparing each product’s discounted performance against its own no-discount baseline, it becomes clear that only a subset of products actually benefit from discounting at all. For most products, maximum revenue is achieved at 0% discount.

Here’s the Cypher query so you can see for yourself. 

Revenue Lift (Table):

MATCH (:Order)-[od:ORDERS]->(p:Product)
WITH
  p.productName AS product,
  toFloat(coalesce(od.discount,'0')) AS d,
  toFloat(od.unitPrice) AS unitPrice,
  toInteger(od.quantity) AS quantity
WITH
  product,
  CASE
    WHEN d = 0 THEN '0%'
    WHEN d <= 0.05 THEN '5%'
    WHEN d <= 0.10 THEN '10%'
    WHEN d <= 0.15 THEN '15%'
    WHEN d <= 0.20 THEN '20%'
    ELSE '25%+'
  END AS band,
  (unitPrice * quantity * (1 - d)) AS netRevenue
WITH product, band, sum(netRevenue) AS bandRevenue
WITH product, collect({band: band, revenue: bandRevenue}) AS rows
WITH
  product,
  head([r IN rows WHERE r.band = '0%']) AS baseline,
  [r IN rows WHERE r.band <> '0%'] AS discountedRows
UNWIND discountedRows AS r
WITH
  product,
  baseline.revenue AS baselineRevenue,
  r.band AS band,
  r.revenue AS revenue
ORDER BY product, revenue DESC
WITH
  product,
  baselineRevenue,
  collect({band: band, revenue: revenue}) AS ranked
RETURN
  product,
  baselineRevenue,
  ranked[0].band AS bestDiscountBand,
  ranked[0].revenue AS bestDiscountBandRevenue,
  (ranked[0].revenue - baselineRevenue) AS bestRevenueLift
ORDER BY bestRevenueLift DESC;
 

From Data Analysis to Dashboard

In this section, I’ll briefly explain how I chose the charts above and which alternatives were considered as I put together the larger dashboard in gdotv.

This dashboard above (and marked in groups below) was not designed to display everything the data could possibly show. 

Instead, I designed it to answer a small number of specific business questions as clearly as possible. Each chart exists because it resolves a particular ambiguity or prevents a common misinterpretation, not because the data visualization itself is novel or visually dense. Let’s break it down, group by group.

Group 1: Do Discounts Change Behavior?

The first group of charts in this dashboard establishes context. These charts answer the most basic questions an executive is likely to ask: What happens, in general, when we apply discounts?

By comparing discounted and non-discounted orders at an aggregate level, these views confirm that discounts do influence behavior. Orders with discounts tend to be larger, and at first glance, can even appear to generate more revenue per order. These charts are placed at the top left to ground the rest of the dashboard in basic knowledge which we will then break down further.

Group 2: Where Do Discounts Stop Paying Off?

The second group of charts (shaded in green above) introduces specifics. Rather than treating discounting as a binary choice, these charts show how outcomes change as discounts increase.

Here, I chose line charts to reveal patterns that bar charts would take longer to visually interpret. Order quantity rises steadily with higher discounts, while revenue efficiency peaks early and then declines. The dashboard viewer can see that the same mechanism driving larger orders also erodes value past a certain point.

This group of charts exists to correct the oversimplification in Group 1. It shows that “discounted vs non-discounted” is helpful but over-simplified, and that discount level matters.

Here’s the Cypher query to recreate the chart in the top right corner of the dashboard above.

Net Revenue per Unit (Line Chart):

MATCH (:Order)-[od:ORDERS]->(:Product)
WITH
  toFloat(coalesce(od.discount,'0')) AS d,
  toFloat(od.unitPrice) AS unitPrice,
  toInteger(od.quantity) AS quantity
WITH
  CASE
    WHEN d = 0 THEN '0%'
    WHEN d <= 0.05 THEN '5%'
    WHEN d <= 0.10 THEN '10%'
    WHEN d <= 0.15 THEN '15%'
    WHEN d <= 0.20 THEN '20%'
    ELSE '25%+'
  END AS discountLevel,
  CASE
    WHEN d = 0 THEN 0
    WHEN d <= 0.05 THEN 5
    WHEN d <= 0.10 THEN 10
    WHEN d <= 0.15 THEN 15
    WHEN d <= 0.20 THEN 20
    ELSE 25
  END AS sortOrder,
  (unitPrice * quantity * (1 - d)) AS netRevenue,
  quantity
WITH
  discountLevel,
  sortOrder,
  sum(netRevenue) / sum(quantity) AS netRevenuePerUnit
ORDER BY sortOrder
RETURN
  discountLevel,
  netRevenuePerUnit;
 

Group 3: Which Products Benefit from Discounting?

The third group in the dashboard (shaded in red) shifts from patterns to decisions. Once the general behavior is understood, the question naturally becomes: Which products should we discount?

This section replaces charts with a table because precision matters more than pattern recognition. Each product is evaluated against its own no-discount baseline, showing the discount level that produced the highest observed revenue for that product and the resulting lift. 

The key insight emerges when most of those revenue lifts are negative. Even at their best-performing discount, most products generate less revenue than they do at full price.

Group 4: What Happens If We Change the Discount Policy?

The final group (shaded in pink above) looks forward. Rather than asking what has happened, it explores what could happen under different discount rules.

By holding customer behavior constant and applying alternative discount policies, this view makes the long-term cost of discounting visible over time. It does not predict the future, but it illustrates the mechanical consequences of different strategies. This allows executives and decision-makers to reason about policy changes before committing to them.

If you’re following along, here’s the Cypher query to make it for yourself.

Predicted Revenue over Time with Discount Modifications (Line Chart):

MATCH (o:Order)-[od:ORDERS]->(p:Product)
WITH
  date(substring(o.orderDate, 0, 10)) AS d,
  p.productName AS product,
  toFloat(od.unitPrice) AS unitPrice,
  toInteger(od.quantity) AS quantity,
  toFloat(coalesce(od.discount,'0')) AS discount
WITH
  date.truncate('month', d) AS month,
  (unitPrice * quantity) AS gross,
  discount,
  product
WITH
  month,

  // 1) actual net revenue
  gross * (1 - discount) AS actualNet,

  // 2) cap any discount > 5% down to 5%
  gross * (1 - CASE WHEN discount > 0.05 THEN 0.05 ELSE discount END) AS capped5Net,

  // 3) cap everything at 0%, except winners (cap them at their best band)
  gross * (1 - CASE
    WHEN product = 'Mishi Kobe Niku' THEN CASE WHEN discount > 0.25 THEN 0.25 ELSE discount END
    WHEN product = 'Chocolade' THEN CASE WHEN discount > 0.15 THEN 0.15 ELSE discount END
    WHEN product = 'Gravad lax' THEN CASE WHEN discount > 0.20 THEN 0.20 ELSE discount END
    WHEN product = 'Escargots de Bourgogne' THEN CASE WHEN discount > 0.20 THEN 0.20 ELSE discount END
    ELSE 0
  END) AS winnersOnlyNet

RETURN
  month,
  sum(actualNet) AS actualRevenue,
  sum(capped5Net) AS revenueIfCappedAt5,
  sum(winnersOnlyNet) AS revenueIfOnlyWinnersDiscounted
ORDER BY month;
 

Why the Ordering of This Dashboard Matters

So why did I choose this particular order and grouping for our example dashboard? 

In left-to-right reading cultures, users often begin scanning at the top-left of a page and move across and downward. Dashboards are no exception. Because layout strongly influences how information is perceived, I structured this dashboard to align with that common scanning pattern.

This structure reflects a broader principle: Dashboards are most effective when they guide the reader through a sequence of questions, not when they attempt to answer everything at once. The structure also highlights an important cross-cultural design consideration: if the native reading direction of the target audience is right-to-left, the same logic applies, but the layout should be mirrored to match how those users naturally scan information.

What This Data Analysis Means for a Discount Strategy

Three conclusions emerge from the data analysis in our example dashboard:

1. Discounts do increase quantity, but quantity alone is a poor proxy for success. Larger orders can mask declining revenue efficiency, making discounting appear beneficial when it is not.
2. Modest discounts around 5% tend to perform best on average, but this result is often misunderstood. In most cases, these discounts do not increase revenue; they simply minimize revenue loss compared to deeper discounts. A 5% discount is frequently the least damaging option, not a reliably profitable one. In other words, “best-performing” does not mean “value-creating.”
3. Most importantly, discounting is a product-specific decision. The majority of products generate their highest revenue at full price and should not be discounted at all. A small subset of products does respond positively to discounting, sometimes requiring deeper discounts to unlock additional demand, but these cases must be identified and managed individually.

These conclusions didn’t merge from any single chart. They came from combining relevant metrics to narrow decisions, guided by the underlying question driving the dashboard.

Whether your dashboard is meant to show which business locations are performing best, which product features are gaining traction, or how revenue is trending over time – it should be built to serve you. Here at gdotv we’ve provided a variety of panels to help you explore and answer those questions against your database.

Use gdotv Dashboard Panels

With the introduction of dashboards in gdotv (release notes here), this data analysis also serves as a practical example of how different panel types can be used to answer specific business questions. Here are a few example dashboards in gdotv that include the panel types discussed below.