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.
Pytanie o odbiorców prognozowanych pojawia się u mnie zwykle w tej samej formie: dlaczego w naszym Analytics ta opcja jest wyszarzona. Odpowiedź prawie zawsze leży w warunkach, które usługa musi spełnić, żeby model mógł się w ogóle wytrenować — i te warunki są ostrzejsze, niż większość osób przypuszcza.
Warto też uporządkować nazewnictwo, bo w rozmowach mieszają się dwie rzeczy. Metryki prognozowane to liczby wyliczane dla poszczególnych użytkowników. Odbiorcy prognozowani to segmenty zbudowane na tych liczbach. Bez pierwszych nie ma drugich.
Poniżej rozkładam to na części: co konkretnie przewiduje model, jakich zdarzeń potrzebuje, po czym poznać, że przestał być wiarygodny, i jak zbudować segment tak, żeby nie okazał się dziesięcioma osobami.
Analytics wylicza trzy wartości i każda ma inne okno czasowe, co bywa źródłem nieporozumień.
Prawdopodobieństwo zakupu to szansa, że użytkownik aktywny w ostatnim okresie dokona zakupu w ciągu najbliższych siedmiu dni. Model patrzy na aktywność z ostatnich dwudziestu ośmiu dni i przewiduje krótką przyszłość, nie kwartał.
Prawdopodobieństwo odejścia działa odwrotnie: to szansa, że użytkownik aktywny w ostatnim tygodniu nie wróci w kolejnym. Tu warto uważać na interpretację, bo „odejście” w rozumieniu Analytics nie oznacza rezygnacji z marki, tylko brak wizyty w konkretnym oknie.
Przewidywany przychód to oczekiwana suma zakupów w ciągu najbliższych dwudziestu ośmiu dni od użytkownika aktywnego w ostatnim okresie. Ta metryka jest najbardziej wrażliwa na jakość danych o wartości transakcji — jeśli przekazujesz kwoty brutto raz z dostawą, raz bez, prognoza to odziedziczy.
Dwie pierwsze metryki są klasyfikacją, trzecia regresją. W praktyce oznacza to, że przewidywanego przychodu nie da się rozsądnie użyć jako progu binarnego i lepiej pracować na nim percentylami.
Tutaj kryje się przyczyna większości wyszarzonych opcji w panelu.
Model potrzebuje odpowiedniej liczby przykładów po obu stronach: użytkowników powracających, którzy wykonali przewidywane działanie, i takich, którzy go nie wykonali. Google podaje jako minimum tysiąc jednych i tysiąc drugich w oknie dwudziestu ośmiu dni. To nie jest tysiąc użytkowników w usłudze — to tysiąc powracających użytkowników z konkretnym zachowaniem.
Do tego usługa musi wysyłać właściwe zdarzenia. Dla prognozy zakupu i przychodu potrzebne jest zdarzenie zakupu z poprawną wartością, wysyłane konsekwentnie. Jeśli sklep raportuje transakcje własnym zdarzeniem o nietypowej nazwie, model nie ma czego szukać.
Trzeci warunek jest najmniej intuicyjny: jakość modelu musi się utrzymać. Analytics ocenia, czy prognozy odpowiadają rzeczywistości, i jeśli ocena spada poniżej progu, metryki przestają być dostępne — nawet jeśli wcześniej działały. Zdarza się to po większych zmianach w sklepie albo po przebudowie pomiaru.
Warto na koniec zapamiętać, że przy sezonowych sklepach warunki bywają spełnione tylko w części roku. Widziałem usługi, w których prognozy działały od października do stycznia i znikały na wiosnę.
Kiedy klient przysyła mi zrzut z takim komunikatem, sprawdzam kolejno kilka rzeczy i zwykle wystarczają one do rozstrzygnięcia.
Najpierw patrzę na wolumen powracających użytkowników, a nie na cały ruch. Sklep z dużym ruchem z płatnych kampanii i niską powracalnością bardzo długo nie zbierze wymaganej próby.
Potem sprawdzam nazwę i kompletność zdarzenia zakupu — czy jest to standardowe zdarzenie e-commerce, czy jest wysyłane raz na transakcję i czy zawiera wartość. Podwójne wysyłanie przy odświeżeniu strony podziękowania psuje nie tylko raporty, ale i model.
Trzecia rzecz to filtry i zakres danych. Jeśli usługa jest nowa, po prostu nie ma dwudziestu ośmiu dni historii z wymaganą liczbą przypadków, i trzeba poczekać.
Czwarta, najmniej oczywista: prognozy dotyczą użytkowników, a identyfikacja użytkowników w warunkach europejskich jest niepełna. Przy niskim odsetku zgód liczba rozpoznanych, powracających osób spada poniżej progu, mimo że sprzedaż w sklepie idzie dobrze.
Kreator odbiorców podpowiada kilka gotowych segmentów i warto wiedzieć, co jest pod spodem, bo nazwy brzmią podobnie, a znaczą różne rzeczy.
Szablony są wygodne, ale mają jedną cechę, o której trzeba pamiętać: definiują progi za nas. Przy nietypowym rozkładzie danych bywa, że górny zakres to grupa zbyt mała, żeby cokolwiek z nią zrobić.
Dlatego przy poważniejszych wdrożeniach buduję odbiorców ręcznie, korzystając z metryk prognozowanych jako warunku.
Zaczynam od sprawdzenia, jak rozkłada się prawdopodobieństwo w mojej usłudze. Kreator pokazuje szacowaną liczebność przy wybranym progu i to jest jedyna sensowna podstawa decyzji — nie okrągła liczba przepisana z artykułu w internecie.
Potem dobieram próg tak, żeby segment miał sens operacyjny: był dostatecznie liczny, by kampania mogła się z niego uczyć, i dostatecznie zawężony, by różnił się od średniej. Przy dużych sklepach zwykle pracuję na górnych kilku procentach, przy mniejszych muszę zejść znacznie niżej.
Do warunku prognozy dokładam zwykle jeden warunek behawioralny — kategorię obejrzanych produktów albo wizytę w konkretnej sekcji. Nie dlatego, że model tego wymaga, ale dlatego, że dzięki temu wiem, jaki komunikat przygotować. Segment „wysoka szansa na zakup” bez kontekstu produktowego zostawia mnie z pytaniem, co takim ludziom właściwie pokazać.
Model może być technicznie sprawny i jednocześnie bezużyteczny w danym biznesie. Do sprawdzenia tego używam eksploracji.
Buduję prostą eksplorację, w której metryki prognozowane zestawiam z faktycznym zachowaniem w kolejnym okresie. Jeśli grupa z górnego zakresu prawdopodobieństwa nie kupuje wyraźnie częściej niż grupa środkowa, prognoza w tym koncie niczego nie porządkuje i nie warto na niej opierać kierowania.
Zwracam też uwagę na stabilność. Metryka, która w jednym tygodniu wskazuje setki użytkowników z wysokim prawdopodobieństwem, a w kolejnym kilkunastu, sygnalizuje albo problem z pomiarem, albo zbyt mały wolumen do treningu.
I rzecz banalna, o której często się zapomina: prognozy są liczone dla użytkowników aktywnych w ostatnim okresie. Nie znajdziesz w nich osób, które odwiedziły sklep pół roku temu, choćby zostawiły po sobie najlepsze możliwe sygnały.
Zbiorę na koniec rzeczy, które mówię klientom przed rozpoczęciem takiego projektu, żeby nie było rozczarowania.
Prognoza jest wyliczana na danych z tej jednej usługi i nie zna nic poza nią. Nie widzi rozmów telefonicznych, kontaktu z działem sprzedaży ani historii z systemu magazynowego. W biznesach, w których decyzja zapada poza stroną, jej wartość jest ograniczona.
Model jest przezroczysty tylko w wyniku, nie w uzasadnieniu. Nie dowiem się, dlaczego ktoś dostał wysokie prawdopodobieństwo, i nie mogę tego wykorzystać jako materiału do analizy zachowań. To narzędzie do segmentacji, nie do zrozumienia klienta.
Metryki mogą zniknąć. Przy zmianie sposobu mierzenia transakcji albo dużym spadku ruchu segmenty prognozowane potrafią przestać się zapełniać, a kampanie oparte wyłącznie na nich stracą kierowanie. Dlatego nigdy nie zostawiam konta reklamowego w sytuacji, w której jedyna działająca lista odbiorców jest listą prognozowaną.
Na koniec zdroworozsądkowo: to jest wyliczenie statystyczne na krótkim oknie, a nie wiedza o zamiarach konkretnej osoby. Traktuję je jako uporządkowanie kolejki, w której warto obsłużyć kogoś wcześniej, i nie oczekuję od tego więcej.
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 |