In diesem Blogpost lernt ihr:

  • Was ist ein Angemessenheitsbeschluss und was bedeutet er für internationale Datentransfers in die USA?
  • Was sind die neusten Entwicklungen?
  • Was ist der Impact für meine Data Strategy und den Einsatz von US-basierten Tools?
  • Wie könnte es weiter gehen?

 

Das Wichtigste in Kürze:

  • Die Europäische Kommission hat den Angemessenheitsbeschluss für den EU-US Data Privacy Framework (DPF) angenommen.
  • Damit bescheinigt die Kommission DPF-zertifizierten Unternehmen in den USA ein mit der EU vergleichbares Datenschutzniveau.
  • Personenbezogene Daten können nun an solche Unternehmen übermittelt werden, ohne dass hierfür zusätzliche Schutzmaßnahmen getroffen werden müssen.
  • Es wird für die meisten US-Anbieter (wie beispielsweise Google oder Meta) vermutlich noch einige Wochen oder Monate dauern, bis sie die Anforderungen des DPF umgesetzt haben.
  • Es ist nicht sicher, dass der Angemessenheitsbeschluss die Datentransferproblematik auf Dauer lösen wird. Max Schrems‘ Datenschutzorganisation NOYB plant bereits den neuen DPF vor Gericht zu bringen.

 

Am 10. Juli 2023 veröffentlichte die Europäische Kommission eine Pressemitteilung auf ihrer Website zum neuen Angemessenheitsbeschluss für den EU-US Data Privacy Framework, die die Aufmerksamkeit aller Web-Analysten auf sich zog. Die häufigsten Fragen waren: Kann ich Google Analytics jetzt legal verwenden? Und wie sieht es mit all den anderen US-Tools aus, die wir gerne auf Websites nutzen?

Im Interview beantwortet unser FELD M Privacy Experte Stefan Riegler die vier wichtigsten Fragen:

 

Die Europäische Kommission hat den Angemessenheitsbeschluss für den EU-US Data Privacy Framework (DPF) angenommen. Kannst du kurz erklären, was das ist?

„Ein Angemessenheitsbeschluss ist eines der Instrumente, welche die DSGVO für rechtmäßige Übermittlungen von personenbezogenen Daten in Drittstaaten zur Verfügung stellt. Ein Angemessenheitsbeschluss zeigt an, dass ein Drittstaat ein Datenschutzniveau besitzt, welches mit dem in der EU vergleichbar ist.

Seit der Ungültigerklärung des Privacy Shield durch den Europäischen Gerichtshof (EuGH) in seinem Schrems II Urteil hatten die USA ein solches Niveau offiziell nicht mehr. Mit der Annahme des neuen Angemessenheitsbeschluss erklärt die Kommission nun, dass US Unternehmen, welche unter dem DPF zertifiziert sind, ein angemessenes Datenschutzniveau vorweisen.

Der Beschluss kann nun als rechtliche Grundlage für Datenübermittlungen an derartige Unternehmen genutzt werden, ohne dass hierbei zusätzliche Datenschutzgarantien getroffen werden müssen.“

 

Wann treten die neuen Regelungen in Kraft?

„Der Angemessenheitsbeschluss und das Data Privacy Framework sind bereits in Kraft.

Um personenbezogene Daten rechtmäßig an ein US-Unternehmen exportieren zu dürfen, muss besagtes Unternehmen unter dem DPF zertifiziert sein. Ich vermute viele US Anbieter (wie beispielsweise Google oder Meta) werden noch einige Wochen oder Monate brauchen, um sich an den DPF anzupassen, sich bei Bedarf zertifizieren zu lassen und ihre Datenschutzerklärungen anzupassen.”

 

Heißt das ich kann Google Analytics jetzt legal nutzen?

„Zunächst einmal zur Frage, wo bisher das Problem mit Google Analytics lag: In Folge des Schrems II Urteils und der Ungültigerklärung des Privacy Shield mussten exportierende Unternehmen ihre Datentransfers auf eine andere Rechtsgrundlage stützen – in der Regel auf Standardvertragsklauseln (SCCs). SCCs alleine reichen jedoch nicht aus, um ein angemessenes Datenschutzniveau zu sichern, weshalb die beteiligten Unternehmen zusätzliche Datenschutzmaßnahmen treffen mussten, um ein EU-vergleichbares Datenschutzniveau zu gewährleisten.

In den vergangenen Jahren erklärten diverse europäische Datenschutzaufsichtsbehörden, dass Googles zusätzliche Maßnahmen in diesem Zusammenhang nicht ausreichten, und belegten in Folge Unternehmen, welche über die Nutzung von Google Analytics Daten in die USA exportieren, mit Bußgeldern und Strafen.

Mit dem neuen Angemessenheitsbeschluss können exportierende EU-Unternehmen ihre Transfers an zertifizierte US-Unternehmen rechtlich nun darauf stützen anstatt auf Standardvertragsklauseln.

Kommen wir zum “Jetzt” in deiner initialen Frage: Unserem Verständnis des Beschlusses nach, dürfen US Organisationen Daten empfangen, sobald sie auf einer Liste des US Department of Commerce stehen. Organisationen wie Google, welche bereits unter dem früheren Privacy Shield zertifiziert waren, sollen ihren alten Mitgliedsstatus “erben”. Sie müssen jedoch innerhalb einer dreimonatigen Frist ihre Datenschutzerklärungen entsprechend anpassen.

Google wird tatsächlich bereits auf der Liste des Department of Commerce als aktiver Teilnehmer gelistet. Nach heutigem Stand (27.07.2023) erklärt Googles Informationsseite jedoch zu Datentransfers noch, dass man sich nicht mehr auf den Privacy Shield stütze. Diese Seite wurde im Februar 2022 zuletzt aktualisiert.

Wenn man als Unternehmen also Google Analytics nutzen will, sollte man ein Auge auf Googles Datenschutzerklärungen haben und auf deren Aktualisierung warten. Gegebenenfalls macht es auch bereits Sinn, einen Termin mit seinem Datenschutzbeauftragten oder Rechtsberatern zu vereinbaren, um mit ihnen zu erörtern, was der Angemessenheitsbeschluss für die eigene unternehmensspezifische Situation bedeutet und welche nächsten Schritte man gegebenenfalls gehen will oder könnte.„

 

Tipp: Lade unsere Checkliste zum EU-US Data Privacy Framework für in der EU ansässige Unternehmen herunter, um herauszufinden, was als nächstes zu tun ist.

 

Können wir uns sicher sein, dass dieses neue Abkommen länger Bestand haben wird als sein Vorgänger?

„Das ist eine schwierige Frage. Einerseits betont die Europäische Kommission in ihrer Außenkommunikation, dass die USA „beispiellose Zusagen“ für den DPF gemacht haben.

So sollen mit dem neuen Deal US-Nachrichtendienste beispielsweise nur noch auf EU-Daten zugreifen, wenn dies notwendig und verhältnismäßig ist, um nationale Sicherheitsinteressen zu verfolgen. Außerdem wurde ein Rechtsbehelfsverfahren eingeführt, wodurch Betroffene rechtswidrige Überwachungspraktiken anfechten können sollen.

Es ist jedoch fraglich, ob die seitens der USA ergriffenen Maßnahmen tatsächlich ausreichen, um jene Bedenken des EuGH auszuräumen, welche ihn zu seinem Schrems II Urteil vor drei Jahren führten.

Datenschutzorganisationen bereiten sich jedenfalls schon darauf vor, den neuen Angemessenheitsbeschluss wieder vor Gericht zu bringen. Die von Max Schrems gegründete Datenschutzorganisation NOYB hat bereits angekündigt, dass sie verschiedene Optionen vorbereitet hat, um das Abkommen wieder vor den EuGH zu bringen.

Ihnen zufolge könnte eine Anfechtung des Abkommens den EuGH Ende 2023 oder Anfang 2024 erreichen. Ferner könne der EuGH ihrer Ansicht nach dann sogar den DPF für die Dauer des Verfahrens aussetzen. Eine endgültige Entscheidung erwarten sie für 2024 oder 2025.

Also nein, für den Moment würde ich nicht meine komplette Datenstrategie und Datenschutzstrategie auf der Annahme bauen, dass der Bestand des Data Privacy Framework in Stein gemeißelt ist.“

 

So geht es weiter

Die vorherrschende Stimmung in Bezug auf Datenschutz und Consent ist für viele von Unsicherheit geprägt. Neue politische Initiativen, Gerichtsurteile sowie Behördenbescheide und -standpunkte erschweren den Durchblick. Viele Websites und Apps befinden sich in einer rechtlichen Grauzone – entweder weil die Betreiber sich schlicht unsicher sind, wie sie das Thema Consent angehen sollen oder schlimmer, weil sie aktiv Consent Management Richtlinien missachten und auf manipulative Designs setzen.

Umso wichtiger ist es in der heutigen Zeit einen verlässlichen Partner an seiner Seite zu haben, der seinen Finger am Puls aktueller rechtlicher Diskussionen hat sowie Erfahrung mit pragmatischen Best-Practices – einen Partner, der Sie bei der Entwicklung innovativer technischer Lösungen unterstützt und Ihnen einen rechtlichen Vorteil gegenüber Ihren Wettbewerbern sichert. FELD M kann dieser Partner für Sie sein. Falls Sie sich unsicher sind, ob Ihre Organisation vollständig rechtskonform aufgestellt ist, können wir Sie gerne zu Themen rund um Consent und Privacy beraten.

 

* Haftungsausschluss: Wir möchten darauf hinweisen, dass die Informationen, die wir in diesem Blogbeitrag zum neuen Angemessenheitsbeschluss der Europäischen Kommission bereitstellen, lediglich allgemeiner Natur sind und nicht als Rechtsberatung angesehen werden können.
Dieser Blogbeitrag dient lediglich dazu, allgemeine Informationen zu vermitteln und soll keine individuelle Beratung durch Anwälte oder Datenschutzbeauftragte ersetzen. Es liegt in der Verantwortung der Leser:innen, sich bei rechtlichen Fragen oder Unsicherheiten zu ihrer spezifischen Situation an qualifizierte Rechtsberater:innen oder ihre:n Datenschutzbeauftragte:n zu wenden, um eine fundierte rechtliche Bewertung und Beratung zu erhalten.

Wir übernehmen keine Haftung für etwaige Verluste, Schäden oder rechtliche Konsequenzen, die aus der Verwendung oder Interpretation der in unserem Blogbeitrag bereitgestellten Informationen resultieren. Die Verwendung der Informationen erfolgt auf eigenes Risiko.

 

Weiterführende Informationen zum Angemessenheitsbeschluss finden Sie hier:

Ich bin Mariia, Data Engineer im Data Product Team bei FELD M. Im April 2023 reisten mein Kollege Valerii Haidar und ich nach Berlin, um die berühmte PyCon zu besuchen – Europas größte Konferenz zur Diskussion und Förderung der Programmiersprache Python. Jedes Jahr treffen sich dort Python-Anwender:innen und -Enthusiast:innen aus der ganzen Welt, um sich über neue Entwicklungen zu informieren, Wissen auszutauschen und voneinander zu lernen. 

Im Jahr 2023 wurde die PyCon Berlin mit der PyData zusammengelegt, einem Forum für Nutzer:innen und Entwickler:innen von Datenanalysetools. Sie dauerte drei Tage und umfasste so viele Präsentationen, dass ein Team von mindestens sieben Personen nötig wäre, um alle zu besuchen. Glücklicherweise wurden die Sitzungen aufgezeichnet, und jetzt, nach einigen Monaten, sind sie für alle zugänglich. Am Ende dieses Artikels findet ihr einen Link zur YouTube-Playlist der Vorträge der PyCon Berlin 2023. 

Doch zunächst möchte ich euch meinen eigenen Überblick über die Vorträge geben, die wir besucht haben und die uns am besten gefallen haben. Bitte denkt daran, dass dieser Überblick auf einer persönlichen Meinung beruht und sich daher von der euren unterscheiden kann. Schreibt uns eure Sichtweise gerne in die Kommentare! 

1. Pandas 2.0 and beyond 

Für wen: Software- und Data Engineers, Data Scientists und alle, die mit Pandas arbeiten (mit Ausnahme von Personal in öffentlichen Zoos, vielleicht). 

Warum es sich lohnt: Der Vortrag behandelt nicht nur die Änderungen in Pandas 2.0 im Vergleich zu Pandas 1.0, sondern geht auch auf das Thema PyArrow ein, das in der neuesten Version von Pandas aktiv genutzt wird. (Wenn du wissen willst, was PyArrow ist, findest du einen Link zum Vortrag darüber am Ende dieser Liste). 

Unsere Meinung: Interessantes Thema, sehr relevant für unsere Arbeit, Bewertung: 9/10 

Details: https://pretalx.com/pyconde-pydata-berlin-2023/talk/DB3KC7/ 

Video: https://www.youtube.com/watch?v=7QQZ1hrHG1s&list=PLGVZCDnMOq0peDguAzds7kVmBr8avp46K 

2. Large Scale Feature Engineering und Data Science mit Python & Snowflake 

Für wen: Data Scientists, Data Engineers, und diejenigen, die an Snowflake interessiert sind. 

Warum es sich lohnt: Dieser Vortrag war im Grunde eine Einführung in Snowpark, Snowflakes Framework für die Entwicklung von maschinellem Lernen, das mit Big Data in Python, Scala oder Java arbeiten kann. 

Unsere Meinung: Gute Präsentation, aber du wirst nicht allzu viel mitnehmen, wenn du nicht regelmäßig mit Snowflake arbeitest. Bewertung: 7/10 

Details: https://pretalx.com/pyconde-pydata-berlin-2023/talk/3TYND7/ 

Video: https://www.youtube.com/watch?v=mpY7auHK3zw&list=PLGVZCDnMOq0peDguAzds7kVmBr8avp46K 

3. Raised by Pandas, striving for more: Eine meinungsstarke Einführung in Polars 

Für wen: Software- und Data Engineers, Data Scientists, und alle, die mit Pandas arbeiten (und noch mehr möchten) 

Warum es sich lohnt: Der Vortrag gibt einen guten Überblick über Polars und regt dazu an, es als leistungsfähigere Alternative zu Pandas zu testen. 

Unsere Meinung: Der Referent war begeistert von dem Framework und ein sehr engagierter Redner. Die Folien waren sehr lustig! Vor allem ist das Thema Polars im Moment sehr aktuell, also auf jeden Fall: Bewertung: 10/10 

Details: https://pretalx.com/pyconde-pydata-berlin-2023/talk/Z8PESY/ 

Video: https://www.youtube.com/watch?v=7xcUvzERwx0&list=PLGVZCDnMOq0peDguAzds7kVmBr8avp46K 

4. Häufige Probleme mit Zeitreihendaten und wie man sie löst  

Für wen: hauptsächlich für Data Scientists, aber auch für alle, die mit Daten arbeiten  

Warum es sich lohnt: Diese Präsentation erläutert vier häufig auftretende Probleme mit Zeitreihendaten und gibt dir Hinweise zur Lösung.  

Unsere Meinung: Die Präsentation war recht gut, deckte aber relativ grundlegende Dinge ab, daher: Bewertung: 7/10 

Details: https://pretalx.com/pyconde-pydata-berlin-2023/talk/ZRAFKA/ 

Video: https://www.youtube.com/watch?v=sSF1uzK6DuI&list=PLGVZCDnMOq0peDguAzds7kVmBr8avp46K 

5. WALD: Ein moderner & nachhaltiger Analytics Stack 

Für wen: Data Engineers, BI-Fachleute sowie Unternehmen und Teams, die datenorientierter werden wollen  

Warum es sich lohnt: Im Vortrag ging es um die Tools, mit denen eine moderne Reporting-Pipeline aufgebaut werden kann, und um WALD, eine Lösung, in der diese Tools kombiniert werden.  

Unsere Meinung: Wir waren sehr gespannt welche Technologien andere Unternehmen für den Aufbau von Reporting-Pipelines verwenden. Und ich muss zugeben, dass die Folien sehr cool waren! Bewertung: 8/10  

Details: https://pretalx.com/pyconde-pydata-berlin-2023/talk/TP7ABB/  

Video: https://www.youtube.com/watch?v=7GfbA6_a09I&list=PLGVZCDnMOq0peDguAzds7kVmBr8avp46K 

Falls du auf der Suche nach einer sofort einsatzbereiten Lösung bist, die dir hilft, mehr Wert aus deinen Daten zu ziehen, solltest du dir die Entwicklung unseres Data Product Teams ansehen: Datacroft Analytics Stack Datacroft Analytics Stack und kontaktiere uns gerne für weitere Details! 

6. Der Weg zu erlernten Datenbanksystemen 

Für wen: Alle, die mit Datenbanken arbeiten 

Warum es sich lohnt: Die Präsentation zeigt die neue Richtung der so genannten „Learned Database Management Systems“ (DBMS), bei denen Kernbestandteile von DBMS durch maschinelle Lernmodelle ersetzt werden, was erhebliche Leistungsvorteile mit sich bringt. 

Unsere Meinung: Das Thema ist an sich schon spannend, aber Hut ab vor dem Referenten – er hat es mit seiner hervorragenden und ausgewogenen Präsentation noch interessanter gemacht! Bewertung: 10/10 

Details: https://pretalx.com/pyconde-pydata-berlin-2023/talk/JZSYA3/ 

Video: https://www.youtube.com/watch?v=VtL6Y4x10O0&list=PLGVZCDnMOq0peDguAzds7kVmBr8avp46K 

7. Rusty Python: Eine Praxisstudie  

Für wen: Software- und Data Engineers die mit Python arbeiten 

Warum es sich lohnt: Ein Überblick über Rust und seine Vorteile für Python-Entwickler:innen. Spannende Präsentation über die Implementierung einer Lösung in Rust und deren Integration mit einer Python-Anwendung unter Verwendung von PyO3.  

Unsere Meinung: Sehr interessantes Thema und hervorragende Präsentation, Bewertung: 10/10  

Details: https://pretalx.com/pyconde-pydata-berlin-2023/talk/LMGF8V/  

Video: https://www.youtube.com/watch?v=Y5XQR0wUEyM&list=PLGVZCDnMOq0peDguAzds7kVmBr8avp46K 

8. Lorem ipsum dolor sit amet  

Für wen: Alle, die mit Software und Daten arbeiten 

Warum es sich lohnt: Der Vortrag widmet sich dem Prozess der Suche nach aussagekräftigen Testdaten für die eigene Software. Die Bedeutung dieses Themas kann gar nicht hoch genug eingeschätzt werden. Wer also regelmäßig mit Daten arbeitet, sollte sich den Vortrag unbedingt ansehen. 

Unsere Meinung: Lustige Folien, aber ich habe das Gefühl, dass die Hauptbotschaft durch die vielen Witze und Beispiele ein wenig verwässert wurde. Dennoch eine nützliche und ansprechende Präsentation. Bewertung: 8/10 

Details: https://pretalx.com/pyconde-pydata-berlin-2023/talk/HJ9J7Z/ 

Video: https://www.youtube.com/watch?v=ulBqrMyVSMM&list=PLGVZCDnMOq0peDguAzds7kVmBr8avp46K 

9. Unlocking Information – Erstellung synthetischer Daten für Open Access  

Für wen: Data Scientists, könnte aber für alle interessant sein, die mit Daten arbeiten. 

Warum es sich lohnt: Wenn du dich schon immer gefragt hast, wie du die Daten, die du in deiner Arbeit benutzt hast, öffentlich machen kannst, ohne persönliche Informationen preiszugeben, dann könnte diese Präsentation genau das Richtige für dich sein. 

Unsere Meinung: Das Thema ist ein wenig nischig, aber dennoch gut für die allgemeine berufliche Entwicklung. Bewertung: 7/10 

Details: https://pretalx.com/pyconde-pydata-berlin-2023/talk/J9KRKZ/ 

Video: https://www.youtube.com/watch?v=N1i_Z-WKaRs&list=PLGVZCDnMOq0peDguAzds7kVmBr8avp46K 

10. Most of you don’t need Spark. Kostengünstige Verwaltung umfangreicher Daten mit Python  

Für wen: Software- und Data Engineers, Data Scientists  

Warum es sich lohnt: Der Vortrag behandelt viele Aspekte und Technologien, die dabei helfen können, große Datenmengen zu verwalten und eine skalierbare Infrastruktur für deren Verarbeitung aufzubauen. 

Unsere Meinung: Der Referent stellt einige Fragen, die einen etwas dumm vorkommen lassen könnten und einen Anfall von Hochstapler-Syndrom auslösen, aber abgesehen davon war der Vortrag großartig! Bewertung: 9/10 

Details: https://pretalx.com/pyconde-pydata-berlin-2023/talk/V9HBUU/ 

Video: https://www.youtube.com/watch?v=OsYcsv4VkO8&list=PLGVZCDnMOq0peDguAzds7kVmBr8avp46K 

11. Apache Arrow: Verbindung und Beschleunigung von Dataframe-Bibliotheken im PyData-Ökosystem  

Für wen: Software- und Data Engineers, Data Scientists  

Warum es sich lohnt: Wenn du PyArrow oder Apache Arrow schon einmal gehört hast (z.B. während des Vortrags „Pandas 2.0 and beyond“) und du tiefer eintauchen und mehr über diese Technologie herausfinden möchtest, ist dieser Vortrag genau das Richtige für dich. Wenn du noch nie etwas von PyArrow gehört hast, ist dieser Vortrag sogar noch besser für dich geeignet.  

Unsere Meinung: Arrow ist fantastisch, aber das Gespräch war kein Zuckerschlecken, so dass es etwas Konzentration erfordert. Bewertung: 8/10  

Details: https://pretalx.com/pyconde-pydata-berlin-2023/talk/H7ZCWK/  

Video: https://www.youtube.com/watch?v=h7F3Rr8Ozgw&list=PLGVZCDnMOq0peDguAzds7kVmBr8avp46K 

12. Postmodern Architecture – The Python Powered Modern Data Stack 

Für wen: Data Engineers, BI-Fachleute, Unternehmen und Teams, die datenorientierter werden wollen  

Warum es sich lohnt: Der Redner und sein Team haben im Grunde einen Konkurrenten von WALD (siehe Punkt 5 der Liste) entwickelt. Sie bieten es als eine Sammlung von Technologien an, die einen flexiblen Stack bilden, der sich mit der Integration von Daten und der Gewinnung von Werten aus ihnen befassen kann.  

Unsere Meinung: Auch hier gilt: Wenn du neugierig auf Technologien bist, die für den Aufbau einer modernen Reporting-Pipeline verwendet werden können, solltest du dir diesen Vortrag ansehen. Und als Fan der Brooklyn 99 kann ich nicht anders, als die Folien zu bewundern. Bewertung: 8/10 

Details: https://pretalx.com/pyconde-pydata-berlin-2023/talk/A7B8P8/ 

Video: https://www.youtube.com/watch?v=na7yqvz5-B4&list=PLGVZCDnMOq0peDguAzds7kVmBr8avp46K 

 

Wie bereits oben erwähnt, gab es noch viele weitere spannende Vorträge auf der PyCon Berlin 2023. Die vollständige Liste der Sessions mit Beschreibungen kannst du auf der Veranstaltungsseite der Konferenz finden. Und glücklicherweise sind die meisten der Aufzeichnungen jetzt für alle auf YouTube verfügbar! 

Zusammenfassend kann ich sagen, dass die PyCon eine großartige Veranstaltung für alle ist, die sich für das Programmieren, für Daten und natürlich für Python begeistern. Sie inspiriert dazu, Neues auszuprobieren und eigene Ansätze zu überdenken, es bringt dich deiner Entwicklergemeinschaft näher und gibt dir die Möglichkeit, von den besten Profis auf deinem Gebiet zu lernen. Und natürlich ist es ein perfekter Grund, Berlin zu besuchen und sich an den kulinarischen Köstlichkeiten, dem Nachtleben, der reichen Geschichte und einigen der bemerkenswertesten Sehenswürdigkeiten zu erfreuen! Wir freuen uns auf die PyCon 2024 und hoffen, dass du es nach diesem Artikel auch tust! 

Wenn du dich für unsere Arbeit im Data Product Team interessierst, findest du hier weitere Informationen. Außerdem stellen wir hier einige unserer Projekte im Bereich Data Engineering und -Architektur vor. 

 

Looker und Looker Studio (Pro), früher bekannt als Google Data Studio, sind weit verbreitete Business-Intelligence-Tools aus dem Google-Kosmos, mit deren Hilfe sich interaktive Dashboards und Berichte erstellen lassen. Die Tools haben ihre individuellen Stärken und sind für unterschiedliche Anwendungsfälle und Zielgruppen konzipiert. In diesem Artikel gehen wir auf die Funktionen der beiden Tools ein und heben ihre Unterschiede hervor, indem wir typische Anwendungsfälle beschreiben, für welche die Tools am besten geeignet sind. Außerdem werden wir auf die wichtigsten Vor- und Nachteile der Tools hinweisen.

 

Inhaltsverzeichnis:

1. Looker

2. Looker Studio

3. Looker Studio Pro

4. Zusammenfassung und Fazit

 

1. Looker – Der Ferrari unter den Business Intelligence Tools?

 

 

Looker Example Dashboard

Beispiel eines Looker-Dashboard; Quelle

Use Case 1: Vertrauen in die Daten zurückgewinnen und Self-Service-Analysen in einem Scale Up einführen.

Ein datengetriebenes Scale Up-Unternehmen musste feststellen, dass das Data-Team zu einem Bottleneck für die Erstellung von Analysen und Bereitstellung von Erkenntnissen geworden war, denn alle Dashboards des Unternehmens mussten von Datenanalyst*innen mithilfe von SQL-Abfragen erstellt werden. Außerdem bemerkte das Unternehmen, dass die in den verschiedenen Berichten verwendeten Metriken inkonsistent waren, was zu einem schwindenden Vertrauen in diese Daten führte. Das Unternehmen möchte nun einen Self-Service-Ansatz implementieren, der die Daten direkt in die Hände der Business User gibt, die bereits versiert im Umgang mit Daten sind, und der ferner sicherstellt, dass die Metriken in allen Berichten denselben Definitionen folgen.

In diesem exemplarischen Use Case ist Looker ein hilfreiches Tool, um das Problem der inkonsistenten Metriken zu lösen und es den Business Usern zu ermöglichen, auch ohne SQL-Kenntnisse selbstständig Erkenntnisse aus den Daten zu gewinnen.

Looker ist eine Datenplattform, die es Unternehmen ermöglicht, eine Verbindung zu ihren Data Warehouses herzustellen, die Daten zu untersuchen und darauf aufbauend Visualisierungen und Dashboards zu erstellen. Looker bietet einen einzigartigen semantischen Layer mit Looker-eigener Sprache, LookML, die Dimensionen, Aggregate, Kalkulationen und Datenbeziehungen in einer SQL-Datenbank beschreibt. Mit LookML – eine Mischung aus YAML und dialektunabhängigem SQL – können wiederverwendbare, versionskontrollierte Datenmodelle erstellt werden. Looker verwendet diese Modelle, um SQL-Abfragen für die Datenbank zu generieren. LookML unterstützt Data Analyst*innen und Analytics Engineers dabei, dem DRY-Prinzip („don’t repeat yourself“) aus der Softwareentwicklung zu folgen. Das bedeutet, dass SQL-Ausdrücke einmalig an einer Stelle geschrieben werden und die Abfrage-Engine von Looker den Code wiederholt verwendet, um Ad-hoc-SQL-Abfragen zu generieren. Die Business User können dann die Ergebnisse verwenden, um komplexe Analysen und Dashboards in Looker zu erstellen – und sich dabei auf den benötigten Inhalt konzentrieren, anstatt auf die Komplexität der SQL dahinter. Da große Teile des Unternehmens auf diese Weise keine SQL-Kenntnisse für die Datenanalyse mehr benötigen, hat das Unternehmen einen großen Schritt in Richtung Self-Service-Analytics gemacht.

Die Dimensionen (z. B. „Was ist ein User?“) und Metriken (z. B. „Wie ist MRR definiert?“) werden nur zentral an einer Stelle definiert, wodurch sie in allen Berichten konsistent sind. Das hilft dabei, das Vertrauen der Business User in die Daten aufrechtzuerhalten.

Beispiel der Looker-eigenen Sprache LookML

Die Looker-eigene Sprache LookML; Quelle: Google Cloud Skill Boosts

 

Use Case 2: Ein großer Retailer möchte Daten aus verschiedenen Quellen analysieren.

Ein großes Einzelhandelsunternehmen möchte Daten aus verschiedenen Quellen, einschließlich des Online-Shops und der Filialen, analysieren, um Wachstumsbereiche aufzudecken und ein besseres Verständnis für das Kund*innenverhalten zu entwickeln. Das Unternehmen möchte seinen Filialleitungen Performance-Übersichten in Form von Dashboards zur Verfügung stellen, wobei die Manager*innen nur auf die für sie relevanten Daten zugreifen können. Außerdem möchte das Unternehmen maßgeschneiderte Dashboards mit Erkenntnissen über die Leistung bestimmter Produkte und das Kaufverhalten in seine Partnerplattform einbetten und seinen zentralen Partnermarken den Zugang dazu in Rechnung stellen.

In diesem zweiten Anwendungsfall ist Looker das ideale Tool, weil es sich mit einer Vielzahl von Data Warehouses verbinden lässt, in denen die Daten aus verschiedenen Datenquellen liegen, es zeilen- und spaltenbasierte Funktionen zur Verwaltung der Benutzer*innenzugriffe sowie die Möglichkeit zur Einbettung von White Label-Dashboards bietet. Lookers Funktion zur Zugriffskontrolle ermöglicht es Teams, die Daten und Visualisierungen nur für relevante Personen freizugeben, was es perfekt für diesen Anwendungsfall macht, bei dem Filialleitungen und Partnermarken nur die sie betreffenden Daten sehen sollen.

Durch den Einsatz des Retail Analytics Blocks von Looker sparte das Unternehmen Stunden an Arbeit, die sonst für die Datenmodellierung und die Erstellung von Dashboards aufgewendet werden müssten. Der Block bietet einen umfassenden Überblick über die Gruppen- und Filialleistung des Unternehmens, das Verhalten der Kund*innen, die Dynamik der Warenkörbe und die zu fördernden Kund*innensegmente oder Produkt-Bundles. Looker-Blocks sind Vorlagen für Datenmodelle und Dashboards, die im Idealfall nur von den Nutzer*innen konfiguriert werden müssen, um schnell von der Datenbank zum Dashboard zu gelangen. Sie bestehen aus vorgefertigten LookML-Codeblöcken, die Sie in Ihr Projekt kopieren können. Looker-Blocks gibt es für eine Vielzahl von Datenquellen und Anwendungsfällen (z. B. Hubspot Marketing, Google Analytics 4, Shopify). Allerdings funktionieren einige Blöcke nur dann, wenn die Daten in einer bestimmten Struktur vorliegen oder für eine bestimmte Datenbank optimiert sind. Sie können sich alle vorhandenen Blöcke auf dem Looker-Marktplatz ansehen.

Um die erstellten Dashboards den Filialleiter*innen zur Verfügung zu stellen und sicherzustellen, dass diese nur auf die für sie relevanten Daten zugreifen können, nutzte das Unternehmen die Looker-Funktionen für Zugriffskontrolle und Berechtigungsmanagement.

  • Sie richteten eine Gruppe „Store Manager“ ein, um Inhalte und Funktionen für alle Store Manager zu definieren.
  • Der „Inhaltszugriff“ definiert, welche Ordner ein*e Benutzer*in oder eine Gruppe von Nutzer*innen sehen oder bearbeiten kann.
  • Der „Feature-Zugriff“ steuert die Arten von Aktionen, die ein*e Benutzer*in in Looker durchführen darf.
  • Außerdem wurde der Zugriff auf Zeilenebene so konfiguriert, dass jede*r Filialleiter*in nur Zugriff auf diejenigen Daten hat, die sich auf die von ihm*ihr verwaltete Filiale beziehen.

Um eine weitere Einnahmequelle zu erschließen, wurde ein Dashboard mit Informationen über Produktleistung und Kaufverhalten erstellt und das Partnerportal integriert. Gegen eine geringe Gebühr konnten einzelne Marken diese Funktion nutzen, um die Marktforschung und sogar die Produktentwicklung zu unterstützen und zu beschleunigen. Looker bietet die Einbettung von Inhalten wie Dashboards via iframe auf verschiedene sichere Arten wie SSO Embed oder Private Embed. Das Unternehmen nutzte auch die Möglichkeit von Looker, eigene Themes zu erstellen, um sicherzugehen, dass das Dashboard gut in das bestehende Design des Partnerportals passt.

Darüber hinaus bietet Looker ein Feature, das viel Zeit und Mühe sparen kann: Eine integrierte Planungs- und Benachrichtigungsfunktion ermöglicht es den Nutzer*innen, Berichte automatisiert an verschiedene Teams oder Stakeholder zu versenden – entweder nach einem  bestimmten Zeitplan oder immer dann, wenn eine bestimmte Bedingung erfüllt ist (z. B. wenn die Rücklaufquote einen bestimmten Wert übersteigt).

 

2. Looker Studio – Eine ideale Lösung für kleine Unternehmen

Nachdem wir ein umfassendes Verständnis der Möglichkeiten, Anwendungsfälle und Features von Looker erlangt haben, werden wir nun Looker Studio näher betrachten, das früher als „Google Data Studio“ bekannt war. Diese benutzer*innenfreundliche Plattform bietet eine Vielzahl direkter Integrationen, insbesondere für Google-Produkte, und vereinfacht so die Anbindung verschiedener Datenquellen und das Gewinnen wertvoller Erkenntnisse. Die intuitive Benutzer*innenoberfläche ermöglicht es den Nutzer*innen, selbstständige Analysen durchzuführen, indem sie einfache Datenmodellierungen vornehmen und schnell Diagramme mit grundlegenden Funktionen erstellen können, die aber weniger Interaktivität bieten.

Looker Studio New Report

Erstellen eines neuen Reports in Looker Studio.

Use Case 3: Ein Startup möchte einfache, interaktive Dashboards erstellen, um die Leistung und das Wachstum seines Produkts zu verfolgen.

Ein Startup möchte – nach der Markteinführung seines Produkts vor zwei Jahren – seine Vertriebs- und Marketingleistung  verfolgen. Es möchte schlanke, übersichtliche und interaktive Berichte für eine effektive Analyse der Vertriebs- und Marketingkanäle erstellen. Sie benötigen ein Tool, das schnell implementiert werden kann und auch von nicht-technischen Anwender*innen genutzt werden kann, da sie über keine umfangreichen IT-Ressourcen verfügen. In diesem Fall wäre Looker Studio die optimale Lösung, denn es ist benutzer*innenfreundlich, kostengünstig und schnell einsetzbar, sodass auch technisch weniger versierte Benutzer *innen wertvolle Erkenntnisse gewinnen können.

 

Looker Studio Visualization Options

Einige der Visualisierungsmöglichkeiten in Looker Studio

 

Looker Studio ist eine kostenlose Cloud-basierte Lösung zur Datenvisualisierung. Mit der Drag-and-Drop-Oberfläche können auch technisch nicht versierte Nutzer*innen Dashboards und Berichte mit vorgefertigten Diagrammen, Grafiken und Tabellen erstellen. Es ist einfach, kalkulierte Felder für bestimmte Metriken pro Dashboard zu definieren. Geplante Datenaktualisierungen können auf Report-Ebene eingerichtet werden, um sicherzustellen, dass die Informationen darin immer aktuell sind. Die Erstellung von Templates und die Möglichkeit der Einbettung von Reports in Webseiten sind ebenfalls verfügbar.

Da es sich um ein Google-Produkt handelt, lässt es sich nahtlos mit Google-Produkten wie Google Sheets, Google Analytics und BigQuery integrieren und kann auch mit beliebten Plattformen wie Salesforce und Facebook Ads verbunden werden – alle verfügbaren Konnektoren finden Sie hier. Auch Data Blending ist für die grundlegende Datenmodellierung in Form von „Left Joins“ verfügbar, aber für den Aufbau eines komplexeren Datenmodells muss ein Datenteam geeignete Datenpipelines und Modelle in einem Data Warehouse einrichten. Das Tool ermöglicht die Zusammenarbeit und die gemeinsame Nutzung innerhalb von Organisationen in begrenztem Umfang (z. B. keine definierten Arbeitsbereiche), aber Looker Studio Pro, ein neues Upgrade-Angebot von Google, bietet zusätzliche Vorteile und wird im nächsten Abschnitt ausführlich behandelt.

Data Source Connectors - Google

Ein Überblick über verfügbare Konnektoren

 

Nachteile von Looker Studio sind die begrenzten Datenmodellierungsmöglichkeiten und die fehlende Versionskontrolle. Wenn das Startup wächst und seine Anforderungen an das BI-Tool steigen (z. B. tiefergehende Analysen, komplexere Visualisierungen mit mehr Interaktivität, bessere Zusammenarbeit, erweiterte Freigabefunktionen und Benutzer*innenrechte), ist Looker Studio möglicherweise nicht das Tool mit der besten Eignung. Es ist zwar grundsätzlich kostenlos nutzbar, aber für einige der Datenkonnektoren und Datenquellen entstehen zusätzliche Kosten. Außerdem bietet Looker Studio nur eine begrenzte Unterstützung für Big Data und ist möglicherweise nicht in der Lage, große Datensätze effizient zu verarbeiten.

Zusammenfassend lässt sich sagen, dass Looker Studio aufgrund seiner Benutzer*innenfreundlichkeit und Kosteneffizienz die bevorzugte Lösung ist, wenn es um Datenanalyse und -visualisierung für kleinere Unternehmen geht. Wenn ein Unternehmen jedoch schnell wächst und zusätzliche Funktionalitäten benötigt, wäre Looker oder Looker Studio Pro die bessere Wahl. Obwohl also Looker Studio seine Grenzen hat, ist es dennoch ein leistungsfähiges Tool ist, das genutzt werden kann, um wertvolle Erkenntnisse zu gewinnen und den Datenbetrieb für kleine bis mittlere Unternehmen zu optimieren.

 

3. Looker Studio Pro – Der ältere Bruder des Looker Studio

Looker Studio Pro ist ein umfassendes Tool, das auf der Funktionalität und der benutzer*innenfreundlichen Oberfläche von Looker Studio aufbaut. Looker Studio Pro ist mit einer Reihe zusätzlicher Funktionen ausgestattet, die auf größere Unternehmen ausgerichtet sind, z. B. die Möglichkeit

  • Arbeitsbereiche zu definieren,
  • Berechtigungen und Rollen für die Nutzer*innenverwaltung festzulegen,
  • Zugang zu erweitertem Kund*innensupport über Googles Kund*innenbetreuungsprogramm zu erhalten.

Das Abo-Modell kostet rund 7 US-Dollar pro Nutzer *in und Monat, vorbehaltlich spezieller Anpassungen für Ihre Geschäftsanforderungen. Einen individuellen Preisplan bekommen Sie vom Google-Vertriebsteam.

 

Use case 4: Ein mittelständisches Unternehmen, das für jede Abteilung ein eigenes Dashboard erstellen möchte.

Ein mittelgroßes Unternehmen möchte verschiedene interne Dashboards erstellen, um die Leistung der einzelnen Abteilungen überwachen zu können und gleichzeitig Benutzer*innenfreundlichkeit und Effizienz zu gewährleisten sowie nicht-technischen Nutzenden gerecht zu werden. Um das zu erreichen, benötigt jede Abteilung ihren eigenen Arbeitsbereich mit definierten Berechtigungen und Rollen. Dadurch lässt sich kontrollieren, wer auf welche Reports zugreifen, sie erstellen, ansehen oder bearbeiten kann. In diesem Fall erweisen sich die kürzlich hinzugefügten Funktionen von Looker Studio Pro als hilfreich: mit den Möglichkeiten, Teambereiche zu definieren, Berechtigungen und Rollen für die Nutzer*innenverwaltung festzulegen und auf das Kund*innenbetreuungsprogramm von Google zuzugreifen, ermöglicht Looker Studio Pro den Nutzer*innen, Datenarbeiten zu rationalisieren und gleichzeitig eine effiziente Zusammenarbeit und optimierte Leistung sicherzustellen.

Einer der wichtigsten Vorteile von Looker Studio Pro ist die Möglichkeit, separate Arbeitsbereiche zu erstellen, sodass Benutzer*innen individuelle oder gruppenbezogene Zugriffsrechte für jeden Arbeitsbereich definieren können. Darüber hinaus bietet Looker Studio Pro eine Vielzahl von Workspace-Rollen (darunter Manager*innen, Content Manager*innen und Contributor), um die Zusammenarbeit und die Kontrolle über den Datenzugriff weiter zu verbessern – weitere Details zu den Rollen finden Sie hier. Mit Looker Studio Pro ist es nicht mehr nötig, Besitzrechte von Reports zu übertragen, wenn Mitarbeitende das Unternehmen verlassen, was bei Looker Studio hingegen noch notwendig ist.

Team Workspace Pro in Looker Studio Pro

Das neue Team Workspaces Feature in Looker Studio Pro

 

Darüber hinaus kann die Erteilung von Berechtigungen zum Anzeigen oder Ändern von Besitzrechten innerhalb der Organisation über das Identitäts- und Zugriffsmanagement (IAM) in der Google Cloud Platform (GCP) erfolgen.

Permission Space GCP

Der neue Berechtigungsbereich für das Identitäts- & Zugriffsmanagement (IAM) in der GCP

Google bietet derzeit einen privaten Zugang an, um Looker-Studio-Inhalte auf Dataplex zu bringen. Dataplex ist eine intelligente Datenstruktur, die es Unternehmen ermöglicht, ihre Daten über verschiedene Datenspeicher wie Data Lakes, Data Warehouses und Data Marts hinweg effektiv zu lokalisieren, zu verwalten, zu überwachen und zu regulieren. Dies führt zu einer zuverlässigen Kontrolle und ermöglicht umfangreiche Datenanalysen, die sicherstellen, dass auf Daten präzise und akkurat zugegriffen werden kann.

Looker Studio Pro ist eine erweiterte Version von Looker Studio mit zusätzlichen Funktionen, aber immer noch günstiger als Looker. Dies macht es zu einer großartigen Option für mittelgroße bis große Unternehmen, die Zugriffs-, Berechtigungs- und Sicherheitsfunktionen vermissen, ohne dabei das Budget sprengen zu wollen.

 

Zusammenfassung und unser Fazit

Looker und Looker Studio (Pro) sind alle leistungsstarke Datenvisualisierungstools – sie sind aber für unterschiedliche Anwendungsfälle konzipiert und richten sich damit an unterschiedliche Kund*innen.

Trotz anderer vielversprechender Tools (wie Metabase, ThoughtSpot or Lightdash), gilt Looker weithin als eine der besten BI-Lösungen auf dem Markt. Looker eignet sich am besten für Unternehmen, die über große Datenmengen verfügen, die möglicherweise in verschiedenen Datenbanken gespeichert sind, und die ein Tool benötigen, das eine Verbindung zu all diesen Datenbanken herstellen, Daten bereinigen, umwandeln und integrieren und individuelle Visualisierungen erstellen kann. Es bietet eine leistungsstarke semantische Schicht zur Verwaltung wiederverwendbarer Metrik- und Entitätsdefinitionen, Versionskontrolle, eine Planungs- und Benachrichtigungsfunktion, die Möglichkeit zur Einbettung in Websites und Apps, eine API sowie umfangreiche Funktionen zur Benutzer*innen- und Zugriffsverwaltung. Darüber hinaus ist es gut in das Google-Ökosystem integriert, sodass es mit einer Vielzahl anderer Google-Produkte (wie BigQuery) kompatibel ist.
Die Kosten für die Nutzung von Looker können jedoch – mit monatlichen Ausgaben von bis zu tausenden Dollarn – hoch sein, abhängig von einer Vielzahl von Faktoren wie Anzahl und Art der benötigten Lizenzen und der Art der Bereitstellung (selbst gehostet, von Looker gehostet oder von Google Cloud Core gehostet). Andere kleinere Nachteile, die wir sehen, sind die begrenzten Visualisierungsmöglichkeiten im Vergleich zu Tableau (Looker ermöglicht die Entwicklung eigener Visualisierungen mit Javascript, was aber zusätzliche Entwickler*innenressourcen erfordert) sowie den gewissen Lernaufwand, den es benötigt, um mit der eigenen Sprache Look ML zu arbeiten. Auch erwähnenswert ist hier, dass Looker nicht für einmalige Analysen oder explorative Arbeiten an neuen Datensätzen gedacht ist, da die erforderlichen Dimensionen und Maße zuerst in LookML modelliert werden müssen. Außerdem hat sich seit der Übernahme durch Google im Februar 2020 die Qualität des Kundensupports verschlechtert, da weniger und nicht so erfahrene Mitarbeiter*innen zur Unterstützung der Nutzer*innen zur Verfügung stehen. Andererseits hat Google seine Bemühungen verstärkt, Looker besser in sein bestehendes Produktportfolio zu integrieren. Mit der jüngsten Ankündigung von „Looker Modeler“ gliedert Google die semantische Schicht von Looker als eigenständiges Produkt aus und öffnet sie für andere BI-Tools und Anwendungen.

Looker Studio ist eine hervorragende Option für kleinere Unternehmen, die einfache, interaktive Dashboards und Reports erstellen möchten – ohne horrende Kosten oder umfangreiche IT- und Datenressourcen dafür zu benötigen. Es ist auch ideal für individuelle Analysen, einmalige Visualisierungen und Reports. Looker Studio kann nahtlos eine einzelne Datenquelle, voraggregierte Datensätze, Tabellenkalkulationsdaten und CSV-Dateien verarbeiten und bietet eine große Auswahl an nativen Konnektoren, von denen einige jedoch zusätzliche Kosten erzeugen können.

Für diejenigen, die sich eine größere Kontrolle über Nutzer*innenbereiche, Berechtigungen, Rollen und Zusammenarbeit auch über GCP wünschen, ist ein Upgrade auf Looker Studio Pro eine gute Option für kleines Geld. Außerdem können Kund*innen mit dem Google Customer Care Programm deutlich besseren Support erwarten und haben die Option, Service Level Agreements (SLAs) mit Google zu schließen.

Jedes Tool hat damit seine eigenen Stärken und Grenzen und die Auswahl des geeigneten Tools hängt von den individuellen Anforderungen und Anwendungsfällen Ihres Unternehmens ab.

 

Um Ihnen dabei zu helfen, die Vor- und Nachteile der BI-Tools von Google mit Ihren Anforderungen abzugleichen und die für Ihr Unternehmen am besten geeignete Lösung zu evaluieren, finden Sie hier eine übersichtlich strukturierte Zusammenfassung des Tool-Vergleichs:

 

Hier Überblick als PDF herunterladen

 

Sie haben Fragen zu Looker oder Looker Studio (Pro), benötigen Unterstützung bei der Auswahl und Implementierung der richtigen Datenarchitektur für Ihr Unternehmen oder bei der Extraktion von Daten aus Ihren 3rd Party Tools und Produktionsdatenbanken in Ihr Data Warehouse? Unsere Expert*innen stehen Ihnen gerne mit Rat und Tat und ihrer Erfahrung zur Seite. Wir freuen uns von Ihnen über contact@feld-m.de zu hören!

Mehr über unsere Data Product Services erfahren Sie hier.

Sie möchten wissen wie sich Googles BI Produkte weiter entwickeln und alle 2-3 Monate die News, Trends und Best Practices aus dem Data & Analytics-Universum in Ihr Postfach bekommen? Hier geht’s zur Anmeldung zu unserem Newsletter.

 

(mehr …)

Alle reden von CTV (Connected Television), von IoT (Internet of Things) und Connected Driving, dem Vernetzten Fahren. Längst nutzen wir nicht nur die Fernbedienung, um das Auto aufzusperren, sondern navigieren souverän durch die vielfältigen Optionen und Annehmlichkeiten des digitalen Autos – von Cockpit-Systemen bis hin zur Fahrzeug-App auf dem Handy. Diese Möglichkeiten haben wir, weil Autos inzwischen „vernetzt“, also mit dem Internet verbunden, sind. Doch die Verarbeitung personenbezogener Daten setzt auch bei vernetzten Technologien außerhalb von Websites eine Zustimmung der betroffenen Personen voraus. Dabei gibt es verschiedene Anforderungen für die verschiedenen Analytics Use Cases, mit denen Mehrwert geschaffen werden kann – für Hersteller, Nutzer*innen und Drittparteien.

 

Mehr Daten brauchen mehr Datenschutz

Die diametrale Entwicklung von Big Data und Datenschutz stellt auch für die Automobil-Industrie eine große Herausforderung dar.

  • Einerseits können so viele Daten erhoben werden wie nie zuvor: Autobesitzer*innen interagieren mit ihren Fahrzeugen über In-Car-Multimedia-Systeme oder mit Apps, die mit dem Fahrzeug verbunden sind. Das Auto selbst erhebt Daten über das Fahrverhalten und die Abnutzung von Verschleißteilen. Wichtige Funktionen aus Motor und Getriebe werden überwacht, um mögliche Schäden frühzeitig zu erkennen und die Sicherheit für die Fahrenden zu erhöhen. So weit, so gut.
  • Andererseits wird die Nutzung ebendieser Daten immer schwieriger: Die Datenschutz-Grundverordnung (DSGVO) regelt seit geraumer Zeit verbindlich, worauf aus datenschutzrechtlicher Sicht bei der Datenverarbeitung, insbesondere bei der Erhebung und der anschließenden weiteren Prozessierung zu achten ist. Werden beim Fahren oder der Mensch-Fahrzeug-Interaktion Daten mit Personenbezug erhoben, dürfen sie in der Regel nur mit Einwilligung zu weiteren Analysezwecken verarbeitet werden.

Die Autoindustrie muss darüber nachdenken, wie sie Daten auf eine konforme Weise verarbeiten kann und wie die Nutzer*innen wirklich verstehen können, was mit ihren Daten passiert, denn nur so ist eine informierte Einwilligung zur Datenverarbeitung durch die Nutzer*innen bzw. Fahrer*innen möglich.

 

Welche personenbezogenen Daten werden beim Connected Driving erhoben?

Bei Anwendungsfällen aus dem Bereich Connected Driving geht es vor allem um folgende IDs, die nach DSGVO als personenbezogenes Datum gelten und deshalb die Einwilligung der Nutzer*innen benötigen, bevor sie verarbeitet werden dürfen:

  1. User ID: Diese kommt vor allem aus dem Bereich Web Analytics bzw. einem der dominierenden Web-Analytics-Systeme (z. B. Google Analytics, Adobe Analytics, PiwikPRO). Sie wird zufällig generiert und bezieht sich eigentlich gar nicht auf den User, sondern auf das Device bzw. sogar nur den jeweiligen Browser.    Wird über das In-Car-Multimedia-System ein Service aufgerufen, der auf einer Web-Applikation beruht, kann die Nutzer*inneninteraktion über „normales“ Web Tracking erhoben werden. Wie seit geraumer Zeit bekannt, muss auch für diese Art von Tracking eine Einwilligung eingeholt werden.
  2. Fahrzeugidentifikationsnummer (FIN): Dabei handelt es sich um eine pro Fahrzeug eindeutige ID. Über diese ID kann rückverfolgt werden, um welches Fahrzeug es sich genau handelt. Integriert man diese ID in Datensysteme, in denen auch Daten aus anderen Systemen erhoben werden, könnte grundsätzlich eine eindeutige Verbindung zwischen Fahrzeug und einer Person hergestellt werden. Die Verarbeitung der FIN für Analytics-Zwecke benötigt somit ebenfalls Einwilligung.
  3. Login ID: Auch Automobilhersteller versuchen bereits seit Längerem, individuelle Bereiche für Autobesitzer*innen zur Verfügung zu stellen. Nach einem Autokauf erhält man einen Account, mit welchem man zusätzliche Inhalte und Funktionen nutzen kann, die nur den jeweiligen Autobesitzer*innen zur Verfügung stehen. Diese Inhalte werden nur nach Login angeboten. Die Login ID ist eindeutig pro Person (z. B. E-Mail-Adresse, Benutzername) und somit ein Datum, das zwar spannende Analytics Use Cases zulässt, jedoch ebenfalls eine zweckgebundene Einwilligung voraussetzt.

Um sowohl interessante und wertschöpfende Analyse- als auch Aktivierungs-Use-Cases umzusetzen, ist es mitunter notwendig, diese IDs (gesondert oder auch im Zusammenspiel) zu verarbeiten. Nur über eindeutige IDs, wie die oben genannten, können Interaktionen und Datenpunkte, die zu ein und derselben Person oder demselben Fahrzeug gehören, verknüpft werden. Darüber können beispielsweise Erkenntnisse über verschiedene Fahrer*innensegmente gewonnen werden und wir können verstehen, wie die gesamtheitliche Customer Journey von Autobesitzer*innen – von der Informationsbeschaffung, über den Kauf, bis hin zur Nutzung von Login-basierten Inhalten und dem Verhalten im Auto – aussieht.

 

Connected Driving Use Cases – Wie können Daten aus dem Fahrzeug Mehrwert liefern?

Analytics

Je mehr Datenpunkte ein Unternehmen zur Verfügung hat, desto mehr Erkenntnisse können daraus gewonnen werden. Die Erkenntnisse können dann wiederum die Verbesserung, Anpassung oder Neuentwicklung von Funktionen, der Produktion oder Marketingmaßnahmen anstoßen.

Aus unserer Erfahrung können Analytics Use Cases durch die Anreicherung mit In-Car-Daten vielfältig sein und echten Mehrwert stiften. Mögliche Anwendungsfälle:

  • Verstehen, wie Nutzer*innen interagieren:
    Wie nutzen Fahrer*innen die bereitgestellten In-Car und Connected-Drive Features? Welche Nutzungspfade gibt es? Wie unterscheiden sich die beobachteten Pfade von der herstellerseitig intendierten Nutzer*innenführung? Welche Befehlssteuerung wird bevorzugt (z. B. Touchscreen, Mittelkonsole, Sprachsteuerung)?
  • Planen zukünftiger Entwicklungen:
    Stehen Entwicklungsaufwände im Verhältnis zur tatsächlichen Nutzung? Wie kostenintensiv ist die Bereitstellung einzelner Funktionen und wie oft werden sie letztendlich genutzt? Was sind die meistgenutzten Funktionen und wie präsent werden diese angezeigt?
  • System-Performance messen:
    Wie gut funktioniert die Interaktion zwischen Auto und anderen Systemen (z. B. App zum Steuern einzelner Funktionen wie Sitzheizung oder Klimatisierung)? Was sind die häufigsten Fehler?
  • Erstellen unterschiedlicher Nutzer*innen-Profile:
    Gibt es unterschiedliche Segmente von Nutzer*innen bezüglich der Interaktion mit den bereitgestellten Funktionen, z. B. Musikliebhaber, Technisch-Affine, Puristen? Wie korrelieren unterschiedliche Nutzer*innen-Segmente mit dem Fahrzeugtyp (z. B. E-Fahrzeuge vs. Sportwagen vs. Family-Van)? Wie können wir Daten über das Fahrverhalten erheben und analysieren, um unterschiedliche Profile von Fahrer*innen-Typen zu erstellen?

Bezüglich der Einwilligung zur Datenverarbeitung sollte einerseits zwischen Fragestellungen, die auch ohne Zuordnung zu Nutzer*innen oder Fahrzeug funktionieren, und anderseits jenen, die eine Zuordnung zu mindestens einer der oben genannten IDs bedürfen, unterschieden werden. Gerade wenn es um das reine Verstehen von Interkationen oder der Häufigkeit der Nutzung verschiedener Features geht, ist eine solche Zuordnung nicht zwangsläufig notwendig. Ein Erstellen von Segmenten und das Herstellen einer Verbindung zum Auto wird hingegen ohne ID nicht möglich sein.

Sobald das Erheben einer oder mehrerer dieser IDs erforderlich ist, um die genannten Analytics Use Cases umzusetzen, ist auch eine rechtlich saubere Einwilligung einzuholen. Fahrer*innen müssen in die Erhebung aktiv einwilligen und dabei transparent informiert werden, welche Daten wofür erhoben werden und wie die jeweiligen Automobilhersteller (oder deren Dienstleister) diese weiter verarbeiten, also verwenden.

 

In-Car Activation

Werden die Daten erst einmal erhoben und weiterverarbeitet, können sie in einem nächsten Schritt im Auto selbst aktiviert werden. Das Multimedia-System eines Autos bietet einen zusätzlichen digitalen Touchpoint, der – ähnlich zu anderen Touchpoints wie Websites und Apps – für eine direkte und individualisierte Kunden*innen-Ansprache genutzt werden kann. So können In-Car-Daten, ggf. zusammen mit Daten aus anderen Bereichen, so verarbeitet werden, dass die Autonutzung, das Fahrerlebnis oder die Nutzung digitaler Services rund um das Auto nutzer*innenzentriert angepasst werden können.

Für Automobilhersteller entstehen dadurch unter anderem folgende Möglichkeiten:

  • Personalisierte In-Car-Multimedia-Inhalte:
    Ähnlich wie bei der Personalisierung von Websites oder mobilen Apps kann dank der Daten und Insights, die aus In-Car Analytics generiert wurden, eine personalisierte Gestaltung des Multimedia-Systems erfolgen. Je nachdem, welche Funktionen ein*e Fahrer*in öfter nutzt oder zu welchen Zeiten welche Funktionen genutzt werden, kann das Interface personalisiert werden. Werden zusätzlich die Daten aus unterschiedlichen Bereichen (mit dem Auto verbundene App(s), persönlicher Login-Bereich, In-Car) zusammengeführt, kann eine ganzheitliche personalisierte User Experience aufgebaut werden, die auf allen beteiligten Touchpoints – und somit auch innerhalb des Autos – bereitgestellt werden kann.
  • Erstellen verschiedener Fahrer*innenprofile:
    Integriert man neben den Interaktionsdaten der digitalen Touchpoints auch jene aus dem Auto selbst – sprich: die Daten über Fahrverhalten und sensorische Daten aus Fahrwerk und Motor – so können verschiedene Profile angelegt werden. Wird ein Auto beispielsweise von mehreren Familienmitgliedern genutzt oder haben mehrere Personen eines Unternehmens Zugriff auf ein gewerbliches Fahrzeug, so könnte über das Verarbeiten der Daten ein Profil pro Person erstellt werden. Eigens dafür verwendete Machine-Learning-Algorithmen könnten von der Nutzung der Multimedia-Funktionen und dem individuellen Fahrstil der jeweiligen Personen lernen. Wählt eine Person dann beim Einsteigen ihr entsprechendes Profil aus, wird ihr Fahrerlebnis möglichst genau auf ihre individuellen Bedürfnisse zugeschnitten.
  • Schaffen zusätzlicher Umsätze über In-Car Sales:
    Zusätzliche Touchpoints sind auch zusätzliche Points-of-Sale (PoS). Während wir es bereits gewohnt sind, Online-Käufe über unser Smartphone zu tätigen, ist es ebenfalls denkbar, dies auch über den Touchscreen unseres Autos zu tun. Für Automobilhersteller bietet sich dadurch die Möglichkeit, den Kund*innen dort Angebote zu machen, wo sie auch wirklich relevant sind. Unter der Annahme, dass die Daten entsprechend erhoben, integriert und prozessiert werden, könnten mögliche In-Car Angebote wie folgt aussehen:
    „Sie scheinen ein*e sportliche*r Fahrer*in zu sein. Testen Sie für nur xx,xx € unser Upgrade für die Motoreinstellung auf das Paket «Sport».“
    „Wir merken, dass Sie gerne reisen. Upgraden Sie jetzt für nur xx,xx € auf die erweiterte Version unseres Navigationssystems und genießen Sie dadurch zusätzliche Vorteile im Ausland.“

Zugegeben, je fortgeschrittener die Use Cases werden, desto mehr stellt sich auch die Frage nach tatsächlicher Machbarkeit. Dennoch, moderne Automobile sind einerseits bereits eine wertvolle Datenquelle, andererseits haben sie auch das Potenzial, ein ebenso wertvoller aktivierbarer Kund*innen-Touchpoint zu sein. Sind die Daten grundsätzlich vorhanden bzw. ist es zumindest möglich, diese zu verarbeiten und lassen das In-Car-Multimedia-System bzw. das Auto selbst es zu, flexibel Anpassungen vorzunehmen, ist eine Umsetzung solcher Use Cases zumindest aus technischer Sicht durchaus möglich.

Bezüglich der Einwilligung wird es hier entsprechender komplexer: Möchte ich im Zusammenhang mit der Nutzung von Connected Driving erhobene Daten im jeweiligen Auto aktivieren, müssen diese auch zu jederzeit und eindeutig ebendiesem Auto – oder in manchen der beschriebenen Beispiele: dem Auto UND einer Person im Auto – zugewiesen werden können. Eine zweckgebundene, eindeutige und freiwillige Einwilligung muss entsprechend eingeholt werden und von den Nutzer*innen auch jederzeit widerrufen werden können. Hier stellt sich die Frage, ob eine Einwilligung vor jeder Fahrt eingeholt werden muss, da es durchaus möglich ist, dass mehrere Personen ein und dasselbe Auto nutzen. Beim Starten des Autos weiß dieses aber noch nicht, welche Person hinter dem Lenkrad sitzt. Zudem können unterschiedliche Personen unterschiedliche Präferenzen haben, was die Einwilligung zur Datenerhebung und -prozessierung betrifft. Beim Widerruf einer einst erteilten Einwilligung muss sichergestellt werden, dass dieser Widerruf für alle an der Datenarchitektur beteiligten System greift. Eine angeforderte Löschung muss ebenfalls für alle Systeme garantiert werden.

 

Data-Sharing

Eine weitere Kategorie möglicher Use Cases ergibt sich durch Datenpartnerschaften mit Drittunternehmen. Hier kann großer Mehrwert für alle beteiligten Parteien entstehen, jedoch kann der Vorteil der einen Partei auch zum Nachteil für eine andere werden. Für die Einwilligung ist das entsprechend relevant, da ein*e Fahrer*in naturgemäß vorsichtig wäre, seine bzw. ihre Einwilligung für einen Zweck der Datenverarbeitung zu geben, der ihm bzw. ihr auch zum Nachteil gereichen könnte.

Ein Beispiel für ein solche Partnerschaft ist das Teilen von erhobenen Fahrzeug- und Fahrverhaltensdaten mit Versicherungsunternehmen. In Form eines „Pay-as-you-Drive“-Modells ließe sich die Versicherungspolice für jede Person individuell und anpassbar gestalten. Daten aus dem Fahrzeug würden es Versicherungsunternehmen erlauben, das der Police zugrundeliegende Risiko besser und für jede Person individuell einschätzen zu können. Der Versicherungsbetrag würde somit nicht pauschal aus der Grundgesamtheit aller Versicherten oder allgemeiner Parameter berechnet werden, sondern individuell für die jeweilige Person. Hier zeigt sich aber auch die Schwierigkeit eines solchen Modells: Als Fahrer*in, der*die vorsichtig und/oder selten mit dem Auto fährt, wäre so ein Modell von Vorteil; für unvorsichtige und/oder Vielfahrer*innen wäre es aber höchstwahrscheinlich von Nachteil. Wenn wir nun davon ausgehen, dass es eine Einwilligung für diesen Zweck der Datenübermittlung braucht, würde erstere Gruppe vermehrt zustimmen, zweitere vermehrt ablehnen. Inwiefern eine Versicherung wiederum von einer Datenbasis aus nahezu nur vorsichtigen Fahrer*innen profitieren würde, ist selbstredend schwierig einzuschätzen und abzusehen.

Würde das Erheben und Teilen der dafür notwendigen Daten sich allerdings nicht nur auf den Versicherungsbetrag, sondern auch auf die verschiedenen Bestandteile einer Versicherung auswirken, könnte das für jede*n Autobesitzer*in von Interesse sein. Kann man beispielsweise je nach Fahr- und Nutzungsverhalten unterschiedliche Bestandteile einer Police hinzu oder abwählen, könnte jede Person ihre ganz individuellen Risiken bestmöglich und auf sie zugeschnitten versichern.

Ein weiteres Beispiel, welches zu großen Teilen auch schon Realität ist, ist das Teilen von Fahrzeugdaten mit Autohäusern und Werkstätten. Durch die Verarbeitung und das Teilen von Daten aus dem Fahrzeug können Werkstätten zum Beispiel Service-Termine direkt im Display des jeweiligen Autos vorschlagen oder auf Angebote aufmerksam machen. Je mehr Daten zur (Ab-)Nutzung aus dem Auto gesammelt, verarbeitet und zur Verfügung gestellt werden und je besser die dafür notwendige Datenarchitektur gestaltet ist, umso fortschrittlicher können die Anwendungsfälle sein. So kann „Predictive Maintenance“ dazu beitragen, Abnutzungen oder kleinere Mängel frühzeitig zu erkennen und möglichen Schäden proaktiv entgegenzuwirken. Der*die Autobesitzer*in spart sich dadurch Geld, der Automobilhersteller erhöht dank verbesserter Customer Experience die Chance auf eine langfristige Kundenbindung.

Sieht man sich diese Data-Sharing Beispiele aus Sicht des Consent Managements an, unterscheiden sie sich nicht stark von jenen der In-Car-Datenaktivierung. Werden personenbezogene Daten erhoben und verarbeitet – was bei diesen Use Cases der Fall ist – ist eine DSGVO-konforme Einwilligung notwendig. Das detaillierte Informieren über den Zweck der Datenverarbeitung ist dabei entscheidend. Insbesondere, wenn die Verarbeitung Drittparteien – wie beispielsweise Versicherungen – einschließt.

 

Einwilligungsraten und transparente Kommunikation am Point-of-Consent

Es ist anzunehmen, dass Kund*innen ein Teilen ihrer Daten mit anderen Parteien mit Vorsicht genießen und zunächst auch zögerlich sein werden, den eigenen Fahrstil evaluieren und bewerten zu lassen. Daher sind Automobilhersteller in diesen Fällen besonders gefordert, – im Vorfeld, aber auch am Point-of-Consent – Vertrauen aufzubauen, um eine belastbare und wirklich mehrwertstiftende Datengrundlage zu erhalten. Die transparente Kommunikation und das Herausstellen eines zu erwartenden Nutzens für die jeweilige Person sollte deshalb ein Kernelement des Consent-Managements sein. Doch auch hier stellt sich die Frage, wie sich das Einholen der Einwilligung, die Verarbeitung der Daten und die letztendliche Nutzung der Daten im konkreten Fall optimal gestalten lässt – insbesondere in Szenarien, in denen mehrere Personen Zugriff auf dasselbe Auto haben, aber nicht vor jeder Fahrt mit einem Consent-Banner oder Einwilligungsaufruf konfrontiert sein wollen. Ein möglicherweise täglich wechselnder Einwilligungsstatus verhindert außerdem zusammenhängende Daten und Einsichten, was bei zunehmender Unregelmäßigkeit den grundsätzlichen Mehrwert der Daten in Frage stellt und die Anzahl der sinnvollen Use Cases stark limitiert.

Datenmacht und Verantwortung: Wem gehören die Daten aus dem Auto eigentlich?

Wem genau die Daten aus dem Auto gehören, ist juristisch nach wie vor ungeklärt: Gehören sie dem Autohersteller, der sie erhebt oder den Besitzer*innen der Fahrzeuge? Den Tech-Unternehmen, die das vernetzte Auto erst ermöglichen? Der Öffentlichkeit, da die Daten einen faire(re)n Wettbewerb ermöglichen würden? Verbraucherschützer*innen, Automobilzulieferer*innen und Versicherer befürchten, dass sich das geplante EU-Gesetz, das diese Frage beantworten sollte, nun erneut verzögert.

Bisher gilt die normative Kraft des Faktischen: Das Problem ist, dass die Daten im Moment bei den Fahrzeugherstellern liegen und diesen damit ein großer Wettbewerbsvorteil gegenüber dritten Parteien, Zulieferern und StartUps entsteht. Von der Datensouveränität der Individuen ganz zu schweigen. Mit einer finalen Entscheidung, die dieses Datenmonopol der Hersteller brechen könnte, rechnet man während dieser EU-Legislaturperiode nicht mehr, obwohl bereits 2021 ein Gesetzesentwurf hätte vorliegen sollen. Mit der Verzögerung werden nun Fakten zugunsten der Hersteller geschaffen, die ihr Datenmonopol zunächst behalten dürfen. Die Branche freut‘s.

Der Zugang zu diesen Mobilitäts- und Fahrzeug-Daten wäre jedoch ganz entscheidend für neue Geschäftsmodelle. „40 bis 50 Datenpunkte brauche es von einem Fahrzeug in etwa, um beispielsweise neue Versicherungskonzepte wie „Pay-as-you-drive“ oder Ferndiagnosen oder -wartung realisieren zu können, heißt es aus der Branche. Auch die Zulieferer haben ein starkes Interesse daran, dass Dritte wie etwa freie Werkstätten einen Zugriff auf die Fahrzeugdaten haben. Ein unabhängiger Reparaturmarkt ist für sie Voraussetzung, um die Abhängigkeit von den großen Autoherstellern zu reduzieren.“ (Kugoth 2023)

Ein mögliches Szenario wäre es, dass die EU-Kommission auf Regelungen für diesen spezifischen Sektor verzichtet und stattdessen auf den Data Act verweist, der Daten für Drittparteien besser nutzbar machen soll. Damit wäre jedoch die Automobilbranche ganz und gar nicht einverstanden, da der Data Act – analog zu den letzten Digitalgesetzen der EU, wie dem Digital Services Act – die Nutzer*innen in den Mittelpunkt stellt, die die Hoheit über ihre Daten behalten sollen – auch wenn es für die meisten Autofahrer*innen vermutlich schwer sein dürfte, zu durchdringen, wofür welche ihrer Fahr- und Fahrzeugdaten letztlich genutzt werden (könnten). Ob die deutsche Bundesregierung das Thema des Datenzugriffs auf Fahrzeugdaten in das geplante Mobilitätsdatengesetz aufnehmen wird, bleibt unklar, soll derzeit aber geprüft werden.

 

Kugoth, J. (30. Januar 2023), Brüssel bremst bei Fahrzeugdaten, Mobilitätsdienstleister empört. https://background.tagesspiegel.de/mobilitaet-transport/bruessel-bremst-bei-fahrzeugdaten-mobilitaetsdienstleister-empoert. Zugriffen: 1. März 2023.

Vielen Dank an David Berger und Gabriela Strack (Bay-Q) für Input und rechtlichen Check.

 

Tl;dr:  

  • Das TTDSG regelt Bestimmungen zum Fernmeldegeheimnis und zum Datenschutz bei Telemedien, also auf Websites. Es ersetzt die Datenschutzregelungen des Telemediengesetzes (TMG) und des Telekommunikationsgesetzes (TKG), passt sie an die Regelungen der DSGVO an und dient in erster Linie der Umsetzung der ePrivacy-Richtline 
  • Ziel ist es, vor allem Rechtsklarheit zu schaffen 
  • Schutz der Geräteintegrität: Websites brauchen ab dem 1. Dezember 2021 für Cookies und Tracking eine echte Einwilligung der Nutzer*innen 
  • Nahezu jede Website braucht damit ein DSGVO-konformes Consent Banner  
  • Das TTDSG gilt auch für Messengerdienste und Apps

 

Hintergrund zum TTSDG 

Am 01.12.2021 trat das neue deutsche Telekommunikations-Telemedien-Datenschutzgesetz, kurz TTDSG, in Kraft, nachdem es im Mai 2021 im Bundestag beschlossen wurde. Da der erste Entwurf zum TTDSG erst vom Juli 2020 stammt, könnte man von einem sehr strikten Zeitplan und einer wirklich schnellen Umsetzung sprechen. Doch genau das Gegenteil ist der Fall: Der deutsche Gesetzgeber ist der letzte der europäischen Gesetzgeber, der der Umsetzungspflicht aus der ePrivacy-Richtlinie aus 2009 nachkommt. Impulsgebend für das am Ende doch zügige Vorgehen war sicherlich auch die höchstrichterliche Rechtsprechung des EuGH und BGH, die dem deutschen Gesetzgeber kein gutes Zeugnis ausgestellt hat.  

 

Die wichtigsten Regelungen im TTDSG für Website- und Shopbetreiber 

Im Folgenden finden Sie die wichtigsten Punkte, die Sie beim Tracking Ihrer Kund*innen und Nutzer*innen auf Ihrer Website oder App berücksichtigen müssen. 

Die gute Nachricht vorweg: Es kommt zu keinen gravierenden Änderungen der Rechtslage. Ähnlich  wie beim Inkrafttreten der DSGVO setzt das neue Gesetz die bereits seit dem Cookie-Urteil des BGH vom 28. Mai 2020 gelebte Praxis um und bringt die an dieser Stelle eher unklaren Bereiche der DSGVO mit den Anforderungen aus der ePrivacy-Richtlinie miteinander in Einklang. 

 

Gültigkeit und Geltungsbereich 

Das TTDSG ist ab dem Tag des Inkrafttretens anwendbar (1. Dezember 2021). Es gibt keine Übergangszeit. Es gilt für alle Unternehmen, die eine Niederlassung in Deutschland haben oder Waren/Dienstleistungen auf dem deutschen Markt anbieten.  

Es gilt technologieunabhängig! D.h. es gilt im Bereich der Tracking-Technologien nicht nur für Cookies, sondern beispielsweise auch für die Nutzung von Browser Fingerprinting oder der Nutzung des Local Storage. 

 

Fokus und Abgrenzung zur DSGVO 

Das TTDSG nimmt die Speicherung auf den Endgeräten der Nutzer*innen und das Auslesen von Geräte-Identifiern in den Fokus; die Verarbeitung von personenbezogenen Daten wird hingegen weiterhin durch die DSGVO geregelt. 

 

Speicherorte 

Das neue TTDSG macht in Hinblick auf die Speicherung der Daten keinen Unterschied, wo die Daten aufbewahrt werden (z.B. lokal oder in der Cloud). 

 

Speicherung/Auslesen von Informationen ohne Einwilligung  

Das TTDSG erlaubt es, Informationen in der Endeinrichtung der Nutzer*innen zu speichern (Cookie zu setzen) oder auf Informationen, die in der Endeinrichtung der Nutzer*innen bereits gespeichert sind, zuzugreifen (Cookies auszulesen). Dies geht ohne die Einwilligung des Nutzers, wenn das Speichern bzw. der Zugriff unbedingt erforderlich ist, damit der von Nutzer*innen ausdrücklich gewünschte Telemediendienst (Website/App) vom Anbieter zur Verfügung gestellt werden kann.

Die anschließende Verarbeitung von personenbezogenen Daten ist dann auch einwilligungsfrei erlaubt. 

 

Technische Erforderlichkeit von Analyse- & Verwaltungsfunktionen 

Analyse-Technologien (Cookies) können als unbedingt erforderlich betrachtet werden, wenn sie beispielsweise zur Leistungsmessung, dem Erkennen von Navigationsproblemen, der Schätzung erforderlicher Serverkapazitäten oder zur Analyse abgerufener Inhalte eingesetzt werden.

 

Tag Management Systeme 

Der Einsatz von Tag Management Systemen ist grundsätzlich einwilligungsfrei erlaubt. Beim Einsatz von Google Tag Manager (GTM), der Teil von Google Universal Analytics ist, bestehen Bedenken hinsichtlich der einwilligungsfreien Nutzung. Der einwilligungsfreie Einsatz des GTM sollte daher mit der eigenen Rechtsberatung abgeklärt werden.

 

Berechtigtes Interesse 

Sollen Cookies oder andere Tracking-Technologien gemäß berechtigtem Interesse eingesetzt werden, muss das berechtigte Interesse in den Datenschutzbestimmungen beschrieben und begründet werden. 

 

Dynamische Zweckbindung von Cookies 

Wird ein Cookie gesetzt, der sowohl einwilligungsfreie als auch einwilligungsbedürftige Informationen speichert bzw. ausliest, und erteilen Nutzer*innen keine Einwilligung, darf der im Cookie gespeicherte Identifier nur für die einwilligungsfreien Zwecke genutzt werden. Die Einwilligungspflichtigen müssen unterbleiben. Diese Zwecke müssen im Vorwege festgelegt, bei dem Einsatz eingehalten und Nutzer*innen darüber transparent informiert werden.  

Dies ist beispielsweise der Fall, wenn zur Reichweitemessung bei der Umsetzung eines anonymen Trackings das Tracking Cookie modifiziert wurde. Stimmt der Nutzer oder die Nutzerin dem einwilligungspflichtigen Standardtracking zu, müsste der vorher gesetzte Cookie gelöscht und ersetzt werden. Dies sollte dann bei jeder Änderung der Zustimmung in den Privatssphäre-Einstellungen erfolgen. 

 

Informationspflichten und Consent Management 

Das TTDSG schreibt eine umfassende Informationspflicht nur bei einwilligungspflichtigen Zugriffen vor. Die Einholung der Einwilligung unterliegt den gleichen Bedingungen wie nach der DSGVO und muss durch eine bestätigende Handlung z.B. auf einem entsprechenden Button eines Consent-Banners ausgeführt und auch aufwandsgleich wieder zurückgenommen werden können. Vorhandene installierte Consent Management Plattformen können also weiterhin wie gehabt genutzt werden und dürfen ebenfalls einwilligungsfrei zum Einsatz kommen. 

 

Speicherdauern und Kriterien 

Bei der Bereitstellung der Informationen ist darauf zu achten, dass nicht nur die Speicherdauer, sondern auch die Kriterien für die Lebensdauer der Cookies angegeben werden (z.B. automatische Löschung durch den Browser wegen Inaktivität). 

 

Browsereinstellungen, PIMS und Plug-Ins 

Das TTDSG schreibt nicht vor, dass individuelle Einstellungen im Browser (Opt-Out) zu berücksichtigen sind. Das TTDSG verpflichtet jedoch die künftige Bundesregierung, durch Rechtsverordnung sicher zu stellen, dass Browser den jeweils aktuellen Einwilligungsstatus der Nutzer*innen berücksichtigen. Das soll mit Hilfe von Diensten zur Einwilligungsverwaltung, den sogenannten PIMS (Personal Information Management Systems) erfolgen. PIMS ermöglichen den Nutzer*innen ihre erklärten Einwilligungen und Widersprüche für die genutzten Websites übersichtlich zu dokumentieren und zu steuern. Die Rechtsverordnung soll auch Vorgaben für die Ausgestaltung der PIMS hinsichtlich der Nutzer*innenfreundlichkeit, der Wettbewerbskonformität und technische Umsetzung enthalten. Mit der entsprechenden Verordnung wird für kommendes Jahr gerechnet. Einstweilen finden Sie hier weitere Informationen zur Einordnung des ADPC-Programms des österreichischen Datenschutzvereins noyb als PIMS. 

 

Bußgelder und Strafen 

Das TTDSG bedient sich eines eigenen Bußgeldrahmens mit einer Obergrenze von EUR 300.000, der bei Verstößen gegen das Einwilligungsgebot wirksam wird. Derselbe Verstoß kann dann aber nicht mehr zusätzlich durch die DSGVO sanktioniert werden. 

 

Ausblick: Wie geht’s weiter mit Datenschutzrecht, Cookies und Tracking? 

Einer der spannendsten Punkte im TTDSG sind die bereits erwähnten PIMS, zu deren Konzeption, Umsetzung und Einsatz noch keine endgültige Klarheit herrscht. Eine Experten-Kommission des Bundeswirtschaftsministeriums berät im Jahr 2022 über die technische Beschaffenheit und mögliche Einsatzvarianten von PIMS. Bis Ende 2022 will die Kommission im Parlament die technischen Voraussetzungen verabschiedet haben, sodass diese Veränderung in absehbarer Zukunft zu berücksichtigen sein wird. (Quelle: Tagesspiegel Background Newsletter vom 04.11.2021 “Delegierte Datensouveränität”) 

Dies könnte dazu führen, dass Ende des kommenden Jahres das “Consent Management” allein bei den Nutzer*innen liegt und Zustimmungen und Widerrufe mit einem Klick zentral verwaltet werden können – beispielsweise in einem Browser-Plug-In. Dadurch besteht die Möglichkeit, dass Consent Management Systeme auf den Websites überflüssig werden, da letztere angehalten sind, auf den Nutzer*innenwillen gemäß der PIMS zu hören. Allerdings halten wir das Aussterben von klassischen Consent Management Systemen derzeit für nicht sehr wahrscheinlich, da ein Nutzer*innenwille durch den gezielten Opt-In oder Opt-Out auf einer Website direkt letztlich unmittelbarer abgebildet werden kann, als über eine globale Zustimmung oder Ablehnung via PIMS. Wie sich das jedoch genau gestalten wird, wird zu sehen sein. Auch eine neue Erfolgswelle für Micro-Consents – also Consents, die an der jeweiligen Stelle der Website direkt abgefragt werden, z.B. ob man auf Nachrichtenseiten die originalen Tweets eingeblendet bekommen möchte – ist durchaus denkbar.  

Darüber hinaus könnten in Zukunft auch die noch immer in Abstimmung befindliche ePrivacy-Verordnung sowie der Digital Services Act einige Neuerungen bringen. Sie sehen: Beständig ist in der digitalen Datenschutzwelt nur der Wandel.  

 

Kontaktieren Sie uns, wenn Sie den Wandel bei Ihnen mit uns gemeinsam gestalten möchten.  

Diese Information wurde zusammen mit den Datenschutzexpert*innen von Bay-Q erarbeitet (http://www.bay-q.com/).  

 

Teil 1, Das Datacroft „Link Manager“ Kampagnentracking-Tool.

Der Bereich der Marketingtechnologie (MarTech) ist in den letzten Jahren mit einer erstaunlichen Geschwindigkeit gewachsen. Vor einigen Monaten gab es schätzungsweise 8.000 verschiedene Tools und Lösungen auf dem Markt*, und es wird davon ausgegangen, dass diese Zahlen in Zukunft noch viel stärker explodieren werden. Da wir bei FELD M bereits seit 2012 MarTech-Lösungen unter der Marke „Datacroft: FELD M Products“ entwickeln, wollten wir Euch einen Blick „hinter die Kulissen“ gewähren und erzählen, warum wir uns entschieden haben, unsere Produkte zu entwickeln – sozusagen die origin story unserer Produkte 😊.

Die MarTech-Landkarte

Aber gehen wir zunächst zurück zur MarTech-Landkarte: Der Grund, warum die Zahl der MarTech-Lösungen so stark gewachsen ist,  dass sich die Entwicklungsbedingungen dafür stark verbessert haben: In allen Marketing-Bereichen, vom Adserving zu CDPs, von Personalisierung bis zum Vertrieb, von Content-Erstellung bis zum Workflow-Management, wird daran gearbeitet, spezifische Aspekte des Marketings durch die Entwicklung neuer Tools zu automatisieren und/oder zu verbessern, so dass sie effizienter und damit für die Kunden kostengünstiger abgewickelt werden können. Ein weiterer wesentlicher Bestandteil dieser Lösungen ist, dass sie sich in der Regel in alle anderen MarTech-Tools im Tech-Stack eines Kunden integrieren lassen, so dass eine Reihe von Tools miteinander verbunden werden können, um die Arbeitsabläufe weiter zu optimieren und Overhead zu reduzieren. Das übergeordnete Ziel von MarTech-Tools ist es, zu automatisieren, zu erweitern und zu integrieren („automate, augment and integrate“).

Einige dieser neuen Tools werden von Service-Agenturen selbst entwickelt, weil diese Agenturen entweder eine Lösung für ihre eigenen internen Anforderungen als Marketing-Agentur benötigen oder weil sie die Anforderungen ihrer Kunden erfüllen müssen **.

Dies spiegelt genau die Art und Weise wider, wie wir bei FELD M dazu gekommen sind, unsere eigene business unit, Datacroft: FELD M Products zu gründen, um unsere eigenen „kleinen Helfer“-Lösungen und Services zu entwickeln, die unseren Kunden helfen, ihre Marketingaktivitäten datengesteuert zu analysieren und zu optimieren. Wir möchten Euch nun einen tieferen Einblick geben, wie wir auf die Idee gekommen sind, unsere Produkte zu entwickeln – und beginnen in Teil 1 mit unserem Kampagnentracking-Tool, dem „Link Manager“.

Der Datacroft „Link Manager“

Unsere Motivation für die Entwicklung unseres ersten Produkts war ganz simpel: Wir waren in der Excel-Hölle und wollten endlich raus.

Genauer gesagt waren wir 2012 damit beauftragt, eine globale Kampagnentracking-Linkstruktur für eine große Anzahl von Märkten und Geschäftsbereichen eines großen Firmenkunden von uns zu pflegen und zu validieren. Das geschah damals mit mehreren marktspezifischen Excel-Dateien, die von uns gemäß den Kundenanforderungen konfiguriert worden waren. Das Problem war, dass einige dieser Märkte ihre eigene Vorstellung davon hatten, wie ihr Kampagnentracking aussehen sollte, und sie waren gut darin, unsere Excel-Vorlagen auf jede erdenkliche Weise zu benutzen – nur nicht so, wie wir (und unser direkter Ansprechpartner, die Zentrale des Unternehmens) es beabsichtigt hatten, damit die Daten kanalübergreifend und auf globaler Ebene analysiert werden konnten. Schließlich gelang es uns, die Zentrale von unserer Produktidee zu überzeugen, und sie gab uns grünes Licht, damit wir mit der Entwicklung des Software-as-a-Service-Tools beginnen konnten, aus dem der „Link Manager“ entstanden ist.

Nun mussten wir uns überlegen, mit welchen Features wir unser neues Tool ausstatten sollten. Einerseits sollte unser Tool den Märkten ein Höchstmaß an Flexibilität und Spielraum gewähren, aber andererseits nur so weit, dass das Ziel der Zentrale, kanalübergreifende und globale Analysen erstellen zu können, nicht dadurch gefährdet wurde.

Zunächst haben wir unsere bisherigen Erfahrungen mit Kampagnentracking in Kundenprojekten aufgeschrieben, um herauszufinden, was unser Tool unseren Nutzern bieten sollte:

  • Oft wurden wir gebeten, Trackinglinks sehr kurzfristig zu erstellen, weil an Kampagnentracking erst sehr knapp vor Kampagnenstart gedacht wurde – deshalb erreichten uns zu diesem Zeitpunkt meist sehr dringende E-Mails oder Anrufe, weil noch Trackinglinks fehlten und unsere Kunden diese JETZT, am besten GESTERN, haben wollte!
  • Oft fehlten auch wichtige Kampagnendaten, die ebenfalls kurzfristig ergänzt werden mussten, zum Beispiel neue Kampagnennamen oder Produktnamen. Wenn die richtigen Werte nicht rechtzeitig hinzugefügt werden konnten, verwendeten die Benutzer oft irgendeinen Wert, der vage mit ihren Kampagnentypen übereinstimmte (oder auch nicht…), was natürlich die Datenqualität minderte.
  • Die beiden oben genannten Punkte – fehlende Trackinglinks und fehlende oder fehlerhafte Daten – führten zu einer allgemein schlechten Qualität der Kampagnendaten in Web Analytics – Lösungen, mit denen wir konfrontiert wurden, wenn unsere Kunden uns baten, Kampagnenberichte auf der Grundlage dieser Daten zu erstellen. Diese Berichte waren dann oft ziemlich nutzlos und konnten nicht zur Analyse aktueller Kampagnen oder zur Optimierung zukünftiger Kampagnen verwendet werden (was übrigens immer das Ziel sein sollte). Oft mussten wir entweder versuchen, Annahmen anhand von historischen, hoffentlich korrekten Daten zu treffen, und dadurch einen gewissen Einblick zu gewinnen, oder wir versuchten, andere Daten zu finden, mit denen wir die Lücken in den Kampagnendaten füllen konnten. Alles in allem war es keine sehr befriedigende Arbeit, denn das Hauptproblem – die schlechte Datenqualität des Kampagnen-Traffics unserer Kunden – wurde nicht gelöst.
  • Während des Kampagnen-Tracking-Prozesses mussten wir mit Personen kommunizieren, die über unterschiedliche Skill Level und Fachwissen verfügten und ein unterschiedliches Bewusstsein für die Bedeutung von Kampagnendaten hatten: Von Webanalysten auf Kundenseite, die jeden Tag in ihre Berichte schaute und über detaillierte Kenntnisse der Tracking-Implementierung Bescheid wissen, bis hin zu den Account Managern der Service-Agenturen, die die Daten, die sie messbar machen sollten, nie zu sehen und zu nutzen bekamen und überhaupt keine Kenntnisse von Tracking-Implementierungen hatten. Da unser Tool von beiden Nutzergruppen verwendet werden sollte, mussten wir bei der Gestaltung der Benutzeroberfläche und der Funktionen beide im Blick haben.
  • Außerdem mussten wir uns mit den unterschiedlichen technischen Tracking-Anforderungen unserer Kunden auseinandersetzen. Bei unseren Kunden hatte sich die Struktur der Kampagnenmessung im Web Analytics Tool oft über Jahre hinweg entwickelt und war manchmal ziemlich kompliziert und festgefahren. Alles zu verwerfen und mit einer neuen, sauberen Struktur zu beginnen, war oft keine Option. Das Setup der Kampagnenmessung musste manchmal nicht nur die Anforderungen von Web Analytics – Lösungen erfüllen (unser Tool unterstützt übrigens jede Art von Web Analytics-Lösung, nicht nur Adobe Analytics), sondern auch die von anderen Tools und Systemen, die im Laufe der Zeit hinzugekommen waren. Ein „one size fits all“-Ansatz funktionierte also nicht immer für alle unsere Kunden, sie benötigten viel öfters Custom Anpassungen.

 

Auf der Grundlage dieser Erfahrungen haben wir die folgenden development guidelines aufgestellt:

  • Einfacher Zugang für alle: Wir vergeben an all unsere Kunden eine unbegrenzte Anzahl an Benutzerlogins, auf die jede*r Nutzer*in per Browser zugreifen kann. Selbst wenn vor Kampagnenstart alles sehr eilig und gehetzt ist, gibt es also keinen Engpass, weil der Kollege mit dem lizenzierten User Login gerade nicht erreichbar ist.
  • Einfach zu bedienende Oberfläche: Es sind keine Kenntnisse über Tracking-Implementierungen erforderlich, um unser Tool zu nutzen. So ist jede*r Nutzer*in in der Lage, kurzfristig neue Daten hinzuzufügen und neue Trackinglinks zu erstellen.
  • Bulk-Upload-Funktion: Natürlich ist nicht alles, was in Excel gemacht wird, schlecht! Gerade wenn es um viele Trackinglinks auf einmal geht, kann eine Excel-basierte Lösung sehr effizient sein. Deshalb haben wir eine Lösung entwickelt, mit der Trackinglinks in großen Mengen in einer Excel-Datei erstellt werden können, die dann in unser Tool hochgeladen werden, so dass unsere Nutzer*innen das Beste von beiden Welten haben.
  • Automatische Validierung von Trackinglink-Daten und URLs, so dass die Datenqualität in Webanalyse-Reports steigt und fehlerhafte Landingpage-URLs erkannt werden können, bevor sie zu Marketingmaßnahmen hinzugefügt werden. Da unbrauchbare Kampagnendaten zu unbrauchbaren Kampagnenberichten führen, wollten wir sicherstellen, dass unsere Benutzer so schnell wie möglich die richtigen Daten auswählen und eventuelle Fehler erkennen können, ohne selbst händische Qualitätsprüfungen durchführen zu müssen.
  • Außerdem können wir die neuen Daten, die die Nutzer im Tool hinzufügen und/oder auswählen können, so einschränken, dass sie vordefinierten Namenskonventionen entsprechen müssen, was wiederum die Datenqualität erhöht. Wie bereits erwähnt, wollen wir einerseits so viel Flexibilität wie möglich für jede Art von Marketingkanal gewährleisten, da viele Kanäle ihre eigenen spezifischen Tracking-Anforderungen haben, andererseits wollen wir aber auch sicherstellen, dass die Kampagnendaten in einer konsistenten Struktur aufgebaut sind, die ein globales, kanalübergreifendes Reporting ermöglicht. Wir können z. B. Dropdowns mit Werten vorbelegen, die nicht geändert werden können, um eine einheitliche Schreibweise zu gewährleisten. Wir können auch die Eingabemöglichkeiten von Freitextfeldern einschränken, so dass die Benutzer ein bestimmtes Format einhalten müssen, z. B. nur Kleinbuchstaben, keine Leerzeichen, nur Unterstriche als Trennzeichen usw.
  • Individuelle Anpassungen auf der Grundlage kundenspezifischer Anforderungen: Es war uns schon immer sehr wichtig, Custom Wege zu finden, um spezifische Kundenanforderungen zu erfüllen und unsere Lösung so eng wie möglich an bestehende Infrastruktur anzupassen. Auf diese Weise können wir natürlich auch neue Feature-Ideen entdecken, die für alle unserer Kunden von Nutzen sein können. Wir haben zum Beispiel unsere Trackingcode-Logik so angepasst, dass sie mit einem String von abgekürzten Kampagnenwerten befüllt werden kann, nachdem unser Kunde MINI Deutschland dies von uns angefragt hatte (anstatt einen Unique ID-Trackingcode zu nutzen, wie wir es zuvor für andere Kunden getan hatten). Diese Anforderung kam zustande, weil die Trackinglinks nicht nur für das Adobe Analytics Setup, sondern auch für das CRM-Tool „Top Drive“ funktionieren mussten. Es ist jetzt eine Standardfunktion und wurde für viele verschiedene Arten von Trackingcode-Logiken verwendet.

Jetzt, im Jahr 2021, wurde unser „Link Manager“ SaaS-Tool bereits von einer Reihe von Kunden lizenziert, von einem mittelständischen eCommerce-Unternehmen bis hin zu globalen Konzernen mit einer großen Anzahl von Märkten wie der BSH Group und der BMW Group.

Da wir bereits vor 9 Jahren gestartet sind und uns immer eng an den Anforderungen und Bedürfnissen unserer Kunden orientiert haben, können wir heute mit dem „Link Manager“ einen Grad an Produktinnovation und technischer Reife bieten, den andere Anbieter in ihrem Produktzyklus noch nicht erreicht haben.

Für weitere Informationen über unser Tool besucht bitte unsere Produktseite unter

https://datacroft.de/link-manager/

In Teil 2 werden wir über den „Campaign Data Importer“ sprechen, ein Tool, das eng mit dem „Link Manager“ verknüpft ist!

Startseite – suchbare Übersicht über alle Trackinglinks in der Datenbank

 

Linkerstellungsmaske

 

Automatischer URL check

 

Bulk Upload feature, um eine große Anzahl von Trackinglinks auf einmal zu erstellen

 

*Quelle: https://chiefmartec.com/2020/04/marketing-technology-landscape-2020-martech-5000/

**Quelle: The Martech Show Episode #5: 5 Martech Trends for the Decade Ahead / The Agency View: https://www.youtube.com/watch?v=DnMAl5d0Zx8

Als Antwort auf einige Probleme, die ich mit der Custom Code Rule Action (CCA) von Adobes Core Extension hatte, habe ich vor zwei Jahren meine eigene Adobe Launch Extension geschrieben. Angeregt durch eine  aktuelle Diskussion auf Twitter, habe ich mich nun entschlossen, diesen Beitrag zu verfassen.

Zudem veröffentliche ich meine neue Extension Friendly Helpers, die eine Synchronous Code Rule Action als Lösung für die Schwierigkeiten mit der CCA beinhaltet. Zusätzliche Funktionen sind bereits in Planung. Der Code ist Open Source. Weitere Details finden Sie am Ende dieses Beitrags.

Einleitung

Ich möchte vorwegschicken, dass ich im Herzen Entwickler bin. Um das Setup für weniger technisch versierte Nutzer nicht unnötig kompliziert zu machen, sollte Custom Code in Adobe Launch meiner Meinung nach möglichst zurückhaltend eingesetzt werden. In vielen Fällen ist benutzerdefinierter Code jedoch unvermeidlich, sobald man ein umfangreiches Setup aufbauen möchte – und genau das tun wir hier bei FELD M. Ein gut durchdachtes Data Layer Konzept kann zwar helfen, Regeln einfach zu halten. Letztendlich werden fortlaufende Ergänzungen aber immer mehr Lösungen auf Basis von benutzerdefiniertem Code erforderlich machen. Das beste Beispiel dafür sind in meinen Augen die technischen Implikationen der DSGVO.

Vor Einführung der DSGVO schickten die meisten Webseiten ihre Analytics Requests am Seitenende ab. Doch das war einmal – heute läuft alles asynchron. Launch muss warten, bis das Consent Management Tool der Wahl geladen wurde und dann auf dessen Antwort reagieren. Außer natürlich, Sie haben die Rechtsabteilung mit (echten) Cookies bestochen und man hat das Tracking standardmäßig erlaubt… nur um es dann zwei Monate später auf einen Aktiven Opt-in anzupassen. Ja, so kann das laufen. Ich kann gar nicht sagen, wie viele verschiedene Datenschutzimplementierungen und -interpretationen mir in den letzten Jahren bei meinen Kunden untergekommen sind. Ohne den regelmäßigen Einsatz von Custom Code wäre dies nicht möglich gewesen wäre.

Der etwas unsanfte Start von Launch

Mit dem offiziellen Ende vom DTM starteten im Jahr 2018 eine Vielzahl von Migrationsprojekten – die meist nicht ganz so glatt liefen, wie erhofft. Adobe hat zwar umfangreiche Informationen über die Migration von einem System zum anderen bereitgestellt (siehe hier), aber der Teufel steckte wie so oft im Detail. Die CCA und die Frage, wie Launch mit der von Adobe selbst eingeführten asynchronen Ausführung umgeht – oder besser gesagt nicht umgeht – führte regelmäßig zu Schwierigkeiten.

Tatsächlich war das größte Problem gar nicht die CCA selbst, sondern die Adobe Analytics Extension. Im DTM erfolgte die Ausspielung des AppMeasurement Objekts (auch bekannt als „s“-Object) synchron mit dem auslösenden Event. Nicht so in Launch. Hier sind Adobe Analytics Aktionen, wie beispielsweise „Set Variables“, in ein sogenanntes „Promise“ verpackt. Das bedeutet, dass sie unabhängig vom auslösenden Event erst zu einem späteren Zeitpunkt ausgeführt werden, beispielsweise wenn die Analytics Extension all ihre Abhängigkeiten, wie z.B. das AppMeasurement, geladen hat. Hat sich der Data Layer in der Zwischenzeit geändert? Pech gehabt; falsche Daten wurden an Adobe Analytics gesendet.

Dieses Problem veranlasste mich, meine erste Launch-Erweiterung für einen event-driven data layer (EDDL) mit kontextbezogenen Daten zu programmieren, ähnlich dem Adobe Client Data Layer – nur etwa 2 Jahre früher und nur 5KB groß…
Sie wird derzeit von DER SPIEGEL, den Schweizerischen Bundesbahnen (SBB) und anderen Kund*innen in der DACH-Region verwendet. Die CCA, die ich eigentlich mehr als kleines Goodie zu der Erweiterung hinzugefügt hatte, hat sich im Laufe der Zeit zu einem geschätzten Asset entwickelt.

Wie die CCA funktioniert

Bevor ich auf die technischen Gründe eingehe, warum ich die Synchronous Code Action erstellt habe, werfen wir einen kurzen Blick darauf, wie die CCA der Adobe Core Extension für JavaScript funktioniert. Aaron Hardy von Adobe hat die Details in diesem Community-Post beschrieben.

Kurz gesagt: Custom JavaScript Code wird in Launch auf zwei Arten behandelt:

Regeln basieren auf dem Event „page bottom“ oder „page top“ (library loaded)
Der Code wird als String in die Launch library Datei aufgenommen. Auf der Client-Seite wird er dann in einen Skript-Tag verpackt und mit Hilfe von document.write zum Dokument hinzugefügt.

Regeln basieren auf einem anderen Event
Der Code wird nicht in der Launch library gebündelt. Stattdessen wird er in eine separate Datei gespeichert, die geladen werden muss. Der Code selbst ist nur Text, der mit Hilfe von postscribe zum Dokument hinzugefügt wird.

Grund 1: Verwirrend

Im DTM konnten Sie aktiv zwischen „sequentiellem“ und „nicht sequentiellem“ benutzerdefiniertem JavaScript wählen.

Auch Launch bietet zwei verschiedene Implementierungen von benutzerdefiniertem Code an. Allerdings stellt es nur eine CCA zur Verfügung, deren Verhalten – wie oben beschrieben – von den event-Typen der Regel abhängig ist. Welche Methode verwendet wird, ist in der Benutzeroberfläche nicht ohne Weiteres ersichtlich. Entweder Sie wissen es – oder sie wissen es eben es nicht. Aufgrund der weitreichenden technischen Implikationen, die damit einhergehen, stellt dies ein großes Problem dar. Wir sollten in der Lage sein, aktiv zu wählen, welche Methode verwendet werden soll.

Grund 2: Keine sofortige Ausführung

Zeitkritische Events wie Click-Listener und das Unload-/Page Hide Event sind regelmäßig vorkommende Anwendungsfälle, bei denen eine sofortige Codeausführung erforderlich ist. Leider funktioniert die Verwendung der CCA in einer Regel, die auf einem einfachen Click-Listener basiert, so nicht. Wenn ein Benutzer auf einen Link klickt, muss der Code erst heruntergeladen werden. In dieser Zeit wurde der Seitenkontext mit hoher Wahrscheinlichkeit bereits aktualisiert (Single Page Application => falsche URL/Seitenname) oder er geht sogar ganz verloren, wenn der Browser navigiert (=> kein Analytics-Hit wird gesendet).

Eine mögliche Lösung wäre es, den Code entweder in Rule Conditions oder Events einzubinden. Diese sind immer direkt in der Launch library gebündelt. Damit sind zwar meine technischen Probleme gelöst, aber die Regeln werden dadurch weniger übersichtlich. Würde nur ich selbst mit dem Launch Setup arbeiten, könnte ich darüber noch hinwegsehen.

Eine andere mögliche Lösung, bei der nur die Core Extension verwendet wird, besteht darin, die Code-Bündelung zu erzwingen, indem man der Rule ein „page bottom“- oder „page top“-Event hinzufügt und es in einer Bedingung aufhebt.  Urs Boller hat dazu einen hervorragenden Blog-Beitrag verfasst. Jedoch bläht dieser Ansatz die Regel ein wenig auf. Zudem löst er auch nicht die anderen technischen Probleme.

Grund 3.1: Performance – Gehostete Dateien und Dateigröße

Besonders aufmerksam haben die Entwickler*innen bei meinen Kund*innen die Performance von Launch beobachtet, da wir ihnen im Zusammenhang mit dem Wechsel von DTM zu Launch natürlich ein deutliche Performance-Verbesserung versprochen hatten. Sowohl die Größe der gebündelten Dateien als auch die Größe der gesamten Assets wurden kritisch betrachtet. Hier hat Adobe das Versprechen eingehalten: Launch ist schneller, die Bündelung ist intelligenter. Es lädt z.B. nur die Teile von Erweiterungen, die Sie tatsächlich brauchen und benutzen.

Abgesehen von den Extensions fehlt jedoch die Möglichkeit zur Feinjustierung von Custom Code. Es steht nur der Custom Code von Adobes Core Extension zur Verfügung. Außerdem führen, wie bereits erwähnt, die technischen Implikationen der DSGVO und andere asynchrone Abhängigkeiten dazu, dass sowohl „Page Bottom“ als auch „Page Top“ (library loaded) Events seltener verwendet werden. Dadurch steigt die Anzahl der separaten Code-Dateien, die auf jeder Seite für die Ausführung des Analytics-Setups benötigt werden. Nur nutzen diese eben nicht die Standard event trigger.

Es gibt also Anwendungsfälle, in denen man unbedingt möchte, dass der Code direkt in der Launch-Bibliothek gebündelt wird und nicht erst von einem Server geladen werden muss. Es kann vorteilhaft sein, eine einzelne, größere Datei zu laden, anstatt vieler kleiner Dateien. Das ist einer der Gründe, warum JS-Code-Bundler existieren.

Außerdem wird CCA-Code nicht minimiert.

Zu guter Letzt fügt das einfache Einbinden von CCA in Ihre Library, selbst wenn es nur um das Hinzufügen von console.log('yay it works') geht, Ihrer Launch Library-Datei etwa 6kb hinzu. Launch muss nun die entsprechende Logik einbinden, einschließlich Postscribe, die das CCA-Verhalten ermöglicht.

Grund 3.2: Performance – document.write

Eine zweite Implikation im Zusammenhang mit der Performance ist die fortlaufende Verwendung von document.write, das nach wie vor von der CCA verwendet wird, um Code zum Dokument hinzuzufügen. Ich weiß nicht wie oft sich schon Entwickler*innen bei mir gemeldet haben, um sich genau darüber zu beschweren. Das war ein großes Problem für meine Kund*innen. „Ihr habt hohe Performance versprochen, aber ihr verwendet hier document.write“.

Fürs Protokoll: Ich habe dieses Verhalten bei Launch in letzter Zeit seltener beobachtet. Trotzdem, document.write ist im Quellcode enthalten und das wird von Entwickler:innen in Reviews auch weiterhin kritisch angemerkt.

Grund 4: XHTML-Fehler

Letztes Jahr meldete sich ein Kunde bei mir: Man hatte festgestellt, dass für bestimmte Webseiten Daten fehlten. Ich sah nach. Alles war in Launch korrekt aufgesetzt. Ein Schlüsselelement des benutzerdefinierten Codes, der eine direkt in die Library eingebundene JavaScript CCA verwendete, wurde jedoch nicht richtig auf der Website geladen.

Es stellte sich heraus, dass alle betroffenen Seiten XHTML-Seiten waren.

Failed to set the 'innerHTML' property on 'Element': The provided markup is invalid XML, and therefore cannot be inserted into an XML document.

Leider kann ich den Fehler derzeit nicht reproduzieren. Die betroffenen Webseiten wurden seitdem angepasst. Aus der „Known Errors“-Dokumentation meines Kunden geht hervor, dass die Lösung darin bestand, von der CCA zur Verwendung der Synchronous Code Action zu wechseln.

Dies könnte damit zusammenhängen, dass Launch den benutzerdefinierten Code als String speichert, wenn er in die Library eingebunden wird. Der String muss dann zur Laufzeit in eine Funktion zur Ausführung konvertiert werden. Das Einfügen des geparsten Codes in das Dokument schlug fehl.

Lösung: Synchronous Code Action

Die oben genannten Gründe haben mich dazu veranlasst, eine Synchronous Code Action zu erstellen, bei der benutzerdefinierter JavaScript Code direkt in Form einer Funktionsdefinition in die Adobe Launch library eingebunden wird. Dadurch werden alle oben genannten Probleme behoben.

Der folgende Code zeigt, wie die Synchronous Code Action und die CCA (unter Verwendung eines Page-Top-Events) in die launch-library.js eingebunden werden.

{
    // [...]
    "actions": [
        {
            "modulePath": "friendly-helpers-feldm/src/lib/actions/synchronousCode.js",
            "settings": {
                "callback": function (event, target, Promise) {
                    console.log('Friendly Helper', arguments, 'this:', this);
                }
            }
        },
        {
            "modulePath": "core/src/lib/actions/customCode.js",
            "settings": {
                "source": "console.log('Custom Code',arguments,'this:', this);",
                "language": "javascript"
            }
        }
    ]
}

Beachten Sie, dass der CCA-Benutzercode ein String ist, der auf der Client-Seite erst umgewandelt werden muss.

Die Entwicklung der Extension selbst und die technischen Details würden den Rahmen dieses Blogs sprengen. Daher sei bis zu diesem Punkt auf  die offizielle Dokumentation als guten Ausgangspunkt verwiesen.

Technische Details für Entwickler:innen von Extensions

Das Kernstück der Synchronous Code Action ist ein „transform“ Feature im Extension Manifest. Hier die relevante Dokumentation: extension manifest documentation > function transforms:

Using the function transform tells Platform Launch to wrap the user’s code in a executable function when it is emitted in the Platform Launch runtime library

Der benutzerdefinierte Code für Events und Bedingungen in Adobes Core Extension verwendet ebenfalls diese Funktionstransformation. Die Synchronous Code Action ist somit einfach die CCA, die anstelle des derzeit undokumentierten customCodeTransformation die Funktionstransformation verwendet. Wir können dies im Extension Manifest im Git-Repository von Adobes Core Extension sehen. Zum jetzigen Zeitpunkt (April 2021) sind nur file, function undremove Transformationen dokumentiert.

Ein weiteres wichtiges Puzzlestück – die Bereitstellung einer GUI, in der Benutzer ihren eigenen Code eingeben können – müssen wir glücklicherweise nicht selbst schreiben. Launch bietet über Extension Bridge API Zugriff auf den eingebauten Code-Editor.

Die „Friendly Helpers“-Erweiterung

Ich habe eine neue Extension entwickelt, „Friendly Helpers“, um Adobe Launch um eine Reihe nützlicher Funktionen zu erweitern, die nicht von Haus aus mitgeliefert werden. Den Anfang macht dabei die Synchronous Code Action.

Der Code ist Open Source und hier verfügbar: https://github.com/feld-m/Friendly-Helpers

Ich beabsichtige, die Erweiterung über Adobe öffentlich zugänglich zu machen. Damit können Sie die Extension ganz einfach zu Ihrer Launch Property hinzufügen. Bis dahin ist sie leider nur als private Erweiterung verfügbar, die Sie für Ihre Organisation installieren müssen. Eine Anleitung dazu finden Sie in der Readme-Datei im Repository.

Folgende weitere Rule Actions sollen der Erweiterung hinzugefügt werden.

Wenn Sie Vorschläge für weitere Funktionen haben, melden Sie sich bitte und ich werde sehen, was ich tun kann! E-Mail: analytics@feld-m.de

Die Erweiterung verwendet die Adobe Coral/Spectrum UI, um ihr das gleiche Aussehen und Nutzer:innenerlebnis wie der Launch GUI zu geben. Der relevante Code befindet sich im src/views Ordner.

Wie FELD M Ihr komplexes Web Analytics Tracking Setup in einem Tag Management System umsetzt

Es ist keine Seltenheit für internationale Unternehmen, dass eine Website in mehreren Sprachen existiert. Es ist ebenfalls gut möglich, dass sich die Länderwebseiten nicht nur in der Sprache, sondern auch inhaltlich unterscheiden. Dies erfordert in der Regel ein komplexes Web Tracking Setup im Tag Management System – gerade wenn auch noch mehrere Stakeholder ins Spiel kommen.

Die scheinbar unlösbare Schwierigkeit: Ein Tracking-Setup für mehrere Märkte

FELD M kennt dieses Szenario bereits sehr gut, da viele unserer Kund:innen mit solch einer Konstellation und den unterschiedlichen Zielen der einzelnen Stakeholder konfrontiert sind. Stakeholder wie die Web Analytics Abteilung eines Unternehmens, die Führungsetage, die Marketingabteilung, die Marktverantwortlichen oder die Produktverantwortlichen wollen in der Regel unterschiedliche Informationen im jeweiligen Detailgrad. Ein übergreifendes KPI-Konzept ist daher ohnehin Voraussetzung für ein so komplexes Tracking Setup.

Wer braucht welche Analyticsdaten?

Mit Fokus auf die folgenden beiden Stakeholder zeigen wir beispielhaft, wie vielfältig die Anforderungen an ein Web Tracking sein können.

Stakeholder: Zentrale Web Analytics Abteilung

Häufig gibt es eine zentrale Abteilung im Unternehmen, die sich speziell um Web Analytics und Tracking kümmert. Diese Abteilung möchte gewährleisten, dass das Tracking auf allen Länderwebsites einheitlich und skalierbar ist. Die Märkte sollen das einheitliche Web Tracking in der Regel nicht verändern können, da ansonsten keine länderübergreifenden Analysen mehr möglich sind.

Stakeholder: Marktverantwortliche
Gleichzeitig gibt es aber auch Marktverantwortliche, die auf ihren spezifischen Länderseiten spezielle Inhalte anpassen und tracken wollen. Beispielsweise möchten sie Inhalte manipulieren, um A/B Tests auszusteuern oder sie wollen Module, die sie speziell für den Markt entwickelt haben, mit Tracking versehen. Neben der Web Analyse für den eigenen Markt, wollen Marktverantwortliche oft auch Marketing Tags auf ihren Länderwebsites integrieren.

No size fits all – Unterschiedliche Tools erfordern unterschiedliche Lösungen

FELD M hat dieses komplexe Setup bereits für mehrere Kund:innen auf verschiedene Art und Weisen umgesetzt. Aber warum braucht es überhaupt verschiedene Herangehensweisen? Dies liegt vor allem am jeweiligen Tool Stack unserer Kund:innen. Jedes Tag Management System und jedes Analytics Tool weist unterschiedliche Funktionalitäten auf . Es gibt also nicht die eine Wahrheit. Oder?

Wie FELD M die Analytics-Anforderungen unter einen Hut bringt: Die eierlegende Wollmilchsau für diese Art von Tracking Implementierungen

Wir haben einen Ansatz gefunden, der quasi diesem Hybridwesen entspricht. Voraussetzung dafür ist ein Tag Management System, das ein granulares Rollen- und Rechtekonzept sowie Vererbung zwischen verschiedenen Ebenen ermöglicht. Auf diese Ebenen oder Layer gehen wir gleich noch genauer ein.

Ein Hoch auf das Data Layer und Tag Management für Fortgeschrittene

Um all die Anforderungen der angesprochenen Stakeholder berücksichtigen zu können, muss eine einheitliche und strukturiert geordnete Basis geschaffen werden. Diese Basis stellt das Data Layer dar – ein JavaScript Objekt auf der Website, das alle trackingrelevanten Informationen enthält. Ein identisch strukturiertes Data Layer über alle Webseiten hinweg ermöglicht ein skalierbares Tracking Setup im Tag Manager.
Mit einem entsprechenden Aufbau im Tag Management System können nun alle Anforderungen in Bezug auf das Tracking und die Stakeholder erfüllt werden. Ein modularer Aufbau stellt sicher, dass es keine negativen Interferenzen gibt.

Layer 1: Core Tracking
Das Core Tracking bildet das Herzstück für das Tracking aller Webseiten, unabhängig von Sprache und Content. Es kann nahezu ohne zusätzlichen Aufwand ausgerollt werden und stellt ein Basis Tracking sicher.

Layer 2: Module Tracking
Für spezifische Module, die beispielsweise auf unterschiedlichen Marktseiten eingesetzt werden oder die ein ausführlicheres Tracking erfordern, das nicht über das Core Tracking abgebildet werden kann, gibt es einen zweiten Layer im Tag Management System. Hier wird das Core Tracking auf eine modulare Weise erweitert. Auf Layer 1 und 2 hat nur die zentrale Web Analytics Abteilung Zugriff. Dadurch wird sichergestellt, dass es zum einen ein einheitliches Tracking über alle Seiten gibt, dass aber zum anderen auch spezifischere Trackinganforderungen abgebildet werden können. Durch die zentrale Verwaltung des Trackings können weiterhin alle Daten länderübergreifend analysiert werden.

Layer 3: Markt Ebene
Marktverantwortliche können ausschließlich auf diese Ebene im Tag Manager zugreifen. Dadurch können sie spezifische Anpassungen für ihren Markt vornehmen und spezielles Tracking, Marketing Tags oder Feedback Tools einbinden. FELD M bietet hierzu Schulungen an, damit die einzelnen Märkte das Beste aus ihren Websites herausholen können!

Geringer Maintenance Aufwand und hohe Datenqualität – Win-win für alle Beteiligten

Dank der modularen Struktur im Tag Management System bleibt die Datenqualität hoch – bei geringem Maintenance Aufwand, was natürlich auf lange Sicht Kosten spart. Aus der Konfliktsituation zu Beginn, die unterschiedliche Ziele von diversen Stakeholdern beinhaltete, machen wir also eine Win-Win-Situation.
Ein großer Vorteil der beschriebenen Herangehensweise im Tag Manager ist, dass eine Verwaltung von Tags auf verschiedenen Ebenen stattfinden kann. Die jeweiligen Verantwortlichen haben Zugriffe auf die entsprechenden Layer und können Anpassungen auf der globalen Ebene durchführen, aber auch auf Webseiten-Ebene oder Markt-Ebene. FELD M konfiguriert hierzu verschiedene Rollen im Tag Management System, um Zugriffe zu ermöglichen, aber auch einzuschränken.
Und auch die Analysten werden sich freuen: die Web Analytics Daten sind von hoher Qualität und konsistent über Websites, Anwendungen und Märkte hinweg. Happy analyzing!

FELD M berät Ihr Unternehmen gerne, welches Tag Management Setup Ihre Anforderungen erfüllt und welches Tag Management System dafür geeignet ist. Wir sind Spezialist:innen im Bereich Web Analytics und haben bereits für viele Unternehmen ganz unterschiedlicher Größe eine Tracking Implementierung inklusive Data Layer umgesetzt.
Mehr zu unseren Leistungen im Bereich Digital Analytics finden Sie hier: https://www.feld-m.de/service/digital-analytics/
Und hier gibt es noch ein paar Projektbeispiele für Sie: https://www.feld-m.de/projekte/

Mit der Ankündigung von Google Analytics 4 (GA4) unternimmt Google den nächsten Schritt für seine Analyseplattform. Dieser Schritt beinhaltet einige der größten Funktionsänderungen in der Geschichte von Google Analytics. Das bekannte Datenmodell wurde geändert und auf nur den einen verfügbaren Typ „Ereignisse“ reduziert, der an GA4 gesendet werden kann. Da Daten von Websites und Apps nun nativ in einer Property gesammelt werden können, bieten sich für die Nutzer:innen neue Analysemöglichkeiten.  

Die Bekanntgabe von Google, einen nativen Konnektor anzubieten, um Daten an BigQuery zu senden, war eine der aufregendsten Neuigkeiten. Denn diese exklusive Funktion war bisher nur zahlenden Kunden von GA360 vorbehalten und steht nun allen Nutzer:innen von Google Analytics 4 zur Verfügung.  

  

Warum sollte man Google Analytics 4-Daten an BigQuery senden  

Zugang zu Daten auf Hit-Ebene  

Die kostenlose Version von Universal Analytics (dritte Generation von Google Analytics) bot keinen direkten Zugriff auf Hit-Level-Daten und die Analyse von Hit-Level-Daten war insgesamt eine Herausforderung. Besonders, wenn es um spezifischere Fragen ging (wie z.B. Fragen zur Datenqualität), war es schwierig, diese ohne Zugriff auf Hit-Level-Daten zu lösen oder zu debuggen.   

  

Ungesampelte Daten in jedem Fall   

Die Stichprobenbildung innerhalb von Google Analytics war immer ein Problem, insbesondere wenn innerhalb eines großen Datensatzes viele verschiedene Werte für eine Dimension auftraten. Innerhalb von BigQuery findet keine Stichprobenziehung mehr statt.  

  

Daten in BigQuery umgehen teilweise Limitierungen des Interfaces 

Daten, die mehr Ereignisparameter enthalten als das Google Analytics Interface handhaben könnte, werden direkt an BigQuery gesendet und sind dort verfügbar, während sie in der Benutzer:innenoberfläche von Google Analytics fehlen. Die Berücksichtigung von Googles Limit ist immer empfehlenswert – nun erhalten wir aber eine zusätzliche kleine Absicherung gegen Datenverlust.  

  

Breite Palette möglicher Analysefälle   

Mit den verfügbaren Hit-Level-Daten sind viele Anwendungsfälle möglich, die ohne eine 360er-Lizenz nicht verfügbar wären. Die meisten Analysen, die Google anbietet, von der deskriptiven Analyse bis hin zu Prognoseanalysen, basieren hauptsächlich auf historischen GA-Daten. Mit diesen Daten in der Hand können ab jetzt theoretisch all diese Analysen selbst durchgeführt werden 

   

Nutzung der Cloud-Infrastruktur   

Die Google Cloud bietet zahlreiche Tools und Funktionen an. Da BigQuery ein Teil der Google Cloud ist, können andere GCloud-Tools nativ integriert werden. Ein Beispiel wäre „Dataprep„, welches hilft, Daten zu bereinigen und für die Analyse vorzubereiten.   

 Source: https://cloud.google.com/dataprep 

 

Sehr günstig im Vergleich zu einer Unternehmenslizenz  

Es entstehen keine Kosten, wenn GA4 mit BigQuery verknüpft wird, aber die Nutzung von BigQuery ist nicht kostenlos. Für die Speicherung und Verarbeitung der Daten fallen Kosten an: Google bietet verschiedene Preismodelle an, die vor allem im Vergleich zur Unternehmensversion sehr preisgünstig sind. Die Daten selbst werden für 0,02$ pro GB pro Monat gespeichert und können für 5$ pro TB im EU- oder US-Raum analysiert werden. Auf der BigQuery-Preisseite sind alle Einzelheiten zu finden. Es gibt auch eine kostenlose Stufen-Nutzung von 10 GB Speicher und 1 TB Abfragen pro Monat.  

  

Wie man Daten mit BigQuery verbindet     

Wenn man die Vorteile der Verwendung von BigQuery betrachtet, bleibt die Frage, wie die Verknüpfung hergestellt werden kann. Glücklicherweise macht es Google sehr einfach, Google Analytics 4 mit BigQuery zu verbinden.  

1. Erstelle eine Google Analytics 4-Property und füge alle relevanten iOS App-, Android App- oder Website-Streams hinzu

 

2. Gehe zu deinen Admin-Einstellungen und klicke auf “BigQuery Verknüpfung” 

Wenn noch keine Verbindung besteht, wird dieses Fenster leer sein und man kann auf „Verknüpfen“ klicken, um eine Verbindung herzustellen. 

 

3. Erstelle eine Verbindung mit BigQuery 

Als erstes muss das BigQuery-Projekt ausgewählt werden. Wenn bereits eines erstellt wurde, kann es aus der Liste ausgewählt werden, die sich nach einem Klick auf „BigQuery Project auswählen“ öffnet. 

Wenn nicht, wird eine leere Liste gezeigt und es muss noch ein BigQuery Project angelegt werden 

Ein Cloud Project erstellen (Du kannst diesen Teil überspringen, wenn bereits ein Projekt existiert, das verwendet werden soll) 

Gehe zu https://console.cloud.google.com und erstelle ein neues oder wähle ein existierendes Projekt ausFür dieses Tutorial werden wir ein neues Projekt erstellen. 

Wähle einen Projektnamen, eine Organisation und klicke auf Erstellen“.

Nach der Erstellung muss das soeben erstellte Projekt ausgewählt sein.   

In der linken Navigation ist „APIs & Services“ zu finden. Hier muss der Punkt „Bibliothek“ auswählt werden. 

Hier musst du nach der BigQuery-API suchen und die BigQuery-API auswählen, um zu überprüfen, ob diese API aktiviert ist. Es ist automatisch der Sandbox-Modus aktiviert, der ohne Kosten verwendet werden kann. Zu beachten sind hier die zusätzlichen Limits.

Wenn dies geprüft ist, können wir zu Google Analytics 4 zurückkehren. 

 

4. Verbindung zum Cloud Project herstellen 

Klicke noch einmal auf “BigQuery Project auswählen, wähle das Projektwelches gerade angelegt wurde, und klicke auf “Bestätigen”. 


Wähle deine Location und klicke “Weiter”. 

Hier ist es möglich, das Datenzentrum auszuwählen, in dem die BigQuery-Daten gespeichert werden sollen. Wir empfehlen die Nutzung der EU-Region, da Google hier die niedrigsten Preise verlangt. Wenn die Daten nur in der Europäischen Union gespeichert werden, kann die Nutzung dieses Rechenzentrums auch helfen, die europäischen Datenschutzbestimmungen einzuhalten

 

5. Data Streams und regelmäßige Exporte auswählen 

Es können alle oder nur einige Datenströme ausgewählt werden, um Daten an BigQuery zu streamen. Ein Anwendungsfall  für wenige Datenströme könnte sein, einen dedizierten Datenstrom für eine Testumgebung zu haben, dessen Daten nicht an BigQuery gesendet werden sollen. 

Im nächsten Schritt kann ausgewählt werden, wie oft die Daten an BigQuery exportiert werden sollen. „Täglich“ exportiert die Daten einmal am Tag und ist im aktuell genutzten Sandbox-Modus enthalten. „Streaming“ ermöglicht den Zugriff auf Daten in BQ nahezu in Echtzeit, aber das Streaming ist mit einem Preis von 0,01$ pro 200MB gestreamte Daten verbunden. 

Nach Auswahl der gewünschten Frequenz wird dieser Schritt mit Klick auf Weiter abgeschlossen. 

 

6. Überprüfen und Übermitteln der Verknüpfung 

Als letzten Schritt muss nur noch die Verbindung überprüft und abgeschickt werden. Wenn die Erstellung erfolgreich war, sollte eine Erfolgsmeldung „Verknüpfung erstellt“ zu sehen sein. 

7. Zurück zu BigQuery 

Nach einem Tag (da wir nur den täglichen Export gewählt haben) sind die Daten in BigQuery angekommen und wir können uns das neue Schema ansehen. 

 

Das neue Datenmodell in BigQuery  

Wie zu Beginn dieses Artikels erwähnt, hat Google das Datenmodell von einem auf Sessions“ fokussierten Modell auf ein eventbasiertes Modell geändert. Diese Anpassung ist auch in BigQuery sichtbar. Während bei Universal Analytics jede Zeile eine Sitzung war, stellt GA4 ein Ereignis in jeder Zeile dar.  

Jeder Treffer enthält eine Kennung pro Benutzer (Feld: „user_pseudo_id„), die ID der Sitzung (Feld : „ga_session_id„) und auch die Sitzungsnummer (Feld : „ga_session_number„). Somit sind trotz den Änderungen weiterhin alle sitzungsbasierten Analysen möglich.   

 Abbildung 3 GA4 – ein Event je Zeile 

 

Schlussfolgerung  

Durch die Bereitstellung einer nativen BigQuery-Verbindung, ohne dass hierfür eine 360-Lizenz nötig ist, eröffnet Google viele spannende Möglichkeiten für Analyse-Anwendungsfälle.  Da wir nicht an alle GA4-Limits gebunden sind, jederzeit über ungesampelte Daten verfügen und die Cloud-Infrastruktur mit all den leistungsstarken Tools nutzen können, die auch noch zu einem kleinen Preis angeboten werden, gibt es viele Gründe, sich für diese Option zu entscheiden.  

Für die Nutzer:innen ist dies ein klarer Fortschritt in Bezug auf Flexibilität und Datennutzung. Gleichzeitig schafft es Google, zahlende Google Analytics Kund:innen zu gewinnen, auch wenn diese nicht zu einer kostenpflichtigen Lizenz wechseln würden.  

Um die neu gewonnenen Rohdaten optimal nutzen zu können, spielt die Qualität der Datengrundlage eine entscheidende Rolle.  

Hierzu empfehlen wir zusätzlich unseren letzten Beitrag darüber, wie die duale Strategie für eine reibungslose Umstellung auf die neue GA4-Lösung in deinem Unternehmen genutzt werden kann.

  

Wie kann FELD M unterstützen?  

Als eine auf Analysen spezialisierte Agentur sind wir Expert:innen im Umgang mit Google Analytics (und anderen Webanalyse-Tools). Durch unser Tagesgeschäft mit unseren Kund:innen und der Analytics-Szene sind wir immer auf dem Laufenden, was es Neues bei GA4 gibt. In einer langfristigen Doppelstrategie, d.h. dem Übergang von GA Universal Analytics zu GA4, können wir helfen, die neuen Verbindungen herzustellen, ein verbessertes Tracking zu entwerfen und mehr Erkenntnisse aus den Daten zu gewinnen.    

Mehr über unsere Digital Analytics Services erfahren Sie hier: https://www.feld-m.de/service/digital-analytics/ 

 

(c) Image by GraphicsSC from Pixabay

Mit Google Analytics 4 (GA4) (ehemals App+Web property) bringt Google ein komplett neues Tracking Tool auf den Markt. Damit wird erstmals in der Geschichte von Google Analytics ein harter Schnitt in den Daten vollzogen, denn historische Daten können nicht zu GA4 übernommen werden. Auch das Datenmodell wurde überarbeitet. Nach 15 Jahren GA mit eher inkrementellen Updates nun also einmal alles neu. Aber was bedeutet das für dein Unternehmen? Und wie lässt sich ein solches Upgrade durchführen, wenn Google Analytics bereits tief in die Unternehmensstrukturen integriert ist?

In unserem Beitrag schauen wir uns genauer an, welche strategischen Vorteile es bringt, jetzt eine neue GA4 Property einzurichten und parallel zur bisherigen Voll-Implementierung mit GA Universal Analytics Daten zu erfassen.

Technisch betrachtet ist das neue GA4 mit dem alten GA Universal Analytics (GA UA) kaum noch zu vergleichen: das grundlegende Konzept wurde von Google komplett überarbeitet. Die größte Herausforderung für Unternehmen dürfte sein, dass die Daten durch das neue Datenschema nicht historisch übernommen werden können. Mit GA4 fängt man also wieder bei 0 an Daten zu sammeln. Das macht so einfache Anforderungen wie Year-over-Year-Vergleiche schwierig.

Auch die Umstellung selbst kann schwierig und langwierig sein, wenn das alte Google Analytics tief in die Unternehmensstrukturen eingebunden ist. Wenn externe Systeme durch BigQuery, CSV-Exporte und –Importe oder die Reporting API angebunden sind, erfordert der Wechsel auf GA4 viel technischen Aufwand.

Die Dual-Strategie

Sowohl Google, als auch wir empfehlen für die meisten unserer Kund*innen eine Dual-Strategie. Dabei werden beide Systeme gleichzeitig genutzt. Dieses Setup kann realistisch für 2-3 Jahre oder auch länger bestehen bleiben.

Außerdem ist es so, dass der aktuelle Stand von GA4 nicht für alle Unternehmen ausreichend ist. Einige gewohnte Features aus GA UA mögen noch fehlen. So wurden z.B. erst kurzfristig überhaupt eCommerce-Berichte in GA4 eingeführt.

Die Dual-Strategie hilft Unternehmen dabei, das Beste aus beiden Welten zu bekommen: die gewohnten Reports aus GA UA sowie die neuen Features von GA4.

Die 3 Vorteile einer Dual-Strategie sind:

  1. Anbindungen an externe Systeme können ausreichend geplant und sauber überführt werden
  2. Eine Datenhistorie kann in GA4 aufgebaut werden, sodass Vergleiche mit vergangenen Zeiträumen möglich werden (z.B. YoY-Vergleich)
  3. Google hat Zeit, weitere Features für GA4 zu veröffentlichen, denn aktuell gibt es durchaus noch Verbesserungspotenzial

1. Anbindung externer Systeme

Die unterschiedlichen Möglichkeiten, Daten aus GA zu exportieren und auch zu importieren, bieten hervorragende Ansätze, externe Systeme einzubinden. Sei es ein Attributionsreporting in Tableau, Datastudio Dashboards basierend auf BigQuery oder Kostenuploads für Marketingkampagnen.

Mit dem neuen GA4 müssen die Anbindungen an externe Systeme angepasst werden.

Zwar gibt es in GA4 einen integrierten Export zu BigQuery (und dieses Mal kostenlos), das Datenschema hat sich jedoch geändert. Auch die bekannte Reporting API funktioniert nicht mehr. Die neue GA4 Data API ist aktuell noch im closed-Beta Status.

Beide Systeme gleichzeitig für einen längeren Zeitraum laufen zu haben, unterstützt bei der Anpassung der externen Systeme, schont Entwickler*innen-Ressourcen und hält das Kerngeschäft am Laufen.

2. Datenhistorie

Lange aufgezeichnete historischen Daten nicht mehr nutzen zu können, stellt ein datengetriebenes Unternehmen vor Herausforderungen. Jahresvergleiche sind nicht mehr möglich. Langfristige Trendanalysen kaum machbar. Harte Brüche in den Daten kommen aber immer mal wieder vor, nicht nur bei einem Toolwechsel. Zum Beispiel kann auch ein Website Relaunch einen starken Bruch in den Daten verursachen, was dazu führt, dass langfristige Vergleiche nicht mehr aussagekräftig sind.

Um dem vorzubeugen, hilft die Dual-Strategie, indem zumindest grundlegenden Informationen bereits in GA4 erfasst werden. Hierbei gilt: Je früher desto besser, damit so viele Daten wie möglich historisch aufgezeichnet werden können.

3. Weitere Features und Releases von GA4

GA4 ist von Google bereits als „production-ready“ eingestuft worden. Damit ist eine gewisse garantierte Verfügbarkeit gegeben. Unternehmen können bereits unbesorgt umsteigen.

Dennoch arbeitet Google weiterhin an neuen Features. Es kann sich also noch einiges ändern. Meistens ist das auch gut so. Google fokussiert die Entwickler*innen-Ressourcen auf GA4 und es ist in den kommenden Monaten mit weiteren Features und Verbesserungen zu rechnen. In GA UA ist daher allerdings nicht mehr mit Updates zu rechnen.

Was sollten Unternehmen jetzt tun?

Webanalyst*innen sollten spätestens jetzt anfangen, sich mit GA4 zu beschäftigen. Idealerweise kann der GA4 Tracker bereits in die eigene Website (ggf. ein Unterbereich) eingebaut werden, um Daten für die Reports zu sammeln. An GA Universal Analytics wird sich nichts mehr ändern. Der Fokus muss jetzt auf GA4 liegen.

Wie kann FELD M unterstützen?

Als auf Analytics spezialisierte Agentur sind wir Expert*innen im Umgang mit Google Analytics (und anderen Webanalyse Tools). Durch unser Tagesgeschäft mit unseren Kund*innen sowie der Analytics-Szene sind wir immer up-to-date, was es gerade Neues bei GA4 gibt. Bei einer langfristig ausgelegten Dual-Strategie, bzw. dem Übergang von GA Universal Analytics zu GA4, können wir helfen, die neuen Anbindungen zu entwickeln, ein verbessertes Tracking zu konzipieren und mehr Insights aus den Daten zu gewinnen.

Mehr zu unseren Leistungen im Bereich Digital Analytics finden Sie hier: https://www.feld-m.de/service/digital-analytics/

 

 

(c) Image by GraphicsSC from Pixabay