Ce que devient un lien d'app ouvert dans Instagram et TikTok : 74,000 redirections mesurées

Ces chiffres viennent des logs de redirection d'un service de liens intelligents : une seule URL qui envoie un téléphone vers l'App Store ou Google Play. Chaque fois qu'un lien est ouvert dans une app sociale, nous servons une petite page qui passe le visiteur au store, et cette page rapporte ce qui s'est passé ensuite. Voici ce que disent ces rapports, comment nous les avons mesurés, et où s'arrête la mesure.

Les données

Deux choses ressortent avant toute analyse. Les apps de Meta envoient bien plus de trafic que TikTok. Et sur Android, plus des trois quarts des arrivées passent par un navigateur in-app, pas par Chrome.

Comment la page rapporte ce qui s'est passé

Quand un lien est ouvert dans un navigateur in-app, la page fait trois choses et envoie une balise pour chacune :

• auto : elle lance le passage au store dès le chargement (iOS : location.replace vers l'URL App Store ; Android : une URL intent:// qui ouvre l'app native Play Store).
• exit : la page devient masquée (Page Visibility API). C'est le meilleur signal dont dispose une page web que quelque chose, très probablement le store, a pris l'écran.
• stuck : la page est toujours visible 2.2 secondes après le passage au store ; elle affiche alors une carte de secours avec un bouton vers le store, une indication « ouvrir dans votre navigateur » et un bouton pour copier le lien.

Une page web ne peut pas voir l'App Store ni le Play Store. Tout ce qui suit est déduit de ces trois signaux, et la section des limites dit où cette déduction ne tient plus.

Constat 1 : environ 1 arrivée Meta Android sur 11 est un préchargement que personne n'a vu

Sur les 30 jours jusqu'au 12 octobre, un groupe net de sessions Android s'est comporté comme aucune visite humaine ne le pourrait : la page s'est chargée, le minuteur de passage au store n'a jamais tourné, et la page a été détruite 29 à 31 secondes plus tard. Pas de auto, pas de stuck, aucun appui. Rien de comparable sur iOS.

C'est la signature du navigateur in-app d'Instagram et de Facebook qui précharge un lien présent dans un fil, le garde masqué, puis le jette quand l'utilisateur continue de défiler. La page a exécuté notre JavaScript, donc l'arrivée a été enregistrée. Personne ne l'a jamais regardée.

Nous avons confronté le critère à des sessions clairement humaines : 0 sur 17,606 sessions où le store s'est ouvert 2–3 s après le passage au store y correspondaient, et 0 sur 244 sessions où quelqu'un a appuyé sur le bouton du store.

La part varie d'une semaine à l'autre : 6.8% la dernière semaine de cette période, puis 8.8%, 10.6% et 10.0% les semaines précédentes. Elle se concentre aussi là où tournent des campagnes Instagram payantes : 72% des préchargements de la période venaient d'un seul lien derrière une grosse campagne Instagram.

Depuis le 16 octobre, la page fait elle-même ce classement à l'exécution : elle signale un préchargement au lieu d'une sortie quand elle meurt après au moins 20 s sans avoir jamais été affichée. Voici ce qu'elle a détecté depuis :

Ce comptage à l'exécution est un plancher. Un préchargement qui meurt sans exécuter le moindre script ne laisse aucune balise, et la règle à l'exécution est plus stricte que la reconstruction historique.

Pourquoi c'est important. Si vous comptez les clics à votre redirection, environ un « clic » Instagram Android sur 13 n'a jamais été vu par une personne. Votre ratio clics/installations pour ce canal paraît pire qu'il ne l'est, et un tableau de bord de campagne construit sur les hits bruts de redirection surestime la portée d'à peu près autant.

Constat 2 : TikTok refuse le Play Store selon la webview qu'il utilise

Dans TikTok sur Android, une partie des visiteurs ne quittent jamais la page : le passage au store se déclenche et TikTok affiche sa propre boîte de dialogue (« The action cannot be completed »). Cela n'arrive pas sur tous les liens, et pendant des semaines on a cru que cela dépendait du lien. Ce n'est pas le cas. Cela dépend du navigateur in-app que TikTok utilise pour ce visiteur, et son user-agent le trahit :

Une session compte comme réussie quand le passage au store s'est déclenché et que la page est passée masquée, et comme un échec quand la carte de secours s'est affichée. Le taux vaut réussites / (réussites + échecs), par appareil et par jour :

La comparaison qui tranche garde le lien et le jour constants, puisque le mélange des formats change d'une semaine à l'autre :

Même lien, même code de redirection, même jour : une webview laisse le store s'ouvrir, l'autre la plupart du temps non. Les domaines personnalisés n'ont fait aucune différence dans les données sur 90 jours. TikTok ne documente ni cette boîte de dialogue, ni ce qui la déclenche, ni quels utilisateurs reçoivent quelle webview : la répartition par user-agent est tout ce qu'on a.

Pourquoi c'est important. Aucune forme d'URL n'y change rien : la sortie par intent:// et une simple URL https://play.google.com reçoivent le même refus. Ce que vous pouvez faire, c'est ne pas cacher la sortie : dans TikTok, affichez tout de suite les instructions « ouvrir dans le navigateur » et un bouton de copie, au lieu de les afficher après un délai.

Constat 3 : sur iOS, l'App Store s'ouvre par-dessus le navigateur in-app

Sur Android, après le passage au store, la page passe masquée dans la plupart des sessions, en général 1 à 3 secondes plus tard. Sur iOS dans Instagram et Facebook, souvent non, alors que le passage au store s'est déclenché dans presque toutes les sessions :

Si deux tiers des visiteurs iOS étaient vraiment bloqués devant une carte de secours visible avec un bouton « Ouvrir l'App Store », bon nombre appuieraient dessus. Ce n'est pas le cas : 0.9% des chargements de page Instagram iOS et 0.4% des chargements Facebook iOS appuient sur le bouton. Et aucune version d'iOS ne « fonctionne » :

L'explication qui colle est que, dans Instagram et Facebook sur iOS, l'App Store apparaît par-dessus le navigateur in-app sans l'envoyer en arrière-plan. La page reste « visible » tout du long, donc visibilitychange et pagehide ne se déclenchent jamais, alors que le visiteur a l'App Store sous les yeux.

Pourquoi c'est important. Toute métrique qui déduit l'ouverture du store du fait que la page quitte l'écran est fausse sur iOS. Nous montrions à nos clients un pourcentage de « portée store » construit exactement ainsi, et il disait à 10 clients payants sur 12 que des liens qui fonctionnaient étaient cassés. Nous l'avons retiré. Sur iOS, le signal d'installation fiable est côté store : les rapports de campagne App Store Connect, avec un provider token (pt) et un campaign token (ct) sur l'URL App Store.

Ce que nous avons mesuré en chemin

• Le Play Store met du temps à s'afficher sur Android. Dans les sessions Instagram Android où le passage au store s'est déclenché, la page est passée masquée 0–1 s après l'arrivée dans 1,061 sessions, 2–3 s après dans 2,596, et 4–8 s après dans 1,273 (7 jours). Un minuteur « ça a marché ? » de 2 secondes se déclenche avant l'apparition du store pour une grande partie des vraies réussites. Notre propre entonnoir les comptait comme des échecs jusqu'à ce que nous laissions une sortie jusqu'à 8 s après le passage au store compter quand même.
• Le vrai taux d'échec est faible. Sur 7,357 sessions Instagram Android reconstruites sur 3 jours début octobre, le schéma « passage au store, puis rien » représentait 1.9% des sessions, et 24.3% de ces visiteurs ont rouvert le lien dans les 3 minutes. Les visiteurs dont la session a affiché la carte de secours l'ont rouvert à 5.4%, à peu près comme ceux dont le store s'est ouvert (4.6%) : la plupart de ces « échecs » n'en étaient pas.
• Exiger un appui coûte la majorité du trafic. Avant que la page ne lance le passage au store dès le chargement, elle affichait une carte avec un bouton vers le store. Sur 30 jours, 10,523 arrivées in-app ont produit 2,119 appuis : environ 80% des visiteurs n'ont jamais atteint le store.

Méthode

• Source. Chaque arrivée sur un lien intelligent et chaque balise de la page de passage au store sont écrites dans Cloudflare Workers Analytics Engine avec la plateforme, le navigateur in-app (d'après le user-agent), le type d'événement et un horodatage à la seconde. Les visiteurs dont le user-agent se déclare bot, crawler ou outil d'aperçu de lien sont mis à part et exclus de tous les chiffres ici.
• Sessions. Analytics Engine n'a pas d'identifiant de chargement de page : les sessions sont reconstruites en associant une arrivée aux balises qui partagent son lien, son pays, sa ville, son user-agent et son navigateur in-app dans l'heure qui suit, jusqu'à la prochaine arrivée de même clé. Environ 98% des balises se rattachent à une arrivée.
• Préchargements (constat 1). Critère historique : pas de passage au store, pas de carte de secours, pas d'appui, et une sortie 20 s à 15 min après l'arrivée. Critère à l'exécution depuis le 2026-10-16 : la page signale un préchargement quand elle meurt après au moins 20 s sans avoir jamais été affichée et que son minuteur de passage au store n'a jamais tourné (ou qu'elle s'est chargée masquée). La balise porte un jeton signé à usage unique, elle ne peut donc pas être rejouée pour effacer une vraie visite.
• TikTok (constat 2). Sessions indexées par lien, modèle d'appareil, version de l'app TikTok et jour. Règle de format : version musical_ly_ à points → A ; sinon JsSdk → B ; sinon C. Les visiteurs venant de réseaux d'hébergement sont comptés à part et exclus du tableau. La nouvelle mesure sur 30 jours utilise le même script que l'analyse initiale sur 90 jours.
• Les totaux utilisent l'intervalle d'échantillonnage d'Analytics Engine (2–4% des lignes représentent plus d'un événement). Les tableaux de sessions comptent des lignes.

Limites

• Nous ne voyons jamais le store. « Passée masquée » est un indicateur indirect de « le store s'est ouvert ». Il se déclenche aussi quand le visiteur change d'app ou verrouille son téléphone.
• Les horodatages sont à la seconde, et les sessions sont des reconstructions. Deux chargements rapprochés depuis le même appareil peuvent fusionner.
• Concentration. Quelques gros liens dominent certaines périodes : une campagne Instagram représente 72% des préchargements sur 30 jours, et deux liens portent la plupart des sessions TikTok. Les tableaux à lien constant existent pour cette raison.
• Rien ici n'a été vérifié sur un vrai téléphone. Les comportements sont déduits de ce que rapportent les pages. L'explication iOS du constat 3 est celle qui colle aux données, pas quelque chose que nous avons vu se produire.
• Le trafic est le nôtre. Ce sont les visiteurs des apps qui utilisent nos liens, fortement pondérés vers des campagnes Instagram et Facebook dans une poignée de pays. Un autre mélange donnera d'autres pourcentages, même si les mécanismes devraient être les mêmes.
• Les préchargements qui n'exécutent jamais de JavaScript sont invisibles. 12% des chargements de page Instagram Android n'envoient aucune balise, et une partie d'entre eux sont probablement aussi des préchargements.

Que faire

1. Lancez le passage au store dès le chargement. Une page qui attend un appui perd la plupart des visiteurs in-app. Gardez le bouton manuel comme solution de secours, affiché seulement si le passage au store a visiblement échoué.
2. Sur Android, utilisez `intent://` avec `S.browser_fallback_url`. Une URL https://play.google.com dans une webview ouvre le site web du Play Store, qui ne peut rien installer sans connexion.
3. Laissez du temps à un store lent. Attendez au moins 3 s avant de conclure que le passage au store a échoué, et comptez quand même une sortie tardive.
4. Dans TikTok, montrez la sortie tout de suite : « ··· → Ouvrir dans le navigateur » et un bouton pour copier le lien. Aucun changement d'URL ne fait disparaître le refus de TikTok.
5. Ne comptez pas les préchargements Meta comme des clics. Si vous comptez les clics depuis une redirection, attendez-vous à ce que 2–9% des arrivées Instagram et Facebook sur Android soient des pages que personne n'a vues.
6. Mesurez les installations côté store, avec des liens de campagne App Store Connect (pt + ct) sur iOS et le Play Install Referrer sur Android, pas avec des événements de page.

Nous développons onestore.link, qui fait ces six choses par défaut pour chaque lien, et les données ci-dessus viennent de ses logs de redirection.

Questions et réponses