Agent, który codziennie czyta konto Google Ads i podsuwa rekomendacje do zatwierdzenia

Kto to był i co go bolało

Firma B2B prowadząca własne konto reklamowe w Google Ads. Konto nie jest ogromne, ale wymaga codziennego oka. Frazy zaczynają przeciekać z dnia na dzień, budżet ucieka na zapytania, które nigdy nie dowiozą klienta, a jeżeli nikt nie zajrzy przez tydzień, strata jest już policzalna.

Naturalnym odruchem jest sięgnięcie po gotowe narzędzie do audytu konta. Problem w tym, że takie narzędzia oceniają każde konto tą samą miarą, czyli miarą sklepu, w którym lead kosztuje dziesięć złotych. W modelu B2B jeden lead potrafi być wart tyle, ile w sklepie warta jest setka zamówień. Rekomendacje typu "obniż stawkę, bo koszt kliknięcia jest wysoki" są w tym kontekście po prostu szkodliwe.

Drugi ból to powtarzalność rad. Narzędzia lubią co tydzień proponować to samo, bo nie pamiętają, co już zostało zrobione. Jeżeli lista negatywnych fraz na koncie jest budowana od dwóch lat, to dostawanie propozycji dodania fraz, które już tam są, jest tylko szumem, przez który przestaje się czytać całą listę.

I trzecia rzecz, postawiona twardo od początku: żadnych automatycznych zmian na koncie. Agent może wszystko przeczytać i wszystko zaproponować, ale nie tyka ustawień. Decyzję podejmuje człowiek.

Co zrobiliśmy

Zbudowaliśmy agenta, który codziennie pobiera dane z konta i przygotowuje listę rekomendacji do zatwierdzenia. Warstwa pobierania danych stoi na Pythonie i korzysta z API Google Ads w trybie wyłącznie do odczytu - to nie jest kwestia dyscypliny, tylko uprawnień, więc agent fizycznie nie ma jak nic zmienić.

Codzienny odczyt obejmuje kampanie, frazy i zapytania, na które wyświetlały się reklamy. Te dane trafiają do modelu analitycznego razem z kontekstem biznesowym: jaki jest model sprzedaży, ile realnie wart jest lead, kto jest klientem docelowym. Dzięki temu ocena konta nie jest ćwiczeniem z arytmetyki na koszcie kliknięcia, tylko rozmową o tym, czy dane zapytanie w ogóle może przynieść klienta.

Zanim agent zaproponuje cokolwiek, robi cross-check z tym, co już jest zrobione. Czyta istniejące listy fraz wykluczających i wycina ze swojej listy wszystko, co ktoś dodał wcześniej. To banalny mechanizm, ale to on decyduje o tym, czy raport da się czytać.

Gotowe rekomendacje lądują na dashboardzie z poziomem ważności i uzasadnieniem. Historia rekomendacji, ich statusy i dane pomocnicze siedzą w Supabase, a całość odpala się z harmonogramu raz na dobę. Człowiek przechodzi po liście i oznacza pozycje jako wdrożone albo odrzucone.

Jak to działa dzisiaj

Agent chodzi w trybie ciągłym, raz dziennie. Rano na dashboardzie czeka lista propozycji uporządkowana według ważności, każda z krótkim wyjaśnieniem, skąd się wzięła i którego fragmentu konta dotyczy. Nic nie jest wdrażane samo.

Oznaczanie pozycji jako wdrożonych albo odrzuconych nie jest tylko porządkiem w interfejsie. To sygnał zwrotny, przez który agent przestaje wracać do tematów już zamkniętych. Efekt jest taki, że lista jest krótsza z tygodnia na tydzień, a nie dłuższa.

Co z tego wyszło

Konto jest analizowane raz dziennie zamiast wtedy, kiedy ktoś znajdzie czas. Agent pracuje w trybie wyłącznie do odczytu, więc żadna zmiana nie wchodzi bez zgody człowieka. Kontekst kosztu leada w modelu B2B jest częścią oceny, a nie dopiskiem na końcu raportu. Cross-check z istniejącymi frazami wykluczającymi robi się automatycznie, więc te same rady nie wracają w kółko.

Co zrobilibyśmy inaczej

Największym wąskim gardłem nie było ani API, ani model, tylko opis kontekstu biznesowego. Pierwsza wersja miała go za mało i agent, mimo dostępu do wszystkich danych, wydawał rekomendacje jak z podręcznika dla sklepów. Dopisanie kilku akapitów o tym, ile realnie wart jest lead i kto jest klientem, zmieniło jakość wyników mocniej niż jakakolwiek zmiana techniczna. Następnym razem zaczynamy od tego, a nie od integracji.

Nie doceniliśmy też cross-checku z tym, co już zrobione. Traktowaliśmy go jako drobny dodatek, a okazał się warunkiem, żeby ktokolwiek w ogóle czytał codzienny raport. Przy kolejnym agencie monitorującym wpiszemy pamięć o wykonanych działaniach do pierwszej wersji, nie do drugiej.