Quando è stato lanciato DataLab, abbiamo lavorato sodo per garantire la migliore esperienza possibile per svolgere attività di data science e data analytics. Questo ha significato creare un editor veloce e leggero, abilitare la collaborazione in tempo reale e produrre report professionali in sola lettura.
Allo stesso tempo, ci affidavamo a strumenti di terze parti per le nostre analisi interne. Metriche di prodotto come il numero di utenti che usano DataLab e il tempo trascorso sulla piattaforma venivano tracciate con altri strumenti. Ci siamo resi conto che, se volevamo prendere sul serio DataLab come strumento per il lavoro professionale, dovevamo usarlo noi per primi.
In questo articolo analizzeremo come svolgevamo le analytics interne in passato e come siamo passati a DataLab. Tratteremo anche i vantaggi e le lezioni che abbiamo ricavato dal passaggio.
Le nostre analytics prima di DataLab
Prima di DataLab, il nostro strumento principale per le analytics interne sul prodotto era Metabase. Metabase è uno strumento di business intelligence connesso a un data lake contenente informazioni sui contenuti e sull’attività di DataLab. Con Metabase potevamo eseguire rapidamente query SQL, generare report e persino creare dashboard dinamiche.
Metabase era usato ampiamente dal team. Lo utilizzavamo per monitorare quanto gli utenti fossero coinvolti con diversi tipi di contenuti, quanto tempo i nostri utenti trascorrevano in Workspace e quanti utenti interagivano con DataLab su base giornaliera, settimanale e mensile.
Usare DataLab per le nostre analytics a quel punto non era così comune. Accadeva solo quando ci scontravamo con i limiti di SQL o delle funzionalità di visualizzazione no-code di Metabase. In questi casi, esportavamo i dati grezzi, li aggiungevamo manualmente a un nuovo workbook e continuavamo l’analisi in Python. Tuttavia, questo processo era macchinoso e aggiornare i dati era una seccatura.
Perché siamo passati a DataLab
Con la crescita di DataLab, le domande a cui vogliamo rispondere sui nostri utenti e sul loro tempo su DataLab sono diventate sempre più complesse. Per quanto comodo possa essere Metabase, molte delle nostre domande richiedono gli strumenti aggiuntivi offerti da Python e R.
Sapevamo anche che, se volevamo offrire la migliore esperienza possibile all’utente, dovevamo usarlo noi stessi, una pratica chiamata “dogfooding”. In effetti, quale modo migliore per capire i limiti e le frustrazioni di DataLab se non usarlo in prima persona?
Per queste due ragioni, ci siamo posti l’obiettivo di trasferire la maggior parte delle nostre analytics da Metabase a DataLab a partire dall’estate del 2022.
La transizione
La transizione è iniziata quando abbiamo lanciato le celle SQL all’interno di DataLab. Da quel momento, eravamo in grado di interrogare gli stessi dati a cui accedevamo in Metabase, ma con i risultati delle query trasformati all’istante in un DataFrame Python o R (a seconda dello strumento che stavamo usando). Potevamo passare facilmente dall’interrogazione del database all’analisi dei risultati con gli strumenti di nostra scelta. Nel giro di poche settimane, abbiamo migrato la maggior parte delle query esistenti da Metabase a DataLab.
Al momento in cui scriviamo, abbiamo 141 diversi utenti DataCamp che hanno trascorso 30 minuti o più all’interno di DataLab. Come si può vedere dal grafico, è stato un progresso costante!
Continuiamo a reclutare nuovi DataCamper in DataLab!
I vantaggi di passare a DataLab
Da quando siamo passati a DataLab, abbiamo riscontrato diversi vantaggi chiave nel lavoro quotidiano:
- Visualizzazioni completamente personalizzabili: Sebbene Metabase offra molte visualizzazioni e attributi personalizzabili, le possibilità non sono infinite. Con DataLab, i risultati delle nostre query SQL vengono restituiti come DataFrame. Questo significa che possiamo usare librerie Python come Plotly per creare grafici con annotazioni, temi personalizzati e tipi di plot unici.
Un esempio di una delle visualizzazioni che abbiamo creato in DataLab accedendo ai nostri dati interni.
- Analisi avanzate: Combinando SQL con Python o R, possiamo analizzare all’istante i nostri dati con tecniche non possibili in SQL. Questo ci ha permesso, ad esempio, di segmentare i nostri utenti e addestrare modelli di classificazione per prevedere come gli utenti lavorano all’interno di DataLab.
- Report descrittivi: Una dashboard è eccellente per gli utenti che conoscono il prodotto. Tuttavia, può essere difficile da interpretare per i nuovi arrivati o per chi è esterno al team. Con DataLab, possiamo inserire riepiloghi testuali all’interno dei nostri report che possono essere letti in un secondo momento dagli stakeholder interessati.
- Pubblicazioni condivisibili e social: La possibilità di condividere un link a un workbook pubblicato si è rivelata estremamente preziosa. Analisi pubblicate sono finite nelle mani del nostro CEO e di altri dirigenti, che poi aggiungono feedback sotto forma di commenti e domande. Insieme alla natura descrittiva dei workbook pubblicati, il management può leggere il lavoro di analytics con calma, senza un briefing di persona.
- Grafici no-code: La maggior parte dei DataCamper ha competenze SQL, ma non tutti si sentono altrettanto a proprio agio in Python o R. Le celle di grafico permettono agli utenti meno tecnici di comunicare le proprie intuizioni usando visualizzazioni di alta qualità senza scrivere una riga di codice.
Le nostre celle di grafico no-code in azione!
Cosa abbiamo imparato finora
A metà ottobre, i DataCamper hanno accumulato in totale 4132 ore dentro DataLab! Abbiamo ora migrato tutta la reportistica centrale relativa agli obiettivi trimestrali e all’utilizzo del prodotto su DataLab. Di seguito un riepilogo delle lezioni principali e di come hanno influenzato DataLab come prodotto:
- La velocità è fondamentale: È fastidioso aspettare più del previsto per il caricamento del tuo workbook, l’esecuzione del codice o il ritorno dei risultati di una query. L’esperienza dovrebbe essere almeno veloce quanto, e idealmente più veloce di, lavorare in un Jupyter Notebook in locale. Il nostro team ha fatto grandi passi avanti nel ridurre i tempi di caricamento di notebook e pubblicazioni. Ha anche lavorato per garantire che l’esecuzione del codice sia paragonabile a quella di un notebook locale.
- Non tutti vogliono vedere il codice: In passato, le nostre pubblicazioni contenevano grandi celle piene di complesse query SQL e codice Python denso. Sebbene fosse utile per i colleghi rivedere gli aspetti tecnici di un report, spesso intralciava i veri insight. Era possibile nascondere celle e pubblicazioni passando all’editor JupyterLab in DataLab, ma questo non si rifletteva nell’editor DataCamp Notebook. Sapendolo, abbiamo rilasciato un modo per nascondere senza sforzo il codice e le celle SQL nei tuoi workbook. Questo ti permette di garantire un bel report in sola lettura da condividere con qualsiasi stakeholder. I nostri utenti lo adorano.
- Ri-eseguire i notebook può essere frustrante: Per gran parte del nostro monitoraggio, ci basiamo molto su aggiornamenti giornalieri del numero di utenti, dei livelli di attività e dell’adozione delle funzionalità. A differenza di una dashboard dinamica che si aggiorna quando sono disponibili nuovi dati, i workbook devono essere rieseguiti ogni volta. In base alla nostra esperienza, stiamo pianificando di supportare la pianificazione dell’esecuzione dei workbook. Questo garantirà che i report contengano sempre gli insight più recenti.
Queste lezioni non includono i molti piccoli aggiustamenti che abbiamo apportato all’editor da quando siamo passati a DataLab. L’interfaccia utente, la dashboard e funzionalità come le celle di grafico sono in continuo miglioramento, guidati dal feedback degli utenti, sia interni che esterni.
Guardando avanti
Se da un lato l’utilizzo del nostro stesso prodotto ha rivelato molti modi in cui possiamo migliorare, sappiamo che è solo metà della storia. In combinazione con il feedback ricevuto internamente, il nostro team ha lavorato intensamente intervistando gli utenti di DataLab. Queste interviste integrano le nostre scoperte e ci aiutano a cogliere ciò che potremmo perdere con i test interni.
Abbiamo anche lanciato un sondaggio utenti a fine settembre come parte della nostra newsletter bisettimanale. Questo sondaggio ci ha permesso di raccogliere informazioni quantitative dai nostri utenti. I risultati ci stanno aiutando a identificare iniziative ad alta priorità per DataLab e a capire come viene utilizzato il nostro prodotto. E, naturalmente, i dati del sondaggio sono stati analizzati e visualizzati con DataLab!
Il motivo principale riportato dai nostri utenti per usare DataLab è stato provare rapidamente esempi di codice. Tu come usi DataLab?
Nei prossimi mesi, prevediamo di muoverci ancora di più verso un ambiente di analytics esclusivamente DataLab. Questa transizione diventa più facile con ogni nuova funzionalità e miglioramento che il nostro team di ingegneria apporta al prodotto.
Se ti interessa usare DataLab per le tue esigenze interne di data analytics e data science, puoi saperne di più qui. O meglio ancora, entra subito in un workbook Python o R vuoto e inizia a scrivere codice ora!
