Powered by

# Reporting and Analytics

The Reporting and Analytics layer provides business intelligence capabilities for the organization. It emphasizes governed, trustworthy metrics while enabling ad-hoc exploration.

# Capabilities

# Ad-Hoc Data Exploration

Enable analysts and business users to explore data:

Self-service analysis:

  • Query builders for non-technical users
  • SQL access for advanced users
  • Visualization creation
  • Data export for further analysis

Guardrails:

  • Access only to authorized datasets
  • Query cost controls
  • Audit logging of all queries

# Governed Dashboards

Centrally managed dashboards for key metrics:

Characteristics:

  • Defined ownership and stewardship
  • Documented data sources and logic
  • Version control for changes
  • Scheduled refresh and monitoring

# KPI Monitoring

Dedicated views for critical business metrics:

  • Real-time or near-real-time updates
  • Trend analysis and comparisons
  • Alerting on anomalies or threshold breaches
  • Drill-down capabilities

# Access Control

# Authentication

Unified identity through SSO integration:

  • Single sign-on for all reporting tools
  • Centralized user provisioning
  • Automatic deprovisioning on offboarding
  • Audit trail of access

# Authorization

Fine-grained access controls:

Levels:

  • Tool access: Who can use the reporting tool
  • Data source access: Which datasets are visible
  • Dashboard access: Who can view specific dashboards
  • Edit permissions: Who can modify dashboards

# Row-Level Security (RLS)

Filter data based on user attributes:

Use cases:

  • Tenant isolation (each partner sees only their data)
  • Regional access (managers see their region)
  • Role-based filtering (different views for different roles)

# Multi-Tenancy

Support for multiple business units and external tenants:

  • Isolated workspaces per tenant
  • Tenant-specific branding where applicable
  • Separate access controls per tenant
  • Cost attribution by tenant

# Tool Strategy

# Current State

The organization currently uses multiple reporting tools:

Tool Primary Users Status
Metabase Most users Legacy, governance challenges
Looker Studio Management Migration target
Streamlit Data Science, Credit Ad-hoc dashboards

# Challenges with Legacy Tools

Issues identified with current tooling:

  1. Access controls: Overly permissive, all users have broad access
  2. Query exposure: SQL visible in URLs (security concern)
  3. Version lock: Outdated deployment difficult to update
  4. Ungoverned growth: Users create duplicates of indicators

# Migration Approach

Transition to governed reporting:

  1. New work on governed tools: New dashboards in Looker Studio
  2. Gradual migration: Move critical dashboards first
  3. Usage-based prioritization: Migrate heavily used reports
  4. Deprecation timeline: Clear dates for legacy tool shutdown

# KPI Lifecycle

# The Problem

Multiple versions of the same KPI (e.g., 100+ versions of FPD in Metabase):

  • Different filters for different slices
  • Copied and modified without documentation
  • Inconsistent calculations
  • No clear "source of truth"

# The Solution

Governed KPI management:

Central KPI Registry:

  • Single definition per KPI
  • Versioned with change history
  • Assigned owner/steward
  • Documented calculation logic

Standard Dimensions:

  • Pre-defined slices (by time, customer, region)
  • Parameterized filters instead of copied dashboards
  • Consistent naming conventions

Lifecycle Stages:

Stage Description
Draft Under development, not for use
Review Validation in progress
Certified Approved for production use
Deprecated Replaced, use alternative
Retired Removed from platform

# Validation Process

Before certifying a KPI:

  1. Business validation: Owner confirms logic is correct
  2. Data validation: Cross-check with source systems
  3. Technical review: Query efficiency and cost
  4. Documentation: Complete description and examples

# Dashboard Governance

# Ownership

Every dashboard must have:

  • Business owner: Accountable for content accuracy
  • Technical owner: Responsible for maintenance
  • Defined audience: Who should use this dashboard

# Change Management

Process for modifying dashboards:

  1. Request change with justification
  2. Develop in non-production environment
  3. Review by owner and stakeholders
  4. Deploy with notification to users
  5. Monitor for issues

# Monitoring

Track dashboard health:

  • Usage: Views, unique users, query frequency
  • Performance: Load times, query costs
  • Freshness: Last data update
  • Errors: Failed queries, stale data

# Cleanup

Regular review to remove unused dashboards:

  • Identify dashboards not accessed in 12 months
  • Notify owners of pending deprecation
  • Archive or delete after grace period
  • Update catalog to reflect changes

# Alerting

# Metric Alerts

Notify stakeholders of significant changes:

  • Threshold breaches (above/below limits)
  • Anomaly detection (unusual patterns)
  • Trend alerts (significant changes over time)

# Operational Alerts

Monitor dashboard health:

  • Data freshness (stale data warnings)
  • Query failures
  • Performance degradation

# Best Practices

# For Dashboard Creators

  1. Use certified datasets: Build on trusted data
  2. Document your work: Add descriptions and context
  3. Consider performance: Optimize queries, avoid large scans
  4. Think about audience: Design for your users' needs
  5. Request feedback: Iterate based on user input

# For Dashboard Consumers

  1. Check data freshness: Know when data was last updated
  2. Understand the source: Check documentation for definitions
  3. Report issues: Notify owners of problems
  4. Use official dashboards: Prefer certified over ad-hoc

# Related Sections