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.
Koniec września to moment, w którym prowadzę z klientami e-commerce najważniejszą rozmowę w roku. Nie o kreacjach ani o rabatach, a o tym, czego nie zdążymy zrobić, jeśli zaczniemy w listopadzie.
Sezon wysoki ma tę nieprzyjemną właściwość, że wszystko, co w nim zawodzi, zawodzi jednocześnie i przy najwyższych kosztach kliknięcia w roku. Awaria pomiaru konwersji w marcu to strata tygodnia danych. Ta sama awaria w tygodniu Black Friday to strata, której nie da się nadrobić do końca roku.
Poniżej opisuję, co robię w październiku, co w pierwszej połowie listopada i czego staram się nie robić w ogóle w trakcie szczytu. Dodam też uwagę o tegorocznym kontekście, bo różni się on od poprzednich lat.
Kolejność wynika z tego, ile czasu potrzebuje każdy element, żeby zadziałać.
Ta lista wygląda na oczywistą, a jednak w większości kont, które przejmuję po sezonie, widać, że kreacje powstawały w listopadzie, a listy odbiorców wtedy zaczynały się budować.
Zaczynam zawsze od pomiaru, bo wszystkie decyzje w trakcie sezonu będą się na nim opierać.
Sprawdzam, czy konwersje zliczają się poprawnie, czy nie ma duplikatów i czy wartość transakcji przekazywana jest w sposób zgodny z rzeczywistością. Przy okazji weryfikuję, czy pomiar obsłuży sytuację, której w ciągu roku nie ma: zamówienia z kodem rabatowym. Jeśli wartość przekazywana do systemu nie uwzględnia rabatu, cały grudniowy ROAS będzie zawyżony i decyzje podjęte na tej podstawie będą złe.
Druga rzecz to okno konwersji i model atrybucji. W sezonie ścieżki zakupowe się skracają, ale robią się bardziej wielokanałowe — ludzie porównują, wracają, kupują z innego urządzenia. Warto wiedzieć, jakie ustawienia obowiązują, przed sezonem, a nie tłumaczyć rozbieżności w raportach w grudniu.
Trzecia, często pomijana: sprawdzam, czy strona i pomiar wytrzymają większy ruch. Wolna strona przy podwojonym ruchu to nie tylko utracone konwersje, ale też gorsza jakość danych, bo część zdarzeń nie zdąży się wysłać.
Koszt kliknięcia w listopadzie rośnie i to jest stała, którą trzeba założyć w planie. Nie ma sensu planować sezonu przy średnich stawkach z września.
Praktycznie oznacza to trzy decyzje. Pierwsza: budżet dzienny podnoszony wcześniej i stopniowo, nie skokowo w dniu Black Friday. Skokowe zmiany przy strategiach automatycznych wywołują ponowne uczenie w najgorszym możliwym momencie. Druga: przygotowana rezerwa budżetowa i ustalone z klientem, kto i na jakiej podstawie decyduje o jej uruchomieniu — w środku sezonu nie ma czasu na uzgodnienia. Trzecia: świadomość, że przy strategiach nastawionych na koszt konwersji podniesienie budżetu bez rozluźnienia celu niczego nie zmieni, bo ograniczeniem nie jest budżet, a cel.
Do zapowiedzianych krótkich okresów wyjątkowej konwersyjności służą korekty sezonowe. To narzędzie stworzone dokładnie do takich sytuacji: informujesz system, że w konkretnych dniach oczekujesz wyższego współczynnika konwersji, i on uwzględnia to w stawkach, nie czekając na zebranie danych. Ustawiam je na kilka dni przed wydarzeniem i tylko na krótkie okresy — do trwających tygodniami zmian to narzędzie nie jest przeznaczone.
Czego nie robię: nie zmieniam strategii ustalania stawek w listopadzie. Przejście z ręcznych stawek na automat wymaga okresu uczenia i sezon szczytowy jest najgorszym momentem, żeby go zaczynać. Jeśli zmiana jest potrzebna, robię ją najpóźniej w połowie października.
W sklepie internetowym kampanie produktowe zwykle odpowiadają za większość sprzedaży z reklam, a ich skuteczność zależy od pliku danych bardziej niż od czegokolwiek w panelu.
Sprawdzam trzy rzeczy. Dostępność — czy stany magazynowe aktualizują się wystarczająco często. W sezonie produkt schodzi w godzinach, a reklama towaru niedostępnego to kliknięcie kupione za najwyższą stawkę w roku i wyrzucone. Ceny — czy rabaty przenoszą się do pliku w polu przeznaczonym na cenę promocyjną, a nie przez podmianę ceny podstawowej. Odrzucenia — lista problemów w Merchant Center powinna być pusta na początku listopada, bo w trakcie sezonu proces ponownego zatwierdzania potrafi potrwać.
Warto też zawczasu przygotować to, co się w sezonie przydaje: własne etykiety pozwalające wydzielić produkty promocyjne i marżowe, żeby dało się nimi zarządzać osobno. Etykieta dodana w listopadzie wymaga ponownego przetworzenia pliku, a to znowu czas.
Osobno wspomnę o czymś, co tej jesieni ma znaczenie większe niż zwykle: dostępność towaru z importu. Problemy z łańcuchami dostaw są tematem, o którym mówi w tym roku każdy handlowiec, i warto uwzględnić w planie scenariusz, w którym część asortymentu po prostu nie dojedzie. Kampania reklamująca produkt, którego nie będzie w magazynie, to najdroższy możliwy błąd w tym okresie.
Teksty przygotowuję z wyprzedzeniem i wgrywam wcześniej, ale z terminami wyświetlania, żeby nie trzeba było ich włączać ręcznie o świcie.
Praktyczne uwagi z poprzednich sezonów:
Strona docelowa promocji musi istnieć i działać przed startem kampanii. Kierowanie ruchu z reklamy o rabacie na stronę główną, na której o rabacie nie ma słowa, to najczęstszy błąd sezonu i widzę go co roku.
Tydzień Black Friday nie jest czasem na eksperymenty i to jest jedna z niewielu zasad, których trzymam się bez wyjątków.
Nie wprowadzam zmian w strukturze kampanii. Nie dodaję nowych typów kampanii. Nie zmieniam celów strategii automatycznych z dnia na dzień. Nie wprowadzam zmian w pomiarze konwersji. Każda z tych rzeczy oznacza okres, w którym system się przestawia, a w szczycie nie ma na to marginesu.
Co natomiast robię codziennie: sprawdzam trzy liczby — wydatek względem planu, stan zatwierdzenia reklam i produktów oraz dostępność najlepiej sprzedających się pozycji. To pięć minut i wyłapuje niemal wszystko, co może pójść nie tak.
I ostatnia rzecz, o której łatwo zapomnieć w euforii dobrego grudnia: ustal z góry, co i kiedy wyłączasz po sezonie. Korekty sezonowe, podniesione budżety, kampanie promocyjne. Konta, na których wszystko to zostało włączone do lutego, to nie hipoteza — to najczęstszy stan, w jakim przejmuję konta na początku 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 |