Published on : Sep 11, 2026

How to Find the Root Cause of a Sales Drop Using Data

A decomposition-first approach to finding what actually caused a sales decline, with SQL to isolate the driver

5 Minutes Read
Rutvik Acharya, Principal Data Scientist at Atlassian

Rutvik Acharya

Principal Data Scientist Atlassian

How to Find the Root Cause of a Sales Drop Using Data

How to Find the Root Cause of a Sales Drop Using Data

“Sales are down 12% this quarter” is a headline, not a diagnosis. It could mean fewer transactions, smaller transactions, a shift toward lower-margin products, or a single large account that churned. Each of those has a different fix, and none of them is visible from the topline number alone.

Root cause analysis for a sales drop starts by decomposing revenue, not by guessing at explanations. This article walks through that decomposition using a running example: Northfield Retail, a mid-size retailer whose CFO has flagged a quarter-over-quarter revenue decline and wants to know why before the next board meeting.


Step 1: Decompose the Drop Before Explaining It

Revenue is the product of volume and price, and both of those can be broken down further by channel, region, product line, or customer segment. Before forming a hypothesis about why sales dropped, the first job is figuring out exactly where the drop is concentrated.

Screenshot 2026-09-03 155138.png

A decomposition diagram breaking total revenue decline into volume and price components, each split further by channel and product line

For Northfield, that means checking questions like these before anyone proposes a cause:

  • Is the decline driven by fewer transactions (volume) or lower revenue per transaction (price or mix)?

  • Is it concentrated in one channel (in-store versus online), one region, or one product category?

  • Is it broad-based across most customers, or concentrated in a small number of large accounts?

A drop that is uniform across every channel and product line points toward something structural (a macro demand shift, a broad pricing change). A drop concentrated in one segment points toward something specific to that segment, which is a much narrower, faster investigation.


Step 2: Isolate the Segment With SQL

Once the decomposition question is clear, SQL can answer “where” quickly. A standard approach is comparing the current period to a prior period, sliced by the dimension being tested (channel, region, product), and computing both volume and revenue for each.

Plain text
-- Compare revenue and transaction volume by channel, current vs prior quarter (PostgreSQL syntax)
SELECT
    channel,
    quarter,
    COUNT(DISTINCT order_id) AS transaction_count,
    SUM(order_total) AS total_revenue,
    ROUND(SUM(order_total) / NULLIF(COUNT(DISTINCT order_id), 0), 2) AS avg_order_value
FROM orders
WHERE quarter IN ('2026-Q1', '2026-Q2')
GROUP BY channel, quarter
ORDER BY channel, quarter;

NULLIF() here prevents a divide-by-zero error if a channel had zero transactions in either period, which is a common edge case when a new channel launched partway through the comparison window. COUNT(DISTINCT ...) and SUM() follow standard aggregate behavior covered in the PostgreSQL aggregation functions documentation. Once this query runs, a period-over-period percentage change per channel, per product line, and per region isolates which slice is driving the aggregate decline rather than assuming it applies everywhere equally.

For a more direct period comparison in a single query, a window function avoids joining the same table to itself:

Plain text
SELECT
    channel,
    quarter,
    total_revenue,
    LAG(total_revenue) OVER (PARTITION BY channel ORDER BY quarter) AS prior_quarter_revenue,
    ROUND(
        100.0 * (total_revenue - LAG(total_revenue) OVER (PARTITION BY channel ORDER BY quarter))
        / NULLIF(LAG(total_revenue) OVER (PARTITION BY channel ORDER BY quarter), 0),
        1
    ) AS pct_change
FROM channel_quarterly_revenue;

LAG() and the PARTITION BY pattern used here follow the standard window function structure documented in the PostgreSQL window functions documentation, applied to a period-comparison problem instead of a running total or ranking.


Step 3: Categorize the Cause

Once the decline is isolated to a segment, the next step is figuring out which broad category of cause it falls into. Most sales declines trace back to one of four categories: demand-side (fewer or smaller orders from existing intent), supply-side (inventory, fulfillment, or availability issues), pricing or mix (higher prices or a shift toward lower-value items), or an external one-time factor (seasonality, a competitor promotion, a holiday calendar shift).

Screenshot 2026-09-03 155208.png

A decision flowchart routing a sales decline to demand, supply, pricing/mix, or external one-time causes based on what the segment-level data shows

For Northfield, if the decline is concentrated in the online channel with transaction volume down but average order value flat, that points away from pricing and toward either a demand-side issue (traffic or conversion) or a supply-side issue (stockouts on popular items). Checking whether flagship products showed reduced inventory availability during the decline window is a fast way to rule supply-side causes in or out before spending time on a demand-side investigation like traffic or conversion analysis.

If the decline instead shows flat transaction volume but falling average order value, that points toward pricing or mix, for example a shift toward promotional or lower-margin items, or a change in the product mix customers are buying. Distinguishing these two shapes (volume-driven versus value-driven) from the Step 2 query output is usually enough to rule out at least two of the four categories before any further investigation.


Step 4: Confirm Before Presenting

A plausible category is not the same as a confirmed cause. Before Northfield’s finding goes to the CFO, it needs a check against an obvious confound: did the prior-period comparison include an unusual event (a one-time bulk order, a promotional spike) that makes the “decline” partly an artifact of an inflated baseline rather than a genuine drop?

Comparing the affected segment against a longer trailing baseline, not just the immediately preceding quarter, helps rule this out. If the current quarter looks low only relative to an unusually strong prior quarter, but is in line with the trend from two or three quarters earlier, the framing of the finding changes substantially, from “sales are declining” to “sales returned to trend after a one-time high.” This is the same discipline covered more generally in the Gradient Learnings piece on why analytics projects fail: a conclusion that survives only one comparison point is not yet a validated finding.

Once the cause is confirmed, the recommendation should name the segment, the category of cause, and a specific next step, rather than restating the decline. “Online revenue is down 9%, driven by a volume drop concentrated in the outdoor gear category, coinciding with stockouts on the three highest-selling SKUs in that category. Recommendation: prioritize restocking those SKUs before evaluating a broader online demand investigation.” That framing mirrors the structure covered in the Gradient Learnings guide to presenting findings to senior leaders, which applies whether the finding is good news or, as with a sales drop, not.


Common Mistakes / Practical Checklist

  • Explaining the drop before decomposing it. A hypothesis formed before checking volume versus price, or before slicing by segment, risks fitting a story to a number that has a much narrower cause.

  • Comparing only to the immediately prior period. A single comparison point cannot distinguish a genuine decline from reversion after an unusually strong prior period.

  • Treating a uniform decline and a concentrated decline as the same investigation. They point toward structurally different categories of cause and different owners for the fix.

  • Skipping the divide-by-zero edge case in average order value or per-unit calculations when a new channel, region, or product line has incomplete data for one of the compared periods.

  • Assuming the first plausible category (demand, supply, pricing, external) is correct without checking the specific pattern in the data, such as whether volume or average order value is the component actually moving.

  • Presenting the segment and the category without a specific recommendation, which leaves the reader to infer what should happen next.


Where to Go From Here

This article assumes basic comfort with SQL aggregation, joins, and window functions for the period-comparison queries above. If SQL is the gap, SQL for data analysts: essential skills is the right starting point. For a sales decline that traces back to a conversion problem rather than a volume or pricing issue, for example fewer completed purchases relative to site visits, funnel analysis: finding where customers drop off covers that specific investigation in more depth. If the next step is narrating a sales drop investigation in an interview setting, how to explain a data analyst project in an interview covers how to structure that story concisely.


Quiz

TEST WHAT YOU LEARNED

Question 1 of 15

Q1: A CFO says “sales are down 12% this quarter.” According to the framework in this article, what should be checked first?

FAQ

FREQUENTLY ASKED QUESTIONS

Check whether the decline is driven by transaction volume, average order value, or both. This single decomposition step rules out or points toward entire categories of causes before any deeper investigation begins and should come before forming a hypothesis about why the drop happened.
Compare the percentage change in revenue for each segment, such as channel, region, or product line, against the overall percentage change. If most segments show a decline roughly in line with the total, the pattern is uniform. If one or two segments show a much larger decline than the rest, or decline while others are flat or growing, the pattern is concentrated.
Yes, and this is worth ruling out early, particularly if the drop appears suddenly and precisely at a date that coincides with a system migration, tracking change, or reporting pipeline update. Checking whether the drop appears consistently across independent data sources, such as payment processor records and an internal orders table, helps rule this out before investigating business causes.
Multiple declining segments do not necessarily share a cause, so it is still worth checking each segment individually rather than assuming one investigation covers all of them. In some cases, a shared external factor such as a macroeconomic shift or calendar effect does explain several segments at once, but this should be confirmed rather than assumed just because the timing overlaps.
This depends on how volatile the metric normally is and how seasonal the business is, so there is no fixed number of periods that applies universally. As a practical starting point, comparing at least three to four prior periods, rather than only the immediately preceding one, is usually enough to distinguish a trend from a one-time spike or dip.
Forecasting is a different problem: predicting what will happen next based on historical patterns rather than diagnosing why something that already happened occurred. Root cause analysis and forecasting often use overlapping data, but the analytical approaches and validation methods differ enough to warrant separate treatment.
Yes. When that happens, it may signal a broad-based demand issue affecting the whole segment or two independent causes overlapping in the same period, such as a stockout combined with a promotional price cut on remaining inventory. Checking whether the two components moved together or independently over several periods helps distinguish a shared cause from a coincidence.
Cross-check the decline window against a pricing or promotions calendar, if one exists. If no such record is available, compare the timing of the mix shift to product catalog changes, discontinued SKUs, or new product launches during the same period as an indirect check.
A demand-side cause means fewer customers wanted to buy at the current terms, whether from reduced traffic, lower conversion, or reduced repeat purchasing. A supply-side cause means customers wanted to buy but could not, typically due to stockouts, fulfillment delays, or reduced availability of specific products.
If the decline is concentrated in a small number of large accounts rather than spread across many smaller transactions, a customer-level churn or account-health investigation is usually a better fit than channel and product decomposition. Checking what percentage of the revenue decline comes from the top 10 or 20 accounts by revenue is a quick way to determine which approach applies.
It is worth considering, particularly for smaller segments or shorter time windows where normal period-to-period variability could produce what looks like a meaningful decline by chance. For high-volume aggregate revenue over a full quarter, variability may be small relative to a genuine double-digit percentage decline, but for narrower segments or shorter windows, checking against historical variability is a reasonable safeguard before treating the pattern as confirmed.
State the primary driver first based on its size of contribution, followed by secondary factors, rather than presenting a flat list of equally weighted causes. If an online-channel volume drop accounts for most of the decline and a smaller pricing shift accounts for the rest, lead with the volume drop and its recommended fix, then note the pricing shift as a secondary factor worth monitoring.
Yes. The same decomposition of volume versus price, sliced by segment, and the same category framework of demand, supply, pricing and mix, and external factors apply equally to understanding what is driving growth. This helps determine whether the growth is likely to continue or was driven by a one-time factor.
A tracking or pipeline issue can produce a pattern that looks identical to a genuine business decline. Investigating business causes for what is actually a reporting error wastes time and can lead to an incorrect recommendation being acted on. A quick cross-check against an independent data source is generally cheaper than a full business-side investigation that turns out to be unnecessary.
Skipping the decomposition step and jumping straight to a hypothesis, usually whichever explanation the stakeholder proposed first, is the most common failure mode. Decomposition narrows the space of plausible causes with data before anyone invests time chasing a specific explanation.