{"id":8823,"date":"2026-08-15T13:59:00","date_gmt":"2026-08-15T11:59:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=8821"},"modified":"2026-08-13T14:29:54","modified_gmt":"2026-08-13T12:29:54","slug":"ga4-bigquery-kostenoptimierung-rohdaten-export","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/digital-analytics-de\/ga4-bigquery-kostenoptimierung-rohdaten-export\/","title":{"rendered":"GA4 BigQuery Kostenoptimierung: Das Ende unn\u00f6tiger Kosten beim Rohdaten-Export"},"content":{"rendered":"\r\n

GA4 BigQuery Kostenoptimierung: Das Ende unn\u00f6tiger Kosten beim Rohdaten-Export<\/h2>\r\n\r\n\r\n\r\n

Die Nutzung des nativen Google Analytics 4 (GA4) Rohdaten-Exports in Google Cloud BigQuery bietet maximale analytische Flexibilit\u00e4t. Jedoch f\u00fchren unoptimierte Abfragen auf Rohdaten-Tabellen schnell zu exponentiell steigenden Infrastrukturkosten. Da BigQuery exakt nach dem Datenvolumen abgerechnet wird, das w\u00e4hrend einer Abfrage verarbeitet wird, ist das Verst\u00e4ndnis der spaltenorientierten Speicherarchitektur essenziell f\u00fcr effizientes Data Engineering.<\/p>\r\n\r\n\r\n\r\n

1. Die Kostenfalle von SELECT * auf events_* Tabellen<\/h2>\r\n\r\n\r\n\r\n

BigQuery trennt Abfrageausf\u00fchrung und Speicherung: Dremel ist die verteilte Abfrage-Engine, die Daten selbst liegen im spaltenorientierten Speicherformat Capacitor. In relationalen Datenbanken wird bei einer Abfrage stets der gesamte Datensatz (die Zeile) gelesen. In einer spaltenorientierten Datenbank wird jede Spalte isoliert in verteilten Speicherbl\u00f6cken abgelegt. Die Abfragekosten h\u00e4ngen somit ausschlie\u00dflich davon ab, wie viele Datenbytes die im SQL-Statement explizit benannten Spalten umfassen.<\/p>\r\n\r\n\r\n\r\n

Ein undifferenziertes SELECT * FROM `project.analytics_12345.events_*`<\/code> zwingt die Engine, s\u00e4mtliche Spalten \u00fcber alle verf\u00fcgbaren Shards hinweg zu scannen \u2013 inklusive speicherintensiver, verschachtelter RECORD-Strukturen wie event_params<\/code>, user_properties<\/code> und items<\/code>. Eine einzige solche Abfrage \u00fcber mehrere Monate hinweg verarbeitet schnell Terabytes an Daten und erzeugt erhebliche Fehlkosten.<\/p>\r\n\r\n\r\n\r\n

\n\"Drei\n
Jede Stufe verkleinert, was die Abfrage lesen muss: erst das Zeitfenster und die Spalten, dann die Rohtabelle selbst, die das Dashboard gar nicht mehr anfasst.<\/figcaption>\n<\/figure>\n\n

2. Datums-Partitionierung und Tabellen-Suffixe nutzen<\/h2>\r\n\r\n\r\n\r\n

GA4 speichert Exportdaten in t\u00e4glichen Shard-Tabellen nach dem Schema events_YYYYMMDD<\/code>. Der wichtigste Hebel zur Verringerung der gescannten Bytes ist die konsequente Einschr\u00e4nkung \u00fcber die Pseudo-Spalte _TABLE_SUFFIX<\/code>. Ohne diese Filterung scannt BigQuery grunds\u00e4tzlich die gesamte Historie des Datensatzes, bevor WHERE-Bedingungen ausgewertet werden.<\/p>\r\n\r\n\r\n\r\n

-- KOSTENINTENSIV (Scannt die gesamte Historie):\r\nSELECT event_name, user_pseudo_id \r\nFROM `project.analytics_12345.events_*`\r\nWHERE event_name = 'purchase';\r\n\r\n-- OPTIMIERT (Begrenzt den Scan auf ein 7-Tage-Fenster):\r\nSELECT event_name, user_pseudo_id \r\nFROM `project.analytics_12345.events_*`\r\nWHERE _TABLE_SUFFIX BETWEEN '20260801' AND '20260807'\r\n  AND event_name = 'purchase';<\/code><\/pre>\r\n\r\n\r\n\r\n
3. Clustering nach event_name und user_pseudo_id<\/h2>\r\n\r\n\r\n\r\n
W\u00e4hrend die Partitionierung Daten auf Tabellenebene trennt, sortiert ein Clustering die internen Speicherbl\u00f6cke anhand spezifischer Spaltenwerte. Wenn analytische Prozesse regelm\u00e4\u00dfig nach Event-Typen oder User-IDs filtern, reduziert ein gezieltes Clustering in nachgelagerten Staging-Tabellen die Ausf\u00fchrungszeit und die Kosten drastisch.<\/p>\r\n\r\n\r\n\r\n
Wird auf eine geclusterte Spalte gefiltert, \u00fcberspringt BigQuery irrelevante Speicherbl\u00f6cke vollautomatisch. F\u00fcr analytische Workloads liefert eine Sortierung nach Kardinalit\u00e4t \u2013 beginnend mit event_name<\/code>, gefolgt von user_pseudo_id<\/code> \u2013 die h\u00f6chste Effizienz.<\/p>\r\n\r\n\r\n\r\n
4. Aufbau von Zwischentabellen durch inkrementelle Scheduled Queries<\/h2>\r\n\r\n\r\n\r\n
Es ist ineffizient, Dashboards oder Reporting-Tools direkt an verschachtelte GA4-Rohtabellen anzubinden. Die Best Practice besteht in der Implementierung eines ETL-Prozesses (Extract, Transform, Load) mittels inkrementeller Scheduled Queries<\/strong>. Indem t\u00e4glich nur die Daten des Vortages verarbeitet und in eine flache, geclusterte Summary-Tabelle geschrieben werden, sinken die wiederkehrenden Abfragekosten um bis zu 95 %.<\/p>\r\n\r\n\r\n\r\n
-- Einmalige Einrichtung: Zieltabelle anlegen (nur einmal ausf\u00fchren)\r\nCREATE TABLE IF NOT EXISTS `project.analytics_12345.daily_user_metrics`\r\n(\r\n  event_date DATE,\r\n  event_name STRING,\r\n  user_pseudo_id STRING,\r\n  total_events INT64,\r\n  sessions INT64\r\n)\r\nPARTITION BY event_date\r\nCLUSTER BY event_name, user_pseudo_id;\r\n\r\n-- T\u00e4gliche inkrementelle Aggregation (der eigentliche Tagesjob)\r\nDELETE FROM `project.analytics_12345.daily_user_metrics`\r\nWHERE event_date = DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY);\r\n\r\nINSERT INTO `project.analytics_12345.daily_user_metrics`\r\nSELECT\r\n  PARSE_DATE('%Y%m%d', event_date) AS event_date,\r\n  event_name,\r\n  user_pseudo_id,\r\n  COUNT(1) AS total_events,\r\n  COUNT(DISTINCT (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id')) AS sessions\r\nFROM `project.analytics_12345.events_*`\r\nWHERE _TABLE_SUFFIX = FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY))\r\nGROUP BY 1, 2, 3;<\/code><\/pre>\r\n\r\n\r\n\r\n
Zusammenfassung<\/h2>\r\n\r\n\r\n\r\n
Eine kosteneffiziente GA4-BigQuery-Architektur beruht auf drei Grundregeln: dem Verzicht auf Wildcard-Spaltenabfragen, der strikten Begrenzung des Scan-Bereichs \u00fcber _TABLE_SUFFIX<\/code> und der Auslagerung rechenintensiver Reportings auf flache, geclusterte Zwischentabellen durch automatisierte Tagesjobs.<\/p>\r\n\n\n
\n
Quellen<\/h2>\n