Apache Superset for Embedded Customer Analytics in Finance

Table of Contents

1. Why Superset for Embedded Analytics in Finance
2. Data Modelling for Financial Customer Analytics
3. Dashboard Design Principles for Finance
4. Security and Compliance Architecture
5. Embedding Superset Dashboards in Your Product
6. Rollout Patterns and Operational Playbooks
7. Real-World Considerations and Pitfalls
8. Next Steps and Implementation Timeline

---

Why Superset for Embedded Analytics in Finance

Financial services organisations—from fintechs and wealth managers to lending platforms and asset managers—need to embed customer analytics directly into their products. Your customers expect real-time visibility into their portfolios, transactions, risk profiles, and performance. Off-the-shelf BI tools designed for per-seat licensing create friction, cost, and poor user experience. You need embedded analytics that scale with your customer base without exploding your software bill.

Apache Superset is an open-source, modern data visualisation platform that solves this problem. Unlike proprietary BI vendors, Superset was built for embedding from the ground up. It’s lightweight, runs on commodity infrastructure, and integrates seamlessly into multi-tenant SaaS architectures. For finance organisations, this means you control the entire stack—data model, security context, performance tuning, and regulatory audit trail.

The core advantage is simplicity and cost. You’re not paying per user or per dashboard. You’re deploying a single, scalable analytics engine that serves unlimited customers. Combined with proper data modelling and security architecture, you can achieve SOC 2 compliance, audit-readiness, and the performance your customers demand. Many organisations we work with at PADISO have replaced expensive per-seat BI tools with embedded Superset, cutting analytics costs by 40–60% whilst improving customer experience and internal decision-making speed.

Superset’s flexibility also matters. You can connect to PostgreSQL, MySQL, Snowflake, Redshift, BigQuery, ClickHouse, or dozens of other databases. You can build virtual datasets (SQL-based or table-based) that model your business logic without touching raw tables. You can control row-level security (RLS) so each customer sees only their data. And because it’s open source under the Apache License, Version 2.0, you own the code and can extend it without vendor lock-in.

For finance specifically, Superset integrates well with data platforms that handle compliance requirements. If you’re building platform engineering in Sydney or scaling across the US—say, in New York, Chicago, or Austin—Superset sits cleanly at the presentation layer of a SOC 2-ready data architecture. The underlying data platform handles encryption, access logs, and audit trails; Superset consumes that data and presents it securely to end users.

---

Data Modelling for Financial Customer Analytics

The foundation of any embedded analytics system is the data model. A poor model will cause performance problems, security gaps, and dashboard maintenance nightmares. A well-designed model makes everything downstream simple.

Dimensional Modelling for Finance

Start with dimensional (star schema) thinking. In finance analytics, your fact tables typically represent transactions, positions, valuations, or events. Your dimensions are the entities that describe those facts: customers, accounts, securities, counterparties, time periods, and risk classifications.

For a wealth management platform, you might have:

• Fact table: holdings — daily snapshots of customer positions (account_id, security_id, date, quantity, market_value, cost_basis, unrealised_gain_loss)
• Fact table: transactions — all trades and cash flows (account_id, transaction_id, date, type, amount, security_id, counterparty_id)
• Dimension table: accounts — customer account metadata (account_id, customer_id, account_type, custodian, inception_date, status)
• Dimension table: customers — customer profiles (customer_id, name, segment, risk_profile, aum_bucket)
• Dimension table: securities — asset details (security_id, isin, name, asset_class, currency, sector)
• Dimension table: time — date attributes (date_id, date, month, quarter, year, fiscal_period)

This structure allows you to slice analytics by customer, account, security, time period, and risk profile. It’s normalised enough to avoid redundancy but denormalised enough to keep query performance fast.

Handling Customer Isolation and Soft Deletes

In a multi-tenant system, every fact and dimension must include a customer_id (or equivalent tenant identifier). This is non-negotiable for row-level security.

Also, avoid hard deletes. Use soft deletes (a deleted_at timestamp or is_deleted flag) so that historical analytics remain consistent. If a customer deletes an account, you still need to report on its historical performance. Your data model should make this explicit:

CREATE TABLE accounts (
  account_id UUID PRIMARY KEY,
  customer_id UUID NOT NULL,
  account_type VARCHAR(50),
  inception_date DATE,
  closed_date DATE,
  is_deleted BOOLEAN DEFAULT FALSE,
  deleted_at TIMESTAMP,
  created_at TIMESTAMP DEFAULT NOW(),
  updated_at TIMESTAMP DEFAULT NOW()
);

When building Superset datasets, always filter out soft-deleted records unless you explicitly want historical data:

SELECT * FROM accounts WHERE is_deleted = FALSE AND customer_id = {{ customer_id }}

Virtual Datasets and Calculated Metrics

Instead of hardcoding business logic in your data warehouse, use Superset’s virtual dataset (or saved query) feature to define metrics and dimensions once, then reuse them across dashboards.

For example, create a virtual dataset called customer_performance that calculates key metrics:

SELECT
  c.customer_id,
  a.account_id,
  SUM(h.market_value) AS total_aum,
  SUM(h.unrealised_gain_loss) AS total_unrealised_gain,
  SUM(h.unrealised_gain_loss) / SUM(h.cost_basis) AS ytd_return,
  COUNT(DISTINCT h.security_id) AS position_count,
  MAX(h.date) AS as_of_date
FROM customers c
JOIN accounts a ON c.customer_id = a.customer_id
JOIN holdings h ON a.account_id = h.account_id
WHERE c.is_deleted = FALSE
  AND a.is_deleted = FALSE
  AND h.date >= CURRENT_DATE - INTERVAL '1 year'
GROUP BY c.customer_id, a.account_id

Then, in Superset, you can create dashboards that slice this dataset by segment, risk profile, or time period without rewriting the metric logic. This approach also makes it easier to audit and version your analytics definitions.

Time-Series and Slowly Changing Dimensions

Financial data is inherently time-series. Holdings change daily, valuations fluctuate, and customer profiles evolve. Use a time dimension table to standardise date handling:

CREATE TABLE dim_date (
  date_id INT PRIMARY KEY,
  date DATE UNIQUE,
  month INT,
  quarter INT,
  year INT,
  fiscal_year INT,
  day_of_week VARCHAR(10),
  is_business_day BOOLEAN,
  is_month_end BOOLEAN
);

For slowly changing dimensions (e.g., customer risk profile changes quarterly), use a Type 2 SCD approach: add effective_from and effective_to timestamps:

CREATE TABLE dim_customer_scd (
  customer_key INT,
  customer_id UUID,
  risk_profile VARCHAR(50),
  segment VARCHAR(50),
  effective_from DATE,
  effective_to DATE,
  is_current BOOLEAN
);

This allows you to report on historical customer profiles accurately. A dashboard showing “return by risk profile” will correctly attribute returns to the profile that was active on the date of the return.

---

Dashboard Design Principles for Finance

Once your data model is solid, dashboard design determines whether your embedded analytics drives action or sits unused.

Start with User Journeys, Not Metrics

Don’t build a dashboard and hope customers find it useful. Instead, map out the decisions your customers need to make:

• Portfolio manager: “Is my portfolio performing? Where are my underperformers? What’s my risk exposure?”
• Wealth advisor: “How are my clients’ portfolios tracking? Which clients need outreach? What’s my AUM by segment?”
• Compliance officer: “Are we within our risk limits? What’s our exposure to concentration risk? What trades breached policy?”

Each user journey gets its own dashboard. A portfolio manager’s dashboard is fundamentally different from a compliance officer’s, even though they may both use the same underlying data.

Hierarchy and Progressive Disclosure

Don’t cram everything into one dashboard. Use a hierarchy:

1. Overview dashboard — one-page snapshot of the most important metrics (total AUM, YTD return, top positions, key risks)
2. Detailed dashboards — drilled-down views for specific analyses (performance attribution, risk breakdown, transaction history, peer comparison)
3. Exploratory dashboards — ad-hoc query tools for power users who need to slice data in custom ways

Within each dashboard, use progressive disclosure. Show the headline number, then allow drill-down to detail. In Superset, this means using cross-filters and linked dashboards.

Performance and Responsiveness

Finance users are impatient. A dashboard that takes 10 seconds to load will be abandoned. Optimise for sub-2-second query times:

• Pre-aggregate where possible — build fact tables at the right granularity. If customers only need daily holdings snapshots, don’t store intra-day data.
• Index aggressively — ensure your database has indexes on customer_id, account_id, date, and any common filter columns.
• Use caching — Superset supports query result caching. Set appropriate TTLs based on data freshness requirements (e.g., cache for 1 hour for daily snapshots, 15 minutes for real-time data).
• Denormalise for speed — sometimes a fully normalised schema is too slow. Add denormalised columns to fact tables if it dramatically improves query performance. Document why.

For real-time or near-real-time dashboards, consider ClickHouse as your analytics database. Many platform engineering teams across the US—particularly in Dallas and Atlanta—use ClickHouse with Superset for sub-second query latency on billions of rows.

Visual Design for Finance

Finance dashboards should be functional, not decorative. Key principles:

• Colour coding: Use red/green sparingly and only for clear semantic meaning (gain/loss, above/below target). Avoid rainbow palettes.
• Numbers first: Lead with the metric value, not the chart. A large number with a sparkline is often more useful than a complex chart.
• Trend lines: Show historical context. A position’s current value is less useful than its value over time.
• Comparisons: Benchmark against targets, peers, or historical periods. “AUM is $10M” is less useful than “AUM is $10M, up 5% YTD, tracking above our 8% target.”
• Consistency: Use the same colour scheme, fonts, and layout across all dashboards. Consistency reduces cognitive load.

Example: Wealth Manager Dashboard

A typical wealth manager dashboard might include:

1. KPI cards (top row): Total AUM, YTD return, number of clients, AUM under management by segment
2. Portfolio performance (left column): YTD return by client, return vs. benchmark, return by asset class
3. Risk and allocation (right column): Concentration risk (top 10 holdings), asset allocation vs. target, sector exposure
4. Client activity (bottom): New client acquisitions, AUM growth by client, client retention rate

Each element is clickable. Clicking a client name filters the entire dashboard to that client. Clicking an asset class drills into holdings in that class. This is where Superset’s cross-filter feature shines.

---

Security and Compliance Architecture

Embedded analytics in finance must be secure by design. Your data is sensitive; your customers’ financial information is confidential. A breach is catastrophic.

Row-Level Security (RLS)

Every customer should see only their data. Superset supports RLS through its Superset Embedded SDK and database-level filters.

The cleanest approach is to implement RLS at the database level, not in Superset. Add a customer_id filter to every query:

SELECT * FROM holdings WHERE customer_id = {{ logged_in_customer_id }}

In Superset, you can enforce this via:

1. Dataset-level filters — add a filter to the virtual dataset that restricts rows to the current user’s customer_id
2. Superset RLS rules — use Superset’s RLS feature to define which users can see which rows based on their role or attribute

For embedded scenarios (where customers access dashboards via your product, not directly), the cleanest approach is to:

1. Authenticate the customer in your application
2. Generate a Superset guest token that embeds the customer_id as a filter
3. Pass the token to the embedded dashboard
4. The dashboard automatically filters to that customer’s data

This way, even if a customer tries to manipulate the browser, they can’t see other customers’ data. The server-side filter is authoritative.

Encryption and Data Protection

Your data in transit and at rest must be encrypted:

• In transit: Use TLS 1.2+ for all communication between your application, Superset, and the database.
• At rest: Enable encryption on your database (RDS encryption, Snowflake native encryption, etc.) and your storage layer.
• Database credentials: Store Superset’s database connection strings in a secrets manager (AWS Secrets Manager, HashiCorp Vault, etc.), not in config files.

For regulated financial services organisations, audit-readiness is critical. If you’re pursuing SOC 2 compliance, ensure that:

• All database access is logged (Superset logs which user ran which query, and the database logs the query itself)
• Queries are immutable (store them in an audit log)
• Access controls are documented and tested
• Encryption keys are rotated regularly

Network Isolation

Deploy Superset in a private subnet with no direct internet access. All traffic flows through your VPC. If you need to serve dashboards to external customers, use an API gateway or reverse proxy to control access.

For organisations in financial services in Sydney, network architecture must comply with APRA CPS 234 and ASIC RG 271. This typically means:

• Superset runs in your private cloud or on-premises
• All data stays within your jurisdiction
• Access is logged and auditable
• Incident response procedures are documented

Audit Logging

Superset logs dashboard views, filter changes, and queries. Configure Superset to send logs to a centralised logging system (ELK, Splunk, CloudWatch). Key events to log:

• Dashboard access (who viewed which dashboard, when)
• Query execution (which user, which query, execution time, row count)
• Configuration changes (dashboard edits, dataset changes)
• Authentication (login attempts, token generation)

For SOC 2 compliance, these logs must be immutable and retained for at least 1 year. Store them in a write-once storage system (S3 with Object Lock, Azure Immutable Blob Storage, etc.).

---

Embedding Superset Dashboards in Your Product

Embedding is where Superset shines. Unlike traditional BI tools, Superset was designed to be embedded into applications.

The Embedded SDK

Superset provides an Embedded SDK that makes embedding simple. The SDK handles authentication, rendering, and cross-filter communication.

Basic workflow:

1. Create a dashboard in Superset — design your visualisations and filters
2. Generate a guest token — your backend calls Superset’s API to create a guest token that embeds the customer_id and any other context
3. Embed the dashboard — your frontend uses the SDK to render the dashboard in an iframe

Example (simplified):

import { EmbeddedSupersetDashboard } from '@superset-ui/embedded-sdk';

const token = await fetch('/api/superset-token', {
  method: 'POST',
  body: JSON.stringify({ customerId: '123' })
}).then(r => r.json());

const dashboard = new EmbeddedSupersetDashboard({
  id: 'dashboard-id',
  supersetDomain: 'https://analytics.yourcompany.com',
  mountPoint: document.getElementById('dashboard-container'),
  fetchGuestToken: () => Promise.resolve(token.token),
  dashboardUiConfig: {
    hideTitle: true,
    hideChartControls: true,
    filters: {
      visible: true,
      expanded: true
    }
  }
});

On your backend:

from superset_client import SupersetClient

client = SupersetClient(
    host='https://analytics.yourcompany.com',
    username='superset_user',
    password='superset_password'
)

token = client.get_guest_token(
    user_id=current_user.id,
    username=current_user.email,
    first_name=current_user.first_name,
    last_name=current_user.last_name,
    email=current_user.email,
    filters=[
        {
            'field': 'customer_id',
            'value': current_user.customer_id
        }
    ]
)

return { 'token': token }

The guest token is short-lived (typically 15 minutes) and scoped to the specific user and customer. Even if a token is leaked, it’s useless after 15 minutes and can’t be used to access other customers’ data.

Customisation and Branding

The Embedded SDK allows you to customise the look and feel:

• Hide controls — hide the title, filters, or chart controls if you want a cleaner interface
• Custom styling — apply CSS to match your brand
• Cross-filter — use the SDK’s API to programmatically set filters from your application
• Event handling — listen for filter changes, drill-downs, or errors

For example, if a user clicks a customer name in your CRM, you can automatically filter the embedded dashboard:

dashboard.on('filterChange', (filters) => {
  console.log('User changed filters:', filters);
});

// Programmatically set filters
dashboard.setFilter('customer_id', ['123', '456']);

Performance Optimisation

Embedded dashboards are part of your product’s user experience. Slow dashboards hurt retention. Optimise:

1. Query caching — configure Superset to cache query results. For daily snapshots, 1-hour cache is reasonable. For real-time data, use shorter TTLs or no caching.
2. Preload data — if a dashboard is accessed frequently, preload its data during off-peak hours.
3. Lazy loading — don’t load all charts at once. Load the above-the-fold charts first, then load charts below the fold as the user scrolls.
4. Database indexing — ensure your database has appropriate indexes. A missing index can make a dashboard unusable.

---

Rollout Patterns and Operational Playbooks

Deploying embedded analytics at scale requires careful orchestration. Here’s a proven pattern.

Phase 1: Pilot (Weeks 1–4)

Start with a small cohort of power users or friendly customers. Goals:

• Validate that your data model is correct
• Test the embedding flow end-to-end
• Gather feedback on dashboard design
• Identify performance issues

Run a pilot with 10–20 internal users first (your team, customer success, etc.). Fix obvious issues. Then expand to 50–100 external customers.

Deliverables:

• 2–3 core dashboards (overview, performance, risk)
• Guest token generation working end-to-end
• Embedding code integrated into your product
• Performance benchmarks (query latency, page load time)

Phase 2: Rollout (Weeks 5–8)

Expand to all customers. Plan for:

• Communication — explain what analytics are available and how to use them
• Training — create short videos or docs explaining key metrics and filters
• Support — have a customer success playbook for common questions
• Monitoring — track dashboard usage, query latency, and error rates

Rollout in waves if you have many customers. First wave: top 20% by AUM. Second wave: next 30%. Third wave: everyone else. This lets you catch issues before impacting all customers.

Phase 3: Expansion (Weeks 9–12+)

Once the core dashboards are stable, add more:

• Segment-specific dashboards — e.g., a dashboard for high-net-worth clients, another for institutional clients
• Advisor dashboards — views for wealth advisors managing multiple clients
• Risk dashboards — for compliance and risk teams
• Admin dashboards — internal views of customer activity, data quality, system health

Each new dashboard follows the same validation process: design, pilot, rollout, monitor.

Operational Playbook: Monitoring and Alerting

Set up monitoring for:

1. Query latency — if a dashboard query takes >5 seconds, alert. Investigate slow queries and optimise.
2. Dashboard errors — if a dashboard fails to load, alert. Check database connectivity, query syntax, permissions.
3. Data freshness — if the underlying data is stale (e.g., holdings are >1 day old), alert. Check ETL pipelines.
4. Usage metrics — track which dashboards are used, by whom, how often. Dashboards with zero usage may need redesign or removal.
5. Security events — log and alert on failed authentication, permission denials, or suspicious access patterns.

Example alerts (using Prometheus + Alertmanager):

groups:
  - name: superset
    rules:
      - alert: SupersetQueryLatency
        expr: histogram_quantile(0.95, superset_query_duration_seconds) > 5
        for: 5m
        annotations:
          summary: "Superset query latency high"
      - alert: SupersetDashboardErrors
        expr: rate(superset_dashboard_errors_total[5m]) > 0.01
        for: 5m
        annotations:
          summary: "Superset dashboard error rate high"

Maintenance and Updates

Superset is actively maintained. Plan for:

• Monthly updates — new features, bug fixes, security patches. Test in a staging environment before deploying to production.
• Database schema changes — when you add new data or modify existing tables, update Superset’s dataset definitions. Test dashboards to ensure they still work.
• Dashboard reviews — quarterly, review dashboard usage and feedback. Retire unused dashboards, redesign underperforming ones, add new ones based on customer requests.

---

Real-World Considerations and Pitfalls

Data Freshness vs. Query Performance

You can’t have both real-time data and sub-second query latency on large datasets. You must choose:

• Real-time, small data — stream data to a fast database (ClickHouse, TimescaleDB) and query directly. Suitable for transaction-level analytics on recent data.
• Daily snapshots, large data — batch load data once per day into a data warehouse. Suitable for portfolio analytics, risk reporting, performance attribution.
• Hybrid — real-time data for the last 7 days, daily snapshots for historical data. Query the appropriate source based on the date range.

For most finance use cases, daily snapshots are sufficient. Customers care about end-of-day valuations, not intra-day prices. If you need real-time data, use ClickHouse or a columnar database designed for analytics.

Customer Data Privacy and Segregation

In a multi-tenant system, data isolation is critical. A bug that leaks customer A’s data to customer B is catastrophic. Test rigorously:

• Unit tests — for every RLS rule, write a test that verifies a customer can’t see other customers’ data
• Integration tests — test the full embedding flow: generate a guest token for customer A, verify they can only see their data
• Penetration testing — hire a security firm to try to break your RLS implementation
• Audit logs — log all data access and review logs regularly for anomalies

Handling Deleted or Archived Data

When a customer closes an account or deletes data, you have two options:

1. Hard delete — remove the data immediately. Downside: historical analytics become inconsistent (a customer’s 2023 return can’t be recalculated if 2023 data is gone).
2. Soft delete — mark data as deleted but keep it. Downside: more storage, more complex queries.

For finance, soft delete is usually better. A customer should be able to see their historical performance even after closing an account. Use soft deletes and filter them out in dashboards unless explicitly requested.

Scaling Superset

Superset is stateless and horizontally scalable. As your customer base grows:

1. Deploy multiple Superset instances behind a load balancer
2. Use a shared database for Superset metadata (dashboards, datasets, users)
3. Use a shared cache (Redis) for query result caching
4. Monitor and scale based on CPU, memory, and query queue depth

Most organisations can run Superset on 2–4 instances serving thousands of customers. If you have millions of queries per day, you may need more instances or a query queue (e.g., Celery) to prevent overload.

Handling Compliance and Audits

When an auditor asks “Who accessed customer X’s data on 2024-01-15?”, you need to answer in minutes, not days. Invest in:

• Centralised logging — all access events in one searchable system
• Audit trail — immutable record of who did what, when
• Alerting — notify security team of suspicious access
• Documentation — document your RLS rules, encryption, access controls, and incident response procedures

For organisations pursuing SOC 2 compliance, Superset’s audit logs are a key control. Ensure they’re comprehensive, immutable, and retained for the required period.

Choosing Between Superset and Managed Alternatives

Preset is a managed SaaS built on Superset. It handles hosting, scaling, and updates. Pros: less operational overhead. Cons: less control, potential vendor lock-in, additional cost.

For most organisations, open-source Superset is the right choice. You control the code, the infrastructure, and the cost. The operational overhead is modest if you have a competent platform engineering team.

If you’re building analytics infrastructure for the first time, consider partnering with experienced platform engineers. Teams across Miami, Philadelphia, and Toronto have shipped embedded Superset analytics at scale. A fractional CTO or platform engineering partner can accelerate your timeline and avoid costly mistakes.

---

Next Steps and Implementation Timeline

Typical Implementation: 8–12 Weeks

Weeks 1–2: Design and Planning

• Finalise your data model (dimensions, fact tables, virtual datasets)
• Design 2–3 core dashboards
• Plan your embedding architecture
• Set up development and staging environments

Weeks 3–4: Data Pipeline and Infrastructure

• Build or validate your ETL pipeline
• Deploy Superset to staging
• Connect Superset to your analytics database
• Test query performance

Weeks 5–6: Dashboard Development

• Build dashboards in Superset
• Implement RLS and guest token generation
• Test embedding end-to-end
• Optimise query performance

Weeks 7–8: Pilot and Feedback

• Roll out to 50–100 pilot users
• Gather feedback on dashboard design and performance
• Fix issues and refine

Weeks 9–12: Full Rollout and Expansion

• Communicate and train customers
• Roll out to all customers
• Monitor usage and performance
• Plan next-phase dashboards

Key Success Metrics

Track these KPIs:

• Adoption: % of customers viewing dashboards at least once per month
• Engagement: average views per customer per month, time spent per dashboard
• Performance: 95th percentile query latency (target: <2 seconds)
• Reliability: dashboard availability (target: 99.9%)
• Satisfaction: NPS or CSAT for analytics feature

Investment and Resources

You’ll need:

• Platform engineers (2–3 FTE) — data modelling, Superset deployment, RLS implementation, monitoring
• Analytics engineers (1–2 FTE) — dashboard design, metric definition, data quality
• Infrastructure — Superset instances, analytics database, caching layer, logging system. Budget ~$5–10K/month depending on scale.
• Third-party tools — optional but recommended: Vanta for compliance automation, Datadog or similar for monitoring.

If you lack internal expertise, consider engaging a partner. Many organisations we work with at PADISO bring in fractional CTO or platform engineering support to accelerate the project and ensure best practices around security, performance, and compliance.

Conclusion

Apache Superset is a powerful, cost-effective platform for embedded customer analytics in finance. With proper data modelling, dashboard design, security architecture, and operational discipline, you can deliver analytics that delight customers, drive engagement, and reduce per-user BI costs by 40–60%.

The key is to start small (pilot with power users), validate the approach, then scale systematically. Monitor performance and security relentlessly. Invest in documentation and training so your team can maintain and evolve the system over time.

If you’re building analytics infrastructure for financial services, reach out. We’ve helped dozens of organisations across financial services in Sydney, insurance, and across the US deploy Superset at scale. We can accelerate your timeline, ensure compliance, and help you avoid costly mistakes.

Your customers expect analytics. Superset makes it possible to deliver them without breaking your budget or your engineering team.