{"id":9402,"date":"2026-08-12T19:00:00","date_gmt":"2026-08-12T17:00:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=9402"},"modified":"2026-10-09T22:41:28","modified_gmt":"2026-10-09T20:41:28","slug":"bigquery-backfill-grenze-und-google-signals-reichweite-zwei-ga4-anderungen","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/digital-analytics-de\/bigquery-backfill-grenze-und-google-signals-reichweite-zwei-ga4-anderungen\/","title":{"rendered":"BigQuery-Backfill-Grenze und Google-Signals-Reichweite: Zwei GA4-\u00c4nderungen aus dem Juni 2026"},"content":{"rendered":"\n
Im Juni 2026 sind zwei \u00c4nderungen im Google-Analytics-Stack wirksam geworden. Beide sind dokumentiert, beide gelten mit Stand 10.08.2026, und keine von beiden meldet sich, w\u00e4hrend eine Pipeline l\u00e4uft. Die erste schr\u00e4nkt ein, was der BigQuery Data Transfer Service bei einem Backfill abruft. Die zweite schr\u00e4nkt ein, wor\u00fcber die Einstellung Google Signals in der Analytics-Verwaltung tats\u00e4chlich bestimmt. Verbunden sind sie nicht \u00fcber das Thema, sondern \u00fcber die Art ihres Auftretens: kein fehlgeschlagener Job, keine Exception im Log, keine Zeile in einem Monitoring-Dashboard. Die erste zeigt sich, sobald ein Backfill gestartet wird. Die zweite zeigt sich, sobald auff\u00e4llt, dass ein Schalter nicht mehr die Wirkung hat, die er zuvor hatte.<\/p>\n\n\n\n
1. Zwei \u00c4nderungen, die im Juni ohne Fehlermeldung wirksam wurden<\/h2>\n\n\n\n
Die meisten \u00c4nderungen in einem Datenstack melden sich von selbst. Ein Schema verschiebt sich, und eine Query schl\u00e4gt fehl. Ein Endpunkt wird abgeschaltet, und ein Client liefert einen Statuscode. Ein Kontingent wird enger, und ein Job bleibt stehen. Solche \u00c4nderungen sind laut, und gerade der L\u00e4rm macht sie billig im Umgang: Das vorhandene Monitoring greift, und jemand liest die Meldung.<\/p>\n\n\n\n
Die beiden Juni-\u00c4nderungen geh\u00f6ren in eine andere Kategorie. In beiden F\u00e4llen arbeitet das System weiter. Jobs laufen durch, Einstellungen lassen sich weiterhin umschalten, Dashboards werden weiterhin gerendert. Die \u00c4nderung zeigt sich allein im Inhalt der Daten oder in der Bedeutung eines Konfigurationswerts, und beides deckt das \u00fcbliche Alerting nicht ab.<\/p>\n\n\n\n
\n
BigQuery Data Transfer Service:<\/strong> seit dem 01.06.2026 f\u00fcllen die Konnektoren f\u00fcr Google Ads, Search Ads 360 und Google Analytics 4 Backfill-L\u00e4ufe nicht mehr mit Daten, die \u00e4lter als 37 Monate sind. Die Dokumentation h\u00e4lt fest, dass solche L\u00e4ufe unvollst\u00e4ndige oder leere Ergebnisse zur\u00fcckgeben und vorhandene vollst\u00e4ndige Historie \u00fcberschreiben k\u00f6nnen.<\/li>\n
Google Signals:<\/strong> ab dem 15.06.2026 steuern die Einstellung Google Signals in der Analytics-Verwaltung und die Google Signals API ausschlie\u00dflich die Verkn\u00fcpfung von Analytics-Daten mit Informationen aus angemeldeten Nutzerkonten f\u00fcr das Verhaltens-Reporting. Die Kontrolle \u00fcber die Daten selbst liegt beim Consent Mode, konkret beim Parameter ad_storage<\/code>.<\/li>\n<\/ul>\n\n\n\n
Der weitere Text behandelt beide als zwei Auspr\u00e4gungen desselben betrieblichen Problems: eine dokumentierte \u00c4nderung, deren Wirkung erst durch eine bewusste Pr\u00fcfung sichtbar wird. Die Abschnitte 2 bis 4 behandeln die Transfergrenze und eine Absicherung, die sich einem Backfill vorschalten l\u00e4sst. Die Abschnitte 5 und 6 behandeln die Signals-\u00c4nderung und eine Bestandsaufnahme, die den aktuellen Stand festh\u00e4lt, bevor er gebraucht wird.<\/p>\n\n\n\n
2. Die 37-Monats-Grenze im BigQuery Data Transfer Service<\/h2>\n\n\n\n
Der Eintrag erschien am 06.05.2026 in den BigQuery Release Notes und wurde am 01.06.2026 wirksam. Er betrifft drei Konnektoren des BigQuery Data Transfer Service: Google Ads, Search Ads 360 und Google Analytics 4. Backfill-L\u00e4ufe dieser Konnektoren werden nicht mehr mit Daten bef\u00fcllt, die \u00e4lter als 37 Monate sind. Als Grund wird eine \u00c4nderung der Aufbewahrungsregeln auf der Seite von Google Ads genannt.<\/p>\n\n\n\n
F\u00fcr den Betrieb eines Warehouse, das auf diesen Transfers aufsetzt, sind zwei Abgrenzungen der \u00c4nderung wesentlich. Bereits \u00fcbertragene Daten bleiben unangetastet \u2013 solange kein Backfill dar\u00fcber l\u00e4uft. Die 37 Monate sind ein rollierendes Fenster und kein fester Stichtag, weshalb ein Zeitraum, der im Juni noch innerhalb der Grenze lag, mit den vergehenden Monaten aus ihr herausf\u00e4llt. Eine Backfill-Definition, die vor einem Jahr in einem Runbook abgelegt und seither nicht ver\u00e4ndert wurde, \u00fcberschreitet die Grenze daher irgendwann, ohne dass sich an der Definition selbst etwas \u00e4ndert.<\/p>\n\n\n\n
Die Dokumentation l\u00e4sst mehrere Fragen offen: Gibt ein solcher Lauf einen Fehlercode oder eine Meldung aus? Warnt die Cloud Console bei einem Zeitraum jenseits der Grenze? L\u00e4sst sich der Vorgang nachtr\u00e4glich r\u00fcckg\u00e4ngig machen? Keine dieser Verhaltensweisen sollte vorausgesetzt werden. Die Absicherung muss deshalb den angefragten Zeitraum und die zur\u00fcckgegebenen Zeilen pr\u00fcfen, statt sich auf ein nicht dokumentiertes Signal des Dienstes zu verlassen.<\/p>\n\n\n\n
3. Warum ein Backfill vollst\u00e4ndige Historie ersetzen kann<\/h2>\n\n\n\n
Der Kern dieser \u00c4nderung ist nicht die Grenze. Eine Begrenzung, wie weit ein Konnektor zur\u00fcckreicht, w\u00e4re eine Unbequemlichkeit mit naheliegender Umgehung: das vorhandene Archiv behalten. Der Kern ist die zweite H\u00e4lfte des dokumentierten Verhaltens \u2013 ein Lauf, der unvollst\u00e4ndige oder leere Ergebnisse zur\u00fcckgibt, kann Historie \u00fcberschreiben, die vollst\u00e4ndig war.<\/p>\n\n\n\n
Der Ablauf, der dorthin f\u00fchrt, ist gew\u00f6hnlich. Ein Warehouse h\u00e4lt vier Jahre Transferdaten. Eine sp\u00e4te Korrektur, eine Schemaanpassung oder eine vermutete L\u00fccke gibt den Anlass, ein \u00e4lteres Fenster erneut zu laden. Der Backfill wird mit einem Zeitraum geplant, der ganz oder teilweise weiter als 37 Monate zur\u00fcckreicht. Der Lauf wird abgeschlossen. Die Partitionen innerhalb des Fensters werden mit dem \u00fcberschrieben, was der Konnektor geliefert hat, und was der Konnektor f\u00fcr den Teil jenseits der Grenze geliefert hat, ist unvollst\u00e4ndig oder leer. Nichts in dieser Kette setzt einen Fehler in der Anfrage selbst voraus; dieselbe Anfrage h\u00e4tte im Mai funktioniert.<\/p>\n\n\n\n
Darin unterscheidet sich ein erneuter Lauf von einer Erstbeladung. Eine Erstbeladung in einen leeren Zeitraum kann nur erg\u00e4nzen. Ein erneuter Lauf \u00fcber einen bestehenden Zeitraum ersetzt, und Ersetzen ist nur dann unbedenklich, wenn die Quelle mindestens so vollst\u00e4ndig ist wie das Ziel. Seit dem 1. Juni gilt diese Annahme f\u00fcr die betroffenen Konnektoren jenseits der 37-Monats-Marke nicht mehr, womit aus einem Routinevorgang einer wird, an den eine Vorbedingung geh\u00f6rt.<\/p>\n\n\n\n
Da die Dokumentation keinen Weg zur R\u00fccknahme beschreibt, liegt die praktische Folge darin, dass die Pr\u00fcfung vor dem Lauf stattfinden muss und eine Kopie vor dem Lauf vorliegen muss. Eine nachtr\u00e4gliche Wiederherstellung h\u00e4ngt vollst\u00e4ndig davon ab, was das Warehouse selbst aufbewahrt hat.<\/p>\n\n\n\n\n\nDie Grenze verhindert den Lauf nicht, sie \u00e4ndert, was der Lauf schreibt. Alles links davon kommt unvollst\u00e4ndig oder leer zur\u00fcck \u2014 und landet in denselben Zeilen, in denen zuvor die vollst\u00e4ndige Historie stand.<\/figcaption>\n<\/figure>\n\n\n\n
4. Eine Absicherung vor dem Lauf: Grenze pr\u00fcfen, Zeilen z\u00e4hlen, Kopie anlegen<\/h2>\n\n\n\n
Die Absicherung besteht aus drei Teilen, und jeder davon ist klein genug, um einem vorhandenen Backfill-Schritt vorangestellt zu werden. Alle im Folgenden gro\u00dfgeschriebenen Bezeichner sind Platzhalter f\u00fcr Projekt, Dataset, Tabelle und Datumsspalte des Warehouse, das der Lauf ber\u00fchrt; die Spaltennamen gibt der Dienst nicht vor, sie richten sich danach, was die Zieltabelle bereits verwendet.<\/p>\n\n\n\n
Der erste Teil vergleicht den angefragten Zeitraum mit der rollierenden Grenze. Er beantwortet eine einzige Frage \u2013 f\u00e4llt ein Teil dieses Fensters jenseits von 37 Monaten \u2013 und beantwortet sie aus dem Kalender heraus, nicht aus einer Antwort, die der Dienst senden mag oder auch nicht.<\/p>\n\n\nSQL<\/span>
![\"Dieselbe](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/hand-backfill-de.png\")
\n