Enlace profundo

Cuando hacemos enlaces profundos en la web lo que hacemos es enlazar a un contenido que no es el de la página de inicio del sitio web. Cuando el usuario le hace clic se le dirige directamente al contenido que quiere ver, y no tiene que navegar dentro de la web para acceder a él.[2]

El enlace siguiente es un ejemplo de un enlace profundo: https://en.wikipedia.org/w/index.php?title=Special:Contributions&limit=13&contribs=user&target=Atlgirl052005 La URL contiene toda la información necesaria para llevar hasta un ítem particular de la Wikipedia en inglés, las 13 últimas contribuciones del usuario Atlgirl052005.

Desde el punto de vista tecnológico no hay ninguna distinción dentro de los enlaces web entre lo enlaces profundos y el resto. La posibilidad del llamado "deep" linking está presente en la tecnología Web del HTTP y del URL por defecto. Aunque un sitio puede intentar restringir tales enlaces, hacerlo requiere un esfuerzo extra. De acuerdo con el Technical Architecture Group del World Wide Web Consortium, "cualquier tentativa de prohibir la práctica del deep linking se basa en un malentendido sobre la tecnología, y amenaza con minar el funcionamiento de la Web como conjunto". Una forma de prevenir el deep linking es configurar el servidor web para comprobar la URL correspondiente usando un Rewrite engine.[3]

Sin embargo, algunas páginas web comerciales critican que otras páginas hagan deep links a su contenido ya que eso supone saltarse los anuncios que aparecen en su página principal o incluso hacer que los contenidos (incrustados en un marco o similar) parezcan ser del "enlazante" y no del enlazado. Eso ha dado lugar a que existan demandas judiciales por el tema

Los enlaces profundos en apps (en inglés app deep links) son enlaces que llevan al usuario a un lugar específico de una app. Esos enlaces no sólo abren la app, sino que llevan al usuario a un lugar concreto de la misma.[1]

La existencia de enlaces profundos a apps ha producido la necesidad de crear la indexación de apps en los buscadores. Se han creado distintas técnicas para indicar al buscador que tipo de contenidos tiene cierto enlace profunda a una app (XML Sitemap, Schema.org , <link rel="alternate" android-app://...).[4]

Podemos identificar tres tipos de enlaces profundos según como se comportan:[1]

• Tradicionales o por defecto (del inglés Default deep links). Estos enlaces sólo funcionan si la app está instalada. En caso contrario, el enlace no funciona y mostrará un error o una página alternativa.
• Condicionales o diferidos (del inglés 'Deferred deep links'). Si tienes la app instalada, este tipo de enlace te lleva al lugar concreto de la app. Pero si no la tienes instalada te redirige a la store para que puedas descargarla (App Store o Play Store) o a una URL con más información. Si descargas la app, te muestra el contenido "diferido" inmediatamente después del primer lanzamiento.[5] Para conseguir este tipo de funcionalidades se pueden usar aplicaciones de terceros como Branch o Firebase.[6]
• Contextuales. Es como un enlace diferido pero que además se puede meter información adicional como por ejemplo cuándo y dónde se ha presionado el enlace o quién compartió ese enlace. Esta información permitirá a los creadores de apps añadir contenidos y páginas de bienvenida o contenidos personalizados. De esta forma se beneficia a los usuarios porque las apps pueden proveer mejores experiencias y una información más relevante.

La forma original de proporcionar enlaces en apps fue crear enlaces con URL's de la forma <nombre_app>://path/to/content?query_string. Por ejemplo twitter://timeline, eBay://item/view?id=360703170135 y spotify://playlist/30345.[1]

Esta forma es fácil de configurar pero tiene la desventaja de que el dispositivo de un usuario solo reconoce estas URI si la aplicación correspondiente ya está instalada, y no hay una opción de reserva elegante por defecto. La única forma alternativa implica el uso de un enlace web tradicional a una página que contenga una redirección de JavaScript a un esquema de URI personalizado, que es ejecutado por el navegador web para iniciar la aplicación. Si el intento de redireccionamiento falla porque la aplicación no está instalada, el JavaScript lleva al usuario a la App Store o Play Store.

Introducidos por Apple para plataformas iOS en iOS 9.0 como una solución a la falta de funcionalidad de respaldo elegante en los enlaces profundos del esquema URI personalizado. Son enlaces web (HTTP/HTTPS) que apuntan tanto a la web como a una parte de contenido dentro de la app. Al abrir un enlace iOS busca si tenemos la app instalada. De ser así el contenido se abre dentro de la app. Si no la tenemos abrirá la URL en el navegador. Esta URL puede ser la versión web del contenido o una simple redirección al redirect to the App Store.[7] Para la configuración del sistema se mete en el servidor web un fichero de configuración de nombre “apple-app-site-association".[8]

Introducidos en 2005 para Android 6.0.[8] Son enlaces web (HTTP/HTTPS) que apuntan a una pieza de contenido dentro de la app. Al abrir un enlace Android busca si tenemos la app instalada. De ser así el contenido se abre dentro de la app. Si no la tenemos abrirá la versión web del contenido a través de navegador.[7] La configuración se realiza en el servidor web, en el fichero “https:// YOUR_DOMAIN /.well-known/assetlinks.json”. En él hay entradas que certifican que la aplicación se asocia con cierto patrón de URL. El sistema operativo del móvil se encargará de implementar dicha asociación.[8][6]

En 2014 Facebook creó los Facebook App Links como un estándar abierto para resolver las limitaciones de los esquemas URI personalizados. Este sistema está formado por dos componentes:

• Un conjunto de propiedades para etiquetas meta (al:ios:url, al:ios:app_store_id, ...) que se agregan a la página web destino de un enlace web estándar. Estas etiquetas especifican la ubicación del esquema URI personalizado del contenido correspondiente dentro de la aplicación nativa, y el comportamiento que debería ocurrir si la aplicación no está instalada.
• Un motor de enrutamiento para usar dentro de aplicaciones que admiten la apertura de enlaces. Este motor verifica la URL de destino para las etiquetas de enlaces de aplicaciones antes de abrirla, y luego inicia la aplicación correspondiente o ejecuta el comportamiento de reserva especificado.

Los metas han sido ampliamente implementados en las páginas web, sin embargo las únicas implementaciones importantes del motor de enrutamiento fueron hechas en las apps de Facebook y Messenger.

Facebook hoy día prefiere mantener los usuarios dentro de su plataforma y ha eliminado el motor de enrutamiento App Links de todas partes, excepto la aplicación principal de Android. También bloquea los enlaces universales de iOS.

Han aparecido distintas plataformas para implementar enlaces profundos en apps. Los más importantes son Branch, EMMA[9] y el módulo de enlaces dinámicos de Firebase (Firebase Dynamic Link), aunque recientemente han anunciado su retirada[10]. Ambas plataformas requieren la instalación y configuración en las apps de su SDK. Esta SDK permiten crear enlaces multiplataforma que funcionan en los distintos dispositivos (incluyendo escritorio). Ambas lanzan la app si está instalada, y hacen que vayan al usuario directamente al contenido. Si la app no está instalada ambas redirigen al App/Play Store y después llevan a la aplicación al contenido especificado (enlace profundo diferido).[11] Otro ejemplo de este tipo de plataformas es GetSocial[12].