Contesto storico
Tra il 2010 e il 2015, il metodo dominante era quello della piena compatibilità, in cui le aziende supportavano applicazioni native per iOS e Android, coprendo il 95% del mercato in termini di versioni del sistema operativo. Tuttavia, con l'aumento della complessità delle funzionalità e il passaggio a API moderne (come Biometric API, Camera2, Jetpack Compose), il costo di supporto del legacy-code ha superato la marginalità degli utenti mantenuti. Negli anni 2020, la politica standard è diventata "n-2", richiedendo lo sviluppo di metodologie per valutare il vero effetto della disattivazione, piuttosto che semplicemente l'analisi correlazionale delle metriche.
Definizione del problema
La disattivazione forzata crea endogeneità di auto-selezione: gli utenti con dispositivi obsoleti non possono fisicamente aggiornarsi alla versione richiesta di iOS o Android, mentre il pubblico attivo con smartphone moderni si aggiorna rapidamente. Il calo osservato di MAU può essere il risultato di una vera fuoriuscita (churn) o di una migrazione a PWA (Progressive Web App) o al web mobile. Il classico A/B testing è impossibile, poiché la disattivazione ha un carattere tecnico e si applica a tutti gli utenti di una determinata versione del sistema operativo contemporaneamente, ed è difficile monitorare l'identità tra l'applicazione nativa e la versione web a causa delle restrizioni di Safari e Chrome nel gestire i cookies.
Soluzione dettagliata
La metodologia ottimale si basa su una combinazione di regressione discontinua (RDD) e metodo di controllo sintetico (Synthetic Control Method). In primo luogo, si utilizza RDD con una soglia basata sulla versione del sistema operativo (ad esempio, soglia su Android 8.0 contro Android 9.0), dove gli utenti con versioni appena al di sotto della soglia fungono da gruppo di controllo per gli utenti appena al di sopra della soglia, con aggiustamento per caratteristiche fluide (modello del dispositivo, frequenza storica di utilizzo).
In secondo luogo, per valutare la migrazione al canale web, si costruisce un controllo sintetico basato su dati storici di DAU per coorti di utenti comparabili per modelli comportamentali prima della disattivazione. Viene creata una combinazione ponderata di coorti non esposte (ad esempio, utenti di altre regioni con una struttura di dispositivi simile), che modella la traiettoria controfattuale delle metriche.
In terzo luogo, si applica difference-in-differences con Propensity Score Matching per confrontare gli utenti che potrebbero aggiornarsi, ma non lo hanno fatto, con quelli che si sono aggiornati, con aggiustamento per le caratteristiche tecniche dei dispositivi. È importante monitorare la migrazione cross-device attraverso una Customer Data Platform (CDP), collegando il device_id dell'app mobile con il cookie_id della versione web tramite un unico user_id durante l'autenticazione. Inoltre, si utilizza l'analisi della sopravvivenza (modelli di Cox) per valutare il tempo fino all'abbandono in base alla versione del sistema operativo e alla disponibilità di alternative web.
Contesto: Un grande marketplace ha deciso di smettere di supportare Android 7.0 e versioni inferiori (circa l'8% della base) per implementare le Biometric API per pagamenti sicuri. Il budget del progetto prevedeva una perdita di non più del 3% del pubblico attivo, compensata da un aumento della conversione nelle nuove versioni.
Opzione 1: Semplice confronto di MAU prima e dopo la disattivazione in base alle date, calcolando la percentuale di perdita. Pro: semplicità di calcolo, rapidità nell'ottenere risultati, non richiede infrastrutture complesse. Contro: ignora completamente la stagionalità, la migrazione al web e l'auto-selezione in base ai dispositivi; alto rischio di conclusioni falsamente positive sull'abbandono, quando gli utenti sono semplicemente passati a m.site.
Opzione 2: Costruzione di un'analisi di coorti con abbinamento in base ai dispositivi con Android 8.0 (che avrebbero potuto rimanere, ma si sono aggiornati) contro Android 7.0 (che non potevano aggiornarsi). Pro: considera i limiti tecnici, consente di isolare l'effetto dell'impossibilità di aggiornarsi da quello della riluttanza. Contro: complessità nella raccolta di dati puliti a causa della frammentazione dei produttori OEM (Samsung, Xiaomi), differenze nel comportamento degli utenti di diversi marchi e eterogeneità geografica.
Opzione 3: Approccio completo con Synthetic Control a livello di regioni geografiche con una quota elevata di dispositivi obsoleti (confronto tra la regione A, dove il 30% è su Android 7, e la regione B, dove sono solo il 5%, prima e dopo la disattivazione) con aggiustamento per le tendenze generali del mercato. Pro: considera i fattori macroeconomici e la stagionalità, consente di valutare l'effetto complessivo sul business. Contro: richiede campioni di grandi dimensioni e presuppone l'assenza di altre interazioni simultanee nelle regioni.
Soluzione scelta: È stata attuata l'Opzione 3 in combinazione con un'analisi di coorti degli utenti autenticati (per monitorare la migrazione al web attraverso login SSO). La scelta è stata motivata dalla necessità di separare il vero abbandono dalla cannibalizzazione del traffico web, fondamentale per valutare la unit-economics (gli utenti web hanno un AOV inferiore del 15%).
Risultato: L'analisi ha mostrato che solo il 40% dei "persi" MAU si è realmente allontanato, il 35% è migrato a PWA, mentre il 25% ha aggiornato i dispositivi entro un trimestre. L'effetto negativo reale è stato 2,5 volte inferiore alle previsioni, il che ha consentito di proseguire con la strategia di aggiornamento delle API per il restante 92% del pubblico con un aumento del GMV dell'8% grazie alle nuove funzionalità di pagamento.
Come distinguere tra l'impossibilità tecnica di aggiornarsi e il rifiuto comportamentale di aggiornarsi, se entrambi i gruppi rimangono su versioni obsolete dell'app?
La risposta deve essere costruita sull'analisi di device_change events in CDP. Gli utenti con rifiuto comportamentale (lazy updaters) presentano spesso un modello di "aggiornamenti posticipati" nella cronologia (ad esempio, saltare diverse versioni minori, ma installando patch critiche di sicurezza), mentre gli utenti con limiti tecnici non cambiano mai la versione del sistema operativo durante l'intero ciclo di vita del dispositivo. Viene inoltre analizzato il hardware fingerprint attraverso WebGL o Canvas nella versione web: se un utente appare in PWA con lo stesso dispositivo (basato su User-Agent e risoluzione dello schermo) utilizzato nell'app nativa prima della disattivazione, questo conferma la migrazione, e non l'abbandono. È anche importante segmentare in base alla cronologia di app_version: se un utente si è aggiornato regolarmente all'interno di Android 7 (tra patch 7.0->7.1), ma non è passato a 8.0, ciò indica un limite tecnico, piuttosto che una riluttanza.
Perché il standard Propensity Score Matching può dare stime distorte nel valutare l'effetto dell'upgrade forzato in condizioni di alta correlazione tra il reddito dell'utente e il modello del dispositivo?
Lo standard PSM si basa sull'indipendenza condizionale, presupponendo che le covariate osservate spieghino completamente l'auto-selezione. Tuttavia, nel caso della politica di sunset esiste una variabile nascosta: il disposable income, che è correlato sia al modello dello smartphone (flagship contro budget) sia al LTV dell'utente. I dispositivi economici ricevono meno frequentemente aggiornamenti del sistema operativo, e i loro proprietari tendono ad avere una capacità di spesa inferiore. Lo standard PSM sottovaluterà l'effetto negativo, poiché "peserà" gli utenti benestanti con nuovi dispositivi come equivalenti ai poveri con dispositivi obsoleti, sebbene i loro modelli comportamentali differiscano fondamentalmente. La soluzione è l'uso di Coarsened Exact Matching (CEM) con stratificazione precisa in base ai segmenti di prezzo dei dispositivi (low-end, mid-range, flagship) prima di applicare il PSM, o variabili strumentali (IV) utilizzando la politica degli aggiornamenti dei produttori OEM come shock esogeno.
Come considerare correttamente gli effetti di rete tra gli utenti di diverse versioni dell'app nell'analisi dell'abbandono, se la funzionalità "condividi prodotto" funziona in modo diverso nelle versioni vecchie e nuove?
Gli effetti di rete creano spillover tra i gruppi di trattamento e di controllo: se un utente attivo della nuova versione (trattamento) non può condividere contenuti con un amico sulla versione vecchia (che non supporta il nuovo formato di deep link), questo peggiora l'esperienza di entrambi e può accelerare l'abbandono del gruppo di controllo non a causa della politica di sunset, ma a causa di una degradazione dell'UX. Per la correzione è necessario applicare un network-based DID (Difference-in-Differences con pesi di rete). Viene costruito un grafo delle relazioni sociali (attraverso l'analisi di referral codes, ordini condivisi o messaggi nella chat dell'app). Si valuta il "contagio" (contagion) delle metriche: se un utente nel gruppo di controllo (vecchia versione) ha molti legami con il gruppo di trattamento (nuova versione), il suo comportamento sarà distorto. Si aggiunge un termine interattivo Treatment x Network_Exposure, dove Network_Exposure è la quota di legami nella rete che utilizzano la nuova versione. In presenza di elevati effetti di rete, l'effetto reale della politica di sunset sarà sottostimato, poiché parte degli utenti "di controllo" è stata effettivamente soggetta a un'influenza indiretta, e sarà necessaria una correzione sull'intention-to-treat (ITT) tenendo conto di questa contaminazione.