{"id":10472,"date":"2026-09-19T12:30:00","date_gmt":"2026-09-19T10:30:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=10472"},"modified":"2026-09-09T17:09:54","modified_gmt":"2026-09-09T15:09:54","slug":"bigquery-kosten-beim-ga4-export-welche-tabellen-und-spalten-eine-abfrage","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/digital-analytics-de\/bigquery-kosten-beim-ga4-export-welche-tabellen-und-spalten-eine-abfrage\/","title":{"rendered":"BigQuery-Kosten beim GA4-Export: Welche Tabellen und Spalten eine Abfrage liest und der kostenlose Probelauf"},"content":{"rendered":"

Der GA4-Export wird nach Bytes abgerechnet, und die Byte-Zahl hat mit der Antwort fast nichts zu tun. Eine Abfrage, die vierzig Zeilen liefert, und eine, die vier Millionen liefert, k\u00f6nnen genau gleich viel lesen – denn abgerechnet wird, was unterwegs ge\u00f6ffnet werden musste, und nicht, was am Ende zur\u00fcckkam.<\/p>\n

Zwei Feinheiten entscheiden dar\u00fcber: wie viele der Tagestabellen ge\u00f6ffnet werden m\u00fcssen und wie viele Spalten darin zu lesen sind. Beides steht fest, bevor eine einzige Zeile entsteht, und beides l\u00e4sst sich vorher ablesen.<\/p>\n

\n\"Neunzig
Derselbe Monat, dieselben Zeilen, dasselbe Ergebnis. Nur der Filter ist anders geschrieben.<\/figcaption><\/figure>\n

Bezahlt wird das Lesen, nicht das Zur\u00fcckgeben<\/h2>\n

Das teuerste Missverst\u00e4ndnis in diesem Bereich hei\u00dft LIMIT<\/code>. Eine Begrenzung greift, nachdem die Daten gelesen wurden; sie deckelt die Ergebnismenge und \u00e4ndert an den Kosten nichts. Dasselbe gilt f\u00fcr ORDER BY<\/code> und f\u00fcr alles andere, was geschieht, wenn die Zeilen erst einmal da sind.<\/p>\n

Damit ist die Gewohnheit, mit SELECT * ... LIMIT 10<\/code> zu st\u00f6bern – in fast jeder anderen Datenbank vern\u00fcnftig -, die teuerste Art, einen GA4-Export anzusehen. Zehn Zeilen aus jeder Spalte \u00fcber jede Tabelle des Platzhalters sind ein vollst\u00e4ndiger Durchlauf mit einem kleinen Fenster am Ende.<\/p>\n

Warum event_date nichts beschneidet<\/h2>\n

Die Tagestabellen werden \u00fcber einen Platzhalter angesprochen, und _TABLE_SUFFIX<\/code> ist der Teil des Tabellennamens, der darauf folgt. Danach zu filtern, w\u00e4hlt Tabellen aus, und Ausw\u00e4hlen geschieht vor dem Lesen – den Rest \u00f6ffnet die Maschine schlicht nie.<\/p>\n

event_date<\/code> sieht aus, als t\u00e4te es dasselbe, und tut das Gegenteil. Es ist eine Spalte in jeder Tabelle; um herauszufinden, ob eine Tabelle passende Zeilen enth\u00e4lt, muss sie ge\u00f6ffnet und die Spalte gelesen werden. Der Filter wirkt korrekt, das Ergebnis ist identisch, und die Rechnung umfasst den ganzen Platzhalter.<\/p>\n

# beschneidet: der Suffix ist Teil des Namens\nWHERE _TABLE_SUFFIX BETWEEN '20260801' AND '20260831'\n\n# beschneidet nicht: die Spalte liegt in den Tabellen\nWHERE event_date BETWEEN '20260801' AND '20260831'\n\n# beide liefern dieselben Zeilen<\/code><\/pre>\n
Dieselbe Logik erkl\u00e4rt, warum der Platzhalter auch events_intraday_*<\/code> trifft und warum der Suffixfilter sie ausschlie\u00dft: intraday_<\/code> sortiert hinter jedem achtstelligen Datum, ein Bereich, der auf ein Datum endet, l\u00e4sst sie also drau\u00dfen. Das ist eine Nebenwirkung, die zu kennen ist, ohne darauf zu bauen – f\u00fcr den laufenden Tag wird die Intraday-Tabelle absichtlich und getrennt abgefragt.<\/p>\n
Spalten sind der zweite Hebel<\/h2>\n
Innerhalb der Tabellen, die tats\u00e4chlich ge\u00f6ffnet werden, sind die Kosten die Summe der genannten Spalten. Hier wird die Bauform des Exports wichtig: event_params<\/code> ist eine einzige verschachtelte Spalte, in der jeder Parameter jedes Ereignisses liegt, und eine Abfrage, die einen einzelnen Parameter herauszieht, liest die ganze Spalte.<\/p>\n
Aus diesem Feld nur page_location<\/code> zu lesen, ist nicht m\u00f6glich. Das spricht nicht gegen seine Verwendung – es spricht daf\u00fcr, Spalten ausdr\u00fccklich zu benennen statt zu SELECT *<\/code> zu greifen, denn die wirklich gro\u00dfen Spalten sind genau die, die niemand braucht: user_properties<\/code>, items<\/code>, collected_traffic_source<\/code> und die Ger\u00e4te- und Geostrukturen.<\/p>\n
Was jede Ma\u00dfnahme tats\u00e4chlich \u00e4ndert<\/h2>\n\n\n\n\n\n\n\n\n\n\n
Ma\u00dfnahme<\/th>\nWirkung auf die gelesenen Bytes<\/th>\n<\/tr>\n<\/thead>\n
_TABLE_SUFFIX<\/code> statt event_date<\/code><\/td>\nvon jeder Tabelle des Datensatzes auf die im Zeitraum<\/td>\n<\/tr>\n
Spalten benennen statt SELECT *<\/code><\/td>\nanteilig – oft die gr\u00f6\u00dfte einzelne Ersparnis<\/td>\n<\/tr>\n
LIMIT 100<\/code><\/td>\nkeine<\/td>\n<\/tr>\n
ein Filter auf einen Ereignisparameter<\/td>\nkeine – event_params<\/code> wird so oder so ganz gelesen<\/td>\n<\/tr>\n
ein Filter auf event_name<\/code><\/td>\nh\u00e4ngt an der Clusterung der Tabellen – der Probelauf sagt es<\/td>\n<\/tr>\n
eine einmal je Tag geschriebene schmale Tabelle<\/td>\nein Bruchteil, dauerhaft, f\u00fcr jede folgende Abfrage<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Die Zeile zur Clusterung bleibt hier absichtlich unbeantwortet. Ob ein Filter auf event_name<\/code> Bytes spart, h\u00e4ngt am Datensatz, und dar\u00fcber zu mutma\u00dfen er\u00fcbrigt sich, wenn die genaue Antwort einen Tastendruck entfernt liegt.<\/p>\n
Der Probelauf ist kostenlos und genau<\/h2>\n
BigQuery berechnet die Byte-Sch\u00e4tzung aus den Tabellenmetadaten, ohne etwas auszuf\u00fchren – damit ist sie kostenlos und exakt. Der Editor zeigt sie in der Ecke, bevor die Abfrage abgeschickt wird; auf der Befehlszeile gibt es dasselbe als Schalter.<\/p>\n
bq query --use_legacy_sql=false --dry_run 'SELECT ...'\n\nQuery successfully validated.\nAssuming the tables are not modified,\nthis query will process 41.203.847.552 bytes of data.<\/code><\/pre>\n
Einundvierzig Gigabyte sind eine Zahl, \u00fcber die sich entscheiden l\u00e4sst. Die Abfrage erst laufen zu lassen und es danach zu erfahren, ist dieselbe Auskunft zum schlechteren Zeitpunkt, und zwischen beiden Gewohnheiten liegt eine Zeile vor der Anweisung.<\/p>\n
Was sich wiederholt, geh\u00f6rt in eine schmale Tabelle<\/h2>\n
Der letzte Hebel ist ein baulicher und kein sprachlicher. Eine Auswertung, die jeden Morgen \u00fcber neunzig Tage l\u00e4uft, liest neunundachtzig Tage erneut, die sich seit gestern nicht ge\u00e4ndert haben.<\/p>\n
Eine geplante Abfrage, die einmal je Tag die wenigen tats\u00e4chlich verwendeten Felder in eine eigene Tabelle schreibt, macht daraus: einen Tag lesen und danach etwas Kleines abfragen. Der t\u00e4gliche Lauf kostet, was ein Tag kostet; alles Nachgelagerte kostet einen Bruchteil des Bisherigen. Es ist derselbe Kniff wie eine materialisierte Sicht und lohnt sich, sobald eine Abfrage dreimal von Hand gelaufen ist.<\/p>\n
\n
Quellen<\/h2>\n