Diagnostic Analytics: Trace a Sales Drop
An online store ends the week with fewer orders, even though its website received the same number of visits. A sales leader asks whether the new campaign attracted the wrong people. The product team points to a recent checkout change. Customer service has heard complaints about delivery estimates. Each explanation is plausible, and each suggests a different expense. The useful question is not which story sounds most convincing. It is where the loss occurred, what else changed at the same time, and which explanation still fits after the numbers are separated.
Diagnostic analytics is the work of investigating why an observed result changed. It starts with a defined event or trend, then examines the records, relationships, and operational context that could explain it. IBM describes the field as using historical data and techniques including drill-down, correlation analysis, and statistical modeling to investigate patterns behind outcomes in its overview of diagnostic analytics. The result should be a better decision about what to check or change, with a clear account of what remains uncertain.
Start with the result that needs an explanation
“Sales are down” is too broad to investigate well. Sales can fall because fewer people arrived, fewer visitors ordered, orders contained fewer items, prices changed, or more orders were refunded. Even a correctly calculated revenue figure cannot tell a manager which of those happened. The first job is to specify the measure, its denominator, its time window, and the comparison that made the change noticeable.
For example, a useful problem statement might be: “Completed orders per 1,000 website visits fell during the week after a campaign launch, compared with the preceding week.” That sentence identifies a rate rather than a total, says what counts as an order, and names the two periods. It still needs details: Are visits sessions or distinct people? Are cancelled orders excluded? Did the tracking definition change? Those questions matter because a difference in measurement can look like a difference in customer behavior.
The comparison period deserves as much care as the current period. Comparing a holiday week with an ordinary week may turn a predictable timing effect into an apparent problem. Comparing a partial day with a full day is worse. If the business usually reports by calendar week, use complete weeks and retain the daily figures so that a one-day disruption does not disappear inside the total. The point is to create a fair description of the change before looking for a cause.
This is where diagnostic work separates from the other common analytics questions. A descriptive report says what happened; a forecast estimates what may happen next; an optimization exercise considers what action to take. Diagnostic analytics asks what might explain a result that has already been observed. IBM places those four questions in the same analytics lifecycle. They can inform one another, but a forecast of next month’s orders does not by itself explain last week’s decline.
Make sure the change is in the business, not the records
Before dividing a metric into segments, check how it was assembled. If a checkout event stopped firing, an order dashboard may fall while payment records do not. If a new sales channel was added to revenue but not to the prior comparison, growth can be exaggerated. If one system records refunds on the purchase date and another records them on the refund date, both may be internally consistent yet tell different stories about a short period. These are possible data problems, not claims about any particular company.
I would reconcile the headline figure to the most direct operational record available: orders against completed transactions, support complaints against ticket records, or shipment delays against dispatch timestamps. I would then check missing values, duplicate identifiers, late arriving records, and changes in definitions. This preparation is part of the analysis because poor quality or incomplete data can mislead the interpretation, a limitation identified in IBM’s discussion of diagnostic analytics and its account of data-informed decisions.
The unit of analysis also needs to match the question. A table with one row per order can answer questions about orders, but it cannot calculate a visitor conversion rate without a reliable count of visitors who did not order. A table with one row per customer may hide repeated visits. Joining order, campaign, and support tables without checking their keys can multiply rows and inflate totals. A quick check that totals before and after each join agree can prevent hours of explaining a change that the join itself created.
Keep the original values as well as the cleaned version. If a missing delivery date is replaced with an assumed value, the assumption should remain visible. If records are excluded because they arrived late, note how many and why. A neat dataset can be less trustworthy than a messy one when its missing pieces have been silently removed. IBM’s customer analytics guidance emphasizes that customer information can come from transactions, feedback, support, and other interactions; bringing those views together is useful only when their context is preserved.
Follow the loss from the total into its components
Once the measure is sound, break it into the parts that can account for the change. For an online store, orders can be viewed as visits multiplied by the share of visits that produce an order. Revenue adds another component: the average value of those orders. A decline in orders with stable visits points toward conversion or a change in the kinds of visitors. A decline in revenue with stable orders points toward order value, product mix, refunds, or price. This arithmetic does not find a cause, but it prevents a team from investigating the wrong part of the business.
Next, compare like with like. An aggregate can move even while every underlying group stays steady. Consider a purely illustrative store with 10,000 visits in each of two weeks. In the first week, 6,000 visits came from new visitors and 2% of them ordered, yielding 120 orders. The other 4,000 visits came from returning visitors and 7% ordered, yielding 280. The store recorded 400 orders overall, or 4% of visits.
In the second illustrative week, 8,000 visits came from new visitors and 2% ordered, yielding 160. Returning visitors accounted for 2,000 visits and still ordered at 7%, yielding 140. The store recorded 300 orders overall, or 3% of visits. Each group’s conversion rate remained exactly the same. The overall rate fell because the mix shifted toward the group with the lower rate. Calling this a checkout failure would send the team to the wrong place.
The example still does not tell us why the mix changed. A campaign might have attracted more first-time visitors; an email program might have reached fewer returning customers; a change in visitor identification might have relabeled people. The next useful comparison is between traffic source, campaign timing, and identification rules, with the relevant owners involved. If the campaign caused the shift, the business must decide whether more new visitors are valuable despite a lower immediate order rate. A diagnostic conclusion should retain that decision context rather than treating every lower rate as a defect.
Drill-down analysis works in the same way for other outcomes: from company to region, from region to store, from store to product; or from all support tickets to issue, channel, and day. IBM describes drill-down as moving from an aggregate into more detailed layers. The best slice is one tied to a plausible mechanism. Do not make dozens of cuts simply because a dashboard permits them. With enough small groups, some will look extreme by chance, while others will have too few observations to guide a decision.
A useful segment comparison preserves both the rate and its base. “Returns rose to 10%” means something different for 10 purchases than for 10,000. Likewise, the segment that accounts for the largest number of lost orders may not have the largest percentage decline. If a large product category drops modestly and a tiny category collapses, the large category may explain more of the total change. The numerator, denominator, and contribution to the overall difference belong together.
Choose a method that fits the question
There is no single diagnostic analytics technique that works for every change. The question and the available information should determine the method. IBM’s diagnostic analytics overview lists correlation, drill-down, regression, hypothesis testing, and time series methods among the options; its root-cause guide likewise describes several ways to investigate an event. A method is useful when it narrows a real uncertainty, not when its name makes the analysis sound sophisticated.
If the outcome changed abruptly, build a timeline. Put the first abnormal observation beside launches, staffing changes, supplier changes, promotions, price changes, and known incidents. The order of events can eliminate explanations: a checkout release made after the decline began cannot explain the start of that decline. Timing alone still leaves other possibilities, such as a seasonal shift or a simultaneous campaign. A timeline is a disciplined way to ask better questions, not a substitute for comparing the affected and unaffected records.
If a metric has a regular cycle, look at comparable points in that cycle. A weekend order rate should be compared with other weekends before it is compared with an average weekday. If the business has a longer history, separating a broad trend from seasonal movement may expose a genuine break that a raw chart hides. IBM includes time series decomposition among diagnostic techniques. I would use it when repeated timing patterns are plausible and enough history exists to estimate them; I would avoid treating a short, irregular series as if it had a stable seasonal pattern.
If two measures move together, examine the relationship and its possible alternatives. A support team may observe that accounts with more tickets also cancel more often. That relationship could mean unresolved problems contribute to cancellation. It could also arise because customers near cancellation contact support more often, or because large accounts both file more tickets and have more opportunities to cancel. Correlation helps locate a question; it cannot choose among those explanations. IBM explicitly cautions that a detected correlation does not always establish cause and effect.
Regression or a comparable statistical model can help when several measured factors change together. For instance, a team might compare order rates while accounting for visitor type, campaign, and device. Such a model can show whether an association remains after those recorded differences are considered. It cannot account for a missing factor merely because the output includes a precise coefficient. I would reach for modeling after the metric definition, segment counts, and time sequence are understood. Otherwise, an impressive result may only disguise a basic measurement error.
For a repeated operational failure, structured root-cause work brings in information that a transaction table may not contain. Suppose late shipments cluster around a warehouse handoff. The records can locate the delay, while dispatch logs and conversations with the people who handle orders can clarify whether stock was unavailable, scanning stopped, or a policy held orders for review. IBM describes root-cause analysis as a structured search for underlying contributors rather than a treatment of symptoms. The aim is to find a change that addresses the recurring condition, not merely to give the condition a label.
Anomalies deserve a similar distinction. An unusual spike in refunds may signal a product issue, a promotional return window, a reporting backlog, or a single large account. Flagging the point is valuable because it directs attention. The next step is to inspect the underlying records and the timing, then decide whether the point belongs to the business process being studied. An outlier should not be deleted simply because it makes a chart less tidy.
Use customer, operational, and financial context together
Diagnostic questions rarely stay inside one department. If cancellations rise, a customer team may see the cancellations, a support team may see complaints, and a product team may see feature use. IBM describes customer analytics as drawing on interactions such as purchase history, feedback, and support information. Joining those views can show whether the change is concentrated among customers who encountered a particular experience. It can also reveal gaps: a customer with no support ticket may still have had a problem, and survey respondents are only the people who answered.
The same reasoning applies to operations. A delivery dashboard can locate the day a service level slipped, but warehouse timestamps may reveal whether orders waited before picking, during packing, or after carrier handoff. That distinction changes the action. Adding packers is a poor response if parcels spent the extra time waiting for stock; pressing a carrier is a poor response if parcels never left the warehouse. The useful outcome is a bounded explanation attached to a point in the process where someone can intervene.
Financial figures have their own traps. A fall in revenue may reflect fewer purchases, smaller baskets, discounts, or refunds. Even when the arithmetic identifies the largest contributor, a manager needs context about why it changed and whether the change was intended. A promotional discount can reduce revenue per order while increasing new customer acquisition. Without the campaign goal, a diagnostic report could recommend reversing a deliberate trade-off. IBM’s account of data-driven decisions places analysis alongside business objectives and interpretation; the choice cannot be delegated to a chart.
The same report can serve several teams if it distinguishes shared facts from local decisions. Everyone should agree on the date of the change and the count behind it. The marketing team may then ask whether acquisition quality changed, the product team whether a new release affected a step, and the finance team whether the margin impact justifies intervention. Those are different questions about one event. Keeping the common measurement stable allows the explanations to be compared instead of argued from incompatible dashboards.
Treat a plausible explanation as a hypothesis
Diagnostic analytics often ends with several credible contributors rather than one proved cause. A disciplined team writes each candidate in a form that can be checked. “The new campaign attracted visitors less likely to order on their first visit” predicts a shift in visitor mix, stable within-group rates, and a timing match with the campaign. “The checkout release caused the loss” predicts a drop at or after release, concentrated in the affected path, with a corresponding increase in failures or abandonment. The hypotheses suggest different records to inspect.
Ask what would count against a favored explanation before running another chart. If order rates fell before the release, the release is unlikely to explain the start. If an unaffected device shows the same drop as the supposedly affected device, the device-specific theory weakens. If a product issue is the candidate, returns or complaints should at least be examined at the product level and after the relevant purchase. The point is not to force certainty; it is to make the strength of each explanation visible.
Be especially careful with before-and-after comparisons. When price, advertising, inventory, and season all change within a week, an outcome that followed one change cannot automatically be attributed to it. An affected group can sometimes be compared with a credible unaffected group, but the groups must have been comparable for the question at hand. A controlled test may be possible for a planned change. For a past incident, logs, timing, process knowledge, and repeated patterns may support a narrower conclusion. IBM notes the causal limit of correlations in diagnostic analytics; no dashboard can remove that limit by renaming a relationship a “driver.”
Root-cause language can also overstate what was learned. A shipment delay may have several necessary contributors: an inaccurate stock count, a handoff that failed to flag it, and a review queue without enough coverage. Naming only the last person to touch the order would confuse the visible symptom with the conditions that allowed it. IBM’s root-cause guidance allows for multiple underlying causes and calls for actions aimed at preventing recurrence. A useful account names the contributing conditions and the part each played.
Let the decision determine how far to investigate
Not every uncertainty is worth eliminating. If a metric is wrong because a tracking event broke, correct the measurement before launching a customer campaign. If two plausible explanations call for the same inexpensive, reversible fix, the team may be able to act while monitoring the result. If they call for costly and opposing actions, the missing distinction is worth more investigation. The standard of confidence should rise with the cost and irreversibility of the decision.
For the illustrative store, I would first confirm that order and visit counts are real, then verify that the new and returning visitor labels stayed consistent. If both checks pass, the segment arithmetic supports a narrow statement: the overall conversion decline is explained by the changed mix in those two groups. I would then ask why the mix changed and whether the business expected that change. I would not order a checkout redesign on the evidence given. The cost of this path is time spent reconciling traffic and customer definitions before making a visible product change; the benefit is avoiding an intervention aimed at the wrong part of the funnel.
If the same store instead showed a large within-group decline beginning with a checkout release, I would change the priority. The immediate question would be which checkout step or device was affected and whether the payment record agrees with the website events. That finding could justify a targeted rollback or fix, depending on the operational risk and the strength of the timing and failure records. The conclusion would remain specific: a change in a measured path and a plausible mechanism, not a universal claim that every customer was affected.
A short decision note is often more useful than a long dashboard. It should say what changed, which records were checked, the leading explanation, what would disconfirm it, the action proposed, and what result will be watched afterward. IBM’s decision-making guidance connects analysis with objectives, implementation, and later evaluation. The follow-up matters: if the metric does not move as expected after an intervention, the explanation or the intervention needs another look.
Choose tools for the size of the question
A spreadsheet can be enough for a small, well-formed table. Microsoft says Excel’s Analyze Data feature can surface summaries, trends, patterns, and suggested questions, with charts and PivotTables for further exploration in its product guidance. That can help someone notice a surprising category or date. The feature works best with clean tabular data and clear column headers, according to the same guidance. A generated chart still depends on the input table and on a person who understands what the columns mean.
When the question spans many records or systems, a repeatable query and a shared dashboard may be more practical. The priority is traceability: can another person reproduce the order count, the segment definition, and the comparison period? A more elaborate platform will not fix inconsistent identifiers or a missing record of when a campaign began. Conversely, a spreadsheet may become fragile when each analyst copies and edits a different extract. Choose the simplest setup that keeps the calculation reliable and the underlying records accessible.
Automated suggestions are best used as prompts for inspection. A tool can point to an outlier, a trend, or an apparent relationship; it cannot know whether an inventory status was backfilled, whether a promotion was intentional, or whether a customer identifier changed meaning. Microsoft presents Analyze Data as a way to explore a table, including suggested questions, rather than a source of business context in its instructions. The analyst’s job is to connect the output to the process that produced the data.
The useful answer is specific enough to change a decision
Diagnostic analytics earns its place when it turns a broad result into a bounded explanation. “Orders fell” becomes “orders per visit fell because a larger share of visits came from first-time visitors, while each visitor group’s rate stayed stable,” if the illustrative data and definitions hold. That statement tells a team where to look next and what action would be premature. It also leaves open the reason the visitor mix changed.
The strongest work keeps three things together: a reliable description of the change, a comparison that separates competing explanations, and a decision proportionate to the remaining uncertainty. Start with the business measure, check the records, follow the change into its components, and bring in the people who know the process. When the data supports only an association, say so. When it supports a narrower operational conclusion, state that conclusion plainly and watch whether the chosen action produces the expected result.