Tracking & Analytics 9 min Lesezeit

GTM 2026: Das stille, aber größte Update seit Jahren

Vier Monate, vier Release Notes, ein roter Faden. Was Google beim Tag Manager dieses Jahr eigentlich macht, und warum die meisten Setups das übersehen.

Simon Bluhm
Co-Founder, rulers · LinkedIn ↗
Tag Manager · 2026 Recap
GTM Edge
TL;DR

Google hat in den letzten Monaten die Architektur des Tag Managers grundlegend umgebaut. Nicht durch ein einzelnes großes Feature, sondern durch vier eher unscheinbare Release Notes, die zusammen etwas Großes ergeben. Tag Gateway für Werbetreibende über Google Cloud Platform, Akamai und Fastly. Plus erweiterte Event-Auto-Detection in Google Ads seit Februar. Wer das ernst nimmt, baut sich bis Ende 2026 ein Datenfundament, von dem die Konkurrenz erst 2027 hören wird.

Was mir bei den Release Notes auffällt

Ich lese die GTM Release Notes seit ungefähr 2018, jeden Monat. Meistens sind das kleine Sachen. Eine UI-Verbesserung hier, ein neuer Variablentyp da, gelegentlich eine Bug-Fix-Welle. Selten passiert etwas, bei dem ich denke: ok, das verändert wie wir bauen.

2026 ist anders.

Wenn man die vier Release Notes von Januar bis Mai nebeneinander legt, fügen sie sich zu einem Bild zusammen, das Google nicht in einer Keynote angekündigt hat. Kein Marketing-Splash, keine PR-Welle. Einfach vier nüchterne Einträge in einer Doku-Seite. Und doch ist das, was dabei passiert, die größte strukturelle Veränderung am Tag Manager, die ich kenne.

Das Stichwort heißt Google tag gateway for advertisers. Klingt sperrig, also auf Deutsch ungefähr: first-party Mess-Infrastruktur direkt von Google. Lass mich das aufdröseln.

Tag Gateway, also was eigentlich

Stell dir vor du betreibst einen Webshop. Bisher lief das so: dein Browser lädt einen Tag von googletagmanager.com, der schickt Daten an google-analytics.com. Beides sind Google-Domains. Safari blockt die unter ITP teilweise weg. uBlock und Brave sowieso. Du verlierst Signal.

Tag Gateway macht etwas anderes. Statt direkt zu Google geht der Traffic über deine eigene Domain. Cookies werden first-party gesetzt. Browser-Blocker haben nichts mehr, was sie blocken könnten, weil die Requests rein technisch von deiner Marke kommen. Erst hinter den Kulissen werden sie an Google weitergereicht.

# Bisher (third-party, ITP-blockbar)
Browser  →  googletagmanager.com/gtm.js
         →  google-analytics.com/g/collect

# Mit Tag Gateway (first-party über deine Domain)
Browser  →  deine-domain.com/_/gtag/js
         →  (intern weitergereicht)
         →  google-analytics.com/g/collectflow

Das ist im Grunde Server-Side GTM, aber tiefer integriert. Wo bisher viel manuelle Cloud Run Konfiguration nötig war, bietet Google jetzt eine vorgefertigte Lösung direkt im Tag Manager an.

Was an dieser Sache neu ist: Google macht es nicht über ein neues Tool. Google integriert sich direkt in die Infrastruktur, die du eh schon hast. Also dein CDN.

Januar 2026: GCP Beta

Der erste Schritt im Januar war Google Cloud Platform. Aus der Release Note vom 5. Januar:

This release introduces a new workflow for Google tag gateway for advertisers, allowing you to leverage Google Cloud Platform's Global external Application Load Balancer. This "one-click" integration directly in GTM and Google tag settings, streamlines deployment and configures your Google tag and tag containers to send data through your first-party web infrastructure before it is relayed to Google.

Was technisch passiert: GTM bekommt einen Hebel, der auf Klick einen Global Application Load Balancer in deiner GCP-Konfiguration platziert. Der Load Balancer nimmt Traffic von deiner eigenen Domain an und reicht Google-Signale (Tag-Container, Analytics-Requests) sauber an Google weiter.

Für GCP-Kunden ist das ein "one-click" Komfort-Upgrade. Für alle, die nicht auf GCP sind, eher Beobachtungsmaterial. Das war der frühe Schritt, ein Testballon.

Februar 2026: Mehr Event-Daten aus Google Ads

Vier Wochen später, am 4. Februar, kam dieses fast unauffällige Update:

Google Ads will help advertisers measure more effectively and gain deeper insights with less manual configuration, by automatically collecting a broader range of event data from their websites. Advertisers may notice additional network requests to Google domains when these events are transmitted.

Auf den ersten Blick ein Marketing-Satz. Aber zwischen den Zeilen passiert was Interessantes. Google Ads sammelt automatisch mehr Event-Daten von deiner Seite. Du brauchst dafür nichts mehr zu konfigurieren.

Was das praktisch bedeutet: Conversions, die du bisher manuell tracken musstest, also Klicks auf "Add to Cart" oder Scroll-Tiefe oder Formular-Interaktionen, werden in Teilen automatisch erkannt. Auto-Tagging wird mächtiger.

Klingt komfortabel. Ist es auch. Aber es kommt mit einem Preis: du gibst Kontrolle ab. Was Google von deiner Seite sammelt und wie diese Signale interpretiert werden, läuft jetzt ein Stück weit unter der Haube. Das kann gut sein (wenn die Algorithmen smart sind) oder problematisch (wenn deine Datenstruktur Spezifika hat).

Mein Tipp dazu: wenn du Standard-GA4-Events sauber nutzt, profitierst du davon. Wenn du custom Tracking baust und auf Granularität achtest, beobachte das in den ersten Wochen genauer.

Januar 2026: Akamai geht live

Ende Januar, kurz nach GCP, kam Akamai dazu.

This release introduces a new option to configure Google tag gateway for advertisers using Akamai as your content delivery network (CDN). This integration gives you greater control over your data, improving the accuracy of your Google Analytics reporting and driving conversions uplift.

Akamai ist einer der größten CDN-Anbieter weltweit. Wer große Shops betreibt, fährt oft auf Akamai oder Cloudflare oder Fastly.

Diese erste Akamai-Integration war noch eher manuell. Du musstest in der Akamai-Konsole selbst Routing-Regeln einrichten, was nicht trivial ist. Aber das ging überhaupt erst einmal. Google hat den Türöffner hingestellt.

Mai 2026: Akamai und Fastly automatisiert

Und dann kam Mai. Das ist die Release Note, die meiner Meinung nach das eigentliche Update darstellt:

This release introduces a streamlined integration to configure Google tag gateway for advertisers using Akamai or Fastly as your content delivery network (CDN). You can now authorize Google to automatically detect your CDN zones and inject routing rules directly from the Google tag interface, eliminating the need for manual configuration in the Akamai Control Center or Fastly dashboard.

Lesen wir das nochmal genau. "Automatically detect your CDN zones and inject routing rules directly from the Google tag interface."

Das heißt: du loggst dich in GTM ein, autorisierst Google, dass es deine Akamai- oder Fastly-Settings lesen und schreiben darf, und Google konfiguriert deine CDN-Routing-Rules von selbst. Aus der GTM-Oberfläche heraus.

Zur Anschauung, was bei Fastly hinter den Kulissen passiert (vereinfacht):

# Auto-injected von Google ins Fastly VCL
sub vcl_recv {
    if (req.url ~ "^/_/gtag/") {
        set req.backend = F_googletagmanager;
        set req.http.X-Forwarded-Host = req.http.host;
        return(pass);
    }
}fastly · vcl

Vorher musstest du dieses Routing manuell pflegen, im Fastly-Dashboard zwischen 10 anderen Backend-Regeln. Jetzt schreibt Google das selbst hin, und du siehst es nur noch als "konfiguriert" in GTM.

Das war im Januar noch undenkbar. Im Mai ist es ein Klick.

Und gleichzeitig kommt Fastly mit dazu. Fastly ist der CDN-Player, der bei vielen modernen Tech-Stacks läuft (Vercel, einige Shopify Plus Setups, etliche Headless-Architekturen). Heißt: Google hat jetzt die drei größten Player abgedeckt. GCP, Akamai, Fastly.

Was das zusammen bedeutet

Wenn man die vier Release Notes übereinander legt, sieht man eine Strategie.

Erstens, Google macht first-party measurement zur Standardarchitektur. Nicht mehr eine Option für Tech-Heavy-Setups, sondern was alle nutzen sollen.

Zweitens, Google integriert sich direkt in die Infrastruktur, die du eh schon hast. CDN ist nicht etwas, was man neu kauft. Wenn du einen Shop betreibst, hast du eins. Wenn das ein Akamai, Fastly oder GCP ist, kannst du nun Tag Gateway aktivieren.

Drittens, der Aufwand sinkt drastisch. Im Januar war das Setup noch ein Projekt für einen Senior. Im Mai ist es eine Self-Service-Funktion.

Viertens, die Datenqualität geht hoch. Das ist nicht meine Aussage, das schreibt Google selber: "improving the accuracy of your Google Analytics reporting, and drive conversion uplift through enhanced signal recovery." Conversion-Uplift ist business-relevant. Wenn du im Performance-Marketing-Spiel bist, ist das spürbar.

Mein Bauchgefühl dazu: Wer den Schritt jetzt geht, gewinnt 6 bis 12 Monate Vorsprung gegenüber Wettbewerbern, die das Thema erst 2027 angehen. Nicht weil es so kompliziert wäre, sondern weil es so still kommuniziert wird, dass es leicht übersehen wird.

Für wen sich das lohnt

Sehr verschieden, je nach Setup. Hier ein ehrlicher Schnitt:

Shops mit GA4 + Google Ads als Hauptkanal

Massiv relevant. Du verlierst durch Browser-Blocker zwischen 10 und 30 Prozent deiner Signale, je nach Zielgruppe. Tag Gateway holt einen großen Teil davon zurück. Conversion-Uplift im einstelligen Prozentbereich ist realistisch.

Shops mit fertigem Server-Side-Setup

Wenig direkter Nutzen. Du hast die Probleme schon gelöst, eventuell mit eigenem Cloud Run oder GTM Server-Container. Aber irgendwann wirst du dieses Setup ablösen wollen, weil Tag Gateway weniger Wartung braucht.

B2B mit langem Sales Cycle

Indirekt relevant. Tag Gateway hilft dir bei initialer Lead-Erfassung. Was danach passiert (CRM, Pipeline), bleibt davon unberührt.

Zielgruppe mit hohem Apple-Anteil

Sehr hoch. Safari ITP frisst sonst viel Signal. Tag Gateway umgeht das fast vollständig.

Cloudflare-Setups (also nicht Akamai, Fastly, GCP)

Noch nichts dabei. Offizielle Cloudflare-Integration ist meines Wissens nach noch nicht verfügbar. Würde mich nicht wundern, wenn das Ende 2026 kommt. Bis dahin hilft Cloudflare Workers als Eigenbau-Lösung.

Was ich an deiner Stelle tun würde

Erstens, prüfe welchen CDN du eigentlich nutzt. Viele wissen das gar nicht genau, weil das oft im Hosting-Setup mit dabei ist. Wenn du auf Managed-Hosting wie Cloudways, Kinsta oder WP Engine bist, frag den Support. Bei AWS-Setups ist es meistens CloudFront, was auch noch nicht von Tag Gateway abgedeckt ist.

Schneller Check vom Terminal aus:

# Verrät dir den CDN-Provider
curl -sI https://deine-domain.de | grep -iE 'server|x-served-by|cf-ray|x-cache|x-akamai'bash

Antwortet "cf-ray:" → Cloudflare. "x-served-by:" → meist Fastly. "x-akamai-...:" → Akamai. "x-cache: cloudfront" → CloudFront. Keine dieser Headers → vermutlich direktes Hosting ohne CDN, dann hast du andere Themen zu klären.

Zweitens, wenn du auf Akamai, Fastly oder GCP bist, schau dir die Tag-Gateway-Setup-Doku an. Das ist kein massives Projekt mehr.

Drittens, bevor du aktivierst: prüfe deine Datenschutz-Doku und das Consent-Management. Tag Gateway ändert technisch, wie Daten fließen, was die Datenschutzerklärung berührt. Nicht unkompliziert, aber lösbar.

Viertens, plane einen Vergleich vorher/nachher. Sieh dir Conversion-Volumen und Datenqualität in den ersten zwei bis vier Wochen nach Aktivierung an. Erstell vorher Baseline-Reports. Sonst weißt du später nicht, was der Uplift wirklich war.

Schluss-Gedanke

Ich finde es faszinierend, wie still solche großen Updates manchmal sind. Im Vergleich zu GA4-Migrationen, die mit Pomp und Trara liefen, kommt Tag Gateway als Reihe nüchterner Release Notes daher. Genau das macht es leise unterschätzt.

Wer es ernst nimmt, baut sich hier 2026 ein Datenfundament, von dem die meisten Konkurrenten erst 2027 oder 2028 hören werden. Vorausgesetzt, du nimmst dir die zwei Stunden, um zu prüfen, ob es bei dir geht.

← Alle Beiträge Setup-Check anfragen →