Als DataLab erstmals an den Start ging, haben wir viel Energie hineingesteckt, die bestmögliche Experience für Data-Science- und Data-Analytics-Arbeit zu schaffen. Dazu gehörten ein schneller, schlanker Editor, die Zusammenarbeit in Echtzeit und professionelle, schreibgeschützte Reports.
Gleichzeitig haben wir für unsere internen Analysen auf Dritttools gesetzt. Produktmetriken wie die Zahl der DataLab-Nutzer und die auf der Plattform verbrachte Zeit wurden mit anderen Tools getrackt. Uns wurde klar: Wenn wir DataLab als Profi-Tool ernst nehmen, müssen wir es selbst einsetzen.
In diesem Artikel zeigen wir, wie wir interne Analysen früher umgesetzt haben und wie wir auf DataLab umgestiegen sind. Außerdem teilen wir die Vorteile und Learnings aus diesem Schritt.
Unsere Analytics vor DataLab
Vor DataLab war unser zentrales Tool für interne Produktanalysen Metabase. Metabase ist ein Business-Intelligence-Tool, das mit einem Data Lake verbunden ist, der Informationen zu DataLab-Inhalten und -Aktivitäten enthält. Mit Metabase konnten wir schnell SQL-Queries ausführen, Reports erstellen und sogar dynamische Dashboards bauen.
Metabase wurde im gesamten Team intensiv genutzt. Wir haben damit gemessen, wie stark sich Nutzer mit unterschiedlichen Inhaltstypen beschäftigen, wie viel Zeit sie in Workspace verbringen und wie viele Menschen täglich, wöchentlich und monatlich mit DataLab interagieren.
DataLab für unsere Analysen zu verwenden, war zu diesem Zeitpunkt eher die Ausnahme. Das passierte vor allem dann, wenn wir an die Grenzen von SQL oder der No-Code-Visualisierung von Metabase stießen. In solchen Fällen exportierten wir die Rohdaten, fügten sie manuell in ein neues Workbook ein und führten die Analyse in Python fort. Das war umständlich und machte Aktualisierungen mühsam.
Warum wir auf DataLab umgestiegen sind
Mit dem Wachstum von DataLab wurden auch die Fragen komplexer, die wir zur Nutzung und zur auf DataLab verbrachten Zeit unserer User beantworten wollten. So bequem Metabase auch ist, viele Fragestellungen erforderten die zusätzlichen Möglichkeiten von Python und R.
Außerdem wussten wir: Wenn wir die bestmögliche User Experience bieten wollen, müssen wir unser Produkt selbst nutzen – auch bekannt als „Dogfooding“. Welcher Weg könnte besser sein, die Grenzen und Frustrationen von DataLab zu verstehen, als es täglich selbst einzusetzen?
Aus diesen beiden Gründen haben wir uns vorgenommen, ab Sommer 2022 den Großteil unserer Analysen von Metabase auf DataLab umzustellen.
Die Umstellung
Der Umstieg begann mit der Einführung von SQL-Zellen in DataLab. Damit konnten wir auf dieselben Daten zugreifen wie in Metabase – nur dass die Query-Ergebnisse direkt als Python- oder R-DataFrame (abhängig vom verwendeten Tool) vorlagen. So ließ sich nahtlos zwischen Datenbankabfrage und Analyse mit dem bevorzugten Tool wechseln. Innerhalb weniger Wochen migrierten wir die meisten unserer bestehenden Queries von Metabase nach DataLab.
Zum Zeitpunkt der Erstellung dieses Artikels haben 141 unterschiedliche DataCamp-Nutzer je 30 Minuten oder mehr in DataLab verbracht. Wie im Chart zu sehen ist, geht es stetig voran!
Wir holen laufend weitere DataCamper in DataLab!
Die Vorteile des Wechsels zu DataLab
Seit dem Wechsel zu DataLab haben wir im Alltag mehrere Schlüsselvorteile entdeckt:
- Voll anpassbare Visualisierungen: Metabase bietet viele Charts und Einstellungsmöglichkeiten, aber nicht alles ist machbar. In DataLab kommen die Ergebnisse unserer SQL-Queries als DataFrames zurück. So können wir mit Python-Bibliotheken wie Plotly Charts mit Annotationen, eigenen Themes und speziellen Diagrammtypen erstellen.
Ein Beispiel für Visualisierungen, die wir in DataLab mit unseren internen Daten erstellt haben.
- Erweiterte Analysen: Durch die Kombination aus SQL und Python oder R können wir Daten mit Verfahren analysieren, die in SQL nicht möglich sind. So segmentieren wir Nutzer oder trainieren Klassifikationsmodelle, die vorhersagen, wie Nutzer in DataLab arbeiten.
- Beschreibende Reports: Ein Dashboard ist super für alle, die das Produkt kennen. Für Neueinsteiger oder externe Stakeholder ist es jedoch oft schwer zu deuten. In DataLab können wir überall in unseren Reports verständliche Zusammenfassungen einbetten, die relevante Stakeholder später in Ruhe lesen können.
- Teilbare, soziale Publikationen: Ein Link zu einem veröffentlichten Workbook zu teilen, ist enorm wertvoll. Veröffentlichte Analysen landen bei unserem CEO und weiteren Führungskräften, die dann Feedback in Form von Kommentaren und Fragen geben. Zusammen mit dem beschreibenden Charakter der Workbooks kann sich das Management die Analysen ohne Präsenztermin in Ruhe ansehen.
- No-Code-Charts: Die meisten DataCamper beherrschen SQL, aber nicht alle fühlen sich in Python oder R gleichermaßen wohl. Chart-Zellen ermöglichen es weniger technischen Nutzerinnen und Nutzern, ihre Erkenntnisse mit hochwertigen Visualisierungen zu teilen – ganz ohne Code.
Unsere No-Code-Chart-Zellen in Aktion!
Das haben wir bisher gelernt
Stand Mitte Oktober haben DataCamper kumuliert 4.132 Stunden in DataLab verbracht! Wir haben inzwischen alle zentralen Reports zu Quartalszielen und Produktnutzung nach DataLab migriert. Hier sind unsere wichtigsten Learnings und wie sie DataLab als Produkt beeinflusst haben:
- Tempo ist entscheidend: Es nervt, länger als erwartet auf das Laden eines Workbooks, die Codeausführung oder Query-Ergebnisse zu warten. Die Experience sollte mindestens so schnell, idealerweise schneller sein als in einem lokal laufenden Jupyter Notebook. Unser Team hat große Fortschritte erzielt, die Ladezeiten von Notebooks und Publikationen zu reduzieren und die Codeausführung auf das Niveau eines lokalen Notebooks zu bringen.
- Nicht jeder möchte den Code sehen: Früher enthielten unsere Publikationen große Zellen mit komplexen SQL-Queries und dichtem Python-Code. Das war für technische Reviews hilfreich, verdeckte aber oft die eigentlichen Insights. Man konnte Zellen in JupyterLab innerhalb von DataLab ausblenden, im DataCamp-Notebook-Editor war das jedoch nicht sichtbar. Deshalb haben wir eine einfache Möglichkeit eingeführt, Code- und SQL-Zellen in Workbooks auszublenden. So entstehen schöne, schreibgeschützte Reports für alle Stakeholder. Unsere Nutzer lieben es.
- Notebooks immer wieder neu laufen zu lassen, ist mühsam: Für vieles Tracking verlassen wir uns auf tägliche Updates zu Nutzerzahlen, Aktivitätsleveln und Feature-Adoption. Anders als ein dynamisches Dashboard, das sich bei neuen Daten aktualisiert, müssen Workbooks jedes Mal neu ausgeführt werden. Basierend auf unseren Erfahrungen planen wir, die zeitgesteuerte Ausführung von Workbooks zu unterstützen. So enthalten Reports stets die neuesten Erkenntnisse.
Und das sind nur die großen Learnings – daneben gab es viele kleine Verbesserungen am Editor seit dem Wechsel zu DataLab. Die Benutzeroberfläche, das Dashboard und Features wie Chart-Zellen werden kontinuierlich optimiert – getrieben durch Feedback von internen und externen Nutzern.
Der Blick nach vorn
Unser eigenes Produkt im Einsatz zu haben, zeigt viele Stellschrauben für Verbesserungen – das ist aber nur die halbe Miete. Ergänzend zu internem Feedback führt unser Team intensive Interviews mit DataLab-Nutzern. Diese Gespräche bestätigen unsere Beobachtungen und helfen uns, blinde Flecken aus internen Tests zu schließen.
Außerdem haben wir Ende September eine Umfrage über unseren zweiwöchentlichen Newsletter gestartet. So konnten wir quantitative Rückmeldungen sammeln. Die Ergebnisse helfen uns, Initiativen mit höchster Priorität für DataLab zu identifizieren und zu verstehen, wie unser Produkt eingesetzt wird. Und natürlich haben wir die Umfragedaten in DataLab analysiert und visualisiert!
Der häufigste Grund für die Nutzung von DataLab: Codebeispiele schnell ausprobieren. Wie nutzt du DataLab?
In den kommenden Monaten wollen wir unsere Analytics-Umgebung noch stärker auf DataLab fokussieren. Mit jeder neuen Funktion und Verbesserung unseres Engineering-Teams wird dieser Schritt einfacher.
Wenn du DataLab für deine internen Data-Analytics- und Data-Science-Anforderungen nutzen möchtest, findest du hier weitere Infos. Oder besser noch: Starte direkt mit einem leeren Python- oder R-Workbook und leg los!
