Tealium Tag-Management und die DSGVO

Wenn man ein Tag-Management-System [TMS] wie Tealium einsetzt, ist es in heutigen Zeiten unausweichlich, sich mit der DSGVO und den Datenschutzbestimmungen auseinanderzusetzen. Offensichtlich personenbezogene Kundendaten dürfen nur erhoben werden, wenn deren Verarbeitung für den Einsatzzweck notwendig ist und der Kunde explizit sein Einverständnis dazu gegeben hat. Aber auch bei allgemeineren Kundendaten, z.B. jenen, die typischerweise beim Besuch einer Webseite für die Webanalyse gesammelt werden, sollte die Kundenzustimmung eingeholt werden. Die Meinungen über die strikte Notwendigkeit bei letzterem gehen zwar auseinander, aber sicher ist sicher.

Verwaltet man nun die Tags seiner Webpräsenz mit einem TMS, kommt man nicht umhin, den Besuchern die Möglichkeit zu geben, sich mit der Verwendung der Tags einverstanden zu erklären (oder auch nicht) und ihnen ggf. bei verschiedenen Tags sogar individuelle Wahlmöglichkeiten anzubieten.

In diesem Artikel beleuchten wir nun, welche Werkzeuge Tealium IQ dafür bereithält. Dabei ist diese Steuerung natürlich primär für die in Tealium selbst konfigurierten Tags gedacht. Alle ursprünglichen Lösungen sind in Tealium als sogenannte Extensions verfügbar. Das sind in gewisser Weise Module, die aus einer Art Baukasten ausgewählt, konfiguriert und aktiviert werden können. Das neuste Privacy-Tool in Tealiums Portfolio, das Consent Management, ist dagegen ein zentraler Konfigurationsbaustein.

Abb. 1: Tealium Privacy Extensions

 

Do Not Track Extension

Mit Hilfe dieser Extension kann Tealium den „Do Not Track“-Status des Kundenbrowsers auslesen. Alle modernen Browser unterstützen seit einigen Jahren diese standardisierte Schnittstelle, in der der Benutzer seinen Wunsch nicht getrackt zu werden hinterlegen kann. Der Nachteil ist, dass der Browser außer dem Merken und Bekanntgeben der Benutzervorliebe keine weiteren Anstalten macht, technisch dahingehend etwas zu unternehmen. Die Webseitenbetreiber und Anbieter der Tracking-Tools auf der anderen Seite sind nicht an diese Konfiguration gebunden und können sie genauso gut auch ignorieren, was im Normalfall sogar Stand der Dinge ist.

Die Do Not Track Extension veranlasst Tealium, den „Do Not Track“-Status des Kundenbrowsers zu beachten und alle Aktivitäten einzustellen. Die Einrichtung ist dabei gleichermaßen simpel wie starr. Es gibt lediglich die Möglichkeit des Ein- oder Ausschaltens. Ist die Extension aktiv, unterdrückt sie alle weiteren Tealium-Aktivitäten, sofern der benutzte Browser Do Not Track aktiviert hat. Feinere Abstufungen oder gar individuelle Konfigurationen der einzelnen Tags sind nicht möglich.

Außer dem fairen Verhalten und guten Willen dient diese Extension keinem weiteren Zweck. Sie erfüllt auch keine rechtlichen Anforderungen im Sinne der DSGVO.

 

Tracking Opt-Out Extension

Die Tracking-Opt-Out-Extension ist fast keine Extension im eigentlichen Sinne. Wird sie aktiviert, stellt sie lediglich zwei Javascript-Links zur Verfügung, die beim Ausführen den Opt-Out-Status an oder ausschalten. Die Einstellung wird in einem Cookie gespeichert und ist nur solange wirksam, wie das Cookie nicht gelöscht wird. Bei aktiviertem Opt-Out unterdrückt sie jegliche Tealium-Aktivität. Die Darstellung der beiden Links liegt völlig in der Hand des Betreibers und wird von dieser Extension nicht weiter unterstützt.

Verpackt in einen rechtskonformen Kundenhinweis mit Auswahlmöglichkeit kann diese Extension zwar die Anforderungen der DSGVO erfüllen, allerdings bietet sie auch nur das komplette Ab- und Einschalten der Tealium-Aktivitäten, was die Möglichkeiten einschränkt. Dadurch wird dem Kunden keine Chance gelassen, bestimmte Tags zu nutzen und dennoch andere abzulehnen. Dem Betreiber entgehen dadurch Daten, deren Erhebung viele Kunden bei feinerer Wahlmöglichkeit womöglich doch zugestimmt hätten.

 

Privacy Manager Extension

Die Privacy-Manager-Extension war der erste Entwurf von Tealium, der einem Besucher eine feiner abgestufte Auswahlmöglichkeit bot. Diese Extension ist schon seit einigen Jahren verfügbar. Sie verfolgt ein gutes Konzept, ist aber konfigurationstechnisch leider nicht zu Ende gedacht und daher zu starr um wirklich sinnvoll eingesetzt werden zu können.

Die Privacy-Manager-Extension zeigt dem Besucher ein Popup an, das alle verwendeten Tags auflistet und mit einem An-/Aus-Schalter versieht. Hier kann der Besucher zum Beispiel ein Hilfe-Chat-Tool aktivieren, die personalisierte Werbung aber abschalten. Da es sich um viele einzelne konfigurierte Tags handeln kann und deren Namen einem Laien meist nicht wirklich etwas sagen, bietet die Extension noch die Möglichkeit, Kategorien anstatt einzelner Tags anzuzeigen (siehe Abb. 2). Die Zuweisung der Tags in die Kategorien kann bei der Konfiguration vorgenommen werden. Weitere Kategorien können hinzugefügt werden. Ebenso lassen sich einzelne Tags ausklammern, die immer, unabhängig von der Besucherauswahl, ausgeführt werden. Zu guter Letzt wählt man noch eine Opt-In- oder Opt-Out-Strategie. Also ob zu Beginn alles deaktiviert oder aktiviert ist. Auch diese Benutzerauswahl wird in einem Cookie gespeichert und würde mit dem Löschen der Cookies wieder verschwinden.

Abb. 2: Privacy Manager Extension

Damit endet allerdings auch schon die Liste der Konfigurationsmöglichkeiten. Anpassungen, die auf den zweiten Blick essentiell erscheinen, können nicht – oder nur mit „Hacks“ – erreicht werden. Hier ein paar Beispiele.

  • Designänderung / Corporate Design:
    Der vorgegebene Popup-Code verwendet ein paar Klassennamen, über welche CSS-Anpassungen in begrenztem Rahmen möglich sind. Das Logo oben rechts kann ebenfalls getauscht oder entfernt werden. Etwaige grundlegende Umgestaltungen sind nicht möglich.

 

  • Beschriftungen und Textänderungen:
    Vorgesehen sind solche Anpassungen nicht. Über das manipulieren des Code-Templates können einige Felder zumindest geändert werden. Tag-Namen, die in der internen Konfiguration womöglich anders heißen sollen, als bei der Besucheransprache, können aber nicht geändert werden.

 

  • Einzelne Tags vs. Tag-Typen:
    Habe ich bisher von einzelnen Tags gesprochen, stimmt das leider nicht ganz, was sehr frustrierend werden kann. Verwendet man zum Beispiel zwei verschiedene Google Analytics Tags, die beide auf dem gleichen Vendor-Tag basieren, kann in der Konfiguration nur „Google Analytics“ gesteuert werden, nicht aber beide Tags unterschiedlich. Gerade bei dem viel verwendeten Vendor „Tealium Custom Container“ stößt man hier schon schnell an seine Grenzen.

 

  • Sprachunterstützung:
    In der Privacy-Manager-Extension ist nur eine Sprache vorgesehen und das ist Englisch. Eine Multisprachunterstützung fehlt hier völlig.

 

 

Consent Management (Consent Prompt Manager & Consent Preferences Dialog)

Seit Mai 2018 ist das neuste Mitglied der Privacy-Tools in Tealium verfügbar. Das Consent Management kommt nicht mehr als Extension daher, sondern ist tief im System verankert und lässt sich über den „My IQ“-Reiter konfigurieren. Hier hat Tealium einen wirklich guten Ansatz verfolgt. Bei allen vorherigen Extensions ließ sich eine gute Portion negativer Kritik heraushören, die der Autor auch durch nicht zufriedenstellende eigene Erfahrungen angesammelt hat.
Das Consent Management [CM] ist dagegen hochgradig anpassbar und den eigenen Vorstellungen nach formbar. Ich würde jedem empfehlen, direkt das CM einzusetzen und die Extensions beiseitezulassen.

Das CM besteht aus zwei Komponenten, dem Consent Prompt und dem Consent Preference Dialog. Der Consent Prompt ist für das Overlay gedacht, welches den Besucher um die generelle Zustimmung bittet. Darin kann auch ein Button platziert werden, der zum Consent Preference Dialog führt. Letzterer stellt dann – analog zur Privacy Manager Extension – eine Auswahlmöglichkeit einzelner Tags oder Kategorien zur Verfügung.

Abb 3: Consent Management mit Consent Prompt und Consent Preference Dialog

Die Ressourcen, wie Namen und Texte für Erklärungen, werden in den Konfigurationsmasken des CM hinterlegt. Die Konfiguration des Overlays und Dialogs kann mittels HTML, CSS und Javascript praktisch allen Wünschen und Anforderungen nach erstellt werden, wobei die Inhalte aus den Resourcen-Konfigurationen über {{Platzhalter}} zugreifbar sind. Eine ganze Reihe von API-Funktionen ermöglicht dann die gezielte Steuerung der Abläufe im Javscript, wie z.B. Abrufen und Speicherung von Auswahlen, Triggern des Overlays oder Dialogs. Auch hier wird die Benutzerauswahl in einem Cookie gespeichert und würde mit dem Löschen der Cookies wieder verschwinden.

Mit bloßem Zusammenklicken ist eine solche Flexibilität natürlich nicht erreichbar. Gesundes Wissen über HTML, CSS und Javascript ist schon eine Voraussetzung. Meiner Meinung nach hat Tealium hier aber die richtige Balance zwischen Einfachheit und Möglichkeiten der Konfiguration getroffen.

Abb 4: Konfiguration von Design und Funktionalität mittels HTML, CSS und Javascript

Auch an die Multisprachunterstützung hat Tealium beim CM gedacht. Alle Ressourcen-Masken können für unzählige Sprachen als parallele Konfigurationssätze eingefügt werden, die dann automatisch, je nach Sprachauswahl, aufgerufen werden. Die Übersetzung und Befüllung der Elemente muss selbstverständlich vom Betreiber selbst kommen.

Das Auslesen der Benutzerauswahlen und das daraus hervorgehende selektive Blockieren der abgewählten Tags geschieht dann automatisch, unabhängig von den herkömmlichen Laderegeln.

Schon nach dem ersten Consent-Manager-Projekt, was e-dynamics für Kunden umgesetzt hat, habe ich die Philosophie und den Ansatz des CM lieben gelernt. Dennoch hat auch das CM noch ein paar Kinderkrankheiten, die Tealium hoffentlich in der nächsten Zeit beheben wird:

  • Es gibt 15 vorgegebene Kategorien, die für die Zuordnung der Tags genutzt werden können. Bisher gibt es keine Möglichkeit eigene oder weitere Kategorien zu erstellen. Es ist durchaus möglich, in den Ressourcen die vorgegeben Kategorien umzubenennen, sodass den Besuchern die gewünschten Namen in allen Sprachen angezeigt werden. Intern aber arbeitet die Konfiguration mit den originalen Namen. Das ist umständlich, schränkt aber die Benutzung nicht ein, solange man nicht mindestens 16 Kategorien benötigt.

 

  • Die Zuordnung einzelner Tags in Kategorien ist hier etwas flexibler als es noch bei der Privacy-Manager-Extension der Fall war. „Tealium Generic Tags“ und „Tealium Custom Container“ erscheinen jetzt als einzelne Tags für die Zuweisung in die Kategorien. [Generic Tags erst seit meinem Bug-Report an Tealium, den sie recht schnell gefixt haben.]
    Vorgefertigte Vendor-Tags, wie das obige Beispiel mit dem Google Analytics dagegen, betrachtet die Konfiguration weiterhin als ein Tag. Das ist ärgerlich, sollte man die beiden Tags in unterschiedliche Kategorien einsortieren wollen. Es kann aber dadurch umgangen werden, dass weitere Tags als eigene Custom-Container-Tags erstellt werden.

 

  • Die Spracherkennung funktioniert automatisch über die Spracheinstellungen des Browsers. Zwar muss man hier nichts weiter konfigurieren, hat aber auch (noch) nicht die Möglichkeit, explizit manuell selbst eine Sprachauswahl vorzugeben. Auf einer Webpräsenz mit unterschiedlichen Sprachen kann das störende Nebenwirkungen haben. Wechselt der sprachbegabte Kunde mit einem deutschen Browser die angezeigte Sprache auf Französisch, dann sieht er trotzdem auf der französischen Seite weiterhin die deutschen Dialoge des CM. Die manuelle Steuerung liegt Tealium aber als Feature-Request vor und wird bald nachgezogen.

Sobald diese Macken behoben sind, ist das Content Management in Tealium ein sehr gut funktionierendes Privacy-Tool. Aber auch jetzt ist es das Tool der Wahl, um DSGVO-konforme Nutzungshinweise und Zustimmungsabfragen auf den eigenen Webpräsenzen einzurichten.

BigQuery - Eigenschaften und Fähigkeiten - Teil 2

Falls ihr vorab noch grundlegende Informationen über BigQuery und damit die perfekte Vorbereitung für den folgenden Artikel sucht, empfehlen wir euch:

BigQuery – Eigenschaften und Fähigkeiten – Teil 1

“BigQuery & Google Analytics – Starter Pack”

Wo fängt man an, wenn es darum geht, Google Analytics Daten mit Hilfe von BigQuery auszuwerten? Und vor allem, wie funktioniert das Ganze? Nachfolgend findet ihr ein kleines Starter Pack und die wichtigsten Punkte, um loszulegen.

 

A. Eine Verknüpfung zwischen Google Analytics & BigQuery muss her

Google Analytics lässt sich einfach mit BigQuery verknüpfen.

Im Adminbereich von Google Analytics ist die Product Linking Option “BigQuery” relativ schnell gefunden – doch Obacht! Es gibt noch ein paar weitere Dinge, die beachtet werden sollten, damit der Export einwandfrei funktioniert. Google liefert hier eine Schritt-für-Schritt Anleitung, die die Verknüpfung kinderleicht macht.

https://support.google.com/analytics/answer/3416092

 

B. Es ist wichtig zu wissen, wie Google Analytics Daten in BigQuery gespeichert werden

 

1. Welche Daten werden gespeichert?

Die Wahl liegt bei euch – es kann jeweils ein Google Analytics View pro Property mit BigQuery verknüpft werden. Wir empfehlen, den View zu verknüpfen, der auch für das Google Analytics Reporting genutzt wird. Sprich: verknüpft besser nicht den Rohdaten View, den ihr womöglich als Backup in GA erstellt habt, sondern nutzt den View, in dem die Bots & Co. bereits gefiltert wurden. Das hat den positiven Effekt, dass ihr mit BigQuery und Google Analytics die gleichen Zahlen reporten werdet. Die Rohdaten würden ansonsten Datenunterschiede und/oder einen immensen Filterauswand in BQ mit sich bringen.

 

Nachdem ein View für den Export ausgewählt wurde, werden die Google Analytics Daten täglich in einer jeweils neuen Datentabelle gespeichert.

Die Benennung der Tabellen erfolgt dabei immer nach Schema F: “ga_sessions_YYYMMDD”. (Beispiel: “ga_sessions20170801”)

 

Doch wie sehen diese Daten dann tatsächlich aus? Und wie kann ich sie abfragen?

 

2. Wie sieht das Exportschema aus?

Glücklicherweise hat Google uns hier eine Doku bereitgestellt.

Das Exportschema umfasst die Struktur und Erklärungen der Spalten & Felder, in denen die Google Analytics Daten gespeichert werden und sollte ab jetzt euer neuer stetiger Begleiter sein, wenn es um Google Analytics Daten in BigQuery geht.

 

3. Gibt es Beispieldaten?

Ja, mit dem Google Analytics Sample Dataset liefert Google ein Beispiel Dataset aus dem Google Merchandising Store. Mit Hilfe dieses Samples kann sich der User zum einen vorab einen guten Überblick davon verschaffen, wie die Daten grundsätzlich einlaufen werden, zum anderen bildet es eine perfekte Spielwiese, um sich mit BigQuery, den Google Analytics Daten und im speziellen mit den SQL Dialekten vertraut zu machen.

 

4. Wie sieht die Tabellenstruktur aus?

Anders als bei einer relationalen Datenbank sind die Google Analytics Daten ‘genested’, d.h. eine Zeile kann wiederum mehrere Zeilen beinhalten, die wiederum mehrere Zeilen enthalten können. Diese Besonderheit in Kombination mit den Google Analytics spezifischen Dimensionen und Metriken bedarf etwas Übung.

 

Um das Ganze etwas haptischer darzustellen, hier ein Vergleich zwischen einer relationalen Datenbank und der genesteten Struktur in BigQuery.

https://lh5.googleusercontent.com/3ZM1gNpcHSHKJJBdAmbrzxJoL3dPgAc117JkWeHnqWehxAab6J-EyglnVkIJ6cpyb0pgfNpIvF0442k3kZ-6JCIstP6t1hKYyV6sSbylj1PgrCgRgRnz9dJzs6E9Ri3LX0T-qlTi

Abb. 1: Relationale Datenbank

 

https://lh4.googleusercontent.com/xFKrKBY4U-35ZJqU3BFLMA1jMr8mIJEhSp7TS2LcHWC8y4_jwMqEcKDrQa3dhuF_ziidtFs6GzS7vN4PRyTet2RbU4tV3Gijl-E55s_aTIYodDdRywg-98ZsiGFHfNWOWidSNIa9

Abb. 2: Nested Structure

 

In Bezug auf die Google Analytics Daten sieht die Struktur in etwa so aus:

https://lh5.googleusercontent.com/8wKkAA-X9OnbePRIV_m3d9leqwuWk1imme5gBmim1JcUDaLxUzcdingda7sx7z5zpbE6f1IlB4ekwiyfLDHvN_kWhz8c9YvbUGLIhCaJfBv0oDfJeNL65ouWNv-_pEvjR4e168li

Abb. 3: Nested Structure in Bezug auf Google Analytics Daten

 

Eine Zeile der Datentabelle entspricht jeweils einer Session. Die Aktionen innerhalb der Session (z.B. Pageviews oder Events) werden wiederum in Nestern innerhalb der Session abgebildet, die weitere Nester enthalten können (z.B. Produktdetails, der auf der Seite abgebildeten Produkte).

 

Eine Preview mit allen Spalten findet sich übrigens auch im Google Analytics Sample Dataset:

https://lh3.googleusercontent.com/26ANBGMz_sJ1IU8wKHfeMamlD6jiY2r0mJEvy6oYXXtQSbWvFxnE48GDoisI0jWY4LclGGSItKwmA84nt4_G2lorIGtTSz38RPQeGCCY8-YvdL5m4UpLdnIrHMXAEDcfiT22BOKc

Abb. 4: Preview aus Google Analytics Sample Dataset

Quelle: https://bigquery.cloud.google.com/table/bigquery-public-data:google_analytics_sample.ga_sessions_20170801?pli=1&tab=preview

 

C. Queries – Und wie frage ich diese nested Daten ab?

Die Google Analytics Daten können sowohl mit einem von Google entwickelten SQL Dialekt (Legacy SQL Reference) als auch mit Standard SQL (Standard SQL Dialekt) abgefragt werden. In Bezug auf die Nested Structure bietet Legacy SQL zwar teils eine einfachere Handhabe, allerdings ist Standard SQL breiter aufgestellt und ermöglicht zusätzliche Optionen, wie zum Beispiel Custom Functions.  

 

Der einfachste Weg mit einer Query loszulegen, ist

 

  1. das Öffnen des Google Analytics Sample Datasets  und
  2. der Klick auf “Query Table” oben rechts im Fenster nachdem ihr euer Dataset durch anklicken aufgerufen habt.

https://lh4.googleusercontent.com/1lL18HO_xX8FYpv6pSZO30_K_Saa_o_ScA_nRNQUWg8QZqp-H4HeJIr7Tww-WszilXfBELM1QLW_pHf6r_j1UJYxdU3nav-1sM6n5WiGNmjdJ0afPF5xz8Jk90XClvu_z05Va57d

Abb. 5: Öffnen des Google Analytics Sample Datasets

 

Sofort öffnet sich ein Abfragefenster, in dem das Wichtigste schon vordefiniert ist. Durch einen Klick auf “Format Query” wird die Abfrage direkt in das typische SQL Format umgewandelt:

https://lh6.googleusercontent.com/6hJf6Wfpi66y7f0IsupQX5shhUxEN50WaL0LSjefhFDSEDbpu5Q0GzZWo1lY4o6I5bI1nFQJ3GAjnw74lc3jOwppO6fLx2fYlZdDsnU3pbgBQwSWol7mX2qr51iJKNFtt7AWijZc

Abb. 6: Abfragefenster

Quelle: https://bigquery.cloud.google.com/table/bigquery-public-data:google_analytics_sample.ga_sessions_20170801?pli=1&tab=preview

 

 

Jetzt kann es losgehen.

 

Aber Achtung: solltet ihr dem Beispiel oben gefolgt sein, befindet ihr euch gerade in einer Legacy SQL Abfrage. Das lässt sich zum Beispiel an den eckigen Klammern der Datenquelle [bigquery-public… 20170801] erkennen.

 

Solltet ihr Standard SQL nutzen wollen, müsste zu Beginn der Abfrage ein #standardsql eingefügt und die Syntax etwas angepasst werden:

https://lh4.googleusercontent.com/SNC3qo22Yy2CmI96H1D3cPK-LNdwOVl__kHV1nsSyZJRy4QWwaBaaArFmaOuK0A3iPv9NFhzil4f6QZA38YL2Bmdwqy6-q8bl_37Qx8RYyhGwxvAq-y9ot8fogU-eqV8YQtM7kky

Abb. 7: Abfragefenster #standardsql

Quelle: https://bigquery.cloud.google.com/table/bigquery-public-data:google_analytics_sample.ga_sessions_20170801?pli=1&tab=preview

 

Wem das allerdings auf Dauer zu viel Aufwand ist, der kann sich auch einfach eins der verfügbaren AddOns herunterladen, welches den Wechsel von Standard zu Legacy oder andersherum von selbst erledigt und zudem praktischerweise auch noch anzeigt, welches Budget man da gerade auf den Kopf haut.

Ein Beispiel ist das Add On superQuery, mit dem sich die Visualisierung dann folgendermaßen ändert:

https://lh5.googleusercontent.com/-CFqnybE4CaoG-orqxtqPObFnijj_4Tgqiewnlo3ffQXQ14BZxIeJX-TZjM16jCm5yuc3EcA8534P5XYktc1xGxwMNa4TOGN3YYc7uAP-3RvheJ0Bgx6cb9hYP8j3wFZmj3nZJ4U

Abb. 7: Add On superQuery

Quelle: https://bigquery.cloud.google.com/table/bigquery-public-data:google_analytics_sample.ga_sessions_20170801?pli=1&tab=preview

 

Jetzt kann es aber wirklich losgehen!

 

Um sich etwas mit der Syntax & der Datenstruktur vertraut zu machen, ein paar Beispiele für einfache Abfragen in BigQuery in Standard SQL:

 

FRAGE: Wie viele Sessions hatte der Google Merchandise Shop pro Tag am 01.08.2018?

 

SELECT

  date,

  SUM(totals.visits) AS Sessions

FROM

  `bigquery-public-data.google_analytics_sample.ga_sessions_20170801`

GROUP BY

  date

Wird beispielsweise eine ganze Woche als Zeitrahmen benötigt, könnte die Abfrage folgendermaßen angepasst werden:

 

SELECT

  date,

  SUM(totals.visits) AS Sessions

FROM

  `bigquery-public-data.google_analytics_sample.ga_sessions_*` 

WHERE

  _TABLE_SUFFIX BETWEEN '20170726'

  AND '20170801'

GROUP BY

  date

 

Sollten mehr Metriken als nur die Sessions benötigt werden, kann die Abfrage beliebig erweitert werden:

 

SELECT

  date,

  COUNT(DISTINCT(fullVisitorId)) AS Users,

  SUM(totals.newVisits) AS NewUsers,

  SUM(totals.visits) AS Sessions,

  SUM(totals.transactions) AS Transactions,

  ROUND(SUM(totals.transactions)/SUM(totals.visits)*100,2) AS SessionConversionRate,

  ROUND((SUM(totals.totalTransactionRevenue)/POW(10,6))/SUM(totals.transactions),2) AS AverageOrderValue

FROM

  `bigquery-public-data.google_analytics_sample.ga_sessions_20170615`

GROUP BY

  date

 

Ein Beispiel für eine Abfrage, in der ein Datennest abgefragt werden muss, ist die Frage nach seitenbezogenen Metriken. Würden wir uns beispielsweise pro Seite ausgeben lassen wollen, wie viele Users, Sessions, Pageviews und Entrances es gab, könnte der nachfolgende Code verwendet werden.

Mit UNNEST(hits) ‘öffnen’ wir sozusagen das Nest, um es für die Abfrage verfügbar zu machen.

 

SELECT

  hits.page.pagePath,

  COUNT(DISTINCT(fullVisitorId)) AS Users,

  COUNT(DISTINCT(CONCAT(fullVisitorId, CAST(visitId AS STRING)))) AS Sessions,

  COUNT(hits.page.pagePath)AS Pageviews,

  COUNT(hits.isEntrance) AS Entrances

FROM

  `bigquery-public-data.google_analytics_sample.ga_sessions_20170801` AS t,

   UNNEST(hits) as hits

WHERE

  hits.type = 'PAGE'

GROUP BY

  1

ORDER BY

  2 DESC

Doch das ist nur der Anfang – mit BigQuery eröffnen sich ganz neue Analysemöglichkeiten, die dem Analysten im Interface bislang verwehrt bleiben.

Beispiele hierfür sind komplexe Kohortenanalysen, Deepdives zu User Engagement, Cross-Device-Verhalten, detaillierte User Journeys, uvm.

 

Aber auch im Kleinen bringt BigQuery Vorteile mit sich, mit Hilfe derer sich die ein oder andere Limitation des Google Analytics Interfaces überwinden lässt:

 

    1. Scopes in Google Analytics → nicht jede Dimension lässt sich mit jeder Metrik kombinieren. Mit Hilfe von BigQuery lässt sich dieses Problem an vielen Stellen umgehen. Die Analysemöglichkeiten werden flexibler.
    2. Anzahl der Dimensionen & Metriken: Im interface ist die Anzahl der angezeigten Dimensionen & Metriken begrenzt. Mit BigQuery lassen sich beliebig viele Dimensionen und Metriken miteinander kombinieren.
    3. Filter: die Filteroptionen in Google Analytics könnten flexibler sein. In BigQuery ist die Filternutzung deutlich individueller – dem Filtern sind hier (fast) keine Grenzen gesetzt.
    4. Einblick in Sessionverläufe / User Journeys: ein großer Vorteil ist zudem die Verfügbarkeit von Visit IDs und User IDs. Das Interface bietet nur limitierten Einblick in den Verlauf von Sessions & User Journeys. Mit BigQuery lässt sich beides jedoch detailliert ausgeben und auswerten.
    5. Cross-Device: Im Interface wird strikt zwischen Cross-Device & clientbasiertem View getrennt. Wenn allerdings eine UserId nach erfolgreichem Login übergeben wird, können in BigQuery beide Ansichten miteinander verknüpft werden, d.h. sobald eine LoginId verfügbar ist, wird der User deviceübergreifend betrachtet, liegt keine ID vor, greift die ursprüngliche clientbasierte User Definition.

 

Ein Zugewinn ist zudem die Möglichkeit, zusätzliche Datenquellen mit den Google Analytics Daten über BigQuery verknüpfen zu können. So lassen sich beispielsweise Daten weiterer Marketingtools oder auch Daten des DWH miteinander kombinieren und auswerten. Diese Verknüpfung ermöglicht ein übergreifendes Reporting, das mithilfe eines Visualisierungstools problemlos erstellt werden kann.

 

Aus unserer Sicht ist BigQuery in Kombination mit Google Analytics eine sinnvolle zusätzliche Erweiterung, die zum einen Limitationen des Interface umgehen, aber auch neuen Möglichkeiten der Analyse eröffnen und Reportings standardisieren kann.

Durch das schnelle Aufsetzen der Verknüpfung und den im Verhältnis zu anderen Datenbanklösungen geringen Kosten, ist BigQuery ein Must Have für alle Google Analytics 360 Kunden, die tiefer in das Thema Analytics und Reporting einsteigen wollen.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Clusteranalyse - Verfahren um Daten besser zu verstehen

Teil 2: Beispiele für Verfahren zur Klassifikation von Daten

 

Im ersten Teil dieses Artikels haben wir schon einiges über das statistische Verfahren der Clusteranalyse berichtet. Nun werden wir an den schon vorgestellten Beispieldaten zwei Algorithmen testen, welche beide das Ziel haben große Datenmengen in verhältnismäßiger Zeit zu klassifizieren. Dabei werden wir sehen, dass die Ergebnisse dabei sehr unterschiedlich ausfallen können.

 

Der k-Means Algorithmus

Abbildung 2: Plot k-Means Algorithmus

 

Dieser Algorithmus basiert darauf, dass zuvor eine feste Anzahl k von Klassen festgelegt werden muss und sich jede Klasse über ihren Schwerpunkt bzw. Mittelwert (engl. Mean) von den anderen unterschiedet. Vor der Analyse sollte also die Anzahl der vorliegenden Klassen bekannt sein. Im ersten Schritt werden zufällig k Objekte als Startwerte ausgewählt. Diese repräsentieren zunächst die k Klassen. Die restlichen Objekte werden derjenigen Klasse zugeordnet, zu dessen Startpunkt sie die größte Ähnlichkeit vorweisen. Nach erfolgreicher Zuteilung aller Objekte, werden pro Klasse die Schwerpunkte berechnet. Vergleichbar ist diese Berechnung mit der einfachen Mittelwertbildung über alle Objekte in einem Cluster. Mit den neuen Schwerpunkten als Startwerte beginnt der k-Means Algorithmus erneut. Das wird so lange wiederholt, bis kein Objekt mehr in einem Durchlauf einer anderen Klasse zugeordnet wird wie im Durchlauf zuvor. Die finale Einteilung ist dann das Ergebnis der Clusteranalyse.

 

Leider ist dieses Verfahren sehr von den initialen Startwerten abhängig (siehe Abb. 2). Die Anwendung auf den Beispieldatensatz zeigt ein zwar mathematisch völlig korrektes, jedoch auch nicht optimales Ergebnis. Zwei der vorliegenden Cluster wurden beinahe richtig erkannt (rot und schwarz). Die grüne Klasse umfasst zwei der fünf Anhäufungen, weshalb die letzte Blase in die beiden blauen Cluster geteilt wurde. Hätte das Verfahren mit anderen Startwerten begonnen, hätten alle Cluster wie erwartet zugeordnet werden können oder aber es wäre ein weiteres falsch interpretierbares Ergebnis herausgekommen.

 

Verhindern lässt sich dieses Phänomen dadurch, den gesamten Algorithmus mehrmals hintereinander auszuführen und mit Hilfe einer Gütefunktion das „beste“ Ergebnis zu bestimmen. In den meisten Fällen wird dann die natürliche Struktur innerhalb der Datenmenge richtig erkannt. Jede weitere Ausführung des Algorithmus verlängert jedoch die Laufzeit erheblich.

 

Der BIRCH Algorithmus

Abbildung 3: Plot BIRCH Algorithmus

 

Der BIRCH-Algorithmus besteht grundsätzlich aus zwei Schritten. Zunächst werden die Daten mit Hilfe einer Baumstruktur „vorklassifiziert“. In unserem Beispiel werden die 1 Mio. Objekte schon zu etwa nur noch 2000 Gruppen von Klassen zusammengefasst. Aufgrund der Reduzierung des Umfangs kann dann eine klassische Clusteranalyse auf die Daten angewendet werden. Diese Verfahren beruhen darauf, dass am Anfang jedes Objekt eine eigene Klasse darstellt. In jedem Schritt werden dann die zwei Klassen zusammengefügt, welche die größte Ähnlichkeit zueinander aufweisen und das Ergebnis wird zwischengespeichert, solange bis die nur noch eine allumfassende Klasse vorhanden ist. Der Algorithmus wählt dann das Ergebnis aus, das die Ähnlichkeit innerhalb eines Clusters und Unterschiede zwischen den Clustern am besten beschreibt.

Im Gegensatz zum k-Means wird also auch die Anzahl an vorhandenen Klassen selbstständig erkannt und das Endergebnis entspricht in den meisten Fällen der tatsächlich vorliegenden Struktur (siehe Abb. 3). Die bessere Genauigkeit dieser clusteranalytischen Verfahren wird jedoch aus einer sehr viel höheren Komplexität gewonnen. Im Klartext heißt dies, um brauchbare Ergebnisse mit BIRCH zu erzielen, sind sehr viel mehr statistische Kenntnisse nötig, um die maximale Effizienz aus dem Verfahren herauszuholen.

 

Fazit

 

Die Clusteranalyse kann in vielen Fällen helfen sich einen Überblick über große Datenmenge zu verschaffen. Besonders im Big Data Bereich ist dies nötig, um so Ausreißer zu identifizieren oder die Daten zu segmentieren. Die beiden vorgestellten Verfahren bieten dabei zusammengefasst folgende Vor- und Nachteile:

 

k-Means

Vorteile:
  • Einfach anzuwenden
  • Von vielen Statistik Programmen standardmäßig implementiert
  • Liefert in vielen Fällen ein brauchbares Ergebnis
NachteilE:
  • Klassenanzahl muss vorher bekannt sein
  • Ergebnis kann, abhängig von den Startwerten, eine andere Struktur als die natürliche Struktur wiedergeben
  • Erhöhte Genauigkeit erfordert sehr viel mehr Laufzeit

 

BIRCH

Vorteile:
  • In den meisten Fällen wird die natürliche Struktur erkannt
  • Variable Einstellung, um auf unterschiedliche Datenbeschaffungen einzugehen
  • Sehr schnelle Laufzeit, auch bei großen Datenmengen
  • Klassenanzahl wird selbstständig erkannt
Nachteile:
  • Verfahren nicht weit verbreitet in gängigen Statistikprogrammen
  • Hohes Maß an statistischen Wissen nötig
  • Durch die Vorklassifizierung geht Information verloren

 

Neben den beiden vorgestellten Algorithmen gibt es natürlich noch eine Vielzahl weiterer Methoden, die sich mit der gleichen Fragestellung befassen und die je nach Fall bessere und schlechtere Ergebnisse liefern können. Jedoch haben wir die Erfahrung gemacht, dass bereits diese beiden Verfahren ausreichen, um aus großen Datenmengen tiefgehende Erkenntnisse zu ziehen. Aus unserer Sicht ist die Clusteranalyse ein verhältnismäßig einfaches Verfahren, das statistisch verlässliche Insights liefert und damit ein fester Bestandteil im Repertoire eines Analysten sein sollte.  

 

 

 

 

 

 

 

Clusteranalyse - Verfahren um Daten besser zu verstehen

Teil 1: Was ist eine Clusteranalyse – Ein kleiner Einblick

Die Arbeit mit Datenmengen ist im Bereich Digital Analytics nicht wegzudenken. Neben dem Erfassen, Aufbereiten und Reporten sind auch vor allem spezifische Analysen der Daten ein wichtiger Bestandteil dieser Arbeit. Heute wollen wir ein ganz bestimmtes statistisches Verfahren vorstellen, die Clusteranalyse.

Das Ziel einer Clusteranalyse liegt darin, in einer Datenmenge Ähnlichkeiten und/oder Unterschiede festzustellen und auf dieser Grundlage die Objekte in Klassen (bzw. Cluster) einzuteilen. Dabei können die Verfahren die Datenmenge in eine vorher vorgegebene Anzahl von Klassen unterteilen oder auch komplett selbstständig Klassen identifizieren. Die in den Daten vorliegende Klasseneinteilung, welche von der Analyse erkannt werden soll, wird dabei natürliche Struktur genannt.

Zunächst klingt es nicht nach einer Herausforderung, aber gerade bei sehr großen Datenmengen oder bei Daten mit mehr als drei Merkmalen ist mit dem bloßen Auge das Auffinden von natürlichen Strukturen nicht mehr möglich. Insbesondere Daten im dreidimensionalen Raum können schlicht und einfach leicht erfasst werden und benötigen eine besondere Visualisierung.

 

Was bringt eine Klassifikation von Daten?

 Durch die Analyse sollen Hypothesen, welche im Voraus auf Grundlagen der Datenmenge getroffen wurden, mathematisch gestützt oder verworfen werden. Mit Hilfe der gefundenen Klassen können dann neue Aussagen über die Verteilung der Datenobjekte gemacht oder Vermutungen bestätigt werden. Oft erbringen Analysen auf den bereits klassifizierten Daten tiefere Erkenntnisse, als wenn sie auf der gesamten Datenmenge durchgeführt worden wären.

An einem Beispiel aus dem Alltag wird der Nutzen klarer. Stehen wir morgens vor dem Kleiderschrank können wir uns meisten mit wenig Handgriffen ein in den meisten Fällen tragbares Outfit zusammenstellen. Dies ist aber nur möglich, wenn wir unsere Klamotten vorher nach bestimmten Kategorien sortiert haben. Viele Menschen versuchen dabei zum Beispiel Hosen, Pullover, Socken etc. auf einem Stapel anzuordnen. Andere gehen sogar soweit die Kleider nach Farbe oder Jahreszeit zu ordnen. Je größer die Anzahl an Kleidungstücken dabei ist, umso mehr Sinn macht dabei eine feinere Sortierung. Denn die wenigstens haben wahrscheinlich Lust jeden Morgen aus einem riesigen Haufen Klamotten ein Paar passender Socken zu suchen.

Es gibt jedoch auch Sortierungen, welche weniger sinnvoll sind, beispielweise nach Gewicht und Preis. Ebenso gibt es bei Clusteranalysen mehr und weniger erkenntnisreiche Ergebnisse.

Dieses Prinzip lässt sich leicht auch auf technische Fälle anwenden. Angenommen es existiert eine Webseite, welche Waren aus verschiedenen Kategorien zum Verkauf anbietet. Interessant wäre es zu wissen, ob Besucher der Seite aufgrund ihres Verhaltens in verschiedene Käufer-Typen eingeordnet werden können. Typische Fragen wären hierbei, welches Verhalten bei Besuchern eher zu einem Kaufabschluss oder im Vergleich zu einem höheren Umsatz führt. Oder aber, ob bestimmte Produkte bevorzugt im Einkaufswagen landen, bevor es zu einem Kaufabschluss kommt. Diese Fragestellungen könnten durch eine Clusteranalyse z.B. auf Basis der Seitenaufrufe in den einzelnen Produktkategorien und des Umsatzes pro Kunde beantwortet werden.

 

Wie funktioniert die Mathematik dahinter?

Mathematisch werden zwei Bedingungen bei der Clusteranalyse an die entstehenden Klassen gestellt. Zum einen sollen Objekte aus gleichen Klassen untereinander ähnlich sein und andererseits sollen Objekte aus verschiedenen Clustern unähnlich zueinander sein. Dies hört sich zunächst trivial an, benötigt jedoch eine genaue mathematische Definition. Nach einer erfolgreichen Clusteranalyse sollte idealerweise jede gefundene Gruppe ganz bestimmte Strukturen aufweisen, sodass ein Cluster durch seine Eigenschaften oder eventuell durch die Wahl eines Repräsentanten direkt Aufschluss über seine enthaltenen Objekte gibt und eine mögliche Interpretation zulässt. Klassen mit wenigen Objekten können hierbei meist als Ausreißer-Klasse identifiziert werden. In jedem Fall sollte die Analyse eine leichter überschaubare und übersichtlichere Struktur vorweisen.

Es gibt verschiedene statistische Herangehensweisen für eine Klassifizierung der Daten. Die Auswahl des Verfahrens hängt dabei von der Beschaffenheit der Daten und in hohem Maße von dem Ziel, welches erreicht werden soll, ab. Die verschiedenen Verfahren unterscheiden sich primär durch den mathematischen Algorithmus, welcher zur Analyse verwendet wird. Es existieren auch verschiedenste Möglichkeiten die Ähnlichkeit bzw. Unähnlichkeit von zwei Objekten bzw. zwei Klassen zu beschreiben. Ein erfahrener Analyst hat in vielen Fällen sofort ein Gespür dafür, welche Berechnungen sich für die vorliegenden Beobachtungen besonders eignen. Vor der Auswahl ist aber eine genaue Voruntersuchung und eventuelle Aufbereitung der Daten unbedingt notwendig. Andernfalls können Ergebnisse entstehen, die gar keine oder eine falsche Interpretation zulassen.

 

Die Herausforderung „Big Data“

Typischerweise sind die Datenmengen, die in digitalen Bereichen (z.B. Website Tracking, App Tracking, etc.) erhoben werden, sehr groß. Daher sind eine schnelle Rechenlaufzeit und sparsame Speicherverwaltung grundlegende Anforderungen an jedes statistische Verfahren. Viele klassische clusteranalytische Verfahren, welche zwar gut darin sind Klassenstrukturen aufzudecken, scheiden daher schon von vornherein aus. Die Durchführung solcher Verfahren würde bei Umfängen, wie sie im Big Data Bereich vorkommen, meist mehrere Tage oder Wochen beanspruchen. Wir wollen daher zwei spezielle Verfahren vorstellen. Zum einen den verbreiteten k-Means Algorithmus und zum anderen den weniger bekannteren BIRCH Algorithmus. Hierbei werden wir ein kleines Stückchen tiefer in die Mathematik hinter den Algorithmen steigen, um die Unterschiede und Vor- und Nachteile herauszuarbeiten. Mit Hilfe dieser beiden Verfahren, können bereits viele Erkenntnisse über die natürliche Struktur innerhalb der Daten gewonnen werden.

Als Beispieldatensatz betrachten wir fiktiven Daten mit 1 Mio. Objekten, die je drei Merkmale aufweisen (siehe Abb. 1). Wir können die Daten also in einem dreidimensionalen Koordinatensystem visualisieren.

 

Abbildung 1: Plot fiktiver Datensatz

In diesem Beispiel kann die natürliche Struktur der Daten durch bloßes Hinsehen erkannt werden. Die Objekte lassen sich in fünf verschiedene „Anhäufungen“ oder „Blasen“ einteilen. Trotzdem ist nicht bekannt welches einzelne Objekt im Datensatz welcher der fünf Klassen zugeordnet werden kann. Bei 1 Mio. Objekten ist die händische Zuteilung auch schon nicht mehr in verhältnismäßiger Zeit möglich. Daher werden wir die Zuteilung über die Algorithmen vornehmen. In der Realität ist jedoch die Trennung zwischen den Klassen meist wesentlich weniger eindeutig.

Im zweiten Teil dieses Artikels werden wir die zwei Verfahren vorstellen, welche das Problem mit unterschiedlichen Herangehensweisen lösen. Dabei werden wir sehen, dass je nach Beschaffenheit der Daten, beide Verfahren mal besser und mal schlechter Ergebnisse liefern und im schlimmsten Fall kann auch eine völlig ungeeignete Klassifizierung berechnet werden kann.

Die Fortsetzung finden Sie hier: https://www.e-dynamics.de/blog/clusteranalyse-teil2.html.

Verwaltung von Werbekampagnen mit OME

Wie messe ich den Erfolg meiner Kampagnen?

Als Marketing Abteilung eines Unternehmens mit Internetauftritt arbeitet man häufig mit vielen Marketing Agenturen, Dienstleistern und weiteren Toolanbietern zusammen. Man fährt online Kampagnen, schaltet Werbung, verschickt e-Mails und druckt Flyer mit Barcode. Das kostet in der Regel Zeit und Geld. Doch wie messe ich den Erfolg der verschiedenen Kampagnen, Werbungen und Investitionen? Wie behalte ich den Überblick bei den vielen Accounts? Es wird zum Beispiel mit Google AdWords gearbeitet, auf der Website selbst sind Marketing Pixel einer Agentur implementiert und einen Newsletter gibt es auch.

 

Open Media Exchange (OME) – das Tool

Es ist kein Geheimnis, dass man an die URL des Unternehmens leicht einen Code anhängen kann, um zu verfolgen, woher der Besucher gerade kommt. Einen URL-Parameter. Jedes größere Analytics Tool kann anhand dieses Codes bewerten, wie gut die Quelle oder das Medium ist, über das der Kunde gekommen ist.

Die Pflege dahinter kann aber aufwändig sein. An dieser Stelle wird das e-dynamics Tool Open Media Exchange (OME) eingesetzt. Es verfügt über Schnittstellen zu den verschiedensten Tools. Dazu gehören AdWords, BingAds und viele mehr. Diese Schnittstellen werden regelmäßig abgefragt und die Kampagnen mit allen gewünschten Informationen in das Tool übernommen. Der Nutzer kann auch manuell Kampagnen für den internen Gebrauch anlegen oder einer Agentur Zugriff geben. Diese kann, bei größeren Mengen an Kampagnen, Excel-Dateien über das Webinterface hochladen, um Kampagnen zu erstellen oder zu pflegen.

Beim Erstellen der Kampagne gibt OME eine URL mit einem URL-Parameter zurück, der in der Kampagne benutzt werden sollte. Diese wird anhand der einzelnen Kampagnenparameter erstellt oder einfach hochgezählt. Das kann der Benutzer des Tools frei entscheiden. Für die Google Suite wird hier das Standard Kampagnentracking gewählt. Statt viele Parameter an die URL anzuhängen, reicht es also, einen einzigen hinzuzufügen. Die Zuordnung von URL-Paramtern zur Kampagnendaten übernimmt OME automatisch.

 

Graphik 1&2: Anlegen einer neuen Kampagne in OME

 

Der Prozess von der Kampagnenerstellung bis hin zur Erfolgsmessung im Analytics-Tool ist so vollständig automatisiert und weniger fehleranfällig. Zusätzlich gibt es eine einzelne Quelle mit allen im Unternehmen erstellten Online Kampagnen. Ein echter Mehrwert bei der Organisation und Qualität des Kampagnen Trackings.

 

OME in der Anwendung

Ein einfaches Anwendungsbeispiel könnte folgendermaßen aussehen:

Das Tool müsste mit wenigen Eingaben gefüttert werden:

Das Ergebnis der Ziel-URL kann in diesem Fall zum Beispiel so aussehen: https://www.e-dynamics.de/?cid=DSGVO_NEW_INT oder https://www.e-dynamics.de/?cid=12

Auf diese Weise generiert das Tool einen standardisierten URL-Paramter für das Analytics Tool. OME überträgt die Daten, wie Kampagnen Eigenschaften und den dazugehörigen URL-Parameter an das genutzte Analytics Tool. Dies geschieht in der Regel automatisiert per FTP Upload einer Classification Datei und wird für Webtrekk und Adobe bereits unterstützt.

Somit können wunderbar Auswertungen über einzelne Kampagnen und deren Eigenschaften erstellt werden, ohne selbst URL’s zu basteln und im Analytics Tool zu pflegen.

Darüberhinaus können viele Agenturen und Mitarbeiter gleichzeitig daran arbeiten. Lästige Excellisten werden auf diese Weise erfolgreich abgelöst.

 

Haben Sie Interesse am e-dynamics Tool Open Media Exchange (OME)?

Dann einfach unser Kontaktformular ausfüllen und wir melden uns dann direkt.

 

BigQuery - Eigenschaften und Fähigkeiten -Teil 1

  • Was ist BigQuery
  • Was kostet BigQuery?
  • Wie benutzt man es?
  • Wer braucht es? Und wofür?

Datenbank mal anders – eine BigQuery Starthilfe

BigQuery ist in aller Munde und wir wollen euch nachfolgend mit den wichtigsten Infos ausstatten, die ihr braucht, um mit BigQuery loszulegen. Was ist es? Wie benutzt man es? Und vor allem wie teuer ist es und wer braucht es eigentlich? Hier findet ihr alle Infos, die ihr braucht.

Was ist BigQuery?

BigQuery ist eine cloudbasierte Datenbank aus dem Hause Google, in der man verschiedenste Datensätze speichern, verknüpfen, aufrufen und abfragen kann. Dabei ist die Datenbank aufgrund verschiedenster Logiken & Entwicklungen seitens Google sehr performant – selbst größere Datenmengen können binnen Sekunden abgefragt und prozessiert werden. An dieser Stelle wollen wir uns jedoch nicht allzu sehr in technischen Details verlieren, sondern einem anderen großen Vorteil von Google BigQuery Tribut zollen. Denn jeder mit einem Google Account und etwas SQL Kenntnissen kann das Tool nutzen. Im Gegensatz zu anderen Datenbanken werden keine Ressourcen benötigt, um das System zu verwalten oder die Rechenressourcen zu dimensionieren. Ganz im Gegenteil: Über bigquery.cloud.google.com kann BigQuery von jedem Ort mit einer Internetverbindung aufgerufen werden. Die Frage, wie das Tool von wem mit welcher Absicht bedient wird, liegt natürlich in unserer Hand – um alles andere kümmert sich Google.

Wie teuer ist es?

Den Vorteil der nicht nötigen Datenbankverwaltung und -skalierung lässt Google sich natürlich bezahlen – hier halten sich die Kosten allerdings in Grenzen.

Um sich anfangs mit dem Tool auseinander setzen zu können, bietet Google einen Testaccount mit großzügigen Konditionen an. Mit einer Laufzeit von 12 Monaten und einem freien Budget von 300$ lassen sich einige Terabytes an Daten abfragen und speichern.

Zudem ist der Account nicht nur auf BigQuery limitiert, sondern umfasst auch andere Google Cloud Platform Produkte.

 

Sollte dieser Freibetrag tatsächlich irgendwann aufgebraucht oder das Jahr vergangen sein, greifen folgende Preise:

 

Speicherung von Daten:

0,02$ pro GB pro Monat (die ersten 10 GB im Monat sind kostenlos)

 

Abfragen von Daten:

5$ pro 1 TB (das erste TB ist pro Monat kostenlos)

 

Dabei ist es wichtig zu wissen, dass nur erfolgreiche Abfragen berechnet werden. Sollte die Abfrage einen Fehler auswerfen, berechnet Google keinen Cent.

 

Alles in allem heißt das, dass sich die Kosten bei kleineren Datenmengen in einem überschaubaren Rahmen bewegen und keinesfalls im Verhältnis dazu stehen, was ausgegeben werden müsste, um die gleiche Qualität mit einer eigenen Datenbank zu bewerkstelligen. Für Firmen mit größerem Datenvolumen bietet Google zudem Pauschalpreise an.

Details zu den Preisen: https://cloud.google.com/bigquery/pricing

 

Hinzu kommt, dass es mehrere Sicherheitsmechanismen gibt, die verhindern, dass ein bestimmtes Budget überschritten wird.

Details: https://cloud.google.com/bigquery/docs/custom-quotas

 

Wie benutzt man es?

BigQuery enthält ein integriertes Abfragemodul, in dem die Abfragen direkt gestellt und die Daten entsprechend ausgegeben werden können.

 

Abfragen werden in SQL verfasst.

Quelle: https://bigquery.cloud.google.com/table/bigquery-public-data:google_analytics_sample.ga_sessions_20170801?pli=1

 

In Bezug auf die SQL Nutzung innerhalb von BigQuery gibt es allerdings einen wichtigen Unterschied.

Es existiert sowohl der ältere “Legacy SQL” Dialekt, der eine Google spezifische Adaption des normalen SQL ist, als auch der im Juni 2016 eingeführte “Standard SQL” Dialekt.

 

Beide Dialekte sind aktiv und können verwendet werden. Bisher hat Google keine Anzeichen von sich gegeben, das teils sehr beliebte Legacy SQL abzuschaffen.

Wer braucht BigQuery? Und wofür?

Fälschlicherweise wird BigQuery oft nur im Zusammenhang mit Google Analytics gesehen.

Häufig wird es als eine Art Feature von Google Analytics 360 verstanden – damit tut man dem Tool allerdings unrecht.

BigQuery ist eine eigenständige Datenbank, die zwar mit der sehr einfach umzusetzenden Verbindung zu Google Analytics einen großen Vorteil in der Analyse der Google Analytics Daten mit sich bringt, doch zusätzlich noch eine Menge weiterer Vorteile vorweisen kann.

 

Der Data Lake ist in aller Munde – BigQuery ist hier eine mögliche Alternative mehrere Datenquellen zusammengeführen und sie zentral zu speichern.

Verschiedene Datensätze können entsprechend im Tool gespeichert und über einfache JOIN Abfragen miteinander verknüpft werden. Wie man es von Google gewohnt ist, ist die Verknüpfung mit hauseigenen Programmen sehr einfach gestaltet – beispielsweise wird ein Data Transfer Service für AdWords, DoubleClick oder auch YouTube angeboten.

Ein großer Vorteil ist zudem, dass Datensätze, die im Google Cloud Storage, in Cloud BigTable oder auch in Google Drive gespeichert wurden, abgefragt werden können, ohne, dass diese dupliziert und als weiterer Datensatz innerhalb von BigQuery abgelegt werden müssen.  

 

Die Ergebnistabelle kann dann wiederum als Basis für ein Reporting dienen, das mehrere Datenquellen darstellt. Alle gängigen Visualisierungstool verfügen mittlerweile über eine vordefinierte Schnittstelle zu BigQuery, über die die Daten kinderleicht und ohne Programmierkenntnisse ihren Weg in das entsprechende Tool finden.

 

Wer sollte BigQuery nutzen?

Alle, die möglichst heute noch in das Datenbankthema einsteigen, aber kein großes Budget in die Hand nehmen wollen, um eine eigene Datenbank aufzubauen, sind bei BigQuery richtig aufgehoben.

Durch die einfache und sehr performante Bedienung lässt sich der Fokus auf die Abfrage, Verknüpfung und Analyse der Daten richten.

 

Vorteile bietet das Tool auch als zusätzliche Datenbank, um vorhandene Datenquellen wie zum Beispiel Google Analytics, Adwords & Co. zu verknüpfen oder mit anderen Daten aus dem Data Warehouse anzureichern. Durch den Vorteil, dass es – bis auf die sehr geringen Kosten der Speicherung – keine laufenden Kosten gibt, eignet sich das Tool sehr gut als Zweit-Datenbank.

 

Für alle Google Analytics 360 Nutzer bietet BigQuery zudem den Vorteil, dass Limitationen, die im Interface vorhanden sind, umgangen und größere Mengen an Daten abgefragt und verarbeitet werden können.

 

Insgesamt hat Google mit BigQuery eine sehr performante Alternative zu anderen Datenbanken geschaffen, bei der die Einstiegsschwelle sehr niedrig und die Kosten verhältnismäßig gering sind. Sowohl für Datenbankanfänger als auch für Fortgeschrittene bietet BigQuery das richtige Setup und kann mit der Anbindung zu zahlreichen anderen Produkten ein Einstieg in die Welt der Google Cloud sein.

 

Die Fortsetzung von diesem Artikel findet ihr hier:

BigQuery – Eigenschaften und Fähigkeiten – Teil 2