Sie sind ein produktorientiertes Unternehmen, das schnell expandiert. Ihre Geschäftsmethodik ist das produktgesteuerte Wachstum (PLG), bei dem Benutzerakquisition, Conversion, Engagement, Bindung und Expansion produktgesteuert sind. Daher sehnen sich Ihre Produkt-, Wachstums-, Marketing-, Vertriebs- und Success-Organisationen nach mehr Produkt- und Kundenanalysen, um die wichtigsten Triebkräfte der Geschäftsziele zu verstehen und zu beeinflussen.
Ihr Team wurde damit beauftragt, eine Analysestrategie für das Unternehmen zu entwickeln - mit einer geeigneten Architektur und geeigneten Tools. Bauen Sie intern oder kaufen Sie von externen Anbietern? In diesem Blog geht es um das moderne Architekturmuster, das Sie verwenden sollten, und um die Vor- und Nachteile von Eigenentwicklungen und gekauften Tools für die Produktanalyse.
Analyse-Architektur
Die folgenden Prinzipien sind für die Architektur eines modernen Datenanalysesystems von zentraler Bedeutung:
- Warehouse-Zentrierung: Das Data Warehouse ist der zentrale Aufbewahrungsort für alle Daten, einschließlich der Produktinstrumentierungsdaten und der Daten aus den Geschäftssystemen.
- ELT (Extrahieren, Laden, Transformieren): Verwendung von ELT im Gegensatz zu ETL. Die Datenumwandlung erfolgt im Warehouse mit Warehouse-zentrierten Tools wie DBT. Rohdaten, wie z.B. Ereignisdaten, werden im Warehouse in nativer Form gespeichert und stehen in roher oder umgewandelter Form zur Verfügung, je nachdem, was der konsumierende Kunde benötigt. Keine Datenverluste oder Beeinträchtigungen der Datentreue.
- Entkoppelte Instrumentierung: Die SDKs und Bibliotheken für die Produktinstrumentierung sind von den Analysetools entkoppelt. Verwendung von erstklassigen Tools wie Segment, Snowplow und Rudderstack zur Instrumentierung von Produkten und Apps, wobei die Daten direkt im zentralen Data Warehouse des Unternehmens landen. Diese Daten liegen in einem offenen Format vor, das in vertrauten relationalen Modellen im Warehouse gespeichert ist und von jedem Analysetool problemlos genutzt werden kann.
- Warehouse-native Analysen: Alle Analysetools sollten sich mit dem Warehouse verbinden und direkt mit diesen Daten arbeiten. Es sollten keine Daten aus dem zentralen Data Warehouse kopiert werden - dies ist aus Gründen der Kosten, der Sicherheit, der Governance, der Genauigkeit und der Verwaltbarkeit entscheidend.
Abbildung 1: Der moderne Datenstapel für Analysen
Bauen oder kaufen
Unter der Annahme, dass Sie die oben beschriebenen architektonischen Muster befolgen, sollten wir uns klarmachen, wie Build versus Buy für die Produktanalytik aussieht. Hier sind einige Szenarien, an die Sie vielleicht schon gedacht haben:
Erstellen Szenario 1:
Mir ist klar, dass die Produktanalytik sehr spezialisiert ist. Aber wir sind ein technikaffines Unternehmen, das komplexe Produkte herstellt. Wir können selbst ein Produktanalysetool entwickeln.
Vorteile
- Volle Kontrolle über das Tool, das auf die Bedürfnisse Ihres Unternehmens zugeschnitten werden kann.
- Keine zusätzlichen Kosten für die Lizenzierung externer Produkte.
- Keine Sicherheits- und Compliance-Probleme mit Datenbewegungen oder der Nutzung externer SaaS-Dienste.
Nachteile
- Massive Investitionen in ein großes Team, um ein solch spezialisiertes, komplexes Tool zu entwickeln. Kann um ein Vielfaches teurer sein als die Lizenzierung eines Produkts, das ausschließlich auf Analysen ausgerichtet ist.
- Risiko des Verfalls des Produkts und versunkener Investitionen, wenn wichtige Mitglieder des Teams das Unternehmen verlassen.
- Verlorene Chance, die Investition in das Produkt-Analyse-Tool an anderer Stelle zu nutzen, wo es für Ihr Unternehmen vielleicht wichtiger ist.
Aufbau-Szenario 2:
Mein Data-Engineering-Team verfügt über gute SQL-Kenntnisse. Ich kann dies mit SQL-Tools wie Mode oder Notebooks tun.
Vorteile
- Niedrige Kosten für SQL-Editor-Tools.
- Dateningenieure können spezielle Analysen mit SQL erstellen, die sie gewohnt sind und gut beherrschen.
- Die grundlegende Visualisierung, die diese Tools bieten, kann für Ihre Kunden gut genug sein.
- SQL-Tools arbeiten direkt mit den Daten im Data Warehouse. Sie entsprechen also dem modernen Architekturmuster, das Sie unterstützen. Sie können den Analysen vertrauen, da sie direkt mit den Stammdaten im Data Warehouse arbeiten und nicht mit einer Kopie.
Nachteile
- Geschäftsanwender können sich nicht selbst um Analysen kümmern und müssen sich auf Datenanalysten verlassen und darauf warten, dass diese für jede Anfrage Berichte erstellen.
- SQL für Abfragen zur Produktanalyse ist nicht skalierbar, komplex und mühsam zu schreiben und zu pflegen. Enorme Belastung der Datenanalysten durch wiederholte Anfragen aus dem Unternehmen.
- Spezialisierte Visualisierungen und Modellierungskonstrukte wie Zeitreihen, Kohorten, Trichter und Pfade sind in einfachen SQL-Tools nicht verfügbar.
- Die erstellten Berichte sind nicht interaktiv für die nächste Analyseebene, z.B. für die Untersuchung von Benutzern, die zwischen zwei Stufen in einem Trichter abgebrochen haben.
- Rohes SQL für Abfragen zur Produktanalyse ist nicht leistungsfähig und kann ungewöhnlich langsam sein. Analysten müssen für Cubing, Tuning, Pre-Processing, Sampling usw. mit Data-Engineering-Teams zusammenarbeiten, um Leistungsprobleme zu lösen.
Erstellen Sie Szenario 3:
Ich habe bereits Tableau. Ich werde es nur für Product Analytics verwenden.
Vorteile
- Keine neuen Ausgaben durch die Verwendung eines Tools, für das bereits bezahlt wurde.
- Sie müssen kein neues Tool erlernen, da Sie ein vertrautes Tool verwenden, das bereits im Einsatz ist.
- BI-Tools wie Tableau arbeiten direkt mit den Daten im Data Warehouse. Sie entsprechen also dem modernen Architekturmuster, das Sie unterstützen.
- Sie können den Analysen vertrauen, da sie direkt mit den Stammdaten im Data Warehouse arbeiten und nicht mit einer Kopie.
Nachteile
- BI-Tools eignen sich nicht für die Formulierung ereignisorientierter Produktanalyseabfragen, die Kohorten, Sequenzen, Pfade, Flüsse und Zeitreihen umfassen. Geschäftsanwender können sich also nicht selbst bedienen und müssen sich auf Data Engineering verlassen.
- Dateningenieure müssen mit Low-Level-SQL arbeiten. SQL für Produktanalyseabfragen ist nicht skalierbar, komplex und mühsam zu schreiben und zu pflegen. Enorme Belastung der Data-Engineering-Teams durch wiederholte, oft banale Anfragen aus dem Unternehmen.
- BI-Tools sind für Abfragen zur Produktanalyse nicht geeignet und können für viele Anwendungsfälle unbrauchbar sein. Die Datentechnik muss in Cubing, Tuning, Pre-Processing, Sampling usw. investieren, um Leistungsprobleme zu lösen.
- Die Interaktionen in BI-Berichten beschränken sich auf traditionelles dimensionales Drilling und verstehen die Semantik der Produktanalyse nicht, z.B. das Drilling nach Benutzern, die zwischen zwei Stufen in einem Trichter abgebrochen haben, und die Anzeige aller Pfade, die sie vor dem Abbruch genommen haben.
Kaufszenario 1:
Ich gehe auf Nummer sicher und entscheide mich für ein traditionelles Tool der ersten Generation wie Amplitude, das es schon seit mehr als einem Jahrzehnt gibt.
Vorteile
- Geringes Risiko durch den Kauf eines traditionellen Tools, das Reife erlangt hat und bekanntermaßen funktioniert.
- Es lassen sich Mitarbeiter finden, die wissen, wie man mit diesem Tool arbeitet, da es schon lange im Einsatz ist.
- Geschäftsanwender können sich mit einfachen Berichtsvorlagen, die speziell für die Produktanalyse entwickelt wurden, selbst bedienen.
Nachteile
- Sie müssen kostspielige ETL-Jobs erstellen und pflegen, um Daten aus dem Warehouse in Produktanalysetools der ersten Generation zu übertragen, da diese Tools nicht direkt mit dem Data Warehouse arbeiten können.
- Verstößt gegen Ihr architektonisches Grundprinzip der Zentrierung des Warehouse und der Nichtverlagerung von Daten aus Ihrem Unternehmensspeicher. Sicherheits- und Governance-Risiken, wenn kritische Kundendaten an einen Blackbox-SaaS-Dienst eines Anbieters ausgelagert werden.
- Die Zahlen in Tableau und Amplitude stimmen oft nicht überein, weil sie auf unterschiedlichen Datenkopien basieren. Wochenlanger Abgleich von widersprüchlichen Zahlen. Trauen Sie den Zahlen im Produktanalysetool nicht, da es oft mit veralteten oder unvollständigen Kopien der Stammdaten im Warehouse arbeitet. Sie können dies niemals der Unternehmensleitung vorlegen.
- Die ereignisabhängige Preisgestaltung von Produktanalysetools wie Amplitude macht sie unerschwinglich teuer. Es gibt keine einfache Möglichkeit, ungenutzte Ereignisse zu löschen. Sie zahlen unnötigerweise für Ereignisse, egal ob jemand sie nutzt oder nicht. Jeden Monat ein enormer Aufwand, um herauszufinden, welche Ereignisse an das Produktanalysetool gesendet werden sollen (und welche nicht), um die Kosten zu kontrollieren.
- Da das Tool der ersten Generation mit einem bestimmten Datenmodell und einem Ein-Tabellen-Rechnersystem entwickelt wurde, können Sie nicht über einfache Berichtsvorlagen hinausgehen. Explorative Ad-hoc-Analysen, insbesondere mit zusätzlichem Geschäftskontext wie Konten, Verträgen, Tickets, Supportanfragen usw., sind nicht möglich. Folglich müssen die Daten aus dem Tool per ETL in das Data Warehouse übertragen werden, wo sie von den Data Engineering-Teams weiter analysiert werden. Zusätzliche ETL-Kopfschmerzen.
- Die Unternehmensteams beginnen mit den Tools der ersten Generation, stoßen aber schnell an Grenzen. Sie müssen sich an die Datentechnik wenden, um Daten zu exportieren und benutzerdefinierte, einmalige Berichte zu schreiben, was Wochen dauern kann. Am Ende haben Sie fragmentierte Analysen in zwei separaten Systemen.
Kauf-Szenario 2:
Ich möchte ein Produktanalysetool der nächsten Generation kaufen, das mich nicht dazu zwingt, Daten aus meinem Data Warehouse zu verschieben.
Sehen Sie sich Optimizely Warehouse-Native Analytics an, ein Self-Service-Tool für die Produktanalyse, das Sie nicht zwingt, Daten aus Ihrem Data Warehouse zu verschieben. Wir sind die erste wirklich warehouse-native Produktanalyseplattform - keine Daten verlassen jemals Ihr sicheres Data Warehouse.
Abbildung 2: Produktanalyse der nächsten Generation mit Optimizely Warehouse-Native Analytics
Optimizely Warehouse-Native Analytics bringt die Ad-hoc-Analyseleistung von BI in die Welt der Produktanalyse. Mit umfangreichen Vorlagen für die Produktanalyse und visuellen Funktionen für die Ad-hoc-Datenexploration ermöglicht Optimizely Warehouse-Native Analytics Geschäftsanwendern die Selbstbedienung auch für ihre fortgeschrittenen Anforderungen. Erstellen Sie komplexe Trichter über Ereignisströme mit bedingten Stufen, und das alles in einer Umgebung ohne Code, anstatt seitenweise blutiges SQL zu schreiben.
Video ansehen: Vergleich von Optimizely Warehouse-Native Analytics mit der SQL-Entwicklung für die Erstellung eines 4-stufigen Trichters und das anschließende Hinzufügen eines Filters
Optimizely Warehouse-Native Analytics generiert automatisch elegantes SQL für die anspruchsvollsten Produktanalyseabfragen und gibt Power-Analysten und Dateningenieuren volle SQL-Unterstützung und erweiterte Funktionen für die Skripterstellung an die Hand. Die meisten Ihrer anspruchsvollen Fragen lassen sich jedoch problemlos innerhalb der vollständig selbstverwalteten Plattform beantworten.
Über den Autor
Entrepreneur, executive and product leader with a proven track record of conceiving and building innovative, successful, large-scale software systems Company builder...
