BigQuery mit Data Studio verbinden: Reporting, das schnell bleibt und Abfragekosten im Griff hat

Wann braucht ein Data-Studio-Bericht BigQuery als Unterbau?

Wenn die Daten über das hinauswachsen, was Konnektoren und Tabellen gut bewältigen. Die üblichen Anzeichen sind GA4-Kontingentfehler, die auch nach dem Verschlanken der Seiten bleiben, Fehler wegen „zu vieler Zeilen“, Datenverknüpfungen, die mehr als fünf Quellen oder einen Join ohne Gleichheitsbedingung brauchen, und Google Sheets, die eine Minute zum Öffnen brauchen.

BigQuery passt auch zu Daten, die bereits in Google Cloud liegen, etwa dem GA4-Export nach BigQuery, einer Produktdatenbank oder Dateien aus Finanzen und Operations, die nach Zeitplan geladen werden. Es ist eine Quelle mit flexiblem Schema, eine Tabelle kann also bis zu 100 Dimensionen und 100 Messwerte nutzen statt der 10 und 20, die bei GA4 und Google Ads erlaubt sind.

Wie richtet man Datenquellen richtig ein, um BigQuery mit Data Studio zu verbinden?

Bauen Sie zuerst eine Reporting-Schicht und verbinden Sie Data Studio dann damit. Rohtabellen dienen der Speicherung und Modellierung. Berichte sollten aus kleinen, zweckgebundenen Tabellen oder Views mit klaren Namen lesen, mit einer Zeile pro Tag und Einheit und nur den Spalten, die die Diagramme brauchen.

Für jede Datenquelle entscheide ich drei Dinge: ob sie eine Tabelle oder eine Custom-SQL-Abfrage liest, wessen Anmeldedaten sie nutzt und welches Projekt für die Abfragen belastet wird. Mit den Anmeldedaten des Eigentümers sehen Betrachter Daten ohne eigenen BigQuery-Zugriff, was für die meisten Geschäfts-Dashboards richtig ist. Die Anmeldedaten des Betrachters sind richtig, wenn der Zugriff den Berechtigungen jeder einzelnen Person folgen muss.

Namen zählen mehr, als man denkt. Eine Tabelle namens rpt_sales_daily mit Feldern wie order_date und net_revenue sagt der nächsten Analystin genau, was darin steht. Klare Namen machen außerdem berechnete Felder in Data Studio kürzer, weil die Bereinigung schon in SQL passiert ist.

• Tabellenquellen für vorbereitete, stabile Reporting-Tabellen.
• Custom-SQL-Quellen für Logik, die auf Berichtsparameter reagieren muss.
• Views für gemeinsame Definitionen, die mehrere Berichte nutzen.
• Ein eigenes Abrechnungsprojekt, damit die Reporting-Kosten separat sichtbar sind.

Wie senken Partitionierung und Custom SQL die BigQuery-Kosten?

BigQuery berechnet nach gescannter Datenmenge, das Ziel ist also, bei jedem Laden eines Diagramms weniger zu scannen. Partitionieren Sie Reporting-Tabellen nach Datum, clustern Sie sie nach den Feldern, nach denen am häufigsten gefiltert wird, und stellen Sie sicher, dass jede Abfrage nur die Partitionen im gewählten Zeitraum berührt.

In einer Custom-SQL-Datenquelle nutze ich die Zeitraumparameter des Berichts in der WHERE-Klausel, sodass ein Betrachter, der die letzte Woche ansieht, eine Woche an Daten scannt und nicht drei Jahre. Ohne das kann jede Filteränderung die ganze Tabelle erneut scannen, und ein viel genutztes Dashboard kann zum größten Posten auf der Cloud-Rechnung werden.

Den Rest erledigen geplante Abfragen. Statt Dashboards bei jedem Laden Millionen Rohzeilen aggregieren zu lassen, baut eine geplante Abfrage jeden Morgen eine tägliche Übersichtstabelle. Der Bericht liest diese Übersicht, die klein, günstig und schnell ist.

Wie nutze ich den GA4-Export nach BigQuery in Data Studio?

Modellieren Sie ihn, bevor Sie darüber berichten. Der GA4-Export speichert eine Zeile pro Ereignis mit verschachtelten Parametern, was präzise, aber umständlich direkt darzustellen ist. Ich schreibe SQL, das die benötigten Parameter flach legt, Sitzungen und Schlüsselereignisse bildet, Ihre Kanalgruppierung anwendet und das Ergebnis in partitionierte Tagestabellen schreibt.

Der Gewinn: GA4-Berichte hängen nicht mehr vom Kontingent der Data API von 14.000 Tokens pro Projekt und Property pro Stunde ab, und Sie können Webverhalten mit CRM-, Produkt- oder Umsatzdaten verknüpfen, die GA4 nie sieht. Der Preis dafür sind Abfragekosten und jemand, der SQL lesen kann, deshalb dokumentiere ich jedes Modell in verständlicher Sprache.

Was ist Conversational Analytics in Data Studio, und braucht es BigQuery?

Mit Conversational Analytics stellen Mitarbeitende ihren Daten in Data Studio Fragen in natürlicher Sprache, über Datenagenten, die in BigQuery erstellt und in Data Studio veröffentlicht werden. Die Funktion steht seit dem 16. April 2026 allen Nutzern zur Verfügung und ist seit dem 30. Juli 2026 allgemein verfügbar.

Die Antworten sind nur so gut wie die Tabellen und Beschreibungen hinter dem Agenten. Saubere, gut benannte Reporting-Tabellen mit dokumentierten Feldern sind dieselbe Grundlage, die ein gutes Dashboard braucht. Wer die BigQuery-Schicht richtig aufbaut, ist also für beides vorbereitet.

Wie sieht ein Dashboard auf BigQuery-Basis in der Praxis aus?

Ein Dashboard für Lieferkette und Einkauf, das ich bei Greenwolf Tech Labs geleitet habe, ist ein gutes Beispiel. Es zeigt die gesamten Einkaufsausgaben, realisierte Einsparungen, aktive Lieferanten, die durchschnittliche Lieferzeit, Compliance-Vorfälle, die größten Lieferanten nach Ausgaben, Ausgaben nach Kategorie und Land, Lieferanten mit Risiko und den Freigabestatus.

Solche Daten stammen aus mehreren Systemen und umfassen viele Zeilen. Sie vorgelagert zu verknüpfen und zu bereinigen und Data Studio dann ein paar aufgeräumte Tabellen bereitzustellen, sorgt dafür, dass eine Einkaufsleitung nach Land oder Kategorie filtern und in Sekunden eine Antwort bekommen kann, statt auf eine Tabelle zu warten.