14.1 Business Events: Capture, Ingestion & the bizevents Grail Table

Every signal covered so far answers a technical question: how fast, how many, how healthy. Business events answer a different one: what happened to the business? An order was placed for £248.50. An insurance quote was abandoned at step 3. A payment was declined by the issuer.

Business Analytics is a separately scored topic on the Associate exam score report, and the official learning path devotes half of its Business Analytics & DEM lesson to business events. Dynatrace's own framing 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 it leverages business events to achieve the precision many business use cases demand.

---

What Makes a Business Event Different

The precision point is the one exam questions lean on. Traces may be sampled by Adaptive Traffic Management; business events are not, because a financial or compliance record that is 90% accurate is worthless. If a scenario says "we need an exact count of completed transactions," the answer is business events, not a request-count metric.

---

The Four Sources of Business Events

Business events can come from OneAgent (stored in the bizevents Grail table), RUM data, generic data ingest via the bizevents API endpoint, and logs.

1. OneAgent capture rules — the zero-code path

OneAgent can capture business events from incoming HTTP requests using capture rules that tell OneAgent to capture business events when specific web services or endpoints are called. A rule specifies:

• Trigger — which endpoint, path, or web service the rule applies to (for example POST /api/v1/orders)
• Event type and provider — how the record is classified
• Field extraction — which values to pull from the request or response body, headers, query parameters, or path segments

Because the extraction happens inside the already-injected agent, no application code changes and no redeployment are required. This is the exam's favourite business-events fact: a team that wants order-value analytics on an existing, unchanged production service can have it by configuring a capture rule.

2. RUM

Browser and mobile RUM instrumentation can emit business events from the client side, which is how front-end funnel steps and abandonment points that never reach a backend endpoint get captured.

3. The business events ingest API

For systems Dynatrace does not instrument — a mainframe, a partner settlement feed, an ERP export — Business Observability offers the Business events API to ingest JSON-format data via the /bizevents/ingest endpoint:

POST https://{environment-id}.live.dynatrace.com/api/v2/bizevents/ingest
Content-Type: application/json

{
  "event.provider": "erp.settlement",
  "event.type": "payment.settled",
  "order.id": "A-99213",
  "payment.amount": 248.50,
  "payment.currency": "GBP",
  "customer.tier": "gold"
}

4. Logs

Where an application already writes a structured line containing the business fact, that line can be transformed into a business event on ingest rather than duplicating the emission.

---

Where They Live and How You Read Them

Business events are stored in the bizevents table in Grail and are queried with the same DQL used for logs, spans, and metrics. The learning path's own call to action is to run:

fetch bizevents

…and inspect what comes back. Building on the DQL taught in Chapter 11:

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

One query, no separate BI tool, no nightly export — and because it is the same Grail store, the same timeframe filter can be applied to the problem that was open during that window.

---

Modelling Rules That Matter

1. Use a consistent event.provider and event.type taxonomy. These are the primary grouping dimensions; inconsistent naming makes the data unqueryable in practice.
2. Type your numeric fields as numbers, not strings — sum() and avg() cannot aggregate a string.
3. Do not put personally identifiable information in business events unless your data-protection posture explicitly allows it. Masking on ingest is covered in Chapters 10 and 11 and applies here too.
4. Business events are metered. Ingest what the business will actually query rather than everything the application knows.

---

Choosing the Right Source