Daten in Looker Studio verbinden: Falsche Summen und doppelte Zeilen vermeiden

Data Blending verbindet Tabellen aus mehreren Quellen in einem Diagramm. Ein Join ordnet Zeilen anhand passender Werte zu, etwa desselben Datums und derselben Kampagnen-ID. Plausible Summen können trotzdem falsch sein, wenn ein Join Werte wiederholt, nicht passende Schlüssel entfernt oder unvereinbare Kennzahlen kombiniert. Eine belastbare Prüfung betrachtet Einzelwerte und Summen.

Drei Schritte sind entscheidend: Jede Tabelle wird nach den gewählten Dimensionen gruppiert, die entstandenen Zeilen werden verbunden, und das Diagramm kann das Ergebnis erneut aggregieren. Tabellenfilter, Zeiträume und Diagrammfilter gehören ebenfalls zur Prüfung. Der Join-Typ allein bestimmt die Endzahl nicht.

1. Die Bedeutung einer Zeile festlegen

Vor der Feldauswahl sollte die gewünschte Zeile feststehen: ein Tag, eine Kampagne je Tag oder eine Bestellung. Der Join-Schlüssel muss diese Detailebene abbilden. Eine zusammengesetzte Bedingung kann Datum und Kampagne als getrennte Felder enthalten; ein zusammengeklebter Textschlüssel ist unnötig.

Enthält eine Datumszeile 100 Sitzungen und trifft auf drei Kampagnenzeilen, entstehen drei Kopien des Sitzungswerts. Ein anschließendes SUM ergibt 300. Der Faktor beträgt nur bei Schlüsseln mit genau drei Treffern drei. Über mehrere Schlüssel hängt die Summe von Kennzahlenwerten und Trefferzahlen ab.

Eins-zu-viele-Joins sind nicht grundsätzlich falsch: Eine Kampagnensumme kann bewusst neben Tagesdetails stehen. Kennzeichnung und Aggregation müssen dazu passen. AVG oder MAX ist keine allgemeine Deduplizierungsregel und kann Beiträge anderer Kampagnen verlieren. Eine Zeile je Schlüssel auf beiden Seiten ist eine einfache Lösung für einen Eins-zu-eins-Vergleich.

2. Den Join nach der Berichtsfrage wählen

Left Outer behält linke Zeilen und ergänzt rechte Treffer. Right Outer kehrt diese Wahl um. Inner behält nur passende Paare. Full Outer erhält zusätzlich nicht passende Zeilen beider Seiten. Cross kombiniert jede Zeile mit jeder anderen und benötigt keinen Schlüssel.

Full Outer verhindert keine Wiederholungen und erzeugt keine Tage, die in beiden Quellen fehlen. Ein Kalender mit einer Zeile je benötigtem Tag kann Left Joins verankern, sofern sämtliche Verbindungen das Kalenderdatum verwenden und spätere Filter keine Zeilen ohne Treffer entfernen. Bei Full Outer kann das angezeigte Datum IFNULL(linkes_datum, rechtes_datum) benötigen.

Mehrere Joins werden der Reihe nach ausgewertet; spätere Verbindungen arbeiten mit vorherigen Ergebnissen. Die erste physische Tabelle ist daher nicht der vollständige linke Eingang jeder Folge-Verbindung. Ein Blend unterstützt höchstens fünf Tabellen einschließlich Kalender. Unabhängige Diagramme können eigene Blends nutzen; ein Diagramm mit mehr Eingängen benötigt gegebenenfalls eine vorgelagerte Aufbereitung.

3. Schlüssel und tatsächliche Eingangszeilen prüfen

Datum und Zeitstempel benötigen kompatible Typen und eine festgelegte Berichtszeitzone. Eine Umrechnung um Mitternacht kann dasselbe Ereignis verschiedenen Tagen zuordnen. LOWER und TRIM dürfen Kampagnenbezeichnungen nur normalisieren, wenn die fachliche Bedeutung das zulässt. Unterschiedliche Kennungen dürfen nicht allein wegen ähnlicher Schreibweisen zusammenfallen.

Ein Schlüssel kann in der Quelle oder in einem unterstützten berechneten Feld der einzelnen Blend-Tabelle vorbereitet werden. Berechnungen innerhalb einer Blend-Tabelle dürfen nur Felder dieser Tabelle verwenden. Berechnungen über mehrere Tabellen gehören hinter den Blend, beispielsweise ins Diagramm.

Record Count zählt häufig zugrunde liegende Quelldatensätze und nicht die voraggregierten Join-Zeilen. Ein täglicher Eins-zu-eins-Join kann deshalb einen Wert über eins zeigen. Eine Diagnosetabelle sollte sämtliche ausgewählten Dimensionen offenlegen, Zeilen je vollständigem Schlüssel zählen und fehlende Schlüssel zeigen. Ein Connector-Zeitablauf kann eine Fehlermeldung auslösen; ein leeres Diagramm allein erklärt die Ursache nicht.

4. Felder eindeutig benennen

Aliasse wie sessions_a und sessions_b erleichtern die Prüfung von Formeln. Das tatsächlich gemeinte Quellfeld muss weiterhin richtig ausgewählt werden. Gleiche Anzeigenamen beweisen für sich genommen keine stillschweigend falsch berechnete Summe.

Quellmetriken können nach dem Blending erneut aggregiert werden. SUM passt zu additiven Werten auf der gewünschten Ebene, repariert aber weder vervielfachte Zeilen noch eindeutige Nutzerzahlen. Automatische Aggregation sollte vor einer Änderung verstanden werden. Zwei Diagramme können denselben Blend auf unterschiedlichen Ebenen verwenden, sofern die Kennzahlen diesen Wechsel erlauben.

5. Nutzer, Ereignisse und Verhältnisse trennen

Addierte Nutzerzahlen regionaler Properties zählen Zugehörigkeiten zu Properties und nicht zwingend eindeutige Personen. Auch tägliche eindeutige Nutzerzahlen ergeben keine eindeutige Monatszahl: Ein Besuch derselben Person am Montag und Dienstag zählt in beiden Tageswerten, im Monat aber nur einmal. Solche Zählungen sind nur bei nachweislich überschneidungsfreien Gruppen additiv. Ereignisexporte lösen die Identität über Properties nicht allein: Deduplizierung benötigt eine gültige, einheitlich abgegrenzte Kennung und eine definierte Identitätsregel.

Für zwei überschneidungsfreie Quellen mit kompatiblen Definitionen lässt sich eine Quote aus summierten Bestandteilen berechnen. Im folgenden Beispiel zählt converted_sessions Sitzungen mit mindestens einem passenden Ergebnis. Eine Ereigniszahl im Zähler würde die Bedeutung zu Ereignissen je Sitzung ändern und könnte über 100 Prozent liegen.

Ein fehlender Wert (NULL) ist nicht automatisch die Zahl 0. Ein gescheiterter Import, ein nicht passender Schlüssel und ein bestätigter Tag ohne Aktivität bedeuten Unterschiedliches. Die folgende Formel lässt unvollständige Daten bewusst offen; eine Ersetzung durch 0 ist nur bei fachlich gesicherter Nullaktivität passend.

CASE
  WHEN SUM(
    CASE
      WHEN sessions_a IS NULL OR sessions_b IS NULL
        OR converted_sessions_a IS NULL
        OR converted_sessions_b IS NULL
      THEN 1 ELSE 0
    END
  ) > 0 THEN NULL
  ELSE
    (SUM(converted_sessions_a) + SUM(converted_sessions_b))
    / NULLIF(SUM(sessions_a) + SUM(sessions_b), 0)
END

Diese Diagrammformel setzt eine vollständige Zeile je gemeinsamem Schlüssel auf beiden Seiten, überschneidungsfreie Gruppen, gleiche Zeiträume und nicht negative Sitzungszahlen voraus. Feldnamen sind Beispielaliasse. Jede unvollständige verbundene Zeile lässt das Ergebnis leer; eine getrennte Vollständigkeitsprüfung muss außerdem Tage oder Schlüssel erkennen, die in beiden Quellen fehlen. Das numerische Ergebnis ist ein Bruchteil und wird als Prozentwert dargestellt.

6. Mit Gegenbeispielen testen

Angenommen, A hat 100 Sitzungen und 10 Ergebnisse, B dagegen 900 Sitzungen und 9 Ergebnisse. Gemeinsam ergibt das 19/1000 = 1,9 Prozent. Trifft A einmal und B dreimal, liefert SUM nach dem Join 37/2800, rund 1,32 Prozent. Zähler und Nenner aus derselben Quelle erhalten die Gesamtquote bei unterschiedlichen Trefferzahlen je Schlüssel nicht.

Gleiche Gesamtsummen beweisen keine korrekte Verbindung. A=100 und B=100 ergeben ursprünglich 200; ein Ergebnis mit A zweimal und fehlendem B ergibt ebenfalls 200. Der Vergleich muss Schlüsselabdeckung und Einzelwerte einschließen. Größere oder kleinere Summen sind Hinweise, keine eindeutigen Diagnosen: Auch Zeiträume, Filter, Kennzahlendefinition und Quellenaktualisierung können abweichen.

Eine belastbare Abnahme vergleicht gleiche Zeiträume, Filter und Kennzahlendefinitionen in Quelle und Blend. Anschließend folgen repräsentative Schlüssel, fehlende Treffer und Nenner mit Wert 0. Sämtliche verbundenen Zeilen sind unter der tatsächlich verwendeten Diagrammaggregation zu beurteilen.