Hallo, müde Reisende. Wahrscheinlich haben Sie schon über den modern Data Stack (MDS) gelesen, eine Reihe von Komponenten zum Sammeln und Analysieren von Daten, die für maximale Verfügbarkeit, Skalierbarkeit, einfache Handhabung und Stabilität optimiert sind. 

In diesem Artikel stellen wir vier Schlüsselfaktoren vor, die Sie bei der Auswahl der Tools in Ihrem MDS berücksichtigen sollten: Ihre Mitarbeiter, Ihre Anwendungsfälle, Ihr Budget und Ihre Zukunftspläne. 

 

First things first: Was ist überhaupt ein Modern Data Stack (MDS)?

Mit einem MDS können Sie ein benutzerfreundliches und einfach zu verwaltendes Portfolio von Tools einrichten, das eine breite Palette von Anwendungsfällen unterstützt. Und das ganz ohne dass Sie unbedingt ein spezielles Data Team, ein Budget auf Unternehmensebene oder einen paranoiden Androiden benötigen, der alle Berechnungen für Sie durchführt.  

Wie bei jedem Daten-Stack gehören dazu Tools für die Datenerfassung die Datenspeicherung oder das Warehousing, die Datentransformation sowie die Business Intelligence-/Visualisierung. Über diese Minimalausstattung hinaus gibt es viele weitere Tools, die je nach den Anforderungen Ihres Unternehmens hinzugefügt werden können, z. B. für die Katalogisierung von Daten, die Data Governance und die Orchestrierung. 

Die schiere Anzahl der verfügbaren Tools für jede Komponente oder gar das ganze Paket kann dazu führen, dass der Entscheidungsprozess überwältigenden ist. Obwohl die meisten bekannten Tools alle Kriterien für einen MDS erfüllen, variieren sie in ihrer Eignung für bestimmte Anwendungsfälle und Nutzer.  

Wenn Sie mehr über konkrete Anwendungsfälle wie Visualisierung oder die Performance von Marketing Kampagnen wissen wollen, lesen sie hier unsere Projekt Case Studies.

Lassen Sie uns nun in diesen Blog Post einsteigen und uns die 4 Schlüsselfaktoren ansehen, die Ihnen die Entscheidung erleichtern:  

Ihre Mitarbeiter*innen: Der Dreh-und Angelpunkt Ihrer MDS Entscheidung

Mitarbeiter*innen halten buchstäblich den Laden am Laufen und daher stehen sie auch im Mittelpunkt Ihrer Entscheidung. Im Folgenden finden Sie einige wichtige Fragen, die Ihnen helfen die richtigen Tools für Ihre Bedürfnisse zu finden. 

Wer sind die Hauptanwender*innen der gewonnenen Erkenntnisse?

Berücksichtigen Sie zunächst die technischen Fähigkeiten, die Datenreife, die Tools, mit denen Ihre Mitarbeitenden vertraut sind aber auch eventuelle Hürden in Bezug auf zeitliche Ressourcen oder die Bereitschaft, sich in neue Tools einzuarbeiten.  

Die Datenreife Ihrer Stakeholder (oder Endnutzer) sollte bei der Wahl des Visualisierungstools eine Rolle spielen, da sie mit diesem Tool am meisten interagieren werden. Wenn Ihre Stakeholder nicht technisch versiert sind, können Dashboards, die mit vertrauteren Tools wie Tableau oder Power BI erstellt wurden, ausreichend sein und neue Mitarbeiter leichter einarbeiten.  

Datenversiertere Stakeholder werden jedoch wahrscheinlich die Flexibilität von Self-Service-Analysetools wie ThoughtSpot, Veezoo oder sogar Hex wertschätzen, die es ihnen ermöglichen, selbst Hand anzulegen. 

Die Instandhaltung im laufenden Betrieb: Wer wird die Daten und die damit verbundenen Pipelines pflegen?

Die Gemeinkosten und die Instandhaltung eines miteinander verbundenen MDS können auf unterschiedliche Weise gehandhabt werden.  

Wenn Sie in Ihrem Team bereits über Mitarbeiter mit technischen Kenntnissen und Erfahrungen verfügen, z.B. ein vollwertiges internes Datenteam, können Sie die Tools unabhängig voneinander einrichten und einsetzen. Dies spart Kosten für die Infrastruktur und gibt Ihnen eine viel größere Flexibilität und Kontrolle über Ihren Aufbau.  

Andererseits sind vertikal integrierte Lösungen wie Y42 besser für Unternehmen mit kleinen Teams und begrenzter Bandbreite geeignet. Da die meisten Tools des Stacks bereits in einer Plattform gebündelt sind und gemeinsam verwaltet werden, können ein oder zwei Personen die Datenintegration, -speicherung und -umwandlung relativ einfach verwalten.  

Sie haben auch die Möglichkeit, Berater an Bord zu holen (wie uns!), die Sie bei der Entscheidung und Implementierung des Stacks unterstützen und Ihnen bei der Wartung helfen. 

Erfahren Sie hier mehr über unsere Data Product Service hier. 

 

Ihre Anwendungsfälle 

Wie die hyperintelligenten Mäuse mit Deep Thought herausgefunden haben, ist das Wissen um die richtigen Fragen, die man seinen Daten stellen kann, genauso wichtig, wenn nicht sogar wichtiger, als die Antwort selbst zu erhalten. Denken Sie also sorgfältig über Ihre Anwendungsfälle nach, oder mit anderen Worten, was Sie mit Ihren Daten tun wollen.  

Wie sollten Ihre Stakeholder mit den Daten interagieren – und wie oft?

Die meisten Unternehmen beginnen damit Dashboards zu erstellen, die die wichtigsten Geschäftskennzahlen zusammenfassen. Diese Berichte müssen in der Regel nur ein paar Mal am Tag mit neuen Daten aktualisiert werden. Ein gutes Beispiel wäre die Beobachtung der langfristigen Performance Ihrer Social-Media-Kampagnen über verschiedene Plattformen hinweg.   

Dieser Anwendungsfall wird von den meisten Cloud-Tools wie Airbyte oder Fivetran für die Datenintegration, dbt für die Modellierung, BigQuery oder anderen Cloud Data Warehouses für die Speicherung und BI-Tools wie Power BI oder Tableau für die Visualisierung bereits gut abgedeckt. 

Wie sollen Ihre Stakeholder Daten in der Zukunft nutzen?

Unternehmen mit einem höheren Datenreifegrad suchen oft nach Möglichkeiten, ihre Daten über reines Reporting hinaus zu nutzen. Ein solcher Anwendungsfall wäre das Zurückspielen modellierter Daten aus dem Data Warehouse an die Geschäftsdatentools. Zum Beispiel kann die Kaufhistorie eines jeden Kunden an Ihr Kundenservice-Tool gesendet werden. Dies wird in der Regel als Datenaktivierung bezeichnet und wird von Reverse-ETL-Tools wie Census unterstützt.  

Zu den komplexeren Anwendungsfällen gehören Echtzeitanalysen, Vorhersage- und Prognosemodelle sowie KI-Anwendungen, die alle entweder zusätzliche Tools oder Frontend-/Backend-Entwicklung erfordern. 

Lesen Sie unsere Modern Data Stack Case Study. 

 

Ihr Budget: Der richtige MDS muss nicht richtig teuer sein.  

Der größte Faktor für viele Unternehmen sind wohl die Kosten, was dann zu der Frage führt: 

Wieviel Geld sind Sie bereit für Ihren MDS auszugeben? 

Daten sind mit Kosten verbunden. Die im Vorfeld sichtbaren Kosten sind die für die anfängliche Einrichtung und Implementierung, aber laufende Pipelines und die Nutzung von Daten verursachen wiederkehrende Kosten, egal für welches Setup Sie sich entscheiden. Sie müssen entweder Abonnementgebühren für Cloud-Tools oder Serverkosten bezahlen.  

Cloud-Plattformen erheben Gebühren für den Dateneingang und -ausgang, die Speicherung und die Rechenkapazität. Das bedeutet, dass die Erfassung, Speicherung, Modellierung und Nutzung Ihrer Daten in Rechnung gestellt wird, insbesondere wenn Sie keine nativen Integrations- und Visualisierungstools verwenden. 

Wieviel Zeit sind Sie bereit zu investieren?

Wenn Ihr Unternehmen wächst und Ihr Team zusätzliche Tools in seine Arbeitsabläufe integriert, sollten Sie auch die Betriebskosten für das Hinzufügen neuer Datenquellen, die Behebung von Fehlern und die Anpassung an Ihre Geschäftsprozesse im Auge behalten.  

Die Bereitstellung der Open-Source-Version von Tools auf Ihren eigenen Servern ist kostengünstiger und gibt Ihnen mehr Kontrolle über Ihre Datenmodelle und Pipeline. Sie ist jedoch komplexer in der Implementierung und zeitaufwändiger im Betrieb als die kostenpflichtige Cloud-basierte Version dieser Tools. Es ist also eine Frage der Markteinführungszeit und der Opportunitätskosten. Fragen Sie sich, was in Ihrem Fall wichtiger ist: schneller zu neuen Erkenntnissen zu gelangen oder die laufenden Kosten zu minimieren? 

Ihre Vergangenheit/ Ihre Zukunft  

Zu guter Letzt sollte auch die bereits vorhandene Infrastruktur und der voraussichtliche künftige Bedarf berücksichtigt werden, wenn Sie sich entscheiden, wo Ihr MDS eingesetzt werden soll. 

Was ist bereits im Einsatz?

Wenn Ihr Unternehmen bereits hauptsächlich eine Cloud-Plattform nutzt, werden Ihre Entscheidungen für ein Tool häufig auf die Tools eingegrenzt, die von Haus aus angeboten werden oder mit Ihrer Cloud kompatibel sind.  

Auch wenn Sie keine Cloud-Plattform nutzen, bewahren Sie Ruhe! Die Implementierung eines MDS erfordert nicht unbedingt, dass Sie Ihre bisherigen Systeme erneuern und alles in die Cloud verlagern.  

Es gibt jedoch starke Argumente für Cloud-basierte Tools, insbesondere für Cloud-basierte Data Warehouses wie BigQuery oder Snowflake. Analyse-Workloads sind im Vergleich zu herkömmlichen relationalen Datenbankmanagementsystemen (RDBMS) wie PostgreSQL in der Regel leistungsfähiger.   

Bei großen Datenmengen mit mehreren zehn Millionen Zeilen, wie z.B. bei Webanalysedaten auf Event-Ebene, kann der Unterschied in der Verarbeitungszeit zwischen Minuten und Stunden liegen. Mit Feinabstimmung, Konfiguration und sorgfältiger Datenbankwartung können jedoch auch herkömmliche RDBMS, die auf Ihren vorhandenen Servern laufen, schnell sein und gleichzeitig kosteneffizient bleiben. 

Welche Tools werden Sie in der Zukunft brauchen?   

Egal für welches Setup Sie sich entscheiden, ist es wichtig sicherzustellen, dass Ihr MSD auch für die Zukunft richtig aufgestellt ist. Die Hauptaspekte, die es zu berücksichtigen gilt, sind die folgenden:   

Zugang

Sie sollten Eigentümer Ihrer Daten und der damit verbundenen Pipelines und Modelle sein und Zugriff darauf haben. Aus diesem Grund empfehlen wir unabhängig von den von Ihnen verwendeten Tools immer ein eigenes Data Warehouse. Ganz gleich ob es vor Ort oder in der Cloud betrieben wird, sollten Sie sicherstellen, dass Sie über sauber synchronisierte und getestete Backups verfügen. Vermeiden Sie es, Ihre Daten auf Plattformen von Anbietern ohne SLAs für die Datenspeicherung abzulegen. 

Betrieb und Wartung

Sie sollten in der Lage sein, Ihre Pipelines und Modelle einfach zu pflegen. Datenmodellierungstools wie dbt bieten einen SQL-Rahmen, der Datenmodelle standardisiert. Sie sind in der Regel mit versionskontrollierten Repositories wie einem GitHub-Repository kompatibel, was äußerst hilfreich ist für die Nachvollziehbarkeit und Wartungsfreundlichkeit. 

Skalierbarkeit

Wenn Ihr Unternehmen wächst, müssen die Tools in Ihrem MDS mitwachsen können. Sie sollten interoperabel sein, d.h., wenn ein Tool nicht mehr Ihren Anforderungen entspricht, sollte es problemlos ersetzt werden können, ohne dass das gesamte Setup von Grund auf neu aufgebaut werden muss.  

Fazit 

Die Wahl Ihrer Tools ist eine wichtige Entscheidung, die Sie nicht auf die leichte Schulter nehmen sollten. Es ist eine Entscheidung, mit der Sie und Ihr Team jahrelang arbeiten und für die sie bezahlen werden. Bevor Sie eine Entscheidung treffen, sollten Sie diese vier Faktoren berücksichtigen, um sich darüber klar zu werden, was genau Ihre Organisation braucht und auf welchen Gegebenheiten sie aufsetzen sollten:  

– Ihre Mitarbeiter  

– Ihre Anwendungsfälle  

– Ihr Budget  

– Ihre Vergangenheit/ Ihre Zukunft 

 

Sie wünschen sich Unterstützung beim Aufbau eines MDS? Dann wenden Sie sich gerne an uns für ein unverbindliches Gespräch. 

Aus unserer Beratungspraxis kennen wir Ihre Situation nur zu gut, dass sich die Zustimmungsraten zu den klassischen Consent-Bannern nur schwer über 70% – 80% heben lassen. Tracking, Erfassung von Kund*innendaten und Performance Marketing scheinen damit aktuell leider erste Grenzen gesetzt. Weitere Optimierungen ohne weitreichendes Nudging, also dem mittelbaren Steuern der Nutzer*innenzustimmung über eine geschickte Bannergestaltung, scheinen nahezu unmöglich.

 

Welche Implikationen hat TCF 2.0?

 

Leider erfährt diese gängige Praxis der gestalterischen und textlichen Optimierung der Consent-Banner aktuell wesentliche Einschränkungen durch die vom Interactive Advertising Bureau Europe (IAB Europe) eingeführten detaillierten Vorgaben zum Consent-Banner-Design. Diese sind im Transparency and Consent Framework 2.0 (TCF 2.0) niedergelegt. Aus unserer Sicht ist daher in Zukunft eher mit sinkenden Consent-Raten bei einer TCF 2.0 entsprechenden Macro-Consent-Einholung per Banner zu rechnen.

 

Was wäre, wenn der initiale Consent-Banner gar nicht die „single source of truth“ ist?

 

Wir wollen daher den Fokus, weg vom Macro-Consent-Banner zu Beginn des Besuchs einer Website oder App, hin zum Konzept einer Micro-Consent-Einholung an geeigneter Stelle während des Besuchs lenken. Die Bezeichnung Micro-Consent bezieht sich dabei auf einen fallspezifischen Consent, der ggf. nicht so umfänglich ausfällt, wie der übergreifende Macro-Consent. Essenziell ist dabei, dass die Consent-Einholung für den Nutzer transparent und sinnvoll erfolgt. Zudem sollte der Nutzer*in ein aus ihrer Sicht relevanter Mehrwert als Gegenwert für die Einwilligung angeboten werden.

Warum ich zustimme, wenn ich zum richtigen Zeitpunkt gefragt werde

 

Hier ein konkretes Beispiel zur Demonstration, wann ein Micro-Consent dem Macro-Consent überlegen sein kann: Vielleicht ist es Ihnen auch passiert, dass Ihre Krankenkassen-App Sie beim ersten Start nach einer Berechtigung zum Kamerazugriff per Consent-Banner gefragt hat. Da die Anfrage für die Nutzer*in an dieser Stelle nicht nachvollziehbar ist und oftmals mit der Unsicherheit einhergeht, was die Krankenkasse denn wohl im Schilde führt, sind die Zustimmungsraten entsprechend niedrig. Hier kann die Micro-Consent-Einholung zu einem späteren geeigneteren Zeitpunkt ihre volle Kraft entfalten. Sobald sich für die Nutzer*in die Notwendigkeit ergibt, eine Krankmeldung oder Rechnung an ihre Krankenkasse per App zu senden, ist die Chance für die Micro-Consent-Einholung gekommen. Der Nutzer*in werden in der Regel 3 Möglichkeiten zur Übersendung der Dokumente angeboten: per Brief, als PDF-Upload oder als Foto. Da die letztgenannte Möglichkeit oftmals die attraktivste darstellt, wird die Nutzer*in an diesem Punkt sehr gerne einem Kamerazugriff zustimmen. Es ist ihr transparent, warum der Zugriff benötigt wird. Sie erkennt die Sinnhaftigkeit und erhält den konkreten Mehrwert, die Dokumente weder in ein PDF umwandeln, noch zur Post bringen zu müssen.

 

Welche Möglichkeiten für Micro-Consents bieten sich an?

 

In der Praxis ergeben sich unzählige Möglichkeiten der sinnvollen und mehrwertstiftenden Micro-Consent-Einholung. Hier ein paar Anregungen:

  • Abspeichern wiederholter Eingaben zur Steigerung der Convenience (z.B. Standorte in Onsite-Search-Elementen)
  • Abspeichern wiederholter Filterauswahlen Steigerung der User Experience (z.B. Größenangaben in Shops)
  • Einschaltung einer gewünschten Personalisierung (z.B. in Mediatheken oder Shops)
  • Abruf von Empfehlungen als Service-Mehrwert (z.B. komplementäre Produktvorschläge)
  • Email-Benachrichtigungen über Warenverfügbarkeit, um wiederholte erfolglose Shopbesuche zu ersparen

 

Lassen Sie uns sehr gerne gemeinsam schauen, welche Potenziale sich konkret für Ihren Anwendungsfall finden lassen. Sie werden überrascht sein!

Data Flow 1.0

So you set up this more than elegant data model on your Postgres database. It consists of several layers of views which are all sensible units in and of themselves, which are reusable in various contexts and which in sum prepare your data in exactly the way you want it for your Tableau dashboard. Perfect. You deploy your Tableau dashboard and everything is working as intended.

Then you jump into another project and only return when changed requirements demand for changes to your beautiful data model. You open up your database tool and all it tells you is the following:

Erm… what? (Let´s ignore the awful view names for the sake of the argument…) Where are all those clever processing stages and dependencies you created so painstakingly? So you remember some of the calculations and joins which caused you a lot of headaches but it´s all several months in the past…

You still know that the views which are relevant to your Tableau dashboard are “data_modeller_test_3”, “order_statistics” and “init_order_statistics_by_category”. You also remember that there should be data from the tables “orders” and “people” in there. But do you really have to go through all that code to find out about all dependencies and all the code sections you need to change due to the new requirements?

If you´re anything like us, you experienced situations like this or similar ones (think of handing over the project to another colleague, for example) a lot of times. This is why we came up with the idea to create a tool which supports you in developing and maintaining your data model on your Postgres database. We call it “Data Flow” and want to share it with you so that it may help you managing your own data models.

In today´s first blog entry on Data Flow, we´re presenting two user defined functions (UDFs) as well as the Data Flow Dashboard to you. The UDFs were developed to provide the data source for the workbook while the workbook automatically generates a network visualization of your data model and provides further useful information on the model. All files may be found at the bottom of this article.

This is what the Data Flow Dashboard looks like:

Both UDFs make use of system tables like “pg_depend” which Postgres handily provides. While return_data_model() accepts one or several “end_nodes”, i.e. views that you´re reporting on (see “data_modeller_test_3”, “order_statistics” and “init_order_statistics_by_category” above), and iterates through all upstream dependencies to sort out the data model you created, return_data_model_tableau_prep() calls upon return_data_model() and structures the function´s output in a way that may be used to create the network visualization of the data model depicted above.

  

Both UDFs are ready to be created and used on Postgres servers using a version later than 9.5.10. They should function on older versions as well but this has not yet been tested. Just create them on the database in question and direct your copy of the Data Flow workbook towards that database.

Aside from filtering on relevant end nodes, the Tableau workbook provides further features such as highlighting of dependencies and displaying the create code of selected elements. You may also decide whether you want to color code data model elements with respect to their node_role (i.e. root, intermediary or end node) or whether you want to color the nodes between data model elements depending on their I/O type (i.e. downstream or upstream dependency).

In upcoming further development stages of this project we will add further UDFs which allow to track the creation of as well as changes and refreshments of data model elements. This will provide workbook users with important information on all data model elements. Another extension will see UDFs which will make the process of changing a data model easier by taking care of necessary drop / create operations for you. Stay tuned for more, Data Flow will only get more powerful over time.

If you found this article to provide useful insights to you, please consider sharing it with others who might benefit from it. Also, please don´t hesitate to reach out to us if you´re interested in more details!

Download the sql and twb files