Die Zusammenführung von BI & Product Analytics

Als datengetriebene Organisation nutzen Sie wahrscheinlich mehrere Analyse-Tools, um verschiedene analytische Anwendungsfälle abzudecken:

Während die letzten beiden, Infrastruktur-Monitoring und Machine Learning (ML), spezialisierte Tools sind, die wahrscheinlich getrennt bleiben, verschwimmen die Grenzen zwischen Business Intelligence (BI) und Product Analytics. 

Warum verschwimmen die Grenzen zwischen BI und Product Analytics? Historisch konzentrierte sich Product Analytics darauf, nur Streams der Produktinstrumentierung zu analysieren, um Produktmanagern Einblick in die Produktnutzung zu geben. Tools der ersten Generation wie Amplitude und Mixpanel haben traditionelle Product Analytics zum Mainstream gemacht. Ihre isolierte Sichtweise war jedoch immer sehr einschränkend. Dies wird in jüngster Zeit durch PLG-getriebene Ansätze weiter verschärft, bei denen Unternehmen einen 360-Grad-Blick auf ihre Kunden wünschen – über alle Interaktionskanäle hinweg und unter Einbeziehung des Kontexts aus allen Geschäftssystemen. Schwache Versuche, dies in Tools der ersten Generation mit simplen „Reverse-ETL“-Lösungen anzugehen, sind umständlich und unvollständig.

Stellen Sie sich ein traditionelles Product-Analytics-Tool vor, das Ihnen zeigt, dass die Conversion Rate nach der Veröffentlichung eines neuen Features gestiegen ist. Doch was, wenn die Mehrheit der Kunden, die konvertiert haben, am Ende durch einen Anruf bei Ihrem Callcenter gekündigt hat? Diese Daten befinden sich nicht im isolierten Stream der Produktinstrumentierung, mit dem traditionelle Tools arbeiten. Sie liegen in einem anderen Geschäftssystem, das für Product-Analytics-Tools der ersten Generation unzugänglich ist. Können Sie ebenso die Auswirkung einer Produktänderung auf Support-Tickets/-Anrufe verstehen – Daten, die in Zendesk liegen? Können Sie das Produkt-Engagement nach Abonnementstufe verstehen – Daten, die in Salesforce liegen? Können Sie auf Produktfriktion oder gesteigertes Engagement in Accounts hingewiesen werden, deren Verlängerung in einem Monat ansteht – Daten, die in NetSuite liegen? 

Können Sie Abonnementumsätze nach Kundenkohorten aufschlüsseln? Können Sie Produktprobleme nach ihrer Auswirkung auf den Umsatz priorisieren? Können Sie die richtige Gruppe von Kunden mit den richtigen Kampagnen/Angeboten/Nurture-Maßnahmen auf Basis ihres Customer Lifetime Value ansprechen?

Es reicht nicht mehr aus, eng definierte Produktkennzahlen allein auf Basis von Produktinstrumentierungsdaten zu verstehen. Während sich moderne Unternehmen zu produktgetriebenem Wachstum entwickeln, werden Produktteams schnell zu Umsatzzentren und müssen von Produktkennzahlen zu Geschäftskennzahlen aufsteigen, wobei Produktinstrumentierungsdaten nur eine Eingabequelle sind. Sie brauchen ein Business-Analytics-Tool, das einen breiteren Blick bietet. Sie brauchen Business Analytics, die wirkungsvoller und einflussreicher gegenüber der C-Ebene ist.

Traditionelle Product Analytics dienten in erster Linie nur Produktmanagern. Doch mehrere andere Teams in modernen Unternehmen benötigen im Kontext ihrer Geschäftsfunktionen Einblick in die Produktnutzung und das Kundenverhalten. Business Analytics sind für alle in der Organisation, denen das Produkt und ihre Kunden am Herzen liegen – Growth Marketing, Customer Success, Vertrieb und Support. Und auch Produktmanager können von einem breiteren Verständnis der geschäftlichen Auswirkung der Produktfeatures profitieren, an denen sie arbeiten.

Wie sieht also ein solches Business-Analytics-Tool aus? Es beginnt mit klassischer Product Analytics, etwa Event-Segmentierung, Retention, Funnel, Pfaden usw. Aber wir sprechen auch davon, Daten aus Geschäftssystemen einzubeziehen, über die typischerweise in BI-Tools berichtet wird. Wir sprechen davon, nahtlos vom einen zum anderen zu navigieren. Nehmen Sie zum Beispiel eine Kohorte von Nutzern, die von einer bestimmten Funnel-Stufe zur nächsten abgesprungen sind, und schlüsseln Sie sie nach verschiedenen Dimensionen wie Account, Region, Alter usw. auf. Ersteres (Funnel) ist klassische Product Analytics. Letzteres (dimensionales Slice-and-Dice) ist klassische BI. 

Die Herausforderung besteht heute darin, dass sich diese in getrennten Systemen befinden. Wenn ein Nutzer in einem Product-Analytics-Tool der ersten Generation also die nächste Ebene von Fragen hat, muss er seine Data-Engineering-Teams anrufen, damit sie ihm einen einmaligen Report in einem BI-Tool erstellen. Das Data-Engineering-Team muss Daten aus dem Product-Analytics-Tool in ein Data Warehouse exportieren und umständliches SQL schreiben, um den Report zu erzeugen – das kann Wochen dauern. Darüber hinaus haben Sie nun fragmentierte Analysen in zwei getrennten Systemen, die nicht nahtlos zusammen genutzt werden können. Was wäre zum Beispiel, wenn Sie aus einem BI-Report eine Kohorte von Nutzern erstellen und sie nutzen wollten, um die Journeys zu verstehen, die diese Nutzer im Produkt zurückgelegt haben? Das ist heute praktisch unmöglich.

Die landläufige Meinung besagt, dass man in einem BI-Tool keine Product Analytics betreiben kann oder in einem Product-Analytics-Tool keine BI. Das war einmal wahr. 

Traditionelle Product-Analytics-Tools können heute nicht auf einem Warehouse arbeiten, wie es BI-Tools können. Sie verfügen nicht über eine generische Datenmodellierungs- oder analytische Ausdrucksschicht wie BI. Sie sind für einen bestimmten Anwendungsfall maßgeschneidert und keine generischen Analyseplattformen wie BI.

BI-Tools wiederum eignen sich nicht für die Formulierung ereignisorientierter Abfragen, die Sequenzen, Pfade, Flows und Zeitreihen umfassen. Solche Abfragen in SQL auszudrücken ist äußerst umständlich. Darüber hinaus performt das von ihnen generierte SQL für interaktive Analysen nicht gut.

Diese beiden Systemtypen wurden unterschiedlich konzipiert – einer ereignisorientiert und einer zustandsorientiert.

Doch diese Systeme wurden vor Jahrzehnten entworfen. Was, wenn Sie von Grund auf neu beginnen und ein System konzipieren könnten, das beiden Zwecken dient? Was, wenn BI und Product Analytics in einer Plattform zusammengeführt werden könnten? Der Geschäftswert eines solchen zusammengeführten Tools wäre enorm!

Generationswechsel bei Analyse-Tools gehen oft mit großen Verschiebungen in den Datenarchitekturen einher. Heute erleben wir eine Verschiebung hin zum Modern Data Stack. 

Im Zentrum des Modern Data Stack steht ein Cloud Data Warehouse wie Snowflake oder BigQuery. Diese Data Warehouses sind das zentrale Repository aller Daten in modernen Unternehmen. Sogar Daten wie Events der Produktinstrumentierung oder IoT-Sensorwerte, die es traditionell nie ins Data Warehouse geschafft haben, werden nun dort gespeichert. Das ist die primäre Verschiebung.

Die zweite Verschiebung ist das Aufkommen der modularen CDP. Eine modulare CDP bedeutet, Best-of-Breed-Systeme zu verwenden, die auf dem Data Warehouse zentralisiert sind. Das bedeutet:

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 ereignis- und zustandsorientierter Systeme überbrückt. Wir sind warehouse-native, wobei alle Berechnungen innerhalb des Data Warehouse stattfinden und niemals Daten das Warehouse verlassen. Wir bieten spezialisierte Templates für Product Analytics, stellen aber auch BI-artige Ad-hoc-Explorationsanalysen bereit – alles über eine Self-Service-Oberfläche. 

Wir haben dies erreicht, indem wir mit einem traditionellen relationalen Modell begonnen und ein Event-Modell darübergelegt haben. Letztlich sind die generierten Abfragen also SQL, das gegen das Warehouse ausgeführt wird. Das traditionelle relationale Modell ermöglicht BI-artige dimensionale Slice-and-Dice-Analysen. Die Event-Modell-Schicht ermöglicht reiche Ausdrucksfähigkeit und Optimierungen für spezialisierte Product-Analytics-Reports. Eine spezialisierte Sprache namens NetScript bietet eine Abstraktionsschicht für optimierte Abfrageverarbeitung, die im Warehouse gut performen kann.

Wir glauben, dass BI und Product Analytics effektiv in einem einzigen Tool durchgeführt werden können. Das hat enorme Vorteile in Bezug auf Kosten, Governance, Sicherheit und geschäftswirksame Analysen.

So wie das Data Warehouse Datensilos beseitigt, beseitigen Business-Analytics-Systeme wie Optimizely Warehouse-Native Analytics Analytics-Silos. Ein einziges Analyse-Tool auf einem einzigen zentralen Warehouse – dieser Traum wird jetzt wahr. Und Unternehmen haben gute Gründe, ihn anzunehmen und zu feiern.