![\"Zwei](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/looker-blending-de.png\")
Was ein Blend tats\u00e4chlich tut<\/h2>\n
Ein Blend f\u00fchrt zwei Operationen aus, in dieser Reihenfolge: Jede Tabelle wird zuerst \u00fcber ihre eigenen Dimensionen aggregiert<\/strong>, und die aggregierten Ergebnisse werden anschlie\u00dfend<\/strong> \u00fcber den konfigurierten Schl\u00fcssel verbunden. Beide H\u00e4lften dieses Satzes z\u00e4hlen. Die Aggregation geschieht vor dem Join, also bestimmen die f\u00fcr eine Tabelle gew\u00e4hlten Dimensionen, wie viele Zeilen diese Tabelle in den Join einbringt \u2013 und der Join gleicht diese Zeilen danach Zeile f\u00fcr Zeile gegen die andere Tabelle ab.<\/p>\n Deshalb ist ein Blend kein Nachschlagen, und deshalb ist die Wahl der Dimensionen nicht kosmetisch. Eine Dimension zu einer Tabelle hinzuzuf\u00fcgen erg\u00e4nzt nicht einfach eine Spalte; es ver\u00e4ndert die Anzahl der Zeilen, die diese Tabelle beisteuert, und damit das Ergebnis des Joins.<\/p>\n Looker Studio bietet den Standardsatz, und die Wahl entscheidet, welche Zeilen \u00fcberleben, wenn ein Schl\u00fcssel nur auf einer Seite existiert:<\/p>\n Eine praktische Regel: Lautet die Frage \u201ewie haben sich diese beiden Dinge im selben Zeitraum entwickelt\u201c, sch\u00fctzt Full Outer auf dem Datum vor stillschweigend verlorenen Tagen. Lautet die Frage \u201ewas ist mit den Datens\u00e4tzen passiert, die in beiden Systemen existieren\u201c, ist Inner die ehrliche Wahl \u2013 und die Zahl der dabei entfernten Zeilen ist selbst berichtenswert.<\/p>\n Ein Join-Schl\u00fcssel muss exakt \u00fcbereinstimmen, und die meisten Fehlschl\u00e4ge stammen von Werten, die f\u00fcr einen Menschen identisch aussehen und es f\u00fcr die Maschine nicht sind.<\/p>\n Die Datumsgranularit\u00e4t ist der h\u00e4ufigste Fall: Liefert eine Quelle einen Zeitstempel und die andere ein Datum, passt nie etwas zusammen \u2013 und die L\u00f6sung besteht darin, in jeder Quelle ein reines Datumsfeld bereitzustellen, statt darauf zu hoffen, dass der Blend das ausgleicht. Gro\u00df-\/Kleinschreibung und Leerzeichen folgen: Eine weitere Einschr\u00e4nkung ist struktureller Natur: Schl\u00fcssel mit sehr hoher Kardinalit\u00e4t, etwa eine Transaktions-ID, machen Blends langsam \u2013 und ein Blend, der in den Zeit\u00fcberlauf l\u00e4uft, ist ein leeres Diagramm und keine Fehlermeldung.<\/p>\n 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\u00fcssel 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\u00df \u2013 und weiterhin eine runde, plausibel aussehende Zahl.<\/p>\n Zwei Gewohnheiten verhindern das. Die erste: die Granularit\u00e4t des Blends festlegen, bevor irgendein Feld gew\u00e4hlt wird, und jede Tabelle genau auf diese Granularit\u00e4t aggregieren \u2013 liegt der Blend auf Tagesebene, f\u00fchrt keine Tabelle die Kampagne mit. Die zweite ist eine Diagnose: Record Count<\/strong> aus jeder Tabelle in eine vor\u00fcbergehende Tabellenansicht aufzunehmen zeigt sofort, ob ein Schl\u00fcssel mehr Zeilen trifft als erwartet, denn ein sauberer Eins-zu-eins-Join liefert je Zeile und Tabelle einen Record Count von eins.<\/p>\n Wird die Kampagnenebene wirklich gebraucht, geh\u00f6rt sie in einen zweiten, auf dieser Granularit\u00e4t gebauten Blend und nicht in denselben. Ein einzelner Blend f\u00fcr zwei Granularit\u00e4ten ist die Anforderung, die sich nicht erf\u00fcllen l\u00e4sst.<\/p>\n Dieselbe Metrik aus mehreren Properties zusammenzuf\u00fchren \u2013 etwa Gesamtnutzer aus drei regionalen GA4-Properties \u2013 trifft auf ein Verhalten, das leicht f\u00fcr einen Rechenfehler gehalten wird.<\/p>\n Jede Tabelle in einem Blend beh\u00e4lt die Feldnamen ihrer Quelle. Steuern drei Tabellen je ein Feld namens Total users<\/em> bei, gelangen drei gleichnamige Felder in den Blend, und ein berechnetes Feld, das als Addition dieses Namens geschrieben ist, hat keine eindeutige M\u00f6glichkeit, sich an das richtige zu binden. Heraus kommt eine Zahl, die ohne Fehlermeldung entsteht und nicht die beabsichtigte Summe ist.<\/p>\n Die L\u00f6sung besteht darin, jede Metrik im Blend-Editor umzubenennen, bevor \u00fcberhaupt ein berechnetes Feld geschrieben wird<\/strong>. Ausdr\u00fcckliche, unterscheidbare Namen \u2013 Im selben Durchgang zu pr\u00fcfen: die f\u00fcr jede Metrik im Blend eingestellte Aggregation. Ein Feld mit automatischer Aggregation kann sich anders verhalten als eines, das ausdr\u00fccklich auf Das Umbenennen bringt die Addition mechanisch zum Laufen. Ob die Addition etwas bedeutet, ist eine zweite Frage \u2013 und f\u00fcr zwei Kategorien von Metriken lautet die Antwort Nein.<\/p>\n Deduplizierte Z\u00e4hlungen<\/strong> \u2013 Nutzer, aktive Nutzer, jede Distinct-Z\u00e4hlung \u2013 sind nicht additiv. Wer zwei der drei Properties besucht, ist eine Person; die drei Z\u00e4hlungen addiert melden zwei. Dasselbe gilt \u00fcber die Zeit: Tageswerte f\u00fcr Nutzer \u00fcber einen Monat aufzusummieren ergibt nicht die Monatsnutzer. Keine Blend-Konfiguration behebt das, denn die zum Deduplizieren n\u00f6tige Information steckt in den aggregierten Werten nicht mehr drin. Wird eine echte Property-\u00fcbergreifende Nutzerzahl gebraucht, muss die Deduplizierung vor Looker Studio stattfinden \u2013 praktisch also auf den Rohdaten in einem Warehouse.<\/p>\n Raten und Durchschnitte<\/strong> \u2013 CTR, Conversion Rate, Absprungrate, durchschnittlicher Bestellwert \u2013 m\u00fcssen 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\u00e4llig identische Nenner. Die richtige Form summiert die Bestandteile und teilt zum Schluss:<\/p>\n Data Blending ist verl\u00e4sslich, sobald seine Reihenfolge ernst genommen wird: erst aggregieren, dann verbinden. Nahezu jedes unplausible Ergebnis geht auf eine von vier Ursachen zur\u00fcck. Eine Dimension blieb in einer Tabelle stehen und vervielfachte die Zeilen. Ein Join-Schl\u00fcssel traf wegen Typ oder Formatierung nicht. Ein Metrikname war \u00fcber Tabellen hinweg mehrdeutig. Oder eine Metrik war von vornherein nicht additiv.<\/p>\n Die zugeh\u00f6rige Disziplin ist kurz. Die Granularit\u00e4t festlegen, bevor Felder gew\u00e4hlt werden, und jede Tabelle darauf aggregieren. Den Join-Typ bewusst w\u00e4hlen, statt die Voreinstellung zu \u00fcbernehmen. Jede Metrik im Blend eindeutig umbenennen, bevor ein berechnetes Feld entsteht, und ihre Aggregation ausdr\u00fccklich setzen. Raten aus summierten Bestandteilen neu berechnen statt sie zu mitteln, und deduplizierte Z\u00e4hlungen als etwas behandeln, das ein Blend nicht liefern kann. Und bevor eine geblendete Zahl pr\u00e4sentiert wird: dieselbe Zahl in ihrer eigenen Quelle gegenpr\u00fcfen \u2013 ein Blend, der mit seinen Eing\u00e4ngen \u00fcbereinstimmt, ist vertrauensw\u00fcrdig, und einer, der es nicht tut, hat eine konkrete, auffindbare Ursache.<\/p>\n","protected":false},"excerpt":{"rendered":" Wie ein Blend wirklich arbeitet \u2013 erst aggregieren, dann verbinden \u2013, was die f\u00fcnf Join-Typen jeweils tun, warum eine zus\u00e4tzliche Dimension jede Zahl vervielfachen kann und warum die Summe einer Metrik \u00fcber mehrere Properties erst nach dem Umbenennen des Felds verl\u00e4sslich ist.<\/p>\n","protected":false},"author":1,"featured_media":11411,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[10],"tags":[92088,92091,92508,92110],"class_list":["post-10153","post","type-post","status-publish","format-standard","hentry","category-digital-analytics-de","tag-data-quality-de","tag-google-analytics-4-de","tag-looker-studio-de","tag-web-analytics-de"],"yoast_head":"\nDie f\u00fcnf Join-Typen<\/h2>\n
\n
Wo Join-Schl\u00fcssel ohne Warnung brechen<\/h2>\n
Newsletter<\/code>, newsletter<\/code> und newsletter <\/code> sind drei verschiedene Schl\u00fcssel. Das Normalisieren mit LOWER()<\/code> und TRIM()<\/code> geh\u00f6rt als berechnetes Feld in die Datenquelle, denn ein dort erzeugtes Feld steht als Join-Schl\u00fcssel zur Verf\u00fcgung \u2013 der Blend-Editor ist nicht der Ort, Eingangsdaten zu reparieren. W\u00e4hrungs- und Locale-Formatierung erzeugen dieselbe Fehlerklasse bei numerischen oder Identifikator-Schl\u00fcsseln.<\/p>\nDimensionen entscheiden, was eine Zeile bedeutet<\/h2>\n
Metriknamen und Summen \u00fcber mehrere Properties<\/h2>\n
users_de<\/code>, users_at<\/code>, users_ch<\/code> \u2013 machen den Bezug eindeutig, und die Addition verh\u00e4lt sich dann wie erwartet:<\/p>\n-- Erst verlaesslich, wenn jede Quellmetrik einen eindeutigen Namen traegt\nusers_de + users_at + users_ch<\/code><\/pre>\nSUM<\/code> steht \u2013 und da beide anstandslos rendern, ist die ausdr\u00fcckliche Einstellung vorzuziehen.<\/p>\nMetriken, die sich gar nicht summieren lassen<\/h2>\n
-- Falsch: zwei Raten mitteln\n(conv_rate_a + conv_rate_b) \/ 2\n\n-- Richtig: aus den summierten Bestandteilen neu berechnen\n(conversions_a + conversions_b) \/ (sessions_a + sessions_b)<\/code><\/pre>\nWeitere Techniken, die sich lohnen<\/h2>\n
\n
IFNULL(metrik, 0)<\/code> \u2013 verhindert, dass Zeilen ohne sichtbaren Grund aus einer Summe fallen.<\/li>\nFazit<\/h2>\n