Deep links en iOS y Android: guía práctica

Un deep link es una URL que abre una pantalla concreta dentro de una app instalada en lugar de una página web. Esa es toda la idea, y se ha implementado de tres formas distintas a lo largo de quince años, cada una con sus propios modos de fallo. La razón por la que los equipos de marketing no dejan de reportar incidencias al respecto es que las tres siguen existiendo a la vez, y la misma URL puede comportarse de forma distinta según se haya tocado en un mensaje, en un navegador, en un cliente de correo o en un webview integrado dentro de una app social.

Esta guía explica los mecanismos con honestidad, incluido lo que no pueden hacer. Si te quedas con una sola cosa, que sea esta: enrutar un clic a la pantalla correcta de una app es infraestructura resuelta, y llevar a un usuario a la pantalla correcta después de que instale la app no lo es, al menos no desde la plataforma de enlaces por sí sola.

Las tres generaciones del enlazado a apps

Esquemas de URL propios

El mecanismo original. Una app registra un esquema como myapp, y una URL como myapp://product/42 le entrega la solicitud. Los esquemas son triviales de implementar y siguen siendo útiles como formato interno de enrutado, pero arrastran dos problemas estructurales.

No hay verificación de propiedad: cualquier app puede registrar cualquier esquema, y cuando dos apps reclaman el mismo, la resolución queda indefinida en iOS y en Android aparece un diálogo de selección. Y no hay alternativa: en un dispositivo sin la app instalada, una URL de esquema produce una página de error o directamente nada, así que todo enlace de esquema necesita una envoltura que detecte el fallo y mande al usuario a algún sitio útil. Esa envoltura es justo la pieza frágil que se rompió cuando los navegadores endurecieron su gestión de los temporizadores de navegación.

Universal Links en iOS

El sustituto de Apple usa URL HTTPS normales. Tu app declara un entitlement de dominios asociados con la forma applinks:yourbrand.com, y el dominio publica un archivo JSON en /.well-known/apple-app-site-association que describe qué rutas pertenecen a la app.

{
  "applinks": {
    "details": [
      {
        "appIDs": ["ABCDE12345.com.yourbrand.app"],
        "components": [{ "/": "/p/*", "comment": "Product pages" }]
      }
    ]
  }
}

El archivo debe servirse por HTTPS sin redirecciones, como JSON y en esa ruta exacta. iOS lo descarga alrededor del momento de la instalación y de las actualizaciones, en buena medida a través de la CDN de Apple, lo que significa que los cambios no surten efecto al instante. La ventaja es que la misma URL funciona en todas partes: si la app está instalada y la ruta encaja, se abre; si no, Safari carga la página web. No hay estado de error.

App Links en Android

El equivalente de Android usa un archivo Digital Asset Links en /.well-known/assetlinks.json, que nombra el paquete de la app y la huella SHA-256 del certificado de firma.

[
  {
    "relation": ["delegate_permission/common.handle_all_urls"],
    "target": {
      "namespace": "android_app",
      "package_name": "com.yourbrand.app",
      "sha256_cert_fingerprints": ["A1:B2:C3:D4:E5:F6:..."]
    }
  }
]

Del lado de la app se declara un intent filter para el dominio con la verificación automática activada. Cuando la verificación tiene éxito, el enlace abre la app sin ningún diálogo de selección. Cuando falla, el enlace abre el navegador, y la causa más frecuente con diferencia es una huella que no coincide: los equipos publican la huella de su clave de firma local mientras Play App Signing vuelve a firmar la app con otra distinta. La huella que corresponde poner en el archivo es la que la tienda muestra para el artefacto distribuido.

Cómo elige su destino un enlace corto

Un enlace corto es un punto de decisión más que un puntero fijo, y eso es justo lo que lo hace útil para las campañas de app: un mismo código impreso puede tratar de forma distinta a los usuarios de iPhone, a los de Android y a las visitas de escritorio, y la decisión puede cambiar después de imprimir el código.

El motor de redirección ve el user agent de la solicitud, los client hints que lleva y las señales derivadas de la red, como el país. Un enlace configurado para tráfico de app suele guardar tres destinos: una URL de iOS, una URL de Android y una URL web que se usa para todo lo demás. Por encima de eso, las reglas de segmentación pueden enrutar por país, dispositivo, sistema operativo o idioma, de modo que una campaña puede mandar el tráfico Android canadiense a un destino y a todos los demás a otro sin crear enlaces separados.

Merece la pena conocer dos detalles de implementación, porque explican casi todo el comportamiento desconcertante.

El primero son los rastreadores sociales. Cuando un bot como el de Facebook o el de Telegram pide un enlace para construir una tarjeta de vista previa, un motor de redirección correcto responde con los metadatos de la vista previa en lugar de contar la solicitud como un clic y en lugar de enrutarla como si fuera un teléfono. Si tus recuentos de clics se disparan en cuanto publicas un enlace y antes de que nadie lo haya tocado, el motor no está haciendo esto.

El segundo es la frontera de la asociación, y es el punto técnico más importante de este artículo. Los Universal Links se evalúan contra el dominio de la URL que el usuario tocó realmente. Si alguien toca go.yourbrand.com/p/42 y ese dominio responde con una redirección a yourbrand.com/p/42, iOS no trata el destino de la redirección como un enlace asociado, así que la app no se abre. Para que un enlace corto abra la app de forma nativa, el archivo de asociación debe servirse en el propio dominio corto. Donde eso no es posible, la alternativa práctica es un traspaso a un esquema propio o directamente a la tienda, que es lo que de verdad hacen la mayoría de las funciones de deep link de los acortadores. Pregunta a cualquier proveedor cuál de las dos implementa, porque el texto de marketing es idéntico en ambos casos.

La cadena de alternativas

Un enlace de app que funciona es en realidad un pequeño árbol de decisión, y cada rama necesita una respuesta deliberada.

| Situación | Qué debería pasar | Error habitual | | --- | --- | --- | | App instalada, ruta reconocida | La app se abre en la pantalla de destino | Una cadena de redirecciones rompe la asociación | | App instalada, ruta no reconocida | Se carga la página web y se sugiere la app | Se muestra el diálogo de selección en cada toque | | App no instalada, móvil | Página de la tienda de la plataforma correcta | Enlace de tienda fijado a una sola plataforma | | Escritorio | Equivalente web completo de la pantalla | Aterrizar en una página principal genérica | | Rastreador social | Metadatos de vista previa, sin contar clic | La descarga de la vista previa infla las analíticas |

Apunta la rama de la tienda a la ficha adecuada para cada plataforma en lugar de a un enlace único, y mantén la rama web genuinamente equivalente a la pantalla de la app. Una parte grande del tráfico de las campañas de app acaba en la rama web por bien configurado que esté todo lo demás, y tratarla como un callejón sin salida desperdicia la mayor parte de la inversión.

La frontera de la instalación, con honestidad

Aquí es donde el marketing de los proveedores y la realidad se separan. Supón que un usuario nuevo toca un enlace a un producto concreto, no tiene la app, aterriza en la tienda, instala y abre. La app le muestra ahora su pantalla de inicio por defecto, porque nada llevó el identificador del producto al otro lado de la instalación. Hacer que eso funcione se llama deep linking diferido, y no es algo que una plataforma de enlaces pueda hacer por su cuenta.

Requiere un SDK dentro de la app que, en el primer arranque, pregunte a un servidor qué tocó el usuario antes de instalar. El servidor tiene que emparejar los dos eventos, y las señales disponibles para ese emparejamiento se han estrechado mucho. La huella digital del dispositivo es poco fiable y cada vez está más restringida por las políticas de las plataformas. Los identificadores publicitarios exigen un consentimiento que la mayoría de los usuarios rechaza. Los marcos de atribución de Apple informan a los anunciantes de la atribución a nivel de instalación, en lugar de pasar una ruta a tu app. La técnica del portapapeles que antes transportaba un token ahora dispara un aviso visible de pegado.

Lo que queda funciona, pero es otro producto con otro coste de integración: un SDK de mobile measurement partner, una inicialización dentro de la app y una ventana de emparejamiento que es probabilística y no exacta. LinkProfit enruta los clics por dispositivo y cede el paso a la tienda, y no afirma hacer enrutado posterior a la instalación, porque hacerlo bien significa enviar código dentro de tu app. Si el enrutado diferido es un requisito duro, planifica ese SDK junto a tu plataforma de enlaces y no en lugar de ella.

Webviews y otras trampas prácticas

Navegadores dentro de apps

La mayoría de los enlaces que se tocan dentro de apps sociales se abren en un webview integrado y no en el navegador del sistema, y los webviews tratan la asociación con apps de forma inconsistente: algunos ignoran los Universal Links, otros bloquean los esquemas propios, y el comportamiento cambia según la versión de la app. Esta es la razón más habitual de que un enlace que funciona perfectamente en las pruebas abra la web en producción, ya que las pruebas suelen hacerse tocando un enlace en una app de mensajería, que se comporta correctamente.

No hay ninguna configuración que arregle esto de forma global. Lo que funciona es hacer bueno el destino web, añadirle un control visible para abrir en la app y probar cada canal de publicación por separado en lugar de suponer que todos se comportan igual.

Errores con el archivo de asociación

Cuatro se repiten. Servir el archivo de asociación a través de una redirección, incluida la redirección automática del dominio raíz a www, que lo invalida. Servirlo con el content type equivocado o desde una ruta que reescribe un framework. Publicar la huella de firma de Android equivocada, como se ha descrito arriba. Y olvidar que iOS cachea el archivo, así que una corrección puede tardar un día o más en llegar a los dispositivos que ya tienen la app instalada.

Analíticas en la rama de la app

En cuanto un clic entra en una app, tu analítica web deja de verlo, y ahí es donde los informes se desmoronan en silencio. Mantén los parámetros de campaña en el enlace para que el motor de redirección los registre, y pasa un identificador hasta el destino de la app para que la sesión dentro de la app pueda unirse al clic. Nuestra guía para medir los clics de tus enlaces cubre lo que un evento de clic puede y no puede contarte, y aquí se aplican las mismas advertencias sobre bots y visitantes únicos.

Probar antes de publicar

curl -sSI https://yourbrand.com/.well-known/apple-app-site-association
curl -sS https://yourbrand.com/.well-known/assetlinks.json

# Android: open a URL as if it were tapped, then inspect verification state
adb shell am start -a android.intent.action.VIEW -d "https://yourbrand.com/p/42"
adb shell pm get-app-links com.yourbrand.app

# iOS simulator
xcrun simctl openurl booted "https://yourbrand.com/p/42"

Los dos primeros comandos deberían devolver 200 sin ninguna redirección. Ten en cuenta que escribir un Universal Link en la barra de direcciones de Safari deliberadamente no abre la app, así que prueba desde una nota, un mensaje o el comando del simulador, o perseguirás un fallo que no existe.

Qué incluyen realmente las plataformas de enlaces

El soporte de deep links se empaqueta de forma muy distinta según el proveedor, y las diferencias tienen que ver con qué plan hay que comprar más que con la capacidad.

| Proveedor | Disponibilidad de deep links, a fecha de agosto de 2026 | | --- | --- | | BL.INK | Todos los planes; nivel de entrada de 48 USD al mes para un usuario y un dominio | | Short.io | A partir del plan Team, por 48 USD al mes | | Rebrandly | A partir del plan Growth, de 99 a 119 USD al mes | | Switchy | Cobertura anunciada de más de 130 apps | | LinkProfit | Destinos por dispositivo en todos los planes |

BL.INK es aquí la referencia honesta: incluir deep links en todos los niveles es poco habitual, aunque el precio de entrada sea alto para un solo dominio. La colocación de Rebrandly en Growth es el patrón que conviene vigilar en general, porque el nivel que necesitas por una sola función tiende a determinar toda la factura.

Una secuencia de despliegue que funciona

1. Decide la URL web canónica de cada pantalla de la app a la que quieras enlazar; la página web es la alternativa y la fuente de verdad.
2. Publica ambos archivos de asociación en el dominio que va a aparecer en los enlaces, y verifícalos por HTTPS sin redirecciones.
3. Añade el entitlement de dominios asociados en iOS y el intent filter verificado en Android, usando la huella de la compilación distribuida.
4. Confirma en qué dominio se van a tocar tus enlaces cortos, y si la asociación vive ahí o la plataforma cede el paso a un esquema o a la tienda.
5. Configura en cada enlace destinos por dispositivo más una alternativa web, con la ficha de tienda correcta para cada plataforma.
6. Prueba en ambas plataformas desde una app de mensajería, desde el navegador del sistema y desde cada app social en la que publiques.
7. Verifica que los parámetros de campaña sobreviven a la redirección y quedan registrados en analíticas.
8. Automatiza la creación mediante la API si los enlaces se generan por campaña, por destinatario o por producto.

Nada de esto es difícil por separado. La dificultad está en que las piezas viven en tres sitios —el proyecto de la app, la zona DNS y la plataforma de enlaces—, normalmente en manos de tres personas distintas. Dejar escrito quién es el dueño del archivo de asociación vale más que cualquier consejo de configuración concreto de este artículo.