Tradycyjnie walka z oszustwami w produktach cyfrowych opierała się na ścisłych zasadach opartych na regułach lub ręcznej moderacji, co prowadziło do wysokiego obciążenia operacyjnego i statyczności systemu. Wraz z rozwojem uczenia maszynowego firmy zaczęły wdrażać Real-Time Fraud Detection SDK, które oceniają każdą transakcję pod kątem prawdopodobieństwa oszustwa. Kluczową trudnością jest to, że każdy klasyfikator popełnia błędy dwóch typów: Fałszywie Pozytywne (blokowanie legalnego użytkownika) bezpośrednio zmniejsza przychody, a Fałszywie Negatywne (przeoczenie oszustwa) zwiększa chargeback. Krytycznie ważne dla biznesu jest zmierzenie trade-off między tymi błędami w celu optymalizacji progów scoringu.
Standardowe A/B testowanie jest niemożliwe, ponieważ celowe przepuszczenie oszukańczych transakcji w grupie kontrolnej jest niedopuszczalne z punktu widzenia reputacji oraz wymagań FinCEN/PCI-DSS. Proste porównanie metryk przed i po wdrożeniu jest zniekształcone przez sezonowość ataków oszustów oraz samozbieranie użytkowników (aplikację aktualizują bardziej lojalni). Użytkownicy z wysokim ryzykiem oszustwa mają początkowo inną konwersję niż o niskim ryzyku, dlatego naiwne porównanie między zatwierdzonymi a odrzuconymi daje zniekształconą ocenę z powodu confounding by indication.
Optymalną metodą jest Sharp Regression Discontinuity Design (RDD) wokół wartości progowej fraud score (na przykład 0.7), gdzie następuje gwałtowna zmiana prawdopodobieństwa akceptacji z 1 do 0. Porównujemy transakcje z wynikiem 0.69 (traktowane jako zaakceptowane) i 0.71 (kontrolowane, odrzucone), zakładając lokalną losowość w oknie bandwidth (±0.05). Używamy Local Linear Regression z trójkątnym jądrem do oceny LATE (Local Average Treatment Effect). Aby zwiększyć dokładność, stosujemy Covariate-Adjusted RDD, dodając predyktory (historia urządzenia, geolokalizacja) jako zmienne kontrolne. Aby ocenić czysty przychód, obliczamy Incremental Revenue: różnicę między zapobieganym oszustwem (oczekiwany chargeback) a utraconym przychodem z false positives, zidentyfikowanymi za pomocą RDD.
W mobilnej aplikacji marketplace po integracji Fraud Detection SDK od zewnętrznego dostawcy ogólna konwersja w zakupie spadła z 4.2% do 3.5%, podczas gdy wskaźnik oszustw spadł z 2.8% do 0.4%. Zespół produktowy podejrzewał, że system jest zbyt agresywny i odrzuca legalnych płatnych użytkowników, ale nie mógł ilościowo ocenić zakresu problemu z powodu braku grupy kontrolnej.
Opcja A: Proste porównanie konwersji przed i po wdrożeniu (analiza pre-post). Zalety: minimalne nakłady pracy, nie wymaga specjalnej infrastruktury. Wady: całkowicie ignoruje sezonowość (okres po wdrożeniu zbiegł się z początkiem niskiego sezonu), samozbieranie przy aktualizacji aplikacji oraz zmiana mikstu marketingowego (uruchomiono nowy kanał z niską konwersją).
Opcja B: Podział geograficzny (miasta Grupa A z włączonym systemem, Grupa B bez). Zalety: tworzy czystą grupę kontrolną. Wady: technicznie niemożliwe z powodu jednolitej bazy kodowej i CDN caching; użytkownicy migrują między miastami; profil oszustw zasadniczo różni się w różnych regionach (horyzontalna niejednorodność).
Opcja C: Regression Discontinuity Design według ciągłego fraud score wokół progu odcięcia 0.65. Zalety: wykorzystuje naturalny eksperyment, gwarantuje lokalną losowość, pozwala na izolację efektu przyczynowego dokładnie dla "granicznych" transakcji. Wady: wymaga dużej ilości danych w oknie progu; ocenia LATE, który może różnić się od ATE dla całej populacji; wrażliwy na manipulacje scoringiem (oszuści mogą nauczyć się omijać próg).
Opcja D: Synthetic Control Method, stworzenie ważonej kombinacji historycznych kohort w celu imitacji grupy kontrolnej. Zalety: działa bez fizycznej grupy kontrolnej, uwzględnia trendy czasowe. Wady: zakłada, że czynniki wpływające są stabilne w czasie; wrażliwy na odstające wartości w przedobróbce; trudno to walidować poza testami placebo.
Wybrano Opcję C (RDD) z bandwidth 0.08 i wielomianem pierwszego stopnia. Analiza wykazała, że dla transakcji powyżej 15 000 ₽ wskaźnik fałszywych pozytywów jest dwukrotnie wyższy niż dla drobniejszych zakupów. Na podstawie tego dostosowano dynamiczne progi według kategorii produktów.
Wynik: Udało się ilościowo ocenić, że 0.6 punktu procentowego z 0.7 utraty konwersji pochodzi z fałszywych pozytywów. Po kalibracji progów odzyskano 45% utraconego przychodu (≈18 mln ₽ miesięcznie) przy zachowaniu 90% skuteczności przeciwdziałania oszustwom.
Jak odróżnić efekt przyczynowy od biasu selekcyjnego, gdy użytkownicy z wysokim fraud score mają początkowo niższą skłonność do zakupu, nawet gdyby systemy oszukańcze nie istniały?
Odpowiedź: To klasyczny problem confounding by indication, gdzie wskazanie do leczenia (wysokie ryzyko) koreluje z wynikiem. W RDD kluczowe jest sprawdzenie balance kowariatu (covariate balance) w oknie bandwidth: porównanie rozkładu wieku urządzeń, historii zakupów, geolokalizacji między grupami tuż poniżej i tuż powyżej progu. Jeśli występuje nierównowaga, należy zastosować bias-corrected RDD z uwzględnieniem kowariatu w regresji lub użyć podejścia Local Randomization, formalnie testując hipotezę o losowości rozkładu. Bez tej weryfikacji oszacowanie efektu będzie zmixowane z istnieniem różnic między użytkownikami wysokiego i niskiego ryzyka.
Dlaczego proste porównanie approve rate między użytkownikami, którzy przeszli przez różne wersje modelu (v1 i v2), nie pozwala poprawnie ocenić efektu poprawy algorytmu?
Odpowiedź: To porównanie cierpi na selection bias według unobservables oraz compositional drift. Nowy model v2 może być stosowany selektywnie (na przykład tylko dla nowych użytkowników lub w pilotażowych regionach), tworząc nieporównywalne grupy. Co więcej, poprawa jakości scoringu zmienia composition zaakceptowanych użytkowników: v2 może akceptować "szarą strefę", którą v1 odrzuciła, ale ci użytkownicy mają inną konwersję. Aby poprawnie ocenić, należy przeprowadzić Offline Policy Evaluation z Inverse Propensity Weighting (IPW) lub Doubly Robust Estimation na historycznych logach, oceniając counterfactual, jakie przychody przyniosłaby v1 na tych samych transakcjach, co v2.
Jak uwzględnić problem opóźnionej reakcji, gdy oszustwo potwierdzane jest po 30 dniach (chargeback), a analitycy potrzebują oceny efektu za 7 dni dla szybkich decyzji?
Odpowiedź: To stwarza problem cenzurowanych danych (censored data) oraz asymetrii w ocenie. Dla transakcji ostatnich 30 dni nie znamy prawdziwej etykiety (oszustwo/nie oszustwo). Rozwiązaniem jest zastosowanie Survival Analysis (model Cox proportional hazards) do oceny time-to-fraud, co pozwala pracować z niepełnymi danymi. Alternatywnie, można zastosować Surrogate Metrics (na przykład funkcje prędkości, zmiana odcisku urządzenia w trakcie sesji), korelujące z przyszłym oszustwem, jako proxy. Ważne jest zrozumienie, że false positives są widoczne od razu (natychmiastowe odrzucenie), a false negatives — z opóźnieniem, co zniekształca precision w kierunku zawyżania na krótkim horyzoncie. Dla RDD zaleca się używanie "zamrożonych" danych z lagiem w 30+ dni, akceptując utratę świeżości dla poprawności wniosku przyczynowego.