14.2 Business Analytics: Connecting Performance to Revenue, Conversion & KPIs

Section 14.1 got business events into Grail. This section is about what the exam actually asks: what business question does this data answer, and how?

Dynatrace's positioning is that Business Analytics connects application performance and user experience to business metrics, enabling business and IT teams to collaborate through shared real-time perspectives, and that it simplifies critical, real-time business decisions with precision, speed, and context. Translated into exam terms: Business Analytics is what lets one system answer both "was the service degraded?" and "what did that degradation cost?"

---

Pattern 1: Quantifying Incident Impact

This is the highest-value use case and the one most likely to appear as a scenario.

A Davis problem opens at 14:05 and closes at 14:47 on the payment service. The technical answer is "42 minutes of elevated failure rate." The business answer requires comparing the same window against a healthy baseline:

fetch bizevents, from: -7d
| filter event.type == "order.completed"
| makeTimeseries revenue = sum(order.amount), interval: 5m

Overlay the problem window and the shortfall is directly readable. A more targeted version compares the incident window to the same window on prior days:

fetch bizevents, from: now() - 1h
| filter event.type == "order.completed"
| summarize revenue = sum(order.amount),
            orders  = count(),
            by: { payment.method }
| sort revenue desc

Because business events are not sampled (14.1), the resulting figure is a real number rather than an estimate — which is what makes it usable in an executive incident report.

---

Pattern 2: Funnel and Drop-Off Analysis

A multi-step journey — browse, add to cart, enter address, enter payment, confirm — emits a business event at each step. Counting events per step produces the funnel:

fetch bizevents, from: now() - 24h
| filter event.provider == "checkout"
| summarize sessions = countDistinct(session.id), by: { funnel.step }
| sort funnel.step asc

The insight lives in the ratios between steps, not the absolute numbers. A funnel that holds 92%, 89%, and 91% between stages and then collapses to 34% at the payment step localizes the problem precisely. Crucially, this is invisible in technical metrics: if the payment page returns HTTP 200 in 300 ms every time, availability and latency both look perfect while the business bleeds.

That contrast — healthy technical signals, failing business outcome — is the signature scenario for this topic. The answer is always business events or RUM conversion analysis, never a service metric.

---

Pattern 3: Segmentation

An aggregate figure hides the finding. The same query grouped by a business dimension exposes it:

Worked example: total conversion is down 4% — small enough to ignore. Segmented by payment.method, one provider has dropped 71% while the others are flat. The aggregate number would never have prompted an investigation; the segmented one names the vendor to call.

---

Pattern 4: Alerting on Business KPIs

Business events do not have to be read retrospectively. Because they live in Grail alongside everything else:

• A DQL-based metric or event can be derived from business event volume or value.
• Davis can apply anomaly detection to that signal, so an unexplained drop in completed orders raises a problem the same way a latency regression does.
• A Workflow (Chapter 12) can act on it — notify a business channel, open a ServiceNow ticket, or trigger a rollback.

The operational shift the exam wants you to recognize: a revenue anomaly becomes an alert in minutes instead of a discovery at month-end reporting.

---

Pattern 5: Shared Context Between Teams

The collaboration argument is a genuine exam point rather than marketing. Because business events, traces, logs, and infrastructure metrics share Grail and Smartscape:

• A business analyst filters completed orders by region in a Notebook and sees the drop.
• The same Notebook holds the Davis problem and the PurePath for the failing requests.
• Nobody exports a CSV, and nobody argues about whose numbers are correct, because there is one dataset.

---

What Business Analytics Is Not

Two boundaries commonly tested:

1. It is not RUM. RUM measures experience — load times, Apdex, errors, user actions. Business Analytics measures outcomes — value, conversions, counts. They are complementary, and both feed the DEM picture, but a question asking for order value is not answered by Apdex.
2. It is not a replacement for a data warehouse. Business Analytics excels at real-time, operational business questions with technical context. It is not positioned as the system of record for year-over-year financial reporting.