Google Analytics API gibt Conversion-Daten für Entwickler frei

Google hat die wohl folgenreichste Analytics-API-Änderung des Jahres 2026 ausgeliefert – und das ohne Pressemitteilung. Am 4. Mai 2026 öffnete Google kanalübergreifende Conversion-Daten über die Google Analytics Data API und machte den Conversion-Performance-Bericht erstmals programmatisch abrufbar. Die technische Grundlage, ein neues ConversionSpec-Feld in RunReportRequest, wurde bereits elf Tage zuvor, am 23. April, still und leise zur v1 alpha hinzugefügt.

Dies ist die vierte Analytics-Funktion, die Google allein im Jahr 2026 veröffentlicht oder erweitert hat – nach den drei gleichzeitigen Betas im Januar, den generierten Insights im Februar und dem Task Assistant im April. Vier Releases in etwa vier Monaten, alle ohne formelle Ankündigungen – ein Tempo, das für jeden relevant ist, der Attribution-Pipelines betreibt.

Was passiert ist

Die entscheidende Tatsache: Entwickler können jetzt runReport mit einem ConversionSpec aufrufen und dieselben Daten abrufen, die bisher ausschließlich hinter der Google Analytics-Oberfläche unter Werbung > Conversion-Performance verfügbar waren. Vor diesem Update gab es keine programmatische Alternative zu diesem Bericht. Teams, die benutzerdefinierte Dashboards, Warehouse-Pipelines oder BI-Integrationen aufbauen, hatten keine unterstützte Möglichkeit, Conversion-Performance-Daten zu extrahieren, wie PPC Land in seiner Berichterstattung über das Changelog dokumentiert hat. Der Workaround war der manuelle Export aus der UI – genau die Art von Schritt, die bei großem Maßstab versagt.

Das Release gilt sowohl für Google Analytics- als auch für Google Ads-Kunden, aber das Feature bleibt in der Alpha-Phase und ist nicht allgemein verfügbar. Dieser letzte Punkt ist wichtig, denn Alpha bedeutet bei Google historisch gesehen instabile Verträge und stille Fehler – ein produktiver Einsatz dieser Funktion ist daher verfrüht.

Zum zeitlichen Kontext: Im Januar 2026 führte Google drei Beta-Features gleichzeitig ein, nämlich kanalübergreifendes Budgeting, verbessertes Web-Conversion-Management für Ads-Kunden und einen Conversion-Attributions-Analysebericht. Das Release vom 16. Januar führte außerdem Attributionseinstellungen pro Conversion ein, die das bisherige Property-Modell ablösten, bei dem eine Attributionswahl für jedes Conversion-Ereignis einer Property galt. Am 10. Februar wurden generierte Insights zur Analytics-Startseite hinzugefügt, die die drei wichtigsten Datenänderungen seit dem letzten Besuch des Nutzers zusammenfassen – über Konfigurationsaktualisierungen, Anomalien und Saisonalität. Am 29. April wurde der Task Assistant eingeführt, ein geführtes Setup-Tool in der linken Navigation, das Property-Aufgaben wie das Verbinden von Konten und das Beheben von Datenproblemen organisiert. Das API-Release schließt den Kreis: Die UI wurde intelligenter, und jetzt sind die Daten endlich abrufbar.

Technische Details

Das Changelog dokumentiert drei konkrete Ergänzungen. Erstens nimmt das neue ConversionSpec-Feld in RunReportRequest zwei Parameter entgegen. conversionActions akzeptiert Conversion-Action-IDs als Filter, und AttributionModel akzeptiert einen von zwei Enum-Werten: DATA_DRIVEN oder LAST_CLICK. Zwei Modelle, keine weiteren. Das ist eine bewusste Einschränkung.

Zweitens wurde ein Section-Feld zu ResponseMetaData hinzugefügt, das angibt, ob der zurückgegebene Payload aus SECTION_REPORT (Standard-Reporting) oder SECTION_ADVERTISING (der Conversion-Reporting-Oberfläche) stammt. Drittens gibt die getMetadata-Methode in v1 alpha nun conversion-spezifische Metadaten zurück, einschließlich eines conversions-Felds, das Conversion-Action-IDs über eine Liste von ConversionMetadata-Objekten Display-Namen zuordnet. Ein sections-Feld wurde außerdem sowohl zu DimensionMetadata als auch zu MetricMetadata hinzugefügt, das Aufrufern explizit mitteilt, ob eine bestimmte Dimension oder Metrik im Standard-Reporting, im Conversion-Reporting oder in beiden gültig ist.

Dieses letzte Detail ist das, worauf Entwickler achten sollten. Nicht jede Dimension und Metrik, die in einem Standard-Report funktioniert, funktioniert auch in Conversion-Reports – und der Metadata-Endpunkt dokumentiert diese Grenzen nun. Ohne dieses Feld würde man die Grenzen durch fehlschlagende Abfragen entdecken.

Die Wahl des Attributionsmodells ist an sich interessant. Google hat ab 2024 mehrere regelbasierte Attributionsmodelle abgekündigt und das Ökosystem in Richtung datengetriebener Attribution gedrängt. Dass LAST_CLICK hier trotz dieser allgemeinen Abkündigung als gültiger Wert beibehalten wird, signalisiert, dass Google Last-Click als Referenzpunkt für plattformübergreifende Abstimmung betrachtet – nicht als empfohlenes Primärmodell. Die Quelle gibt nicht preis, ob später weitere Modelle hinzugefügt werden. Das ist relevant, denn wenn das Enum für die Dauer der Alpha auf zwei Werte beschränkt bleibt, werden Anbieter, die Reconciliation-Tooling etwa gegen die Conversions API von Meta entwickeln, eine engere Vergleichsbasis haben als gewünscht. Die Grenze liegt heute bei zwei Modellen, ohne öffentliche Roadmap-Zusage darüber hinaus.

Der Conversion-Performance-Bericht selbst unterstützt zwei Zeitdimensionen – Conversion-Zeit und Interaktionszeit – und die Metrik „Alle Conversions" umfasst sowohl primäre als auch sekundäre Conversion-Aktionen. Der Bericht respektiert sowohl Google Analytics-Property-Einstellungen als auch Google Ads-Kontoeinstellungen. Ob die API jeden dieser Schalter in gleicher Weise wie die UI bereitstellt, müssen Entwickler manuell gegen die Alpha prüfen. Wenn ich raten müsste, würde ich erwarten, dass innerhalb von 60 Tagen nach einem breiteren Rollout mindestens eine Lücke zur Parität auftaucht.

Wer betroffen ist

Am stärksten betroffen sind Teams, die Export-und-Zusammenführungs-Pipelines aufgebaut haben, weil die UI die einzige Datenquelle war. Performance-Marketing-Analytics-Gruppen innerhalb von iGaming-Betreibern, Fintech-Akquisitionsteams und Krypto-Börsen, die bezahlten Traffic in großem Maßstab betreiben, haben alle irgendeine Version von „In die UI einloggen, CSV exportieren, ins Warehouse laden, in dbt joinen" praktiziert. Dieser Workflow hat nun einen unterstützten Ersatz, was bedeutet, dass die intern entwickelten Tools darum schnell an Wert verlieren.

Anbieter sind die interessantere Kategorie. Attribution-Plattformen und Marketing-Mix-Modeling-Agenturen, die „GA-Conversion-Datenextraktion" als Feature berechnen, haben nun weniger Alleinstellungsmerkmal. Wenn das Engineering-Team eines Kunden runReport direkt mit einem ConversionSpec aufrufen und gleichwertige Daten erhalten kann, schrumpft der Mehrwert eines Anbieter-Zwischenhändlers auf die Transformations-, Blending- oder Visualisierungsebene, die darüber liegt. Manche Anbieter werden in Ordnung sein, weil ihr Mehrwert im Modeling liegt. Andere haben ihren Preis auf das Zugriffsproblem gestützt – und das Zugriffsproblem wird von der Plattform selbst gelöst.

Ads-Teams, die sich über Reporting-Diskrepanzen zwischen Google Ads und Google Analytics beschwert haben, haben ebenfalls ein neues Werkzeug. Mit Attributionseinstellungen pro Conversion (live seit dem 16. Januar) und nun programmatischem Zugriff auf Conversion-Daten unter sowohl DATA_DRIVEN als auch LAST_CLICK in einer einzigen Pipeline wird die Diagnoseschleife für „Warum sagt Ads X und Analytics Y" deutlich kürzer. Wir wissen noch nicht, wie oft die beiden Modelle in der Praxis für eine gegebene Property voneinander abweichen werden, aber die Grenze ist nun testbar: beide abrufen, vergleichen, den Alert automatisieren.

Wenn sich das so entwickelt wie ich erwarte, sollte der Preisdruck auf GA-Conversion-Extraktions-Features bei Anbietern bis Q3 2026 sichtbar werden, und mindestens ein großer Attribution-Anbieter wird seine Kommunikation noch vor Jahresende von „Wir verbinden mit GA" in Richtung Modellierungstiefe umpositionieren.

Playbook für Performance Marketing

Für Teams, die Paid-Acquisition-Pipelines betreiben, drei Maßnahmen für diese Woche. Erstens: Alpha-Zugang beantragen, wenn das Konto berechtigt ist – aber noch keine Produktions-Reportings migrieren. Alpha-Verträge ändern sich, und die Quelle weist ausdrücklich darauf hin, dass das Feature nicht allgemein verfügbar ist. Eine parallele Pipeline aufbauen, sie neben dem bestehenden exportbasierten Ablauf betreiben und abgleichen.

Zweitens: Das sections-Metadatenfeld bei Dimensionen und Metriken als harten Validator verwenden. Keine Parität mit dem Standard-Reporting annehmen. Ein Discovery-Skript schreiben, das getMetadata aufruft und eine Kompatibilitätsmatrix für den spezifischen Anwendungsfall ausgibt. Das spart wochenlange Fehlersuche, wenn eine Abfrage leere Ergebnisse zurückgibt, weil die Dimension nur für SECTION_REPORT markiert ist.

Drittens: Sowohl DATA_DRIVEN als auch LAST_CLICK im gleichen Job abrufen. Der Aufwand ist ein zusätzlicher API-Aufruf. Der Mehrwert ist eine permanente Reconciliation-Linse zwischen Analytics und dem breiteren Ads API-Ökosystem, wo Last-Click immer noch ein gängiger plattformübergreifender Referenzpunkt ist. Beide Snapshots speichern, die BI-Schicht entscheiden lassen, welchen für welchen Stakeholder anzuzeigen.

Für Platform-Leads bei iGaming- und Fintech-Betreibern speziell sind die im Januar veröffentlichten Attributionseinstellungen pro Conversion das größere langfristige Unlock, denn Einzahlungs-Events und Registrierungs-Events verdienen fast nie dasselbe Attributionsmodell. Das API-Release ermöglicht es, diese Nuance ins Warehouse fließen zu lassen, anstatt sie in einer UI sterben zu lassen.

Zusammenfassung

• Alpha, nicht GA: ConversionSpec befindet sich seit dem 23. April 2026 in v1 alpha. Parallele Pipelines aufbauen, noch nicht auf Produktion umstellen.
• Zwei Attributionsmodelle, Punkt: Nur DATA_DRIVEN und LAST_CLICK sind verfügbar. Die Grenze für modellübergreifende Vergleiche liegt derzeit bei zwei.
• Metadata-first-Entwicklung: Das neue sections-Feld bei DimensionMetadata und MetricMetadata zur Validierung der Kompatibilität nutzen, bevor Report-Abfragen geschrieben werden.
• Anbieter-Moat-Kompression: Anbieter, die Extraktion als Feature verkaufen, verlieren Preismacht. Modeling- und Blending-Anbieter sind geschützt.
• Auf Paritätslücken achten: Die Quelle bestätigt keine vollständige UI-zu-API-Feature-Parität. Mindestens eine Lücke ist innerhalb von 60 Tagen nach dem breiteren Rollout zu erwarten.