Aby przeanalizować wpływ biometrycznej płatności na konwersję, należy przeprowadzić test A/B z losowaniem na poziomie użytkownika. Kluczowe metryki: główna — konwersja w zakup (conversion rate), kontrolne — średni koszyk, głębokość lejka (initiate checkout → payment success), retencja w 7. dniu. Dodatkowo wymagana jest segmentacja według urządzeń (iOS/Android) oraz kohort nowych/powracających użytkowników w celu zidentyfikowania efektu nowości.
Minimalny projekt eksperymentu: podział 50/50, długość co najmniej 2 pełnych cykli biznesowych (14 dni), moc testu (power) ≥ 80% oraz poziom istotności (alpha) = 5%. Dodatkowo wykonywana jest analiza kohortowa z wykorzystaniem SQL do walidacji stabilności efektu w czasie oraz Pythona (SciPy, Pandas) do statystycznej weryfikacji hipotezy o równości proporcji.
Problem:
Startup fintech planował wprowadzenie płatności przez Apple Face ID w aplikacji iOS. Zespół produktowy zakładał wzrost konwersji o 15%, ale biznes obawiał się czasochłonności opracowania (2 sprinty). Zadaniem analityka było uzasadnienie lub obalenie zasadności funkcji, wykluczając alternatywne wyjaśnienia wzrostu metryk (sezonowość, działania marketingowe, aktualizacja iOS).
Rozważane rozwiązania:
Pierwsze rozwiązanie — analiza „przed i po” (pre-post analysis) poprzez porównanie konwersji w tygodniu przed i po wydaniu. Zalety: minimalne nakłady czasowe, nie wymaga izolacji użytkowników. Wady: niemożność oddzielenia efektu funkcji od czynników zewnętrznych (np. jednoczesne uruchomienie kampanii reklamowej), wysokie ryzyko fałszywie pozytywnych wniosków.
Drugie rozwiązanie — quasi-eksperyment z użyciem metody Difference-in-Differences (DiD). Planowano porównanie użytkowników iOS (gdzie pojawi się Face ID) z użytkownikami Android (grupa kontrolna), uwzględniając trendy przed wprowadzeniem. Zalety: nie wymaga technicznej realizacji podziału w aplikacji, działa na danych obserwacyjnych. Wady: krytyczne założenie o równoległych trendach między platformami często jest naruszane z powodu różnej publiczności iOS i Android, trudności w interpretacji w obecności confounderów.
Trzecie rozwiązanie (wybrane) — pełne testy A/B z użyciem flag funkcjonalnych (LaunchDarkly). 50% użytkowników iOS uzyskało dostęp do Face ID (grupa testowa), 50% — płatność według starego schematu (kontrola). Obliczenie wielkości próby przeprowadzone zostało w R z użyciem biblioteki pwr: przy podstawowej konwersji 8%, oczekiwanym MDE (Minimum Detectable Effect) 12%, power=0.8 i alpha=0.05 wymagano ≥ 12 000 użytkowników na grupę. Eksperyment trwał 3 tygodnie, aby obejmować różne dni tygodnia.
Wynik:
Konwersja w grupie testowej wzrosła o 11,3% (z 8,1% do 9,0%), p-value = 0.002 (dwustronny test z). Jednak analiza kohort pokazała, że efekt jest statystycznie istotny tylko dla nowych użytkowników (+18%), podczas gdy dla obecnych użytkowników nie zarejestrowano żadnych zmian. W rezultacie decyzję podjęto o wprowadzeniu funkcji dla 100% użytkowników, ale materiały marketingowe przekierowano na przyciąganie nowych użytkowników, co zwiększyło ROI projektu o 40% w porównaniu do pierwotnego modelu.
Jak odróżnić efekt nowości (novelty effect) od trwałej poprawy metryk?
Kandydaci często kończą testy A/B po osiągnięciu istotności statystycznej, nie sprawdzając trwałości efektu. Aby zidentyfikować efekt nowości, należy zbudować krzywe akumulacji metryki (cumulative metric curves) według dni i przeprowadzić analizę heterogeniczności: porównać efekt w pierwszych 3 dniach z efektem w ostatnim tygodniu. Użyj analizy kohortowej w SQL: podziel ruch według dnia przybycia do eksperymentu (cohort_date) i sprawdź, czy lift jest zachowany dla „starych” kohort. Jeśli efekt maleje z czasem, to klasyczny efekt nowości — użytkownicy początkowo testują funkcję z ciekawości, ale nie zmieniają długoterminowego zachowania.
Czym różni się istotność statystyczna (statistical significance) od istotności praktycznej (practical significance) w analizie produktów?
Przy dużych próbach nawet 0,5% wzrost konwersji może być statystycznie istotny (p < 0,05), ale bezsensowny dla biznesu, gdy koszt wsparcia funkcji przewyższa przychody z dodatkowych zakupów. Przed uruchomieniem eksperymentu należy określić MDE (Minimum Detectable Effect) — minimalny rozmiar efektu, który ma wartość biznesową. Oblicza się go jako (Oczekiwany Przychód na Konwersję × Dodatkowe Konwersje) — Koszt Funkcji. Jeśli faktyczny lift jest poniżej MDE, nawet przy p-value = 0,01 funkcji nie należy wprowadzać. Do obliczeń użyj Pythona (statsmodels.stats.power) lub kalkulatorów online Evan Millera.
Jak radzić sobie w sytuacji, gdy użytkownik widzi funkcję, ale nie może jej użyć (efekt sieciowy lub awaria techniczna w jednej z grup)?
To problem kontaminacji lub efektu spillover. Klasyczny przykład: w grupie testowej wprowadzono płatność kryptowalutą, ale dostawca usługi był niedostępny 30% czasu. Analiza „intencjonalnego leczenia” (intent-to-treat, ITT) ocenia efekt na wszystkich, którym pokazano przycisk, niezależnie od faktu użycia. Dla czystości oceny stosuj metodę CACE (Complier Average Causal Effect) lub instrumental variables (zmienne instrumentalne), gdzie „przydział do grupy” służy jako narzędzie do faktycznego użycia funkcji. W SQL realizuje się to poprzez regresję dwuetapową lub poprzez JOIN z dziennikami rzeczywistych operacji, wykluczając użytkowników z błędami serwera z analizy efektywności, ale zachowując ich w pierwotnym losowaniu w celu weryfikacji równowagi grup.