Automatyzacja PPC była możliwa od zawsze. Po prostu nigdy się nie zwracała — aż do teraz.

Cały argument w jednym zdaniu

Porządna automatyzacja PPC była możliwa od zawsze — po prostu nigdy się nie zwracała, więc prawie nikt jej nie robił. AI nie dało nam nowych mocy; ścięło koszt korzystania ze starych, a ta jedna zmiana w ekonomii kładzie z powrotem na stół całą dekadę „chętnie byśmy to zrobili, ale nigdy by się nie zwróciło”. Wszystko poniżej to dowód, opowiedziany z wnętrza narzędzi, którymi naprawdę buduję — nie z keynote’u dostawcy.

Oto co konkretnie z tego tekstu wyniesiesz: trzy ery, które uczyniły automatyzację PPC zbyt drogą, by się nią zajmować, dokładny moment, w którym w tym roku rachunek się przewrócił, i jedno realne zadanie — czyszczenie śmieciowych wyszukiwanych haseł lokalnym modelem open source — rozłożone krok po kroku, z pośrednim wynikiem, na który patrzyłbyś na każdym etapie. Na koniec będziesz umiał odróżnić „AI dało nam nowe umiejętności” (przeważnie nieprawda) od „AI zmieniło, kogo stać na te stare” (rzecz, która naprawdę się liczy) — i będziesz mieć przepływ, który możesz skopiować.

W latach 2015–2017 prowadziłem mały blog o Google Ads Scripts, potem przestałem pisać. Nie dlatego, że skończyły się pomysły — bo przepaść między „to jest możliwe” a „to się opłaca robić dla klienta” przez dekadę uparcie pozostawała szeroka. Niemal wszystko, co czytałeś o tym, jak AI zabija specjalistę PPC, odwraca mechanizm na opak. AI nie zmieniło, co możesz robić w płatnym wyszukiwaniu. Większość z tego była możliwa od zawsze. Zmieniło to, kto może to robić i jakim kosztem — a to znacznie większa sprawa niż kolejny przełącznik automatycznego ustalania stawek. Pozwól, że pokażę, skąd to wiem.

Era Scripts: kilka dni na „prosty” skrypt

Dlaczego zaczynam tutaj: żeby pokazać, że sufitem nigdy nie była technologia. To była robocizna, od pierwszego narzędzia, którego dotknąłem.

Google Ads Scripts wydawały się magią, gdy się pojawiły. JavaScript, prosto w koncie, iterujący po kampaniach. W praktyce „prosty” skrypt — pauzowanie słów kluczowych powyżej progu CPA, oznaczanie zepsutych Final URL — to było kilka dni pisania i debugowania, gdy już ogarnęło się przypadki brzegowe, limity i ciche awarie.

Potem przyszła część, której nikt nie wkalkulował: uruchomienie tego na wielu kontach. Jeden skrypt na konto, kopiowany, rozjeżdżający się coraz bardziej, cicho psujący się, gdy konwencja nazewnictwa jednego klienta nie pasowała do reszty. Skalowanie i dystrybucja były osobną robotą. Dlatego większość skryptów w terenie nigdy nie wyszła poza raportowanie — pociągnięcie kilku liczb do arkusza według harmonogramu. Wszystko, co faktycznie zmieniało konto, było zbyt kruche i zbyt drogie w utrzymaniu, by dla większości agencji było tego warte.

Wniosek, który zabierasz dalej: nawet „łatwa” warstwa automatyzacji była ograniczona kosztem utrzymania, nie możliwościami.

Era API: dwa dni do pierwszego zapytania, dwa lata do narzędzia

Dlaczego ta się liczy: to tutaj luka zwrotu zrobiła się tak szeroka, że stała się decyzją biznesową, a nie inżynierską.

Google Ads API — wtedy AdWords API — to była prawdziwa moc i prawdziwy mur. Patrzyłem, jak nasz architekt systemu, człowiek z ponad 25 latami inżynierii za sobą, spędził dwa pełne dni na czytaniu dokumentacji, zanim jedno zapytanie zwróciło dane. To nie zarzut wobec niego. To rozmiar tego, na co się piszesz.

Mimo to poszliśmy na całość i zbudowaliśmy PPC Robot: głęboko konfigurowalne narzędzie do raportowania i operacji, technicznie piękne, naprawdę potężne. Kosztowało też dwóch programistów, na pełen etat, przez dwa lata. Rozwój, którego wymagało, by działać dalej, krążył gdzieś koło 100 000 € rocznie — z grubsza, rząd wielkości — i nigdy się nie zwrócił. Pokrywało ułamek tego, czego naprawdę potrzebowali nasi specjaliści PPC, więc ostatecznie zaparkowaliśmy je w ograniczonym trybie wewnętrznym. Nie dlatego, że było złe. Dlatego, że rachunek nigdy się nie domykał.

A i tak na tym API dostarczyliśmy realne rzeczy, cztery, pięć lat temu:

Spójrz na tę listę i zauważ jedno: nic z tego nie jest egzotyczne według dzisiejszych standardów. Wszystko było możliwe. Po prostu kosztowało fortunę, żeby to zbudować, i fortunę, żeby utrzymać przy życiu. Każda sensowna funkcja — narzędzie do badania słów kluczowych, narzędzie do ekspansji, tłumaczenie reklam, generator Shopping — mierzona była w miesiącach. To cała lekcja tej ery w jednym zdaniu: sufitem nigdy nie była technologia. To był okres zwrotu.

Dwie rzeczy, które pękły w tym roku

Dlaczego teraz robię się konkretny: „AI zmieniło wszystko” to twierdzenie, które powinieneś odmówić przyjąć na wiarę. Więc oto dwa zadania, które dawniej się nie zwracały, a teraz tak — obydwa rzeczy, które realnie prowadzę, nie hipotezy — a przy pierwszym pokażę dokładnie, co produkuje każdy krok.

1. Wykluczanie niewłaściwych wyszukiwanych haseł

Czyszczenie nietrafnych wyszukiwanych haseł z konta jest wartościowe i ogłupiające. Stary sposób to półręczne przedzieranie się przez tysiące zapytań, wypatrywanie wzorców, dodawanie wykluczeń ręcznie. Wyobraź sobie: sklep z butami biegowymi płaci za kliknięcia w „running shoes repair”, „nike air max history” i „free running shoes” — żadnej z tych rzeczy nie sprzedaje ani nie serwisuje. Pomnóż to przez tysiące wierszy, co tydzień, na każdym koncie. To zadanie, którego nikt nie chce, a wszyscy potrzebują.

Działanie, które się zmieniło: skrypt w Pythonie pociąga zapytania z Google Ads API i przekazuje je modelowi open source — Google Gemma 4 — z porządnymi instrukcjami i, co kluczowe, kontekstem o stronie: mapą witryny, strukturą strony/bazy danych, taksonomią okruszków, feedem produktowym. Rezultat: model nie tylko oznacza pojedyncze śmieciowe zapytania; wydobywa wzorce za nimi, szybciej i taniej niż człowiek przeglądający okiem. Oto ten przepływ w pięciu konkretnych krokach.

Cichy nagłówek tutaj nie brzmi „AI jest mądre”. Brzmi: że model open source działający lokalnie wystarcza — nie potrzebujesz nawet API frontier, żeby się to zwracało. To ekonomia w ruchu, nie możliwość.

Patrz, jak działa: co każdy krok faktycznie wypluwa

Pięć kroków to przepis; to tutaj jest danie. Poniżej konkretny artefakt, który podaje ci każdy krok dla naszego sklepu z butami biegowymi — to, na co dosłownie patrzysz, zanim ruszysz dalej. Kształty są dokładnie tym, co zwracają narzędzia; wiersze są ilustracyjne, nie to prawdziwy klient. (Wszędzie przykłady ilustracyjne.)

POBIERZ → surowe wyszukiwane hasła, z dopiętymi pieniędzmi. Każde hasło, za które konto zapłaciło, posortowane tak, by marnotrawstwo było widoczne:

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

Cztery z tych pięciu wierszy to czysty wydatek z zerem konwersji — 139 €, których konto nie musiało nigdy płacić. Problem jest oczywisty w pięciu wierszach i niewidoczny w pięciu tysiącach.

UGRUNTUJ → pakiet kontekstu, względem którego model rozumuje. Nie proza — zwięzła mapa tego, czym strona naprawdę jest:

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

To właśnie ostatni wiersz wykonuje robotę: model teraz wie, że „repair” to nie jest coś, co ten sklep oferuje, zamiast zgadywać.

ZAPYTAJ → werdykty, a nad nimi wzorce. Model zwraca werdykt na zapytanie — ale nagrodą jest blok na samym dole:

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.

Z czterech wierszy zrobiła się jedna reguła. Ta reguła złapie śmieci w stylu „running shoes free shipping returns”, których jeszcze nie widziałeś — i o to chodzi w całości.

SPRAWDŹ → człowiek zatwierdza regułę. Czytasz jeden wiersz — „non-commercial modifiers absent from our taxonomy” — zgadzasz się, że jest słuszny, i gotowe. Żadnego przewijania 5000 wierszy. Osąd dzieje się raz.

WGRAJ → wykluczenia lądują na właściwym poziomie. Ponieważ wzorzec jest ogólnostronowy, trafia na współdzieloną listę wykluczeń, nie do jednej grupy reklam:

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

Jeden wzorzec, jedna lista, każda kampania chroniona — i dalej zarabia na siebie w przyszłym tygodniu bez kolejnego przejścia człowieka. To moment, w którym ogłupiająca cotygodniowa harówka staje się dziesięciominutowym przeglądem.

2. Badanie słów kluczowych

Drugie zadanie to to, które dawniej było osobną pozycją w budżecie. Prawdziwe badanie słów kluczowych — takie, które mapuje popyt na twoje strony docelowe i mówi, czego brakuje na stronie — oznaczało dawniej dziesiątki godzin pociągania danych (AdWords API, podpowiedzi wyszukiwarki, OpenRefine), półręczne czyszczenie, klasyfikację według strony docelowej oraz raportowanie trendów / wolumenów wyszukiwań / luk na wierzchu.

To nie tylko taniej. To lepiej — precyzyjniej, z godzinami spędzonymi na walidacji i osądzie zamiast na hydraulice. Ta kombinacja, taniej i lepiej, to dokładnie to, co miało być niemożliwe. Rozłożyłem nowoczesną wersję od początku do końca w blueprincie ekspansji rynkowej i w analizie luk w treści — obie z prawdziwym pośrednim wynikiem pokazanym na każdym kroku.

Ekonomia, przed i po

To cała teza w jednej tabeli. Te same zadania, ta sama poprzeczka jakości — przesunął się jedynie koszt ich wykonania. Udokumentowane liczby tam, gdzie je mam; reszta to rząd wielkości z dwóch dekad jednej agencji, która właśnie to robi.

Przeczytaj tabelę z góry na dół, a wzorzec jest w każdym wierszu ten sam: kolumna możliwości się nie zmieniła — wszystko to umieliśmy już w 2019. Kolumna ceny zapadła się przez podłogę. To nie historia o technologii. To historia o okresie zwrotu, a okres zwrotu decyduje o tym, czy mądry pomysł kiedykolwiek powstanie.

Co to naprawdę oznacza dla branży

Dlaczego zatknę tu flagę: popularne ujęcie — „AI kończy ze specjalistą PPC” — jest leniwe, a zrozumienie go na opak ma realne konsekwencje dla kariery ludzi, którzy to czytają.

„Era specjalistów PPC dobiega końca” to bzdura. Dzieje się odwrotnie. Dobrzy specjaliści latami frustrowali się tym, że mądra rzecz — rzecz, którą wyraźnie widzieli — „nie była warta budowania”. Teraz mogą ją zbudować. Automatycznie, dochodowo, na skalę. Cała półka strategii PPC, które dawniej były nieopłacalne albo wręcz absurdalne do podjęcia, nagle leży na stole.

To, co naprawdę się dzieje, to ostrzejszy podział wewnątrz rzemiosła. Po jednej stronie juniorzy bez wyobraźni, wizji czy biegłości w narzędziach — ludzie, którzy traktują interfejs platformy jako całą robotę. Po drugiej super-seniorzy, którzy władają narzędziami, wymyślają workflowy, myślą poza schematami platformy, łączą źródła danych, których nikt inny nie łączy, i budują sobie wyspecjalizowane dashboardy, zamiast czekać, aż dostawca dostarczy funkcję.

I żeby zabić oczywistą pomyłkę: to nie jest opowieść o tańszej usłudze. Narzędzia, moc obliczeniowa i development dalej kosztują pieniądze. Chodzi o to, że projekt, który dawniej był sześcioma miesiącami developmentu, teraz jest dwoma tygodniami — więc inwestycja w końcu ma sens. Klient dostaje dramatycznie lepszą usługę za podobną cenę, nie gorszą za mniej.

Dlaczego znowu piszę

Przestałem blogować lata temu, bo przepaść między pomysłem a ekonomicznie rozsądną realizacją była zbyt szeroka, by była ciekawa. Ta przepaść właśnie się zamknęła. Więc ten blog wraca i będzie konkretny: przypadki użycia z realnymi liczbami, dokładne przepływy, faktyczne wyniki — łącznie z brudnymi fragmentami i ograniczeniami. Pierwsze deep dive są już online; więcej w drodze.

Jeśli twoją reakcją na to wszystko jest „w końcu moglibyśmy zrobić tę rzecz, której zawsze chcieliśmy” — dobrze. O to chodzi w całej tej erze. Zbudujmy to.

1. PULL   Google Ads API → search-terms report (query, clicks, cost, conv)
2. GROUND Build a context pack the model can reason against:
            - sitemap.xml (what the site actually sells)
            - site / DB structure + breadcrumb taxonomy
            - product feed (id, title, category)
3. ASK    Prompt Gemma 4: "Given this site context, classify each query as
            relevant / irrelevant to what we sell. Return the irrelevant ones
            AND the PATTERNS behind them (token, intent, category mismatch)."
4. REVIEW Human validates the ~10 patterns, not 5,000 rows one by one.
5. PUSH   Add negatives back via the API at the right level (shared list for
            site-wide junk tokens; ad group for local noise).

FAQ