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.
Performance Max nie daje stawek na produkcie i nie da ich w przewidywalnej przyszłości. Jedyne, czym realnie kieruję, to cel kampanii i to, jakie produkty do niej wpuszczam. Cała „zaawansowana segmentacja stawek” sprowadza się więc do jednego pytania: jak podzielić asortyment, żeby każdej części móc postawić inny cel.
Najwygodniejszym nożem do tego cięcia są etykiety własne w pliku produktowym. Nie dlatego, że są sprytne — są prymitywne. Dlatego, że są jedynym wymiarem, który definiuję sam, po swojemu, na podstawie danych, których Google nie ma.
Opisuję poniżej, jak układam to na kontach sklepowych: jakie wymiary wybieram, jak je wypełniam i gdzie ta metoda przestaje działać.
Kampania ma jeden docelowy zwrot z nakładów. Asortyment sklepu prawie nigdy nie ma jednej rentowności.
Jeśli w jednej kampanii siedzą produkty z marżą kilkuprocentową i takie z marżą kilkudziesięcioprocentową, algorytm optymalizuje pod wartość zamówienia, a nie pod to, co zostaje w kasie. Będzie wtedy chętnie dowoził obrót na tanich, dobrze konwertujących pozycjach i formalnie realizował cel, podczas gdy zysk stoi w miejscu. Widzę to na większości kont, które przejmuję, i prawie zawsze wygląda to tak samo: raport ładny, właściciel niezadowolony.
Drugi powód jest prostszy. Różne części asortymentu mają różną rolę: coś jest wabikiem, coś nośnikiem marży, coś trzeba wyprzedać. Postawienie im wspólnego celu oznacza, że żadna z tych ról nie jest realizowana świadomie.
Podział etykietami rozwiązuje to bez podnoszenia budżetu — po prostu przestaję uśredniać.
Etykiety własne to pięć niezależnych pól w pliku produktowym, numerowanych od zera do czwórki. Wpisujesz w nie dowolny tekst, a Google nie próbuje go interpretować. To cała mechanika.
Trzy rzeczy, o których warto pamiętać, zanim zacznie się je wypełniać:
Stosuję prostą zasadę nazewnictwa: prefiks mówiący, o jaki wymiar chodzi, i wartość opisowa, czyli na przykład „marza-wysoka” zamiast „A”. Kosztuje to kilka znaków więcej, a ratuje przed pomyłką za każdym razem, gdy do konta zagląda ktoś nowy.
Najczęstszy błąd to dublowanie danych, które Google i tak ma. Marka, kategoria, typ produktu, dostępność, cena — to wszystko jest już w pliku i można na tym budować grupy list produktów bez żadnej etykiety.
Etykiety zostawiam na to, czego w pliku nie ma i mieć nie może:
Więcej niż trzy wymiary jednocześnie rzadko ma sens. Każdy dodatkowy podział to więcej kombinacji, a przy pięciu polach i kilku wartościach w każdym łatwo dojść do siatki, której nikt nie umie już obsłużyć.
Etykietę można wykorzystać na dwóch poziomach i wybór między nimi jest właściwą decyzją strategiczną.
Grupa list produktów w grupie plików ogranicza asortyment w ramach jednej kampanii. Zaletą jest wspólny budżet i wspólna nauka algorytmu, wadą — wspólny cel, więc rozdzielenie rentowności tą drogą nie zadziała. Używam tego, gdy chcę tylko coś wykluczyć albo wyodrębnić bez zmiany celu.
Osobne kampanie to jedyny sposób na osobny cel i osobny budżet. Tego wymaga podział po marży. Kosztem jest rozdrobnienie danych: kampania, do której wpada garść konwersji miesięcznie, uczy się wolno i wynikami skacze.
Trzecia rzecz do przemyślenia: ten sam produkt nie powinien należeć do dwóch kampanii produktowych naraz, bo o wyświetlenie decyduje wtedy mechanizm priorytetów, a nie moje założenia. Buduję więc etykiety tak, żeby wartości były rozłączne i wyczerpujące — każdy produkt trafia dokładnie do jednego koszyka.
Etykieta wpisana raz ręcznie jest bezużyteczna po miesiącu. Marża się zmienia, wyprzedaż się kończy, nowość przestaje być nowością.
Najczystszym rozwiązaniem jest wyliczanie etykiet po stronie sklepu i wysyłanie ich w głównym pliku produktowym. Jeśli nie ma na to zgody działu IT, drugą drogą jest plik dodatkowy dopisujący etykiety po identyfikatorze produktu — dane liczę wtedy w arkuszu albo w prostym skrypcie i podmieniam raz na dobę.
Reguły w panelu Merchant Center wystarczają tylko do podziałów opartych na czymś, co już w pliku jest, na przykład na progach cenowych. Marży w nich nie policzysz.
Programowo dostępne są dwa interfejsy: Merchant API, ogólnie dostępny od sierpnia 2025 roku, oraz starsze Content API for Shopping, które pozostaje w produkcji do wygaszenia zaplanowanego na sierpień 2026. Jeśli ktoś zaczyna integrację teraz, nie ma sensu pisać jej na wersji, która ma za pół roku zniknąć.
Podział bez kontroli zamienia się w chaos wolniej, niż się wydaje, ale zamienia się na pewno.
Raz w tygodniu sprawdzam trzy rzeczy: czy każdy produkt ma etykietę i żadna pozycja nie wypadła do wartości pustej, jak rozłożył się budżet między kampaniami, oraz czy któraś z nich nie zgłodniała do poziomu, na którym przestaje się uczyć. Przy okazji patrzę na liczbę produktów w koszykach — jeśli jeden zebrał prawie cały asortyment, podział jest tylko pozorny.
Do oceny jakości ruchu używam raportu wyszukiwanych haseł, który Performance Max dostał w marcu 2025 roku, oraz raportu grup zasobów. Zanim ten raport się pojawił, tego rodzaju porównania między kampaniami robiło się na wyczucie; teraz da się zobaczyć, czy podział po marży nie oznacza przypadkiem podziału na dwie zupełnie różne intencje zakupowe.
Na koniec rzecz najważniejsza i najczęściej pomijana: wynik oceniam na marży, nie na zwrocie z nakładów. Cały ten podział robi się właśnie po to, żeby móc to policzyć — a jeśli raport nadal kończy się na przychodzie, to zmieniła się tylko struktura konta, nie decyzje.
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 |