Cos'è l'embedded analytics?

L'embedded analytics è l'insieme di grafici, report e metriche integrati direttamente dentro un prodotto software, in modo che chi lo usa li veda nel contesto in cui lavora, senza aprire uno strumento di business intelligence separato dove andare a cercarli. Un cliente che gestisce le proprie spedizioni vede il grafico dei ritardi dentro la piattaforma logistica che già usa ogni giorno; un operatore di un centro assistenza vede i suoi tempi di risposta dentro il gestionale dei ticket. La differenza con la BI classica non sta nel grafico in sé, che può essere identico, ma in dove vive e per chi è pensato: non un report interno consultato da un analista una volta a settimana, ma una funzione di prodotto vista da centinaia o migliaia di clienti in contemporanea, ognuno con i propri dati e nessuna visibilità su quelli degli altri.

Cosa cambia davvero rispetto alla BI classica

In un progetto di BI interna il pubblico è l'analista o il manager, e il carico è prevedibile: un report lanciato ogni mattina, una dashboard aggiornata ogni ora. Nell'embedded analytics il pubblico è il cliente finale o l'operatore, e il carico è imprevedibile per definizione: mille clienti possono aprire la stessa dashboard nello stesso minuto, ognuno filtrando dati diversi. Questo sposta il problema tecnico dalla scelta dello strumento di visualizzazione alla piattaforma dati sottostante: deve isolare i dati per singolo cliente, applicare permessi granulari a livello di riga (row-level security applicata in modo sistematico, non aggiunta a posteriori come toppa) e reggere query concorrenti generate dagli utenti stessi, non pianificate da chi progetta i report. Serve anche coerenza tra le definizioni mostrate nel prodotto e quelle usate nella reportistica interna dell'azienda che lo vende: se il grafico di vendita nel prodotto e il report interno del team finance calcolano "fatturato" in due modi diversi, la fiducia del cliente nel numero crolla alla prima discrepanza. Qui l'aggancio naturale è a un semantic layer condiviso: le stesse definizioni servono sia il prodotto sia gli strumenti interni, invece di essere ricalcolate due volte.

Un esempio enterprise e perché conta per chi vende software

Un fornitore di software gestionale per magazzini integra un cruscotto di metriche di rotazione scorte direttamente nell'app che i clienti usano ogni giorno, invece di offrire un export verso Power BI. Per il cliente finale è comodo: il dato è dove serve, senza cambiare strumento. Per il fornitore è una leva di valore percepito e spesso di monetizzazione diretta, perché l'analitica avanzata diventa una funzione premium venduta come upsell su un piano superiore, non un accessorio gratuito. Per chi la costruisce, però, il problema non è scegliere il tipo di grafico giusto: è progettare una piattaforma dati multi-tenant che regga migliaia di query concorrenti senza che un cliente rallenti l'esperienza di un altro, e senza che un errore di configurazione esponga dati non suoi.

Quando serve e quando no

L'embedded analytics ha senso quando il pubblico dell'analisi è esterno al team interno: clienti, partner, operatori che usano il prodotto ogni giorno e per cui uscire verso un altro strumento sarebbe attrito. Non serve, invece, quando gli utenti dell'analisi sono pochi e interni all'azienda: in quel caso uno strumento di BI classico come Power BI, Tableau, Looker o Qlik costa meno da costruire e mantenere, e risolve lo stesso bisogno senza il carico ingegneristico del multi-tenancy. Costruire embedded analytics per un pubblico di cinque analisti interni è complessità aggiunta senza motivo.