Apps móviles y deep links

Un enlace corto que lleva a una app móvil tiene tres públicos a la vez: quienes ya tienen la app, quienes no la tienen y quienes navegan desde dentro de otra app. Esta página cubre los tres, más las dos piezas de configuración que marcan la diferencia: los archivos de asociación en tu dominio y el contexto del clic diferido que tu app puede leer en el primer arranque.

Qué hace la sección de móvil

Abre un enlace, ve a la pestaña Móvil y activa los destinos para móvil. Para cada plataforma puedes fijar tres direcciones:

• Enlace de la app: la dirección dentro de tu app, es decir tu propio esquema con una ruta (myapp://product/42), un intent de Android o un enlace universal https.
• Dirección de la tienda: la página de App Store o de Google Play, que se usa cuando la app no se abre.
• Alternativa web: una página para los visitantes a los que prefieres no mandar a la tienda.

Todo es opcional. Un enlace que solo lleva dirección de tienda es una simple redirección a la tienda. Un enlace con enlace de app y dirección de tienda obtiene el comportamiento completo: la página prueba primero la app y pasa a la tienda cuando no ocurre nada.

Otros dos ajustes deciden qué pasa fuera de un navegador de móvil corriente:

• Tabletas: tratarlas como móviles (lo predeterminado) o como escritorio.
• Navegadores dentro de apps: qué hacer cuando el enlace se abre dentro de Instagram, TikTok, Facebook o una app parecida.

Los visitantes de escritorio siguen el Destino en escritorio si lo fijas, y el destino principal del enlace en caso contrario. Nada de la sección de móvil cambia lo que ven los visitantes de escritorio salvo que tú lo pidas.

Por qué los navegadores dentro de apps necesitan su propia regla

La mayoría de los clics en enlaces dentro de un feed social nunca llegan a Safari ni a Chrome. Se abren en una vista web dentro de la propia app, y varias de esas vistas web se quedan con toda la navegación: un enlace universal se queda en la vista web, y un esquema propio simplemente no hace nada. Eso no es un fallo que puedas arreglar desde el enlace: es una decisión de la app que posee la vista web.

Así que el ajuste te da tres opciones honestas:

| Opción | Qué recibe el visitante | | --- | --- | | Intentar abrir la app | La página intermedia prueba el enlace de la app; cuando se sabe que la vista web lo bloquea, la página se salta la espera y explica cómo volver a abrir el enlace en el navegador del móvil. | | Ir directamente a la tienda | Sin intentar la app: útil en campañas de instalación donde la página de la tienda es el objetivo. | | Ir a la alternativa web | El visitante se queda en la web, que suele ser la mejor respuesta para enlaces de contenido. |

Archivos de asociación: la configuración que hace que los enlaces abran la app en silencio

Para que un enlace abra tu app sin parada en el navegador, el sistema operativo tiene que saber que tu dominio y tu app van juntos. Las dos plataformas lo comprueban con un archivo servido desde el propio dominio:

https://go.brand.com/.well-known/apple-app-site-association
https://go.brand.com/.well-known/assetlinks.json

Esos archivos no los escribes tú. En Dominios, abre el dominio y añade tus apps en Aplicaciones móviles:

• para iOS: el App ID en la forma TEAMID.com.company.app, y las rutas que debe manejar la app (* cubre todos los enlaces cortos);
• para Android: el nombre del paquete y las huellas de firma SHA-256 de Play Console.

La plataforma construye y sirve ambos archivos desde tu dominio con exactamente la respuesta que ambas plataformas exigen: estado 200, sin redirecciones, application/json, sin compresión de transporte. Esto último importa más de lo que parece: un proxy que comprime el archivo por el camino es una de las causas más habituales de que los enlaces de app dejen de funcionar sin avisar.

Comprobar la configuración

El botón Comprobar los archivos descarga ambos archivos de tu dominio en producción e informa de lo que vería una plataforma. Los hallazgos se corresponden con arreglos concretos:

| Hallazgo | Qué hacer | | --- | --- | | El dominio no ha respondido | El dominio todavía no sirve tráfico, o el DNS aún se está propagando. | | Falta el archivo | No hay apps configuradas para este dominio, o la petición nunca llega a la plataforma. | | El dominio redirige esta dirección | Algo delante del dominio reescribe /.well-known/. Aquí las plataformas no siguen redirecciones. | | Se sirve con el tipo equivocado | La respuesta es HTML, normalmente una página 404 de otro servicio. | | La respuesta llega comprimida | Un proxy comprime el archivo. Las comprobaciones de ambas plataformas pueden fallar con eso. | | No hay ninguna app declarada | El archivo es válido pero está vacío para esa plataforma: añade la app en el panel. |

Una vez los archivos están en su sitio, ambas plataformas los cachean en su propia CDN, así que una instalación nueva de la app puede tardar en recoger un cambio. Reinstalar la app es la forma fiable de forzar una relectura mientras pruebas.

Contexto del clic diferido tras la instalación

Un visitante sin tu app hace clic en un enlace, aterriza en la tienda, instala la app y la abre. En ese momento la app no sabe nada de dónde venía esa persona: la sesión del navegador y la app son dos mundos sin relación.

Activa Entregar el contexto del clic tras la instalación y la plataforma guarda una huella breve del dispositivo durante un par de horas: plataforma, versión mayor del sistema, idioma, país, tamaño de pantalla, zona horaria y operador de red. Ahí no hay dirección IP, ni identificador publicitario, ni nada que pueda rastrearse hasta una persona.

En el primer arranque, tu app le pregunta a la plataforma si hubo un clic:

curl -X POST https://go.brand.com/__dl/claim \
  -H 'content-type: application/json' \
  -d '{
    "platform": "ios",
    "os_version": "17.4",
    "language": "de",
    "timezone_offset": 120,
    "screen_width": 1170,
    "screen_height": 2532,
    "pixel_ratio": 3
  }'

Una coincidencia responde con el enlace original y sus etiquetas de campaña:

{
  "matched": true,
  "confidence": "high",
  "score": 100,
  "matched_on": ["screen", "timezone_offset", "language", "os_version"],
  "url": "myapp://product/42",
  "domain": "go.brand.com",
  "slug": "promo",
  "link_id": "lnk_...",
  "utm": { "utm_source": "newsletter" },
  "click_id": "...",
  "clicked_at": "2026-08-14T10:00:00.000Z"
}

Cuando no hay coincidencia responde {"matched": false}, y lo mismo hace una segunda petición para el mismo clic, porque el registro se entrega exactamente una vez.

Los límites, dichos claramente

• La correspondencia es probabilística. Dos dispositivos del mismo modelo, en la misma red, en la misma zona horaria y con el mismo idioma le resultan idénticos a este método. Por eso cada respuesta lleva un confidence y la lista de atributos con los que se decidió: high significa que el tamaño de pantalla y la zona horaria coincidieron sobre un clic reciente; low significa trátalo como una pista, no como un hecho.
• La ventana son horas, no días. La huella caduca dos horas después del clic, y la confianza baja pasados los primeros quince minutos.
• Envía la petición una sola vez, en el primer arranque. El registro lo consume la primera coincidencia con éxito; una segunda llamada no devuelve nada.
• Una redirección directa a la tienda, sin página intermedia, recoge menos. El tamaño de pantalla y la zona horaria solo los conoce la página que se ejecuta en el navegador, así que un enlace que va derecho a la tienda coincide únicamente por idioma y versión del sistema, y así lo dice, con una confianza menor.

Lista de comprobación de pruebas

1. Abre el enlace en un móvil con la app instalada: debería aterrizar dentro de la app.
2. Ábrelo sin la app: la página aparece un instante y se abre la tienda.
3. Ábrelo desde un feed social: comprueba que tu elección para navegadores dentro de apps coincide con lo que esperas.
4. Ábrelo en un navegador de escritorio: el destino en escritorio, o el destino principal.
5. Ejecuta Comprobar los archivos en el dominio y confirma que ambos archivos vuelven limpios.