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.
Rozmowa zawsze wygląda podobnie. Konto ma zwrot z nakładów na poziomie, który wszyscy uznają za dobry, sprzedaż rośnie, a właściciel mówi, że na koncie firmowym tego nie widać. Nie ma w tym żadnej sprzeczności: zwrot liczony od przychodu nie wie nic o tym, ile kosztuje towar, przesyłka, obsługa płatności i przyjęcie zwrotu.
Skrót POAS opisuje prostą korektę tego rachunku — zamiast dzielić przychód przez wydatki na reklamę, dzielimy przez nie zysk. Pomysł jest oczywisty i dlatego zaskakuje, jak rzadko jest wdrożony. Powód też jest prosty: cała trudność nie leży w formule, a w tym, żeby wiedzieć, ile naprawdę zarabiamy na pojedynczym zamówieniu.
Poniżej opisuję, w jakiej kolejności to układam, jakie koszty wliczam i w którym miejscu warto się zatrzymać, zamiast iść na całość.
Problem nie polega na tym, że wskaźnik jest zły. Polega na tym, że jest jednakowy dla towarów, które zarabiają zupełnie różnie.
W typowym sklepie różnice marż między kategoriami są ogromne. Sprzedaż elektroniki przy kilku procentach narzutu i sprzedaż akcesoriów przy kilkudziesięciu wyglądają w raporcie reklamowym identycznie, o ile kwoty zamówień są zbliżone. Algorytm optymalizujący pod wartość konwersji dostaje więc informację, że oba zamówienia są równie cenne, i będzie kupował ruch tam, gdzie łatwiej o obrót — czyli zwykle na najtańszym, najgorzej zarabiającym asortymencie.
Do tego dochodzą koszty, które nie zależą od wartości zamówienia, a od jego istnienia: pakowanie, kurier, obsługa zwrotu, czas pracownika. Zamówienie na osiemdziesiąt złotych z darmową dostawą potrafi być dla firmy stratą, a w kolumnie przychodu wygląda jak sukces.
Widzę to na większości kont sklepowych, które przejmuję: reklama sumiennie realizuje cel, który jej postawiono, tylko cel opisuje coś innego niż interes firmy.
Tu podejmuje się najwięcej decyzji i tu najłatwiej przedobrzyć.
Poza rachunkiem zostawiam koszty stałe: czynsz, wynagrodzenia biura, oprogramowanie. Nie dlatego, że nie istnieją, ale dlatego, że nie zależą od pojedynczego zamówienia i po rozbiciu na sztuki wprowadzają więcej szumu niż informacji. Interesuje mnie tutaj marża, którą zamówienie wnosi, a nie pełny wynik spółki.
W praktyce wystarczy pierwsza pozycja i szacunek dla pozostałych, żeby obraz zmienił się radykalnie. Nie warto blokować projektu, czekając na idealną kalkulację ze wszystkimi kosztami.
To najbardziej przyziemna część pracy i jednocześnie ta, która najczęściej zatrzymuje wdrożenia na wiele miesięcy.
Najlepszym źródłem jest system magazynowy albo księgowy — tam koszt zakupu jest z definicji. Rzadko jest jednak dostępny w formie, którą da się codziennie wysyłać do systemów reklamowych. Trzeba więc uzgodnić z klientem sposób regularnego eksportu, choćby raz na dobę, do pliku z identyfikatorem produktu i kwotą kosztu.
Jeśli takiego eksportu nie da się zrobić od razu, zaczynam od przybliżenia: przypisuję marżę na poziomie kategorii albo grupy produktów, w kilku progach. To wystarcza, żeby rozdzielić asortyment zarabiający od tego, który tylko generuje obrót, i żeby podjąć pierwsze decyzje. Uczciwie oznaczam wtedy w raporcie, że pracujemy na szacunku.
Osobno pilnuję aktualności. Marże zmieniają się przy każdej akcji promocyjnej i przy zmianie cen zakupu. Dane sprzed pół roku wprowadzają w błąd skuteczniej niż ich brak, bo są traktowane poważnie.
Są dwie drogi i wybór między nimi to najważniejsza decyzja w całym projekcie.
Droga pierwsza, ostrożniejsza: zysk liczę w warstwie raportowej. Do systemu reklamowego dalej trafia przychód, a marżę dokładam po stronie analityki — łącząc dane o zamówieniach z danymi o kosztach i patrząc na wynik per kampania czy grupa produktów. Zaleta: nic nie psuję w licytacji, a decyzje podejmuję świadomie. Wada: algorytm nadal optymalizuje pod obrót, więc muszę korygować go ręcznie, celami i podziałem asortymentu.
Droga druga, mocniejsza: jako wartość konwersji przekazuję marżę zamiast przychodu. Wtedy strategia licytacji sama zaczyna preferować zamówienia, które zarabiają. Zaleta jest oczywista, kosztów jest kilka. Raporty przestają pokazywać przychód, więc trzeba przyzwyczaić wszystkich w firmie, że liczby w panelu to zysk. Trzeba też dopilnować, żeby wartość nigdy nie schodziła do zera ani poniżej, bo zamówienia sprzedane ze stratą przestałyby dla systemu istnieć — a to również jest informacja, którą chcemy zachować.
Najczęściej wybieram wersję pośrednią: dwie akcje konwersji. Jedna, oparta na marży, jest podstawą optymalizacji. Druga, z przychodem, jest tylko obserwowana i służy do rozmowy z zarządem. Trzeba wtedy uważać, żeby do licytacji weszła dokładnie jedna z nich.
Bez tego elementu cała konstrukcja jest nieszczelna, szczególnie w odzieży, obuwiu i meblach.
Google Ads pozwala korygować wartość zarejestrowanej konwersji po fakcie — na podstawie identyfikatora transakcji można obniżyć wartość albo wycofać konwersję, gdy zamówienie zostało anulowane lub zwrócone. Wdrożenie wymaga po stronie sklepu przechowywania identyfikatorów i regularnego wysyłania korekt, ale technicznie nie jest skomplikowane.
Kluczowe są dwie rzeczy: konsekwencja i okno czasowe. Korekty trzeba wysyłać codziennie, w tym samym trybie, bo pojedyncza akcja porządkująca dane raz na kwartał tylko rozchwieje algorytm. Trzeba też sprawdzić, ile czasu upływa u nas między zamówieniem a zwrotem i czy mieści się to w limitach czasowych na przesłanie korekty.
Gdzie korekt zrobić nie można, tam wprowadzam współczynnik: obniżam przekazywaną wartość o typowy poziom zwrotów w danej kategorii. To rozwiązanie zgrubne, ale lepsze niż liczenie każdego zamówienia jako sprzedanego na pewno.
Po zmianie definicji wartości wszystkie dotychczasowe cele przestają mieć sens i to bywa zaskoczeniem.
Jeśli wcześniej celem był zwrot na poziomie kilkuset procent liczony od przychodu, to po przejściu na marżę odpowiednikiem będzie liczba znacznie niższa — bo licznik zmalał do wysokości marży. Nowy cel wyliczam z danych historycznych: biorę okres kilku tygodni, przeliczam dla niego zysk i sprawdzam, jaki poziom kampania faktycznie osiągała. Od tego zaczynam, nie od wartości życzeniowej.
Progi ustawiam osobno dla grup asortymentu o różnej charakterystyce, bo jeden cel dla całego sklepu z powrotem uśrednia to, co właśnie rozdzieliliśmy. I daję kampaniom kilka tygodni spokoju po zmianie, zanim ocenię wynik — zmiana definicji wartości jest dla systemu zdarzeniem porównywalnym z przebudową konta.
Warto też uprzedzić klienta, że część wskaźników pogorszy się na papierze. Liczba konwersji może spaść, koszt pozyskania zamówienia wzrosnąć. Jeśli równocześnie rośnie zysk, to jest dokładnie ten efekt, o który nam chodziło — ale bez uprzedzenia rozmowa o pierwszym miesiącu bywa nieprzyjemna.
Kilka rzeczy, które warto powiedzieć, zanim ktoś uzna to za rozwiązanie wszystkich problemów.
Nie naprawi jakości danych. Jeśli konwersje są liczone podwójnie albo część transakcji nie dochodzi do systemu, przeliczenie ich na zysk tylko zmieni jednostkę błędu. Porządek w pomiarze jest warunkiem wstępnym, nie elementem tego projektu.
Nie rozstrzygnie sporu o atrybucję. Zysk przypisany kampanii zależy dalej od modelu przypisania konwersji, a ten pozostaje przybliżeniem. Przy sprzedaży z wieloma punktami styku wynik jednej kampanii nadal warto czytać razem z wynikiem całości.
I nie zastąpi decyzji o asortymencie. Najczęstszym wnioskiem z takiego wdrożenia nie jest zmiana ustawień kampanii, a odkrycie, że część produktów nie powinna być w ogóle reklamowana przy obecnych cenach zakupu. To rozmowa dla właściciela i działu zakupów — ja mogę tylko pokazać liczby, na których da się ją oprzeć.
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 |