Ogni volta che un merchant su Adobe Commerce mi chiede “come porto i miei dati in Power BI?”, la domanda vera è un’altra: cosa non ti dà già la piattaforma che tu stia cercando altrove. Perché la risposta tecnica è quasi banale — i dati stanno in un database MySQL, le API ci sono, i connettori sul marketplace pure — mentre la risposta di architettura, quella che decide se il progetto reggerà tra due anni, è tutt’altro che scontata. In questo pezzo racconto come collego davvero Adobe Commerce a Power BI, dove ho visto rompersi le scorciatoie, e quando invece conviene restare su Adobe Commerce Intelligence.
Perché Power BI e non Commerce Intelligence
Parto da una presa di posizione, così mettiamo le cose in chiaro. Se hai un singolo store e ti serve rispondere a domande tipo “come crescono gli ordini mese su mese”, “chi sono i clienti più fedeli”, “la strategia coupon sta funzionando”, Adobe Commerce Intelligence (l’ex Magento BI) è spesso la strada più corta. Si collega direttamente al database, arriva con circa 70 report preconfezionati su cinque dashboard, e per fare custom serve saper scrivere SQL. È maturo, è pensato per l’e-commerce, e in molti casi è già incluso o facilmente attivabile.
Power BI ha senso quando la domanda esce dal perimetro dello store. E nel mid-market esce quasi sempre. Il merchant non vuole vedere solo il fatturato di Adobe Commerce: vuole incrociarlo con i costi dall’ERP, con le anagrafiche del CRM, con la spesa media sui canali di marketing, con il margine reale per SKU. Nel momento in cui il reporting deve unire più fonti in un unico semantic model, Commerce diventa una sorgente tra tante e Power BI diventa il posto giusto dove far vivere il modello. A questo aggiungo tre motivi pratici che vedo ricorrere: l’azienda è già tutta dentro lo stack Microsoft (licenze, governance, competenze interne), il modello di licensing di Commerce Intelligence non si incastra col budget, oppure il team finance vuole modellare in DAX cose che in MBI diventano acrobazie.
La regola che uso: una sola fonte e domande da e-commerce puro → Commerce Intelligence. Più fonti, margine, stack Microsoft → Power BI. Non è una guerra di religione, è una scelta di dove metti la complessità.
Le tre vie per collegare Adobe Commerce a Power BI
1. REST API e GraphQL
Adobe Commerce espone REST e GraphQL, con autenticazione OAuth. I connettori del marketplace — ce ne sono diversi, da Power BI a suite dedicate — girano quasi tutti su questo canale: registri un’app, ottieni le credenziali, e Power BI tira i dati attraverso gli endpoint, in modalità schedulata o quasi-live.
Il mio giudizio: ottimo per un proof of concept, per store piccoli, o per un cruscotto verticale. Meno bene appena i volumi crescono. Le REST API di Commerce non sono nate per fare estrazioni analitiche massive: paginare centinaia di migliaia di ordini con le loro righe, tra rate limit e timeout, è un lavoro che l’API fa malvolentieri. Su un merchant fashion attorno ai 15M di GMV, un connettore REST che ricaricava lo storico ordini a ogni refresh ha iniziato a impiegare ore e a incidere sulle performance del sito. Il canale API va bene per delta piccoli e frequenti, non per il carico pesante.
2. Connessione diretta al database MySQL
Tentazione forte, perché Magento e Adobe Commerce vivono su MySQL e lì c’è tutto: tabelle custom, campi, oggetti. Power BI può leggere da MySQL, e Commerce Intelligence stesso lavora così.
Il punto è da quale MySQL leggi. Puntare Power BI sul database di produzione è la cosa che sconsiglio con più forza: query analitiche pesanti su uno schema EAV, in concorrenza con il traffico di vendita, è il modo migliore per rallentare il checkout mentre generi un report. La via corretta, se resti sul database, è leggere da una read replica dedicata al reporting, mai dalla primary. Aggiungici che lo schema EAV di Commerce non è amichevole: ricostruire un attributo prodotto significa join su più tabelle catalog_product_entity_*. Fattibile, ma è lavoro di modellazione vero, non un “collega e vai”.
3. ETL/ELT verso un data warehouse
È l’architettura che propongo quasi sempre ai merchant seri. Uno strato di ETL/ELT — Fivetran, Airbyte, un iPaaS, o pipeline custom — replica i dati di Commerce (via MySQL o via connettore Adobe Commerce dedicato) dentro un data warehouse: BigQuery, Azure Synapse, Snowflake. Da lì Power BI legge un modello pulito, magari già trasformato con dbt, e ci incroci ERP, CRM e marketing.
I vantaggi sono concreti: il carico analitico non tocca più la produzione, lo storico è tuo e non dipende dai limiti dell’API, e il warehouse diventa la single source of truth su cui poggia non solo Power BI ma qualsiasi altro strumento. Il costo è che introduci un componente in più da gestire e, con i modelli consumption-based, una voce di spesa che va tenuta d’occhio. Ma per chiunque abbia più di una fonte dati, è l’unica via che invecchia bene. Ne parlo anche quando ragiono di architetture headless e composable: il principio è lo stesso, disaccoppiare i layer invece di far fare tutto al monolite.
La mia raccomandazione, per taglia
Concretamente, ecco come decido con i clienti:
- Store singolo, reporting e-commerce puro: Adobe Commerce Intelligence. Non complicarti la vita.
- Store singolo ma stack Microsoft e voglia di custom in DAX: Power BI con read replica MySQL, modellando lo schema EAV con attenzione.
- Mid-market con ERP + CRM + marketing da unire, o multi-store: ETL verso data warehouse, Power BI sopra. Qui il ritorno sull’investimento arriva dal fatto che finalmente vedi il margine reale, non solo il fatturato lordo dello store.
Un ultimo consiglio da chi ci è passato: non far scegliere l’architettura al connettore che hai trovato per primo sul marketplace. Parti dalle domande di business e dalle fonti che devi unire — la tecnologia viene dopo. Ho visto merchant B2B, un mondo in cui il potenziale in Italia resta enorme, montare cruscotti bellissimi che rispondevano alle domande sbagliate perché nessuno aveva definito prima il modello dati.
FAQ
Serve un data warehouse per collegare Adobe Commerce a Power BI?
No, non è obbligatorio. Per un PoC o uno store piccolo bastano i connettori REST API o una read replica MySQL. Il data warehouse diventa necessario quando i volumi crescono o quando devi unire i dati e-commerce con altre fonti come ERP e CRM.
Power BI sostituisce Adobe Commerce Intelligence?
Non del tutto. Commerce Intelligence è più veloce da attivare per il reporting e-commerce di un singolo store, con report già pronti. Power BI conviene quando serve un modello multi-fonte, personalizzazione spinta in DAX o integrazione nello stack Microsoft.
Posso collegare Power BI direttamente al database di produzione?
Tecnicamente sì, ma lo sconsiglio. Le query analitiche pesano sullo schema EAV e rischiano di degradare le performance del sito. Usa sempre una read replica dedicata al reporting o un data warehouse a valle di un processo ETL.
Box autore
Fabio Canovi è consulente Adobe presso il gruppo Lutech. Tra i primi in Italia a certificarsi su Adobe Commerce, è certificato anche su Adobe Experience Manager, Adobe Analytics e Adobe Target (Master – Target Architect). Lavora da oltre dieci anni su Magento e Adobe Commerce, dai tempi di Magento 1 fino ad Adobe Commerce Cloud, seguendo merchant EU mid-market su architettura, dati e reporting. Se vuoi approfondire, trovi altri spunti nei miei articoli su Adobe Commerce Cloud e infrastruttura.