miji.beUn Deep Link es una técnica que lleva directamente desde un navegador web, el correo electrónico, las redes sociales, etc. a una pantalla concreta de una aplicación móvil. Mientras que un enlace normal abre la pantalla principal de la aplicación, un Deep Link puede especificar y abrir cualquier pantalla dentro de la aplicación, como la página de detalle de un producto, un artículo concreto o el perfil de un usuario. Las campañas que aprovechan los Deep Links pueden tener una tasa de conversión más alta que los enlaces normales. La razón de esta diferencia es que se reduce el número de pasos desde que el usuario toca el enlace hasta que llega al contenido. Con un enlace normal se necesitan 4 pasos, "abrir en el navegador → iniciar la aplicación → pantalla principal → buscar la pantalla deseada", mientras que con un Deep Link se completa en 1 paso, "tocar → pantalla deseada".
Hay 3 métodos principales de Deep Link. El primero es el esquema URI (Custom URL Scheme). Especifica el destino con un esquema propio de la aplicación, como "myapp://product/12345". Es un método que existe desde hace tiempo y es fácil de implementar, pero tiene el inconveniente de que se produce un error si la aplicación no está instalada. Además, si distintas aplicaciones registran el mismo esquema, se produce una colisión de esquemas y también existe el riesgo de que se abra una aplicación no prevista. El segundo es Universal Links de iOS. Es un método que Apple introdujo en iOS 9 y que asocia una URL HTTPS normal (ejemplo: https://example.com/product/12345) con una pantalla concreta de la aplicación. Incluye de forma estándar un comportamiento de respaldo: si la aplicación está instalada, se abre la aplicación, y si no lo está, la página se muestra en el navegador web. El tercero es App Links de Android. Es un método introducido en Android 6.0 que, igual que Universal Links, asocia una URL HTTPS con la aplicación.
Profundizamos en el trasfondo técnico de por qué Universal Links y App Links son mejores que los esquemas URI. Como los esquemas URI no garantizan la unicidad entre aplicaciones, existe el riesgo de que una aplicación maliciosa registre el mismo esquema y lo use para ataques de phishing. Universal Links y App Links tienen un mecanismo que verifica la propiedad del dominio HTTPS, por lo que es difícil que alguien que no sea el propietario del dominio se apodere de los enlaces. Esta verificación se logra porque el sistema operativo obtiene / verifica automáticamente un archivo de configuración (AASA o assetlinks.json) colocado en el servidor web. Al instalar la aplicación, iOS descarga el archivo AASA a través de la CDN de Apple y guarda en caché la asociación entre el dominio y la aplicación. Al verificar App Links, Android obtiene directamente el assetlinks.json del dominio y coteja el nombre del paquete y la huella SHA-256.
La combinación de URLs cortas y Deep Links es una técnica que se usa en marketing. Si conviertes una URL de Deep Link larga en una URL corta, puedes compartirla de forma concisa en publicaciones de redes sociales y correos electrónicos. Por ejemplo, si acortas el Deep Link a la página de un producto de una aplicación de comercio electrónico, "https://example.com/app/product/12345?utm_source=email&utm_campaign=summer-sale", a "brand.co/summer-item", el aspecto queda más limpio y cabe esperar una mejora de la tasa de clics. Los usuarios que llegan a través de Deep Links pueden permanecer más tiempo en la aplicación y avanzar hasta la compra. Se cree que detrás de esta diferencia está el hecho de que el Deep Link conecta directamente la "intención" del usuario con el "destino", lo que reduce los abandonos por el camino.
El Deep Link diferido (Deferred Deep Link) es una técnica avanzada que también sirve para los usuarios que no tienen instalada la aplicación. Si la aplicación no está instalada cuando el usuario hace clic en el enlace, primero se le dirige a App Store o Google Play y, una vez completada la instalación de la aplicación, se abre automáticamente la pantalla de destino original. Herramientas de atribución como Branch, AppsFlyer y Adjust ofrecen esta función. Técnicamente, se registra en el servidor la información del dispositivo en el momento del clic (dirección IP, User-Agent, resolución de pantalla, etc.). Al cotejar la misma información del dispositivo en el primer inicio de la aplicación, se vincula el clic anterior a la instalación con el inicio posterior a la instalación.
Explicamos un resumen de la implementación técnica. Para configurar Universal Links, tal como indica la documentación de Apple (a octubre de 2026), se coloca un archivo apple-app-site-association (AASA) en el directorio .well-known del servidor web y se describen el Bundle ID de la aplicación y las rutas de URL correspondientes en formato JSON. Ejemplo de archivo AASA: {"applinks":{"apps":[],"details":[{"appID":"TEAMID.com.example.app","paths":["/myapp/items/*","/myapp/posts/*"]}]}}. En el caso de App Links, se coloca un archivo assetlinks.json en el directorio .well-known y se describen el nombre del paquete de la aplicación y la huella SHA-256. En ambos casos HTTPS es obligatorio, y el archivo AASA debe servirse sin redirecciones.
En los Deep Links que pasan por un acortador de URL, hay que prestar atención al comportamiento de la redirección. Es un punto en el que la implementación suele tropezar. Con Universal Links y App Links, puede que no se produzca la transición a la aplicación si se pasa por una redirección HTTP (301/302). Esto se debe a que el sistema operativo busca el AASA/assetlinks.json en el dominio de origen de la redirección, y no en el de destino. Hay 2 formas de evitar este problema. La primera es configurar la compatibilidad con Deep Links en el lado del acortador de URL. Algunos servicios ofrecen una función de proxy para el archivo AASA. La segunda es devolver una página HTML en lugar de una redirección 302 en el lado del servidor y hacer la transición con window.location de JavaScript. En este último caso, el sistema operativo puede consultar correctamente el archivo AASA del dominio de destino. Sin embargo, como la redirección JavaScript implica cargar una página, existe la contrapartida de que la transición es más lenta en comparación con la redirección del lado del servidor.
Como inconvenientes, la implementación y la operación de los Deep Links presentan varios retos. En primer lugar, hay que dar soporte a especificaciones técnicas distintas en iOS y Android, lo que aumenta el coste de desarrollo. En segundo lugar, las especificaciones pueden cambiar con las actualizaciones de versión del sistema operativo, por lo que se requiere un mantenimiento continuo. A partir de iOS 14, la entrega de los archivos AASA pasó a hacerse a través de la CDN de Apple, y las actualizaciones pueden tardar en llegar a los dispositivos. En tercer lugar, hay que diseñar adecuadamente el comportamiento de respaldo para los casos en que el usuario ha desinstalado la aplicación o tiene una versión antigua. En cuarto lugar, con el refuerzo de las normativas de privacidad (como el marco ATT de iOS), la precisión de atribución del Deep Link diferido tiende a disminuir. Según la documentación de Apple (a octubre de 2026), las aplicaciones no pueden hacer seguimiento si no obtienen el permiso del usuario mediante ATT, y el seguimiento a nivel de usuario se ha vuelto difícil. En quinto lugar, construir el entorno de pruebas es complejo. Las pruebas en dispositivos reales son imprescindibles para comprobar el funcionamiento de los Deep Links, y en el simulador es difícil reproducir el comportamiento de Universal Links.
El Deep Link es una técnica útil para mejorar la experiencia de usuario de las aplicaciones móviles y la tasa de conversión de las campañas de marketing. Se cree que, al combinarlo con URLs cortas, la transición a la aplicación también se vuelve más fluida, a la vez que se garantiza la facilidad de gestión y de seguimiento de los enlaces.