Qué pasa con un enlace de app abierto dentro de Instagram y TikTok: 74,000 redirecciones medidas

Estas cifras salen de los registros de redirección de un servicio de enlaces inteligentes: una sola URL que manda un móvil a la App Store o a Google Play. Cada vez que se abre un enlace dentro de una app social, servimos una pequeña página que traspasa al visitante a la tienda, y esa página informa de lo que pasó después. A continuación, lo que dicen esos informes, cómo los medimos y dónde se detiene la medición.

Los datos

Dos cosas destacan antes de cualquier análisis. Las apps de Meta envían mucho más tráfico que TikTok. Y en Android, más de tres cuartas partes de todas las llegadas pasan por un navegador in-app, no por Chrome.

Cómo informa la página de lo que pasó

Cuando se abre un enlace dentro de un navegador in-app, la página hace tres cosas y envía una baliza por cada una:

• auto: inicia el traspaso a la tienda al cargar (iOS: location.replace a la URL de la App Store; Android: una URL intent:// que abre la app nativa de Play Store).
• exit: la página pasa a estar oculta (Page Visibility API). Es la mejor señal que tiene una página web de que algo, muy probablemente la tienda, ocupó la pantalla.
• stuck: la página sigue visible 2.2 segundos después del traspaso, así que muestra una tarjeta de respaldo con un botón a la tienda, una indicación «ábrelo en tu navegador» y un botón para copiar el enlace.

Una página web no puede ver la App Store ni la Play Store. Todo lo que sigue se deduce de estas tres señales, y la sección de límites indica dónde falla esa deducción.

Hallazgo 1: alrededor de 1 de cada 11 llegadas de Meta en Android es una precarga que nadie vio

En los 30 días hasta el 12 de octubre, un grupo claro de sesiones Android se comportó como ninguna visita humana podría: la página cargó, el temporizador del traspaso nunca se ejecutó y la página se destruyó entre 29 y 31 segundos después. Sin auto, sin stuck, sin toques. iOS no mostró nada parecido.

Es la firma del navegador in-app de Instagram y Facebook precargando un enlace que está en un feed, manteniéndolo oculto y desechándolo cuando el usuario sigue deslizando. La página ejecutó nuestro JavaScript, así que la llegada quedó registrada. Nadie llegó a verla.

Contrastamos el criterio con sesiones claramente humanas: 0 de 17,606 sesiones en las que la tienda se abrió 2–3 s después del traspaso cumplían el criterio, y 0 de 244 sesiones en las que alguien tocó el botón de la tienda.

La proporción varía de una semana a otra: 6.8% en la última semana de ese periodo, y 8.8%, 10.6% y 10.0% en las semanas anteriores. También se concentra donde hay campañas de Instagram de pago: el 72% de las precargas del periodo vinieron de un solo enlace detrás de una gran campaña de Instagram.

Desde el 16 de octubre, la página lo clasifica ella misma en tiempo de ejecución: informa de una precarga en lugar de una salida cuando muere tras al menos 20 s sin haberse mostrado nunca. Esto es lo que ha detectado desde entonces:

Ese recuento en tiempo de ejecución es un mínimo. Una precarga que muere sin ejecutar ningún script no deja baliza, y la regla en tiempo de ejecución es más estricta que la reconstrucción histórica.

Por qué importa. Si cuentas clics en tu redirección, aproximadamente uno de cada 13 «clics» de Instagram en Android nunca lo vio una persona. Tu ratio de clics a instalaciones para ese canal parece peor de lo que es, y un panel de campaña basado en los hits brutos de redirección sobrestima el alcance más o menos en esa medida.

Hallazgo 2: TikTok rechaza la Play Store según la webview que usa

Dentro de TikTok en Android, una parte de los visitantes nunca sale de la página: el traspaso se lanza y TikTok muestra su propio diálogo («The action cannot be completed»). No pasa en todos los enlaces, y durante semanas pareció que dependía del enlace. No es así. Depende del navegador in-app que TikTok usa para ese visitante, y su user-agent lo delata:

Una sesión cuenta como éxito cuando el traspaso se lanzó y la página pasó a oculta, y como fallo cuando se mostró la tarjeta de respaldo. La tasa es éxitos / (éxitos + fallos), por dispositivo y día:

La comparación que lo zanja mantiene constantes el enlace y el día, ya que la mezcla de formatos cambia de una semana a otra:

Mismo enlace, mismo código de redirección, mismo día: una webview deja que la tienda se abra y la otra casi nunca. Los dominios personalizados no marcaron ninguna diferencia en los datos de 90 días. TikTok no documenta el diálogo, qué lo provoca ni qué usuarios reciben qué webview, así que la división por user-agent es todo lo que hay.

Por qué importa. Ninguna forma de URL lo arregla: la salida con intent:// y una URL simple https://play.google.com reciben el mismo rechazo. Lo que sí puedes hacer es no esconder la salida: dentro de TikTok, muestra enseguida las instrucciones «abrir en el navegador» y un botón de copiar, en lugar de hacerlo tras una espera.

Hallazgo 3: en iOS, la App Store se abre encima del navegador in-app

En Android, tras el traspaso, la página pasa a oculta en la mayoría de las sesiones, normalmente entre 1 y 3 segundos después. En iOS dentro de Instagram y Facebook a menudo no, aunque el traspaso se lanzó en casi todas las sesiones:

Si dos tercios de los visitantes de iOS estuvieran de verdad atascados ante una tarjeta de respaldo visible con un botón «Abrir la App Store», muchos lo tocarían. No lo hacen: solo el 0.9% de las cargas de página de Instagram en iOS y el 0.4% de las de Facebook en iOS tocan el botón. Tampoco hay una versión de iOS en la que «funcione»:

La explicación que encaja es que, dentro de Instagram y Facebook en iOS, la App Store aparece encima del navegador in-app sin mandarlo a segundo plano. La página sigue «visible» todo el tiempo, así que visibilitychange y pagehide nunca se disparan, aunque el visitante esté mirando la App Store.

Por qué importa. Cualquier métrica que deduzca que se abrió la tienda porque la página salió de la pantalla es errónea en iOS. Mostrábamos a los clientes un porcentaje de «alcance de tienda» construido exactamente así, y les decía a 10 de 12 clientes de pago que enlaces que funcionaban estaban rotos. Lo quitamos. En iOS, la señal de instalación fiable está del lado de la tienda: los informes de campaña de App Store Connect, con un provider token (pt) y un campaign token (ct) en la URL de la App Store.

Cosas más pequeñas que medimos por el camino

• La Play Store tarda en aparecer en Android. En las sesiones de Instagram en Android en las que se lanzó el traspaso, la página pasó a oculta 0–1 s después de la llegada en 1,061 sesiones, 2–3 s después en 2,596 y 4–8 s después en 1,273 (7 días). Un temporizador de «¿ha funcionado?» de 2 segundos salta antes de que aparezca la tienda en buena parte de los éxitos reales. Nuestro propio embudo los contaba como fallos hasta que dejamos que una salida de hasta 8 s después del traspaso siguiera contando.
• La tasa real de fallo es pequeña. En 7,357 sesiones de Instagram en Android reconstruidas durante 3 días a principios de octubre, el patrón «traspaso y luego nada» fue el 1.9% de las sesiones, y el 24.3% de esos visitantes volvió a tocar el enlace en menos de 3 minutos. Los visitantes cuya sesión mostró la tarjeta de respaldo volvieron a tocarlo en un 5.4%, más o menos como aquellos a los que se les abrió la tienda (4.6%): la mayoría de esos «fallos» no lo eran.
• Exigir un toque cuesta la mayor parte del tráfico. Antes de que la página iniciara el traspaso al cargar, mostraba una tarjeta con un botón a la tienda. En 30 días, 10,523 llegadas in-app produjeron 2,119 toques: alrededor del 80% de los visitantes nunca llegó a la tienda.

Método

• Fuente. Cada llegada a un enlace inteligente y cada baliza de la página de traspaso se escriben en Cloudflare Workers Analytics Engine con la plataforma, el navegador in-app (según el user-agent), el tipo de evento y una marca de tiempo al segundo. Los visitantes cuyo user-agent se declara bot, crawler o generador de vistas previas de enlaces se separan y se excluyen de todas las cifras de aquí.
• Sesiones. Analytics Engine no tiene identificador de carga de página, así que las sesiones se reconstruyen uniendo una llegada con las balizas que comparten su enlace, país, ciudad, user-agent y navegador in-app en la hora siguiente, hasta la siguiente llegada con la misma clave. Alrededor del 98% de las balizas se asocian a una llegada.
• Precargas (hallazgo 1). Criterio histórico: sin traspaso, sin tarjeta de respaldo, sin toque, y una salida entre 20 s y 15 min después de la llegada. Criterio en tiempo de ejecución desde el 2026-10-16: la página informa de una precarga cuando muere tras al menos 20 s sin haberse mostrado nunca y su temporizador de traspaso nunca se ejecutó (o cargó oculta). La baliza lleva un token firmado de un solo uso, así que no se puede reenviar para borrar una visita real.
• TikTok (hallazgo 2). Sesiones agrupadas por enlace, modelo de dispositivo, versión de la app de TikTok y día. Regla de formato: versión musical_ly_ con puntos → A; si no, JsSdk → B; si no, C. Los visitantes desde redes de hosting se cuentan aparte y quedan fuera de la tabla. La nueva medición de 30 días usa el mismo script que el análisis original de 90 días.
• Los totales usan el intervalo de muestreo de Analytics Engine (el 2–4% de las filas representan más de un evento). Las tablas de sesiones cuentan filas.

Límites

• Nunca vemos la tienda. «Pasó a oculta» es un indicador indirecto de «se abrió la tienda». También se dispara cuando el visitante cambia de app o bloquea el móvil.
• Las marcas de tiempo son al segundo, y las sesiones son reconstrucciones. Dos cargas rápidas desde el mismo dispositivo pueden fusionarse.
• Concentración. Unos pocos enlaces grandes dominan algunos periodos: una campaña de Instagram supone el 72% de las precargas de 30 días, y dos enlaces concentran la mayoría de las sesiones de TikTok. Las tablas con el mismo enlace existen por eso.
• Nada de esto se comprobó en un móvil físico. Los comportamientos se deducen de lo que informan las páginas. La explicación de iOS del hallazgo 3 es la que encaja con los datos, no algo que viéramos ocurrir.
• El tráfico es el nuestro. Son los visitantes de las apps que usan nuestros enlaces, muy sesgados hacia campañas de Instagram y Facebook en un puñado de países. Otra mezcla dará otros porcentajes, aunque los mecanismos deberían ser los mismos.
• Las precargas que nunca ejecutan JavaScript son invisibles. El 12% de las cargas de página de Instagram en Android no envía ninguna baliza, y probablemente algunas de ellas también son precargas.

Qué hacer al respecto

1. Inicia el traspaso al cargar. Una página que espera un toque pierde a la mayoría de los visitantes in-app. Mantén el botón manual como respaldo, visible solo si el traspaso falló de forma evidente.
2. En Android, usa `intent://` con `S.browser_fallback_url`. Una URL https://play.google.com dentro de una webview abre la web de la Play Store, que no puede instalar nada sin iniciar sesión.
3. Dale tiempo a una tienda lenta. Espera al menos 3 s antes de decidir que el traspaso falló, y cuenta igualmente una salida tardía.
4. Dentro de TikTok, muestra la salida enseguida: «··· → Abrir en el navegador» y un botón para copiar el enlace. Ningún cambio de URL hace desaparecer el rechazo de TikTok.
5. No cuentes las precargas de Meta como clics. Si cuentas clics desde una redirección, espera que entre el 2–9% de las llegadas de Instagram y Facebook en Android sean páginas que nadie vio.
6. Mide las instalaciones en la tienda, con enlaces de campaña de App Store Connect (pt + ct) en iOS y el Play Install Referrer en Android, no con eventos de página.

Desarrollamos onestore.link, que hace las seis cosas por defecto en cada enlace, y los datos de arriba salen de sus registros de redirección.

Preguntas y respuestas