English
Deutsch
PolskiAlerty GA4 przy małych liczbach: próg, przedział i szum statystyczny
Spis treści
Alarm na zdarzenia koszyka ma zgłaszać, że w sklepie coś się zepsuło. Żeby mógł to zrobić, spadek musi być wyraźnie większy niż to, co liczby i tak robią same z siebie. Dopiero wtedy różnica jest istotna – na tyle duża, by nie była zwykłym przypadkiem. Miejsce, w którym przebiega ta granica, to próg alarmu.
Właśnie na tym zawodzi większość alarmów w spokojnych sklepach. Są z konieczności ustawione tak, że odzywają się dopiero przy spadku o połowę, więc przemilczają proces zakupowy zepsuty dla jednej trzeciej klientów. Przy małych liczbach jedna trzecia mieści się jeszcze w normalnym wahaniu.
W której z tych dwóch sytuacji jest dany sklep, nie jest kwestią uznania. Zależy to od jednej liczby: ile zdarzeń wpada w jeden przedział, czyli w okno czasowe, po którym alarm liczy.
Dlaczego małe liczby wahają się mocniej
Liczone rzeczy zawsze się wahają, nawet gdy nic się nie zmieniło. Dziesięć rzutów monetą rzadko daje dokładnie pięć orłów; siedem albo trzy zdarzają się bez przerwy. Tysiąc rzutów niemal zawsze ląduje blisko połowy. Wahanie zatem nie znika, po prostu waży coraz mniej wobec całości.
Dla alarmu rozstrzyga właśnie ta proporcja. Przy dwudziestu pięciu zdarzeniach typowe wahanie wynosi około pięciu, czyli jedną piątą całości. Przy dwóch i pół tysiącach zdarzeń wynosi około pięćdziesięciu: bezwzględnie dziesięć razy więcej, ale względnie już tylko jedną pięćdziesiątą. Duże liczby są spokojne, małe są niespokojne.
Stąd wynika, jak duży musi być spadek co najmniej, żeby był istotny i żeby alarm w ogóle odróżnił go od normalnego wahania.
| Zdarzenia na przedział | Spadek, który alarm zauważy najwcześniej |
|---|---|
| 50 | 76 % |
| 200 | 38 % |
| 800 | 19 % |
| 3200 | 10 % |
Prawa kolumna to cały ten artykuł. Mówi, jaka część ruchu musi zniknąć, zanim w ogóle cokolwiek się wydarzy, a przy pięćdziesięciu zdarzeniach na przedział są to trzy czwarte. Zepsuty przycisk koszyka dotykający jednej trzeciej klientów pozostaje tam niewidoczny. Liczby dotyczą zwykłego progu i prawdziwego ruchu, który waha się mocniej niż samo liczenie – o tym niżej.
Dlaczego niższy próg nie pomaga
Nasuwającą się odpowiedzią jest obniżenie progu, tak by alarm odzywał się już przy mniejszych spadkach. To rzeczywiście działa: wykrywalny spadek maleje o mniej więcej jedną trzecią. Tyle że jednocześnie liczba fałszywych alarmów rośnie siedemnastokrotnie.
Przy monitorowaniu co godzinę oznacza to mniej więcej co drugi dzień alarm, choć nic się nie wydarzyło. Alarm odzywający się bez powodu co drugi dzień zostaje wyciszony w ciągu dwóch tygodni. Potem sklep nie ma już monitoringu, a ma poczucie, że go ma – położenie gorsze niż to, od którego zaczął.
Próg jest wymianą między dwoma błędami: przeoczyć coś albo alarmować bez powodu. Dopóki liczby są małe, ta wymiana jest zła po obu stronach.
Dłuższy przedział zamiast niższego progu
Jest droga, która omija tę wymianę: zmieścić więcej zdarzeń w jednym przedziale, wydłużając ten przedział. Czterokrotnie więcej zdarzeń czyni alarm dwukrotnie czulszym, przy tym samym progu i tej samej częstości fałszywych alarmów na przedział.
| Przedział | Zdarzenia w nim | Najmniejszy widoczny spadek | Alarm przychodzi po |
|---|---|---|---|
| 5 min | 17 | 100 % | pięciu minutach |
| 15 min | 50 | 76 % | kwadransie |
| 1 h | 200 | 38 % | godzinie |
| 4 h | 800 | 19 % | czterech godzinach |
Liczby dotyczą sklepu z 4800 zdarzeniami dziennie, monitorowanego całą dobę. Wiersz pięciominutowy jest tym, który zwykle się ustawia, bo pięć minut brzmi jak szybka reakcja – i jest wierszem, który nie wykrywa niczego.
Ile kosztuje dłuższy przedział, stoi w ostatniej kolumnie i nigdzie indziej: tyle czasu awaria trwa niezauważona. Cztery godziny są dla procesu zakupowego za długie, a dla nocnej dostawy danych całkiem w porządku. Przedział należy więc do obserwowanego przedmiotu, a nie do ogólnego regulaminu.
Prawdziwy ruch waha się mocniej niż samo liczenie
Do tej pory mowa była wyłącznie o wahaniu samego liczenia. Prawdziwy ruch ma dodatkowo rytm dobowy, rytm tygodniowy i wyskoki wokół dni wypłat. Trzymany wobec jednej płaskiej średniej, wszystko to liczy się również jako wahanie: alarm bierze wtedy koniec dnia za awarię, a szczyt w porze obiadowej za poprawę.
Dlatego liczby w tabelach powyżej są gorsze, niż sugerowałoby samo liczenie. To nie sztuczka rachunkowa, lecz cena linii odniesienia, która nie wie, która jest godzina.
Linia odniesienia zbudowana z tej samej godziny tego samego dnia tygodnia z ostatnich tygodni usuwa rytm. Ta jedna zmiana daje czułości więcej niż jakiekolwiek dostrajanie progu – działa mniej więcej tak, jakby sklep miał czterokrotnie większy ruch.
Gdy liczby są po prostu za małe
Niektóre sklepy w żadnym użytecznie krótkim przedziale nie osiągają liczb trzycyfrowych i żadna statystyka tego nie zmieni. Rozwiązaniem jest tam przestać zliczać zdarzenia, a zamiast tego zestawić dwie liczby w stosunek.
Sesje i zdarzenia koszyka nocą spadają obie i w poniedziałek rosną obie. Ich stosunek nie robi ani jednego, ani drugiego; pozostaje spokojny, podczas gdy obie pojedyncze liczby wędrują. Próg na tym stosunku działa więc jeszcze przy wielkościach, przy których próg na samej liczbie jest beznadziejny. Zepsuty przycisk koszyka rusza stosunek natychmiast, ledwie dotykając liczby sesji.
Rachunek z tego artykułu nadal przy tym obowiązuje. Obowiązuje tylko dla wielkości, której rytm dobowy nie przykrył, zanim alarm w ogóle na nią spojrzał.
Pytania i odpowiedzi
Dlaczego dopiero czterokrotnie większa liczba zdarzeń czyni alarm dwukrotnie czulszym?
Ponieważ typowe wahanie zliczenia rośnie jak pierwiastek kwadratowy z liczby zdarzeń. Przy 25 zdarzeniach wynosi około pięciu, przy 100 około dziesięciu: bezwzględnie dwa razy więcej, ale w stosunku do całości o połowę mniej. Dlatego w tabeli najmniejszy wykrywalny spadek zmniejsza się o połowę przy każdym czterokrotnym wzroście, z 76 % przy 50 zdarzeniach do 38 % przy 200.
Czy całkowitą awarię da się wykryć szybciej niż częściową?
Tak, i sugeruje to już sama tabela: w wierszu pięciominutowym stoi 100 %, więc ten przedział wykrywa dokładnie jeden spadek, całkowity. Całkowita awaria stawia inne pytanie niż spadek o jedną trzecią: nie o to, czy przyszło mniej, lecz o to, czy w ogóle coś przyszło.
Przy samym liczeniu, czyli gdy zdarzenia napływają niezależnie od siebie, pusty przedział jest bardzo mało prawdopodobny, gdy tylko oczekuje się kilku zdarzeń. To, że przedział ze średnio 17 zdarzeniami przypadkiem nie zawiera żadnego, zdarza się mniej więcej cztery razy na sto milionów. Alarm na „zero zdarzeń w pięć minut” odzywa się więc w tym sklepie praktycznie tylko przy prawdziwej awarii.
Granicę wyznacza rytm dobowy. Jeśli nocą oczekuje się średnio tylko dwóch zdarzeń na pięć minut, już przy samym liczeniu mniej więcej co siódmy przedział jest pusty, a przy prawdziwym ruchu raczej częściej. Alarm zerowy potrzebuje więc tej samej linii odniesienia co każdy inny, czyli oczekiwanej liczby z tej samej godziny tego samego dnia tygodnia, i powinien odzywać się tylko tam, gdzie to oczekiwanie jest dostatecznie duże.
Czy próg na stosunku dwóch liczb też potrzebuje wystarczającej liczby zdarzeń?
Tak, tylko w innym miejscu. Stosunek zdarzeń koszyka do sesji usuwa rytm dobowy i tygodniowy, ale nie wahanie samego liczenia. To wahanie tkwi głównie w mniejszej z obu liczb: przy 50 zdarzeniach koszyka na 1000 sesji stosunek waha się mniej więcej tak mocno jak zliczenie 50 zdarzeń.
Dla mniejszej liczby nadal obowiązuje więc pierwsza tabela. Stosunek pomaga, bo pozwala wydłużyć przedział i patrzeć łącznie na noc i dzień, a rytm nie psuje przy tym rachunku; to, jaki spadek staje się widoczny, wyznacza jednak liczba zdarzeń koszyka w przedziale.
Czy godzinny alarm na danych GA4 naprawdę odzywa się po godzinie?
Tylko wtedy, gdy liczby z tej godziny są już dostępne. Ostatnia kolumna drugiej tabeli liczy przedział, a nie czas, po którym źródło danych zna go w całości. GA4 przetwarza zdarzenia z opóźnieniem; zanim liczby z danej godziny będą w raportach kompletne, mijają często godziny, a dzienny eksport do BigQuery pojawia się dopiero następnego dnia.
Do monitorowania co godzinę lepiej nadają się więc źródła dostępne szybko: raporty czasu rzeczywistego i zapytanie czasu rzeczywistego w Data API, obejmujące ostatnie 30 minut, eksport strumieniowy do BigQuery albo, w przypadku zakupów, tabela zamówień sklepu. Na czułość wybór ten nie wpływa, bo rachunek z artykułu obowiązuje dla każdego źródła; od źródła zależy tylko czas oczekiwania na alarm.
Kontrola w praktyce: baza dni tygodnia bez sprawdzanego dnia
Detektor anomalii GA4 porównuje teraz wybrany dzień raportowy z tym samym dniem tygodnia z ośmiu poprzednich tygodni. Czwartek jest porównywany z ośmioma czwartkami. Sprawdzany dzień nie wchodzi do średniej odniesienia ani odchylenia standardowego próby. Silny spadek nie obniża więc własnej bazy.
Narzędzie odczytuje sesje, wszystkich użytkowników, wyświetlenia stron/ekranów, kluczowe zdarzenia, liczbę zdarzeń, łączne przychody i współczynnik zaangażowania przez Data API tylko do odczytu. Domyślnie wybrany jest dzień sprzed czterech dni, aby uwzględnić czas przetwarzania. Ten odstęp nie potwierdza jednak kompletności danych. Nadal istotne są strefa raportowania usługi i metadane odpowiedzi.
- Wybór zakończonego dnia i kontrola ośmiu dat odniesienia pokazanych w wyniku.
- Jeżeli w odpowiedzi brakuje wymaganej daty, porównanie zostaje wstrzymane. Brak wiersza nie jest po cichu zastępowany zerem; jawnie raportowane zero pozostaje zerem.
- Ocena opisowego wyniku z względem wybranego progu. Dla stałej bazy pokazywany jest brak zmiany lub zmiana względem stałej wartości, bez dzielenia przez zero.
- Pobranie dziewięciu porównywanych dat jako CSV i zestawienie wskazań z wdrożeniami, kampaniami, świętami i innymi dowodami.
Osiem obserwacji to niewielka baza. Wskazania nie są skalibrowanymi testami istotności, a siedem równoczesnych kontroli metryk może dawać przypadkowe wyniki. Porównanie tych samych dni tygodnia nie usuwa trendów, akcji specjalnych, zmian zgód ani opóźnień przetwarzania. Brak wskazania nie dowodzi kompletności pomiaru, a wskazanie nie ustala przyczyny. To narzędzie do ręcznej analizy, nie usługa cyklicznych alarmów.
Źródła: dokumentacja Google runReport, definicje metryk i NIST o wykrywaniu obserwacji odstających i jego założeniach.
Powiązane artykuły
