Cosa succede a un link di un’app aperto dentro Instagram e TikTok: 74,000 reindirizzamenti misurati

Questi numeri vengono dai log di reindirizzamento di un servizio di smart link: un unico URL che manda un telefono sull’App Store o su Google Play. Ogni volta che un link viene aperto dentro un’app social, serviamo una piccola pagina che passa il visitatore allo store, e quella pagina riporta cosa è successo dopo. Ecco cosa dicono quei resoconti, come li abbiamo misurati e dove si ferma la misura.

I dati

Due cose saltano all’occhio prima di qualsiasi analisi. Le app di Meta mandano molto più traffico di TikTok. E su Android oltre tre quarti di tutti gli arrivi passano da un browser in-app, non da Chrome.

Come la pagina riporta cosa è successo

Quando un link viene aperto in un browser in-app, la pagina fa tre cose e invia un beacon per ciascuna:

• auto: avvia il passaggio allo store al caricamento (iOS: location.replace verso l’URL dell’App Store; Android: un URL intent:// che apre l’app nativa del Play Store).
• exit: la pagina diventa nascosta (Page Visibility API). È il segnale migliore che una pagina web abbia del fatto che qualcosa, molto probabilmente lo store, ha preso lo schermo.
• stuck: la pagina è ancora visibile 2.2 secondi dopo il passaggio allo store, quindi mostra una scheda di riserva con un pulsante per lo store, l’indicazione «apri nel tuo browser» e un pulsante per copiare il link.

Una pagina web non può vedere l’App Store né il Play Store. Tutto quello che segue è dedotto da questi tre segnali, e la sezione sui limiti dice dove questa deduzione non regge più.

Risultato 1: circa 1 arrivo Meta su Android su 11 è un precaricamento che nessuno ha visto

Nei 30 giorni fino al 12 ottobre, un gruppo netto di sessioni Android si è comportato come nessuna visita umana potrebbe: la pagina si è caricata, il timer del passaggio allo store non è mai partito e la pagina è stata distrutta da 29 a 31 secondi dopo. Nessun auto, nessuno stuck, nessun tocco. Su iOS niente di simile.

È la firma del browser in-app di Instagram e Facebook che precarica un link presente in un feed, lo tiene nascosto e lo butta via quando l’utente continua a scorrere. La pagina ha eseguito il nostro JavaScript, quindi l’arrivo è stato registrato. Nessuno l’ha mai guardata.

Abbiamo verificato il criterio su sessioni chiaramente umane: 0 su 17,606 sessioni in cui lo store si è aperto 2–3 s dopo il passaggio vi corrispondevano, e 0 su 244 sessioni in cui qualcuno ha toccato il pulsante dello store.

La quota cambia di settimana in settimana: 6.8% nell’ultima settimana di quel periodo, poi 8.8%, 10.6% e 10.0% nelle settimane precedenti. Si concentra inoltre dove girano campagne Instagram a pagamento: il 72% dei precaricamenti del periodo veniva da un solo link dietro una grande campagna Instagram.

Dal 16 ottobre la pagina lo classifica da sola a runtime: segnala un precaricamento invece di un’uscita quando muore dopo almeno 20 s senza essere mai stata mostrata. Ecco cosa ha rilevato da allora:

Quel conteggio a runtime è un minimo. Un precaricamento che muore senza eseguire alcuno script non lascia beacon, e la regola a runtime è più severa della ricostruzione storica.

Perché conta. Se conti i clic al tuo reindirizzamento, circa un «clic» Instagram Android su 13 non è mai stato visto da una persona. Il tuo rapporto clic/installazioni per quel canale sembra peggiore di quanto sia, e una dashboard di campagna costruita sugli hit grezzi del reindirizzamento sovrastima la copertura più o meno di altrettanto.

Risultato 2: TikTok rifiuta il Play Store a seconda della webview che usa

Dentro TikTok su Android, una parte dei visitatori non lascia mai la pagina: il passaggio allo store parte e TikTok mostra una propria finestra di dialogo («The action cannot be completed»). Non succede su tutti i link, e per settimane è sembrato che dipendesse dal link. Non è così. Dipende dal browser in-app che TikTok usa per quel visitatore, e il suo user-agent lo rivela:

Una sessione conta come riuscita quando il passaggio è partito e la pagina è diventata nascosta, e come fallita quando è comparsa la scheda di riserva. Il tasso è riuscite / (riuscite + fallite), per dispositivo e giorno:

Il confronto decisivo tiene costanti link e giorno, perché il mix dei formati cambia di settimana in settimana:

Stesso link, stesso codice di reindirizzamento, stesso giorno: una webview lascia aprire lo store, l’altra quasi mai. I domini personalizzati non hanno fatto alcuna differenza nei dati a 90 giorni. TikTok non documenta né la finestra di dialogo, né cosa la provoca, né quali utenti ricevono quale webview: la suddivisione per user-agent è tutto ciò che c’è.

Perché conta. Nessuna forma di URL risolve il problema: l’uscita con intent:// e un semplice URL https://play.google.com ricevono lo stesso rifiuto. Quello che puoi fare è non nascondere la via d’uscita: dentro TikTok mostra subito le istruzioni «apri nel browser» e un pulsante per copiare, invece che dopo un timeout.

Risultato 3: su iOS l’App Store si apre sopra il browser in-app

Su Android, dopo il passaggio allo store, la pagina diventa nascosta nella maggior parte delle sessioni, di solito da 1 a 3 secondi dopo. Su iOS dentro Instagram e Facebook spesso no, anche se il passaggio è partito in quasi tutte le sessioni:

Se due terzi dei visitatori iOS fossero davvero bloccati davanti a una scheda di riserva visibile con un pulsante «Apri l’App Store», molti lo toccherebbero. Non lo fanno: solo lo 0.9% dei caricamenti di pagina Instagram su iOS e lo 0.4% di quelli Facebook su iOS tocca il pulsante. E non esiste una versione di iOS in cui «funzioni»:

La spiegazione che torna è che dentro Instagram e Facebook su iOS l’App Store compare sopra il browser in-app senza mandarlo in background. La pagina resta «visibile» per tutto il tempo, quindi visibilitychange e pagehide non scattano mai, anche se il visitatore sta guardando l’App Store.

Perché conta. Qualsiasi metrica che deduce l’apertura dello store dal fatto che la pagina esce dallo schermo è sbagliata su iOS. Mostravamo ai clienti una percentuale di «copertura store» costruita esattamente così, e diceva a 10 clienti paganti su 12 che link funzionanti erano rotti. L’abbiamo tolta. Su iOS il segnale di installazione affidabile sta dal lato dello store: i report delle campagne di App Store Connect, con un provider token (pt) e un campaign token (ct) sull’URL dell’App Store.

Cose più piccole che abbiamo misurato lungo la strada

• Su Android il Play Store è lento a comparire. Nelle sessioni Instagram Android in cui il passaggio è partito, la pagina è diventata nascosta 0–1 s dopo l’arrivo in 1,061 sessioni, 2–3 s dopo in 2,596 e 4–8 s dopo in 1,273 (7 giorni). Un timer «ha funzionato?» da 2 secondi scatta prima che lo store compaia per una buona parte dei veri successi. Il nostro stesso funnel li contava come fallimenti finché non abbiamo lasciato contare comunque un’uscita fino a 8 s dopo il passaggio.
• Il vero tasso di fallimento è basso. Su 7,357 sessioni Instagram Android ricostruite in 3 giorni a inizio ottobre, lo schema «passaggio, poi niente» era l’1.9% delle sessioni, e il 24.3% di quei visitatori ha toccato di nuovo il link entro 3 minuti. I visitatori la cui sessione ha mostrato la scheda di riserva l’hanno ritoccato nel 5.4% dei casi, più o meno come quelli a cui si è aperto lo store (4.6%): la maggior parte di quei «fallimenti» non lo era.
• Chiedere un tocco costa la maggior parte del traffico. Prima che la pagina avviasse il passaggio al caricamento, mostrava una scheda con un pulsante per lo store. In 30 giorni, 10,523 arrivi in-app hanno prodotto 2,119 tocchi: circa l’80% dei visitatori non è mai arrivato allo store.

Metodo

• Fonte. Ogni arrivo su uno smart link e ogni beacon della pagina di passaggio vengono scritti in Cloudflare Workers Analytics Engine con la piattaforma, il browser in-app (dallo user-agent), il tipo di evento e un timestamp al secondo. I visitatori il cui user-agent si dichiara bot, crawler o servizio di anteprima dei link sono tenuti a parte ed esclusi da tutti i numeri qui.
• Sessioni. Analytics Engine non ha un id per caricamento di pagina, quindi le sessioni sono ricostruite unendo un arrivo ai beacon che condividono link, paese, città, user-agent e browser in-app nell’ora successiva, fino al successivo arrivo con la stessa chiave. Circa il 98% dei beacon si aggancia a un arrivo.
• Precaricamenti (risultato 1). Criterio storico: nessun passaggio, nessuna scheda di riserva, nessun tocco e un’uscita da 20 s a 15 min dopo l’arrivo. Criterio a runtime dal 2026-10-16: la pagina segnala un precaricamento quando muore dopo almeno 20 s senza essere mai stata mostrata e il suo timer di passaggio non è mai partito (oppure si è caricata nascosta). Il beacon porta un token firmato monouso, quindi non può essere riprodotto per cancellare una visita reale.
• TikTok (risultato 2). Sessioni raggruppate per link, modello di dispositivo, versione dell’app TikTok e giorno. Regola dei formati: versione musical_ly_ con punti → A; altrimenti JsSdk → B; altrimenti C. I visitatori da reti di hosting sono contati a parte e lasciati fuori dalla tabella. La nuova misura a 30 giorni usa lo stesso script dell’analisi originale a 90 giorni.
• I totali usano l’intervallo di campionamento di Analytics Engine (il 2–4% delle righe rappresenta più di un evento). Le tabelle delle sessioni contano righe.

Limiti

• Non vediamo mai lo store. «Diventata nascosta» è un indicatore indiretto di «lo store si è aperto». Scatta anche quando il visitatore cambia app o blocca il telefono.
• I timestamp sono al secondo, e le sessioni sono ricostruzioni. Due caricamenti ravvicinati dallo stesso dispositivo possono fondersi.
• Concentrazione. Pochi link grandi dominano alcuni periodi: una campagna Instagram vale il 72% dei precaricamenti a 30 giorni, e due link portano la maggior parte delle sessioni TikTok. Le tabelle a link costante esistono per questo.
• Niente qui è stato verificato su un telefono fisico. I comportamenti sono dedotti da ciò che riportano le pagine. La spiegazione iOS del risultato 3 è quella che torna con i dati, non qualcosa che abbiamo visto accadere.
• Il traffico è il nostro. Sono i visitatori delle app che usano i nostri link, fortemente sbilanciati verso campagne Instagram e Facebook in una manciata di paesi. Un altro mix darà altre percentuali, anche se i meccanismi dovrebbero essere gli stessi.
• I precaricamenti che non eseguono mai JavaScript sono invisibili. Il 12% dei caricamenti di pagina Instagram su Android non invia alcun beacon, e probabilmente anche alcuni di questi sono precaricamenti.

Cosa fare

1. Avvia il passaggio allo store al caricamento. Una pagina che aspetta un tocco perde la maggior parte dei visitatori in-app. Tieni il pulsante manuale come riserva, mostrato solo se il passaggio è fallito in modo visibile.
2. Su Android usa `intent://` con `S.browser_fallback_url`. Un URL https://play.google.com dentro una webview apre il sito web del Play Store, che non può installare niente senza accesso.
3. Dai tempo a uno store lento. Aspetta almeno 3 s prima di decidere che il passaggio è fallito, e conta comunque un’uscita tardiva.
4. Dentro TikTok, mostra subito la via d’uscita: «··· → Apri nel browser» e un pulsante per copiare il link. Nessuna modifica all’URL fa sparire il rifiuto di TikTok.
5. Non contare i precaricamenti Meta come clic. Se conti i clic da un reindirizzamento, aspettati che il 2–9% degli arrivi Instagram e Facebook su Android siano pagine che nessuno ha visto.
6. Misura le installazioni sullo store, con i link di campagna di App Store Connect (pt + ct) su iOS e il Play Install Referrer su Android, non con gli eventi di pagina.

Sviluppiamo onestore.link, che fa tutte e sei le cose di default per ogni link, e i dati qui sopra vengono dai suoi log di reindirizzamento.

Domande e risposte