Inhalt
-
- Wichtig: Mails von Google zur gtm.js-/gtag.js-Umstellung
- GA4: Flexible Conversion Lookback Windows
- GA4: Neuer Validierungsbericht für importierte Kampagnendaten
- GTM: Vereinheitlichung von Google Tag und GTM wird ausgerollt
- BigQuery: Monitoring für Data Agents mit Google Cloud Observability (Preview)
- BigQuery Graph: Core Graph Processing künftig nur noch für Enterprise Editions
- BigQuery: MCP-Server übernimmt weitere operative Aufgaben (Preview)
- BigQuery: Neue Funktionen für Time-Series-Analysen (Preview)
- BigQuery Pipelines: AI-gestütztes Metadata Enrichment (Preview)
- Wichtig: Mails von Google zur gtm.js-/gtag.js-Umstellung

Liebe Leser,
im August sorgt aktuell eine Mail von Google zur bevorstehenden gtm.js-/gtag.js-Umstellung für einige Verunsicherung. Was genau dahintersteckt und wer tatsächlich handeln muss, haben wir für Sie zum Einstieg eingeordnet.
Darüber hinaus gibt es neue Entwicklungen in GA4 und BigQuery: GA4 bietet mehr Flexibilität bei der Attribution und eine bessere Kontrolle über importierte Kampagnendaten. In BigQuery schreitet vor allem die Integration von AI und Agents weiter voran, vom Monitoring über operative MCP-Funktionen bis hin zu neuen Möglichkeiten für Time-Series-Analysen und Metadata Enrichment.
Viel Spaß beim Lesen!
1. Wichtig: Mails von Google zur gtm.js-/gtag.js-Umstellung
Google informiert derzeit Website-Betreiber per E-Mail über eine bevorstehende Änderung beim Laden von Google Tags über gtm.js. Die Formulierung der Nachricht kann allerdings den Eindruck vermitteln, dass grundsätzlich von Google Tag Manager auf gtag.js umgestellt werden muss. Das ist nicht der Fall: Entscheidend ist die konkrete Implementierung.
Worum es geht:
Ab dem 2. Oktober 2026 standardisiert Google das Verhalten seiner Tagging-Snippets. gtm.js-Snippets werden dann bereits beim Laden des Containers initialisiert – unabhängig davon, ob anschließend ein gtag(‚config‘)-Befehl ausgeführt wird. Google stellt damit insbesondere die bisherige Nutzung von Google-Tag-IDs wie G-, AW- oder DC- über den gtm.js-Pfad um. Wer den gtag-Konfigurationscode direkt im Quellcode verwendet, sollte deshalb sicherstellen, dass dafür das vorgesehene gtag.js-Snippet verwendet wird. Die von Google versendeten Hinweise nennen konkret erkannte Implementierungen und fordern gegebenenfalls eine Anpassung auf.
Unsere Einordnung:
Die E-Mail bedeutet nicht automatisch, dass eine reguläre Google-Tag-Manager-Implementierung mit einem GTM-Container angepasst werden muss. Wird das Tracking zentral und standardkonform über einen GTM-Container umgesetzt und werden die entsprechenden Google Tags innerhalb dieses Containers konfiguriert, ist die grundsätzliche Nutzung des Google Tag Managers weiterhin vorgesehen. Handlungsbedarf besteht vor allem bei Implementierungen, bei denen Google-Tag-IDs außerhalb des vorgesehenen Setups über gtm.js geladen werden oder gtm.js und gtag(‚config‘) miteinander kombiniert werden.
So sollten Sie jetzt handeln:
Wer eine entsprechende Google-Mail erhalten hat, sollte daher zunächst die konkrete Implementierung prüfen, anstatt vorschnell das bestehende Tracking umzubauen. Die Setups unserer Kunden prüfen wir bereits proaktiv auf möglichen Handlungsbedarf. Sollten Sie als Leser des MarTechBriefings eine solche Nachricht von Google erhalten haben und unsicher sein, ob Ihr Setup von der Änderung betroffen ist, sprechen Sie uns jederzeit gerne an. Wir unterstützen Sie bei der Einordnung und prüfen gemeinsam, ob und welche Anpassungen erforderlich sind.
Quelle: Offizielles Mailing von Google
2. GA4: Flexible Conversion Lookback Windows
Bei der Attribution von Conversions bietet Google Analytics 4 (GA4) künftig deutlich mehr Spielraum. Die Lookback Windows für Click-through- und Engaged-view-Conversions lassen sich nun individuell an unterschiedliche Customer Journeys und Geschäftsmodelle anpassen.
Für Click-through Conversions (CTC) kann das Lookback Window jetzt auf einen beliebigen ganzzahligen Wert zwischen 1 und 90 Tagen gesetzt werden. Zuvor standen lediglich 1, 7, 14, 30, 60 oder 90 Tage zur Auswahl. Bei Engaged-View-Conversions (EVC) fällt die bisher feste Vorgabe von drei Tagen weg. Hier können nun individuell 1 bis 30 Tage festgelegt werden. Die Einstellungen lassen sich sowohl in Google Analytics unter Advertising > Conversion management > Settings als auch über das Conversion Management des verknüpften Google-Ads-Kontos verwalten.
Warum ist das relevant?
Ein einheitliches Lookback Window passt nicht zu jedem Conversion-Zyklus. Unternehmen mit kurzen Kaufentscheidungen können den Betrachtungszeitraum gezielter begrenzen, während längere Customer Journeys entsprechend berücksichtigt werden können. Dadurch lässt sich die Attribution stärker am tatsächlichen Geschäftsmodell ausrichten. Da die Einstellungen auch für mit Google Ads geteilte Conversions relevant sein können, sollten Änderungen allerdings bewusst vorgenommen und ihre Auswirkungen auf Reporting und Kampagnenoptimierung berücksichtigt werden.
Quelle: analytics.google.com
3. GA4: Neuer Validierungsbericht für importierte Kampagnendaten
Für den Import von Kampagnendaten stellt Google Analytics 4 (GA4) eine neue Möglichkeit zur Qualitätskontrolle bereit. Ein eigener Validierungsbericht hilft dabei, fehlende oder unvollständige Daten aus “Non-Google-Kampagnen“ schneller zu erkennen und Probleme beim Cross-Channel-Reporting aufzudecken.
Der neue Bericht zeigt Kampagnen, für die zwar importierte Daten vorliegen, bei denen jedoch wichtige Informationen wie Kosten, Klicks oder Impressionen fehlen. Damit lässt sich direkt in GA4 überprüfen, ob externe Kampagnendaten vollständig und korrekt für die weitere Analyse zur Verfügung stehen. Die Validierung kann dabei auch auf bereits importierte Daten angewendet werden.
Warum ist das relevant?
Wer Kampagnendaten aus Plattformen außerhalb des Google-Ökosystems in GA4 zusammenführt, ist auf eine konsistente Datenbasis angewiesen. Fehlende Kosten-, Klick- oder Impressionsdaten können Kennzahlen und kanalübergreifende Vergleiche verfälschen. Der neue Bericht schafft hier mehr Transparenz und erleichtert es, Fehler im Datenimport frühzeitig zu erkennen, bevor sie sich auf Reporting und Performance-Bewertung auswirken.
Quelle: analytics.google.com
4. GTM: Vereinheitlichung von Google Tag und GTM wird ausgerollt
Nach der Ankündigung im Frühjahr beginnt Google nun mit dem Rollout der umfassenden Änderungen am Google Tag Manager (GTM). Im Mittelpunkt stehen die vereinfachte Benutzeroberfläche, die stärkere Vereinheitlichung von Google Tag und GTM sowie neue Möglichkeiten für Visual Tagging.
Die überarbeitete GTM-Oberfläche wird schrittweise für bestehende Container ausgerollt. Dabei rückt die bereits neu gestaltete Overview-Seite stärker ins Zentrum der Container-Verwaltung und bündelt wichtige Informationen und Einstellungen. Gleichzeitig werden Google Tag und GTM enger miteinander verzahnt, sodass Google-Tag-Konfigurationen stärker direkt innerhalb des GTM-Workflows verwaltet werden können. Mit Visual Tagging sollen sich zudem Tracking-Elemente direkt auf der Website auswählen und konfigurieren lassen, wodurch insbesondere die Einrichtung einfacher Tracking-Anforderungen erleichtert wird.
Nachdem Google die grundlegenden Änderungen bereits angekündigt hatte, beginnt nun die praktische Umstellung bestehender GTM-Workflows. Für erfahrene Nutzer bedeutet das zunächst eine Anpassung an neue Navigations- und Konfigurationswege. Strategisch zeigt der Rollout jedoch vor allem, dass Google die bisher getrennten Konzepte von Google Tag und GTM zunehmend zu einer einheitlichen Tagging-Umgebung zusammenführt.
Quelle: support.google.com
5. BigQuery: Monitoring für Data Agents mit Google Cloud Observability (Preview)
Mit der zunehmenden Nutzung von Data Agents rückt auch deren Überwachung stärker in den Fokus. BigQuery bietet dafür nun eine Integration mit Google Cloud Observability, über die sich Nutzung, Performance und Kosten von Data Agents und ihren Conversations zentral nachvollziehen lassen.
In BigQuery können Teams jetzt die Performance, Adoption, Latenz und Kosten ihrer Data Agents sowie der zugehörigen Conversations überwachen. Die entsprechenden Monitoring-Daten werden über Google Cloud Observability bereitgestellt und sollen einen besseren Einblick darin geben, wie Agents im laufenden Betrieb genutzt werden und welche Ressourcen sie beanspruchen. Die Funktion befindet sich derzeit im Preview-Status.
Warum ist das relevant?
Mit dem Schritt von ersten Experimenten hin zu produktiven agentischen Analytics-Anwendungen werden Monitoring und Kostenkontrolle zunehmend wichtig. Teams können nun besser nachvollziehen, wie intensiv einzelne Agents genutzt werden, wie performant sie arbeiten und welche Kosten dabei entstehen. Damit ergänzt Google den funktionalen Ausbau von Data Agents um eine wichtige operative Ebene und schafft mehr Transparenz für den Einsatz in größeren Unternehmensumgebungen.
Quelle: docs.cloud.google.com
6. BigQuery Graph: Core Graph Processing künftig nur noch für Enterprise Editions
Für Nutzer von BigQuery Graph kündigt Google frühzeitig eine wichtige Änderung bei der Verfügbarkeit und Abrechnung an. Ab dem 26. April 2027 wird das Core Graph Processing auf die BigQuery Enterprise und Enterprise Plus Editions beschränkt. Der Support für Core Graph Processing in der Standard Edition sowie bei On-Demand Billing wird ab diesem Zeitpunkt eingestellt.
Wer die zentralen Graph-Funktionen danach weiterhin nutzen möchte, benötigt entsprechend eine Enterprise- oder Enterprise Plus Edition. Eine Ausnahme bilden Graph Measures: Diese bleiben sowohl in Enterprise als auch in Enterprise Plus sowie für Queries mit On-Demand Pricing verfügbar, werden jedoch nicht in der Standard Edition unterstützt.
Warum ist das relevant?
Die Änderung kann direkte Auswirkungen auf Kosten- und Architekturentscheidungen von Unternehmen haben, die BigQuery Graph bereits einsetzen oder dessen Einführung planen. Insbesondere Nutzer der Standard Edition oder des On-Demand-Modells sollten frühzeitig prüfen, welche Graph-Funktionen sie verwenden und ob perspektivisch ein Wechsel des Abrechnungs- oder Editionsmodells erforderlich wird. Durch die Ankündigung rund acht Monate im Voraus bleibt ausreichend Zeit, bestehende und geplante Graph-Workloads entsprechend zu bewerten.
Quelle: cloud.google.com/blog
7. BigQuery: MCP-Server übernimmt weitere operative Aufgaben (Preview)
Der Einsatz von MCP in BigQuery geht zunehmend über reine Datenabfragen hinaus. Über den Cloud CLI Remote MCP Server können AI-Agenten nun auch komplexere operative und administrative Aufgaben innerhalb von BigQuery ausführen.
Mit dem neuen Tool run_bq_command erhalten AI-Agenten Zugriff auf zusätzliche Funktionen der BigQuery CLI. Darüber lassen sich unter anderem Jobs planen und verwalten sowie BigQuery Reservations administrieren. Die entsprechenden Befehle können über den von Google verwalteten Cloud CLI Remote MCP Server ausgeführt werden. Die Funktion befindet sich derzeit im Preview-Status.
MCP entwickelt sich damit von einer Schnittstelle für den Zugriff auf Daten zunehmend zu einer Steuerungsebene für Cloud- und Datenplattformen. AI-Agenten können nicht mehr nur Informationen aus BigQuery abrufen und analysieren, sondern auch operative Aufgaben übernehmen. Das eröffnet neue Automatisierungsmöglichkeiten für Data-Teams, erhöht gleichzeitig aber die Anforderungen an Berechtigungen, Governance und die Kontrolle agentisch ausgeführter Aktionen.
Quelle: docs.cloud.google.com/sdk/use-gcloud-mcp
8. BigQuery: Neue Funktionen für Time-Series-Analysen (Preview)
Für die Analyse von Zeitreihen stellt BigQuery drei neue Funktionen bereit, mit denen sich Trends, saisonale Muster und strukturelle Veränderungen direkt in den Daten untersuchen lassen. Die Funktionen befinden sich derzeit im Preview-Status und können auch innerhalb von Conversational Analytics eingesetzt werden.
Mit ML.TREND lassen sich zugrunde liegende Trends innerhalb einer Zeitreihe identifizieren, während ML.SEASONALITY wiederkehrende saisonale Muster sichtbar macht. Die dritte neue Funktion, ML.DETECT_CHANGE_POINTS, erkennt Zeitpunkte, an denen sich das Verhalten einer Zeitreihe signifikant verändert. Alle drei Funktionen stehen als Table-Valued Functions zur Verfügung und können sowohl über GoogleSQL als auch im Zusammenspiel mit Conversational Analytics genutzt werden.
Warum ist das relevant?
Typische Zeitreihenanalysen lassen sich direkt in BigQuery durchführen, ohne dafür zusätzliche Analyseumgebungen oder eigene Modelle aufsetzen zu müssen. Besonders interessant ist die Integration in Conversational Analytics: Trends, saisonale Effekte und strukturelle Veränderungen können dadurch auch Bestandteil AI-gestützter Datenanalysen werden.
Quelle: docs.cloud.google.com/bigquery
9. BigQuery Pipelines: AI-gestütztes Metadata Enrichment (Preview)
Dokumentation und Data Governance werden in BigQuery zunehmend Teil automatisierter Datenprozesse. BigQuery Pipelines können nun semantische Metadaten mit dem Knowledge Catalog synchronisieren und mithilfe des Data Engineering Agent automatisch um zusätzlichen Kontext ergänzen.
Metadaten aus SQLX-Konfigurationen innerhalb von BigQuery Pipelines können mit dem Knowledge Catalog synchronisiert werden. Zusätzlich lässt sich der Data Engineering Agent einsetzen, um Metadaten anhand des vorhandenen Kontexts und der beschriebenen Intention automatisch zu erzeugen und anzureichern. Dadurch können Informationen über Datenbestände bereits während der Entwicklung und Ausführung von Pipelines gepflegt werden. Die Funktion befindet sich derzeit im Preview-Status.
Warum ist das relevant?
Aktuelle und aussagekräftige Metadaten sind eine wichtige Grundlage für Data Discovery und Governance, ihre manuelle Pflege ist jedoch aufwendig und wird in der Praxis schnell vernachlässigt. Die neue Funktion verknüpft Datenentwicklung und Dokumentation enger miteinander und kann den manuellen Aufwand reduzieren. Gleichzeitig zeigt sie, dass Google AI-Agenten zunehmend nicht nur für Analyse und Entwicklung, sondern auch für die Verwaltung und Beschreibung von Datenbeständen einsetzt.
Quelle: Architektur von Knowledge Catalog (docs.cloud.google.com)










