Embedded Analytics

Executive summary

Sempre più applicazioni rivolte ai clienti includono grafici, cruscotti e strumenti di esplorazione dei dati direttamente nelle proprie interfacce, senza costringere l'utente a passare a un programma esterno. Questa capacità di incorporare funzionalità analitiche all'interno di un'applicazione esistente è diventata un requisito diffuso, tanto che oltre il settanta per cento delle nuove applicazioni aziendali lanciate nel 2024 prevedeva componenti analitici integrati fin dalla progettazione. L'analisi che segue esamina le principali modalità tecniche di integrazione, confronta gli strumenti a codice aperto più adottati e approfondisce i meccanismi di sicurezza necessari a garantire che, in contesti dove più organizzazioni condividono la stessa infrastruttura, ciascuna possa vedere esclusivamente i propri dati. Ne emerge che la scelta della modalità di integrazione e del modello di isolamento dei dati è determinante per la qualità dell'esperienza utente, la scalabilità operativa e la sostenibilità economica della soluzione nel tempo.

Background

L'embedded analytics, la pratica di integrare dashboard, report e componenti di esplorazione dati all'interno di applicazioni software di terze parti, si è affermata come paradigma architetturale distinto a partire dalla metà degli anni 2010, quando le piattaforme SaaS hanno iniziato a riconoscere che l'accesso ai dati contestuale, senza context-switch verso strumenti BI esterni, rappresentava un vantaggio competitivo misurabile in termini di engagement e retention degli utenti [1]. Gartner, nel "Market Guide for Embedded Analytics" pubblicato nel 2022 e aggiornato nel 2024, ha definito l'embedded analytics come "analytics capabilities that are integrated into business applications, portals, or products rather than deployed as standalone BI tools", distinguendolo esplicitamente dalla business intelligence tradizionale per il fatto che il consumatore finale non è un analista, ma un utente operativo che interagisce con i dati nel contesto del proprio workflow [1].

La dimensione del mercato riflette questa transizione. Secondo i dati raccolti da Emergen Research nel 2024, il mercato statunitense dell'embedded analytics è stato valutato a 5,5 miliardi di dollari, con una proiezione a 15,2 miliardi entro il 2034 e un tasso di crescita annuo composto del 10,5% [2]. Un'indagine citata da Gartner indica che il 62% delle organizzazioni enterprise già utilizza forme di embedded analytics sviluppate internamente, con un ulteriore 21% in fase di pianificazione [1]. Questi numeri segnalano che l'embedded analytics non è più una funzionalità differenziante, ma un requisito di base per le applicazioni data-intensive.

Dal punto di vista architetturale, l'embedded analytics introduce tre problemi fondamentali che non esistono, o esistono in forma più semplice, nella BI tradizionale. Il primo è il problema dell'integrazione: come rendere un componente analitico parte integrante dell'interfaccia dell'applicazione host, rispettandone il design system, i flussi di navigazione e il modello di interazione. Il secondo è il problema dell'autenticazione federata: l'utente è già autenticato nell'applicazione host e non deve autenticarsi nuovamente nella piattaforma analitica; il contesto di identità deve essere propagato in modo sicuro e trasparente. Il terzo è il problema dell'isolamento multi-tenant: in un'applicazione SaaS, ogni tenant deve accedere esclusivamente ai propri dati, anche quando le dashboard sottostanti sono identiche e condividono la stessa infrastruttura [3, 4].

La risposta a questi tre problemi determina l'architettura dell'embedded analytics e, in larga misura, la scelta degli strumenti. Le sezioni che seguono analizzano le modalità di integrazione, le piattaforme open-source più rilevanti, i pattern di sicurezza per il multi-tenancy e i trade-off che emergono in fase di progettazione e operatività.

Architetture di embedding: iframe, SDK e API

Embedding basato su iframe

L'approccio storicamente più diffuso all'embedded analytics è l'inserimento di un elemento <iframe> nell'applicazione host, che carica una pagina della piattaforma BI all'interno di un contesto di navigazione isolato. L'iframe è un costrutto HTML standard (definito nella specifica HTML Living Standard del WHATWG) che crea un browsing context separato: il contenuto caricato nell'iframe ha il proprio DOM, il proprio contesto JavaScript e le proprie regole di sicurezza definite dalla same-origin policy del browser [5].

Questo isolamento ha implicazioni dirette sull'architettura dell'embedded analytics. Da un lato, semplifica l'integrazione iniziale: la piattaforma BI genera un URL firmato (tipicamente con un token JWT che codifica l'identità dell'utente, le risorse accessibili e le regole di filtraggio), e l'applicazione host incorpora quell'URL in un iframe. Il flusso è lineare, il backend dell'applicazione host richiede un token alla piattaforma BI, lo passa al frontend, e il frontend lo utilizza per inizializzare l'iframe [6, 7]. Il diagramma seguente illustra la sequenza tipica per l'embedding basato su guest token, utilizzando Apache Superset come esempio.

sequenceDiagram
    participant U as Utente
    participant App as Applicazione Host (Frontend)
    participant BE as Applicazione Host (Backend)
    participant S as Superset API
    participant DB as Database

    U->>App: Accede alla pagina con dashboard
    App->>BE: Richiede guest token
    BE->>S: POST /api/v1/security/guest_token<br/>(user, resources, rls_rules)
    S-->>BE: JWT guest token (firmato, con exp)
    BE-->>App: guest token
    App->>App: embedDashboard(guestToken)
    App->>S: Carica iframe con guest token
    S->>S: Valida token, applica RLS
    S->>DB: Query SQL con filtri RLS iniettati
    DB-->>S: Risultati filtrati per tenant
    S-->>App: Dashboard renderizzata nell'iframe

Figura 1. Flusso di autenticazione e rendering per l'embedding basato su guest token in Apache Superset.

Apache Superset implementa esattamente questo pattern attraverso il suo embedded SDK (@superset-ui/embedded-sdk), che espone una funzione embedDashboard il cui compito principale è creare un iframe e gestire il ciclo di vita del guest token [6].

Dall'altro lato, l'isolamento dell'iframe introduce vincoli significativi. La comunicazione tra l'applicazione host e il contenuto dell'iframe è limitata alla postMessage API, che opera in modo asincrono e richiede la serializzazione dei dati. Non è possibile accedere al DOM dell'iframe dall'applicazione host (e viceversa) se i domini differiscono. L'applicazione host non può applicare direttamente il proprio CSS al contenuto dell'iframe, rendendo il white-labeling, l'adattamento dell'aspetto visivo della dashboard al design system dell'applicazione, un problema non banale. Alcuni strumenti offrono parametri di personalizzazione tramite query string o API di theming esposte via postMessage, ma il grado di controllo è strutturalmente inferiore a quello ottenibile con componenti nativi [5].

Le implicazioni sulle performance meritano attenzione specifica. Ogni iframe comporta il caricamento di un documento HTML completo, con il proprio stack CSS, JavaScript e richieste di rete. In un'applicazione che visualizza più dashboard o componenti analitici contemporaneamente, il costo in termini di memoria e tempo di rendering può diventare significativo. Inoltre, l'iframe introduce un livello di latenza percepita dall'utente: il caricamento del contenuto è visivamente separato dal caricamento dell'applicazione host, creando un effetto di "contenuto che appare in ritardo" che degrada l'esperienza utente [5].

Embedding basato su SDK nativi

L'approccio alternativo è l'integrazione tramite SDK (Software Development Kit) che espone componenti nativi nel framework frontend dell'applicazione host, tipicamente React, Vue.js o Angular. A differenza dell'iframe, i componenti SDK vengono renderizzati all'interno del DOM dell'applicazione host, condividendone il contesto CSS, il sistema di gestione dello stato e il ciclo di vita dei componenti.

Metabase ha investito significativamente in questa direzione con il Modular Embedding SDK (@metabase/embedding-sdk-react), disponibile nelle edizioni Pro ed Enterprise [8]. L'architettura del SDK è composta da due elementi: un pacchetto npm leggero che funge da bootstrapper, e il codice SDK completo, servito direttamente dall'istanza Metabase. Questa separazione garantisce la compatibilità tra la versione del SDK e l'istanza Metabase, evitando il problema del version mismatch che affligge le architetture client-server con aggiornamenti indipendenti [8]. Il SDK espone componenti React individuali, chart, dashboard, query builder, collection browser, che possono essere inseriti e combinati liberamente nel layout dell'applicazione host.

L'autenticazione nel modello SDK segue un pattern diverso dall'iframe. L'applicazione host espone un endpoint backend che autentica l'utente presso Metabase e restituisce un token di sessione. Il SDK utilizza questo token per effettuare chiamate autenticate direttamente alle API di Metabase, gestendo autonomamente il refresh del token alla scadenza [8]. Questo flusso elimina la necessità di guest token one-shot e consente interazioni più ricche, ad esempio, la creazione di domande personalizzate tramite il query builder integrato, funzionalità non realizzabile in un contesto iframe con token a permessi limitati.

Il trade-off principale dell'approccio SDK è l'accoppiamento tecnologico. Un SDK React è utilizzabile esclusivamente in applicazioni React (o compatibili tramite wrapper). L'integrazione è più profonda ma meno portabile: cambiare framework frontend richiede la riscrittura dell'integrazione analitica. Inoltre, i componenti SDK condividono il contesto JavaScript dell'applicazione host, introducendo potenziali conflitti di dipendenze e aumentando la superficie di attacco, un componente analitico compromesso può, in teoria, accedere al DOM dell'intera applicazione [5, 8].

Embedding basato su API headless

Un terzo approccio, architetturalmente distinto, è l'utilizzo di API headless che forniscono esclusivamente i dati, delegando interamente il rendering all'applicazione host. Cube rappresenta l'implementazione più matura di questo pattern attraverso le sue tre API complementari: REST, GraphQL e SQL [9]. L'applicazione host interroga Cube con richieste semantiche (misure, dimensioni, filtri) e riceve dati strutturati che può visualizzare con qualsiasi libreria di charting (D3.js, Chart.js, Recharts, ECharts).

Questo approccio offre il massimo grado di controllo sull'esperienza utente, l'applicazione è interamente responsabile del rendering e può garantire una coerenza visiva perfetta, ma trasferisce all'applicazione host la complessità di implementare le interazioni analitiche (drill-down, filtri incrociati, export) che le piattaforme BI offrono nativamente. Il trade-off è tra controllo e tempo di sviluppo: un'applicazione che utilizza Cube come backend analitico headless deve implementare autonomamente le funzionalità di esplorazione dati che Metabase o Superset forniscono out of the box [9].

Confronto sintetico dei tre approcci

Piattaforme open-source per embedded analytics

Apache Superset

Apache Superset è un progetto della Apache Software Foundation (licenza Apache 2.0) con un'architettura distribuita composta da web server Flask, worker Celery per task asincroni, cache Redis e metadata database PostgreSQL [6, 10]. L'architettura multi-componente consente scalabilità orizzontale, l'aggiunta di worker Celery permette di gestire carichi concorrenti di query asincrone, ma richiede competenze operative significative per il deployment in produzione (tipicamente orchestrato con Kubernetes o Docker Compose).

L'embedding in Superset opera attraverso il meccanismo dei guest token. Il backend dell'applicazione host effettua una chiamata autenticata all'endpoint POST /api/v1/security/guest_token di Superset, specificando l'identità dell'utente guest, le risorse accessibili (dashboard o chart specifici) e le regole di row-level security da applicare [6]. Superset genera un token JWT firmato che codifica questi claim, user, resources, rls, insieme ai parametri standard JWT (iat, exp, aud). Il frontend dell'applicazione host passa questo token al SDK embedded, che crea un iframe puntato all'istanza Superset e gestisce l'autenticazione tramite il token [6].

La row-level security in Superset è nativa e inclusa nella versione open-source, un vantaggio competitivo rispetto a Metabase Community, dove la RLS è riservata all'edizione Enterprise. I filtri RLS sono definiti come clausole SQL (WHERE) associate a ruoli specifici e applicate a tabelle specifiche. Quando un utente con un determinato ruolo esegue una query su una tabella protetta, Superset inietta automaticamente la clausola di filtraggio nella query SQL generata. Più filtri RLS applicabili allo stesso utente vengono combinati con operatore AND [10]. Per il multi-tenancy, il pattern tipico consiste nel definire un filtro RLS che vincola tenant_id = '<valore>' e associarlo dinamicamente al guest token generato per ciascun tenant.

L'autenticazione e l'autorizzazione in Superset sono gestite da Flask AppBuilder (FAB), che fornisce un sistema di ruoli e permessi granulare. Un utente può avere ruoli multipli, e i permessi effettivi sono l'unione dei permessi di tutti i ruoli associati. Per l'embedding multi-tenant, il guest token crea un utente anonimo con ruolo configurabile (per default "Public"), a cui vengono applicati i filtri RLS specificati nel token [10]. Questo meccanismo consente di servire dashboard identiche a tenant diversi, ciascuno filtrato sui propri dati, senza duplicare le risorse di Superset.

Metabase

Metabase (licenza AGPL per la Community Edition, proprietaria per le edizioni Pro ed Enterprise) è progettato per la self-service analytics di utenti non tecnici [7, 8]. L'architettura è monolitica: un singolo processo JVM che include web server, query engine, metadata store e caching, deployabile come singolo container Docker con un database di supporto (PostgreSQL in produzione). Questa semplicità di deployment è un vantaggio operativo significativo rispetto all'architettura distribuita di Superset, ma limita la scalabilità orizzontale per carichi elevati.

Metabase offre tre modalità di embedding, ciascuna con un profilo architetturale distinto [7, 8]. L'embedding statico utilizza URL firmati con JWT per incorporare dashboard e domande in modalità di sola lettura. Il token JWT è firmato con un secret condiviso tra l'applicazione host e Metabase, e contiene il riferimento alla risorsa da caricare e i valori dei parametri bloccati. Questa modalità è disponibile in tutte le edizioni, ma le dashboard statiche non supportano interattività (drill-down, filtri dinamici).

L'embedding interattivo (precedentemente "full-app embedding") integra l'intera interfaccia Metabase in un iframe, con SSO (JWT o SAML) per l'autenticazione single-sign-on. Questa modalità supporta la self-service analytics completa, query builder, drill-through, collection browser, ed è il punto di ingresso per le funzionalità di multi-tenant analytics, dove ciascun tenant accede a permessi e dati specifici gestiti tramite SSO e data sandboxing [7].

Il Modular Embedding SDK (edizioni Pro ed Enterprise) rappresenta l'evoluzione più recente, con componenti React che si integrano nativamente nel DOM dell'applicazione host. Con la release di Metabase 56 (agosto 2025), il SDK è stato rearchitettato per offrire maggiore flessibilità e controllo sull'integrazione [8]. Il SDK espone componenti individuali, InteractiveDashboard, StaticQuestion, InteractiveQuestion, CollectionBrowser, che possono essere composti liberamente nel layout dell'applicazione.

Il data sandboxing di Metabase, disponibile nella Enterprise Edition, implementa la row-level security tramite l'associazione di attributi utente (propagati via SSO) a filtri su tabelle specifiche. Quando un utente con attributo company_id = 42 accede a una dashboard, Metabase aggiunge automaticamente il filtro WHERE company_id = 42 a ogni query che coinvolge tabelle con sandboxing attivo. La differenza rispetto alla RLS di Superset è che Metabase opera a livello di metadati applicativi (attributi utente SSO), mentre Superset opera a livello di ruoli e filtri SQL espliciti [7, 10].

Cube come semantic layer per embedded analytics

Cube (licenza Apache 2.0 per il core, proprietaria per Cube Cloud) si posiziona come semantic layer per embedded analytics piuttosto che come piattaforma BI completa [9]. L'architettura si articola su quattro componenti: data modeling (definizioni semantiche in YAML o JavaScript), access control (security context e query rewrite), caching (pre-aggregazioni e Cube Store) e API (REST, GraphQL, SQL compatibile Postgres-wire) [9].

Il modello di multi-tenancy in Cube opera attraverso il security context, un insieme verificato di claim sull'utente corrente, propagato tramite token JWT. Il security context è accessibile nella configurazione queryRewrite, una funzione che intercetta ogni query prima dell'esecuzione e può aggiungere filtri, modificare dimensioni o rifiutare l'accesso [11]. Per il multi-tenancy basato su row-level security, la funzione queryRewrite aggiunge un filtro tenant_id derivato dal security context a ogni query in ingresso, garantendo l'isolamento a livello di semantic layer senza dipendere da politiche RLS del database sottostante [11].

Cube supporta anche un modello di multi-tenancy più aggressivo attraverso il COMPILE_CONTEXT, che consente di servire modelli semantici completamente diversi per ciascun tenant, schemi, tabelle e metriche distinte, da una singola istanza Cube [11]. Questo approccio è adatto a scenari in cui i tenant non condividono lo stesso schema dati (ad esempio, un'applicazione verticale dove ogni cliente ha tabelle personalizzate).

Il sistema di pre-aggregazioni è particolarmente rilevante per l'embedded analytics, dove i requisiti di latenza sono più stringenti rispetto alla BI interna (l'utente finale percepisce la dashboard analitica come parte dell'applicazione e si aspetta tempi di risposta coerenti con il resto dell'interfaccia). Le pre-aggregazioni materializzano i risultati in Cube Store, un motore di storage basato su file distribuiti (tipicamente S3), riducendo i tempi di risposta da secondi a millisecondi e il carico sul data warehouse [9]. Il motore di aggregate awareness analizza ogni query in ingresso e determina automaticamente se può essere servita da una pre-aggregazione esistente, in modo trasparente per il client.

Row-level security e isolamento multi-tenant

Il problema dell'isolamento in architetture condivise

In un'applicazione SaaS multi-tenant, il requisito fondamentale è che ciascun tenant acceda esclusivamente ai propri dati, anche quando l'infrastruttura sottostante, database, istanza BI, dashboard, è condivisa. Il fallimento di questo requisito non è un bug funzionale ma una violazione di sicurezza con implicazioni legali e reputazionali. L'isolamento dei dati nell'embedded analytics deve pertanto essere trattato come un vincolo architetturale non negoziabile, implementato con meccanismi defense-in-depth su più livelli dello stack [3, 4].

Le architetture di isolamento multi-tenant per l'embedded analytics si articolano su tre livelli, non mutuamente esclusivi.

Livello 1: RLS a livello di database

PostgreSQL implementa la row-level security come funzionalità nativa a partire dalla versione 9.5, attraverso il costrutto CREATE POLICY [12]. Una policy RLS definisce un predicato booleano (USING clause) che viene valutato per ogni riga durante l'esecuzione di una query. Solo le righe per cui il predicato restituisce true sono visibili all'utente. Il pattern standard per il multi-tenancy prevede una colonna tenant_id in ogni tabella e una policy che vincola tenant_id = current_setting('app.current_tenant'), dove il valore di app.current_tenant viene impostato dalla connessione applicativa tramite SET [12]. La configurazione tipo è la seguente:

-- Abilitazione RLS sulla tabella
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

-- Policy che filtra per tenant_id
CREATE POLICY tenant_isolation ON orders
    USING (tenant_id = current_setting('app.current_tenant')::uuid);

-- L'applicazione imposta il tenant prima di ogni query
SET app.current_tenant = 'a1b2c3d4-...';
SELECT * FROM orders;  -- restituisce solo righe del tenant impostato

La RLS a livello di database offre il massimo livello di garanzia: il filtraggio è applicato dal motore del database indipendentemente dalla modalità di accesso, e un errore applicativo non può esporre dati di altri tenant. AWS, nella documentazione prescrittiva per architetture SaaS multi-tenant su PostgreSQL, raccomanda la RLS come meccanismo primario di isolamento per il modello "shared database, shared schema", evidenziando che "database-level enforcement significantly reduces security risks compared to relying solely on application-level filtering" [13].

Le implicazioni sulle performance richiedono attenzione progettuale. La policy RLS viene valutata per ogni riga esaminata dalla query, il che significa che l'assenza di un indice sulla colonna tenant_id può degradare significativamente le performance. La best practice è creare un indice su tenant_id (o un indice composto che includa tenant_id come primo elemento) e verificare tramite EXPLAIN ANALYZE che il query planner utilizzi l'indice per filtrare i dati prima di applicare la policy [12, 13]. Per workload analitici con aggregazioni su grandi volumi, il partizionamento della tabella per tenant_id può offrire benefici aggiuntivi, consentendo al query planner di eliminare intere partizioni (partition pruning) prima di applicare la policy RLS.

Livello 2: RLS a livello di piattaforma BI

Il secondo livello di isolamento opera all'interno della piattaforma BI stessa, indipendentemente dalle policy del database sottostante. Questo livello è particolarmente rilevante quando la piattaforma BI si connette al database con credenziali condivise (un unico utente di servizio) anziché con credenziali per-tenant, un pattern comune per ragioni di gestione operativa e pooling delle connessioni.

In Apache Superset, la RLS è implementata come filtri SQL associati a ruoli. Quando un utente con un ruolo specifico esegue una query, Superset concatena le clausole WHERE dei filtri RLS applicabili alla query generata dallo strumento di visualizzazione. Per l'embedding, i filtri RLS vengono specificati nel payload del guest token, consentendo al backend dell'applicazione host di definire dinamicamente i filtri per ciascun utente [6, 10]. Questo modello offre flessibilità, i filtri possono variare per utente, non solo per tenant, ma introduce un single point of failure: se il backend dell'applicazione host genera un guest token senza filtri RLS (per errore o per compromissione), l'utente accede a tutti i dati.

In Cube, la RLS è implementata tramite il queryRewrite, che opera a livello del semantic layer prima che la query raggiunga il database [11]. Questo approccio ha un vantaggio architetturale: il filtraggio è applicato indipendentemente dall'API utilizzata (REST, GraphQL o SQL), garantendo coerenza anche quando il semantic layer è consumato da strumenti diversi. Il security context di Cube può inoltre imporre restrizioni a livello di dimensione e misura (column-level security), non solo a livello di riga.

Livello 3: isolamento infrastrutturale

Per tenant con requisiti di isolamento particolarmente stringenti, tipicamente per ragioni di compliance normativa o contrattuali, è possibile implementare un isolamento a livello infrastrutturale: database separati, schemi separati o istanze BI dedicate per ciascun tenant. Questo approccio elimina il rischio di data leakage a livello architetturale, ma introduce costi operativi significativi: ogni tenant richiede risorse dedicate, configurazione indipendente e processi di aggiornamento separati [3, 4].

Il modello ibrido, shared infrastructure con RLS per la maggioranza dei tenant, e istanze dedicate per tenant premium, è il pattern più comune nelle applicazioni SaaS mature. Cube supporta questo modello attraverso il COMPILE_CONTEXT, che consente di indirizzare tenant diversi verso data source diversi dalla stessa istanza Cube [11]. Superset, attraverso la configurazione dei data source e dei permessi per ruolo, può ottenere un effetto analogo, sebbene con maggiore complessità operativa [10].

Defense-in-depth: la combinazione dei livelli

L'approccio raccomandato è la combinazione di più livelli di isolamento (defense-in-depth). Una configurazione robusta per embedded analytics multi-tenant prevede: (1) RLS a livello di database come barriera di ultima istanza, (2) RLS a livello di piattaforma BI o semantic layer come meccanismo primario di filtraggio, e (3) validazione dei token e dei permessi a livello applicativo come primo punto di controllo. In questo modello, un errore in un singolo livello non compromette l'isolamento, perché i livelli sottostanti continuano a filtrare i dati.

La verifica dell'isolamento richiede test specifici e sistematici. È necessario validare che un utente del tenant A non possa accedere ai dati del tenant B attraverso nessuna combinazione di API call, parametri URL o manipolazione dei token. Strumenti di testing automatizzato che simulano richieste cross-tenant e verificano l'assenza di data leakage dovrebbero essere parte integrante della pipeline CI/CD dell'applicazione.

Limiti e problemi aperti

Latenza e coerenza percepita

L'embedded analytics introduce un problema di coerenza percepita: l'utente si aspetta che la dashboard integrata risponda con la stessa velocità del resto dell'applicazione, ma i tempi di query analitiche su grandi volumi sono strutturalmente diversi dai tempi di risposta di API transazionali. Quando una dashboard embedded impiega 3-5 secondi a caricarsi in un'applicazione che per il resto risponde in 200 millisecondi, l'effetto è una discontinuità percettiva che degrada l'esperienza complessiva. Le pre-aggregazioni (Cube) e il caching (Redis in Superset) mitigano il problema, ma non lo eliminano per query ad hoc o per dati in tempo reale [9, 10].

Complessità operativa

L'aggiunta di una piattaforma BI all'architettura di un'applicazione SaaS introduce componenti, dipendenze e superfici di attacco aggiuntive. Superset richiede Flask, Celery, Redis e PostgreSQL; Metabase richiede una JVM e un metadata database; Cube richiede il proprio runtime Node.js e Cube Store. Ogni componente deve essere monitorato, aggiornato e scalato indipendentemente. La gestione degli aggiornamenti è particolarmente critica: un aggiornamento della piattaforma BI può introdurre breaking change nelle API di embedding, richiedendo modifiche simultanee nell'applicazione host, un pattern di deployment coordinato che aumenta il rischio operativo. Per team di piccole dimensioni, questa complessità operativa può superare i benefici dell'embedded analytics, suggerendo l'adozione di servizi managed (Preset per Superset, Metabase Cloud, Cube Cloud) a fronte di un costo ricorrente che, per applicazioni con meno di 50 utenti concorrenti, si attesta tipicamente nell'ordine di alcune centinaia di euro mensili [6, 7, 9].

Evoluzione delle API e stabilità delle integrazioni

Le piattaforme open-source per embedded analytics sono in rapida evoluzione, con API che cambiano frequentemente tra versioni major. Metabase ha rearchitettato il proprio SDK di embedding tra la versione 49 e la 56 [8]; Superset ha introdotto il meccanismo dei guest token nel 2022 con la PR #17517, modificando il pattern di embedding precedente [6]. Per le applicazioni host che dipendono da queste integrazioni, ogni aggiornamento della piattaforma BI richiede la verifica della compatibilità dell'integrazione, un costo di manutenzione non trascurabile che va considerato nella valutazione iniziale.

White-labeling e personalizzazione

Il white-labeling completo, la rimozione di ogni riferimento alla piattaforma BI sottostante e l'adattamento integrale dell'aspetto visivo al design system dell'applicazione host, è un requisito frequente nelle applicazioni SaaS B2B. Le piattaforme open-source supportano il white-labeling in modo parziale: Metabase richiede l'edizione Enterprise per rimuovere il logo "Powered by Metabase" dall'embedding iframe [7]; Superset non impone branding ma la personalizzazione CSS dell'iframe è limitata; Cube, essendo headless, non ha questo problema ma trasferisce l'intero onere del rendering all'applicazione host [7, 9]. La scelta tra "personalizzazione parziale con sviluppo rapido" (iframe) e "personalizzazione totale con sviluppo esteso" (SDK o API headless) è uno dei trade-off architetturali più rilevanti nel dominio.

Governance delle metriche in contesti embedded

Quando le componenti analitiche sono integrate in un'applicazione esterna, il rischio di disallineamento tra le metriche mostrate nella dashboard embedded e quelle calcolate altrove (report interni, export, API) aumenta. Un cliente che osserva un valore di "ricavo mensile" nella dashboard embedded diverso da quello mostrato nel report PDF generato dalla stessa applicazione perde fiducia nell'intero sistema, indipendentemente da quale dei due valori sia corretto. L'adozione di un semantic layer come Cube, che centralizza le definizioni delle metriche e le espone attraverso API uniformi, mitiga questo rischio architetturalmente, garantendo che ogni consumatore (dashboard, API, export) calcoli la metrica nello stesso modo [9]. Tuttavia, l'introduzione di un semantic layer richiede un processo di governance delle definizioni metriche (chi definisce una metrica, chi la approva, come viene versionata) che molte organizzazioni non hanno formalizzato e che rappresenta una sfida organizzativa più che tecnica.

Implicazioni pratiche

La selezione dell'architettura di embedded analytics è determinata dalla combinazione di tre fattori: il grado di personalizzazione richiesto, le competenze del team di sviluppo e il profilo di sicurezza del contesto applicativo.

Per applicazioni che richiedono un time-to-market rapido e un grado di personalizzazione limitato, l'embedding basato su iframe con Apache Superset o Metabase offre il percorso più breve dalla decisione alla produzione. Superset è preferibile quando la RLS multi-tenant è un requisito immediato e il budget non consente edizioni enterprise, grazie alla RLS nativa nella versione open-source. Metabase è preferibile quando gli utenti finali sono non tecnici e la self-service analytics (query builder, drill-down) è parte del valore offerto [6, 7, 10].

Per applicazioni SaaS B2B che richiedono white-labeling completo e integrazione profonda con il design system, l'approccio SDK (Metabase Enterprise) o API headless (Cube) è architetturalmente più adatto. Il SDK Metabase riduce il tempo di sviluppo offrendo componenti analitici pre-costruiti; Cube offre il massimo controllo ma richiede l'implementazione del layer di visualizzazione [8, 9].

Per contesti con requisiti di sicurezza stringenti (fintech, healthcare, settore pubblico), la combinazione di RLS a livello di database (PostgreSQL CREATE POLICY), RLS a livello di semantic layer (Cube queryRewrite) e validazione applicativa dei token rappresenta l'architettura con il profilo di rischio più basso [11, 12, 13]. L'investimento in testing automatizzato per la verifica dell'isolamento cross-tenant è in questi contesti non opzionale.

Indipendentemente dalla scelta architetturale, è opportuno valutare fin dalla fase di progettazione il costo totale di ownership, che include non solo le licenze software ma anche il costo operativo di deployment, monitoraggio, aggiornamento e manutenzione dell'integrazione nel tempo. L'adozione di servizi managed (Preset, Metabase Cloud, Cube Cloud) trasferisce il costo operativo al vendor a fronte di un costo ricorrente, un trade-off che per team con risorse DevOps limitate è spesso economicamente favorevole.

Riferimenti

[1] Gartner, "Market Guide for Embedded Analytics," 2022 (aggiornato 2024). https://www.gartner.com/en/documents/4006442

[2] Emergen Research, "US Embedded Analytics Market Size, Share & 2034 Growth Trends Report," 2024. https://www.emergenresearch.com/industry-report/us-embedded-analytics-market

[3] AWS Database Blog, "Multi-tenant data isolation with PostgreSQL Row Level Security," 2023. https://aws.amazon.com/blogs/database/multi-tenant-data-isolation-with-postgresql-row-level-security/

[4] Microsoft Learn, "Security in Power BI embedded analytics," 2024. https://learn.microsoft.com/en-us/power-bi/developer/embedded/embedded-row-level-security

[5] WHATWG, "HTML Living Standard — The iframe element," 2024. https://html.spec.whatwg.org/multipage/iframe-embed-object.html

[6] Apache Software Foundation, "Apache Superset — Security Configurations and Embedded SDK," 2024. https://superset.apache.org/docs/security/ e https://github.com/apache/superset/tree/master/superset-embedded-sdk

[7] Metabase, "Embedding Introduction — Documentation," 2025. https://www.metabase.com/docs/latest/embedding/introduction

[8] Metabase, "Modular Embedding SDK — Documentation," 2025. https://www.metabase.com/docs/latest/embedding/sdk/introduction

[9] Cube Dev, "Introduction — Cube Documentation," 2025. https://cube.dev/docs/product/introduction

[10] Apache Software Foundation, "Apache Superset — Architecture and Security," 2024. https://superset.apache.org/admin-docs/installation/architecture/

[11] Cube Dev, "Multitenancy and Security Context — Cube Documentation," 2025. https://cube.dev/docs/product/configuration/multitenancy e https://cube.dev/docs/product/auth/context

[12] PostgreSQL Global Development Group, "Row Security Policies — PostgreSQL 18 Documentation," 2025. https://www.postgresql.org/docs/current/ddl-rowsecurity.html

[13] AWS Prescriptive Guidance, "Row-level security recommendations for SaaS multi-tenant managed PostgreSQL," 2024. https://docs.aws.amazon.com/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/rls.html