Modelowane listy odbiorców nie zawierają konkretnych osób, tylko prawdopodobieństwa. Wyjaśniam, jak powstają, gdzie ich szukać w panelu i jak czytać ich raporty.
Po tym, jak kampanie Smart Shopping zostały w tym roku przeniesione do Performance Max, pytanie o wykluczanie fraz wróciło w każdym koncie, które prowadzę. Mechanizm jest znany: kampania sięga po ruch z wyszukiwarki, a reklamodawca nie ma pola, w którym mógłby powiedzieć „na to nie chcę się pokazywać”.
Zaznaczę to od razu, bo tytuł tego wpisu może obiecywać więcej, niż da się dowieźć. Skrypt nie doda wykluczenia wewnątrz kampanii Performance Max, bo nie ma tam czego dodać — ten typ kampanii nie przyjmuje wykluczających słów kluczowych na swoim poziomie. To ograniczenie panelu, nie ograniczenie skryptów.
Automatyzacja ma tu jednak sens, tylko trochę inny niż w kampaniach w sieci wyszukiwania. Skrypt służy do zbierania kandydatów, pilnowania listy i alarmowania, a nie do samego wykluczania. Poniżej opisuję, jak to sobie poukładałem i gdzie są granice.
Performance Max obsługuje jednocześnie wyszukiwarkę, sieć reklamową, YouTube, Discover, Gmail i Mapy. Frazy nie są tu jednostką zarządzania — sygnałem są zasoby, feed produktowy i grupy odbiorców.
Konsekwencja praktyczna jest podwójna. Pierwsza: w kampanii nie ma raportu wyszukiwanych haseł. Nie zobaczę listy konkretnych zapytań, na które pokazały się reklamy, ani tego, ile kosztowały. Google mówi o zwiększaniu przejrzystości, ale dziś tego wglądu po prostu nie mam.
Druga: nie ma pola na wykluczenia. W kampanii w sieci wyszukiwania wystarczy dopisać frazę do listy w grupie reklam albo w kampanii. W Performance Max ta ścieżka nie istnieje.
Efekt widzę na kontach jako rozmycie odpowiedzialności. Wydatek rośnie, część konwersji jest oczywiście brandowa, część ruchu wygląda na przypadkową — i nie ma czym tego rozdzielić. Zanim więc sięgnę po skrypt, muszę zaakceptować, że pracuję z niepełnymi danymi.
Zostają trzy mechanizmy i warto je rozdzielić, bo działają na innych poziomach.
Ważne, czego na tej liście nie ma: sygnały odbiorców nie są wykluczeniem. Dodanie listy klientów jako sygnału podpowiada systemowi, kogo szukać, ale nie zabrania mu wyjść poza ten krąg.
Skoro to jedyne narzędzie, łatwo je przeciążyć. Widzę dwie typowe pomyłki.
Pierwsza: wrzucanie na listę konta fraz, które w kampaniach w wyszukiwarce mają sens. Lista działa na wszystko, więc wykluczenie ogólnego słowa potrafi wyciąć ruch w kampanii, która na tym samym słowie zarabiała. Zawsze sprawdzam, czy dana fraza występuje w raporcie wyszukiwanych haseł kampanii, które działają dobrze.
Druga: wykluczanie własnej marki bez policzenia konsekwencji. Kusi, bo ruch brandowy w Performance Max zawyża wyniki i psuje obraz. Tylko że wykluczenie marki z poziomu konta zabiera ją także kampanii brandowej, a osobnego przełącznika dla samego Performance Max po prostu nie ma. To decyzja typu wszystko albo nic i tak ją trzeba zakomunikować klientowi.
Lista ma też limit rozmiaru, więc nie jest workiem na kilkadziesiąt tysięcy fraz z długiego ogona. Trafiają na nią wykluczenia mocne i trwałe: konkurencja, wulgaryzmy, praca i rekrutacja, „darmowe”, nazwy usług, których firma nie świadczy.
Skoro samego wykluczenia skrypt nie wykona, robi trzy inne rzeczy — i to one dają oszczędność czasu.
Zbiera kandydatów. Skrypt przechodzi raport wyszukiwanych haseł kampanii w sieci wyszukiwania i produktowych z tego samego konta, filtruje zapytania z kosztem powyżej progu i zerową liczbą konwersji, dopasowuje je do listy zakazanych wzorców i zapisuje wynik do arkusza. Zapytań z Performance Max tam nie będzie, ale wzorce nietrafnego ruchu w koncie zwykle się powtarzają — to, co szkodzi w wyszukiwarce, szkodzi też w kampanii automatycznej.
Pilnuje wzorców. Utrzymuję prostą listę reguł: nazwy firm konkurencyjnych, słowa „praca”, „opinie o”, „za darmo”, „instrukcja”, nazwy produktów, których nie mamy w ofercie. Skrypt codziennie sprawdza świeże zapytania pod te reguły i zgłasza trafienia mailem, zamiast czekać, aż ktoś usiądzie do raportu w piątek.
Wykonuje robotę tam, gdzie może. W kampaniach w wyszukiwarce i produktowych skrypt dopisuje wykluczenia od razu — do listy współdzielonej podpiętej do kampanii. To ta część, gdzie automatyzacja jest pełna i bezpieczna, bo działa na obiektach, które skrypty obsługują od lat.
Listę na poziomie konta aktualizuję ręcznie, na podstawie tego, co skrypt przygotował. W praktyce raz na dwa tygodnie, w jednym zgłoszeniu, zamiast po jednej frazie.
Warto to wyliczyć wprost, bo w internecie krąży sporo obietnic, których kod nie może spełnić.
Nie wyciągnie zapytań z Performance Max, bo tych danych nie ma ani w panelu, ani w raportach, do których skrypt ma dostęp. Nie zbuduje więc raportu „na co poszły pieniądze w Performance Max według fraz” — żaden skrypt tego dziś nie zrobi, niezależnie od tego, jak jest reklamowany.
Nie oceni też trafności zapytania za Ciebie. Reguły, które wpiszesz, to jedyna wiedza, jaką skrypt ma o Twojej ofercie. Dlatego pierwszy tydzień pracy takiego rozwiązania to głównie poprawianie reguł, a nie oszczędność czasu.
I rzecz z gatunku bezpieczeństwa: nie uruchamiam skryptu, który sam dodaje wykluczenia bez ograniczeń. Zawsze mam próg kosztu, limit liczby zmian na dobę i tryb testowy, w którym skrypt tylko raportuje. Skrypt działający na koncie klienta bez limitów potrafi w jedną noc wyciąć ruch, którego nikt nie chciał wyciąć.
Kolejność, która się u mnie sprawdza, jest taka.
Raz w miesiącu czytam raport wyszukiwanych haseł kampanii w wyszukiwarce ręcznie, bez skryptu. To źródło reguł — żadna automatyzacja nie wymyśli za mnie, że klient nie zajmuje się serwisem sprzętu, który sprzedaje.
Codziennie skrypt zgłasza trafienia nowych reguł i dopisuje wykluczenia tam, gdzie może. Raz na dwa tygodnie przeglądam kandydatów do listy na poziomie konta i wysyłam zgłoszenie. Notuję przy tym datę i treść zmiany, bo bez tego po dwóch miesiącach nie odtworzę, co spowodowało spadek wyświetleń.
Osobno, przy każdej większej zmianie, pilnuję jednej rzeczy: czy po wykluczeniach kampania nadal ma z czego wybierać. Performance Max nie znosi jednoczesnego zawężania z wielu stron — obciętego feedu, wąskich sygnałów i długiej listy wykluczeń naraz. Jeśli wynik siada, sprawdzam to w pierwszej kolejności, zanim zacznę zmieniać stawki czy budżet.
Używamy plików cookies, aby ułatwić Ci nawigację oraz wykonywanie określonych funkcji. Szczegółowe informacje o wszystkich plikach cookies znajdziesz w każdej kategorii zgody poniżej.
Pliki cookies oznaczone jako "Niezbędne" są przechowywane w Twojej przeglądarce, ponieważ są one kluczowe dla zapewnienia podstawowych funkcji strony.
Używamy również plików cookies firm trzecich, które pomagają nam analizować, w jaki sposób korzystasz z tej strony, zapamiętują Twoje preferencje oraz dostarczają treści i reklamy odpowiednie dla Ciebie. Te pliki cookies będą przechowywane w Twojej przeglądarce tylko za Twoją uprzednią zgodą.
Możesz zdecydować, czy chcesz włączyć lub wyłączyć niektóre bądź wszystkie te pliki cookies, jednak wyłączenie niektórych z nich może wpłynąć na Twoje doświadczenia podczas przeglądania strony.
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __cf_bm | 13 minutes | Cloudflare bot management — distinguishes humans from bots. |
| rc::* | Persistent | Google reCAPTCHA — localStorage holding anti-bot challenge state. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| wpEmojiSettingsSupports | Session | WordPress — sessionStorage flag caching whether the browser can render emoji (feature detection). |
| ytidb* | Persistent | YouTube — IndexedDB storing playback/search state for embedded videos. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| _ga_* | 400 days | Google Analytics 4 — persists session state per property. |
| _ga | 400 days | Google Analytics — distinguishes unique users via a client id. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| NID | 183 days | Google — stores preferences for personalized ads. |
| fr | 90 days | Meta — encrypted Facebook id and browser id for ads. |
| _gcl_au | 90 days | Google AdSense/Ads — experiments with advertising efficiency (conversion linker). |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __Secure-YNID | 180 days | |
| YSC | Session | |
| __Secure-ROLLOUT_TOKEN | 180 days | |
| VISITOR_INFO1_LIVE | 180 days | |
| VISITOR_PRIVACY_METADATA | 180 days | |
| datr | 400 days | |
| sb | 400 days | |
| wd | 7 days |