Optimizely Warehouse-Native Analytics vs. Looker

Optimizely Warehouse-Native Analytics ist eine Plattform für Produkt- und Kundenanalyse. Looker ist eine Business Intelligence (BI)-Plattform. Bei unserem Customer Engagement wird uns oft die Frage gestellt: Wann sollte ich Optimizely Warehouse-Native Analytics und wann Looker verwenden? Dieser Blog befasst sich mit dieser Frage und bietet eine Anleitung zur Verwendung beider Tools.

Nachfolgend finden Sie einen Vergleich der beiden Tools anhand ihrer Funktionen und der Art der Analysen, die von Geschäfts- und Datenteams durchgeführt werden.

Lassen Sie uns jede Zeile einzeln betrachten.

Verhaltensbasierte Analytik

Optimizely Warehouse-Native Analytics bietet eine Vielzahl von UI-gesteuerten Vorlagen, die speziell für Verhaltensanalysen entwickelt wurden und von Geschäftsanwendern und Datentechnikern verwendet werden können, ohne dass sie SQL schreiben müssen. Optimizely Warehouse-Native Analytics optimiert Abfragen an das Data Warehouse für ein optimales Kosten/Leistungs-Verhältnis. Alle von Optimizely Warehouse-Native Analytics erstellten Berichte sind interaktiv, so dass Sie iterativ immer tiefer gehende Analysen durchführen können.

Looker ist nicht für die Verhaltensanalyse konzipiert, da es sich nicht um eine ereignisorientierte Plattform handelt. Für die Verhaltensanalyse in Looker muss SQL geschrieben werden, was sehr komplex und mühsam zu erstellen und zu pflegen ist. Looker hat kein natives Verständnis von Zeitreihen, Kohorten, Trichtern usw., um Abfragen zu optimieren, was zu schlechter Leistung und hohen Lagerkosten führt. Selbst wenn eine Visualisierung in Looker mit SQL (mühsam) erstellt werden kann, ist sie nicht interaktiv. Jede Folgefrage führt zu einer Anfrage an das Datenteam, einen neuen Looker-Bericht zu erstellen.

Produktion von Berichten

Looker ist im Grunde ein Reporting-Tool, das in erster Linie für das Produktionsreporting entwickelt wurde.

Optimizely Warehouse-Native Analytics verfügt zwar über eine reichhaltige Berichts- und Dashboarding-Schicht, aber noch nicht über einige der Visualisierungsfunktionen wie Geo-Maps, erweiterte strategisch neu ausgerichtete Pivot-Tabellen, Finanzberichte, geplante Berichtsverteilung usw.

Explorative Ad-hoc-Analytik

Die spezialisierten Vorlagen für Verhaltensanalysen von Optimizely Warehouse-Native Analytics, die umfangreiche Bibliothek mit Modellierungsvorlagen und die generischen visuellen Explorationsschnittstellen ermöglichen die Ad-hoc-Datenexploration durch Geschäftsanwender im Self-Service-Verfahren, ohne dass sie SQL schreiben müssen.

Looker wurde für Dateningenieure entwickelt und erfordert Skripterstellung mit einer speziellen LookML-Modellierungssprache und das Schreiben von SQL. Es ist nicht für die Selbstbedienung durch Geschäftsanwender geeignet.

Spezialisierte, einmalige Analysen

Looker wurde für SQL-erfahrene Data Scientists/Engineering-Teams entwickelt, die die volle Leistungsfähigkeit von SQL benötigen und die Skripterstellung mit der Modellierungssprache LookML für spezielle, einmalige Analysen beherrschen.

Optimizely Warehouse-Native Analytics bietet volle SQL-Unterstützung und eine leistungsstarke Skripting-Abstraktion über SQL, NetScript genannt. Es bietet jedoch keine skriptbasierte Modellierung mit eingebetteten SQL-Blöcken wie LookML.

Self-Service-Berichterstattung

Optimizely Warehouse-Native Analytics verfügt über umfangreiche Funktionen für Self-Service-Reporting und Dashboarding, mit dem zusätzlichen Vorteil, dass Verhaltensanalysen nahtlos in das dimensionale Reporting integriert werden können. Nehmen Sie z.B. eine Kohorte von Benutzern, die zwischen zwei Stufen eines Trichters abgebrochen sind, und schlüsseln Sie die Metriken für diese Kohorte nach verschiedenen Dimensionen auf. In Szenarien, in denen Unternehmensteams Verhaltensanalysen, BI-Reporting und Dashboarding in einem einzigen Tool benötigen, dient Optimizely Warehouse-Native Analytics als dieses einzige integrierte Tool. Beachten Sie, dass Optimizely Warehouse-Native Analytics in diesem Szenario auch von Datenteams verwendet wird, die den Geschäftsteams bei der Erstellung fortgeschrittener Analysen helfen, mit dem Vorteil, dass sie gemeinsam im selben Tool arbeiten können.

Die Zusammenführung von Product Analytics und BI

Die Herausforderung bestand bisher darin, dass Product Analytics und BI getrennte Systeme waren. Wenn ein Benutzer in einem Produktanalysetool der ersten Generation die nächste Stufe von Fragen hat, muss er sein Data-Engineering-Team anrufen, damit es ihm einen einmaligen Bericht in einem BI-Tool erstellt. Das Data-Engineering-Team muss Daten aus dem Produktanalysetool in ein Data Warehouse exportieren und umständliches SQL schreiben, um den Bericht zu erstellen - das kann Wochen dauern. Außerdem haben Sie jetzt 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 konzipiert. Wir haben eine Architektur entworfen, die die Welten der ereignis- und zustandsorientierten Systeme überbrückt. Dazu haben wir mit einem traditionellen relationalen Modell begonnen und ein Ereignismodell darüber gelegt. Das traditionelle relationale Modell ermöglicht dimensionale Slice-and-Dice-Analysen im BI-Stil über eine Self-Service-Plattform für Produktanalysen. Lesen Sie diesen Blog, um mehr zu erfahren.

Die Entwicklung von Product Analytics zu Customer Analytics

Produktanalysetools der ersten Generation wie Mixpanel und Amplitude kamen vor einem Jahrzehnt auf, als Mobile Apps und SaaS-Dienste allgegenwärtig wurden und BI-Tools, Customer 360 und Data Warehouses dieser Aufgabe noch nicht gewachsen waren. Sie vermittelten den Produktteams schnell ein Verständnis für das Nutzerverhalten innerhalb des Produkts und halfen ihnen, die Produktfunktionen zu verbessern. Leider waren diese Tools isoliert und enthielten nur Daten zur Produktinstrumentierung, was ihren Wert auf Produkt- und Funktionskennzahlen beschränkte. Es konnten keine wichtigen geschäftsrelevanten Entscheidungen getroffen werden - und schon gar nicht solche, die für die C-Suite von Bedeutung waren.

Da Software zunehmend als SaaS-Services im Abonnement genutzt wird, wollen funktionsübergreifende, produktgesteuerte Wachstumsteams nun das Silo der Produktanalyse auflösen und Produkt- und Kundengeschäftsdaten (Vertrieb, Support, Finanzen, Marketing, Erfolg usw.) kombinieren, um eine gemeinsame, konsistente 360°-Ansicht zu erhalten, die alle Berührungspunkte mit dem Kunden umfasst - sowohl innerhalb als auch außerhalb des Produkts - und so geschäftswirksame Analysen ermöglicht. Lesen Sie diesen Blog, um zu erfahren, wie sich mit den Fortschritten bei Cloud Data Warehouses der Kreis bei Customer Analytics schließt.