Kurz gesagt: PPC-Automatisierung wurde nicht plötzlich möglich. Sie wurde plötzlich bezahlbar. KI hat keine Fähigkeiten hinzugefügt; sie ließ die Amortisationsdauer derer einbrechen, die wir seit 2019 haben, und machte aus sechsmonatigen Builds zweiwöchige. Die Gewinner sind die Super-Senioren, die endlich die Workflows bauen dürfen, die sich früher nie rechneten, etwa Tausende Müll-Suchanfragen mit einem Modell auszumisten, das ein gewöhnlicher PC ausführt.
Ich habe einmal zugesehen, wie unser Systemarchitekt, ein Mann mit fünfundzwanzig Jahren Engineering hinter sich, zwei volle Tage Google Ads API-Dokumentation las, bevor eine einzige Query Daten zurückgab. Zwei Tage, eine Query. Er ist der beste Engineer, den ich kenne, und trotzdem brauchte er zwei Tage. Das war schlicht der Eintrittspreis, den die Plattform jedem abverlangte, der an die echte Macht wollte.
Ich stecke seit rund zwanzig Jahren im PPC, zwölf davon schreibe ich Code gegen diese API. Zwischen 2015 und 2017 betrieb ich ppc-scripts.eu, ein kleines Blog über Google Ads Scripts, damals, als PPC-Automatisierung noch nicht cool war. Dann hörte ich auf zu schreiben. Nicht weil die Ideen ausgingen. Die Lücke zwischen „das ist möglich” und „das lohnt sich für einen Kunden” blieb ein Jahrzehnt lang hartnäckig breit, und es gibt nur begrenzt viele Arten, Werkzeuge zu beschreiben, die sich niemand leisten kann.
Dieses Frühjahr habe ich eine Marktexpansions-Analyse geliefert, sechzehn Produkte über fünf Länder gepreist, mit Heat Maps, in etwa sechs Stunden. Von Hand sind das rund 400 Stunden Arbeit. Als Individualsoftware auf die alte Art sind es zwei Monate Entwicklung und eine Rechnung über 16.000 bis 20.000 €, die kein Kunde je zahlen wollte. Dieselbe Leistung, und der Preis kollabierte. Die Analyse ist in diesem Frühjahr nicht schlauer geworden. Die Ökonomie, sie zu bauen, ist gebrochen.
Fast alles, was du darüber gelesen hast, dass KI den PPC-Spezialisten erledigt, dreht diesen Mechanismus falsch herum. KI hat nicht verändert, was du im Paid Search tun kannst. Das meiste war schon immer möglich, und das meiste existierte bereits 2019. Was sie verändert hat, ist, wer es sich leisten kann. Dieser Text ist der Beweis, erzählt aus dem Inneren der Werkzeuge, mit denen ich tatsächlich baue. Zwei Ären, die Automatisierung zu teuer machten, um sich die Mühe zu lohnen, der Moment, in dem die Rechnung kippte, und ein echter Job, das Ausmisten von Müll-Suchanfragen mit einem lokalen Open-Source-Modell, Schritt für Schritt aufgeschlüsselt.
- KI hat dem PPC fast keine neuen Fähigkeiten hinzugefügt. Sie ließ die Amortisationsdauer der Fähigkeiten einbrechen, die wir seit 2019 haben, und allein das schreibt neu, was sich zu bauen lohnt.
- Die entscheidende Währung sind nicht mehr Codezeilen. Knapp sind jetzt Ideen plus Domänenwissen, also zu wissen, was man bauen und welche Daten man verknüpfen sollte.
- Das Handwerk spaltet sich in zwei. Wer die Werkzeuge auslässt, friert ein; wer die Google Ads API bis auf die Knochen kennt und Daten mit Vorstellungskraft kombiniert, zieht davon.
- Das Beispiel im Text zeigt ein lokales Open-Source-Modell, das Tausende Müll-Suchanfragen in Minuten ausmistet, ein Job, der bis vor Kurzem strikt manuell war.
Die Scripts-Ära: ein paar Tage für ein „einfaches” Script
Die Grenze war nie die Technologie, und das will ich dir vom allerersten Werkzeug an zeigen, das ich angefasst habe. Google Ads Scripts fühlten sich wie Magie an, als sie kamen. JavaScript, direkt im Konto, in einer Schleife über Kampagnen. In der Praxis kostete ein „einfaches” Script, etwa Keywords über einem CPA-Schwellenwert zu pausieren oder kaputte Final URLs zu melden, ein paar Tage Schreiben und Debuggen, sobald du die Sonderfälle, die Quotas und die stillen Fehler abgedeckt hattest.
Dann kam der Teil, den niemand einplante. Es über mehrere Konten laufen zu lassen hieß eine Kopie des Scripts pro Konto, die auseinanderdrifteten und leise brachen, sobald die Namenskonvention eines Kunden nicht zu den anderen passte. Skalierung und Verteilung war ein eigener Job. Also kamen die meisten Scripts in freier Wildbahn nie über Reporting hinaus, ein paar Zahlen nach Zeitplan in ein Sheet ziehen. Alles, was das Konto tatsächlich veränderte, war zu fragil und zu teuer im Unterhalt.
Selbst die einfache Automatisierungsebene war durch Wartungskosten begrenzt, nicht durch Fähigkeit. Nimm das mit. Es ist das Muster von allem, was folgt.
Die API-Ära: zwei Tage bis zur ersten Query, zwei Jahre bis zum Tool
Die Google Ads API, damals noch die AdWords API, war die echte Macht und die echte Mauer. Die zwei Tage, die mein Kollege in der Dokumentation verbrachte, waren kein Vorwurf an ihn. Das war die Fläche, auf die sich jeder einließ.
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, und die Weiterentwicklung, die es brauchte, lag irgendwo um 100.000 € pro Jahr. Es rechnete sich nie. Es deckte nur einen Bruchteil dessen ab, was unsere PPC-Spezialisten wirklich brauchten, also parkten wir es irgendwann 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:
Was diese Maschine tatsächlich produzierte
- 404-/Final-URL-Checker über alle Konten ausgeliefert
- Shopping-Kampagnen-Generator aus dem Feed ausgeliefert
- Shopping-/Performance-Max-Segmentierung ausgeliefert
- BigQuery-Pipeline + Reporting nach Sheets / Excel ausgeliefert
- Merchant-Center-Kontostatus-Checks ausgeliefert
Schau dir die Liste an, und dir fällt etwas auf. 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 der Zeit zweier Senioren gemessen, und kein Kunde zahlt, was das kostet.
Die Grenze war nie die Technologie. Es war die Amortisationsdauer.
Der erste Job, der sich losriss: Müll-Suchanfragen
„KI hat alles verändert” ist eine Behauptung, die du nicht auf Treu und Glauben nehmen solltest. Also hier zwei Jobs, die sich früher nicht rechneten und es jetzt tun. Beides sind Dinge, die ich betreibe, keine Hypothesen, und beim ersten gehe ich mit dir den ganzen Ablauf durch.
Irrelevante Suchbegriffe aus einem Konto zu putzen ist wertvoll und sterbenslangweilig, und bis vor Kurzem gab es keinen ehrlichen Weg, es zu automatisieren. Regeln fangen ein exaktes Token, aber ob „nike air max history” einen Klickpreis wert ist, entscheidet Leseverständnis. Also blieb der Job ein halbmanuelles Durchforsten Tausender Anfragen, Muster erspähen, Negatives von Hand hinzufügen. Stell dir einen Laufschuh-Shop vor, der für Klicks auf „running shoes repair”, „nike air max history” und „free running shoes” zahlt, obwohl er nichts davon verkauft oder repariert. Rechne das mal Tausende Zeilen hoch, jede Woche, über jedes Konto. Das ist der Job, den niemand will und jeder braucht.
Das hier hat sich geändert. Ein Python-Script zieht die Anfragen aus der Google Ads API und übergibt sie einem Open-Source-Modell, Googles Gemma 4, das fast jeder aktuelle PC ausführen kann. Es liest Tausende Anfragen in wenigen Minuten. Und wenn du es in Kontext über den Kunden verankerst, die Sitemap, die Site- und DB-Struktur, die Breadcrumb-Taxonomie, den Produkt-Feed, hört es auf zu raten und fängt an zu argumentieren. Es schließt korrekt aus und benennt die Muster hinter dem Müll, schneller als jedes menschliche Überfliegen. Hier ist dieser Ablauf in fünf konkreten Schritten.
ZIEHEN · die rohen Suchbegriffe holen
Zieh den Suchbegriffe-Report aus der Google Ads API. Query, Klicks, Kosten, Conversions. Warum zuerst: das ist die Evidenz, das Geld, das für jeden Begriff bereits ausgegeben wurde. Du willst die Kosten an jeder Zeile, damit das Modell teuren Müll von harmlosem Müll unterscheiden kann. Du bekommst: eine flache Tabelle jedes Begriffs, für den das Konto im Zeitraum gezahlt hat.
VERANKERN · ein Kontext-Paket über die Website bauen
Stell zusammen, was die Site tatsächlich ist, in einer Form, die das Modell lesen kann. Die XML-Sitemap, die Breadcrumb-Taxonomie, den Produkt-Feed (id, title, category) und die DB- und Kategorie-Struktur. Warum das alles entscheidet: ein Modell ohne Kontext rät; ein Modell, das weiß, dass es keine „Reparatur”- oder „Vermietungs”-Kategorie gibt, argumentiert. Du bekommst: ein Kontext-Paket, das aus dem Modell statt eines Raters etwas macht, das deinen Katalog kennt.
FRAGEN · Anfragen klassifizieren und die Muster benennen
Gib Gemma 4 die Begriffe plus das Kontext-Paket vor. Klassifiziere jede Query als relevant oder irrelevant für das, was wir verkaufen, und, der wichtige Teil, gib die Muster hinter den irrelevanten zurück (ein Token, ein Intent, ein Kategorie-Mismatch). Warum Muster, nicht Zeilen: 200 Müll-Anfragen zu markieren spart dir einen Nachmittag; die Kategorie des Mülls zu benennen schließt die nächsten Tausend aus, die du noch gar nicht gesehen hast. Du bekommst: eine Liste irrelevanter Anfragen und darüber die Handvoll Regeln, die sie erzeugt haben.
PRÜFEN · die Regeln validieren, nicht die Zeilen
Ein Mensch liest die Muster, fünf bis zehn davon, nicht 5.000 einzelne Zeilen. Warum das die Zeit spart: Urteilskraft wird einmal pro Regel angewandt statt einmal pro Query, und eine falsche Regel fällt auf eine Art auf, wie es eine einzelne falsch gelabelte Zeile nie tut. Du bekommst: eine kurze, vertrauenswürdige Liste von Ausschluss-Mustern, die ein Mensch tatsächlich abgesegnet hat.
PUSHEN · die Negatives auf der richtigen Ebene hinzufügen
Spiel die genehmigten Negatives über die API auf der richtigen Ebene zurück, Anzeigengruppe, Kampagne oder geteilte Liste, je nachdem, wie breit das Muster ist. Warum die Ebene zählt: ein site-weites Müll-Token („free”, „wikipedia”) gehört auf eine geteilte Liste, nicht in einer einzelnen Anzeigengruppe vergraben. Du bekommst: ein sauberes Konto und eine wiederverwendbare Negative-Liste, die nächste Woche weiter wirkt.
Um zu sehen, warum das funktioniert, schau dir an, was der FRAGEN-Schritt für unseren Laufschuh-Shop tatsächlich zurückgibt. Die Zeilen sind illustrativ, die Form ist genau das, was zurückkommt, und 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. Ein Mensch liest diese eine Zeile, stimmt zu, dass sie stimmt, und die Regel fängt weiter Müll vom Typ „running shoes free shipping returns”, den du noch gar nicht gesehen hast. Das ist der Moment, in dem aus einer sterbenslangweiligen wöchentlichen Plackerei eine zehnminütige Prüfung wird.
Die leise Schlagzeile hier ist, dass ein lokal laufendes Open-Source-Modell genügt. Du brauchst keine Frontier-API, damit sich das rechnet, und deine Daten verlassen nie das Haus. Das ist die Ökonomie in Bewegung, nicht die Fähigkeit.
Der zweite Job: Keyword-Research
Der hier war früher ein eigener Budgetposten. Echtes Keyword-Research, die Art, die Nachfrage auf deine Landingpages abbildet und dir 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-, Volumen- und Lücken-Reporting.
Ein Keyword-Research-Projekt, früher vs. heute
- Der alte Weg (Daten ziehen, putzen, klassifizieren, reporten) 50–100 Std.
- Was der Kunde dafür zahlte ≈ 2.000–4.000 €
- Dasselbe Projekt heute, mit einem guten Skill einstellige Std.
- Und das Ergebnis ist genauer
Es ist nicht nur günstiger. Es ist besser, präziser, mit Stunden, die in Validierung und Urteilskraft fließen statt in die Klempnerei. Günstiger und besser ist genau die Kombination, die eigentlich unmöglich sein sollte. Ich habe die moderne Version im Marktexpansions-Blueprint und in der Content-Lücken-Analyse von Anfang bis Ende aufgeschlüsselt, beide mit dem echten Zwischenergebnis bei jedem Schritt.
Der Teil, der mich immer noch überrascht, ist der Takt. Research wie dieses war früher ein Jahresprojekt, das ein Kunde einmal freigab. Dieselbe Pipeline kann jetzt täglich laufen und zusehen, wie sich die Nachfrage bewegt, statt sie einmal im Jahr zu fotografieren.
Die Ökonomie, davor und danach
Das ist die ganze These in einer Tabelle. Dieselben Jobs, dieselbe Qualitätslatte; nur die Kosten, sie zu erledigen, haben sich bewegt. Belegte Zahlen, wo ich sie habe, Größenordnungen aus zwanzig Jahren Agenturarbeit für den Rest.
| Der Job | Der alte Weg | Heute |
|---|---|---|
| Marktexpansions-Analyse (Preise über mehrere Märkte) | ~400 Std. von Hand · oder 2 Monate Dev, 16.000–20.000 € | 6 Std. |
| Keyword-Research (ein Projekt) | 50–100 Std. · 2.000–4.000 € abgerechnet | einstellige Std. · genauer |
| Negative-Query-Triage | halbmanuelles Durchforsten, Tausende Zeilen von Hand | Script + lokales Modell benennt die Muster |
| Ein neues Automatisierungs-Feature ausliefern | Monate (2 Devs × 2 J. für ein ganzes Tool) | Wochen |
| Eine Reporting-Maschine am Leben halten | ~100.000 €/J., rechnete sich nie | nahezu null mit einem lokalen Modell |
Lies die Tabelle von oben nach unten, und das Muster wiederholt sich in jeder Zeile. Die Fähigkeits-Spalte hat sich nicht bewegt, all das konnten wir schon 2019. Die Preis-Spalte fiel durch den Boden. Und die Amortisationsdauer ist es, die entscheidet, ob eine kluge Idee je gebaut wird.
KI hat weniger neue PPC-Fähigkeiten freigeschaltet, als dass sie die Amortisationsdauer der alten einbrechen ließ. Wenn aus einem sechsmonatigen Build ein zweiwöchiger wird, räumt sich das ganze Backlog an „würden wir gern, aber es würde sich nie lohnen” plötzlich auf.
Was passiert, wenn du voll darauf setzt
Lynt ist vom ersten Tag an eine techniklastige Agentur gewesen. Wir haben einen Systemarchitekten, einen Security Engineer, einen Datenanalysten, der BI baut, und einen Entwickler in Vollzeit im Team, was eine normale Agentur schlicht nicht hat. Jahrelang war dieser Muskel schwer auf PPC-Probleme zu richten, aus all den Amortisationsgründen oben. Jetzt verzinst er sich.
Boostera, unser eigenes Tool, hat zwei Jahre Entwicklung gekostet. Es reichert Google-Merchant-Center-Feeds mit KI an, damit Shopping-Kampagnen auf besseren Produktdaten laufen, als der rohe Feed hergibt. Drumherum sitzt die Klempnerei, die die neue Ökonomie endlich rechtfertigt. Wettbewerber-Preis-Scraping pro Markt, die Art, die die Preistabellen im Expansions-Blueprint gefüttert hat. Keyword-Research-Pipelines, die nach Zeitplan laufen statt einmal im Jahr. Business-Reporting auf Kundenebene in BigQuery, mit Forecasts obendrauf. MCP-Server auf jedem Dienst, den wir anfassen, damit ein KI-Agent mitten in einer Aufgabe aus jedem davon ziehen kann.
Vor zwei Jahren hätte ich jedes dieser Projekte gegen dieselbe Frage verteidigen müssen, ob es sich je rechnet. Heute kommt die Frage kaum noch auf. Wenn Bauen billig wird, hört Infrastruktur auf, Luxus zu sein, und wird zum Burggraben.
Was das wirklich für die Branche bedeutet
Die populäre These sagt, KI beende den PPC-Spezialisten. Das falsch herum zu verstehen hat echte Karrierefolgen für die, die das hier lesen, also stecke ich eine Flagge in den Boden.
„Die Ära der PPC-Spezialisten geht zu Ende” ist Unsinn. Das Gegenteil passiert. Gute Spezialisten verbrachten Jahre frustriert damit, dass die kluge Sache, die sie klar vor sich 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 früher unwirtschaftlich oder schlicht absurd zu versuchen waren, liegt plötzlich auf dem Tisch.
Was passiert, ist eine schärfere Spaltung innerhalb des Handwerks. Auf der einen Seite stehen die, die die Plattform-Oberfläche für den ganzen Job halten und die neuen Werkzeuge vorbeiziehen lassen. Niemand feuert sie morgen. Sie frieren ein, während der Job weiterzieht. Auf der anderen Seite stehen die, die die Google Ads API bis auf die Knochen kennen, Datenquellen verknüpfen, die sonst niemand verknüpft, und sich spezialisierte Dashboards bauen, statt darauf zu warten, dass ein Hersteller ein Feature ausliefert. Zwölf Jahre Code gegen diese API haben mich gelehrt, wo der Vorsprung der zweiten Gruppe wirklich liegt. Der Code wurde billig. Knapp geblieben sind Vorstellungskraft und Domänenwissen, zu wissen, welche Daten man kombiniert und warum.
Und um das naheliegende Missverständnis gleich zu beerdigen, das hier ist keine Geschichte über günstigeren Service. Tools, Compute und Entwicklung kosten weiter Geld. Der Punkt ist, dass ein Projekt, das früher vier bis sechs Monate zweier Senior-Entwickler war, jetzt in Wochen ausliefert, sodass sich die Investition endlich lohnt. Der Kunde bekommt einen dramatisch besseren Service zu einem ähnlichen Preis.
Warum ich wieder schreibe
Ich hörte 2017 auf zu bloggen, weil die Lücke zwischen einer Idee und einer ökonomisch vernünftigen Umsetzung zu breit war, um interessant zu sein. Diese Lücke hat sich gerade geschlossen. Also macht dieses Blog dort weiter, wo ppc-scripts.eu aufgehört hat, und es bleibt konkret. Use Cases mit echten Zahlen, die exakten Abläufe, die tatsächlichen Ergebnisse, unsaubere Teile und Grenzen inklusive. Die ersten Deep Dives sind schon online.
Irgendwo in deinem eigenen Backlog liegt die Automatisierung, die du vor Jahren beiseitegelegt hast, weil sie sich nie rechnen würde. Grab sie aus und rechne noch einmal. Wenn die Zahlen so gekippt sind wie meine, weißt du, was du als Nächstes baust. Und wenn du dich austauschen willst, weißt du, wo du mich findest.
FAQ
Sagst du, Agenturen sollten ihre PPC-Spezialisten feuern?
Das exakte Gegenteil. Spezialisten, die Strategie und Werkzeuge verstehen, sind jetzt wertvoller, weil sie endlich die Ideen umsetzen können, die sich früher nicht rechneten. Was schrumpft, ist der Wert des reinen Knöpfchendrückens in der Plattform-Oberfläche.
Sind die 100.000 €/Jahr und zwei Devs für zwei Jahre exakt?
Nein, nimm sie als Größenordnung. Der Punkt ist nicht der genaue Euro-Betrag. Eine einzige interne Reporting-Maschine trug sechsstellige Jahreskosten und rechnete sich trotzdem nie. Genau um diese Ökonomie geht es in diesem ganzen Text.
Brauche ich dafür ein teures Frontier-Modell?
Nicht für Jobs wie die Negative-Query-Triage. Ein fähiges Open-Source-Modell wie Gemma 4, lokal mit gutem Site-Kontext betrieben, erledigt die Arbeit. Das hält sowohl deine Daten als auch deine Kosten in deiner Hand.
Geht es hier nur um Suchanfragen?
Nein, das ist nur der Job, dem man am leichtesten beim Laufen zusieht. Dieselbe Ökonomie hat sich bewegt für Marktexpansions-Analysen (sechs Stunden statt ~400), für Wettbewerber-Preis-Scraping pro Markt, für Keyword-Research, das täglich läuft statt einmal im Jahr, und für Feed-Anreicherung mit Boostera. Nimm die Fleißarbeit, die du beiseitegelegt hast, und rechne ihre Zahlen neu.
Ist das also nur Hype mit frischem Anstrich?
Wäre es das, hätte ich nicht wieder angefangen zu schreiben. Die Veränderung ist eng und echt, eine eingebrochene Amortisationsdauer für Fähigkeiten, die wir schon hatten. Das ist eine geschäftliche Veränderung, keine magische, und darum räumt sich das Backlog plötzlich auf.
Was wird tatsächlich auf diesem Blog stehen?
Konkrete Use Cases mit Zahlen, die Abläufe dahinter und die Ergebnisse, Grenzen und Fehlermodi inklusive. Weniger Manifest, mehr genau das, was wir laufen ließen und was dabei herauskam.
