Übersicht, Referenz und Hilfecenter beantworten drei verschiedene Fragen
Bei OpenAI beschreiben drei Sorten Seite denselben Werbekanal, und jede von ihnen beantwortet eine andere Frage.
Die Übersichtsseite erklärt, wie etwas gemeint ist. Sie ordnet die Begriffe, nennt die Bausteine und sagt, wofür das Ganze da ist. Die Übersicht zur Werbe-API von OpenAI ist so eine Seite: sie führt die Ressourcen in einer Tabelle auf, erklärt knapp, wie man sich mit einem Schlüssel anmeldet, und nennt als Ratengrenze 600 Anfragen je Minute und Endpunkt.
Die Referenz sagt, welche Felder es gibt. Sie ist die Stelle, an der ein Feldname, ein Pflichtfeld oder ein erlaubter Wertebereich steht, und sonst nirgends. In der Referenz zu den Anzeigen steht deshalb, dass die Überschrift einer Anzeige zwischen 3 und 50 Zeichen lang sein muss und dass der Prüfstand einer Anzeige, also das Feld mit dem Ergebnis ihrer Prüfung durch OpenAI, genau drei Werte kennt: in_review, rejected und approved.
Das Hilfecenter beschreibt, was der Betrieb tatsächlich macht. Dort steht, dass eine offene Kontoprüfung die Auslieferung aufhält, dass eine gescheiterte Kartenzahlung die Auslieferung stoppen kann und dass der Support weder eine Kontoprüfung noch eine Anzeigenprüfung beschleunigt.
Wer nur eine dieser drei liest, baut auf einer halben Auskunft. Die drei Seiten haben verschiedene Leser und verschiedene Zwecke, und jede erfüllt ihren. Der Schaden entsteht in dem Moment, in dem ein Leser eine davon für vollständig hält.
Wir haben am 04.09.2026 sechs Seiten der Werbe-Dokumentation von OpenAI und ihre maschinenlesbare Fassung gegen fünf Seiten des Hilfecenters gelesen. Drei Stellen sind dabei herausgekommen, an denen beide Seiten etwas Verschiedenes sagen, dazu eine Feldliste, die kürzer ist als die Antwort, die sie beschreibt, und eine Zeitangabe, die auf drei Seiten dreimal anders lautet.
Auf die Frage, wann eine Anzeige ausliefert, geben drei Seiten drei verschiedene Antworten
Das ist die erste Frage, die jemand stellt, dessen Kampagne steht und nichts tut.
Die Übersichtsseite beantwortet sie unter der Zwischenüberschrift "Object statuses" so:
For an ad to show to users, the ad and its parent ad group and campaign all have to be enabled. The ad also has to be reviewed. Reviews typically take only a few minutes.
Vier Bedingungen also: Anzeige, Anzeigengruppe und Kampagne müssen aktiv sein, dazu muss die Anzeige geprüft sein. Wer nur diese Seite liest, hält das für die vollständige Liste und wartet auf eine Prüfung, die in wenigen Minuten durch ist.
Die Referenz zum Werbekonto trägt eine fünfte Bedingung nach, die in der Übersicht fehlt:
Poll
GET /ad_accountuntilreview.statusisapproved. An account with any other review status cannot serve ads.
Das Konto selbst hat also einen Prüfstand, und steht der auf irgendetwas anderem als approved, liefert nichts aus. In der Feldbeschreibung derselben Seite heißt dieses Feld die Markenprüfung des Kontos, und weiter oben steht, was sie auslöst: ein neuer Kontoname oder ein neues Bildzeichen über POST /ad_account/brand startet sie erneut.
Die Seite mit den häufigen Fragen im Hilfecenter beantwortet dieselbe Frage mit fünf Punkten, von denen drei auf keiner der beiden Doku-Seiten stehen: das Kampagnenbudget darf nicht erreicht sein, das Enddatum nicht überschritten, und mit der Zahlungsmethode darf nichts im Argen liegen. Die Anleitung zur Fehlersuche nennt dieselben Punkte und schiebt eine Zeitangabe nach, die alles davor relativiert: zwischen der Auslieferung einer Anzeige und ihrem Erscheinen im Bericht liegen typischerweise bis zu sieben Stunden, und vor Ablauf von 24 Stunden nach dem Start soll man ein Auslieferungsproblem gar nicht erst melden.
Eine weitere Bedingung steht mitten im dritten Einrichtungsschritt der Hilfeseite zur Kontoeinrichtung und in keiner der Prüflisten oben: unter Einstellungen und "Account info" müssen Kontoname und Logo genau so eingetragen sein, wie sie in der Anzeige erscheinen sollen. Der Satz darunter lautet "Ads will not serve unless this step is complete."
Neun Bedingungen kommen so zusammen, verteilt auf vier Seiten, und keine dieser vier Seiten nennt alle neun.
Die Kontoreferenz zählt acht Felder auf, und das Feld, an dem die Auslieferung hing, fehlt darin
Die Referenz zum Werbekonto beschreibt, was ein Aufruf von GET /ad_account zurückgibt, und sie tut das in der Form, die eine Referenz auszeichnet: als Liste. Acht Einträge stehen darin: id, name, url, preview_url, status, timezone, currency_code und review. Darüber steht ein Beispiel für die Antwort, und es enthält dieselben acht Felder.
In dem Konto, das wir für den Bericht Dein Konto wird vorbereitet am 03.09.2026 ausgelesen haben, kam ein neuntes Feld zurück. Es heißt account_integrity_review, es hatte einen eigenen Stand, und es war das Feld, an dem die Auslieferung hing: der in der Referenz beschriebene Prüfstand stand seit dem 02.09.2026 um 15:27 auf approved, während dieses hier seit dem 01.09.2026 um 07:41 UTC auf in_review stand.
Unbekannt ist das Feld OpenAI nicht. Es steht in der maschinenlesbaren Fassung der Schnittstelle, die dieselbe Übersichtsseite zum Herunterladen anbietet: in der Fassung 2.3.0, geladen am 04.09.2026, führt sie account_integrity_review am Werbekonto. Nachgezählt haben wir das in Dein ChatGPT-Ads-Konto überwachen.
Auf der Seite, die ein Mensch liest, fehlt es, und das ist unangenehmer als ein Widerspruch zwischen zwei Seiten. Eine Feldliste liest sich wie eine vollständige Aufzählung, und ein Widerspruch fällt beim Vergleichen auf. Eine Auslassung bleibt unsichtbar, bis eine echte Antwort mehr enthält als die Liste.
Dass es diese zweite Prüfung gibt, steht im Hilfecenter, und zwar in der Kontoeinrichtung unter einer Frage, die niemand stellt, der eine API anbindet:
Verification and account review are separate steps. Completing an identity or business verification flow does not always mean the ad account is ready to run campaigns immediately.
Die Seite mit den häufigen Fragen führt diese Trennung nicht. Sie fasst beides unter "Account verification" zusammen und schreibt, ein Hinweisband im Anzeigenmanager, also in der Oberfläche, in der du Kampagnen selbst anlegst und ihre Zahlen abliest, fordere dann zum Nachholen auf. In unserem wartenden Konto stand dort am 03.09.2026 der Satz "Du musst derzeit nichts weiter tun", nachzulesen in Dein Konto wird vorbereitet: ein Schritt zum Nachholen war nicht angezeigt.
Beim Produktfeed ist ein Produkt laut Hilfecenter von selbst anzeigenfähig und laut Doku erst mit einem gesetzten Feld
Ein Produktfeed ist eine Datei, in der jede Zeile ein Produkt beschreibt, mit Titel, Preis, Verfügbarkeit, Bild und Zieladresse. OpenAI baut daraus Anzeigen, ohne dass man je Artikel eine eigene anlegt.
Welche Produkte aus dieser Datei überhaupt in Anzeigen dürfen, beantworten die beiden Seiten gegenteilig. Die Hilfeseite zu Feed-Kampagnen sagt es so:
Feeds created through Ads Manager make products ads-eligible by default unless an item is explicitly marked false for ads eligibility.
Anzeigenfähig ist demnach der Normalfall, und wer ein Produkt heraushalten will, markiert es ausdrücklich. Die Doku-Seite zu Produktfeeds dreht die Richtung um. Sie unterscheidet zwei Feed-Arten und schreibt für die Ads-Variante, man müsse jedes Pflichtfeld der Grundspezifikation mitliefern und dazu
set
is_ads_eligibletotruefor every product that Ads should process.
Also für jedes einzelne Produkt, das verarbeitet werden soll. Dieselbe Seite warnt danach vor einem Feldnamen, der naheliegt und ins Leere läuft: die Feed-Verarbeitung liest genau zwei Schreibweisen, nämlich is_ads_eligible und das alte is_eligible_ads, und is_ads_enabled gehört nicht dazu. Dazu hält sie fest, dass die Anzeigenfähigkeit eine notwendige Bedingung ist und dass ein anzeigenfähiges Produkt trotzdem ohne Auslieferung bleiben kann.
Beide Sätze können nebeneinander stimmen, wenn der Anzeigenmanager beim Anlegen eines Feeds das Feld selbst setzt und die Doku den Weg über die Schnittstelle beschreibt. Ausgesprochen ist das an keiner der beiden Stellen. Wer sich auf den Satz aus dem Hilfecenter verlässt und den Feed maschinell erzeugt, lädt im ungünstigen Fall einen vollständigen Katalog hoch, in dem kein einziges Produkt verarbeitet wird.
Dieselbe Katalogdatei kommt laut Hilfecenter auf drei Wegen zu OpenAI und laut Doku auf einem
Auf derselben Hilfeseite steht, wie die Datei ins Konto kommt, und sie nennt dafür drei Wege zur Auswahl: eine CSV- oder TXT-Datei hochladen, eine feste HTTPS-Adresse hinterlegen, von der OpenAI die Datei selbst abholt, oder eine SFTP-Verbindung einrichten. SFTP ist ein Weg, Dateien über eine verschlüsselte Verbindung auf einen fremden Server zu legen. Weil die Einträge nach zwei Wochen verfallen, empfiehlt die Seite die feste Adresse oder SFTP gegenüber dem einmaligen Hochladen.
Die Doku-Seite beschreibt denselben Bereich des Anzeigenmanagers und kennt davon einen Weg. Sie schreibt, man solle den Händlerkatalog an die dort angezeigte SFTP-Adresse laden, und stellt danach klar:
This Ads catalog transfer uses SFTP;
POST /uploadis only for static ad creative assets.
Dazu die Angabe, die den Unterschied erklärt: die öffentliche Schnittstelle hat gar keine Endpunkte, um eine Feed-Verbindung anzulegen, verknüpfte Feeds aufzulisten oder eine Katalogdatei hochzuladen. Aus Sicht eines Entwicklers, der alles über die Schnittstelle erledigen will, bleibt deshalb SFTP übrig. Aus Sicht des Hilfecenters, das die Oberfläche beschreibt, sind es drei Wege, und zwei davon kommen ohne eine eigene Serververbindung aus.
Praktisch heißt das: für einen Shop, der seinen Katalog ohnehin unter einer festen Adresse ausliefert, steht der einfachste Weg allein im Hilfecenter. Wer nur die Entwicklerdoku liest, baut eine SFTP-Anbindung, die er nicht gebraucht hätte.
Der Anzeigen-Crawler steht in der Crawler-Übersicht als eine von vier Kennungen und im Hilfecenter als Pflicht
Bevor eine Anzeige ausliefert, ruft OpenAI ihre Zielseite mit einem eigenen Programm ab, einem Crawler. Er prüft, ob die Seite den Werberichtlinien entspricht, und der Inhalt fließt zusätzlich in die Entscheidung ein, wann die Anzeige einem Nutzer am ehesten passt.
In der Übersicht der OpenAI-Crawler steht dieses Programm als eine Zeile unter vieren, neben dem Such-Crawler, dem Trainings-Crawler und der Kennung für Abrufe, die ein Nutzer selbst auslöst. Die Zeile nennt den vollständigen User-Agent, also die Zeichenkette, an der ein Server den Abrufenden erkennt, dazu die Adresse der veröffentlichten IP-Bereiche. Der einleitende Absatz der Seite handelt davon, wie ein Betreiber die Crawler steuern kann, und hält fest, dass jede Einstellung unabhängig von den anderen ist. Eine Pflicht steht dort nicht.
Die Hilfeseite für Werbetreibende zu diesen Crawlern beantwortet die Frage in fünf Wörtern:
You must allow OAI-AdsBot.
Dieselbe Seite führt drei Ebenen auf, an denen eine Website den Abruf blockiert, und nur die erste davon ist die, an die man denkt. Die robots.txt ist die Datei, in der eine Website den Crawlern mitteilt, welche Pfade sie abrufen dürfen. Darunter liegen vorgelagerte Schutzdienste, die automatisierten Verkehr abwehren und dabei ein 403 zurückgeben. Und darunter liegen Prüfungen in der Anwendung selbst, also Bilderrätsel, JavaScript-Aufgaben und Verhaltensanalysen. Für einen dieser Schutzdienste gibt OpenAI Entwarnung: bei Cloudflare ist der Anzeigen-Crawler offiziell verifiziert und freigegeben.
Auf die Frage, ob der Support die Prüfung von Hand umgehen kann, antwortet die Seite mit "Do not rely on a manual bypass" und der Anweisung, die Zielseite abrufbar zu machen und die betroffenen Anzeigen danach erneut einzureichen, falls ihr Stand sich nicht von allein aktualisiert.
Die Richtung, in die beide Seiten aufeinander zeigen, ist aufschlussreich. Das Hilfecenter verlinkt für die Definition auf die Crawler-Übersicht. Die Anleitung zur Fehlersuche verlinkt bei abgelehnten Anzeigen an derselben Stelle ebenfalls dorthin; die Hilfeseite mit der Pflicht steht dort nirgends. Und die Crawler-Übersicht verlinkt auf keine der beiden zurück. Wer bei der Crawler-Übersicht anfängt, kommt von dort nicht zu der Seite, auf der die Folgen stehen.
Das Wort Prüfung meint auf drei Seiten drei verschiedene Vorgänge, und deshalb widersprechen sich die drei Zeitangaben nicht
Auf die Frage, wie lange eine Prüfung dauert, gibt es drei Antworten, und sie liegen weit auseinander.
Die Übersichtsseite der Werbe-API schreibt "Reviews typically take only a few minutes", also wenige Minuten. Die Hilfeseite zur Kontoeinrichtung nennt gar keine Zahl und begründet das:
Because there is a high volume of applications that are reviewed in a rolling queue, account verification may take some time.
Die Oberfläche des Anzeigenmanagers wiederum nennt eine Spanne von fünf bis sieben Tagen, nachzulesen im Wortlaut in Dein Konto wird vorbereitet.
Minuten, keine Angabe, fünf bis sieben Tage: das sieht nach drei Antworten auf dieselbe Frage aus, und die drei Seiten beantworten drei verschiedene. Die Minuten der Übersichtsseite stehen im Abschnitt über die Zustände von Anzeigen und meinen die Prüfung einer einzelnen Anzeige. Die Hilfeseite spricht vom Antrag auf ein Werbekonto. Und die Spanne in der Oberfläche steht beim Anlegen des Kontos. Drei Vorgänge, drei Dauern, und das gemeinsame Wort "review" verdeckt, dass es drei sind.
Diese Verwechslung hat eine praktische Folge. Wer die Minuten aus der Übersichtsseite auf sein wartendes Konto bezieht, hält für kaputt, was planmäßig läuft, und legt womöglich ein zweites Konto an. Genau davon rät die Hilfeseite zur Kontoeinrichtung ab: doppelte Anträge und doppelte Werbekonten umgehen die Prüfung nicht und stiften Verwirrung darüber, welches das richtige Konto ist.
Seit wann ein Feld existiert, beantwortet allein der Changelog
Eine Referenz beschreibt den heutigen Stand. Sie sagt nicht, seit wann er gilt, und für ein Bauteil, das schon läuft, ist das oft die eigentliche Frage.
Die Seite zur Conversions API, also zur Meldung eines Abschlusses von Server zu Server statt aus dem Browser, beschreibt ein Feld user.obref. Darin wird die Browser-Kennung aus dem Cookie des Messpixels weitergereicht, jenes kleinen Programms, das auf der eigenen Seite die Abschlüsse an OpenAI meldet. Aus der Seite selbst geht nicht hervor, ob dieses Feld seit dem ersten Tag existiert. Der Changelog am Fuß der Übersichtsseite datiert es, also die Liste der Änderungen an der Schnittstelle mit dem Datum jeder einzelnen: am 16.07.2026 kam die Unterstützung dafür dazu. Wer vor diesem Tag angebunden hat, konnte das Feld noch gar nicht mitschicken.
Derselbe Changelog datiert vier weitere Zuwächse, unter anderem die konversionsoptimierte Gebotsabgabe am 16.06.2026 und die Standortsteuerung am 03.06.2026. Auf den sechs Doku-Seiten, die wir an diesem Tag gelesen haben, ist dieser Changelog die einzige Stelle mit einem Datum. Alle fünf gelesenen Hilfeseiten tragen dagegen über der ersten Zeile eine Angabe dazu, wie lange ihre letzte Änderung her ist, am 04.09.2026 zwischen fünf Tagen und einem Monat.
Auch eine vollständige Doku ist kein Beweis, das sagt erst der erste echte Aufruf
Bis hierher ging es darum, welche der beiden Seiten recht hat. Darüber liegt eine Grenze, die für beide gilt.
Im selben Kanal haben wir zwei Fälle gemessen, in denen die Doku-Seite etwas nicht sagte, das im Betrieb trotzdem passiert. Der erste steht im Bericht zum Conversion-Tracking: das Messpixel legt beim Setzen der Einwilligung ein Cookie namens __oaiq_consent auf dem Gerät ab, und in der Aufzählung der Cookies auf der Pixel-Seite steht es nicht. Gefunden haben wir es am 02.09.2026 in der ausgelieferten Programmdatei des Pixels. Der zweite steht im selben Bericht: der Idempotency-Key, also das Kopfzeilenfeld, mit dem eine Schnittstelle zusagen kann, denselben Aufruf nur einmal auszuführen, hat beim Anlegen einer Ereignisdefinition zwei Definitionen im Konto hinterlassen, die sich nicht archivieren lassen. Dass dieser Endpunkt das Feld überhaupt nicht führt, steht allein in der maschinenlesbaren Fassung, nachgezählt in Kampagnen über die Schnittstelle anlegen.
Beide Fälle sind Lücken: die Doku sagte etwas nicht. Der schwerere Fall ist der, in dem sie etwas sagt, das nicht mehr gilt. In einem anderen Werbekanal fand sich am 02.09.2026 ein Dienst von Google vollständig dokumentiert, mit Feldern, Grenzen und Beispielen, und für neue Anbindungen war er längst geschlossen. Zu erfahren war das allein aus der Ablehnung, die auf den ersten echten Aufruf zurückkam; in der Dokumentation stand davon nichts.
Am Ende jeder Recherche, die in Code einfließt, steht deshalb derselbe Schritt: einmal wirklich aufrufen und lesen, was zurückkommt. Für den Widerspruch beim Produktfeed, der oben offen geblieben ist, heißt das, dass der erste hochgeladene Katalog zeigt, ob ein maschinell erzeugter Feed ohne gesetztes Feld für die Anzeigenfähigkeit verarbeitet wird.
Welche Seite recht hat, hängt davon ab, wonach du fragst
Wer beide Seiten liest und sie an einer Stelle gegeneinander stehen sieht, braucht eine Reihenfolge. Aus den Fällen oben ergibt sich eine, die für diesen Anbieter und diesen Kanal gilt.
Für Feldnamen, Pflichtfelder, Wertebereiche und Grenzen gilt die Referenz. Sie ist die einzige Seite, auf der diese Angaben überhaupt stehen, und eine Übersichtsseite, die dasselbe Feld beiläufig erwähnt, ist keine zweite Quelle dafür.
Für die Frage, wie die Teile zusammengehören und wofür ein Baustein gedacht ist, gilt die Übersichtsseite. Sie ordnet, und dafür lässt sie Einzelheiten weg.
Für alles, was der Betrieb macht, gilt das Hilfecenter. Was eine Auslieferung aufhält, was der Support kann, welcher Schritt in der Oberfläche noch offen ist: dort steht es, und die Entwicklerdoku schweigt dazu oder legt etwas anderes nahe. Für die Frage, seit wann etwas gilt, gilt der Changelog.
Bleibt der Fall, in dem beide Seiten dasselbe Verhalten beschreiben und Verschiedenes sagen, wie beim Feld für die Anzeigenfähigkeit. Dann trägt die strengere der beiden Angaben, also die, bei der mehr zu tun ist. Das Feld je Produkt zu setzen kostet nichts, wenn der Anzeigenmanager es ohnehin setzt. Es wegzulassen kostet den ganzen Feed, falls die Doku recht hat. Den Ausschlag gibt damit die Frage, welcher der beiden Fehler sich reparieren lässt.
Über dieser Reihenfolge steht der Aufruf. Ein Vergleich zweier Seiten grenzt ein, was überhaupt der Fall sein kann, und welche der verbliebenen Möglichkeiten zutrifft, zeigt die erste Antwort aus dem laufenden Betrieb.
Was in diesem Fall gilt
Am 04.09.2026 sagen die Werbe-Doku von OpenAI und ihr Hilfecenter an drei Stellen Verschiedenes. Ein Produkt im Feed ist laut Hilfeseite zu Feed-Kampagnen von selbst anzeigenfähig und laut Doku-Seite zu Produktfeeds erst mit is_ads_eligible auf true. Der Katalog kommt laut derselben Hilfeseite über drei Wege ins Konto und laut derselben Doku-Seite über SFTP. Und der Anzeigen-Crawler ist laut Hilfecenter Pflicht, während die Crawler-Übersicht ihn als eine von vier Kennungen beschreibt.
Dazu kommt eine Auslassung: die Referenz zum Werbekonto zählt acht Antwortfelder auf, und das Feld, an dem in einem am 03.09.2026 ausgelesenen Konto die Auslieferung hing, steht allein in der maschinenlesbaren Fassung der Schnittstelle. Auf die Frage, was erfüllt sein muss, damit eine Anzeige ausliefert, kommen über vier Seiten hinweg neun Bedingungen zusammen, von denen keine einzelne Seite alle neun nennt.
Diese Befunde stammen aus einem einzigen Lesetag. Beide Seiten werden weiter geändert, die fünf gelesenen Hilfeseiten mit einer sichtbaren Angabe dazu, wie lange die letzte Änderung her ist, die Doku-Seiten allein über den Changelog der Übersichtsseite. Über andere Anbieter und über den Stand dieser Seiten in einem Monat sagen sie deshalb nichts.
