Analytics da incorporare per il SaaS
I tuoi clienti vogliono grafici dentro il tuo prodotto. Hai un agente di codice capace di scriverli in un pomeriggio — Claude Code, Codex, Cursor e Gemini producono tutti componenti React decenti sopra una query SQL, e li producono più in fretta di quanto un ticket riesca a descriverli.
Quello che l'agente non sa fare è tutto ciò che viene dopo. Non mantiene corretti i numeri la settimana prossima, non impedisce al cliente A di leggere le righe del cliente B e non ti dà un URL che sei disposto a mettere davanti a un account che paga. È il lavoro che fa vibedasher.
La divisione del lavoro
Il tuo agente scrive la dashboard. Componenti React, query SQL, il layout, la scelta dei grafici. Scrive quello che sa scrivere bene.
Noi la ospitiamo e la governiamo. La dashboard riceve un URL dietro il tuo login. Ogni query è limitata allo spettatore sul server, quindi ogni cliente vede solo le proprie righe. Ottieni una vista da incorporare nella tua applicazione, un aggiornamento pianificato e avvisi quando un numero supera una soglia. Colleghi il tuo warehouse una volta, con uno dei nostri connettori, o carichi un file piatto.
Ognuna delle due parti può andarsene. L'eject-to-code restituisce la dashboard come sorgente nel tuo repository. Niente di ciò che ospitiamo sta in un formato che solo noi sappiamo leggere, ed è esattamente il punto: l'artefatto che il tuo agente ha prodotto è l'artefatto che serviamo.
Rispetto a costruirla in casa
Costruirsi l'analytics incorporata è un progetto ben compreso, ed è proprio questo il problema: tutti sottovalutano la seconda metà. La prima dashboard è una settimana. Quello che segue è un isolamento delle query per tenant che tenga davanti a un cliente ostile, uno strato di query che non crolli quando un account lancia un'aggregazione su un anno, cache con invalidazione sensata, uno scheduler degli aggiornamenti e una reperibilità per le ore in cui i numeri sono sbagliati e il cliente se ne è accorto prima di te.
Niente di tutto questo è lavoro interessante, e niente differenzia il tuo prodotto. È anche la parte che il tuo agente abbozzerà con sicurezza lasciandoti scoprirla.
Rispetto ai fornitori di analytics incorporata
Luzmo, Explo e Metabase fanno analytics incorporata, e sono prodotti veri — se il tuo team vuole un editor drag-and-drop valgono il tuo tempo, e non diremo il contrario.
La differenza è in che cosa è una dashboard. Da loro è un oggetto creato nel loro editor e salvato nel loro formato; l'incorporamento serve quell'oggetto. Il tuo agente non produce quell'oggetto. Produce React e SQL, e non esiste un percorso di importazione da «un componente scritto dal mio agente» al modello interno di un editor visuale — la traduzione perde proprio ciò che volevi.
vibedasher ospita direttamente il React e il SQL. È l'unica distinzione reale, e ha una conseguenza che vale dire chiaramente: siccome l'artefatto è codice, riprenderselo è una copia, non una migrazione.
Rispetto a incorporare Tableau o Power BI
Stessa forma, generazione precedente. Tableau e Power BI ospitano cartelle di lavoro create nei loro editor, e i loro prodotti servono quelle cartelle. Se la tua organizzazione gira già su di essi, la pagina alternativa a Tableau spiega quanto costa davvero spostarsi.
Hosting
Sul cloud gestito, dashboard, dataset e risultati delle query sono elaborati e archiviati nell'Unione europea, a Francoforte — mentre l'identità di accesso, il tuo indirizzo e-mail e l'appartenenza all'account, è conservata negli Stati Uniti per ogni account, da qualunque parte tu ti trovi. La divisione non la scegli tu e non esiste un selettore di regione. Se i tuoi contratti — o quelli dei tuoi clienti — non lo permettono, la build self-hosted esegue lo stesso motore nella tua rete: docker compose per una sola macchina, un chart Helm per Kubernetes. Per essere diretti: quel percorso è documentato e testato, e non ha ancora alcun cliente in produzione. La pagina BI self-hosted spiega cosa significa.
Poi
Leggi la pagina API, SDK e MCP, o la documentazione. Per provarlo: cloud.vibedasher.com. Se preferisci prima parlare con una persona: contatti.
Domande frequenti
- I miei clienti hanno bisogno di un account vibedasher?
- No. La vista incorporata è autorizzata dalla tua applicazione, non da un secondo login. Chiedi alla nostra API un token limitato al cliente che hai già autenticato, e la dashboard viene disegnata dentro il tuo prodotto con le righe di quel cliente e di nessun altro.
- Come viene applicato il filtro per righe?
- Sul server, quando la query viene eseguita — non nel codice della dashboard. L'ambito viaggia con il token, quindi uno spettatore che manipola la richiesta, l'URL o il bundle client riceve comunque solo le proprie righe. Un filtro applicato nel frontend è una scelta di presentazione, non un confine, e non lo trattiamo come tale.
- Posso tenere il codice della dashboard?
- Sì. L'eject-to-code ti consegna la dashboard come sorgente React da ospitare nella tua applicazione, e continua a usare la nostra API di query per i dati. Su questo sito gira una dashboard davvero espulsa, così puoi guardare il risultato invece di crederci.
- Dove vivono i dati?
- Sul cloud gestito, dashboard, dataset e risultati delle query sono elaborati e archiviati nell'Unione europea, a Francoforte. L'identità di accesso — il tuo indirizzo e-mail e l'appartenenza all'account — è conservata negli Stati Uniti, per ogni account, da qualunque parte tu ti trovi. Se è un ostacolo, deve esserlo, e la build self-hosted tiene entrambe le cose nella tua rete — stesso motore, stessa API.
- Di cosa ha bisogno il mio agente per costruirne una?
- Di un server MCP. Punta Claude Code, Codex, Cursor o qualunque agente compatibile con MCP sul nostro e potrà collegare la sorgente dati, scrivere la dashboard, pubblicarla e impostare gli aggiornamenti senza uscire dal terminale. Per pilotarlo dal tuo codice ci sono SDK Python e TypeScript.