Zwei Analytics-Änderungen aus dem Juni, die ohne Fehlermeldung eintreffen

Im Juni 2026 sind zwei Änderungen im Google-Analytics-Stack wirksam geworden. Beide sind dokumentiert, beide gelten mit Stand 10.08.2026, und keine von beiden meldet sich, während eine Pipeline läuft. Die erste schränkt ein, was der BigQuery Data Transfer Service bei einem Backfill abruft. Die zweite schränkt ein, worüber die Einstellung Google Signals in der Analytics-Verwaltung tatsächlich bestimmt. Verbunden sind sie nicht über das Thema, sondern über 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ällt, dass ein Schalter nicht mehr die Wirkung hat, die er zuvor hatte.

1. Zwei Änderungen, die im Juni ohne Fehlermeldung wirksam wurden

Die meisten Änderungen in einem Datenstack melden sich von selbst. Ein Schema verschiebt sich, und eine Query schlägt fehl. Ein Endpunkt wird abgeschaltet, und ein Client liefert einen Statuscode. Ein Kontingent wird enger, und ein Job bleibt stehen. Solche Änderungen sind laut, und gerade der Lärm macht sie billig im Umgang: Das vorhandene Monitoring greift, und jemand liest die Meldung.

Die beiden Juni-Änderungen gehören in eine andere Kategorie. In beiden Fällen arbeitet das System weiter. Jobs laufen durch, Einstellungen lassen sich weiterhin umschalten, Dashboards werden weiterhin gerendert. Die Änderung zeigt sich allein im Inhalt der Daten oder in der Bedeutung eines Konfigurationswerts, und beides deckt das übliche Alerting nicht ab.

• BigQuery Data Transfer Service: seit dem 01.06.2026 füllen die Konnektoren für Google Ads, Search Ads 360 und Google Analytics 4 Backfill-Läufe nicht mehr mit Daten, die älter als 37 Monate sind. Die Dokumentation hält fest, dass solche Läufe unvollständige oder leere Ergebnisse zurückgeben und vorhandene vollständige Historie überschreiben können.
• Google Signals: ab dem 15.06.2026 steuern die Einstellung Google Signals in der Analytics-Verwaltung und die Google Signals API ausschließlich die Verknüpfung von Analytics-Daten mit Informationen aus angemeldeten Nutzerkonten für das Verhaltens-Reporting. Die Kontrolle über die Daten selbst liegt beim Consent Mode, konkret beim Parameter ad_storage.

Der weitere Text behandelt beide als zwei Ausprägungen desselben betrieblichen Problems: eine dokumentierte Änderung, deren Wirkung erst durch eine bewusste Prüfung sichtbar wird. Die Abschnitte 2 bis 4 behandeln die Transfergrenze und eine Absicherung, die sich einem Backfill vorschalten lässt. Die Abschnitte 5 und 6 behandeln die Signals-Änderung und eine Bestandsaufnahme, die den aktuellen Stand festhält, bevor er gebraucht wird.

2. Die 37-Monats-Grenze im BigQuery Data Transfer Service

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äufe dieser Konnektoren werden nicht mehr mit Daten befüllt, die älter als 37 Monate sind. Als Grund wird eine Änderung der Aufbewahrungsregeln auf der Seite von Google Ads genannt.

Für den Betrieb eines Warehouse, das auf diesen Transfers aufsetzt, sind zwei Abgrenzungen der Änderung wesentlich. Bereits übertragene Daten bleiben unangetastet – solange kein Backfill darüber läuft. 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ällt. Eine Backfill-Definition, die vor einem Jahr in einem Runbook abgelegt und seither nicht verändert wurde, überschreitet die Grenze daher irgendwann, ohne dass sich an der Definition selbst etwas ändert.

Mehrere Details deckt die Dokumentation nicht ab, und sie sollten auch nicht unterstellt werden. Nicht dokumentiert ist, welcher Fehlercode oder welche Meldung einen solchen Lauf begleitet, falls überhaupt eine ausgegeben wird. Nicht dokumentiert ist, ob die Cloud Console eine Warnung anzeigt, wenn ein Zeitraum jenseits der Grenze eingetragen wird. Nicht dokumentiert ist, ob sich der Vorgang nachträglich rückgängig machen lässt. Eine Absicherung lässt sich deshalb nicht auf ein Signal des Dienstes stützen; sie muss auf dem Zeitraum aufsetzen, der hineingeht, und auf den Zeilen, die herauskommen.

3. Warum ein Backfill vollständige Historie ersetzen kann

Der Kern dieser Änderung ist nicht die Grenze. Eine Begrenzung, wie weit ein Konnektor zurückreicht, wäre eine Unbequemlichkeit mit naheliegender Umgehung: das vorhandene Archiv behalten. Der Kern ist die zweite Hälfte des dokumentierten Verhaltens – ein Lauf, der unvollständige oder leere Ergebnisse zurückgibt, kann Historie überschreiben, die vollständig war.

Der Ablauf, der dorthin führt, ist gewöhnlich. Ein Warehouse hält vier Jahre Transferdaten. Eine späte Korrektur, eine Schemaanpassung oder eine vermutete Lücke gibt den Anlass, ein älteres Fenster erneut zu laden. Der Backfill wird mit einem Zeitraum geplant, der ganz oder teilweise weiter als 37 Monate zurückreicht. Der Lauf wird abgeschlossen. Die Partitionen innerhalb des Fensters werden mit dem überschrieben, was der Konnektor geliefert hat, und was der Konnektor für den Teil jenseits der Grenze geliefert hat, ist unvollständig oder leer. Nichts in dieser Kette setzt einen Fehler in der Anfrage selbst voraus; dieselbe Anfrage hätte im Mai funktioniert.

Darin unterscheidet sich ein erneuter Lauf von einer Erstbeladung. Eine Erstbeladung in einen leeren Zeitraum kann nur ergänzen. Ein erneuter Lauf über einen bestehenden Zeitraum ersetzt, und Ersetzen ist nur dann unbedenklich, wenn die Quelle mindestens so vollständig ist wie das Ziel. Seit dem 1. Juni gilt diese Annahme für die betroffenen Konnektoren jenseits der 37-Monats-Marke nicht mehr, womit aus einem Routinevorgang einer wird, an den eine Vorbedingung gehört.

Da die Dokumentation keinen Weg zur Rücknahme beschreibt, liegt die praktische Folge darin, dass die Prüfung vor dem Lauf stattfinden muss und eine Kopie vor dem Lauf vorliegen muss. Eine nachträgliche Wiederherstellung hängt vollständig davon ab, was das Warehouse selbst aufbewahrt hat.

4. Eine Absicherung vor dem Lauf: Grenze prüfen, Zeilen zählen, Kopie anlegen

Die Absicherung besteht aus drei Teilen, und jeder davon ist klein genug, um einem vorhandenen Backfill-Schritt vorangestellt zu werden. Alle im Folgenden großgeschriebenen Bezeichner sind Platzhalter für Projekt, Dataset, Tabelle und Datumsspalte des Warehouse, das der Lauf berührt; die Spaltennamen gibt der Dienst nicht vor, sie richten sich danach, was die Zieltabelle bereits verwendet.

Der erste Teil vergleicht den angefragten Zeitraum mit der rollierenden Grenze. Er beantwortet eine einzige Frage – fällt ein Teil dieses Fensters jenseits von 37 Monaten – und beantwortet sie aus dem Kalender heraus, nicht aus einer Antwort, die der Dienst senden mag oder auch nicht.

-- PROJECT, DATASET, TARGET_TABLE und PARTITION_DATE sind Platzhalter.
DECLARE backfill_start DATE DEFAULT DATE '2022-01-01';
DECLARE backfill_end   DATE DEFAULT DATE '2022-06-30';
DECLARE earliest_supported DATE DEFAULT DATE_SUB(CURRENT_DATE(), INTERVAL 37 MONTH);

SELECT
  backfill_start,
  backfill_end,
  earliest_supported,
  backfill_start < earliest_supported AS starts_before_boundary,
  backfill_end   < earliest_supported AS ends_before_boundary,
  DATE_DIFF(earliest_supported, backfill_start, DAY) AS days_outside;

Derselbe Vergleich gehört in den Wrapper, der den Lauf auslöst, damit ein Fenster außerhalb der Grenze den Job anhält und nicht nur eine Zeile in einer Ergebnismenge erzeugt. Ein Gate in der Shell hält die Entscheidung beim Scheduler statt im Warehouse.

#!/usr/bin/env bash
set -euo pipefail

START="2022-01-01"
END="2022-06-30"
BOUNDARY="$(date -u -d '37 months ago' +%F)"

if [[ "$START" < "$BOUNDARY" ]]; then
  echo "range starts $START, boundary is $BOUNDARY - backfill not started" >&2
  exit 1
fi

# wird nur erreicht, wenn das gesamte Fenster innerhalb der Grenze liegt
# ./run_backfill.sh "$START" "$END"

Der zweite Teil ist eine Zeilenzählung je Tag, einmal vor dem Lauf und einmal danach erhoben. Diese Zählung ist von keiner Meldung des Dienstes abhängig und macht eine Ersetzung durch leere Ergebnisse als Zahl sichtbar statt als Vermutung. Werden beide Phasen in derselben Audit-Tabelle abgelegt, bleibt der Vergleich eine einzige Query.

CREATE TABLE IF NOT EXISTS `PROJECT.audit.transfer_row_census` (
  captured_at TIMESTAMP,
  phase STRING,
  day DATE,
  row_count INT64
);

INSERT INTO `PROJECT.audit.transfer_row_census`
SELECT CURRENT_TIMESTAMP(), 'before', PARTITION_DATE, COUNT(*)
FROM `PROJECT.DATASET.TARGET_TABLE`
WHERE PARTITION_DATE BETWEEN DATE '2022-01-01' AND DATE '2022-06-30'
GROUP BY PARTITION_DATE;

-- nach dem Lauf dieselbe Anweisung mit phase = 'after', danach:
SELECT
  b.day,
  b.row_count AS rows_before,
  IFNULL(a.row_count, 0) AS rows_after,
  IFNULL(a.row_count, 0) - b.row_count AS delta
FROM `PROJECT.audit.transfer_row_census` b
LEFT JOIN `PROJECT.audit.transfer_row_census` a
  ON a.day = b.day AND a.phase = 'after'
WHERE b.phase = 'before'
  AND IFNULL(a.row_count, 0) < b.row_count
ORDER BY delta;

Der dritte Teil ist die Kopie. Da die Dokumentation nichts über die Rücknahme eines solchen Laufs sagt, führt der einzig verlässliche Weg zurück über eine Kopie des betroffenen Zeitraums, die angelegt wurde, solange er noch vollständig war. Eine Snapshot-Tabelle, benannt nach dem Lauf und dem Datum des Laufs, genügt, und sie kann verworfen werden, sobald die Zählung kein negatives Delta zeigt.

CREATE TABLE `PROJECT.DATASET.TARGET_TABLE__pre_backfill_20260810` AS
SELECT *
FROM `PROJECT.DATASET.TARGET_TABLE`
WHERE PARTITION_DATE BETWEEN DATE '2022-01-01' AND DATE '2022-06-30';

Drei Schritte, alle auf der Seite des Warehouse, keiner davon abhängig von einem Signal, dessen Versand für den Dienst nicht dokumentiert ist. Den Wert trägt die Reihenfolge: Grenzprüfung, Zählung, Kopie, dann der Lauf.

5. Google Signals steuert seit dem 15. Juni weniger

Die zweite Änderung ist im Code kleiner und in der Auslegung größer. Ab dem 15.06.2026 bestimmen die Einstellung Google Signals in der Analytics-Verwaltung und die Google Signals API nur noch über eines: ob Analytics-Daten mit Informationen aus angemeldeten Nutzerkonten für das Verhaltens-Reporting verknüpft werden. Die Kontrolle über die Daten selbst liegt nun beim Consent Mode, konkret beim Parameter ad_storage. Die Beschreibung findet sich auf der Google-Analytics-Hilfeseite 17016975, abgerufen am 10.08.2026.

Die betriebliche Folge ist eine Verschiebung darin, welche Oberfläche welche Frage beantwortet. Eine Frage nach der Verknüpfung mit angemeldeten Nutzerkonten im Verhaltens-Reporting beantwortet die Signals-Einstellung. Eine Frage nach den zugrunde liegenden Daten beantwortet die Consent-Konfiguration auf der Erfassungsseite. Ein Konfigurationsdokument, eine interne Wiki-Seite oder eine Beschreibung für Kunden, die vor dem 15. Juni verfasst wurde, kann den Signals-Schalter weiterhin als zuständig für die zweite Frage darstellen, und nichts in der Oberfläche kennzeichnet eine solche Beschreibung als überholt.

Mehreres an dieser Änderung ist nicht dokumentiert und sollte eher als offen benannt als geschätzt werden. Die Hilfeseite trägt kein Veröffentlichungsdatum, weshalb sich der genaue Zeitpunkt der Überarbeitung nicht aus der Seite selbst ablesen lässt. Die Seite nennt keine Volumeneffekte, weshalb jede Aussage darüber, wie sich Reporting-Zahlen bewegen, von der Quelle nicht gedeckt ist. Und sie sagt nichts zu bestehenden Audiences, weshalb dort auch der Status von Audiences offenbleibt, die entstanden sind, als die Einstellung einen weiteren Geltungsbereich hatte. Jeder dieser Punkte ist eine Frage an die jeweiligen Properties und keine, die die Dokumentation beantwortet.

6. Eine Bestandsaufnahme je Property, und was offenbleibt

Ohne den dokumentierten Boden zu verlassen, bleibt eine Bestandsaufnahme: den aktuellen Signals-Stand je Property festhalten, den Nachweis aufbewahren und die ad_storage-Consent-Raten getrennt davon im Reporting prüfen. Daraus entsteht eine datierte Ausgangslage, und genau die braucht jede spätere Frage nach einem Unterschied.

Die Google Signals API wird in der Dokumentation als eine der beiden Steuerungsoberflächen genannt, doch Endpunktnamen, Request-Felder oder Response-Schemata sind hier nicht belegt. Das folgende Skript hält den API-Aufruf daher hinter einer Platzhalterfunktion, die anhand der API-Referenz der eingesetzten Client-Bibliothek zu ergänzen ist; ausgeschrieben ist der Teil, der die Persistenz und den Abgleich übernimmt, und dort liegt der Wert der Bestandsaufnahme.

import csv
import datetime

# Platzhalter: umgesetzt gegen die Google Signals API mit der
# eingesetzten Client-Bibliothek. Gibt das Statusfeld zurueck, das die API bereitstellt.
def fetch_signals_state(property_id: str):
    raise NotImplementedError("fill in against the API reference")

PROPERTIES = ["PROPERTY_ID_1", "PROPERTY_ID_2"]   # Platzhalter
OUT = "signals_inventory.csv"

captured_at = datetime.datetime.now(datetime.timezone.utc).isoformat()

with open(OUT, "a", newline="", encoding="utf-8") as fh:
    writer = csv.writer(fh)
    for property_id in PROPERTIES:
        try:
            state = fetch_signals_state(property_id)
            writer.writerow([captured_at, property_id, state, ""])
        except Exception as exc:                  # protokolliert, nicht verschluckt
            writer.writerow([captured_at, property_id, "", repr(exc)])

Die zweite Hälfte der Bestandsaufnahme ist die Consent-Seite. Wie der ad_storage-Status gespeichert wird, unterscheidet sich je nach Setup – er kann in einer Export-Tabelle liegen, in einem Log auf der Erfassungsseite oder in einer Tabelle, die die Consent-Plattform pflegt –, weshalb die Tabellen- und Spaltennamen unten Platzhalter für das sind, was das Warehouse bereits vorhält. Die Query liefert eine Tagesrate, und in dieser Form wäre eine Verschiebung über die Juni-Grenze hinweg überhaupt ablesbar.

-- CONSENT_TABLE, DAY_COLUMN und AD_STORAGE_COLUMN sind Platzhalter
-- fuer die Spalten, in denen das Warehouse den Consent-Status festhaelt.
SELECT
  DAY_COLUMN AS day,
  COUNTIF(AD_STORAGE_COLUMN = 'granted') AS granted,
  COUNT(*) AS total,
  SAFE_DIVIDE(COUNTIF(AD_STORAGE_COLUMN = 'granted'), COUNT(*)) AS granted_rate
FROM `PROJECT.DATASET.CONSENT_TABLE`
WHERE DAY_COLUMN BETWEEN DATE '2026-05-01' AND CURRENT_DATE()
GROUP BY day
ORDER BY day;

Was die Bestandsaufnahme nicht liefert, ist eine Erklärung. Eine Rate, die sich über den Juni hinweg bewegt, kann auf die Consent-Konfiguration zurückgehen, auf Saisonalität, auf die Zusammensetzung des Traffics oder auf ein Release auf der Website. Die Dokumentation nennt keine Volumeneffekte, weshalb es über die Quelle hinausginge, eine Bewegung der Signals-Änderung zuzuschreiben. Der Zweck des Nachweises ist enger und dauerhafter: Er hält je Property einen datierten Stand fest und trennt die Frage, worüber eine Einstellung bestimmt, von der Frage, was die Daten zeigen.

Zusammenfassung

• Transfergrenze: seit dem 01.06.2026 befüllen die Konnektoren des BigQuery Data Transfer Service für Google Ads, Search Ads 360 und Google Analytics 4 Backfill-Läufe nicht mehr mit Daten, die älter als 37 Monate sind. Als Grund werden geänderte Aufbewahrungsregeln bei Google Ads genannt.
• Der folgenreiche Teil: Die Dokumentation hält fest, dass solche Läufe unvollständige oder leere Ergebnisse zurückgeben und vorhandene vollständige Historie überschreiben können. Bereits übertragene Daten bleiben unangetastet, solange kein Backfill darüber läuft.
• Nicht dokumentiert: welcher Fehlercode oder welche Meldung erscheint, ob die Oberfläche warnt und ob sich der Vorgang rückgängig machen lässt. Eine Absicherung stützt sich deshalb auf den angefragten Zeitraum, eine Zeilenzählung vor und nach dem Lauf sowie eine zuvor angelegte Kopie.
• Geltungsbereich von Signals: ab dem 15.06.2026 steuern die Signals-Einstellung und die Google Signals API nur noch die Verknüpfung von Analytics-Daten mit Informationen aus angemeldeten Nutzerkonten für das Verhaltens-Reporting; die Kontrolle über die Daten selbst liegt beim Consent Mode und bei ad_storage.
• Offen auf dieser Seite: Die Hilfeseite trägt kein Veröffentlichungsdatum, nennt keine Volumeneffekte und sagt nichts zu bestehenden Audiences. Eine datierte Bestandsaufnahme je Property hält den Stand fest; sie erklärt keine Bewegungen in den Zahlen.

Beide Änderungen waren dokumentiert, bevor sie wirksam wurden, und beide bleiben im Tagesbetrieb unsichtbar, bis eine bestimmte Handlung oder eine bestimmte Frage sie an die Oberfläche bringt. Der praktische Unterschied liegt im Zeitpunkt, an dem sich eine Prüfung auszahlt: bei der Transfergrenze ist es der Moment vor dem Start eines Backfills, bei Google Signals der Moment, in dem eine Konfigurationsbeschreibung niedergeschrieben und datiert wird.