Optimizely Warehouse-Native Analytics vs. Tableau

Optimizely Warehouse-Native Analytics ist eine Plattform für Produkt- und Kundenanalyse. Tableau ist eine Business-Intelligence-Plattform (BI). In unseren Kundengesprächen werden wir oft gefragt: Wann sollte ich Optimizely Warehouse-Native Analytics verwenden und wann Tableau? Dieser Blog beantwortet die Frage und gibt Orientierung zur Nutzung der beiden Tools. 

Nachfolgend der Vergleich der beiden Tools basierend auf Funktionen und der Art der Analyse, die von Business- und Datenteams durchgeführt wird.

Sehen wir uns jede Zeile einzeln an.

Behavioral Analytics

Optimizely Warehouse-Native Analytics bietet einen reichhaltigen Satz UI-gesteuerter Vorlagen, die speziell für Behavioral Analytics gebaut sind und von Business-Nutzern und Data Engineers genutzt werden können, ohne dass SQL geschrieben werden muss. Optimizely Warehouse-Native Analytics optimiert Abfragen an das Data Warehouse für die besten Kosten-/Leistungsverhältnisse. Alle von Optimizely Warehouse-Native Analytics generierten Berichte sind interaktiv, um iterativ immer tiefere Analysen durchzuführen.

Tableau ist nicht für Behavioral Analytics konzipiert, weil es keine event-orientierte Plattform ist. Behavioral Analytics in Tableau muss durch das Schreiben von SQL erfolgen, was sehr komplex und umständlich aufzubauen und zu pflegen ist. Tableau hat kein natives Verständnis von Zeitreihen, Kohorten, Trichtern usw., um Abfragen zu optimieren, was zu schlechter Performance und hohen Warehouse-Kosten führt. Selbst wenn eine Visualisierung in Tableau (mühsam) mit SQL konstruiert werden kann, ist sie nicht interaktiv. Jede Anschlussfrage muss zu einer Anfrage an das Datenteam führen, einen neuen Tableau-Bericht zu erstellen.

Production Reporting

Die spezialisierten Behavioral-Analytics-Vorlagen von Optimizely Warehouse-Native Analytics, die reichhaltige Bibliothek an Modellierungsvorlagen und die generischen visuellen Explorationsoberflächen ermöglichen Self-Service-Ad-hoc-Datenexploration durch Business-Nutzer, ohne dass SQL geschrieben werden muss.

Tableau ist für Data Engineers konzipiert. Es hat eine komplexe Builder-Oberfläche, typischerweise im Desktop-Client. Es eignet sich nicht für Self-Service durch Business-Nutzer.

Spezialisierte, einmalige Analysen

Optimizely Warehouse-Native Analytics verfügt über reichhaltige Self-Service-Reporting- und Dashboarding-Funktionen, mit dem zusätzlichen Vorteil, Behavioral Analytics nahtlos in dimensionales Reporting zu integrieren – z. B. eine Kohorte von Nutzern zu nehmen, die zwischen zwei Phasen eines Trichters abgesprungen sind, und Kennzahlen für diese Kohorte nach verschiedenen Dimensionen aufzuschlüsseln. In Szenarien, in denen Business-Teams Behavioral Analytics, BI-Reporting und Dashboarding im selben Tool benötigen, dient Optimizely Warehouse-Native Analytics als dieses einzige integrierte Tool. Beachten Sie, dass in diesem Szenario Optimizely Warehouse-Native Analytics auch von Datenteams genutzt wird, die Business-Teams möglicherweise beim Aufbau fortgeschrittenerer Analysen helfen, mit dem Vorteil, kollaborativ im selben Tool bauen zu können.

Die Herausforderung bisher ist, dass Produktanalyse und BI getrennte Systeme waren. Wenn ein Nutzer in einem Produktanalyse-Tool der ersten Generation die nächste Ebene an Fragen hat, muss er seine Data-Engineering-Teams anrufen, um einen einmaligen Bericht in einem BI-Tool zu erstellen. Das Data-Engineering-Team muss Daten aus dem Produktanalyse-Tool in ein Data Warehouse exportieren und umständliches SQL schreiben, um den Bericht zu erstellen – das könnte Wochen dauern. Darüber hinaus haben Sie nun fragmentierte Analysen in zwei getrennten Systemen, die nicht nahtlos genutzt werden können. 

Bei Optimizely Warehouse-Native Analytics haben wir unser System von Grund auf für den Modern Data Stack architektiert. Wir haben eine Architektur entworfen, die die Welten event- und zustandsorientierter Systeme überbrückt. Wir haben dies getan, indem wir mit einem traditionellen relationalen Modell begonnen und ein Event-Modell darüber gelegt haben. Das traditionelle relationale Modell ermöglicht dimensionale Slice-and-Dice-Analysen im BI-Stil aus einer Self-Service-Produktanalyse-Plattform. Lesen Sie diesen Blog, um mehr zu erfahren.

Produktanalyse-Tools der ersten Generation wie Mixpanel und Amplitude entstanden vor einem Jahrzehnt, als Mobile Apps und SaaS-Services allgegenwärtig wurden und BI-Tools, Customer 360 und Data Warehouses der Aufgabe noch nicht gewachsen waren. Sie verschafften Produktteams schnell ein Verständnis des Nutzerverhaltens innerhalb des Produkts und halfen ihnen, Produktfunktionen zu verbessern. Leider waren diese Tools isoliert, nur mit Produkt-Instrumentierungsdaten, was ihren Wert auf Produkt- und Feature-Ebene-Kennzahlen begrenzte. Keine bedeutenden geschäftswirksamen Entscheidungen konnten getroffen werden – und schon gar nicht solche, die die C-Suite interessierten.

Da Software zunehmend als Abonnement-SaaS-Service konsumiert wird, wollen funktionsübergreifende Product-Led-Growth-Teams nun das Produktanalyse-Silo beseitigen und Produkt- und Kunden-Geschäftsdaten (Vertrieb, Support, Finanzen, Marketing, Success usw.) für eine gemeinsame, konsistente 360°-Sicht über alle Kunden-Touchpoints hinweg kombinieren – im Produkt oder außerhalb des Produkts, für geschäftswirksame Analysen. Lesen Sie diesen Blog, um zu erfahren, wie wir mit Fortschritten bei Cloud-Data-Warehouses mit Customer Analytics den Kreis geschlossen haben.