W skrócie: Automatyzacja PPC nie stała się nagle możliwa. Stała się nagle opłacalna. AI nie dodało możliwości; skróciło okres zwrotu z tych, które mamy od 2019 roku, zamieniając półroczne projekty w dwutygodniowe. Wygrywają super-seniorzy, którzy w końcu budują workflowy, jakie nigdy się nie zwracały, na przykład czyszczenie tysięcy śmieciowych zapytań modelem, który uruchomi zwykły pecet.
Kiedyś patrzyłem, jak nasz architekt systemów, człowiek z dwudziestoma pięcioma latami inżynierii za sobą, spędza dwa pełne dni na czytaniu dokumentacji Google Ads API, zanim jedno zapytanie zwróciło dane. Dwa dni, jedno zapytanie. To najlepszy inżynier, jakiego znam, a i tak zajęło mu to dwa dni. Takie było po prostu wpisowe, które platforma kasowała od każdego, kto chciał prawdziwej mocy.
W PPC spędziłem około dwudziestu lat, dwanaście z nich pisząc kod przeciwko temu API. W latach 2015–2017 prowadziłem ppc-scripts.eu, mały blog o Google Ads Scripts, w czasach, gdy automatyzacja PPC nie była jeszcze modna. Potem przestałem pisać. Nie dlatego, że wyschły pomysły. Przepaść między „to jest możliwe” a „to się opłaca zrobić dla klienta” przez dekadę uparcie pozostawała szeroka, a narzędzia, na które nikogo nie stać, da się opisywać tylko na tyle sposobów.
Tej wiosny dostarczyłem analizę ekspansji rynkowej, szesnaście produktów wycenionych w pięciu krajach z mapami cieplnymi, w około sześć godzin. Ręcznie to jakieś 400 godzin pracy. Zbudowane po staremu jako software na zamówienie, to dwa miesiące developmentu i faktura na 16 000 do 20 000 €, której żaden klient nigdy nie chciał zapłacić. Ten sam produkt, a cena się zawaliła. Analiza tej wiosny nie zmądrzała. Pękła ekonomia jej budowania.
Niemal wszystko, co czytałeś o tym, jak AI zabija specjalistę PPC, odwraca ten mechanizm na opak. AI nie zmieniło, co możesz robić w płatnym wyszukiwaniu. Większość była możliwa od zawsze i większość istniała już w 2019 roku. Zmieniło się to, kogo stać, żeby to robić. Ten artykuł to dowód, opowiedziany z wnętrza narzędzi, którymi naprawdę buduję. Dwie ery, które czyniły automatyzację zbyt drogą, żeby się nią zajmować, moment, w którym rachunek się przewrócił, i jedno realne zadanie, czyszczenie śmieciowych wyszukiwanych haseł lokalnym modelem open source, rozłożone krok po kroku.
- AI nie dodało do PPC prawie żadnych nowych możliwości. Skróciło okres zwrotu z tych, które mamy od 2019 roku, a już samo to przepisuje, co warto budować.
- Decydującą walutą przestały być linijki kodu. Rzadkie są teraz pomysły plus znajomość domeny, wiedza, co zbudować i które dane połączyć.
- Rzemiosło pęka na dwoje. Ci, którzy omijają narzędzia, zamierają w miejscu; ci, którzy znają Google Ads API do szpiku kości i łączą dane z wyobraźnią, odjeżdżają do przodu.
- Rozpracowany przykład w środku pokazuje, jak lokalny model open source czyści w kilka minut tysiące śmieciowych zapytań, zadanie, które dawniej było ściśle ręczne.
Era Scripts: kilka dni na „prosty” skrypt
Sufitem nigdy nie była technologia i chcę ci to pokazać już na pierwszym narzędziu, 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, powiedzmy pauzowanie słów kluczowych powyżej progu CPA albo oznaczanie zepsutych Final URL, zajmował kilka dni pisania i debugowania, gdy już ogarnąłeś przypadki brzegowe, limity i ciche awarie.
Potem przyszła część, której nikt nie wkalkulował. Uruchomienie tego na wielu kontach oznaczało jedną kopię skryptu na konto, wersje się rozjeżdżały i cicho psuły, gdy tylko 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.
Nawet łatwa warstwa automatyzacji była ograniczona kosztem utrzymania, nie możliwościami. Zabierz to ze sobą dalej. To wzorzec wszystkiego, co następuje.
Era API: dwa dni do pierwszego zapytania, dwa lata do narzędzia
Google Ads API, wtedy jeszcze AdWords API, było prawdziwą mocą i prawdziwym murem. Te dwa dni, które mój kolega spędził w dokumentacji, nie były zarzutem wobec niego. To był rozmiar tego, na co pisał się każdy.
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. Pochłonęło też dwóch programistów, na pełen etat, przez dwa lata, a development potrzebny, żeby działało dalej, krążył gdzieś koło 100 000 € rocznie. Nigdy się nie zwróciło. Pokrywało ułamek tego, czego nasi specjaliści PPC naprawdę potrzebowali, więc ostatecznie zaparkowaliśmy je w ograniczonym trybie wewnętrznym. Nie dlatego, że było złe. Dlatego, że rachunek nigdy się nie domknął.
A i tak dostarczyliśmy na tym API realne rzeczy, cztery i pięć lat temu:
Co ten silnik faktycznie wyprodukował
- Sprawdzanie błędów 404 / zepsutych Final URL na wszystkich kontach dostarczone
- Generator kampanii Shopping z feedu dostarczone
- Segmentacja Shopping / Performance Max dostarczone
- Pipeline BigQuery + raportowanie do Sheets / Excela dostarczone
- Sprawdzanie statusu konta Merchant Center dostarczone
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 czasu dwóch seniorów, a żaden klient nie zapłaci tyle, ile to kosztuje.
Sufitem nigdy nie była technologia. Był nim okres zwrotu.
Pierwsze zadanie, które się wyrwało: śmieciowe wyszukiwane hasła
„AI zmieniło wszystko” to twierdzenie, którego nie powinieneś przyjmować na wiarę. Oto więc dwa zadania, które dawniej się nie zwracały, a teraz tak. Oba realnie prowadzę, to nie hipotezy, a przez pierwsze przeprowadzę cię krok po kroku.
Czyszczenie nietrafnych wyszukiwanych haseł z konta jest cenne i ogłupiające, a do niedawna nie było uczciwego sposobu, żeby to zautomatyzować. Reguły złapią dokładny token, ale rozstrzygnięcie, czy „nike air max history” jest warte płacenia, wymaga rozumienia tekstu. Zadanie pozostawało więc półręcznym przedzieraniem się przez tysiące zapytań, wypatrywaniem wzorców na oko, dodawaniem wykluczeń ręcznie. Wyobraź sobie sklep z butami biegowymi płacący za kliknięcia w „running shoes repair”, „nike air max history” i „free running shoes”, z których żadnej 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ą.
Oto co się zmieniło. Skrypt w Pythonie pociąga zapytania z Google Ads API i przekazuje je modelowi open source, Gemmie 4 od Google, którą uruchomi niemal każdy współczesny pecet. Czyta tysiące zapytań w kilka minut. A gdy ugruntujesz go w kontekście o kliencie, mapie witryny, strukturze strony i bazy, taksonomii okruszków i feedzie produktowym, przestaje zgadywać i zaczyna rozumować. Wyklucza trafnie i nazywa wzorce stojące za śmieciami, szybciej niż jakiekolwiek ludzkie przeglądanie. Oto ten przepływ w pięciu konkretnych krokach.
POBIERZ · zdobądź surowe wyszukiwane hasła
Pociągnij raport wyszukiwanych haseł z Google Ads API. Zapytanie, kliknięcia, koszt, konwersje. Dlaczego najpierw: to jest dowód, realne pieniądze już wydane na każde hasło. Chcesz mieć koszt przy każdym wierszu, żeby model odróżnił drogie śmieci od nieszkodliwych. Dostajesz: płaską tabelę każdego hasła, za które konto zapłaciło w danym oknie.
UGRUNTUJ · zbuduj pakiet kontekstu o stronie
Zbierz to, czym strona naprawdę jest, w formie, którą model umie przeczytać. Mapa witryny XML, taksonomia okruszków, feed produktowy (id, title, category) oraz struktura bazy i kategorii. Dlaczego to cała gra: model bez kontekstu zgaduje; model, który wie, że nie masz kategorii „naprawa” ani „wypożyczenie”, rozumuje. Dostajesz: pakiet kontekstu, który zamienia model ze zgadywacza w coś, co zna twój katalog.
ZAPYTAJ · sklasyfikuj zapytania i nazwij wzorce
Podaj Gemmie 4 hasła plus pakiet kontekstu. Sklasyfikuj każde zapytanie jako trafne lub nietrafne wobec tego, co sprzedajemy, i, to ważna część, zwróć wzorce stojące za nietrafnymi (token, intencja, niedopasowanie kategorii). Dlaczego wzorce, nie wiersze: oznaczenie 200 śmieciowych zapytań oszczędza ci popołudnie; nazwanie całej kategorii śmieci wyklucza kolejny tysiąc, którego jeszcze nawet nie widziałeś. Dostajesz: listę nietrafnych zapytań i, nad nią, garść reguł, które ją wygenerowały.
SPRAWDŹ · waliduj reguły, nie wiersze
Człowiek czyta wzorce, od pięciu do dziesięciu, nie 5000 pojedynczych wierszy. Dlaczego tu jest oszczędność czasu: osąd stosuje się raz na regułę, nie raz na zapytanie, a błędna reguła jest oczywista w sposób, w jaki pojedynczy źle oznaczony wiersz nigdy nie jest. Dostajesz: krótką, zaufaną listę wzorców wykluczeń, którą człowiek faktycznie zatwierdził.
WGRAJ · dodaj wykluczenia na właściwym poziomie
Wgraj zatwierdzone wykluczenia z powrotem przez API na właściwym poziomie, grupy reklam, kampanii lub listy współdzielonej, w zależności od tego, jak szeroki jest wzorzec. Dlaczego poziom ma znaczenie: ogólnostronowy śmieciowy token („free”, „wikipedia”) należy na listę współdzieloną, nie zakopany w jednej grupie reklam. Dostajesz: wyczyszczone konto i wielokrotnego użytku listę wykluczeń, która działa dalej w przyszłym tygodniu.
Żeby zobaczyć, dlaczego to działa, spójrz, co krok ZAPYTAJ naprawdę zwraca dla naszego sklepu z butami biegowymi. Wiersze są ilustracyjne, kształt jest dokładnie tym, co wraca, a nagrodą jest blok na 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.
Cztery wiersze stały się jedną regułą. Człowiek czyta tę jedną linijkę, zgadza się, że jest słuszna, a reguła dalej łapie śmieci w stylu „running shoes free shipping returns”, których jeszcze nawet nie widziałeś. To moment, w którym ogłupiająca cotygodniowa harówka staje się dziesięciominutowym przeglądem.
Cichy nagłówek jest taki, że model open source działający lokalnie wystarcza. Nie potrzebujesz API frontier, żeby to się zwracało, a twoje dane nigdy nie opuszczają domu. To ekonomia się rusza, nie możliwości.
Drugie zadanie: badanie słów kluczowych
To 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 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 i luk na wierzchu.
Jeden projekt badania słów kluczowych, dawniej vs. dziś
- Stary sposób (pociągnij dane, wyczyść, sklasyfikuj, raportuj) 50–100 godz.
- Ile klient za to zapłacił ≈ 2 000–4 000 €
- Ten sam projekt dziś, z jednym dobrym skillem pojedyncze godziny
- A wynik jest dokładniejszy
To nie tylko taniej. To lepiej, precyzyjniej, z godzinami wydanymi na walidację i osąd zamiast na hydraulikę. Taniej i lepiej to dokładnie ta kombinacja, która miała być niemożliwa. Rozłożyłem nowoczesną wersję od początku do końca w blueprincie ekspansji rynkowej i w analizie luk w treści konkurencji, obie z prawdziwym pośrednim wynikiem pokazanym na każdym kroku.
Częścią, która wciąż mnie zaskakuje, jest rytm. Takie badanie było kiedyś rocznym projektem, który klient zatwierdzał raz. Ten sam pipeline może teraz biegać codziennie i patrzeć, jak popyt się przesuwa, zamiast fotografować go raz w roku.
Ekonomia, przed i po
To cała teza w jednej tabeli. Te same zadania, ta sama poprzeczka jakości; przesunął się tylko koszt ich wykonania. Udokumentowane liczby tam, gdzie je mam, rząd wielkości z dwudziestu lat pracy agencyjnej przy reszcie.
| Zadanie | Stary sposób | Dziś |
|---|---|---|
| Analiza ekspansji rynkowej (wyceny na wielu rynkach) | ~400 godz. ręcznie · albo 2 miesiące developmentu, 16–20 tys. € | 6 godz. |
| Badanie słów kluczowych (jeden projekt) | 50–100 godz. · 2 000–4 000 € na fakturze | pojedyncze godziny · dokładniej |
| Segregacja wykluczających haseł | półręczne przedzieranie się, tysiące wierszy ręcznie | skrypt + lokalny model nazywa wzorce |
| Dostarczenie jednej nowej funkcji automatyzacji | miesiące (2 devs × 2 lata na całe narzędzie) | tygodnie |
| Utrzymanie silnika raportowego przy życiu | ~100 tys. €/rok, nigdy się nie zwrócił | niemal zero z lokalnym modelem |
Przeczytaj tabelę z góry na dół, a wzorzec powtarza się w każdym wierszu. Kolumna możliwości się nie ruszyła; wszystko to umieliśmy już w 2019 roku. Kolumna ceny zapadła się przez podłogę. A okres zwrotu decyduje, czy mądry pomysł kiedykolwiek powstanie.
AI nie tyle odblokowało nowe możliwości PPC, ile skróciło okres zwrotu ze starych. Gdy półroczny projekt staje się dwutygodniowym, cały backlog „chętnie byśmy to zrobili, ale nigdy by się nie zwróciło” nagle się rozładowuje.
Jak to wygląda, gdy pójdziesz w to na całość
Lynt od pierwszego dnia jest agencją mocno techniczną. Mamy w zespole architekta systemów, inżyniera bezpieczeństwa, analityka danych budującego BI i programistę na pełen etat, czego zwykła agencja po prostu nie ma. Przez lata trudno było wycelować ten muskuł w problemy PPC, z wszystkich opisanych wyżej powodów zwrotu. Teraz się kumuluje.
Boostera, nasze własne narzędzie, zajęła dwa lata developmentu. Wzbogaca feedy Google Merchant Center za pomocą AI, więc kampanie Shopping jeżdżą na lepszych danych produktowych, niż daje surowy feed. Wokół niej siedzi hydraulika, którą nowa ekonomia w końcu uzasadnia. Scraping cen konkurencji per rynek, ten, który karmił tabele cenowe w blueprincie ekspansji. Pipeline’y badania słów kluczowych, które biegają według harmonogramu zamiast raz w roku. Raportowanie biznesowe na poziomie klienta w BigQuery z prognozami na wierzchu. Serwery MCP na każdej usłudze, której dotykamy, żeby agent AI mógł w trakcie zadania sięgnąć do dowolnej z nich.
Dwa lata temu musiałbym bronić każdego z tych projektów przed tym samym pytaniem, czy to się kiedykolwiek zwróci. Dziś to pytanie ledwo pada. Gdy budowanie tanieje, infrastruktura przestaje być luksusem i zaczyna być fosą.
Co to naprawdę oznacza dla branży
Popularne ujęcie mówi, że AI kończy ze specjalistą PPC. Zrozumienie tego na opak ma realne konsekwencje dla kariery ludzi, którzy to czytają, więc pozwól, że wbiję flagę.
„Era specjalistów PPC dobiega końca” to bzdura. Dzieje się dokładnie odwrotnie. Dobrzy specjaliści latami frustrowali się tym, że mądra rzecz, ta, 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 stoją ludzie, którzy traktują interfejs platformy jako całą robotę i pozwalają nowym narzędziom przejść obok. Nikt ich jutro nie zwolni. Zamierają w miejscu, podczas gdy praca się przesuwa. Po drugiej stronie stoją ludzie, którzy znają Google Ads API do szpiku kości, łączą źródła danych, których nikt inny nie łączy, i budują sobie wyspecjalizowane dashboardy, zamiast czekać, aż dostawca dowiezie funkcję. Dwanaście lat pisania kodu przeciwko temu API nauczyło mnie, gdzie naprawdę mieszka przewaga tej drugiej grupy. Kod staniał. Rzadkie pozostały wyobraźnia i znajomość domeny, wiedza, które dane połączyć i po co.
I żeby zabić oczywistą pomyłkę, to nie jest opowieść o tańszej usłudze. Narzędzia, moc obliczeniowa i development dalej kosztują. Chodzi o to, że projekt, który dawniej był czterema do sześciu miesiącami dwóch seniorów, teraz dowozi się w tygodnie, więc inwestycja w końcu ma sens. Klient dostaje dramatycznie lepszą usługę za podobną cenę.
Dlaczego znowu piszę
Przestałem blogować w 2017 roku, bo przepaść między pomysłem a ekonomicznie rozsądną realizacją była zbyt szeroka, żeby była ciekawa. Ta przepaść właśnie się zamknęła. Ten blog podejmuje więc wątek tam, gdzie skończył ppc-scripts.eu, i zostaje konkretny. Przypadki użycia z realnymi liczbami, dokładne przepływy, faktyczne wyniki, łącznie z brudnymi fragmentami i ograniczeniami. Pierwsze deep dive’y już są online.
Gdzieś w twoim własnym backlogu leży automatyzacja, którą odłożyłeś lata temu, bo nigdy by się nie zwróciła. Wygrzeb ją i przelicz liczby jeszcze raz. Jeśli przewróciły się tak jak moje, wiesz, co budować dalej. A jeśli chcesz porównać notatki, wiesz, gdzie mnie znaleźć.
FAQ
Czy twierdzisz, że agencje powinny zwalniać specjalistów PPC?
Dokładnie odwrotnie. Specjaliści rozumiejący strategię i narzędzia są teraz cenniejsi, bo w końcu mogą realizować pomysły, które dawniej były nieopłacalne. Maleje wartość samego klikania w interfejs platformy.
Czy kwota 100 tys. € rocznie i dwóch programistów przez dwa lata jest dokładna?
Nie, traktuj ją jako rząd wielkości. Nie chodzi o dokładną sumę w euro. Jeden wewnętrzny silnik raportowy niósł sześciocyfrowy roczny koszt i mimo to nigdy się nie zwrócił. O tej ekonomii jest cały ten tekst.
Czy potrzebuję drogiego modelu frontier, żeby to zrobić?
Nie do zadań takich jak segregacja wykluczających haseł. Zdolny model open source jak Gemma 4, uruchomiony lokalnie z dobrym kontekstem strony, robi robotę. Dane i koszty zostają przy tym pod twoją kontrolą.
Czy chodzi tylko o wyszukiwane hasła?
Nie, to po prostu zadanie, któremu najłatwiej się przyglądać. Ta sama ekonomia ruszyła w analizie ekspansji rynkowej (sześć godzin zamiast ~400), scrapingu cen konkurencji per rynek, badaniu słów kluczowych, które biega codziennie zamiast raz w roku, i wzbogacaniu feedu Boosterą. Wybierz dowolny odłożony obowiązek i przelicz go od nowa.
Czyli to po prostu hype w nowym opakowaniu?
Gdyby tak było, nie zacząłbym znowu pisać. Zmiana jest wąska i realna, skrócony okres zwrotu z możliwości, które już mieliśmy. To zmiana biznesowa, nie magiczna, i dlatego backlog nagle się rozładowuje.
Co właściwie będzie na tym blogu?
Konkretne przypadki użycia z liczbami, stojące za nimi przepływy i wyniki, łącznie z ograniczeniami i trybami awarii. Mniej manifestu, więcej dokładnie tej rzeczy, którą uruchomiliśmy, i tego, co zwróciła.