Kontekst historyczny
W latach 2010-2015 dominował model pełnej zgodności, w którym firmy wspierały aplikacje native dla iOS i Android, obejmując 95% rynku pod względem wersji systemów operacyjnych. Jednak wraz ze wzrostem złożoności funkcjonalności i przejściem na nowoczesne API (takie jak Biometric API, Camera2, Jetpack Compose) koszt wsparcia legacy-owego kodu przekroczył rentowność utrzymywanych użytkowników. W latach 2020-tych standardem stała się polityka "n-2", wymagająca opracowania metodologii oceny rzeczywistego efektu wyłączenia, a nie tylko analizy korelacyjnej metryk.
Zdefiniowanie problemu
Przymusowe wyłączenie tworzy endogenność samoselekcji: użytkownicy z przestarzałymi urządzeniami fizycznie nie mogą zaktualizować się do wymaganej wersji iOS lub Android, podczas gdy aktywna baza użytkowników z nowoczesnymi smartfonami aktualizuje się szybko. Obserwowana utrata MAU może być wynikiem rzeczywistego odpływu (churn), lub migracji do PWA (Progressive Web App) lub mobilnego webu. Klasyczne A/B-testowanie jest niemożliwe, ponieważ wyłączenie ma charakter techniczny i dotyczy wszystkich użytkowników danej wersji systemu operacyjnego jednocześnie, a śledzenie tożsamości między aplikacją natywną a wersją webową jest utrudnione przez ograniczenia Safari i Chrome w pracy z cookies.
Szczegółowe rozwiązanie
Optymalna metodologia opiera się na kombinacji broken regression (RDD) i synthetic control (Synthetic Control Method). Po pierwsze, stosuje się RDD z progiem wersji systemu operacyjnego (na przykład, próg dla Android 8.0 w porównaniu do Android 9.0), gdzie użytkownicy z wersjami nieco poniżej progu służą jako grupa kontrolna dla użytkowników nieco powyżej progu, z korektą na płynne cechy (model urządzenia, historyczna częstotliwość użytkowania).
Po drugie, do oceny migracji do kanału webowego buduje się syntetyczną kontrolę na podstawie danych historycznych DAU dla kohort użytkowników, porównywalnych pod kątem wzorców zachowań przed wyłączeniem. Tworzy się ważoną kombinację kohort, które nie były narażone na wpływ (na przykład, użytkowników z innych regionów o podobnej strukturze urządzeń), która modeluje kontrfaktualną trajektorię metryk.
Po trzecie, stosuje się difference-in-differences z Propensity Score Matching do dopasowania użytkowników, którzy mogli zaktualizować, ale tego nie zrobili, do tych, którzy zaktualizowali, z korektą na techniczne cechy urządzeń. Ważne jest śledzenie migracji cross-device przez Customer Data Platform (CDP), łącząc device_id aplikacji mobilnej z cookie_id wersji webowej przez wspólny user_id podczas autoryzacji. Dodatkowo stosuje się survival analysis (modele Coxa) do oceny czasu do odpływu w zależności od wersji systemu operacyjnego i dostępności alternatywy webowej.
Kontekst: Duży marketplace postanowił zrezygnować z wsparcia dla Android 7.0 i starszych (około 8% bazy) z powodu wdrożenia Biometric API dla bezpiecznych płatności. Budżet projektu zakładał utratę nie więcej niż 3% aktywnej bazy użytkowników z rekompensatą wynikającą ze wzrostu konwersji w nowych wersjach.
Opcja 1: Proste porównanie MAU przed i po wyłączeniu według dat z obliczeniem procentu utraty. Plusy: prostota obliczeń, szybkość uzyskania wyników, nie wymaga złożonej infrastruktury. Minusy: całkowicie ignoruje sezonowość, migrację do webu i samoselekcję według urządzeń; wysokie ryzyko fałszywie dodatnich wniosków o odpływie, kiedy użytkownicy po prostu przeszli na m.site.
Opcja 2: Budowa analizy kohort z dopasowaniem według urządzeń z Android 8.0 (którzy mogli pozostać, ale zaktualizowali) w porównaniu do Android 7.0 (którzy nie mogli zaktualizować). Plusy: uwzględnia ograniczenia techniczne, pozwala na izolację efektu niemożności aktualizacji od braku chęci. Minusy: trudność w uzyskaniu czystych danych z powodu fragmentacji producentów OEM (Samsung, Xiaomi), różnice w zachowaniach użytkowników różnych marek oraz geograficzna heterogeniczność.
Opcja 3: Holisticzne podejście z Synthetic Control na poziomie regionów geograficznych z wysokim udziałem starych urządzeń (porównanie regionu A, gdzie 30% na Android 7, z regionem B, gdzie takich jest 5%, przed i po wyłączeniu) z korektą na ogólne trendy rynkowe. Plusy: uwzględnia makroekonomiczne czynniki i sezonowość, pozwala ocenić ogólny efekt na biznes. Minusy: wymaga dużych prób i zakłada brak innych równoległych interwencji w regionach.
Wybrane rozwiązanie: Wdrożono Opcję 3 w połączeniu z kohortową analizą autoryzowanych użytkowników (w celu śledzenia migracji do webu przez SSO-loginy). Wybór ten był spowodowany koniecznością oddzielenia rzeczywistego odpływu od kanibalizacji ruchu webowego, co jest kluczowe dla oceny unit-economics (użytkownicy webowi mają o 15% mniejszy AOV).
Rezultat: Analiza wykazała, że tylko 40% "straconych" MAU rzeczywiście odeszło, 35% przeszło do PWA, a 25% zaktualizowało urządzenia w ciągu kwartału. Rzeczywisty negatywny efekt okazał się 2,5 razy mniejszy od prognozowanego, co pozwoliło kontynuować strategię aktualizacji API dla pozostałych 92% bazy użytkowników z wzrostem GMV o 8% dzięki nowym funkcjom płatności.
Jak odróżnić techniczną niemożność aktualizacji od behawioralnego odmowy aktualizacji, jeśli obie grupy pozostają na starych wersjach aplikacji?
Odpowiedź należy zbudować na analizie device_change events w CDP. Użytkownicy z behawioralnym odmowem (lazy updaters) często mają wzorzec "odłożonych aktualizacji" w historii (na przykład, pomijanie kilku wersji mniejszych, ale instalowanie krytycznych poprawek bezpieczeństwa), podczas gdy technicznie ograniczeni użytkownicy nigdy nie zmieniają OS version przez całe życie urządzenia. Dodatkowo analizuje się hardware fingerprint przez WebGL lub Canvas w wersji webowej: jeśli użytkownik pojawia się w PWA na tym samym urządzeniu (według User-Agent i rozdzielczości ekranu), co w aplikacji natywnej przed wyłączeniem, to potwierdza migrację, a nie odpływ. Ważne jest również segmentowanie według historii app_version: jeśli użytkownik regularnie aktualizował wewnątrz Android 7 (między poprawkami 7.0->7.1), ale nie przeszedł na 8.0, to wskazuje na limit techniczny, a nie brak chęci.
Dlaczego standardowe Propensity Score Matching może dawać zniekształcone oceny przy ocenie efektu przymusowej aktualizacji w warunkach silnej korelacji między dochodem użytkownika a modelem urządzenia?
Standardowy PSM opiera się na warunkowej niezależności, zakładając, że obserwowane zmienne towarzyszące w pełni wyjaśniają samoselekcję. Jednak w przypadku polityki sunset istnieje ukryta zmienna — disposable income, która koreluje zarówno z modelem smartfona (flagowiec w porównaniu do budżetowego) jak i z LTV użytkownika. Tanie urządzenia rzadziej otrzymują aktualizacje systemu operacyjnego, a ich właściciele mają niższą zdolność płatniczą. Standardowy PSM zaniży negatywny efekt, ponieważ "zważy" bogatych użytkowników z nowymi urządzeniami jako analogów biednych ze starymi, chociaż ich wzorce behawioralne różnią się fundamentalnie. Rozwiązaniem jest zastosowanie Coarsened Exact Matching (CEM) z dokładnym stratyfikowaniem według segmentów cenowych urządzeń (low-end, mid-range, flagship) przed zastosowaniem PSM, bądź zmiennych instrumentalnych (IV) z wykorzystaniem polityki aktualizacji producentów OEM jako egzogennego wstrząsu.
Jak prawidłowo uwzględnić efekty sieciowe między użytkownikami różnych wersji aplikacji przy ocenie odpływu, jeśli funkcjonalność "udzielania dostępu do produktu" działa inaczej w starej i nowej wersji?
Efekty sieciowe tworzą spillover między grupami treatment i control: jeśli aktywny użytkownik nowej wersji (treatment) nie może podzielić się treścią z przyjacielem korzystającym z starszej wersji (która nie obsługuje nowego formatu deep link), to pogarsza to doświadczenie obu i może przyspieszyć odpływ grupy kontrolnej nie z powodu polityki sunset, ale z powodu degradacji UX. Aby poprawnie dostosować, należy zastosować network-based DID (Difference-in-Differences z wagami sieciowymi). Konstrukcja grafu relacji społecznych (poprzez analizę referral codes, wspólnych zamówień lub wiadomości w czacie aplikacji). Ocena "zarażenia" (contagion) metryk: jeśli użytkownik w grupie kontrolnej (stara wersja) ma wiele powiązań z grupą treatment (nowa wersja), jego zachowanie będzie zniekształcone. Do modelu dodaje się interakcyjny człon Treatment x Network_Exposure, gdzie Network_Exposure to udział relacji w sieci, korzystających z nowej wersji. Przy wysokim poziomie efektów sieciowych, rzeczywisty efekt polityki sunset będzie zaniżony, ponieważ część "kontrolnych" użytkowników faktycznie podlegała pośredniemu wpływowi i wymaga korekty na intention-to-treat (ITT) z uwzględnieniem tej kontaminacji.