Eine konversionsoptimierte Kampagne bietet auf genau ein Ereignis, und das steht nach dem Anlegen fest
Beim Anlegen einer Kampagne in ChatGPT Ads wählst du, wonach ausgeliefert wird, und die Doku zu den konversionsoptimierten Kampagnen stellt drei Möglichkeiten nebeneinander. Auf Einblendungen zahlst du je tausend Einblendungen und bekommst breite Auslieferung. Auf Klicks zahlst du je gültigem Klick, ausgesucht werden dann Klicks von Menschen, die wahrscheinlich reagieren. Die dritte Möglichkeit heißt oCPC: bezahlt wird weiter je gültigem Klick, ausgesucht werden dabei die Klicks, die eher zu einem bestimmten Vorgang auf deiner Seite führen.
Dieser Vorgang ist die Konversion, also die Handlung auf deiner eigenen Seite, die du als Ergebnis zählst und an OpenAI meldest. Welche Handlung das ist, entscheidest du, und für die Auslieferung zählt genau eine davon. Unter den Voraussetzungen steht das so:
You have exactly one active standard conversion event to use as the optimization goal. Custom events cannot be oCPC optimization goals.
Standardereignisse sind die zwölf Namen, die OpenAI selbst vergeben hat. Ein eigenes Ereignis, in der Schnittstelle der Platzhalter custom mit einem Namen deiner Wahl, darf gemessen werden. Als Optimierungsziel schließt der zitierte Satz es aus.
Im selben Abschnitt steht, wie fest diese Wahl ist: "Each oCPC campaign uses one selected conversion event, and you cannot change the goal or event after campaign creation." Eine laufende Kampagne auf Einblendungen oder Klicks lässt sich ebenfalls nicht umstellen, dafür braucht es eine neue Kampagne. Und das Werbekonto muss Konversionsgebote überhaupt freigeschaltet haben: fehlt das, antwortet das Anlegen laut Doku mit dem Fehler 403 und dem Hinweis "Conversion bidding is not enabled".
Abgerechnet wird dabei weiter der Klick. OpenAI schreibt dazu "Billing does not change to pay per conversion" und bezeichnet den Preis je Konversion, den du einträgst, als Eingabe für die Auslieferung. Er steuert, wie stark die Kampagne um diese Konversionen mitbietet, während dir gültige Klicks berechnet werden.
Das abgeschickte Formular steht am Ende der Strecke und kommt seltener als alles davor
Wer ein Formular abschickt, hat vorher die Seite geladen, auf der es steht. Die Zahl der abgeschickten Formulare kann deshalb nie über der Zahl der Aufrufe dieser Seite liegen, und dasselbe gilt für jede Station davor. Das folgt aus der Reihenfolge und braucht keine Messung.
Für eine oCPC-Kampagne ist genau diese Zahl der Beitrag, den du zur Auslieferung lieferst. Die Doku zählt auf, was die Auslieferung zusammenzieht:
oCPC uses your selected conversion event together with ad quality, relevance, click likelihood, and conversion likelihood to favor clicks that are more likely to lead to that event.
Fünf Eingaben stehen in dem Satz, und vier davon bildet OpenAI aus dem eigenen Bestand: Anzeigenqualität, Relevanz, Klickwahrscheinlichkeit und Konversionswahrscheinlichkeit. Die fünfte ist das Ereignis, das du auswählst und meldest. Meldest du dafür ausschließlich das abgeschickte Formular, besteht dein Beitrag aus dem seltensten Vorgang deiner Strecke, und die Auslieferung sucht nach Klicks, die eher zu einem abgeschickten Formular führen.
Genug Volumen verlangt OpenAI für das Ziel, eine Zahl nennt die Doku dazu nicht
Unter den fünf Ratschlägen zur Verbesserung steht der Satz, um den es hier geht: "Use a conversion event with enough volume to evaluate performance." In derselben Liste stehen der Rat, das Standardereignis zu wählen, das dein Kampagnenziel am besten abbildet, und der Rat, vor größeren Änderungen an Geboten, Budgets oder Anzeigen erst genug Volumen abzuwarten.
Was "genug" bedeutet, steht dort nicht. Wir haben die Seite am 04.09.2026 vollständig gelesen; sie nennt an keiner Stelle eine Anzahl Konversionen je Woche, je Kampagne oder für einen Lernzeitraum. In der Doku steht damit eine Anforderung ohne Schwelle, und die Prüfung, ob dein Ziel sie erfüllt, bleibt bei dir.
Zwei dieser Ratschläge ziehen dabei in verschiedene Richtungen. Der eine will das Ereignis mit der klarsten Geschäftsbedeutung, der andere will Volumen. Auf einer Anfragestrecke fallen die beiden auseinander, weil der Vorgang mit der klarsten Bedeutung am Ende steht und dort am seltensten vorkommt.
Vor dem Kauf liegen vier Ereignisnamen, vor der abgeschickten Anfrage nur zwei
Am 04.09.2026 führt die Liste der unterstützten Ereignisse zwölf benannte Ereignisse und dazu den Platzhalter custom. Welche Namen das im Einzelnen sind und welche Datenform jeder verlangt, steht im Bericht Conversion-Tracking für ChatGPT Ads einrichten, ohne doppelt zu zählen. Für die Wahl des Ziels zählt hier, in welcher Reihenfolge sie auf einer Strecke liegen.
Für einen Shop liegen fünf dieser Namen auf einer Strecke. page_viewed steht laut Tabelle für den Aufruf einer wichtigen Seite, contents_viewed für den Blick auf ein einzelnes Produkt, ein Angebot, einen Artikel oder eine andere Inhaltseinheit, items_added für das Legen eines oder mehrerer Artikel in Warenkorb, Bündel oder Auswahl, checkout_started für den Beginn der Kasse und order_created für den abgeschlossenen Kauf. Eine Abfolge schreibt die Liste selbst nicht vor, sie ergibt sich aus diesen Beschreibungen. Zwischen den ersten beiden zieht OpenAI dabei eine ausdrückliche Grenze: page_viewed gehört zum Laden einer Seite, contents_viewed zum Ansehen eines bestimmten Inhalts, auch wenn das erst nach dem Laden geschieht.
Wer über die Seite Anfragen sammelt, findet in derselben Liste eine kürzere Strecke. Am Ende stehen lead_created für das abgeschickte Anfrageformular oder die Bitte um Kontakt, appointment_scheduled für den gebuchten Termin, die Demo oder das Beratungsgespräch und registration_completed für eine abgeschlossene Anmeldung. Davor bleiben als Standardnamen nur zwei: contents_viewed für den Blick auf das Angebot und page_viewed für den Aufruf der Seite. Das begonnene Formular, der zweite von vier Schritten, der geöffnete Rechner: für solche Zwischenschritte gibt es keinen benannten Ereignisnamen, sie laufen als custom, und custom scheidet als Ziel aus.
Ein früheres Ereignis kommt häufiger und sagt weniger darüber, ob daraus ein Geschäft wird
Die Rechnung hat zwei Seiten, und die zweite wird beim Vorziehen des Ziels leicht übersehen.
Nimmst du page_viewed als Ziel, meldest du der Kampagne einen Vorgang, den der Klick auf die Anzeige selbst auslöst, weil dabei die Zielseite geladen wird. Wer so optimiert, kauft Aufmerksamkeit ohne erkennbare Absicht dahinter: die Auslieferung sucht dann Klicks, die eher zu einem Seitenaufruf führen, und rückt damit nahe an die Kampagne auf Klicks aus derselben Tabelle, die laut Doku Klicks von Menschen sucht, die wahrscheinlich reagieren. Der Aufwand für die Messung ist damit bezahlt, ohne dass die Auslieferung etwas über die Kaufabsicht erfährt.
Am anderen Ende der Strecke steht das umgekehrte Problem. Die Meldungen tragen dort die volle Geschäftsbedeutung und kommen selten, und die Auslieferung entscheidet auf dünner Grundlage.
Dazwischen liegen die Stationen, die von beidem etwas haben. In einem Shop sind das items_added und checkout_started: beide setzen eine Auswahl voraus, und beide können nach der Reihenfolge nicht seltener vorkommen als der Kauf. Auf einer Anfragestrecke ist es contents_viewed auf der Seite, die das Angebot trägt.
Welche Station bei welchem Volumen die bessere ist, haben wir nicht gemessen. Die Doku beantwortet die Frage ebenfalls nicht; sie verlangt nur beides zugleich, ein Ereignis, das das Kampagnenziel abbildet, und genug Volumen, um die Leistung zu beurteilen.
Ob der gemeldete Betrag die Auslieferung bewegt, sagt die Doku nicht
Jedes Ereignis darf einen Betrag tragen. Die Ereignisliste sieht dafür das Feld amount vor, verlangt zusammen damit eine Währung und will den Wert als ganze Zahl in der kleinsten Einheit dieser Währung, bei Euro also in Cent.
Wer daraus schließt, ein hoher Betrag ziehe die Auslieferung zu den wertvollen Fällen, findet dafür in der Doku keine Stütze. In der Aufzählung, woraus oCPC seine Entscheidung bildet, stehen das gewählte Ereignis, Anzeigenqualität, Relevanz, Klickwahrscheinlichkeit und Konversionswahrscheinlichkeit. Der gemeldete Betrag steht dort nicht. Das Gebot selbst hängt als Preis je Konversion an der Anzeigengruppe, also an der Ebene unter der Kampagne, in der die Anzeigen liegen, und es ist eine einzige Zahl für alle Konversionen dieses Ereignisses.
Für die Namensvergabe heißt das, mit dem dokumentierten Stand zu planen. Solange dort keine Wirkung des Betrags beschrieben ist, muss man damit rechnen, dass zwei verschieden wertvolle Handlungen unter demselben Ereignisnamen für die Auslieferung gleich zählen und die Kampagne die günstigere davon einsammelt. Wer die beiden auseinanderhalten will, meldet sie deshalb unter verschiedenen Namen, und weil die Ereignisliste für den Unterschied zwischen einer kleinen und einer großen Anfrage keinen zweiten Standardnamen führt, bekommt eine der beiden einen selbst vergebenen Namen und scheidet damit als Ziel aus.
Messen und Bieten sind zwei Entscheidungen, und nur das Bieten ist auf ein Ereignis begrenzt
Eine Ereignisdefinition verbindet einen Ereignisnamen mit einer Messquelle, also mit dem Messpixel, dem kleinen Skript, das im Browser deiner Besucher läuft und die Meldungen absetzt. Die Referenz zur Einrichtung der Messung verlangt dafür genau eine Quelle je Definition und ein Zuordnungsfenster in Tagen, also die Frist, innerhalb der eine spätere Konversion noch dem Klick auf die Anzeige zugerechnet wird; empfohlen ist der Wert 30.
Wie viele solcher Definitionen ein Konto führen darf, begrenzt die Doku an dieser Stelle nicht. Begrenzt ist das Ziel: eine aktive Standarddefinition je oCPC-Kampagne. Die Frage "was messe ich" und die Frage "worauf biete ich" haben damit zwei verschiedene Antworten, und die erste darf großzügiger ausfallen als die zweite. Die frühen Ereignisse zeigen dir, an welcher Station die Leute abspringen, auch wenn keines von ihnen die Auslieferung steuert.
Was davon später im Bericht steht, nennt die Doku ebenfalls: Einblendungen, Klicks, Konversionen, Ausgaben, Klickrate und durchschnittlicher Klickpreis nebeneinander, dazu die Kosten je Konversion aus Ausgaben geteilt durch Konversionen. Ob die Konversionen dort nach Ereignisdefinition getrennt ausgewiesen werden, schreibt die Seite nicht.
Ein Abschluss, der erst Wochen später feststeht, lässt sich nicht mehr melden
Zwei Fristen begrenzen, was überhaupt als Konversion ankommt. Das Zuordnungsfenster einer Definition steht bei den empfohlenen 30 Tagen, und was danach passiert, wird dem Klick nicht mehr zugerechnet. Ein Ereignis, das dein Server nachreicht, muss laut Seite zur Conversions API einen Zeitstempel aus den letzten sieben Tagen tragen und darf höchstens zehn Minuten in der Zukunft liegen. Für Einblendungen ohne Klick gilt daneben ein festes Fenster von einem Tag, und trifft beides zu, gewinnt die Zuordnung über den Klick.
Die zweite Frist trifft die Fälle, in denen du erst später erfährst, dass etwas zustande gekommen ist. Ein Abschluss, der nach einem Telefonat und einem Angebot feststeht, kann außerhalb beider Fenster liegen, und dann gibt es keinen dokumentierten Weg, ihn mit seinem eigenen Zeitpunkt nachzureichen.
Für die Wahl des Ziels heißt das: das Ereignis, das den Geschäftswert wirklich trägt, steht der Optimierung womöglich gar nicht zur Verfügung. Als Ziel bleiben dann die Vorgänge, die auf der Seite selbst stattfinden und innerhalb der sieben Tage gemeldet werden können, und darunter ist zu wählen.
Auf ein früheres Ziel umzustellen kostet eine zweite Ereignisdefinition und eine zweite Kampagne
Wer eine Anfragestrecke misst, landet mit den Standardnamen zwangsläufig an ihrem Ende. Das abgeschickte Anfrageformular, der gebuchte Termin und die abgeschlossene Anmeldung sind dort die einzigen benannten Ereignisse, und der Anfang derselben Strecke, also das begonnene Formular oder der zweite von vier Schritten, trägt einen selbst vergebenen Namen und ist als Ziel dauerhaft ausgeschlossen. Ein früheres Ziel gibt es auf dieser Strecke deshalb nur über die beiden frühen Standardnamen, den Aufruf einer wichtigen Seite und den Blick auf ein einzelnes Angebot.
Angelegt sein muss eine solche Definition, bevor die Kampagne entsteht, die auf sie bietet. Eine zusätzliche Definition allein reicht nicht, weil das Ziel einer bestehenden Kampagne feststeht: es braucht die Definition und dazu eine zweite Kampagne. Wer die frühen Standardnamen von Anfang an mitmisst, hat diese Definition schon liegen, wenn sich das späte Ziel als zu dünn erweist.
Inzwischen sind zwei Kampagnen gelaufen, über die Wahl des Ziels sagt das nichts
Alles bis hierher stammt aus der Doku von OpenAI. Ausgeliefert hat inzwischen auch etwas: eine Nacht und einen Vormittag lang liefen am 05. und 06.09.2026 zwei Kampagnen, sie brachten 11.789 Einblendungen und 90 Klicks, und weder eine Konversion noch eine Anfrage kam dabei zustande. Was in dieser Auswertung steht und was ihr fehlt, führt der Bericht 150 Euro ChatGPT Ads Test aus.
Bei null Konversionen fehlt die Meldung, an der sich ablesen ließe, wie stark ein Ziel die Auslieferung lenkt. Ungemessen bleibt damit, wie viele Meldungen je Woche ein Ziel bei ChatGPT Ads tragen muss, bevor die Auslieferung sichtbar darauf reagiert, und ob ein früheres Ziel bei gleichem Einsatz am Ende mehr Anfragen bringt und was eine Anfrage dann kostet. Beantworten lässt sich beides erst, wenn zwei Kampagnen mit verschiedenen Zielen nebeneinander gelaufen sind.
Was in diesem Fall gilt
Wer bei ChatGPT Ads auf Konversionen bieten will, legt das Ereignis beim Anlegen der Kampagne fest und kann es danach nicht mehr wechseln. Auf einer Anfragestrecke bleiben dafür nach der Doku vom 04.09.2026 die späten Ereignisse, weil die Schritte davor keinen Standardnamen tragen und ein selbst benanntes Ereignis als Ziel ausscheidet. Ein früheres Ziel setzt eine eigene Ereignisdefinition und eine zweite Kampagne voraus, und ob sich das lohnt, entscheidet die Zahl der Meldungen, die zusammenkommt: in unseren ersten beiden Kampagnen am 05. und 06.09.2026 kamen bei 11.789 Einblendungen und 90 Klicks null zusammen.
