300 Anzeigen von Wettbewerbern ins Modell kippen – und vier Adjektive zurückbekommen: So geht es besser

Dreihundert Headlines aus der öffentlichen Anzeigenbibliothek der Konkurrenz liegen vor, und die entscheidende Frage lautet: Was verkaufen diese Anbieter eigentlich? Der naheliegende, aber schlechte Weg ist, alles in den Chat zu kopieren und nach den zentralen Verkaufsargumenten zu fragen. Die Antwort kommt schnell: gutes Preis-Leistungs-Verhältnis, Fokus auf Nutzererlebnis, Dringlichkeit, positiver emotionaler Ton. Vier Sätze, die man auch hätte schreiben können, ohne eine einzige Anzeige zu lesen.

An den Daten liegt es nicht. Die Anzeigenbibliotheken und Creative Center der Plattformen sind öffentlich, lassen sich mit dem eigenen Account durchsuchen, und dabei wird nichts umgangen. Das Problem ist die Fragestellung: Wer dem Modell eine aggregierte Frage stellt, bekommt eine aggregierte Antwort. Dreihundert Anzeigen werden zu vier Adjektiven verdichtet – bei dieser Kompression geht jede verwertbare Information verloren. Übrig bleiben Aussagen, die zwar stimmen können, aber nichts bringen.

Für eine brauchbare Analyse großer Copy-Mengen muss zunächst klar sein, was „brauchbar“ überhaupt bedeutet. „Betont ein gutes Preis-Leistungs-Verhältnis“ ist keine Handlungsanweisung. „Ein Sparversprechen mit Zahlenbeleg und zeitlicher Begrenzung; diese Kombination findet sich in 40% dieser Stichprobe und richtet sich an preissensible Zielgruppen“ dagegen schon. Das sagt direkt, an welchen Variablen das nächste Creative ansetzen kann. Dorthin kommt man nicht mit einem einzigen Prompt, sondern mit zwei getrennten Schritten.

Warum Einmal-Prompts nur vage Allgemeinplätze liefern

Das Scheitern des One-Shot-Ansatzes ist strukturell bedingt, nicht Folge eines schlecht formulierten Prompts.

Das Modell soll gleichzeitig zwei grundverschiedene Aufgaben lösen: Informationen aus jeder einzelnen Anzeige extrahieren und diese Informationen anschließend kategorisieren. Die Extraktion ist weitgehend deterministisch: Welches Versprechen macht die Anzeige, liefert sie einen Beleg? Dafür gibt es im Kern eindeutige Antworten. Die Klassifikation erfordert dagegen Abwägung: Welche Versprechen gehören in dieselbe Kategorie, wo verläuft ihre Grenze? Beides in einen Aufruf zu pressen, lädt das Modell zur Abkürzung ein. Es überspringt die Analyse Anzeige für Anzeige, fasst den Textblock nach Gesamteindruck zusammen und liefert einen Haufen freundlicher Adjektive, von denen es annimmt, dass man sie hören möchte.

Außerdem fehlt bei einem One-Shot-Ergebnis jedes Zwischenprodukt. „Betont ein gutes Preis-Leistungs-Verhältnis“ steht als Fazit da, aber es lässt sich nicht nachvollziehen, aus welchen Anzeigen es stammt, welchen Anteil diese ausmachen oder ob es Gegenbeispiele gab. Mit einer neuen Stichprobe verschiebt sich das Ergebnis womöglich. Eine Analyse ohne Zwischenstand kann weder geprüft noch sinnvoll weiterentwickelt werden.

Zwei Schritte statt einem: erst Felder extrahieren, dann clustern

Der bessere Ablauf besteht aus zwei Schritten mit einer strukturierten Datenebene dazwischen.

Im ersten Schritt wird jede Copy einzeln in ein festes Schema überführt. Mindestens vier Dimensionen sollten dabei erfasst werden: das Kernversprechen, die Art des Belegs, das Dringlichkeitssignal und die implizite Zielgruppe. Jede Anzeige wird separat verarbeitet; die Ausgabe ist strikt JSON, ohne Fließtext.

You will receive one ad headline. Break it apart along the fixed fields below.
Output JSON only, no explanation.

<copy>
{{one piece of copy}}
</copy>

Fields and allowed values (pick only from the given enum; when unsure pick
unknown; do not invent values):

- promise: [save money, save time, look better, get healthier, make money,
  learn a skill, belong, identity, unknown]
- evidence: [testimonial, data/numbers, authority, before/after, demo,
  none, unknown]
- urgency: [time limit, scarcity, price-rise warning, fear of missing out,
  none, unknown]
- audience: a short phrase, inferred from the wording, for who it's talking to
  (e.g. "night owls", "moms with kids", "junior designers")

Output:
{"promise":"...","evidence":"...","urgency":"...","audience":"..."}

Nach der Extraktion von dreihundert Anzeigen liegen dreihundert strukturierte Datensätze vor statt dreihundert Textblöcke. Aus „Fasse die Verkaufsargumente zusammen“ wird damit keine unscharfe semantische Aufgabe mehr, sondern eine Datenaufgabe: zählen, gruppieren, Verteilungen darstellen.

Der zweite Schritt ist das Clustering – und geclustert werden die Felder, nicht die Originaltexte. Wer Rohtexte clustert, landet wieder im Nebel semantischer Ähnlichkeit. Strukturierte Felder gruppieren dagegen über wenige diskrete Dimensionen mit klaren Grenzen.

Clustering, aber mit verpflichtendem Gegenbeispiel

Der entscheidende Teil des Clustering-Prompts ist nicht die Aufforderung „Gruppiere diese Daten“. Entscheidend ist, das Modell zu einem Gegenbeispiel zu zwingen.

Below are N ad headlines already extracted into structured records.
The categories are frozen. Do not add categories.

<records>
{{JSON array, each with promise/evidence/urgency/audience}}
</records>

Output three things in order:

1. Combination clustering
   Group by (promise x evidence x urgency), and give each group's record
   count and one representative sample.

2. Counterexample check
   For the top 3 groups by record count, pick one record per group whose
   audience clearly departs from the group's mainstream, and explain why it
   got grouped there. Is it really the same selling point, or did step one
   extract a field wrong?

3. Gaps
   Which combinations that should be common don't appear even once in this
   batch? Are those gaps "nobody's doing it" or "my sample didn't cover it"?

Der zweite Abschnitt macht diesen Prompt wertvoll. Ein Modell möchte grundsätzlich kooperativ wirken. Ohne Gegensteuerung erscheinen seine Cluster daher verdächtig widerspruchsfrei. Muss es aus einer selbst gebildeten Gruppe einen Datensatz herausziehen, der nicht recht hineinpasst, prüft es weiter, obwohl die Aufgabe für es eigentlich schon erledigt wirkt. Entweder legt es offen, dass eine Klassifikationsgrenze zu grob gezogen wurde, oder es zeigt einen Fehler aus Schritt eins auf.

Das Prinzip, ein Modell an der eigenen Arbeit zweifeln zu lassen, ist nicht auf Anzeigenanalysen beschränkt. Beim Reverse Engineering von Code spricht man von einem Abschnitt für Gegenbelege: Erkennt das Modell eine Algorithmusfamilie, nimmt man das nicht einfach hin, sondern fragt gezielt: „Wo weicht das von der Standardimplementierung ab?“ Dasselbe Prinzip bremst die Neigung des Modells, einfach zuzustimmen – sowohl bei verschleiertem Code als auch bei der Identifikation von Algorithmen per Fingerprinting. Beim Copy-Clustering übernimmt der Gegenbeispiel-Check genau diese Rolle.

Das passende Modell für jeden Schritt

Die beiden Schritte verlangen gegensätzliche Fähigkeiten. Für beide dasselbe Modell einzusetzen, verschwendet Geld:

Der Kostenunterschied um eine Größenordnung entsteht genau durch diese Aufteilung. Die Feldextraktion ist der einzige Schritt, dessen Aufwand linear mit dem Volumen wächst: Dreihundert Anzeigen bedeuten dreihundert Aufrufe, tausend Anzeigen tausend. Das Clustering läuft nur einmal pro Batch. Das teure Reasoning-Modell gehört daher in den Clustering-Schritt, der ein- oder zweimal ausgeführt wird; das günstigste Modell übernimmt die Extraktion, die Hunderte Male läuft. Umgekehrt ist es einer der häufigsten Fälle unnötiger Verschwendung: Für die Extraktion wird zu viel Reasoning bezahlt, während das günstige Modell beim Clustering genau an seiner schwächsten Stelle scheitert.

Wie viel die günstigere Stufe tatsächlich spart, sollte man nicht einfach glauben, sondern in einem Durchlauf prüfen:

1. 20 bis 30 Anzeigen aus dem bereits gesammelten Material auswählen.

2. Felder extrahieren: denselben Batch durch claude-sonnet-5 und claude-opus-5 schicken und die vier Felder Datensatz für Datensatz auf Übereinstimmung vergleichen.

3. Clustern: dieselben extrahierten Datensätze mit beiden Stufen clustern und zwei Fragen prüfen. Hinterfragt der Gegenbeispiel-Check die Gruppen tatsächlich oder formuliert er nur das Ergebnis neu? Und weisen die Lücken auf einen umsetzbaren nächsten Schritt hin?

4. Die Entscheidung ergibt sich direkt daraus: Ist die Übereinstimmung bei der Extraktion hoch, kann dieser Schritt auf die günstige Stufe wechseln und Kosten sparen. Liefert die günstige Stufe beim Clustering kein brauchbares Gegenbeispiel, bleibt dieser Schritt beim Reasoning-Modell.

Falle 1: Das Modell seine Kategorien selbst erfinden lassen

Die einfachste Falle besteht darin, bei der Extraktion kein Enum vorzugeben und das Modell eigene Kategorien erfinden zu lassen.

In einem einzelnen Batch sieht das oft überzeugend aus. Das Modell liefert Kategorien, die vernünftig klingen. Das Problem folgt im zweiten Batch: Ähnliche Copy, aber andere Kategorienamen, andere Granularität, verschobene Grenzen. Legt man beide Batches nebeneinander, um einen Trend zu erkennen, passen sie nicht mehr zusammen. Ist „discount“ im ersten Batch dasselbe wie „save money“ im zweiten? Das weiß niemand. Wenn Kategorien von Batch zu Batch driften, sind Vergleiche über mehrere Batches hinweg wertlos.

Die Lösung ist, das Festlegen der Kategorien klar von ihrer Anwendung zu trennen. Zuerst liest das Long-Context-Modell eine große Stichprobe in einem Durchlauf – mehrere hundert Beispiele auf einmal, genau seine Aufgabe – und leitet daraus ein vollständiges Enum mit einheitlicher Granularität ab. Dieses wird anschließend manuell geprüft und eingefroren. Danach darf die Extraktion nur noch Werte aus diesem festen Enum wählen; unknown dient als Auffangwert. Neue Kategorien dürfen nicht spontan entstehen. Die Vorgabe im Extraktionsprompt, „pick only from the given enum, do not invent“, setzt genau diese Regel um.

In einem Satz: Die Kategorien werden festgelegt, das Modell füllt nur die Felder aus.

Falle 2: Häufigkeit mit Wirksamkeit verwechseln

Nach Extraktion und Clustering liegt es nahe, nach Datensatzanzahl zu sortieren und das häufigste Verkaufsargument für das wirksamste zu halten. Genau dieser Schluss ist leicht zu ziehen – und falsch.

Eine hohe Häufigkeit besagt nur: „Alle formulieren es so.“ Sie sagt nicht: „Diese Formulierung funktioniert.“ Copycat-Ketten sind in der Werbung real: Eine Anzeige funktioniert, innerhalb einer Woche springt der ganze Markt auf, und über Nacht erscheinen Dutzende fast identische Headlines im Creative Center. Die Häufigkeitszählung nimmt all diese Nachahmer auf und erklärt das Verkaufsargument zum beliebtesten, obwohl die gesamte Gruppe vielleicht schlecht performt und nur niemand zuerst ausgestiegen ist. Häufigkeit misst Konformität, nicht Wirkung.

Um Häufigkeit und Wirksamkeit zu trennen, braucht jeder Datensatz Leistungsdaten. Jedes Asset in einer öffentlichen Anzeigenbibliothek enthält Felder wie Play-Zahlen, Likes, CTR und Ähnliches. Sortiert werden sollte daher nicht nach der reinen Datensatzanzahl, sondern nach „dem Anteil einer bestimmten Kombination von Verkaufsargumenten, der in einem hohen Performance-Perzentil landet“. Wie sich sekundengenaue Retention und CTR-Perzentile in aussagekräftige Signale übersetzen lassen, behandelt ein anderer Beitrag. Hier ist vor allem wichtig: Häufigkeitstabelle und Wirkungstabelle müssen zwei getrennte Tabellen bleiben. Sobald beides vermischt wird, ist das Fazit verfälscht.

Die Aufgabe des Modells lautet an dieser Stelle Attribution, nicht Sortierung. Eine häufige Kombination wird zusammen mit ihrer Leistungsverteilung an die mittlere Reasoning-Stufe gegeben, die anhand der Zahlen beurteilt: „Ist diese Häufigkeit hoch, weil die Kombination funktioniert, oder weil sich die Anbieter gegenseitig kopieren?“ Eine falsche Attribution ist dabei wenig dramatisch, denn die abschließende Validierung erfolgt ohnehin gegen reale Leistungsdaten.

Falle 3: Nur Gewinner analysieren

Die dritte Falle steckt in der Datenquelle und bleibt leicht unbemerkt: Anzeigenbibliotheken und Creative Center zeigen standardmäßig oft die gut laufenden Anzeigen. Bereiche wie „hot ads“ oder „Top Ads“ sind im Kern Überlebende, die die Plattform bereits nach Performance vorsortiert hat.

Wer einen Haufen Gewinner clustert, gemeinsame Merkmale erfolgreicher Anzeigen findet und diese kopiert, tappt direkt in den Survivorship Bias. Denn die erfolglosen Anzeigen können sehr gut exakt dieselben Merkmale aufweisen. Angenommen, 90% der Gewinner verwenden eine zeitliche Begrenzung, und daraus folgt der Schluss: „Zeitlimits funktionieren.“ Wenn aber 90% der erfolglosen Anzeigen ebenfalls Zeitlimits einsetzen, besitzt dieses Merkmal keinerlei Trennschärfe. Es ist dann lediglich Branchenstandard und nicht mit Erfolg oder Misserfolg verbunden.

Gewinner brauchen deshalb eine Kontrollgruppe. Öffentliche Anzeigenbibliotheken lassen sich meist nach Branche, Marketingziel und Zeitraum filtern. Mit denselben Filtern lassen sich Assets finden, die zwar Impressionen erhalten haben, aber klar niedriges Engagement zeigen. Auch sie werden extrahiert und geclustert, dann der Gewinnergruppe gegenübergestellt. Wertvoll ist nicht „was Gewinner haben“, sondern die Differenzmenge: „Was Gewinner haben, was Verlierer nicht haben.“ Nur ein Merkmal, das in dieser Differenzmenge auftaucht, gehört als Hypothese in das nächste Asset.

Eine vollständige Verlierer-Stichprobe wird es nicht geben – das ist in Ordnung. Schon eine kleine Kontrollgruppe mit schwacher Performance ist deutlich glaubwürdiger als jede Schlussfolgerung aus Top Ads allein.

Am Ende steht eine Variablentabelle, keine Zusammenfassung

Wer die zwei Schritte durchläuft und die drei Fallen vermeidet, sollte nicht mit einem Absatz wie „Die Wettbewerber in diesem Batch setzen auf XX“ enden. Das führt direkt zurück zu den unbrauchbaren Allgemeinplätzen. Das eigentliche Ergebnis ist eine Variablentabelle:

• Welche Werte jede Dimension annimmt: Versprechen, Beleg, Dringlichkeit und Zielgruppe.

• Welche Kombinationen bereits als wirksam validiert sind – in der Differenzmenge und in einem hohen Performance-Perzentil.

• Welche Kombinationen noch niemand getestet hat – ermittelt aus dem Abschnitt zu den Lücken.

Diese Tabelle kann direkt als Input für eine Generierungsaufgabe dienen. Die validiert wirksamen Kombinationen fließen in die massenhafte Erstellung von Varianten, unbesetzte Kombinationen werden als kostengünstige Tests eingesetzt. Die Copy-Variablen steuern ein Textmodell für Skripte; visuelle und tonale Variablen steuern Bild- und Videomodelle für die Assets. So schließt sich der Weg von der Wettbewerber-Copy bis zum eigenen fertigen Spot. Genau diese Variablentabelle liest die Briefing-Phase in der Creative-Pipeline.

Clustering dient nicht dazu, ein hübsches Klassifikationsdiagramm zu erzeugen. Es soll die Tabelle liefern, die die nächste Produktionsrunde steuert.

Ein API-Key für alle vier Modellstufen

Der beschriebene Ablauf braucht vier Stufen: eine günstige, hochparallel arbeitende Stufe für die Extraktion, eine Long-Context-Stufe für das Festlegen der Kategorien, eine Reasoning-Stufe fürs Clustering und eine mittlere Reasoning-Stufe für die Attribution. Sie kommen von mehreren Anbietern mit unterschiedlichen SDKs, Authentifizierungsschemata und Fehlerformaten. Nur um zwischen den Schritten Modelle zu wechseln, mehrere Schnittstellen an den Client anzubinden, lohnt sich kaum. Das ist der eigentliche Grund, warum viele alles mit einem Modell erledigen – und dann genau die zuvor beschriebene Verschwendung erleben: entweder verbrennt ein teures Modell Budget bei der Extraktion, oder ein günstiges Modell scheitert beim Clustering am Gegenbeispiel.

AIReiter vereinheitlicht diese Schicht: ein Key, eine OpenAI-kompatible Schnittstelle, alle vier Stufen dahinter. Zum Wechseln genügt es, im Request-Body das Feld model zu ändern.

# Extract fields: the cheap high-concurrency tier
curl https://aireiter.com/api/v1/chat/completions \
  -H "Authorization: Bearer $AIREITER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-5",
    "messages": [{"role": "user", "content": "<extraction prompt + one piece of copy>"}]
  }'

# Cluster: switch to the reasoning tier, leave the rest
#   "model": "claude-opus-5"
# Frequency attribution:
#   "model": "gpt-5.6-sol"

Wer bereits das OpenAI SDK nutzt, setzt base_url auf https://aireiter.com/api/v1 und muss sonst nichts ändern. Beim Anthropic SDK wird mit demselben Key POST /api/v1/messages aufgerufen.

Preislich laufen Claude-Modelle mit 30% Rabatt auf den Listenpreis, GPT-Modelle zum halben Preis. Der Rabatt trifft genau den kostentreibenden Teil dieses Ablaufs. Die Feldextraktion ist der einzige linear mit dem Volumen wachsende Schritt: Dreihundert Anzeigen bedeuten dreihundert Aufrufe, tausend Anzeigen tausend. Sie läuft auf der günstigsten Sonnet-Stufe, zusätzlich mit 30% Rabatt, und erzeugt den Großteil der Ersparnis. Clustering und Attribution laufen nur einige Male pro Batch, daher fällt die Reasoning-Stufe dort kaum ins Gewicht. Die Kategoriefestlegung erfolgt einmal pro Batch mit dem Long-Context-Modell Kimi K3, das über denselben Key verfügbar ist.

• API-Key holen

• Ohne Anmeldung ausprobieren: Zunächst einige Anzeigen manuell durchlaufen lassen, die günstige Stufe und die Reasoning-Stufe bei Extraktionsübereinstimmung und Clustering-Gegenbeispielen vergleichen und den Prozess erst automatisieren, wenn er zuverlässig funktioniert.

Fazit

Wenn die Analyse großer Mengen an Anzeigen-Copy nur Allgemeinplätze liefert, liegt das nicht an einem schwachen Modell. Der Fehler besteht darin, Extraktion und Klassifikation in einen einzigen Aufruf zu pressen.

Der Ablauf sollte daher zweigeteilt sein: Pro Anzeige strukturierte Felder anhand eines eingefrorenen Enums extrahieren und diesen Schritt Hunderte Male auf der günstigen Stufe ausführen. Anschließend die Felder clustern, ein Gegenbeispiel erzwingen und dafür einmal die Reasoning-Stufe einsetzen. Dabei die drei Fallen im Blick behalten: Das Modell darf keine Kategorien spontan erfinden, Häufigkeit ist nicht Wirksamkeit, und Gewinner brauchen eine Kontrollgruppe. Das Ergebnis ist eine Variablentabelle für die nächste Produktionsrunde – nicht der Satz „betont ein gutes Preis-Leistungs-Verhältnis“.

Das Modell übernimmt in diesem Ablauf zwei getrennte Rollen: günstiger Extraktor und selbstkritischer Klassifikator. Werden beide auf den passenden Stufen eingesetzt, liefern einige hundert Anzeigen verwertbare Erkenntnisse. Werden sie in einem Modell und einem Aufruf vermischt, bleiben nur Adjektive.