Historischer Kontext
Von 2010 bis 2015 dominierte der Ansatz der vollständigen Kompatibilität, bei dem Unternehmen native-Apps für iOS und Android unterstützten, die 95% des Marktes nach Betriebssystemversionen abdeckten. Mit dem Anstieg der Komplexität der Funktionen und dem Übergang zu modernen APIs (wie Biometric API, Camera2, Jetpack Compose) überstiegen die Kosten für die Unterstützung von Legacy-Code die Rentabilität der gehaltenen Nutzer. In den 2020er Jahren wurde die „n-2“-Politik zum Standard, die die Entwicklung von Methodologien zur Bewertung des tatsächlichen Effekts der Abschaltung erforderte, anstatt einfach eine korrelative Analyse der Metriken durchzuführen.
Problemstellung
Die erzwungene Abschaltung erzeugt Endogenität der Selbstselektion: Nutzer mit veralteten Geräten können physisch nicht auf die erforderliche Version von iOS oder Android aktualisieren, während die aktive Nutzerbasis mit modernen Smartphones schnell updatet. Der beobachtete Rückgang der MAU kann das Ergebnis tatsächlicher Abgänge (churn) oder Migrationen zu PWA (Progressive Web Apps) oder mobilem Web sein. Klassisches A/B-Testing ist nicht möglich, da die Abschaltung technischer Natur ist und gleichzeitig alle Nutzer einer bestimmten Betriebssystemversion betrifft, während die Verfolgbarkeit der Identität zwischen der nativen App und der Webversion aufgrund von Einschränkungen in Safari und Chrome bei der Arbeit mit Cookies erschwert wird.
Detaillierte Lösung
Die optimale Methodologie basiert auf einer Kombination aus Rissregression (RDD) und synthetischer Kontrolle (Synthetic Control Method). Zunächst wird RDD mit einem Schwellenwert nach Betriebssystemversion verwendet (z. B. Schnittstelle zwischen Android 8.0 und Android 9.0), wobei Nutzer mit Versionen knapp unter dem Schwellenwert als Kontrollgruppe für Nutzer knapp über dem Schwellenwert dienen, mit Anpassungen an sanfte Merkmale (Gerätemodell, historische Nutzungsfrequenz).
Zweitens wird zur Bewertung der Migration zum Webkanal eine synthetische Kontrolle auf der Grundlage historischer Daten zu den DAU nach Nutzerkohorten erstellt, die bis zur Abschaltung vergleichbar in ihrem Verhaltensmuster sind. Eine gewichtete Kombination von Kohorten, die keiner Intervention ausgesetzt waren (z. B. Nutzer aus anderen Regionen mit ähnlicher Geräteverteilung), wird erstellt, um den kontrafaktischen Verlauf der Metriken zu modellieren.
Drittens wird Difference-in-Differences mit Propensity Score Matching angewendet, um Nutzer zu vergleichen, die hätten aktualisieren können, es aber nicht getan haben, mit denen, die aktualisiert haben, unter Berücksichtigung der technischen Merkmale der Geräte. Es ist wichtig, die cross-device-Migration über die Customer Data Platform (CDP) zu verfolgen, indem device_id der mobilen App mit cookie_id der Webversion über eine einzige user_id bei der Authentifizierung verknüpft wird. Zusätzlich wird die Überlebensanalyse (Cox-Modelle) verwendet, um die Zeit bis zum Abgang in Abhängigkeit von der Betriebssystemversion und der Verfügbarkeit einer Webalternative zu bewerten.
Kontext: Ein großer Marktplatz hat beschlossen, die Unterstützung für Android 7.0 und darunter aufzugeben (etwa 8% der Nutzerbasis), um Biometric API für sichere Zahlungen einzuführen. Das Projektbudget sah einen Verlust von nicht mehr als 3% der aktiven Nutzer mit Kompensation durch Wachstum der Konversion in neuen Versionen vor.
Option 1: Einfacher Vergleich von MAU vor und nach der Abschaltung zu bestimmten Daten mit Berechnung des Verlustprozentsatzes. Vorteile: Einfachheit der Berechnung, Schnelligkeit der Ergebniserhebung, benötigt keine komplexe Infrastruktur. Nachteile: Ignoriert vollständig Saisonalität, Migration zum Web und Selbstselektion nach Geräten; hohes Risiko falscher positiver Schlussfolgerungen zum Abgang, wenn Nutzer lediglich auf m.site gewechselt haben.
Option 2: Durchführung einer Kohortenanalyse mit Matching nach Geräten mit Android 8.0 (die hätten bleiben können, es aber nicht getan haben) gegen Android 7.0 (die nicht updaten konnten). Vorteile: Berücksichtigt technische Einschränkungen, ermöglicht die Isolation des Effekts der Unmöglichkeit des Updates vom Unwillen dazu. Nachteile: Schwierigkeiten bei der Erlangung reiner Daten aufgrund der Fragmentierung durch OEM-Hersteller (Samsung, Xiaomi), Unterschiede im Verhalten der Nutzer verschiedener Marken und geographische Heterogenität.
Option 3: Ganzheitlicher Ansatz mit synthetischer Kontrolle auf Ebene geografischer Regionen mit einem hohen Anteil an alten Geräten (Vergleich von Region A, in der 30% Android 7 nutzen, mit Region B, wo es nur 5% sind, vor und nach der Abschaltung) mit Anpassungen an allgemeinen Markttrends. Vorteile: Berücksichtigt makroökonomische Faktoren und Saisonalität, ermöglicht die Bewertung des Gesamteffekts auf das Geschäft. Nachteile: Erfordert große Stichproben und setzt voraus, dass keine anderen gleichzeitigen Interventionen in den Regionen stattfinden.
Gewählte Lösung: Es wurde Option 3 in Kombination mit der Kohortenanalyse autorisierter Nutzer umgesetzt (zur Verfolgung der Migration ins Web über SSO-Logins). Die Wahl war aufgrund der Notwendigkeit verursacht, den tatsächlichen Abgang von der Kannibalisierung des Web-Traffics zu trennen, was für die Bewertung der Unit Economics entscheidend ist (Webnutzer haben einen um 15% niedrigeren AOV).
Ergebnis: Die Analyse zeigte, dass nur 40% der "verlorenen" MAU tatsächlich abgewandert waren, 35% in PWA migriert waren und 25% innerhalb eines Quartals ihre Geräte aktualisierten. Der tatsächliche negative Effekt stellte sich als 2,5 mal geringer heraus als prognostiziert, was es ermöglichte, die Strategie zur Aktualisierung der APIs für die verbleibenden 92% der Nutzer mit einem Anstieg von GMV um 8% durch neue Zahlungsfunktionen fortzusetzen.
Wie unterscheidet man die technische Unmöglichkeit des Updates vom verhaltensbedingten Unwillen, wenn beide Gruppen auf alten Versionen der App bleiben?
Die Antwort muss auf der Analyse von device_change events in der CDP basieren. Nutzer mit verhaltensbedingtem Unwillen (lazy updaters) haben oft ein Muster von "aufgeschobenen Updates" in der Historie (z. B. mehrere kleinere Versionen auslassen, aber kritische Sicherheitspatches installieren), während technisch eingeschränkte Nutzer niemals die OS-Version während des gesamten Lebenszyklus des Geräts ändern. Zusätzlich wird der hardware fingerprint über WebGL oder Canvas in der Webversion analysiert: Wenn ein Nutzer in PWA mit demselben Gerät (über User-Agent und Bildschirmauflösung) erscheint, wie in der nativen App vor der Abschaltung, bestätigt dies die Migration, nicht den Abgang. Es ist auch wichtig, nach der app_version-Historie zu segmentieren: Wenn ein Nutzer regelmäßig innerhalb von Android 7 aktualisiert hat (zwischen den Patches 7.0->7.1), aber nicht auf 8.0 gewechselt ist, deutet dies auf eine technische Begrenzung und nicht auf Unwillen hin.
Warum kann das Standard-Propensity Score Matching bei der Bewertung der Auswirkungen des erzwungenen Upgrades bei starker Korrelation zwischen dem Einkommen des Nutzers und dem Gerätemodell zu verzerrten Schätzungen führen?
Standard-PSM basiert auf bedingter Unabhängigkeit und geht davon aus, dass die beobachteten Kovariaten die Selbstselektion vollständig erklären. Im Falle der Sunset-Politik gibt es jedoch eine versteckte Variable — disposable income, die sowohl mit dem Gerätemodell (Flaggschiff gegen Budgetgerät) als auch mit dem LTV des Nutzers korreliert. Budgetgeräte erhalten häufiger keine OS-Updates, und deren Besitzer haben eine geringere Kaufkraft. Standard-PSM wird den negativen Effekt unterschätzen, da es "reiche" Nutzer mit neuen Geräten fälschlicherweise als equivalente "arme" mit alten Geräten gewichtet, obwohl sich deren Verhaltensmuster fundamental unterscheiden. Eine Lösung ist die Verwendung von Coarsened Exact Matching (CEM) mit präziser Stratifizierung nach Preissegmenten der Geräte (Low-End, Mid-Range, Flaggschiff) vor der Anwendung von PSM oder instrumentalen Variablen (IV) mit Verwendung der Update-Politik von OEM-Herstellern als exogenem Schock.
Wie berücksichtigt man korrekt Netzwerk-Effekte zwischen Nutzern verschiedener Versionsanwendungen bei der Bewertung des Abgangs, wenn die Funktion "Produkt teilen" in der alten und neuen Version unterschiedlich funktioniert?
Netzwerkeffekte erzeugen spillover zwischen den Treatment- und Kontrollgruppen: Wenn ein aktiver Nutzer der neuen Version (Treatment) keinen Inhalt mit einem Freund in der alten Version (die das neue Format deep link nicht unterstützt) teilen kann, beeinträchtigt dies die Erfahrung beider und kann den Abgang der Kontrollgruppe beschleunigen, nicht aufgrund der Sunset-Politik, sondern wegen einer Verschlechterung der UX. Um dies zu korrigieren, sollte network-based DID (Difference-in-Differences mit Netzwerkgewichtungen) angewendet werden. Ein Netzwerkgraph sozialer Verbindungen wird erstellt (durch Analyse von referral codes, gemeinsamen Bestellungen oder Nachrichten im Anwendungs-Chat). Das "Infizieren" (contagion) der Metriken wird bewertet: Wenn ein Nutzer in der Kontrollgruppe (alte Version) viele Verbindungen zur Treatment-Gruppe (neue Version) hat, wird sein Verhalten verzerrt. Ein Interaktionselement Treatment x Network_Exposure wird in das Modell aufgenommen, wobei Network_Exposure der Anteil der Verbindungen im Netzwerk ist, die die neue Version verwenden. Bei hohem Niveau der Netzwerkeffekte wird der tatsächliche Effekt der Sunset-Politik unterschätzt, da ein Teil der "Kontroll"-Nutzer faktisch indirekt betroffen ist, und eine Anpassung der Intention-to-treat (ITT) unter Berücksichtigung dieser Kontamination ist erforderlich.