Business Intelligence and Analytics
Domain 6 - Business Intelligence and Analytics
This domain tests whether you can define a metric once, aggregate it correctly and present it without misleading the reader.
Semantic layer and metrics
A governed semantic layer centralizes measure definitions, joins and row-level security so every report agrees. Define each KPI explicitly: numerator, denominator, filters, time window, grain and owner. Distinguish additive measures (revenue - summable across any dimension), semi-additive measures (account balance - summable across customers but not across dates; use period-end or average) and non-additive measures (ratios, distinct counts - recompute from components, never sum or average the ratios themselves).
Analysis
Match the grain of the question to the grain of the data: daily rows cannot answer "how many distinct customers this month" by summing daily uniques. Prefer leading indicators for steering and lagging indicators for confirmation. For experiments, check sample size, significance and guardrail metrics before declaring a winner; a pattern on a dashboard is not causation.
Worked example
Monthly active users reported as the average of daily active users is too high, because loyal users appear on many days. Correct: COUNT(DISTINCT customer_id) across the whole month. The same trap hits "average order value": averaging daily AOVs weights a quiet Tuesday like a peak trading day, so compute total revenue divided by total orders for the period. Conversion rate behaves identically - recompute at the aggregate level rather than averaging channel rates.
Traps
- Averaging averages, or summing a percentage.
- Redefining a metric mid-year, which breaks every trend line; version the definition instead.
- Summing semi-additive balances across dates.
- Dashboards with no decision attached - vanity metrics.
- Truncated y-axes or dual axes that exaggerate change.
- Ignoring filter context, so a card and the table beside it show different numbers for the same label.