Data Blending in Looker Studio: Joins, Metriken und die Fallen dazwischen

Data Blending ist die Funktion in Looker Studio, vormals Data Studio, die mehrere Datenquellen in einem Diagramm zusammenführt. Sie ist zugleich die Funktion, die die selbstbewusstesten Falschzahlen erzeugt, denn ein Blend scheitert lautlos: Der Bericht wird gerendert, die Summen wirken plausibel, und nichts deutet darauf hin, dass ein Wert dreifach gezählt wurde oder dass zwei deduplizierte Zählungen addiert wurden, als wären es Mengen.

Der Grund ist, dass ein Blend sich nicht wie ein Verweis in einer Tabellenkalkulation verhält. Die Reihenfolge seiner Arbeitsschritte erklärt fast jedes merkwürdige Ergebnis – deshalb beginnt es dort.

Was ein Blend tatsächlich tut

Ein Blend führt zwei Operationen aus, in dieser Reihenfolge: Jede Tabelle wird zuerst über ihre eigenen Dimensionen aggregiert, und die aggregierten Ergebnisse werden anschließend über den konfigurierten Schlüssel verbunden. Beide Hälften dieses Satzes zählen. Die Aggregation geschieht vor dem Join, also bestimmen die für eine Tabelle gewählten Dimensionen, wie viele Zeilen diese Tabelle in den Join einbringt – und der Join gleicht diese Zeilen danach Zeile für Zeile gegen die andere Tabelle ab.

Deshalb ist ein Blend kein Nachschlagen, und deshalb ist die Wahl der Dimensionen nicht kosmetisch. Eine Dimension zu einer Tabelle hinzuzufügen ergänzt nicht einfach eine Spalte; es verändert die Anzahl der Zeilen, die diese Tabelle beisteuert, und damit das Ergebnis des Joins.

Die fünf Join-Typen

Looker Studio bietet den Standardsatz, und die Wahl entscheidet, welche Zeilen überleben, wenn ein Schlüssel nur auf einer Seite existiert:

• Left Outer – jede Zeile der linken Tabelle plus passende Zeilen der rechten. Unpassende Zeilen rechts entfallen. Die Voreinstellung, und der Grund, warum ein Tag, an dem nur die zweite Quelle Aktivität hatte, aus einem Bericht verschwinden kann.
• Right Outer – das Spiegelbild; selten der klarste Ausdruck einer Absicht, da das Umsortieren der Tabellen samt Left Join meist besser lesbar ist.
• Inner – nur Schlüssel, die in beiden Tabellen vorkommen. Nützlich, wenn eine Zeile nur dann Bedeutung hat, wenn beide Quellen Daten liefern, und gefährlich, wenn das nicht wirklich zutrifft.
• Full Outer – jede Zeile beider Seiten, wo möglich zugeordnet. Die sicherste Wahl, wenn Vollständigkeit wichtiger ist als Kompaktheit, um den Preis null-lastiger Zeilen, die berechnete Felder auffangen müssen.
• Cross – jede Zeile mit jeder Zeile kombiniert. Legitim zum Bau eines Gerüsts, etwa einer Datumsliste mit einer Kanalliste, und verheerend, wenn versehentlich gewählt.

Eine praktische Regel: Lautet die Frage „wie haben sich diese beiden Dinge im selben Zeitraum entwickelt“, schützt Full Outer auf dem Datum vor stillschweigend verlorenen Tagen. Lautet die Frage „was ist mit den Datensätzen passiert, die in beiden Systemen existieren“, ist Inner die ehrliche Wahl – und die Zahl der dabei entfernten Zeilen ist selbst berichtenswert.

Wo Join-Schlüssel ohne Warnung brechen

Ein Join-Schlüssel muss exakt übereinstimmen, und die meisten Fehlschläge stammen von Werten, die für einen Menschen identisch aussehen und es für die Maschine nicht sind.

Die Datumsgranularität ist der häufigste Fall: Liefert eine Quelle einen Zeitstempel und die andere ein Datum, passt nie etwas zusammen – und die Lösung besteht darin, in jeder Quelle ein reines Datumsfeld bereitzustellen, statt darauf zu hoffen, dass der Blend das ausgleicht. Groß-/Kleinschreibung und Leerzeichen folgen: Newsletter, newsletter und newsletter  sind drei verschiedene Schlüssel. Das Normalisieren mit LOWER() und TRIM() gehört als berechnetes Feld in die Datenquelle, denn ein dort erzeugtes Feld steht als Join-Schlüssel zur Verfügung – der Blend-Editor ist nicht der Ort, Eingangsdaten zu reparieren. Währungs- und Locale-Formatierung erzeugen dieselbe Fehlerklasse bei numerischen oder Identifikator-Schlüsseln.

Eine weitere Einschränkung ist struktureller Natur: Schlüssel mit sehr hoher Kardinalität, etwa eine Transaktions-ID, machen Blends langsam – und ein Blend, der in den Zeitüberlauf läuft, ist ein leeres Diagramm und keine Fehlermeldung.

Dimensionen entscheiden, was eine Zeile bedeutet

Der teuerste Einzelfehler besteht darin, in einer Tabelle eine Dimension stehen zu lassen, die die andere nicht hat. Ist Tabelle A nach Datum aggregiert und Tabelle B nach Datum und Kampagne, trifft der Join-Schlüssel Datum eine Zeile aus A auf drei Zeilen aus B, und die Metrik aus A wiederholt sich dreifach. Die Summe ist dann exakt dreimal zu groß – und weiterhin eine runde, plausibel aussehende Zahl.

Zwei Gewohnheiten verhindern das. Die erste: die Granularität des Blends festlegen, bevor irgendein Feld gewählt wird, und jede Tabelle genau auf diese Granularität aggregieren – liegt der Blend auf Tagesebene, führt keine Tabelle die Kampagne mit. Die zweite ist eine Diagnose: Record Count aus jeder Tabelle in eine vorübergehende Tabellenansicht aufzunehmen zeigt sofort, ob ein Schlüssel mehr Zeilen trifft als erwartet, denn ein sauberer Eins-zu-eins-Join liefert je Zeile und Tabelle einen Record Count von eins.

Wird die Kampagnenebene wirklich gebraucht, gehört sie in einen zweiten, auf dieser Granularität gebauten Blend und nicht in denselben. Ein einzelner Blend für zwei Granularitäten ist die Anforderung, die sich nicht erfüllen lässt.

Metriknamen und Summen über mehrere Properties

Dieselbe Metrik aus mehreren Properties zusammenzuführen – etwa Gesamtnutzer aus drei regionalen GA4-Properties – trifft auf ein Verhalten, das leicht für einen Rechenfehler gehalten wird.

Jede Tabelle in einem Blend behält die Feldnamen ihrer Quelle. Steuern drei Tabellen je ein Feld namens Total users bei, gelangen drei gleichnamige Felder in den Blend, und ein berechnetes Feld, das als Addition dieses Namens geschrieben ist, hat keine eindeutige Möglichkeit, sich an das richtige zu binden. Heraus kommt eine Zahl, die ohne Fehlermeldung entsteht und nicht die beabsichtigte Summe ist.

Die Lösung besteht darin, jede Metrik im Blend-Editor umzubenennen, bevor überhaupt ein berechnetes Feld geschrieben wird. Ausdrückliche, unterscheidbare Namen – users_de, users_at, users_ch – machen den Bezug eindeutig, und die Addition verhält sich dann wie erwartet:

-- Erst verlaesslich, wenn jede Quellmetrik einen eindeutigen Namen traegt
users_de + users_at + users_ch

Im selben Durchgang zu prüfen: die für jede Metrik im Blend eingestellte Aggregation. Ein Feld mit automatischer Aggregation kann sich anders verhalten als eines, das ausdrücklich auf SUM steht – und da beide anstandslos rendern, ist die ausdrückliche Einstellung vorzuziehen.

Metriken, die sich gar nicht summieren lassen

Das Umbenennen bringt die Addition mechanisch zum Laufen. Ob die Addition etwas bedeutet, ist eine zweite Frage – und für zwei Kategorien von Metriken lautet die Antwort Nein.

Deduplizierte Zählungen – Nutzer, aktive Nutzer, jede Distinct-Zählung – sind nicht additiv. Wer zwei der drei Properties besucht, ist eine Person; die drei Zählungen addiert melden zwei. Dasselbe gilt über die Zeit: Tageswerte für Nutzer über einen Monat aufzusummieren ergibt nicht die Monatsnutzer. Keine Blend-Konfiguration behebt das, denn die zum Deduplizieren nötige Information steckt in den aggregierten Werten nicht mehr drin. Wird eine echte Property-übergreifende Nutzerzahl gebraucht, muss die Deduplizierung vor Looker Studio stattfinden – praktisch also auf den Rohdaten in einem Warehouse.

Raten und Durchschnitte – CTR, Conversion Rate, Absprungrate, durchschnittlicher Bestellwert – müssen nach dem Blend neu berechnet statt kombiniert werden. Der Durchschnitt zweier Conversion Rates ist nicht die Conversion Rate der zusammengefassten Daten, es sei denn, beide Seiten haben zufällig identische Nenner. Die richtige Form summiert die Bestandteile und teilt zum Schluss:

-- Falsch: zwei Raten mitteln
(conv_rate_a + conv_rate_b) / 2

-- Richtig: aus den summierten Bestandteilen neu berechnen
(conversions_a + conversions_b) / (sessions_a + sessions_b)

Weitere Techniken, die sich lohnen

• Eine Kalendertabelle als Anker. Beide Quellen gegen eine kleine Tabelle mit jedem Datum des Zeitraums zu blenden, mit Left Joins von dort nach außen, stellt sicher, dass kein Tag verschwindet, weil eine Quelle keine Aktivität hatte.
• Blends schmal halten. Ein Blend fragt seine Quellen erneut ab, jedes ungenutzte Feld kostet also Ladezeit. Nur die Felder auszuwählen, die ein Diagramm braucht, ist ebenso eine Performance- wie eine Ordnungsentscheidung.
• Die Tabellenreihenfolge ist nicht kosmetisch. Die erste Tabelle ist die linke Seite jedes Left Joins – und damit die Tabelle, deren Vollständigkeit der Bericht erbt.
• Die Grenze von fünf Tabellen ist eine Entwurfsbedingung, die eingeplant statt entdeckt werden sollte: Ein Blend mit mehr Eingängen ist meist ein Signal, dass das Verbinden in ein Warehouse gehört.
• Umgang mit Null. Outer Joins erzeugen Nullwerte, und Arithmetik mit einem Nullwert ergibt einen Nullwert statt des anderen Operanden. Die Bestandteile vor dem Addieren zu kapseln – IFNULL(metrik, 0) – verhindert, dass Zeilen ohne sichtbaren Grund aus einer Summe fallen.
• Nicht jedes Feld übersteht den Blend. Berechnete Felder, die in der Quelle auf nicht-additiver Aggregation beruhen, stehen im Blend nicht immer zur Verfügung – was mitunter bedeutet, die Berechnung stromaufwärts in die Datenquelle zu verlegen.

Fazit

Data Blending ist verlässlich, sobald seine Reihenfolge ernst genommen wird: erst aggregieren, dann verbinden. Nahezu jedes unplausible Ergebnis geht auf eine von vier Ursachen zurück. Eine Dimension blieb in einer Tabelle stehen und vervielfachte die Zeilen. Ein Join-Schlüssel traf wegen Typ oder Formatierung nicht. Ein Metrikname war über Tabellen hinweg mehrdeutig. Oder eine Metrik war von vornherein nicht additiv.

Die zugehörige Disziplin ist kurz. Die Granularität festlegen, bevor Felder gewählt werden, und jede Tabelle darauf aggregieren. Den Join-Typ bewusst wählen, statt die Voreinstellung zu übernehmen. Jede Metrik im Blend eindeutig umbenennen, bevor ein berechnetes Feld entsteht, und ihre Aggregation ausdrücklich setzen. Raten aus summierten Bestandteilen neu berechnen statt sie zu mitteln, und deduplizierte Zählungen als etwas behandeln, das ein Blend nicht liefern kann. Und bevor eine geblendete Zahl präsentiert wird: dieselbe Zahl in ihrer eigenen Quelle gegenprüfen – ein Blend, der mit seinen Eingängen übereinstimmt, ist vertrauenswürdig, und einer, der es nicht tut, hat eine konkrete, auffindbare Ursache.