Google Data Manager oder sGTM: was 2026 gilt

Hier widersprechen sich zwei Google-Quellen, und das erklärt einen Grossteil der Verwirrung. Die Google-Ads-Hilfe schreibt: Starting June 15, 2026, offline conversions import and enhanced conversions for leads uploads will be migrated to the Data Manager API and blocked in the Google Ads API. Wer nur das liest, rechnet mit einer Abschaltung.

Der Google Ads Developer Blog vom 15. Mai 2026 ist präziser. Ab dem 15. Juni 2026 nimmt die Google Ads API für diese Uploads keine neuen Nutzer mehr an. Wer bereits importiert hat, kann während der Umstellung weiter über die Google Ads API importieren. Neue Aufrufe scheitern mit dem Fehler CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE bei ConversionUploadService.UploadClickConversions. Der Developer Blog ist die belastbarere Quelle: Er beschreibt das technische Verhalten, die Hilfeseite fasst nur zusammen.

Ein Abschaltdatum für bestehende Integrationen hat Google bisher nicht genannt. Es gibt also keine kommunizierte Deadline, bis zu der laufende Setups migriert sein müssen.

Ein Detail mit Sprengkraft für Agenturen: Developer-Tokens, die zwischen Januar und Juni 2026 keinen Request gesendet haben, werden für den Legacy-Zugang nicht freigeschaltet. Wer ein Setup gebaut, aber pausiert hat, kann den Bestandsschutz verloren haben, ohne es zu merken.

Kurz: Wer heute neu startet, startet auf der Data Manager API. Wer schon läuft, hat Zeit, aber kein Enddatum. Panik ist unbegründet, Aufschieben ohne Plan trotzdem eine schlechte Idee.

Das ist die Verwechslung, die praktisch jede Diskussion zum Thema unbrauchbar macht. Google Ads Data Manager ist die Oberfläche in Google Ads. Point-and-Click, kein Code. Er verbindet 17 Datenquellen, darunter BigQuery, Snowflake, Salesforce, HubSpot, Shopify, Zoho CRM, Google Sheets, SFTP und diverse SQL-Datenbanken. Google nennt dazu genau zwei Ziele: Customer Match und den Offline Conversions Import, in dessen Rahmen auch Enhanced Conversions für Leads laufen. Google Analytics ist kein Ziel.

Die Data Manager API ist der programmatische Weg. Sie bedient über einen Endpunkt Google Ads, Google Analytics, Display & Video 360, Campaign Manager 360, Search Ads 360, Google Ad Manager und Firebase. Floodlight-Ziele kamen mit Version 1.7 am 28. Mai 2026 dazu. Die API ist seit dem 6. Oktober 2025 allgemein verfügbar, also kein Beta-Produkt mehr.

Google-nah klingt nach einfach. Die Data Manager API ist es nicht. Voraussetzung sind ein Google-Cloud-Projekt, die installierte gcloud CLI, die explizit aktivierte Data Manager API, eingerichtete Application Default Credentials und ein Konto mit der Berechtigung serviceusage.services.enable. Ein Developer Token ist nicht nötig, anders als bei der Google Ads API. Das ist eine echte Erleichterung, gerade für [Agenturen](/fuer-agenturen), ändert aber nichts am Kern: Die Oberfläche ist Konfiguration, die API ist Entwicklung. Wer beides Data Manager nennt, verschleiert einen erheblichen Aufwandsunterschied.

Bleibt die Frage, die am häufigsten gestellt wird: Ersetzt Data Manager server-side GTM? Nach unserer Einschätzung nein, und diese Einordnung ist ausdrücklich unsere und nicht Googles Aussage. Wir haben beide Dokumentationen geprüft. Die Tag-Manager-Dokumentation erwähnt den Data Manager nicht, die Data-Manager-Dokumentation erwähnt server-side GTM nicht. Es gibt keine Google-Quelle, die die beiden zueinander in Beziehung setzt. Wer behauptet, Google habe sGTM abgelöst, belegt das nirgends. Wer das Gegenteil behauptet, ebenso wenig.

Sachlich lösen die beiden verschiedene Probleme. Die Data Manager API ist ein Ingestion-Weg in Google-Produkte. Server-side GTM ist ein Web-Container plus ein Server-Container in der Cloud, über den Events normalisiert, gefiltert, dedupliziert und an mehrere Plattformen verteilt werden, unter anderem an die Meta Conversions API und die Microsoft Advertising Conversions API. Eine Präzisierung in eigener Sache: sGTM als Layer zwischen Website, App, Shop, CRM und Marketing-Plattformen zu beschreiben, ist überdehnt und klingt nach einer CDP. Shop- und CRM-Daten lassen sich per HTTP-Request anbinden, das ist aber eigene Bauarbeit und nicht Teil von Googles Produktbeschreibung.

Der unterschätzte Punkt der Data Manager API ist nicht der Transport, sondern was unterwegs mit den Daten passiert. Die API unterstützt kundenverwaltete Verschlüsselung. Verwendet wird ein Data Encryption Key, der über einen Key Encryption Key in Google Cloud KMS oder AWS KMS gewrappt wird. Als Cipher ist XCHACHA20_POLY1305 vorgesehen, für die Umsetzung empfiehlt Google die Bibliothek Tink.

Drei Punkte werden dabei regelmässig falsch verstanden. Verschlüsselung ersetzt Hashing nicht: Die Daten werden zuerst normalisiert und mit SHA-256 gehasht, danach verschlüsselt, Google dazu wörtlich Don't encrypt unhashed values. Nicht alles wird verschlüsselt: Ländercode, Postleitzahl, Ort und Verwaltungsregion bleiben unverschlüsselt, weil sie nicht gehasht werden. Und der Schlüssel bleibt beim Absender. Wer das Key-Management kontrolliert, hat gegenüber Datenschutzverantwortlichen ein belastbares Argument, das ein Upload aus einem Google Sheet nicht liefert. Für Unternehmen mit ernsthaften Datenschutz-Anforderungen ist das der stärkste sachliche Grund, die API der Oberfläche vorzuziehen.

Beim Consent ist die Lage umgekehrt ernüchternd. Die Data Manager API kennt zwei Felder, adUserData und adPersonalization, mit den Werten CONSENT_GRANTED, CONSENT_DENIED und CONSENT_STATUS_UNSPECIFIED. Beide Felder sind laut API-Referenz optional. Im Klartext: Die Schnittstelle prüft nicht, ob eine Einwilligung vorliegt, und akzeptiert Daten auch ganz ohne Consent-Angabe. Die Verantwortung bleibt vollständig beim Absender. Wer glaubt, serverseitige Datenübertragung ersetze eine [Consent-Strategie](/leistungen/consent-mode), bekommt hier das Gegenteil belegt.

Und dann der Schweizer Teil, den fast alle überspringen. Googles EU User Consent Policy gilt ausdrücklich für Endnutzer in the European Economic Area, the UK and Switzerland. Die Schweiz steht also explizit im Geltungsbereich dieser vertraglichen Policy. Googles technische Hilfe zum Consent Mode ist dagegen EWR-bezogen formuliert und nennt die Schweiz nicht. Daraus entsteht der Satz, den wir in Erstgesprächen ständig hören: Wir sind nicht in der EU, also betrifft uns das nicht. Das ist keine Rechtsberatung, sondern die schlichte Feststellung, dass zwei Google-Dokumente unterschiedliche Reichweiten haben. Wer daraus eine Entscheidung ableitet, sollte das mit einer Datenschutz-Fachperson tun und nicht mit einem Blogartikel. Mehr Kontext im Beitrag zu [Consent Mode v2 in der Schweiz](/blog/google-consent-mode-v2-schweiz).

Google Ads Help: Upgrade offline conversion import to enhanced conversion for leads, https://support.google.com/google-ads/answer/14274408 und Enhanced conversions Updates, https://support.google.com/google-ads/answer/16884284 sowie Consent Mode EWR, https://support.google.com/google-ads/answer/13695607

Google Ads Developer Blog: Changes to offline click conversion imports, 2026-05-15, https://ads-developers.googleblog.com/2026/05/changes-to-offline-click-conversion.html

Google Ads Data Manager Help: Supported data sources and destinations, https://support.google.com/marketing-data-manager/topic/13860693

Google Developers, Data Manager API: Übersicht https://developers.google.com/data-manager/api, Set up access https://developers.google.com/data-manager/api/devguides/quickstart/set-up-access, Encryption https://developers.google.com/data-manager/api/devguides/concepts/encryption, Consent reference https://developers.google.com/data-manager/api/reference/rest/v1/Consent, Events overview https://developers.google.com/data-manager/api/devguides/events

Google Developers, GA4 Measurement Protocol: https://developers.google.com/analytics/devguides/collection/protocol/ga4. Google, EU User Consent Policy: https://www.google.com/about/company/user-consent-policy/. Microsoft Learn, UET and Conversions API integration: https://learn.microsoft.com/en-us/advertising/guides/uet-conversion-api-integration

Alle Quellen abgerufen am 2026-08-25.