PPC-Automatisierung war immer möglich. Sie rechnete sich nur nie — bis jetzt.

Das ganze Argument in einem Satz

PPC richtig zu automatisieren war immer möglich — es rechnete sich nur nie, also tat es fast niemand. KI hat uns keine neuen Kräfte verliehen; sie ließ die Kosten zusammenfallen, die alten zu nutzen, und genau diese eine ökonomische Verschiebung legt ein Jahrzehnt voller „würden wir gern, aber es würde sich nie lohnen” zurück auf den Tisch. Alles, was folgt, ist der Beweis — erzählt aus dem Inneren der Werkzeuge, mit denen ich tatsächlich baue, nicht von einer Hersteller-Keynote.

Was Sie aus diesem Stück konkret mitnehmen: die drei Ären, die PPC-Automatisierung zu teuer machten, um sich die Mühe zu lohnen, den genauen Moment, in dem dieses Jahr die Rechnung kippte, und einen echten Job — das Ausmisten von Müll-Suchanfragen mit einem lokalen Open-Source-Modell — Schritt für Schritt aufgeschlüsselt, mit dem Zwischenoutput, auf den Sie in jeder Phase starren würden. Am Ende können Sie den Unterschied erkennen zwischen „KI gab uns neue Fähigkeiten” (meistens falsch) und „KI änderte, wer sich die alten leisten kann” (das, worauf es wirklich ankommt) — und Sie haben einen Ablauf, den Sie kopieren können.

Zwischen 2015 und 2017 betrieb ich ein kleines Blog über Google Ads Scripts, dann hörte ich auf zu schreiben. Nicht weil die Ideen ausgingen — sondern weil die Lücke zwischen „das ist möglich” und „das lohnt sich für einen Kunden” ein Jahrzehnt lang hartnäckig breit blieb. Fast alles, was Sie darüber gelesen haben, dass KI den PPC-Spezialisten tötet, dreht den Mechanismus falsch herum. KI hat nicht verändert, was Sie im Paid Search tun können. Das meiste war schon immer möglich. Was sich änderte, ist wer es tun kann und zu welchen Kosten — und das wiegt viel schwerer als ein weiteres Auto-Bidding-Feature. Lassen Sie mich Ihnen zeigen, woher ich das weiß.

Die Scripts-Ära: ein paar Tage für ein „einfaches” Script

Warum ich hier beginne: um Ihnen zu zeigen, dass die Decke nie die Technologie war. Es war die Arbeit, vom allerersten Werkzeug an, das ich anfasste.

Google Ads Scripts fühlten sich wie Magie an, als sie kamen. JavaScript, direkt im Konto, das über Kampagnen iteriert. In der Praxis war ein „einfaches” Script — Keywords über einem CPA-Schwellenwert pausieren, kaputte Final URLs melden — ein paar Tage Schreiben und Debuggen, sobald Sie die Sonderfälle, die Quotas und die stillen Fehler im Griff hatten.

Dann kam der Teil, den niemand einplante: es über mehrere Konten laufen zu lassen. Ein Script pro Konto, kopiert, immer weiter auseinanderdriftend, das leise brach, sobald die Namenskonvention eines Kunden nicht zu den anderen passte. Skalierung und Verteilung waren ein eigener Job. Also kamen die meisten Scripts in freier Wildbahn nie über Reporting hinaus — ein paar Zahlen nach Plan in ein Sheet ziehen. Alles, was das Konto tatsächlich veränderte, war zu fragil und zu teuer im Unterhalt, als dass es sich für die meisten Agenturen gelohnt hätte.

Die Erkenntnis, die Sie mitnehmen: Selbst die „einfache” Automatisierungsebene war durch Wartungskosten begrenzt, nicht durch Fähigkeit.

Die API-Ära: zwei Tage bis zur ersten Query, zwei Jahre bis zum Tool

Warum diese hier zählt: Hier wurde die Amortisationslücke so breit, dass sie zur Geschäftsentscheidung wurde, nicht zur Engineering-Frage.

Die Google Ads API — damals die AdWords API — war die wahre Macht und die wahre Mauer. Ich sah unseren Systemarchitekten, einen Mann mit über 25 Jahren Engineering-Erfahrung, zwei volle Tage Dokumentation lesen, bevor eine einzige Query Daten zurückgab. Das ist kein Vorwurf an ihn. Das ist die Komplexität, auf die Sie sich einlassen.

Wir gingen trotzdem aufs Ganze und bauten PPC Robot: ein tief anpassbares Reporting- und Operations-Tool, technisch schön, wirklich mächtig. Es kostete auch zwei Entwickler, in Vollzeit, zwei Jahre. Die Weiterentwicklung, die es brauchte, lag irgendwo um die 100.000 € pro Jahr — grob, Größenordnung — und es rechnete sich nie. Es deckte nur einen Bruchteil dessen ab, was unsere PPC-Spezialisten wirklich brauchten, also parkten wir es am Ende in einem eingeschränkten internen Modus. Nicht weil es schlecht war. Weil die Rechnung nie aufging.

Und wir lieferten trotzdem echte Dinge auf Basis dieser API — vor vier, fünf Jahren:

Schauen Sie sich diese Liste an und bemerken Sie eines: nichts davon ist nach heutigen Maßstäben exotisch. Es war alles möglich. Es kostete nur ein Vermögen, es zu bauen, und ein Vermögen, es am Leben zu halten. Jedes nennenswerte Feature — ein Keyword-Research-Tool, ein Expansions-Tool, Anzeigenübersetzung, ein Shopping-Generator — wurde in Monaten gemessen. Das ist die ganze Lehre der Ära in einem Satz: Die Decke war nie die Technologie. Es war die Amortisationsdauer.

Zwei Dinge, die dieses Jahr aufbrachen

Warum ich jetzt konkret werde: „KI hat alles verändert” ist eine Behauptung, die Sie sich weigern sollten, auf Treu und Glauben zu akzeptieren. Also hier zwei Jobs, die sich früher nicht rechneten und es jetzt tun — beides Dinge, die ich betreibe, keine Hypothesen — und beim ersten zeige ich Ihnen genau, was jeder Schritt produziert.

1. Die falschen Suchanfragen ausschließen

Irrelevante Suchbegriffe aus einem Konto zu putzen ist wertvoll und sterbenslangweilig. Der alte Weg war ein halbmanuelles Durchforsten Tausender Anfragen, das Erspähen von Mustern, das händische Hinzufügen von Negatives. Stellen Sie sich die Lage vor: ein Laufschuh-Shop zahlt für Klicks auf „running shoes repair”, „nike air max history” und „free running shoes” — nichts davon verkauft oder wartet er. Multiplizieren Sie das mit Tausenden Zeilen, jede Woche, über jedes Konto. Das ist der Job, den niemand will und jeder braucht.

Die Aktion, die sich änderte: Ein Python-Script zieht die Anfragen aus der Google Ads API und übergibt sie einem Open-Source-Modell — Googles Gemma 4 — mit ordentlichen Instruktionen und, entscheidend, Kontext über die Website: der Sitemap, der Site-/DB-Struktur, der Breadcrumb-Taxonomie, dem Produkt-Feed. Das Ergebnis: Das Modell markiert nicht nur einzelne Müll-Anfragen; es legt die Muster dahinter offen, schneller und günstiger als ein menschliches Überfliegen. Hier dieser Ablauf in fünf konkreten Schritten.

Die leise Schlagzeile hier ist nicht „KI ist schlau”. Es ist, dass ein lokal laufendes Open-Source-Modell genügt — Sie brauchen nicht einmal eine Frontier-API, damit sich das rechnet. Das ist die Ökonomie in Bewegung, nicht die Fähigkeit.

Sehen Sie es laufen: was jeder Schritt tatsächlich ausspuckt

Die fünf Schritte sind das Rezept; das hier ist das Essen. Unten steht das konkrete Artefakt, das Ihnen jeder Schritt für unseren Laufschuh-Shop übergibt — das, worauf Sie buchstäblich blicken, bevor Sie weitergehen. Die Formen sind genau das, was die Werkzeuge zurückgeben; die Zeilen sind illustrativ, kein echter Kunde. (Durchgehend illustrative Beispiele.)

ZIEHEN → die rohen Suchbegriffe, mit angehängtem Geld. Jeder Begriff, für den das Konto zahlte, so sortiert, dass die Verschwendung sichtbar ist:

Search term                Clicks  Cost   Conv
running shoes                420    €310    12
free running shoes            88    €61      0
running shoes repair          54    €40      0
nike air max history          31    €24      0
running shoes wikipedia       19    €14      0

Vier dieser fünf Zeilen sind reine Ausgaben mit null Conversions — 139 €, die das Konto nie hätte zahlen müssen. Das Problem ist in fünf Zeilen offensichtlich und in fünftausend unsichtbar.

ERDEN → das Kontext-Paket, gegen das das Modell argumentiert. Keine Prosa — eine kompakte Karte dessen, was die Site wirklich ist:

sitemap.xml      → 1,010 URLs (categories, products, blog)
breadcrumb tax.  → Footwear > Running > Road / Trail
product feed     → 1,205 SKUs (id, title, category, price)
DB structure     → no "repair", "rental" or "history" nodes exist

Diese letzte Zeile ist die, die die Arbeit macht: das Modell weiß nun, dass „repair” nichts ist, was dieser Shop anbietet, statt zu raten.

FRAGEN → Urteile, und die Muster darüber. Das Modell gibt ein Urteil pro Query zurück — aber der Preis ist der Block ganz unten:

Query                     Verdict      Why
free running shoes        irrelevant   freebie intent, no purchase
running shoes repair      irrelevant   service we don't offer
nike air max history      irrelevant   informational, no buy intent
running shoes wikipedia   irrelevant   reference-seeker

→ PATTERN: tokens "free", "repair", "history", "wikipedia"
  = non-commercial modifiers absent from our taxonomy.
  Recommend excluding as a shared negative list.

Aus vier Zeilen wurde eine Regel. Diese Regel fängt Müll vom Typ „running shoes free shipping returns”, den Sie noch nicht gesehen haben — was der ganze Punkt ist.

PRÜFEN → ein Mensch segnet die Regel ab. Sie lesen eine Zeile — „non-commercial modifiers absent from our taxonomy” — stimmen zu, dass sie stimmt, und Sie sind fertig. Kein Scrollen durch 5.000 Zeilen. Das Urteil fällt einmal.

PUSHEN → die Negatives landen auf der richtigen Ebene. Weil das Muster site-weit ist, geht es auf eine geteilte Negative-Liste, nicht in eine Anzeigengruppe:

Shared negative list: "non-commercial modifiers"
  free · repair · history · wikipedia · manual · pdf
Applied to: all Search campaigns

Ein Muster, eine Liste, jede Kampagne geschützt — und es verdient nächste Woche weiter sein Geld, ohne einen weiteren menschlichen Durchgang. Das ist der Moment, in dem aus einer sterbenslangweiligen wöchentlichen Plackerei eine zehnminütige Prüfung wird.

2. Keyword-Research

Der zweite Job ist der, der früher ein eigener Budgetposten war. Echtes Keyword-Research — die Art, die Nachfrage auf Ihre Landingpages abbildet und Ihnen sagt, was auf der Site fehlt — bedeutete früher dutzende Stunden Datenziehen (AdWords API, Suggest-Boxen, OpenRefine), halbmanuelles Aufräumen, Klassifizierung nach Landingpage und obendrauf Trend-/Suchvolumen-/Lücken-Reporting.

Es ist nicht nur günstiger. Es ist besser — präziser, mit Stunden, die in Validierung und Urteilskraft statt in Klempnerarbeit fließen. Diese Kombination, günstiger und besser, ist genau das, was eigentlich unmöglich sein sollte. Ich habe die moderne Version im Marktexpansions-Blueprint und in der Content-Lücken-Analyse durchgängig aufgeschlüsselt — beide mit dem echten Zwischenoutput, der bei jedem Schritt gezeigt wird.

Die Ökonomie, davor und danach

Das ist die ganze These in einer Tabelle. Dieselben Jobs, dieselbe Qualitätslatte — nur die Kosten, sie zu erledigen, bewegten sich. Belegte Zahlen, wo ich sie habe; der Rest ist Größenordnung aus zwei Jahrzehnten einer Agentur, die genau das tut.

Lesen Sie die Tabelle von oben nach unten und das Muster ist in jeder Zeile dasselbe: die Fähigkeits-Spalte änderte sich nicht — wir konnten all das schon 2019. Die Preis-Spalte fiel durch den Boden. Das ist keine Technologie-Geschichte. Es ist eine Amortisationsdauer-Geschichte, und die Amortisationsdauer ist das, was entscheidet, ob eine kluge Idee je gebaut wird.

Was das wirklich für die Branche bedeutet

Warum ich hier eine Fahne einstecke: die populäre These — „KI beendet den PPC-Spezialisten” — ist faul, und sie falsch herum zu verstehen hat echte Karrierefolgen für die Leute, die das lesen.

„Die Ära der PPC-Spezialisten geht zu Ende” ist Unsinn. Das Gegenteil passiert. Gute Spezialisten verbrachten Jahre frustriert damit, dass die kluge Sache — die Sache, die sie klar sahen — „sich nicht zu bauen lohnte”. Jetzt dürfen sie sie bauen. Automatisch, profitabel, im großen Maßstab. Ein ganzes Regal voller PPC-Strategien, die sich früher nicht rechneten oder schlicht absurd zu versuchen waren, liegt plötzlich auf dem Tisch.

Was tatsächlich passiert, ist eine schärfere Spaltung innerhalb des Handwerks. Auf der einen Seite Junioren ohne Vorstellungskraft, Vision oder Tool-Geläufigkeit — Leute, die das Plattform-UI für den ganzen Job halten. Auf der anderen Super-Senioren, die die Werkzeuge beherrschen, die Workflows erfinden, über die Boxen der Plattform hinausdenken, Datenquellen verknüpfen, die sonst niemand verknüpft, und sich spezialisierte Dashboards bauen, statt darauf zu warten, dass ein Hersteller ein Feature ausliefert.

Und um das offensichtliche Missverständnis zu töten: Das ist kein Argument für günstigeren Service. Tools, Compute und Entwicklung kosten weiterhin Geld. Der Punkt ist, dass ein Projekt, das früher sechs Monate Entwicklung war, jetzt zwei Wochen ist — sodass sich die Investition endlich lohnt. Der Kunde bekommt einen dramatisch besseren Service zu einem ähnlichen Preis, nicht einen schlechteren für weniger.

Warum ich wieder schreibe

Ich hörte vor Jahren auf zu bloggen, weil die Lücke zwischen Idee und ökonomisch vernünftiger Umsetzung zu breit war, um interessant zu sein. Diese Lücke hat sich gerade geschlossen. Also ist dieses Blog zurück, und es wird konkret: Use Cases mit echten Zahlen, die exakten Abläufe, die tatsächlichen Ergebnisse — inklusive der unsauberen Teile und der Grenzen. Die ersten Deep Dives sind schon online; mehr kommt.

Wenn Ihre Reaktion auf all das „endlich könnten wir genau das tun, was wir immer wollten” ist — gut. Das ist der ganze Sinn dieser Ära. Lassen Sie es uns bauen.

1. ZIEHEN  Google Ads API → Suchbegriffe-Report (Query, Klicks, Kosten, Conv.)
2. ERDEN   Baue ein Kontext-Paket, gegen das das Modell argumentieren kann:
            - sitemap.xml (was die Site tatsächlich verkauft)
            - Site- / DB-Struktur + Breadcrumb-Taxonomie
            - Produkt-Feed (id, title, category)
3. FRAGEN  Prompt an Gemma 4: "Klassifiziere mit diesem Site-Kontext jede Query
            als relevant / irrelevant zu dem, was wir verkaufen. Gib die
            irrelevanten zurück UND die MUSTER dahinter (Token, Intent,
            Kategorie-Mismatch)."
4. PRÜFEN  Mensch validiert die ~10 Muster, nicht 5.000 Zeilen einzeln.
5. PUSHEN  Negatives über die API auf der richtigen Ebene zurückspielen (geteilte
            Liste für site-weite Müll-Tokens; Anzeigengruppe für lokales Rauschen).

FAQ