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.
Docelowy ROAS jest w sklepach ustawieniem domyślnym niemal wszędzie i zwykle działa. Kłopot pojawia się wtedy, gdy sklep ma produkty o bardzo różnej marży — a to jest sytuacja typowa, nie wyjątkowa.
Mechanizm jest nieprzyjemnie logiczny. Algorytm optymalizuje pod wartość, którą mu przekazujesz, więc jeśli przekazujesz przychód, będzie dążył do maksymalizacji przychodu. Podbije stawki tam, gdzie koszyki są duże, niezależnie od tego, ile z tego koszyka zostaje w firmie. W sklepie z elektroniką i akcesoriami oznacza to systematyczne przesuwanie budżetu na drogi sprzęt z marżą liczoną w kilku procentach, przy jednoczesnym duszeniu kategorii, które faktycznie zarabiają.
Rozwiązaniem jest przekazywanie wartości opartej na marży zamiast na przychodzie. Brzmi to jak jedna zmiana w tagu, a jest decyzją, która pociąga za sobą przeliczenie celów, przebudowę struktury i kilka tygodni cierpliwości. Poniżej opisuję, jak do tego podejść.
Weźmy skrajny, ale prawdziwy typ sklepu: dwie kategorie, jedna z marżą kilkuprocentową i wysoką ceną, druga z marżą kilkudziesięcioprocentową i ceną niską. Przy celu ROAS liczonym od przychodu obie kategorie oceniane są tą samą miarą, więc z punktu widzenia algorytmu droga sprzedaż z marnym zarobkiem jest lepsza niż tania sprzedaż z dobrym.
Skutek widzę na kontach zawsze w tej samej postaci: raport pokazuje świetny zwrot z wydatków, a właściciel mówi, że pieniędzy nie ma. Oba stwierdzenia są prawdziwe, bo mierzą różne rzeczy.
Do tego dochodzi drugi efekt, mniej widoczny. Strategia oparta na przychodzie premiuje też produkty często zwracane, jeśli zwroty nie są odejmowane od wartości konwersji. Przy odzieży to nie detal, a różnica rzędu kilkudziesięciu procent obrotu, która w Google Ads po prostu nie istnieje.
Trzeci efekt dotyczy rabatów. Jeśli do Google trafia wartość zamówienia przed rabatem albo z kosztem dostawy w środku, algorytm dostaje wartość zawyżoną i to zawyżoną nierównomiernie — najbardziej przy zamówieniach promocyjnych, które zarabiają najmniej.
Zanim cokolwiek wdrożę, ustalam z klientem definicję. To rozmowa, nie ustawienie, i zwykle najtrudniejszy etap całego projektu.
Wybieram najprostszy wariant, który da się wyliczyć automatycznie w systemie sklepu. Marża licząca się idealnie, ale wpisywana ręcznie w arkuszu raz na kwartał, jest bezużyteczna, bo przestanie być aktualna szybciej, niż zdąży się przeliczyć.
Ważne zastrzeżenie: nie mieszam do tej definicji kosztów stałych i budżetu reklamowego. Wartość konwersji ma opisywać, ile zostaje po sprzedaniu towaru, a nie ile firma zarabia po wszystkich kosztach — bo koszt reklamy jest właśnie tym, czym steruje strategia.
To miejsce, w którym najczęściej wszystko się psuje. Jeśli podmienię przekazywaną wartość z przychodu na marżę i zostawię dotychczasowy cel, kampania w praktyce dostanie cel wielokrotnie wyższy niż wcześniej — bo mianownik został ten sam, a licznik spadł do części dawnej wartości.
Skutek jest natychmiastowy: system uznaje, że prawie żadna aukcja nie spełnia wymagań, i ruch spada niemal do zera. Widziałem to na kontach po zmianach wprowadzonych z dobrymi intencjami przez dział IT, bez informowania kogokolwiek od kampanii.
Przeliczenie jest arytmetyczne i trzeba je zrobić przed wdrożeniem. Jeśli średnia marża w sklepie wynosi jedną czwartą przychodu, to dotychczasowy cel trzeba podzielić przez cztery, żeby wymagać od kampanii tego samego co wcześniej. Cel liczony od marży jest po prostu wyrażony w innej jednostce i musi mieć inną wartość liczbową.
Dopiero mając cel przeliczony neutralnie, zaczynam nim sterować — i od tego momentu ma on realny sens biznesowy, bo cel równy jedności oznacza wyjście na zero na poziomie marży, a nie zagadkową liczbę zależną od struktury asortymentu.
Zmiany celu wprowadzam potem tak jak zawsze przy strategiach automatycznych: pojedynczo, o kilka procent, z tygodniową przerwą na obserwację.
Nie każdy sklep musi od razu przekazywać dokładną marżę każdego produktu. Zwykle idę schodkami.
Pierwszy schodek to jednolity mnożnik dla całego sklepu — do Google trafia przychód pomnożony przez średnią marżowość. Nie różnicuje produktów, więc nie rozwiązuje głównego problemu, ale porządkuje skalę i pozwala myśleć o celu w kategoriach zarobku. Robię to wtedy, gdy sklep nie ma danych o kosztach zakupu w systemie.
Drugi schodek to mnożnik na poziomie kategorii albo grupy produktowej. To najczęściej wybierany wariant, bo w większości sklepów marża jest podobna w obrębie kategorii, a dane wystarczy przypisać raz i aktualizować przy zmianach cenników. Ten wariant rozwiązuje większość problemu przy niewielkim nakładzie.
Trzeci schodek to marża rzeczywista per produkt, wyliczana w koszyku z aktualnych kosztów zakupu. Najdokładniejszy i najbardziej wymagający — wymaga, żeby system sklepu znał koszt zakupu każdego towaru i żeby ten koszt był aktualizowany.
Przy sklepie z tysiącami pozycji zwykle kończy się na drugim schodku i to jest rozsądny kompromis. Trzeci ma sens tam, gdzie marża zmienia się wewnątrz kategorii drastycznie.
Pierwsza rzecz: strategia wraca do okresu uczenia. Nie tyle formalnie, ile faktycznie — dostaje inny rozkład wartości, więc dotychczasowe wnioski częściowo się dezaktualizują. Zakładam dwa, trzy tygodnie rozchwianych wyników i nie podejmuję w tym czasie żadnych decyzji.
Druga rzecz: raporty przestają być porównywalne z historią. Wartość konwersji w Google Ads po zmianie oznacza coś innego niż przed nią, więc porównania rok do roku wymagają przypisu. Zapisuję datę zmiany w dokumentacji konta i uprzedzam o tym każdego, kto czyta raporty, bo inaczej pierwszy miesiąc wygląda jak katastrofa.
Trzecia rzecz, dla mnie najciekawsza: zmienia się struktura ruchu. Kampanie zaczynają częściej pokazywać produkty z lepszą marżą, przychód nominalnie potrafi spaść, a zarobek wzrosnąć. Dlatego przed wdrożeniem umawiam się z klientem, że oceniamy skutek po marży, nie po obrocie — inaczej rozmowa po miesiącu jest bardzo trudna.
Czwarta: część kampanii może wymagać innych celów niż wcześniej, bo różnice marżowości między nimi wychodzą teraz na wierzch. To dobry moment, żeby przejrzeć podział budżetów.
Przekazywanie marży rozwiązuje problem wewnątrz kampanii, ale nie rozwiązuje problemu budżetów między kampaniami. Jeśli wszystko siedzi w jednym worku z jednym budżetem, to nadal ja decyduję, ile pieniędzy trafia do których produktów.
Dlatego przy sklepach o mocno zróżnicowanej marżowości rozdzielam kampanie produktowe co najmniej na dwie grupy: produkty wysokomarżowe i pozostałe. Każda dostaje własny budżet i własny cel. To pozwala świadomie zdecydować, że kategoria o niskiej marży ma dowozić obrót i pracować na próg opłacalności, a nie rywalizować o budżet z kategorią, która zarabia.
Osobno traktuję produkty, które są wejściem do relacji — takie, na których pierwsza sprzedaż nie zarabia, ale klient wraca. Tu cel ustawiam niżej świadomie, a nie przez pomyłkę, i zapisuję dlaczego. Bez tej notatki po pół roku ktoś „naprawi” tę kampanię, podnosząc jej cel.
Przy okazji porządkuję etykiety niestandardowe w pliku produktowym. Etykieta z poziomem marżowości jest jedną z najbardziej użytecznych rzeczy, jakie można tam wstawić, a wstawia ją mało kto.
Najczęstsza: marża przekazywana w innej walucie albo z podatkiem, gdy reszta konta operuje bez. Nie brzmi groźnie, dopóki nie okaże się, że cel jest błędny o wartość stawki podatku i nikt tego nie zauważył przez kwartał.
Druga: brak zabezpieczenia na wartości zerowe i ujemne. Produkt sprzedany poniżej kosztu zakupu daje ujemną marżę, a Google Ads nie przyjmie ujemnej wartości konwersji. Trzeba zdecydować, co wtedy wysyłać — zwykle wartość zerową — i mieć to obsłużone w kodzie, a nie liczyć, że taka sytuacja nie nastąpi.
Trzecia: rozjazd między Google Ads i Merchant Center. Jeśli w pliku produktowym zostaje cena, a w konwersjach marża, raporty z dwóch narzędzi opowiadają dwie różne historie i po miesiącu nikt nie wie, która jest prawdziwa. Warto z góry ustalić, które źródło jest referencyjne dla jakiej decyzji.
Czwarta, najbardziej ludzka: wdrożenie w środku sezonu. Nie robię tej zmiany w listopadzie ani w tygodniu wyprzedaży. Najlepszy moment to spokojny okres, w którym rozchwianie wyników przez dwa tygodnie nikogo nie zaboli — i dlatego styczeń bywa na to najlepszym miesiącem w roku.
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 |