review-report

# Reviewing Power BI Reports

Structured evaluation of Power BI reports to produce actionable feedback for developers and consultants. A report review assesses whether a report is effective, well-built, and actually being used. The output is a prioritized list of findings with concrete recommendations.

Note that the skill works on one of three scenarios:

1. Report under development: In this scenario, the focus is more on the report content, structure, organization, and performance based on accurately gathered requirements.
2. Report in testing: In this scenario, the focus might incorporate user feedback or check basic information about the deployed report in Power BI / Fabric.
3. Report in use: This is the ideal scenario, where the focus is usage; the ultimate definition of success is whether the report is being used; what percentage of the people who have access to the report have accessed it in the last 28 days, and how much? Bad reports aren't used, or have declining usage. 

In scenario 2-3 you may still provide feedback on the report content / structure, but prioritizing other things first.

## When to Use

Activate when conducting a report review, audit, or health check. Common triggers:

- Reviewing report quality before a release or handoff
- Assessing whether existing reports are worth maintaining
- Identifying optimization opportunities across a workspace
- Evaluating report design and data presentation effectiveness
- Investigating report performance issues

## Review Dimensions

A comprehensive report review evaluates six dimensions. Not every review needs all six -- scope to what the user needs.

### 1. Usage and Adoption

**The most objective signal of report value.** A report that nobody views is a maintenance liability regardless of its design quality.

**Retrieve usage data** with the scripts in `scripts/`:

```bash
# Workspace overview (views, rank, page views, load times)
python3 scripts/get_report_usage.py -w <workspace-id>

# Add Tier 3 cross-workspace last-visited timestamps via the undocumented DataHub V2 API
# Useful for the "is this report being used at all" question without tenant admin role
python3 scripts/get_report_usage.py -w <workspace-id> --include-datahub

# Single report deep-dive (daily views, per-viewer breakdown, page views by day)
python3 scripts/get_report_detail.py -w <workspace-id> -r <report-id>

# Distribution audit (who has access, through what channels)
python3 scripts/get_report_distribution.py -w <workspace-id> -r <report-id>
```

**Filtering viewers:** Exclude non-consumer users from adoption metrics. Service principals (type `App`), report developers, and IT / support personnel inflate viewer counts and distort reach. See `references/usage-metrics.md` for identification heuristics and `references/distribution.md` for resolving security groups and distribution lists via the Microsoft Graph API.

**Evaluate usage signals:**

- **Audience reach** is the most important metric: what percentage of users with access have actually viewed the report in the last 7, 28, and 60 days? See `references/distribution.md` for how to calculate reach and what the numbers mean
- **View trends:** Is viewership stable, growing, or declining? Use the rolling 7D average (see `references/usage-metrics.md`)
- **Page view distribution:** Are views concentrated on one page or spread across the report? Before calling a page unused, check whether it is a tooltip/drillthrough target (no direct views expected) and confirm reachability via `pbir pages list`
- **Last visited:** When was the report last accessed by anyone? Tier 1 (Admin Activity Events, 30-day rolling, admin role required) is the official path. The Tier 3 DataHub V2 `lastVisitedTimeUTC` field (`--include-datahub`) is the non-admin cross-workspace fallback; flag to the user it's undocumented and can break
- **Load times:** Are P50 and P90 load times acceptable for the audience? See `references/performance.md` for interpretation

Do not use arbitrary thresholds for what constitutes "healthy" or "concerning"; these depend entirely on the report's audience, purpose, and lifecycle stage. A report for 3 analysts has different expectations than one for 300 executives. Match the review window to the report's cadence before drawing conclusions; see `references/usage-interpretation.md` for common misreads of the modern Usage Metrics report and the retire/keep/redesign decision framework.

**Subscriptions are not views.** Email subscriptions deliver report snapshots without generating view events. Check `admin/reports/{id}/subscriptions` (requires Fabric Admin) for active subscribers. A report with 0 views but active subscriptions is being consumed passively.

**Use rolling 7-day averages** for view trends. Raw daily counts are noisy. Compare the current 7D average to the prior 7D to identify trajectory. See `references/usage-metrics.md` for methodology.

**Key insight:** Reports with 0 views are not necessarily bad. They may be new, seasonal, consumed via subscriptions, or used via embedded scenarios not captured in telemetry. Cross-reference with last-visited timestamps. Prefer the Tier 1 admin Activity Events feed where admin access is available; fall back to the Tier 3 DataHub V2 path when it is not, while flagging that it is undocumented.

**Permissions:** Tier 1 (WABI) needs any workspace role. Tier 2 (model) needs workspace Contributor+. Distribution and subscription checks need Fabric Admin (tenant-level). See `references/usage-metrics.md` for the full permission matrix.

For additional context on the usage metrics dataset schema and available tables, see `usage-metrics-dataset/`.

### 2. Design and Layout

Evaluate the visual design and information architecture. Consult the `pbi-report-design` skill for detailed guidelines. Reference: [Data Goblins Report Checklist](https://data-goblins.com/power-bi/report-checklist).

**Checklist:**

- [ ] Page titles present and descriptive
- [ ] Visual spacing consistent