Developer Token abgeschafft, Datenpipelines im Umzug: der Umbau der Google-Ads-API 2026

Am 9. September 2026 hat Google den Developer Token abgeschafft – jene Kennung, die bisher darüber entschied, was eine Integration an der Google Ads API darf. Diese Entscheidung hängt jetzt am Google-Cloud-Projekt, mit dem die OAuth-Anmeldedaten erzeugt wurden.

Zeitgleich, aber getrennt angekündigt: Die Datenpipelines für Erstanbieterdaten – Offline-Conversions, Enhanced Conversions für Leads, Customer Match – wandern aus der Google Ads API in die Data Manager API.

Beides gehört zusammen, weil es dieselben Integrationen trifft.

Wer beides verschläft, merkt es nicht sofort. Das ist das eigentliche Problem: Beide Umstellungen sind so gebaut, dass bestehende Integrationen zunächst weiterlaufen. Der Bruch kommt später – und er trifft dann die Conversion-Daten, von denen Smart Bidding lebt.

Teil 1: Der Developer Token ist Geschichte

Was am 9. September passiert ist

Google formuliert es in der Entwicklerdokumentation zum Developer Token unmissverständlich: Developer Tokens sind abgeschafft. Konkret gilt seither:

Du kannst weiterhin einen Developer Token im API-Header mitschicken. Er ist optional und wird von den API-Servern ignoriert.
Google hat angekündigt, Developer Tokens in einer künftigen Hauptversion der API abzulehnen. Ein Termin dafür steht nicht fest.
Die Zugriffsstufe bestimmt sich ab sofort aus dem Google-Cloud-Projekt, mit dem die OAuth-Anmeldedaten erzeugt wurden.

Der letzte Punkt ist der wichtige. «Das Cloud-Projekt» heisst genauer:

Bei Nutzerauthentifizierung: das Projekt, dem die OAuth-Client-ID und das zugehörige Secret gehören.
Bei Dienstkonten: das Projekt, dem das Dienstkonto gehört.

Das klingt nach einer Verwaltungsumstellung und ist in der Praxis eine Architekturfrage. Wer seine OAuth-Anmeldedaten irgendwann in einem beliebigen Projekt angelegt hat – weil es gerade offen war, weil es das erste in der Liste war –, hat jetzt eine Berechtigung, die an dieses Projekt geknüpft ist.

Wie Google die Bestandszugriffe migriert hat

Die Migration lief automatisch und rückblickend: Google hat die API-Aufruflogs der letzten 90 Tage vor dem 9. September ausgewertet und festgestellt, welche Cloud-Projekte mit einem genehmigten Developer Token Aufrufe gemacht haben. Jedes dieser Projekte hat die Zugriffsstufe des Tokens erhalten.

Daraus folgen zwei Konsequenzen, die man kennen sollte:

Projekte, die in diesen 90 Tagen nicht aktiv waren, stehen auf Testzugriff. Ein Skript, das nur quartalsweise läuft, ein Reporting-Job für den Jahresabschluss, eine Notfall-Integration, die seit Monaten stillsteht – diese Projekte haben die Migration nicht mitgemacht.

Ein Token konnte mehrere Projekte versorgen, jetzt zählt jedes einzeln. Google hält fest, dass mehrere Projekte unterschiedliche Zugriffsstufen haben können. Daraus folgt: Wer mit einem Token aus drei Projekten heraus gearbeitet hat, verwaltet jetzt drei Berechtigungen getrennt. Dazu kommt eine Einschränkung, die Google ausdrücklich nennt – das Umhängen eines Developer Tokens auf ein neues Cloud-Projekt, früher im Einzelfall möglich, wird seit dem 9. September 2026 nicht mehr unterstützt.

Die Zugriffsstufen und was sich an der Beantragung geändert hat

Es bleibt bei drei Stufen – Test, Basic, Standard –, aber der Weg dorthin ist neu:

Neue Cloud-Projekte starten auf Testzugriff. Zugriff für ein neues Projekt beantragst du über die Google-Ads-API-Übersichtsseite im Google Cloud Console.
Der Antrag läuft neu direkt in der Google Cloud Console – ein Google-Ads-Verwaltungskonto ist dafür nicht mehr nötig. Das ist für reine Softwareanbieter eine echte Vereinfachung.
Markenverifizierung ist für Basic und Standard neu verpflichtend. Wer das noch nie gemacht hat, sollte den Aufwand einplanen, bevor die Frist drückt.

Und ein Punkt, der Betroffene hart getroffen hat: Alle offenen Basic-Anträge, die vor dem 9. September 2026 eingereicht wurden, wurden geschlossen. Wer in der Warteschlange stand, muss neu beantragen. Offene Standard-Anträge werden dagegen normal weitergeprüft.

Wer was tun muss

Die Dokumentation zum Developer Token beschreibt die Mechanik – sie sagt aber nicht, welche Werkzeuge im Einzelnen betroffen sind. Deshalb hier die Trennung zwischen dem, was belegt ist, und dem, was du selbst prüfen musst:

Integration	Status
Eigener API-Client (Python, PHP, Node)	Belegt betroffen. Prüfen, aus welchem Cloud-Projekt die OAuth-Anmeldedaten stammen und welche Zugriffsstufe dieses Projekt hat. Die Token-Konfiguration kann bleiben, wird aber ignoriert.
Drittanbieter-Tools und Konnektoren (Reporting, Bid-Management, n8n, Make, BI-Konnektoren)	Ableitbar: Die Zugriffsstufe hängt am Cloud-Projekt des Anbieters, nicht an deinem Konto. Deine Aufgabe ist nachzufragen, ob migriert wurde – nicht selbst zu handeln.
Google Ads Scripts	Nicht dokumentiert. Siehe Hinweis unten.
Looker Studio, Google Ads Editor, BigQuery Data Transfer	Nicht dokumentiert. Siehe Hinweis unten.

Hier gibt es keine Entwarnung, weil es keine Quelle dafür gibt. Ob und wie sich die Umstellung auf Google Ads Scripts, Google Ads Editor, Looker Studio und den BigQuery Data Transfer Service auswirkt, geht aus der Dokumentation zum Developer Token nicht hervor. Es kursieren Berichte, diese Werkzeuge seien von den Authentifizierungsänderungen mit erfasst; belegen lässt sich das an Googles eigener Dokumentation nicht. Wer produktionskritische Skripte oder Reportings betreibt, prüft deshalb selbst – konkret: ob der jeweilige Job in den letzten Tagen fehlerfrei durchgelaufen ist – und verlässt sich nicht auf eine Interpretation. Ein Ausfall wäre hier sichtbar, nicht stillschweigend.

Der Versionskalender daneben

Unabhängig von der Token-Frage läuft der Versionszyklus weiter, und der ist eng getaktet. Version 22 wird am 7. Oktober 2026 abgeschaltet; ab diesem Datum schlagen alle v22-Anfragen fehl. Das hat Google am 2. September 2026 im Developer Blog bestätigt. Aktuell ist v25.1, angekündigt am 19. August 2026.

Welche Version deine Integrationen tatsächlich verwenden, musst du nicht raten: In der Google Cloud Console unter APIs und Dienste → Google Ads API → Metriken → Methoden steht, welche Aufrufe aus deinem Projekt gegen welche Version laufen. Das ist derselbe Ort, an dem du auch die Zugriffsstufe siehst – wer ohnehin dort nachschaut, erledigt beides in einem Zug.

Teil 2: Die Datenpipelines ziehen um

Was die Data Manager API ist

Die Data Manager API ist Googles einheitliche Aufnahmeschnittstelle für Erstanbieterdaten. Sie bedient nicht nur Google Ads, sondern:

Google Ads · Google Analytics · Display & Video 360 · Campaign Manager 360 · Search Ads 360 · Google Ad Manager.

Zwei Einstiegspunkte sind relevant:

POST https://datamanager.googleapis.com/v1/audiencemembers:ingest
→ Zielgruppen: Customer Match, Mobile-Device-IDs, PAIR

IngestEvents
→ Conversions und Ereignisse, inklusive Anpassungen

Googles Argument für den Umbau: ein einheitliches Datenmodell über alle Conversion-Anwendungsfälle und alle Werbeprodukte hinweg, statt je Anwendungsfall ein eigenes.

Die Stichtage – und wen sie tatsächlich treffen

Hier ist Genauigkeit wichtig, weil die Fachpresse die Fristen verkürzt wiedergegeben hat. Googles Übersicht zu Feature-Deprecations formuliert sie als Sperren für inaktive Integrationen, nicht als allgemeine Abschaltungen:

Datum	Was	Wen es trifft	Fehlercode
02.02.2026	Session-Attribute und IP-Adressdaten im Conversion-Import	Neueinsteiger in diese Funktionen	`CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE`
01.04.2026	Customer Match über `OfflineUserDataJobService` und `UserDataService`	Developer Tokens ohne Customer-Match-Aufruf zwischen 01.10.2025 und 31.03.2026	`CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE`
15.06.2026	Offline-Conversions über `UploadClickConversions`	Developer Tokens ohne Upload zwischen 17.12.2025 und 15.06.2026	`CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE`

Die praktische Lesart: Wer eine laufende, aktive Integration hat, ist bisher nicht gesperrt. Wer neu anfängt oder eine pausierte Integration wieder aufnimmt, geht über die Data Manager API.

Hier lässt die Dokumentation eine Lücke, und die wird hier nicht gefüllt: Die Allowlisting-Regeln sind an die Aktivität von Developer Tokens geknüpft. Developer Tokens gibt es seit dem 9. September 2026 nicht mehr. Wie die Bestandsberechtigung seither bestimmt wird – über das Cloud-Projekt, über den Kontobezug, oder ob die Regel praktisch eingefroren ist –, geht aus der veröffentlichten Dokumentation nicht hervor. Wer darauf angewiesen ist, sollte den Zustand im eigenen Setup testen, statt sich auf eine Annahme zu stützen.

Zwei Änderungen auf Kontoebene gehören dazu, weil sie den Parallelbetrieb erst ermöglichen: Seit Juni 2026 sind Enhanced Conversions für Web und für Leads zu einer Funktion mit einem einzigen Ein-/Aus-Schalter zusammengelegt. Und seit April 2026 nimmt Google Ads von Nutzern bereitgestellte Daten gleichzeitig aus Website-Tag, Data Manager und API entgegen – vorher musste man sich für einen Weg entscheiden. Ohne diese zweite Änderung liesse sich nicht beides gleichzeitig senden – und damit auch nicht sauber umschalten.

Was in der Data Manager API besser ist

Googles eigener Upgrade-Leitfaden stellt die beiden Wege gegenüber. Die Unterschiede, die operativ zählen:

	Data Manager API	Google Ads API
Developer Token	nicht erforderlich	erforderlich (historisch)
Datenmodell	einheitlich über alle Anwendungsfälle und Produkte	je Anwendungsfall verschieden
Verschlüsselung von Nutzerkennungen	unterstützt	nicht unterstützt
Session-Attribute und IP-Upload	für alle API-Nutzer verfügbar	zugangsbeschränkt
Conversion-Anpassungen	in `IngestEvents` integriert	eigener `ConversionAdjustmentUploadService`
Fehlerverhalten	Fast-Fail	Partial Failure

Zwei Punkte daraus verdienen mehr als eine Tabellenzeile.

Die IP- und Session-Attribut-Frage dreht sich um. In der Google Ads API sind diese Daten seit Februar 2026 für Neueinsteiger gesperrt. In der Data Manager API stehen sie allen offen. Das ist kein Zufall, sondern der Mechanismus der Migration: Google macht den neuen Weg funktional attraktiver, statt den alten hart abzuschalten.

Fast-Fail statt Partial Failure ist eine Umstellung im Betrieb. Die Google Ads API konnte – mit aktiviertem partial_failure – den Rest eines Batches verarbeiten und nur die fehlerhaften Datensätze zurückmelden. Die Data Manager API bricht stattdessen ab. Wer bisher darauf gebaut hat, dass ein einzelner fehlerhafter Datensatz den Rest des Uploads nicht aufhält, braucht eine Validierung vor dem Upload.

Was in der Data Manager API schlechter oder anders ist

Ein ehrlicher Migrationsartikel nennt auch das. Drei Punkte aus Googles eigenem Leitfaden:

1. Das operating_account muss das Konto sein, dem die Conversion-Aktion gehört. Die Google Ads API erlaubte es, Uploads über ein übergeordnetes oder untergeordnetes Konto zu schicken. Die Data Manager API unterstützt das nicht.

Für Agenturen mit MCC-Struktur ist das nach meiner Einschätzung der aufwändigste Punkt der ganzen Migration. Wer heute alle Kunden-Uploads über ein zentrales Verwaltungskonto abwickelt, muss die Logik so umbauen, dass pro Conversion-Aktion das richtige Konto adressiert wird – inklusive der Berechtigungen dafür. Das ist keine Zeile Code, das ist ein Architekturschritt.

2. Conversion-Rücknahmen fehlen. Das Zurücknehmen einer Conversion durch Setzen von Wert und Anzahl auf null wird nicht unterstützt. Wer Stornierungen, Retouren oder disqualifizierte Leads bisher so abgebildet hat, braucht einen anderen Weg.

3. Anpassungen funktionieren anders – zum Besseren, aber anders. Die Data Manager API behandelt einen Upload mit bereits bekannter transaction_id automatisch als Anpassung. Der explizite ConversionAdjustmentType entfällt, und doppelte Transaktions-IDs führen nicht mehr zum Fehler. Wer bisher eine Deduplizierungslogik gebaut hat, um genau diesen Fehler zu vermeiden, kann sie zurückbauen – muss sich aber darüber klar sein, dass ein versehentlicher Doppel-Upload jetzt stillschweigend als Korrektur durchgeht.

Ergänzend hat Google die Schnittstelle im Mai 2026 erweitert: AdIdentifiers kennt jetzt dclid, impressionId, matchId und verschlüsselte Nutzerkennungen, und ein neues Feld CompositeData erlaubt die Übergabe von IP-Adressen für Customer Match – einzeln oder zusammen mit E-Mail, Telefonnummer und Adressdaten.

Der Punkt, den Schweizer Konten zusätzlich prüfen müssen

Customer Match und der neue IP-Pfad sind nicht nur eine technische Frage, sondern eine der Rechtsgrundlage. Wer E-Mail-Adressen, Telefonnummern oder IP-Daten an Google übermittelt, braucht dafür eine Einwilligung – bei Nutzern im EWR und in Grossbritannien verlangt Google sie über seine EU-Nutzereinwilligungsrichtlinie, unabhängig davon, was das revidierte Schweizer Datenschutzgesetz vorschreibt. Für ein Schweizer Konto mit deutschen oder französischen Kunden gilt damit faktisch der strengere Massstab.

Praktisch heisst das: Die Migration ist der richtige Zeitpunkt, um zu prüfen, ob die Einwilligungssignale in der Pipeline überhaupt mitgeführt werden. Die Data Manager API sieht dafür Einwilligungsfelder im Request vor – wer sie nicht befüllt, hat die Frage nicht gelöst, sondern nur verschoben. Wie diese Signale technisch zustande kommen und wann ad_user_data konkret auf denied steht, steht im Leitfaden zu Consent Mode v2.

Was das für Smart Bidding bedeutet

Der Teil, der in Entwicklerartikeln fehlt und in SEA-Artikeln nicht vorkommt, weil beide Seiten aneinander vorbeischreiben.

Eine abgerissene Conversion-Pipeline ist kein Reporting-Problem. Ziel-CPA und Ziel-ROAS optimieren auf die Conversions, die ankommen. Kommen während einer misslungenen Migration zwei Wochen lang keine Offline-Conversions an, lernt die Gebotsstrategie, dass dieser Traffic nicht konvertiert – und drosselt genau dort, wo die Leads herkamen. Wenn die Daten danach wieder fliessen, ist die Lernphase nicht rückgängig zu machen; die Strategie arbeitet sich neu ein.

Der Effekt ist zeitversetzt und deshalb tückisch: In der ersten Woche sieht alles normal aus, weil die Conversion-Verzögerung den Ausfall verdeckt. Sichtbar wird er, wenn die Verzögerungsspanne abgelaufen ist – und dann sieht es aus wie ein Nachfrageproblem, nicht wie ein Datenproblem.

Deshalb gehört zu jeder Migration ein Monitoring, das den Zufluss überwacht, nicht die Leistung:

Anzahl importierter Conversions pro Tag und Conversion-Aktion, gegen den Vorwochenwert.
Der Bericht zur Conversion-Verzögerung in Google Ads – er zeigt, wie lange du auf Daten wartest, und damit, ab wann ein Ausfall überhaupt sichtbar würde.
Die Diagnosehinweise der Conversion-Aktion in Google Ads.
Ein Alarm auf «null Uploads in 24 Stunden», nicht auf «Uploads unter Erwartung». Der Totalausfall ist der Fall, der zählt.

Migrationscheckliste

Für Konten und Agenturen, die Offline-Conversions oder Customer Match über die API betreiben.

Phase 1 – Bestandsaufnahme

Alle Integrationen auflisten, die die Google Ads API schreibend nutzen: eigene Skripte, CRM-Konnektoren, Automatisierungsplattformen, Agentur-Tools.
Je Integration festhalten: Welches Google-Cloud-Projekt liefert die OAuth-Anmeldedaten? Welche Zugriffsstufe hat dieses Projekt heute? Welche API-Version wird verwendet?
Prüfen, ob eine Integration in den 90 Tagen vor dem 9. September 2026 aktiv war. Wenn nicht: Zugriffsstufe kontrollieren, sie steht vermutlich auf Test.
Prüfen, ob eine Integration von v22 abhängt – Abschaltung am 7. Oktober 2026.
Bei Drittanbietern: schriftlich nachfragen, ob sie migriert haben. Nicht annehmen.

Phase 2 – Zugriff herstellen

Für jedes produktiv genutzte Cloud-Projekt die benötigte Zugriffsstufe sicherstellen; Anträge laufen über die Google-Ads-API-Übersicht in der Google Cloud Console.
Markenverifizierung vorbereiten, falls Basic oder Standard beantragt werden muss.
Falls ein Basic-Antrag vor dem 9. September 2026 offen war: Er wurde geschlossen. Neu einreichen.

Phase 3 – Pipelines umbauen

Kontostruktur klären: Welche Conversion-Aktion gehört welchem Konto? Das operating_account muss künftig dieses Konto sein, nicht das Verwaltungskonto.
Fehlerbehandlung von Partial Failure auf Fast-Fail umstellen: Validierung vor dem Upload, saubere Batch-Grössen, Wiederaufnahme nach Abbruch.
Prüfen, ob Conversion-Rücknahmen im bestehenden Prozess vorkommen. Falls ja: Ersatzweg definieren, bevor umgestellt wird.
Deduplizierungslogik für transaction_id überprüfen – Anpassungen laufen jetzt implizit.
Enhanced Conversions: den seit Juni 2026 zusammengelegten Ein-/Aus-Schalter im Konto kontrollieren.

Phase 4 – Parallelbetrieb und Umschaltung

Beide Wege parallel betreiben und die Ergebnisse vergleichen, bevor der alte abgeschaltet wird. Verglichen wird die Anzahl angenommener Conversions je Conversion-Aktion und Tag, nicht die Kampagnenleistung.
Erst umschalten, wenn die Zahlen über mehrere Tage übereinstimmen.
Monitoring gemäss dem Abschnitt oben scharf schalten, bevor der alte Weg abgeschaltet wird – nicht danach.

Zur Länge des Parallelbetriebs kursieren Empfehlungen von zwei bis vier Wochen. Eine Vorgabe von Google dazu ist nicht dokumentiert. Sinnvoll ist eine Spanne, die mindestens die eigene Conversion-Verzögerung abdeckt – die kennst du aus dem entsprechenden Bericht, und sie ist im B2B oft länger als vier Wochen.

Einordnung

Der Umbau folgt einem Muster, das sich 2026 in mehreren Bereichen zeigt: Google trennt die Werbeplattform von der Dateninfrastruktur. Die Google Ads API verwaltet künftig Kampagnen; Erstanbieterdaten laufen über die Data Manager API, die produktübergreifend arbeitet. Der Zugang wiederum hängt nicht mehr an einem Ads-spezifischen Token, sondern an einem Cloud-Projekt wie bei jeder anderen Google-API.

Aus Sicht eines Entwicklers ist das eine Vereinheitlichung, die längst überfällig war. Aus Sicht einer Agentur ist es eine Verschiebung: Was früher im Ads-Konto verwaltet wurde, wird zur Cloud-Verwaltung – mit Projekten, Dienstkonten, Berechtigungen und Markenverifizierung. Wer diese Kompetenz nicht im Haus hat, braucht sie jetzt.

Und es bleibt eine offene Stelle: Ein endgültiges Abschaltdatum für die bestehenden Google-Ads-API-Pfade zu Offline-Conversions und Customer Match hat Google nicht genannt. Solange das so ist, ist die Migration ein Projekt mit Vorlauf – kein Notfall. Dieser Vorlauf ist der Grund, sie jetzt zu planen, statt sie unter Zeitdruck zu machen.