Seit dem 15. Juni entscheidet ein einziges Signal darüber, was Google Ads aus deinem Analytics bekommt.

Was Google am 15. Juni 2026 umgestellt hat

Google hat die Datenkontrollen in Analytics zusammengelegt. Die Ankündigung in der Analytics-Hilfe beschreibt den Wechsel in zwei Sätzen, deren Tragweite man leicht überliest.

Vorher wurde die Erhebung von Google-Ads-Cookies und -IDs durch das Analytics-Tag und das SDK von zwei Einstellungen gemeinsam gesteuert: dem Google-Signals-Schalter in der Analytics-Verwaltung und den Consent-Einstellungen für Anzeigen. Zwei Schalter, beide mussten offen sein.

Seit dem 15. Juni 2026 steuert der Google-Signals-Schalter in der Verwaltung und die zugehörige API laut Google nur noch, ob Analytics-Daten mit Informationen angemeldeter Nutzer verknüpft werden, und zwar für die verhaltensbezogene Berichterstattung innerhalb von Analytics. Über den Datenfluss zu Google Ads entscheidet er nicht mehr.

Das ist keine Abschaffung von Google Signals. Der Schalter existiert weiter und hat weiter eine Funktion. Er hat nur eine andere Funktion als vorher, und die Funktion, die er verloren hat, war die, auf die sich viele Setups unbewusst verlassen haben.

Warum zwei Bremsen etwas anderes sind als eine

In der Theorie waren die beiden Einstellungen redundant. Wer das Consent-Signal korrekt setzt, braucht keinen zweiten Schalter, um denselben Datenfluss zu unterbinden. In der Praxis war die Redundanz der Grund, warum viele Implementierungen funktionierten, obwohl sie ungenau waren.

Ein typischer Fall aus der Prüfpraxis: Ein Consent-Banner setzt bei Ablehnung zwar analytics_storage auf denied, lässt ad_storage aber auf granted, weil die Kategorie im Banner anders geschnitten ist als die Signale im Tag. Das ist ein Konfigurationsfehler, aber solange der Google-Signals-Schalter aus war, blieb er ohne sichtbare Folge für den Datenfluss zu Ads. Der Fehler war da, die Wirkung nicht.

Der umgekehrte Fall ist genauso häufig: Ein Team schaltet Google Signals bewusst ab, weil eine Datenschutzprüfung das so entschieden hat, und betrachtet die Sache damit als erledigt. Das Consent-Signal wurde nie im Detail geprüft, weil der Schalter ja aus war.

Beide Setups verhalten sich seit dem 15. Juni anders als vorher. Nicht weil jemand etwas falsch gemacht hat, sondern weil die zweite Bremse weg ist.

Was sich messtechnisch ändert

Die ehrliche Antwort lautet: das hängt von deinem Ausgangszustand ab, und genau deshalb ist es prüfenswert statt vorhersagbar.

Fall A, Consent sauber und Signals war an. Hier ändert sich am Datenfluss wenig. Das Consent-Signal entschied vorher mit und entscheidet jetzt allein. Was sich ändert, ist die Berichterstattung innerhalb von Analytics zu angemeldeten Nutzern, denn dafür ist der Schalter weiter zuständig.

Fall B, Consent sauber und Signals war aus. Der Schalter blockierte vorher zusätzlich, was das Consent-Signal ohnehin blockierte. Jetzt fällt die zusätzliche Blockade weg. Wenn das Consent-Signal wirklich sauber war, bleibt der Datenfluss unverändert. Der Test dafür ist keine Vermutung, sondern eine Messung.

Fall C, Consent ungenau und Signals war aus. Das ist der Fall, der Aufmerksamkeit verdient. Vorher hat der Schalter die Ungenauigkeit im Consent-Signal aufgefangen. Jetzt wirkt sie unmittelbar. Je nachdem, in welche Richtung die Ungenauigkeit geht, fließen entweder mehr Daten als beabsichtigt oder weniger als für die Kampagnensteuerung nötig.

Fall C ist deshalb heikel, weil er in keiner Oberfläche als Fehler auftaucht. Google Ads meldet keinen Konfigurationsfehler, Analytics zeigt keine Warnung, das Banner meldet Vollzug. Sichtbar wird die Sache erst an einer Kennzahl, die sich seit Mitte Juni anders verhält als davor, und dann meist mit Verzögerung und ohne offensichtlichen Zusammenhang.

Der Prüfweg, der belastbar ist

Die Frage lautet nicht “haben wir Consent Mode?”, sondern “welche Werte stehen zum Zeitpunkt des Tag-Feuerns tatsächlich in den vier Consent-Parametern, getrennt nach Zustimmung, Ablehnung und Erstaufruf?”. Das ist eine Messung, keine Einschätzung.

Ein Weg, der in der Praxis trägt:

1. Drei Zustände definieren. Erstaufruf ohne Entscheidung, vollständige Zustimmung, vollständige Ablehnung. Bei granularen Bannern zusätzlich jede Kombination, die dein Banner überhaupt erzeugen kann.
2. Je Zustand die tatsächlichen Consent-Werte aufzeichnen, nicht die im Banner konfigurierten. Der Unterschied zwischen beidem ist genau das, was Fall C erzeugt.
3. Je Zustand prüfen, welche Anfragen tatsächlich rausgehen und mit welchen Parametern. Ein Tag, das feuert, ist nicht dasselbe wie ein Tag, das Daten überträgt.
4. Den Zustand vor und nach dem 15. Juni vergleichen, soweit historische Daten das hergeben. Ein Bruch in einer Kennzahl um dieses Datum herum ist ein Hinweis, kein Beweis, aber ein guter Startpunkt.

Schritt zwei ist der, den die meisten überspringen, und der einzige, der Fall C sichtbar macht. Die Konfiguration im Banner beschreibt die Absicht. Die Werte im dataLayer beschreiben, was passiert.

Warum das Muster wichtiger ist als der Einzelfall

Diese Umstellung ist für sich genommen überschaubar. Interessant ist sie als Beispiel für eine Kategorie von Risiko, die in Messsystemen systematisch unterschätzt wird: die stille Abhängigkeit von einer Einstellung, die niemand als tragend eingeplant hat.

Niemand hat je entschieden, den Google-Signals-Schalter als Sicherheitsnetz für ein ungenaues Consent-Signal einzusetzen. Es hat sich so ergeben, weil zwei Kontrollen dasselbe blockierten und man deshalb nur eine davon pflegen musste, ohne es zu merken. Genau solche Abhängigkeiten überleben Anbieteränderungen nicht, und sie brechen ohne Fehlermeldung, weil aus Sicht des Systems nichts kaputt ist.

Unser Research-Report zur Messzuverlässigkeit ordnet genau diesen Fall ein: Er unterscheidet zwischen Ereignissen, die beobachtet wurden, solchen, die nachträglich korrigiert werden können, und solchen, die eine Plattform lediglich modelliert. Eine stille Änderung an einer Consent-Kontrolle verschiebt Volumen zwischen diesen Klassen, ohne dass eine einzige Zahl im Bericht rot wird.

Die praktische Konsequenz ist unbequem, aber schlicht. Wenn eine Einstellung für dich wichtig ist, muss sie geprüft und dokumentiert sein, und zwar dort, wo sie wirkt. Auf eine zweite Kontrolle zu bauen, die zufällig dasselbe tut, ist kein Setup, sondern ein Zufall mit Ablaufdatum.

Was jetzt konkret zu tun ist

Für die meisten Setups ist das eine Aufgabe von wenigen Stunden, nicht von Wochen.

• Die vier Consent-Parameter je Zustand aufzeichnen und mit dem vergleichen, was das Banner konfiguriert. Abweichungen sind der eigentliche Befund.
• Prüfen, ob irgendwo im Team dokumentiert ist, dass Google Signals bewusst abgeschaltet wurde, und aus welchem Grund. Wenn der Grund der Datenfluss zu Ads war, ist der Grund seit dem 15. Juni nicht mehr adressiert.
• Kennzahlen um den 15. Juni auf Brüche prüfen, insbesondere Conversion-Zahlen in Google Ads gegenüber der Quelle im Shop oder CRM.
• Den Prüfweg festhalten, nicht nur das Ergebnis. Die nächste Anbieteränderung kommt, und dann ist ein dokumentierter Prüfweg der Unterschied zwischen einer Stunde Arbeit und einer Woche Rekonstruktion.

Wer den Abgleich zwischen gemessenen und tatsächlichen Käufen ohnehin nie sauber aufgesetzt hat, findet im Rechner zur Tracking-Abdeckung einen nüchternen Einstieg. Er zeigt eine Messlücke, keinen nachgewiesenen Umsatzverlust, und genau diese Unterscheidung ist der Punkt.

Das eigentliche Argument

Es geht bei dieser Umstellung nicht darum, ob Google eine gute oder schlechte Entscheidung getroffen hat. Die Zusammenlegung der Kontrollen ist nachvollziehbar, und ein einziger Ort für eine Entscheidung ist am Ende sauberer als zwei.

Es geht darum, dass dein Messsystem gerade sein Verhalten geändert hat, ohne dass du etwas getan hast, und dass die Änderung an keiner Stelle sichtbar wird, wenn du nicht danach suchst. Diese Eigenschaft haben alle Systeme, die dir nicht gehören und deren Regeln jemand anderes schreibt.

Das ist kein Argument gegen Google Analytics. Es ist ein Argument dafür, die Ereignisse, auf denen deine Entscheidungen beruhen, zusätzlich an einem Ort zu führen, an dem sich die Regeln nur ändern, wenn du sie änderst. Wie eine solche Server-Side-Architektur aussieht und was sie realistisch leistet, haben wir an anderer Stelle mit offenen Annahmen durchgerechnet.