Kurz gesagt: PPC-Automatisierung wurde nicht plötzlich möglich. Sie wurde plötzlich bezahlbar. KI hat keine Fähigkeiten hinzugefügt; sie hat die Fähigkeiten, die wir seit 2019 haben, endlich rentabel gemacht: Aus sechsmonatigen Projekten werden zweiwöchige. Die Gewinner sind die Super-Seniors, 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 ihre eigentliche Leistungsfähigkeit nutzen wollte.
Ich stecke seit rund zwanzig Jahren im PPC, zwölf davon entwickle ich mit dieser 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, in fünf Ländern preislich verglichen, 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 wirtschaftliche Rechnung dahinter ist heute eine völlig andere.
Fast alles, was du darüber gelesen hast, wie KI den PPC-Spezialisten abschafft, 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 der Praxis mit den Werkzeugen, mit denen ich tatsächlich baue. Ich zeige dir zwei Ären, die Automatisierung so teuer machten, dass sich der Aufwand nicht lohnte, den Moment, in dem 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.
- KI hat dem PPC fast keine neuen Fähigkeiten hinzugefügt. Sie hat die Amortisationsdauer der Fähigkeiten, die wir seit 2019 haben, drastisch verkürzt, und allein das definiert 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, tritt auf der Stelle; wer die Google Ads API in- und auswendig 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 Skript-Ära: ein paar Tage für ein „einfaches“ Skript
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“ Skript, 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 Skripts pro Konto, und diese Kopien drifteten auseinander und brachen leise, sobald die Namenskonvention eines Kunden nicht zu den anderen passte. Skalierung und Verteilung waren ein Job für sich. Also kamen die meisten Skripte 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 fehlende technische Möglichkeiten. 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. Dass mein Kollege zwei Tage in der Dokumentation verbrachte, spricht nicht gegen ihn. Diesen Aufwand musste jeder einkalkulieren.
Wir gingen trotzdem aufs Ganze und bauten PPC Robot, ein hochgradig anpassbares Reporting- und Operations-Tool. Technisch schön, wirklich mächtig. Es band außerdem zwei Entwickler zwei Jahre lang in Vollzeit. Und danach kostete allein die Weiterentwicklung, die es am Laufen hielt, rund 100.000 € pro Jahr. Es rechnete sich nie. Es deckte nur einen Bruchteil dessen ab, was unsere PPC-Spezialisten wirklich brauchten, also beschränkten wir es irgendwann auf den internen Gebrauch. 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 wurde in Monaten Arbeitszeit zweier Senior-Entwickler gemessen, ob Keyword-Research-Tool, Expansions-Tool, Anzeigenübersetzung oder Shopping-Generator, und kein Kunde war bereit, diesen Preis zu zahlen.
Die Grenze war nie die Technologie. Es war die Amortisationsdauer.
Der erste Job, der sich endlich rechnet: Müll-Suchanfragen
„KI hat alles verändert“ ist eine Behauptung, die du nicht ungeprüft glauben 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 räumen ist wertvoll und sterbenslangweilig, und bis vor Kurzem gab es keinen verlässlichen 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: Er repariert nicht, er verschenkt nichts, und wer Modellgeschichte nachliest, will nichts kaufen. Rechne das hoch auf Tausende Zeilen, jede Woche, in jedem Konto. Das ist der Job, den niemand will und jeder braucht.
Das hier hat sich geändert. Ein Python-Skript 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 ihm Kontext über den Kunden mitgibst, die Sitemap, die Site- und DB-Struktur, die Breadcrumb-Taxonomie, den Produktfeed, hört es auf zu raten und fängt an zu schlussfolgern. Es schließt irrelevante Anfragen zuverlässig aus und benennt die Muster hinter dem Müll, und zwar schneller, als ein Mensch die Liste überfliegen könnte. 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 mit jedem Begriff, 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 Produktfeed (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, schlussfolgert. Du bekommst: ein Kontext-Paket, das aus dem ratenden Modell eines macht, das deinen Katalog kennt.
FRAGEN · Anfragen klassifizieren und die Muster benennen
Füttere Gemma 4 mit den Begriffen und dem Kontext-Paket. Klassifiziere jede Query als relevant oder irrelevant für das, was wir verkaufen. Und das Wichtigste: 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 springt sofort ins Auge, während eine einzelne falsch gelabelte Zeile unbemerkt durchrutscht. Du bekommst: eine kurze Liste von Ausschluss-Mustern, die ein Mensch tatsächlich geprüft und 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 gemeinsame Liste, je nachdem, wie breit das Muster ist. Warum die Ebene zählt: ein Müll-Token, das für die ganze Website gilt („free“, „wikipedia“), gehört auf eine gemeinsame Liste und sollte nicht in einer einzelnen Anzeigengruppe vergraben werden. 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, das Format ist genau das, was zurückkommt, und das Wertvollste steckt im Block ganz unten:
Suchanfrage Urteil Warum
free running shoes irrelevant will etwas gratis, kauft nicht
running shoes repair irrelevant Dienstleistung bieten wir nicht an
nike air max history irrelevant informativ, keine Kaufabsicht
running shoes wikipedia irrelevant will nur nachschlagen
→ MUSTER: Tokens „free“, „repair“, „history“, „wikipedia“
= nichtkommerzielle Modifikatoren, die in unserer Taxonomie fehlen.
Empfehlung: über eine gemeinsame Negative-Liste ausschließen.Aus vier Zeilen wurde eine Regel. Ein Mensch liest diese eine Zeile, gibt ihr recht, und die Regel fängt weiter Müll vom Typ „free running shoe giveaway“, 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 eigentliche Pointe 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 den eigenen Rechner. Was sich geändert hat, ist die Ökonomie, nicht die Fähigkeit.
Der zweite Job: Keyword-Research
Der hier war früher ein eigener Budgetposten. Echtes Keyword-Research, das 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, bereinigen, klassifizieren, reporten) 50–100 Std.
- Was der Kunde dafür zahlte ≈ 2.000–4.000 €
- Dasselbe Projekt heute, mit einem guten KI-Skill einstellige Stundenzahl
- Und das Ergebnis ist genauer
Es ist nicht nur günstiger. Es ist besser und präziser, weil die Arbeitszeit in die Validierung und die fachliche Beurteilung statt in den technischen Unterbau fließt. 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. Eine solche Recherche gab ein Kunde früher einmal jährlich frei. Dieselbe Pipeline kann jetzt täglich laufen und zeigen, wie sich die Nachfrage entwickelt, statt einmal im Jahr eine Momentaufnahme zu liefern.
Die Ökonomie, davor und danach
Das ist die ganze These in einer Tabelle. Dieselben Jobs, dieselbe Qualitätslatte; nur die Kosten dafür haben sich verändert. Wo ich belegte Zahlen habe, nenne ich sie; der Rest sind Größenordnungen aus zwanzig Jahren Agenturarbeit.
| 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 Stundenzahl · genauer |
| Negative-Query-Triage | halbmanuelles Durchforsten, Tausende Zeilen von Hand | Skript + 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 Spalte mit den Fähigkeiten hat sich nicht verändert, all das konnten wir schon 2019. Die Preise sind in den Keller gerauscht. Und die Amortisationsdauer ist es, die entscheidet, ob eine kluge Idee je gebaut wird.
KI hat kaum neue PPC-Fähigkeiten erschlossen. Sie hat vor allem dafür gesorgt, dass sich die alten viel schneller amortisieren. Wenn aus einem sechsmonatigen Projekt ein zweiwöchiges wird, dann leert sich das ganze Backlog an „würden wir gern, aber es würde sich nie lohnen“ auf einen Schlag.
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. Wegen der langen Amortisationszeiten, die ich oben beschrieben habe, ließen sich diese technischen Kompetenzen jahrelang nur schwer für PPC-Probleme einsetzen. Jetzt zahlen sie sich mit Zinseszins aus.
Boostora, 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 ist der Unterbau gewachsen, den die neue Ökonomie endlich rechtfertigt. Wettbewerber-Preis-Scraping pro Markt, das die Preistabellen im Expansions-Blueprint gespeist hat. Keyword-Research-Pipelines, die nach Zeitplan laufen statt einmal im Jahr. Business-Reporting auf Kundenebene in BigQuery, mit Forecasts obendrauf. MCP-Server für jeden Dienst, mit dem wir arbeiten, damit ein KI-Agent mitten in einer Aufgabe aus all diesen Diensten Daten ziehen kann.
Vor zwei Jahren hätte ich mich bei jedem dieser Projekte derselben Frage stellen müssen: Rechnet sich das jemals? Heute kommt die Frage kaum noch auf. Wenn Bauen billig wird, hört Infrastruktur auf, Luxus zu sein, und wird zum Vorsprung, den niemand kopieren kann.
Was das wirklich für die Branche bedeutet
Die verbreitete These lautet, KI mache PPC-Spezialisten überflüssig. Das falsch herum zu verstehen hat echte Karrierefolgen für die, die das hier lesen, also zeige ich hier Flagge.
„Die Ära der PPC-Spezialisten geht zu Ende“ ist Unsinn. Das Gegenteil passiert. Gute Spezialisten waren jahrelang frustriert, weil es sich nicht lohnte, das Kluge zu bauen, das sie klar vor sich sahen. Jetzt dürfen sie es bauen. Automatisch, profitabel, im großen Maßstab. Ein ganzes Regal voller PPC-Strategien, die früher unwirtschaftlich oder schlicht absurd waren, ist plötzlich im Spiel.
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 an sich vorbeiziehen lassen. Niemand feuert sie morgen. Sie treten auf der Stelle, während sich das Berufsbild weiterentwickelt. Auf der anderen Seite stehen die, die die Google Ads API in- und auswendig 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 Entwicklung mit dieser 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 damit das naheliegende Missverständnis gar nicht erst entsteht: Das hier ist keine Geschichte über günstigeren Service. Tools, Compute und Entwicklung kosten weiter Geld. Der Punkt ist, dass ein Projekt, für das früher zwei Senior-Entwickler vier bis sechs Monate brauchten, jetzt in Wochen fertig ist, 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 verursachte 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. So bleiben deine Daten bei dir und deine Kosten unter Kontrolle.
Geht es hier nur um Suchanfragen?
Nein, das ist nur der Job, dem man am leichtesten beim Laufen zusieht. Dieselbe Rechnung geht jetzt auch bei Marktexpansions-Analysen auf (sechs Stunden statt ~400), beim Wettbewerber-Preis-Scraping pro Markt, bei Keyword-Research, das täglich läuft statt einmal im Jahr, und bei der Feed-Anreicherung mit Boostora AI. 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 begrenzt und echt: Die Amortisationsdauer für Fähigkeiten, die wir schon hatten, ist drastisch gesunken. Das ist eine geschäftliche Veränderung, keine magische, und darum leert sich das Backlog plötzlich.
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 davon, was wir genau laufen ließen und was dabei herauskam.
