Self-Service Analytics Platform

Business-friendly semantic layer sitting between the raw data warehouse and the user-facing analytics tool -- exposing entities in plain language (Customers, Orders, Products, Campaigns, Support Tickets) rather than technical table names (dim_customer, fct_orders, stg_hubspot_contacts). Built on dbt Semantic Layer (MetricFlow) for warehouses that support it (BigQuery, Snowflake, Redshift, DuckDB), or as a Metabase-native data model (Metabase's Table Metadata configuration with field display names, types, and relationships), or as a Power BI semantic model (PBIX model with DAX measures and relationships defined). Metric pre-calculation: Total Revenue, Monthly Recurring Revenue, Customer Lifetime Value, Average Order Value, Net Promoter Score, and all department-specific metrics defined as named measures with their exact formula documented -- users click "Total Revenue" and get the correct number, not a raw column that requires them to know to exclude refunds, apply the correct currency conversion, and handle the multi-line order case correctly. Join path enforcement: in Metabase, table relationships are defined with cardinality (many-to-one from orders to customers) and the tool restricts joins to valid relationship paths; in Power BI, the data model relationship diagram controls which tables can be cross-filtered; users cannot accidentally fan-out a join and multiply rows. Field documentation: every field has a description ("Revenue: net of refunds, includes all product lines, converted to GBP at the daily exchange rate at the transaction date"), a type (metric, dimension, date, identifier), and a sensitivity classification (PII fields visually marked and access-restricted). Model tested with dbt tests (not_null, unique, relationships) run before the model is promoted to the production schema that the analytics tool connects to.

Row-level security (RLS) enforced at the data layer so the security boundary is the data model itself -- not the UI toggle that a misconfigured permission or a copied share link bypasses. RLS implementation approach per platform: in Metabase, Sandboxed Tables apply a filter condition (WHERE rep_id = current_user_id) at query time for the data sandbox user groups; in Power BI, RLS roles defined in the model with DAX filter expressions per table (Sales[territory] = LOOKUPVALUE(Users[territory], Users[email], USERPRINCIPALNAME())); in Looker, access filters applied at the model level using the logged-in user's attributes; in custom-built analytics, middleware query rewriting appends tenant_id and user_id filter conditions before the query reaches the database. Access control by data domain: HR compensation data accessible only to HR roles and senior leadership; customer PII (email, phone, payment history) accessible only to roles with a documented business need; aggregated or anonymised views available to all roles for operational metrics that don't require individual-level data. SSO integration: user identity and role attributes synced from your identity provider (Okta, Azure AD, Google Workspace) via SCIM or SAML 2.0 so access is managed in one place and removed automatically when a user leaves the organisation. Audit logging: every query executed against the analytics platform logged with the user identity, the timestamp, the tables accessed, and the query result row count; logs retained for the compliance-required period (typically 12 months minimum); accessible for data access reviews and security audits without requiring production database access. Permission review workflow: quarterly automated report listing all users, their data domain access, and their last login date -- for the data team to review and revoke access for inactive users or role changes.

Guided exploration reduces the blank-canvas problem where non-technical users open the analytics tool, see a list of tables, and have no intuition for where to start a valid analysis. Domain entry points structured as question starters: the Customers domain opens with filter suggestions relevant to customer analysis (by acquisition channel, by plan tier, by country, by sign-up month cohort); the Orders domain opens with the most commonly applied dimensions (by product, by channel, by status, by date range); the Support domain surfaces the standard segmentations (by category, by SLA tier, by agent, by resolution time bucket). Suggested metrics per domain: when a user is exploring the Customers table, the analytics tool surfaces the metrics most commonly calculated on customer data (total customers, customers by status, new customers in period, customer retention rate) as one-click starting points -- the user doesn't need to know which field to sum or group by. Template queries: the analytics team builds and publishes 10--15 template queries per domain (last month's churn by customer tier, MQL by campaign last 90 days, top 20 customers by revenue this year, unresolved tickets by SLA tier today) that any user can run with one click or clone as the starting point for a variation. Related entity navigation: from a Customers query result, the platform suggests "explore Orders for these customers" or "explore Support Tickets for these customers" -- enabling drill-through workflows that would otherwise require a separate query. Progressive disclosure: basic filters (date range, status, region) shown immediately; advanced filters (multi-value IN conditions, date arithmetic, calculated conditions) revealed with an "advanced" toggle so new users see a clean interface and experienced users can access the full capability.

Chart builder for non-technical users built on Metabase's question editor (for Metabase deployments), Power BI's drag-and-drop report canvas (for Power BI deployments), or a custom React-based chart builder (for fully custom platforms using Recharts, D3.js, or Apache ECharts): select the metric to measure, select the dimension to group by, select the date range, configure any additional filters. Chart type is recommended automatically based on the query structure: one metric with a time dimension defaults to a line chart; one metric with a categorical dimension defaults to a bar chart; two metrics with the same dimension defaults to a dual-axis bar/line; a metric and its percentage equivalent defaults to a bar with percentage overlay. Custom chart types available for specific use cases: cohort heatmap (retention cohort analysis with colour intensity scaling), waterfall chart (MRR movement showing new, expansion, contraction, churn components), and funnel chart (conversion funnel from lead to close). Dashboard composition: dashboards composed from saved questions with a resizable tile layout (Metabase Dashboard, Power BI canvas, or a custom React grid using react-grid-layout); filters applied at the dashboard level cascade to all charts on the dashboard simultaneously -- one date range filter updates all charts without each chart having its own filter. Sharing and permissions: dashboards shared via link with public (no login), signed-in user (respects RLS), or embedded (iframed into your product or intranet) delivery modes; scheduled email delivery via Metabase's pulse feature or Power BI's subscriptions with PDF or PNG attachment for recipients who need a periodic summary without logging in.

Organisation-wide library of analytics content -- saved questions, dashboards, and template queries -- managed and curated by the analytics team so department users have a useful starting point in every domain rather than an empty tool they have to populate themselves. Content taxonomy: every piece of saved content tagged with a primary domain (Sales, Finance, Marketing, Operations, Product, Customer Success), a content type (template query for cloning, published dashboard for viewing, reference analysis for understanding the data model), and a freshness indicator (last verified date -- so users know whether a dashboard was verified last week or last year). Fork-and-modify workflow: any saved query can be duplicated as the starting point for a new analysis; the fork preserves the metric definitions and filter structure while allowing the user to add dimensions, change filters, or modify the chart type; the fork is saved in the user's personal collection by default and can be promoted to the shared library if it has broader value. Dashboard version history: Metabase's revision history (or a custom git-based version store for custom platforms) records every change to a dashboard with the user who made the change and a diff of what changed; the analytics team can revert a dashboard to any prior state if an edit introduces an error or an unintended change. Usage analytics: query execution counts, dashboard view counts, and user engagement tracked at the content level (Metabase's built-in usage stats or a custom events table); the analytics team reviews usage data monthly to identify the most-used content (deserves more curation investment), the least-used content (candidates for archiving), and content that is frequently executed but has high execution time (candidates for query optimisation or materialisation as a dbt model).

Data catalogue providing in-platform documentation so users never need to leave the analytics tool to understand what they are querying. Table-level documentation: each table in the semantic model has a description written in plain language ("Customer table: one row per unique customer account; a customer is counted once regardless of how many individual users are on the account; created at first order, not at sign-up"), the data source it is populated from, the refresh frequency, and a link to the dbt model documentation for users who want the technical derivation. Field-level documentation: every field has a display name, a type, a description, known caveats ("this field is null for orders placed before 15 March 2023 when we migrated from the legacy order system"), and the business logic for derived fields ("Churned: a customer is marked churned if their subscription cancellation date is in the past and no active subscription exists on the account -- grace period customers are not counted as churned"). Freshness indicator: data freshness timestamp for each table showing when the source data last updated and when the transformation last ran; if the data is more than 2 hours old for a daily-updated table, a freshness warning is displayed on the table and on any dashboard using that table. Glossary integration: a business terms glossary linking plain-language concepts to their data model implementation (Active Customer, Churned Customer, MQL, Closed-Won, Net Revenue Retention defined in terms any new employee can understand with links to the exact fields and metrics that implement each definition). Data lineage view: for fields derived through multiple transformation steps, a lineage graph showing source system -> staging model -> intermediate model -> mart model with the transformation logic documented at each step -- accessible to advanced users who need to understand the derivation without requiring access to the dbt repository.