Skąd bierze się ten pomysł i kiedy ma sens

Nie każdy sklep tego potrzebuje. Jeżeli marża jest w miarę równa w całym asortymencie, wystarczy dobrze ustawiony docelowy zwrot z wydatków i cała ta konstrukcja jest przerostem formy.

Sens pojawia się przy trzech sytuacjach. Pierwsza: rozstrzał marż między kategoriami jest duży, więc identyczny zwrot z wydatków oznacza w jednej kategorii zysk, a w drugiej stratę. Druga: marża się zmienia — bo zmieniają się ceny zakupu, kursy walut albo rabaty od dostawców. Trzecia: część asortymentu ma promocje i wyprzedaże, przy których rentowność potrafi zjechać do zera w ciągu dnia.

Jest jeszcze czwarty przypadek, moim zdaniem najważniejszy: towar, którego po prostu nie ma. Reklamowanie produktu z terminem dostawy za sześć tygodni to nie problem marży, ale wydatek o ujemnym zwrocie, którego żaden algorytm licytacji sam nie wyłapie, jeśli strona nadal pokazuje przycisk zakupu.

Rozmowę z klientem zaczynam więc nie od integracji, a od pytania: pokaż mi marżę na poziomie kategorii za ostatni kwartał. Zwykle po tym jednym zestawieniu widać, czy jest o czym rozmawiać.

Co znaczy „czas rzeczywisty" w tej układance

Tu prostuję oczekiwania, bo słowo „real time” robi w takich projektach dużo złego.

Google Ads nie reaguje natychmiast na nic. Strategie automatyczne uczą się na historii, budżety działają w skali dnia, a zmiany wprowadzane w koncie potrzebują czasu, żeby ich efekt dał się odczytać. Dosyłanie danych o marży co minutę nie da nic poza obciążeniem interfejsu programistycznego.

Sensowna częstotliwość, którą stosuję, wygląda tak: dane o marży i dostępności raz na dobę, dane o stanach magazynowych częściej, decyzje o budżetach nie częściej niż raz na dzień. Wyjątkiem są sytuacje awaryjne — koniec towaru w kategorii, na którą leci połowa budżetu — i tam faktycznie chcę reakcji w ciągu godziny, ale realizowanej wyłączeniem kampanii albo wykluczeniem produktów, nie zmianą stawek.

Jeżeli klient upiera się przy pełnej synchronizacji ciągłej, pytam o koszt utrzymania takiej integracji. Zwykle po tej kalkulacji sami wybieramy dobę.

Co ERP musi oddać, żeby to działało

Lista jest krótsza, niż zwykle proponują działy IT, i warto ją zawęzić od początku, bo każde dodatkowe pole to kolejne miejsce na błąd.

• Identyfikator produktu zgodny z katalogiem — ten sam, który jedzie w pliku produktowym. Bez wspólnego klucza nie ma projektu, a najczęstsza porażka takich integracji to właśnie rozjechane identyfikatory po migracji sklepu.

• Marża jednostkowa lub procentowa — z jasną definicją, o czym niżej.

• Stan magazynowy i termin dostępności — nie samo „tak / nie”, ale liczba sztuk i realny czas realizacji.

• Flaga produktu wycofywanego — jeśli towar schodzi z oferty, nie chcę go rozreklamować tuż przed końcem.

• Znacznik czasu aktualizacji — żebym wiedział, czy dane są z dziś, czy z zeszłego tygodnia, gdy coś się zatnie.

Kluczowa jest definicja marży i to jest rozmowa z księgowością, nie z programistą. Marża pierwszego stopnia, po kosztach logistyki, po prognozowanych zwrotach — to trzy różne liczby i przy niektórych kategoriach różnią się dramatycznie. Wybieram jedną, zapisuję definicję i konsekwentnie jej trzymam, bo zmiana definicji w połowie projektu unieważnia wszystkie wcześniejsze wnioski.

Trzy poziomy sterowania

Dane z ERP można wykorzystać na trzech różnych poziomach i różnią się one nakładem pracy oraz odwracalnością.

Poziom pierwszy, najprostszy: etykiety w pliku produktowym. Marżę dzielę na trzy–pięć koszyków i wpisuję je do katalogu jako etykietę własną. Potem na tej etykiecie buduję podział kampanii produktowych, celuję innym zwrotem z wydatków w koszyku wysokomarżowym niż w niskomarżowym i wykluczam z reklam to, co jest nierentowne. Nic nie trzeba programować poza cyklicznym generowaniem pliku.

Poziom drugi: budżety i cele przypisane do grup asortymentu. Kampanie mają odrębne budżety według koszyków marży, a nie według kategorii sklepowych. To wymaga przemyślanej struktury konta, bo produkt może zmienić koszyk i wtedy zmienia kampanię — więc koszyków nie robię pięciu, tylko trzy.

Poziom trzeci: automatyczne przesunięcia budżetu na podstawie zestawienia marży z wydatkami, realizowane skryptem albo przez interfejs programistyczny. Tu jest największa obietnica i największe ryzyko, o czym w sekcji o bezpiecznikach.

W dziewięciu przypadkach na dziesięć zatrzymuję się na poziomie drugim i uważam to za dobrą decyzję. Poziom trzeci ma sens przy dużych, zmiennych asortymentach i przy kliencie, który utrzyma tę integrację przez lata.

Struktura konta, która to znosi

Sterowanie budżetem za marżą wymaga, żeby konto dało się w ogóle podzielić według rentowności — a większość kont, które przejmuję, jest podzielona według menu sklepu.

Przebudowę robię etapami i zaczynam od wydzielenia tego, co najbardziej boli: grupy produktów wyraźnie nierentownej i grupy wyraźnie najlepszej. Środek zostawiam w spokoju, bo tam różnice są w granicach szumu, a każda kampania wydzielona bez potrzeby to kolejny budżet do pilnowania i mniej danych na kampanię.

Przy kampaniach z celem sprzedażowym pamiętam o jednej rzeczy: dzielenie ich w nieskończoność rozdrabnia dane, na których uczy się licytacja. Trzy kampanie po sto konwersji miesięcznie zachowują się przewidywalnie, dziesięć po trzydzieści — nie.

Osobno trzymam kampanię brandową, bo mieszanie jej z kalkulacją marżową zawsze zaburza obraz: ruch brandowy jest tani, konwertuje najlepiej i sprawia, że każda grupa, w której siedzi, wygląda na rentowną.

Bezpieczniki, bez których tego nie włączam

Automat operujący na danych z innego systemu potrafi zrobić szkodę szybciej, niż ktokolwiek zauważy. Stąd lista warunków, od których nie odstępuję.

Pierwszy: limity zmian. Żadne automatyczne przesunięcie nie rusza budżetu więcej niż o ustalony procent na dobę i nie schodzi poniżej minimalnego progu, przy którym kampania jeszcze zbiera dane.

Drugi: kontrola świeżości danych. Jeśli plik z ERP nie przyszedł albo znacznik czasu jest starszy niż ustalone okno, automatyka nie działa i zostają ostatnie ręczne ustawienia. Wolę stary budżet niż decyzję na starych danych o marży.

Trzeci: kontrola zdrowego zakresu. Marża ujemna dla całej kategorii albo zerowa dla wszystkiego to niemal zawsze błąd eksportu, nie sytuacja rynkowa. Taki plik odrzucam i wysyłam powiadomienie.

Czwarty: dziennik zmian. Każda automatyczna operacja zapisana z datą, wartością przed i po. Bez tego po miesiącu nie odpowiesz na pytanie, dlaczego kampania ma inny budżet niż w planie.

Piąty: człowiek raz w tygodniu patrzy na całość. Automatyzacja tego nie zastępuje, tylko skraca czas potrzebny na przegląd.

Kiedy odradzam

Odradzam, gdy dane o marży w firmie nie są pewne. Jeśli księgowość nie potrafi podać jednej definicji, projekt zbuduje precyzyjny mechanizm na niepewnym fundamencie i pogorszy wyniki z pełnym przekonaniem, że je poprawia.

Odradzam też przy małych kontach. Przy kilkudziesięciu konwersjach miesięcznie podział asortymentu na koszyki marży pozbawi licytację danych, a zysk z lepszej alokacji będzie mniejszy niż strata z rozdrobnienia.

I ostatnie zastrzeżenie, które mówię klientom wprost: integracja z ERP nie naprawi nierentownego asortymentu. Pokaże go — i to jest jej największa wartość, zwykle większa niż samo przesuwanie budżetów. Zdarzało się, że po pierwszym zestawieniu marży z wydatkami rozmowa przestawała dotyczyć kampanii, a zaczynała cen i dostawców. Uważam to za dobry wynik projektu.