Produktanalysen: Build vs. Buy

Vijay GanesonVijay Ganeson
16. Feb. 2023

Ihre Geschäftsmethodik ist Product-Led Growth (PLG), bei der Nutzergewinnung, Conversion, Engagement, Kundenbindung und Expansion produktgetrieben sind.

Sie sind ein produktgetriebenes Unternehmen, das rasant wächst. Ihre Geschäftsmethodik ist Product-Led Growth (PLG), bei der Nutzergewinnung, Conversion, Engagement, Kundenbindung und Expansion produktgetrieben sind. Infolgedessen verlangen Ihre Bereiche Product, Growth, Marketing, Sales und Success allesamt nach mehr Produkt- und Kundenanalysen, um die zentralen Treiber der Geschäftsziele zu verstehen und zu beeinflussen. 

Ihr Team wurde damit beauftragt, eine Analytics-Strategie für das Unternehmen zu entwickeln – welche Architektur einzuführen und welche Tools zu verwenden sind. Bauen Sie selbst oder kaufen Sie von externen Anbietern? In diesem Blog geht es um das moderne Architekturmuster, das eingesetzt werden sollte, sowie um die Vor- und Nachteile von Build-versus-Buy bei Tools für Produktanalysen.

Analytics-Architektur

Die folgenden Prinzipien sind zentral in der Architektur eines modernen Datenanalyse-Stacks:

  • Warehouse-Zentralität: Das Data Warehouse ist das zentrale Repository aller Daten, einschließlich der Produktinstrumentierungsdaten und der Daten aus Geschäftssystemen.
  • ELT (Extract, Load, Transform): Einsatz von ELT anstelle von ETL. Datentransformationen erfolgen im Warehouse mithilfe warehouse-zentrischer Tools wie DBT. Rohdaten, etwa Ereignisdaten, werden im Warehouse in nativer Form gespeichert und stehen je nach Bedarf des konsumierenden Clients in roher oder transformierter Form zur Verfügung. Kein Verwerfen von Daten und kein Verlust der Datentreue.
  • Entkoppelte Instrumentierung: Produktinstrumentierungs-SDKs und -Bibliotheken sind von den Analytics-Tools entkoppelt. Einsatz branchenführender Tools wie Segment, Snowplow und Rudderstack zur Instrumentierung von Produkten und Apps und zur direkten Ablage dieser Daten im zentralen Unternehmens-Data-Warehouse. Diese Daten liegen in einem offenen Format vor, gespeichert in vertrauten relationalen Modellen im Warehouse, das jedes Analytics-Tool problemlos konsumieren kann.
  • Warehouse-Native Analytics: Alle Analytics-Tools sollten sich mit dem Warehouse verbinden und direkt mit diesen Daten arbeiten. Keine Daten sollten aus dem zentralen Data Warehouse herauskopiert werden – entscheidend aus Gründen der Kosten, Sicherheit, Governance, Genauigkeit und Verwaltbarkeit. 

Abbildung 1: Der Modern Data Stack für Analytics

Build versus Buy

Angenommen, Sie folgen den oben beschriebenen Architekturmustern, lassen Sie uns verstehen, wie Build versus Buy bei Produktanalysen aussieht. Hier sind einige Szenarien, an die Sie vielleicht gedacht haben:

Build-Szenario 1:

Mir ist klar, dass Produktanalysen sehr spezialisiert sind. Aber wir sind ein technisch versiertes Unternehmen, das komplexe Produkte baut. Wir können ein Tool für Produktanalysen selbst entwickeln.

Vorteile

Volle Kontrolle über die Tools, die auf Ihre Geschäftsanforderungen zugeschnitten werden können.
Keine zusätzlichen Kosten für die Lizenzierung externer Produkte.
Keine Sicherheits- und Compliance-Probleme durch Datenbewegung oder die Nutzung externer SaaS-Dienste.

Nachteile

Enorme Investition mit einem großen Team, um ein derart spezialisiertes, komplexes Tool zu bauen. Kann ein Vielfaches dessen kosten, was die Lizenzierung eines Produkts kostet, das sich ausschließlich auf Analytics konzentriert.
Risiko von Produktverfall und versunkener Investition, falls Kernmitglieder dieses Teams das Unternehmen verlassen.
Verpasste Gelegenheit, die Investition in das Tool für Produktanalysen an anderer Stelle einzusetzen, wo sie möglicherweise stärker zum Kern Ihres Geschäfts gehört.

Build-Szenario 2:

Mein Data-Engineering-Team verfügt über starke SQL-Kenntnisse. Ich kann das mit SQL-Tools wie Mode oder Notebooks erledigen.

Vorteile

Geringe Kosten für SQL-Editor-Tools.
Data Engineers können spezialisierte Analysen mit SQL zuschneiden, mit dem sie vertraut und in dem sie stark sind.
Die grundlegende Visualisierung, die diese Tools bieten, ist für Ihre Konsumenten möglicherweise gut genug. 
SQL-Tools arbeiten direkt mit den Daten im Data Warehouse. Sie entsprechen also dem modernen Architekturmuster, dem Sie folgen. Sie können den Analysen vertrauen, da sie direkt mit den Stammdaten im Warehouse arbeiten und nicht mit irgendeiner Kopie.

Nachteile

Business-Anwender können sich nicht selbst mit Analysen versorgen und müssen sich auf Datenanalysten verlassen und auf sie warten, damit diese für jede Anfrage Berichte erstellen.
SQL für Produktanalyse-Abfragen ist unskalierbar komplex und mühsam zu schreiben und zu pflegen. Enorme Belastung für Datenanalysten durch wiederholte Anfragen aus dem Business. 
Spezialisierte Visualisierungen und Modellierungskonstrukte wie Zeitreihen, Kohorten, Trichter und Pfade sind in reinen SQL-Tools nicht verfügbar.
Die erstellten Berichte sind für die nächste Analyseebene nicht interaktiv, z. B. das Hineinzoomen in Nutzer, die zwischen zwei Stufen eines Trichters abgesprungen sind. 
Reines SQL für Produktanalyse-Abfragen ist nicht performant und kann unbrauchbar langsam sein. Analysten müssen mit Data-Engineering-Teams an Cubing, Tuning, Vorverarbeitung, Sampling usw. arbeiten, um Performance-Probleme zu umgehen.

Build-Szenario 3:

Ich habe bereits Tableau. Ich verwende einfach das für Produktanalysen.

Vorteile

Keine neuen Ausgaben, da ein bereits bezahltes Tool genutzt wird.
Kein neues Tool zu erlernen, da ein vertrautes, bereits im Einsatz befindliches Tool genutzt wird.
BI-Tools wie Tableau arbeiten direkt mit den Daten im Data Warehouse. Sie entsprechen also dem modernen Architekturmuster, dem Sie folgen. 
Sie können den Analysen vertrauen, da sie direkt mit den Stammdaten im Warehouse arbeiten und nicht mit irgendeiner Kopie.

Nachteile

BI-Tools eignen sich nicht dafür, ereignisorientierte Produktanalyse-Abfragen auszudrücken, die Kohorten, Sequenzen, Pfade, Flows und Zeitreihen umfassen. Business-Anwender können sich also nicht selbst versorgen und müssen sich auf das Data Engineering verlassen.
Data Engineers müssen mit Low-Level-SQL arbeiten. SQL für Produktanalyse-Abfragen ist unskalierbar komplex und mühsam zu schreiben und zu pflegen. Enorme Belastung für Data-Engineering-Teams durch wiederholte, oft banale Anfragen aus dem Business. 
BI-Tools sind bei Produktanalyse-Abfragen nicht performant und können für viele Anwendungsfälle unbrauchbar sein. Das Data Engineering muss in Cubing, Tuning, Vorverarbeitung, Sampling usw. investieren, um Performance-Probleme zu umgehen.
Interaktionen in BI-Berichten beschränken sich auf herkömmliches dimensionales Drilling und verstehen die Semantik von Produktanalysen nicht, z. B. das Hineinzoomen in Nutzer, die zwischen zwei Stufen eines Trichters abgesprungen sind, und das Anzeigen aller Pfade, die sie vor dem Absprung genommen haben.

Buy-Szenario 1:

Lassen Sie mich auf Nummer sicher gehen, indem ich ein traditionelles Tool der ersten Generation wie Amplitude wähle, das es seit mehr als einem Jahrzehnt gibt.

Vorteile

Geringes Risiko durch den Kauf eines traditionellen Tools, das ausgereift ist und nachweislich funktioniert.
Sie finden Menschen, die wissen, wie man dieses Tool bedient, da es schon lange existiert.
Business-Anwender können sich mit einfachen, vorgefertigten Berichten selbst versorgen, die speziell für Produktanalysen gebaut wurden.

Nachteile

Aufbau und Pflege kostspieliger ETL-Jobs, um Daten aus dem Warehouse zu Produktanalyse-Tools der ersten Generation zu verschieben, da diese Tools nicht direkt mit dem Data Warehouse arbeiten können. 
Verstößt gegen Ihr zentrales Architekturprinzip der Warehouse-Zentralität und gegen das Prinzip, dass Daten Ihren Unternehmensspeicher nicht verlassen. Risikoexposition bei Sicherheit und Governance, wenn kritische Kundendaten an den Black-Box-SaaS-Dienst eines Anbieters abfließen.
Die Zahlen stimmen zwischen Tableau und Amplitude oft nicht überein, weil sie mit unterschiedlichen Kopien der Daten arbeiten. Wochen werden mit dem Abgleich widersprüchlicher Zahlen verbracht. Vertrauen Sie den Zahlen im Produktanalyse-Tool nicht, da es oft mit veralteten oder unvollständigen Kopien der Stammdaten im Warehouse arbeitet. Sie können das niemals der C-Suite vorlegen.
Die ereignisbasierte Preisgestaltung von Produktanalyse-Tools wie Amplitude macht sie unverhältnismäßig teuer. Es gibt keine einfache Möglichkeit, ungenutzte Ereignisse zu löschen. Sie zahlen unnötig für Ereignisse, egal ob sie jemand nutzt oder nicht. Jeden Monat enormer Aufwand, um herauszufinden, welche Ereignisse an das Produktanalyse-Tool gesendet werden sollen (und welche nicht), um die Kosten zu kontrollieren.
Da das Tool der ersten Generation mit einem bestimmten Datenmodell und einem Single-Table-Compute-System konzipiert wurde, können Sie nicht über grundlegendes vorgefertigtes Reporting hinausgehen. Ad-hoc-explorative Analysen, insbesondere mit zusätzlichem Geschäftskontext wie Accounts, Verträgen, Tickets, Support-Anrufen usw., sind unmöglich. Infolgedessen müssen die Daten aus dem Tool per ETL in das Data Warehouse herausgeführt werden, damit Data-Engineering-Teams sie weiter analysieren können. Zusätzliche ETL-Kopfschmerzen.
Business-Teams beginnen mit den Tools der ersten Generation, stoßen aber schnell an eine Wand; sie müssen das Data Engineering hinzuziehen, um Daten herauszuexportieren und maßgeschneiderte Einmalberichte zu schreiben, was Wochen dauern kann. Sie enden mit fragmentierten Analysen in zwei separaten Systemen.

Buy-Szenario 2:

Ich möchte ein Produktanalyse-Tool der nächsten Generation kaufen, das mich nicht zwingt, Daten aus meinem Data Warehouse herauszubewegen.

Werfen Sie einen Blick auf Optimizely Warehouse-Native Analytics – ein Self-Service-Tool für Produktanalysen, das Sie nicht zwingt, Daten aus Ihrem Data Warehouse herauszubewegen. Wir sind die erste wirklich warehouse-native Plattform für Produktanalysen – keine Daten verlassen jemals Ihr sicheres Data Warehouse. 

Abbildung 2: Produktanalysen der nächsten Generation mit Optimizely Warehouse-Native Analytics

Optimizely Warehouse-Native Analytics bringt die Ad-hoc-Analysekraft von BI in die Welt der Produktanalysen. Mit umfangreichen Vorlagen für Produktanalysen und visuellen Ad-hoc-Datenexplorationsfunktionen ermöglicht Optimizely Warehouse-Native Analytics Business-Anwendern, sich selbst zu versorgen – sogar für ihre fortgeschrittenen Anforderungen. Bauen Sie komplexe Trichter über Event-Streams hinweg mit bedingten Stufen, alles in einer No-Code-Umgebung, anstatt seitenweise grausames SQL zu schreiben.

Video ansehen: Vergleich von Optimizely Warehouse-Native Analytics gegenüber SQL-Entwicklung beim Bau eines vierstufigen Trichters und dem anschließenden Hinzufügen eines Filters 

Optimizely Warehouse-Native Analytics generiert automatisch elegantes SQL für die anspruchsvollsten Produktanalyse-Abfragen und stattet Power-Analysten und Data Engineers außerdem mit vollständiger SQL-Unterstützung und fortschrittlichen Skripting-Funktionen aus. Doch die meisten Ihrer anspruchsvollsten Fragen lassen sich innerhalb der vollständig auf Self-Service ausgelegten Plattform mühelos beantworten.