Po co w ogóle prognozować popyt

Zanim ktokolwiek uruchomi jakikolwiek model, warto odpowiedzieć na pytanie, jaka decyzja zależy od wyniku. Bez tego dostaniemy ładny wykres, którego nikt nie użyje.

W praktyce sprowadza się to do czterech zastosowań. Pierwsze to rozkład budżetu reklamowego w czasie — kiedy zwiększyć wydatek, a kiedy nie ma sensu przepłacać za aukcje przy niskim popycie. Drugie to harmonogram pracy nad treścią: jeśli wiem, że szczyt zapytań o kategorię przypada w maju, to strona kategorii musi być gotowa i zindeksowana w lutym, nie w kwietniu. Trzecie to planowanie asortymentu i stanów, jeśli ktoś w firmie w ogóle chce słuchać marketingu w tej sprawie. Czwarte to ocena, czy spadek ruchu w danym miesiącu to nasz problem, czy zwykły spadek popytu na rynku.

To ostatnie zastosowanie uważam za najbardziej niedocenione. Połowa nerwowych rozmów o spadkach w wyszukiwarce wygląda inaczej, gdy obok wykresu naszego ruchu położymy wykres popytu na frazy z naszej kategorii.

Jakie dane w ogóle mamy

To jest moment, w którym najczęściej wychodzi, że zadanie jest trudniejsze, niż wyglądało.

• Planer słów kluczowych — daje średnie miesięczne liczby wyszukiwań z ostatnich lat. Problem w tym, że liczby są zaokrąglane do przedziałów, a bliskie warianty pisowni bywają grupowane. To dane wystarczające do porównywania rzędów wielkości, ale kiepskie jako szereg czasowy do modelowania.

• Google Trends — pokazuje względną popularność w skali od zera do stu, nie bezwzględne liczby. Nadaje się do wychwycenia kształtu sezonu i porównania kilku fraz między sobą, nie do prognozy wolumenu.

• Search Console — jedyne źródło, które podaje faktyczne wyświetlenia dla naszych stron, z historią do szesnastu miesięcy. Zaleta: prawdziwe dane. Wada: mierzy popyt tylko tam, gdzie jesteśmy widoczni, i część zapytań jest pomijana ze względu na prywatność.

• Raport wyszukiwanych haseł z Google Ads — pokazuje rzeczywiste zapytania, ale przefiltrowane przez to, na co licytowaliśmy i ile mieliśmy budżetu.

Wniosek jest taki, że nie mamy jednego czystego szeregu czasowego popytu. Mamy cztery częściowe obrazy, każdy zniekształcony inaczej. Dobra prognoza zaczyna się od świadomej decyzji, który z nich jest miarą, i od pilnowania, żeby nie sklejać ich w jeden wykres.

Co właściwie prognozujemy

Drugie pytanie, które trzeba zadać przed modelem: prognozujemy popyt rynkowy czy nasze wyświetlenia?

To dwie różne rzeczy i mieszanie ich jest najczęstszym błędem w takich projektach. Nasze wyświetlenia zależą od pozycji, od tego, czy nie wypadliśmy z indeksu i czy nie skończył się budżet. Jeśli wytrenuję model na własnych wyświetleniach, to nauczy się on nie tylko sezonowości rynku, ale też historii moich wdrożeń, awarii i decyzji budżetowych — a potem będzie je przewidywał w przyszłość jako prawidłowość.

Dlatego rozdzielam warstwy. Popyt rynkowy modeluję na danych, które nie zależą ode mnie, i traktuję jako czynnik zewnętrzny. Osobno modeluję swój udział w tym popycie, czyli to, jaką jego część potrafię przechwycić. Prognoza ruchu jest wtedy iloczynem obu, a nie jedną liczbą z jednego modelu — i, co ważniejsze, gdy się nie zgodzi, wiem, która część zawiodła.

Analogicznie w reklamie: liczba dostępnych aukcji to jedno, a mój udział w wyświetleniach to drugie. Sklejenie tego w jedną prognozę kliknięć zwykle prowadzi do wniosku, że model „nie działa”.

Modele, które realnie się stosuje

Teraz część, która wszystkich najbardziej interesuje, choć jak napisałem — jest najmniej istotna.

• Baza odniesienia sezonowa — wartość z tego samego miesiąca rok wcześniej, przemnożona przez trend roczny. Prymitywne i zaskakująco trudne do pobicia. Każdy poważniejszy model musi udowodnić, że jest lepszy od tego, inaczej nie ma po co go utrzymywać.

• Dekompozycja szeregu — rozbicie danych na trend, sezonowość i resztę. Formalnie nie jest to prognoza, ale w praktyce najbardziej użyteczne narzędzie, bo pokazuje, ile z wahań to powtarzalny wzorzec, a ile szum.

• Modele klasy ARIMA i wygładzanie wykładnicze — sprawdzone podejście do szeregów z sezonowością. Dostępne w bibliotekach statystycznych, a od pewnego czasu również bezpośrednio w BigQuery, gdzie prognozę robi się zapytaniem, bez wychodzenia do Pythona.

• Prophet — biblioteka nastawiona właśnie na dane z wyraźną sezonowością i świętami. Wybaczająca braki w danych, dobrze radzi sobie z wieloma nakładającymi się cyklami, łatwa do uruchomienia bez wiedzy statystycznej. To bywa też jej wadą, bo zachęca do stosowania bez zrozumienia.

• Modele drzewiaste na cechach kalendarzowych — zamiast traktować dane jako szereg, opisujemy każdy tydzień zestawem cech: numer tygodnia, święto, długi weekend, temperatura, cena, aktywność konkurencji. Podejście silniejsze, gdy popyt zależy od czynników zewnętrznych, ale wymagające przygotowania tych czynników również dla przyszłości.

W kampaniach reklamowych warto pamiętać, że Google udostępnia gotowy planer skuteczności, który prognozuje wyniki na podstawie danych konta. Nie zastępuje własnej analizy popytu, ale przy planowaniu budżetu na kwartał bywa szybszym punktem startu niż budowanie czegokolwiek samemu.

Jak sprawdzić, czy prognoza jest dobra

Ta sekcja odróżnia projekt analityczny od ładnego wykresu.

Model oceniam wyłącznie na danych, których nie widział. W szeregach czasowych oznacza to, że nie mogę losowo podzielić zbioru — muszę uczyć na przeszłości i sprawdzać na późniejszym okresie. Robię to kilka razy, przesuwając granicę, żeby zobaczyć, czy błąd jest stabilny, czy model po prostu trafił raz.

Błąd wyrażam jako średnie odchylenie od wartości rzeczywistej i zawsze porównuję z bazą odniesienia. Sama liczba nic nie znaczy — znaczenie ma to, czy model jest lepszy od naiwnej prognozy sezonowej i o ile.

Osobno patrzę na to, gdzie model się myli. Prognoza, która ma niewielki błąd przez jedenaście miesięcy i kompletnie rozjeżdża się w szczycie sezonu, jest do niczego, bo szczyt sezonu to jedyny moment, w którym potrzebowałem tej prognozy. Uśredniony wskaźnik to ukryje, wykres nie.

I rzecz najważniejsza dla rozmowy z klientem: podaję przedział, nie jedną liczbę. Prognoza bez informacji o niepewności zachęca do planowania z dokładnością, której te dane nie mają.

Gdzie takie projekty się psują

Pierwsza pułapka to zmiany w samych danych. Historia wyszukiwań to nie tylko historia rynku, ale też historia zmian po stronie Google — modyfikacje typów dopasowania, sposobu grupowania wariantów czy prezentacji wyników przecinają szereg czasowy w miejscu, w którym nic się na rynku nie stało. Model tego nie wie i potraktuje to jako trend.

Druga to jednorazowe zdarzenia. Ostatnie lata dostarczyły ich w nadmiarze: lockdowny, gwałtowne zmiany zachowań zakupowych, wzrost cen energii. Zostawienie takich okresów w danych treningowych bez oznaczenia oznacza, że model będzie ich oczekiwał ponownie.

Trzecia to kanibalizacja wewnątrz zbioru fraz. Popyt nie znika, tylko przenosi się na inne sformułowanie. Prognoza dla pojedynczej frazy potrafi więc pokazywać spadek przy zupełnie stabilnym popycie na kategorię — dlatego prognozuję grupy tematyczne, nie pojedyncze słowa.

Czwarta jest organizacyjna: prognoza, której nikt nie aktualizuje, po kwartale jest gorsza niż brak prognozy, bo ludzie wciąż się na nią powołują. Jeśli nie mamy jak jej odświeżać co miesiąc, lepiej zrobić prostszą.

Minimalny sensowny setup

Nie zaczynam od infrastruktury. Zaczynam od jednego arkusza i jednej kategorii produktowej.

Pobieram dane z Search Console przez interfejs programistyczny lub eksport, tak samo z Google Ads, dokładam kształt sezonu z Trendów i buduję najprostszą prognozę bazową. To wystarcza, żeby sprawdzić dwie rzeczy: czy w tych danych jest w ogóle powtarzalna sezonowość i czy ktokolwiek w firmie użyje wyniku do decyzji. Jeśli odpowiedź na którekolwiek z tych pytań brzmi „nie”, projekt się kończy i to jest dobry wynik — zaoszczędzone tygodnie.

Jeśli odpowiedź brzmi „tak”, dopiero wtedy przenoszę dane do hurtowni, dokładam model sezonowy, automatyzuję odświeżanie i podłączam wykres do raportu, który klient i tak otwiera. Sam raport buduję w Looker Studio — narzędziu, które do października nazywało się Data Studio.

Ostatnia uwaga, bardziej o postawie niż o technice. Uczenie maszynowe w tym zadaniu nie odpowiada na pytanie „ile będzie zapytań”. Odpowiada na pytanie „jak wyglądałby najbliższy rok, gdyby zachował się jak poprzednie”. Wartość tej odpowiedzi jest duża, ale całą różnicę robi to, czy ktoś pamięta, że takie założenie zostało zrobione.