Historische context
Tussen 2010 en 2015 domineerde de aanpak van volledige compatibiliteit, waarbij bedrijven native-applicaties voor iOS en Android ondersteunden, wat 95% van de markt qua besturingssysteemversies dekte. Echter, door de toenemende complexiteit van functionaliteiten en de overstap naar moderne API's (zoals Biometric API, Camera2, Jetpack Compose) overschreed de kosten van het ondersteunen van legacy-code de marge van de behouden gebruikers. Tegen de jaren 2020 werd het beleid "n-2" de norm, wat een ontwikkeling vereiste van methoden voor het evalueren van het werkelijke effect van uitschakeling, in plaats van alleen correlatieanalyse van metrics.
Probleemstelling
Gedwongen uitschakeling creëert endogeniteit van zelfselectie: gebruikers met verouderde apparaten kunnen fysiek niet upgraden naar de vereiste versie van iOS of Android, terwijl de actieve gebruikers met moderne smartphones snel upgraden. De waargenomen daling in MAU kan het resultaat zijn van werkelijke uittocht (churn), of migratie naar PWA (Progressive Web App) of mobiel web. Klassiek A/B-testen is niet mogelijk, omdat de uitschakeling technisch van aard is en gelijktijdig wordt toegepast op alle gebruikers van een specifieke versie van het besturingssysteem, en het volgen van de identiteit tussen de native applicatie en de webversie bemoeilijkt wordt door beperkingen in Safari en Chrome met betrekking tot cookies.
Gedetailleerde oplossing
De optimale methodologie is gebaseerd op een combinatie van regressie discontinuïteit (RDD) en synthetische controle (Synthetic Control Method). Ten eerste wordt RDD gebruikt met een drempel op de besturingssysteemversie (bijvoorbeeld de grens tussen Android 8.0 en Android 9.0), waarbij gebruikers met versies net onder de drempel dienen als controle groep voor gebruikers net boven de drempel, met correctie voor vloeiende kenmerken (apparaatmodel, historische gebruiksfrequentie).
Ten tweede, om de migratie naar het webkanaal te evalueren, wordt synthetische controle opgebouwd op basis van historische data van DAU per cohorten gebruikers, vergelijkbaar op gedragsprofielen vóór de uitschakeling. Een gewogen combinatie van cohorten die niet zijn blootgesteld wordt gecreëerd (bijvoorbeeld gebruikers uit andere regio's met een vergelijkbare apparatenstructuur), die de contrafactuale trajecten van metrics modelleert.
Ten derde wordt difference-in-differences toegepast met Propensity Score Matching voor de vergelijking van gebruikers die mogelijk hadden kunnen upgraden, maar dit niet deden, met degenen die wel zijn geüpgraded, met correctie op de technische kenmerken van de apparaten. Het is belangrijk om de cross-device migratie te volgen via een Customer Data Platform (CDP), en het device_id van de mobiele applicatie te koppelen aan het cookie_id van de webversie via een enkele user_id bij inloggen. Daarnaast wordt survival analysis (Cox-modellen) gebruikt om de tijd tot uittocht te evalueren afhankelijk van de besturingssysteemversie en de beschikbaarheid van webalternatieven.
Context: Een grote marktplaats besloot om de ondersteuning van Android 7.0 en lager (ongeveer 8% van de gebruikersbasis) stop te zetten ten behoeve van de implementatie van Biometric API voor veilige betalingen. Het projectbudget voorzag in verlies van niet meer dan 3% van de actieve gebruikers, met compensatie door groei in conversie in nieuwe versies.
Optie 1: Eenvoudige vergelijking van MAU voor en na de uitschakeling op data met percentageverliezen berekend. Voordelen: eenvoud van berekeningen, snelheid van resultaten, vereist geen complexe infrastructuur. Nadelen: negeert volledig seizoensgebondenheid, migratie naar web en zelfselectie op apparaten; hoog risico op valse positieve conclusies over uittocht, wanneer gebruikers simpelweg zijn overgestapt naar m.site.
Optie 2: Opbouwen van cohortanalyse met matching op apparaten met Android 8.0 (die hadden kunnen blijven, maar zijn geüpgraded) tegen Android 7.0 (die niet konden upgraden). Voordelen: houdt rekening met technische beperkingen, maakt isolatie van het effect van onmogelijkheid om te upgraden van de wenselijkheid mogelijk. Nadelen: complexiteit bij het verkrijgen van schone gegevens door fragmentatie van OEM-fabrikanten (Samsung, Xiaomi), verschillen in gedrag van gebruikers van verschillende merken en geografische heterogeniteit.
Optie 3: Een geïntegreerde aanpak met Synthetic Control op het niveau van geografische regio's met een hoge beschikbare dosis van oude apparaten (vergelijking van regio A, waar 30% op Android 7 zit, met regio B, waar dat 5% is, voor en na de uitschakeling) met correctie voor de algemene markttendensen. Voordelen: houdt rekening met macro-economische factoren en seizoensgebondenheid, maakt evaluatie van het totale effect op het bedrijf mogelijk. Nadelen: vereist grote steekproeven en gaat ervan uit dat er geen andere gelijktijdige interventies in de regio's zijn.
Gekozen oplossing: Optie 3 werd geïmplementeerd in combinatie met cohortanalyse van geauthentiseerde gebruikers (voor het volgen van migratie naar het web via SSO-inlogmethoden). De keuze werd bepaald door de noodzaak om werkelijke uittocht te scheiden van cannibalisering van webverkeer, wat cruciaal is voor het inschatten van unit-economics (webgebruikers hebben 15% lagere AOV).
Resultaat: De analyse toonde aan dat slechts 40% van de "verloren" MAU daadwerkelijk is vertrokken, 35% migreerde naar PWA, en 25% vernieuwde hun apparaten binnen een kwartaal. Het werkelijke negatieve effect bleek 2.5 keer kleiner te zijn dan voorspeld, wat het mogelijk maakte om de strategie voor het vernieuwen van API voor de resterende 92% van het publiek voort te zetten met een groei van GMV met 8% door nieuwe betalingsfunctionaliteiten.
Hoe onderscheid je technische onmogelijkheid om te upgraden van gedragsweigering om te upgraden, als beide groepen op oude versies van de applicatie blijven?
Het antwoord moet gebaseerd zijn op de analyse van device_change events in CDP. Gebruikers met gedragsweigering (lazy updaters) hebben vaak een patroon van "uitgestelde updates" in hun geschiedenis (bijvoorbeeld het overslaan van meerdere kleine versies, maar het installeren van kritieke beveiligingspatches), terwijl technisch beperkte gebruikers nooit de OS version in de gehele levenscyclus van het apparaat veranderen. Daarnaast wordt de hardware fingerprint geanalyseerd via WebGL of Canvas in de webversie: als een gebruiker in PWA verschijnt met hetzelfde apparaat (op basis van User-Agent en schermresolutie) als in de native applicatie voor de uitschakeling, bevestigt dat migratie in plaats van uittocht. Het is ook belangrijk om te segmenteren op app_version geschiedenis: als een gebruiker regelmatig is geüpgraded binnen Android 7 (tussen patches 7.0->7.1), maar niet is overgestapt naar 8.0, duidt dit op een technische limiet in plaats van onwil.
Waarom kan standaard Propensity Score Matching scheve schattingen geven bij het beoordelen van het effect van een gedwongen upgrade onder sterke correlatie tussen het inkomen van de gebruiker en het apparaatsmodel?
Standaard PSM is gebaseerd op conditionele onafhankelijkheid, waarbij wordt aangenomen dat de waargenomen covariaten zelfselectie volledig verklaren. Echter, in het geval van eindigen van de ondersteuning zijn er verborgen variabelen — disposable income, die tegelijkertijd correleert met het telefoontype (flagship versus budgetmodel) en de LTV van de gebruiker. Goedkope apparaten krijgen vaak geen OS-updates en hun eigenaren hebben een lagere betalingscapaciteit. Standaard PSM zal het negatieve effect onderschatten, aangezien het "rijke" gebruikers met nieuwe apparaten als gelijken met arme gebruikers met oude apparaten "weegt", terwijl hun gedragsprofielen fundamenteel verschillen. Een oplossing is het gebruik van Coarsened Exact Matching (CEM) met gestructureerde stratificatie op prijsklassen van apparaten (low-end, mid-range, flagship) vóór toepassing van PSM, of instrumentele variabelen (IV) met gebruik van updatebeleid van OEM-fabrikanten als exogene schok.
Hoe houd je netwerkeffecten tussen gebruikers van verschillende versies van de applicatie correct in rekening bij het beoordelen van uittocht, als de functionaliteit "deel een product" anders werkt in de oude en nieuwe versie?
Netwerkeffecten creëren spillover tussen treatment- en controle groepen: als een actieve gebruiker van de nieuwe versie (treatment) geen inhoud kan delen met een vriend op de oude versie (die het nieuwe formaat deep link niet ondersteunt), verslechtert dit de ervaring van beiden en kan het de uittocht van de controle groep versnellen, niet door de sunset-politiek, maar door degradatie van de UX. Voor aanpassing is het nodig om network-based DID (Difference-in-Differences met netwerksgewichten) toe te passen. Er wordt een grafiek van sociale connecties opgebouwd (door het analyseren van referral codes, gezamenlijke bestellingen of berichten in de chat van de applicatie). De "besmetting" (contagion) van metrics wordt beoordeeld: als een gebruiker in de controle groep (oude versie) veel connecties heeft met de treatment-groep (nieuwe versie), zal zijn gedrag vertekend zijn. De interactieterm Treatment x Network_Exposure wordt aan het model toegevoegd, waarbij Network_Exposure het aandeel connecties in het netwerk is die de nieuwe versie gebruiken. Bij een hoog niveau van netwerkeffecten zal het werkelijke effect van de sunset-politiek worden onderschat, aangezien een deel van de "controle" gebruikers feitelijk is blootgesteld aan indirecte invloed, en correctie op intention-to-treat (ITT) vereist is rekening houdend met deze contaminatie.