Migrar de Firebase Dynamic Links a Elido

Firebase Dynamic Links se cerró el 25 de agosto de 2025. Todos los enlaces FDL devuelven ahora 404. Si tu app los usaba para atribución de instalaciones, deferred deep linking o enrutamiento post-instalación hacia una pantalla específica, esos flujos están rotos en producción ahora mismo. Branch.io parte de $199/mes para el nivel que reemplaza lo que FDL hacía gratis. El deep-link routing de Elido cubre los mismos patrones a una fracción del coste, con residencia de datos en la UE incluida.

Esta es la ruta más corta desde los enlaces FDL rotos hasta Universal Links y Android App Links funcionando.

Resumen

• Firebase Dynamic Links se cerró el 25 de agosto de 2025; todas las URLs *.page.link devuelven HTTP 404 desde esa fecha, según las preguntas frecuentes sobre la obsolescencia de Firebase Dynamic Links
• La atribución de instalaciones, el enrutamiento post-instalación y los deferred deep links de tu app están rotos si todavía no has migrado
• La migración es un cambio de DNS, dos archivos JSON (uno de Apple, uno de Google) y una reescritura de enlaces, no una reescritura del código
• El nivel de entrada de Branch.io para este caso de uso es $199/mes; Elido Pro cubre el mismo enrutamiento a un coste sustancialmente menor sin facturación por enlace
• No necesitas tocar el código de gestión de deep links existente en Swift o Kotlin: el traspaso de Universal Link/App Link a nivel de SO funciona igual independientemente de qué servicio aloja el enrutamiento

Lo que hacía Firebase Dynamic Links

FDL era la respuesta de Google a tres problemas que los enlaces HTTPS simples no pueden resolver por sí solos.

Deferred deep linking. Un usuario en un dispositivo sin tu app hace clic en un enlace. El SO abre la App Store o Play Store. El usuario instala la app. La app se abre en una pantalla de inicio genérica sin saber que el usuario intentaba acceder a un contenido específico. FDL almacenaba el destino previsto y lo transmitía tras la instalación: la app podía consultar el SDK de FDL en el primer lanzamiento y llevar al usuario a la pantalla correcta.

Atribución de instalaciones. Los enlaces FDL llevaban parámetros de campaña (utm_source, utm_medium, parámetros personalizados via ?st= y ?si=) que sobrevivían a la instalación. Este era el mecanismo que te permitía atribuir una instalación a una campaña de correo específica, un creativo de social de pago o un enlace de influencer sin necesidad de un MMP de terceros.

Enrutamiento consciente de la plataforma. Un enlace, tres destinos: los usuarios de iOS iban a la App Store (o directamente a la app si estaba instalada), los de Android a Play Store (o a la app) y los navegadores de escritorio recibían una URL de respaldo configurable. El enrutamiento ocurría en el servidor, en el edge de Google, no en el código de tu app.

Cuando FDL se cerró, las tres capacidades dejaron de funcionar al mismo tiempo. Si usabas el SDK de FDL en tu app, está llamando a un endpoint que ya no existe.

El equivalente de Elido

Elido replica los mismos tres comportamientos mediante la detección de plataforma en el edge de redirección y los mecanismos nativos de deep links del SO.

Detección de plataforma en el edge. Un enlace corto de Elido inspecciona la cabecera User-Agent en el momento de la redirección y enruta a distintos destinos según la plataforma: iOS a la URL de la App Store (o al universal link de la app), Android a la URL de Play Store (o al intent de la app), escritorio a tu respaldo web. Esto ocurre en menos de 5ms en el plano de redirección. Sin llamada al SDK, sin ida y vuelta a un servicio de atribución separado.

iOS Universal Links. Cuando tu app está instalada en el dispositivo, iOS intercepta el enlace HTTPS antes de que el navegador lo abra. Esto requiere servir un archivo Apple App Site Association (apple-app-site-association) desde la ruta well-known de tu dominio personalizado. Elido aloja este archivo en tu nombre cuando configuras un dominio personalizado con deep-link routing habilitado. El resultado es idéntico a lo que entregaba FDL: la app se abre directamente en la pantalla enlazada.

Android App Links. El mismo mecanismo en Android, con un formato de archivo diferente. El archivo assetlinks.json de Google reside en /.well-known/assetlinks.json en tu dominio. Elido genera y sirve este archivo cuando proporcionas el nombre de paquete de tu app y la huella digital SHA-256 del certificado de firma. Los Android App Links abren tu app directamente sin un interstitial del navegador.

Transmisión de deferred deep links. Para el caso de instalación pendiente (el usuario aún no tiene la app), Elido almacena el destino de deep-link previsto contra la URL corta y lo expone a través de un endpoint de consulta ligero. Tu app llama a este endpoint en el primer lanzamiento con la URL corta desde la que se instaló, recuperable desde el referrer de instalación en Android (INSTALL_REFERRER) y la API de atribución de la App Store en iOS, y recibe de vuelta la ruta de deep-link original. Sin SDK de FDL, sin protocolo de comunicación propietario. La guía de deep links cubre el contrato del endpoint de consulta.

La página de características completa está en /features/deep-links.

Migración paso a paso

Esto asume que tienes una cuenta en Elido en Pro o superior y un dominio personalizado que controlas. Reserva 30 minutos para una migración sencilla; añade margen si tu volumen de enlaces FDL es lo suficientemente grande como para requerir un script de reescritura masiva.

Paso 1: Añade tu dominio personalizado a Elido

En el panel de Elido, ve a Workspace -> Dominios personalizados -> Añadir dominio. Introduce el dominio de marca que quieres usar (por ejemplo, links.tuapp.com). Elido te mostrará un registro CNAME que debes crear.

En tu registrador de DNS, añade el CNAME:

links.tuapp.com.  CNAME  cname.elido.me.

Recomendación de TTL: bájalo a 300 segundos unas horas antes si actualmente está en 3600 o más. El aprovisionamiento de TLS es automático mediante TLS bajo demanda y se completa en pocos minutos tras la propagación del DNS.

Paso 2: Configura iOS Universal Links (archivo AASA)

En la configuración del dominio, habilita Deep link routing y proporciona:

• Tu identificador de bundle de iOS (por ejemplo, com.tuempresa.tuapp)
• Los patrones de ruta URL que deben abrir la app (por ejemplo, /l/* para todos los enlaces cortos, o rutas específicas)

Elido genera y sirve el archivo AASA en https://links.tuapp.com/.well-known/apple-app-site-association. Verifica que se resuelve correctamente antes de continuar:

curl -s https://links.tuapp.com/.well-known/apple-app-site-association | python3 -m json.tool

La respuesta debe incluir tu bundle ID en el array applinks.details. El CDN de iOS almacena en caché el archivo AASA y lo actualiza de forma programada; fuerza una actualización en las pruebas restableciendo la caché AASA del dispositivo en Desarrollador -> Restablecer en los Ajustes de iOS, o instalando la app desde cero.

El archivo Info.plist de tu app debe declarar el dominio asociado. Si ya lo hace para tu dominio FDL, añade el nuevo dominio junto a él durante el período de solapamiento:

<key>com.apple.developer.associated-domains</key>
<array>
  <string>applinks:links.tuapp.com</string>
  <!-- mantén el dominio FDL durante el solapamiento si es necesario -->
</array>

Paso 3: Configura Android App Links (assetlinks.json)

En el mismo panel de configuración de deep-link, proporciona:

• El nombre de paquete de tu app (por ejemplo, com.tuempresa.tuapp)
• La huella digital SHA-256 de tu certificado de firma de lanzamiento

Recupera la huella digital si no la tienes guardada:

keytool -list -v -keystore release.keystore -alias tu-alias | grep SHA256

Elido genera y sirve el archivo en https://links.tuapp.com/.well-known/assetlinks.json. Verifica:

curl -s https://links.tuapp.com/.well-known/assetlinks.json | python3 -m json.tool

El filtro de intents de tu AndroidManifest.xml ya debería estar configurado para App Links si usabas FDL con la función de auto-verificación del SDK de Android. Si no es así, añade el atributo android:autoVerify="true" a tu filtro de intents de deep-link y apúntalo al nuevo dominio.

Paso 4: Reescribe tus enlaces FDL existentes

Los enlaces FDL tienen la forma https://tuapp.page.link/SLUG o https://tuapp.page.link/?link=https%3A%2F%2F...&.... Ningún patrón seguirá funcionando: el dominio page.link está muerto.

Si generaste un número pequeño de enlaces FDL (menos de unos cientos), reescríbelos manualmente en el panel de Elido. Si generaste miles, lo habitual en campañas de correo o tiradas de impresión de códigos QR, usa la API de importación masiva de Elido:

curl -X POST https://api.elido.app/v1/links/bulk \
  -H "Authorization: Bearer $ELIDO_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "links": [
      {
        "slug": "bienvenida",
        "destination": "https://tuapp.com/bienvenida",
        "routing": {
          "ios": "https://apps.apple.com/app/id12345678",
          "android": "https://play.google.com/store/apps/details?id=com.tuempresa.tuapp",
          "fallback": "https://tuapp.com/bienvenida"
        }
      }
    ]
  }'

Para los enlaces ya impresos en materiales físicos (envases, carteles, tarjetas de visita), no puedes actualizar la URL en sí, pero si la URL impresa era un enlace FDL de dominio personalizado que apunta a un dominio que controlas, puedes reapuntar el CNAME de ese dominio a Elido y el enlace impreso volverá a funcionar con tu nueva configuración de enrutamiento.

Paso 5: Actualiza la consulta de deferred deep link del primer lanzamiento de tu app

Las apps FDL llaman a FirebaseDynamicLinks.dynamicLinks().handleUniversalLink(url) o al método equivalente del SDK en el primer lanzamiento. Elimina eso. Reemplázalo con una llamada al endpoint de deferred deep link de Elido:

// iOS - en el primer lanzamiento tras la instalación
let installURL = "https://links.tuapp.com/bienvenida" // recuperado de la atribución de StoreKit
let endpoint = URL(string: "https://api.elido.app/v1/deferred?url=\(installURL.addingPercentEncoding(withAllowedCharacters: .urlQueryAllowed)!)")!
URLSession.shared.dataTask(with: endpoint) { data, _, _ in
    guard let data, let result = try? JSONDecoder().decode(DeferredLink.self, from: data) else { return }
    DispatchQueue.main.async { self.navigate(to: result.deepLink) }
}.resume()

El equivalente en Android usa la API Play Install Referrer para recuperar la URL corta, luego llama al mismo endpoint. La guía de deep links tiene ejemplos de código completos para ambas plataformas.

Paso 6: Prueba de extremo a extremo

Antes de hacer el corte, prueba los tres casos:

1. App instalada, enlace tocado en el dispositivo - toca el enlace corto en Safari/Chrome, confirma que la app se abre directamente en la pantalla correcta sin interstitial del navegador.
2. App no instalada, enlace tocado - toca el enlace, confirma que enruta a la página correcta de la App Store/Play Store.
3. App instalada desde la tienda tras tocar el enlace - instala la app desde cero, confirma que se abre en la pantalla prevista en el primer lanzamiento (ruta de deferred deep link).

Prueba en un dispositivo físico para Universal Links. Los simuladores de iOS no ejecutan el traspaso AASA de forma fiable.

Casos especiales

Parámetros FDL que leías dentro de la app. Si tu app llamaba a DynamicLink.dynamicLink().url para leer parámetros de un enlace FDL después de abrirlo, esos parámetros ya no existen. Necesitas codificar la misma información en la URL de destino de tu enlace corto de Elido como parámetros de consulta y leerlos desde la URL de deep link que iOS o Android entrega a tu app. La codificación de parámetros es la misma (?screen=onboarding&ref=email_abril), simplemente movida del contenedor propietario link= de FDL a la URL de destino directamente.

Pérdida de atribución. La atribución de FDL era autónoma: Google almacenaba los parámetros de campaña y se los devolvía al SDK. Elido almacena datos de eventos de clic (marca de tiempo, plataforma, país, referrer) en nuestro almacén de analítica y los expone a través de la API de análisis, pero no es un MMP (socio de medición móvil). Si necesitas atribución de instalaciones probabilística o determinista a escala (análisis de cohortes, LTV por fuente de adquisición, integración con SKAdNetwork), necesitas un MMP (Adjust, AppsFlyer) o instrumentar el webhook de clics de Elido en tu propio pipeline de análisis. Para la mayoría de las apps indie y los equipos en etapas tempranas que usaban FDL puramente para "llevar al usuario a la pantalla correcta", los análisis de Elido son suficientes. Para los equipos de adquisición de pago que ejecutan atribución multicanal, consulta la siguiente sección.

URLs cortas FDL existentes ya embebidas en el binario de tu app. Si hardcodeaste URLs cortas de FDL en el código de tu app (cargas de notificaciones push generadas en el cliente, enlaces de referido generados desde la app), esas cadenas hacen referencia a un dominio muerto. Necesitas una actualización forzada de la app o un endpoint del lado del servidor que genere la nueva URL corta bajo demanda. No hay forma de redirigir page.link: Google cerró el dominio por completo.

URLs FDL largas con parámetros codificados. FDL admitía URLs de forma larga como https://tuapp.page.link/?link=https%3A%2F%2F...&ibi=com.tuapp&ifl=...&afl=.... Estos parámetros (ibi, ifl, afl, isi) son específicos de FDL. Mapéalos a los campos de enrutamiento de Elido: ifl (respaldo iOS) → routing.ios, afl (respaldo Android) → routing.android, ibi (bundle ID de iOS) ya está configurado a nivel de dominio en Elido. El parámetro link se convierte en tu URL de destino.

Residencia de datos en la UE. Si tu app opera en la UE y procesas datos de usuarios de la UE, los eventos de redirección, incluidas las direcciones IP y las cadenas User-Agent, son datos personales bajo el RGPD. FDL estaba alojado en la infraestructura global de Google con procesamiento en EE. UU. Elido está alojado en la región de la UE de forma predeterminada; los eventos de clic de la UE permanecen en la UE. La página de confianza y el resumen de cumplimiento cubren los detalles contractuales.

Cuándo realmente necesitas Branch.io

Elido es la elección correcta para la mayoría de las apps que usaban FDL para el enrutamiento de pantallas y la atribución básica de instalaciones. No es la elección correcta si dependes de:

Atribución probabilística para UA de pago. Branch se integra con redes publicitarias (Meta, Google, TikTok, Snap) mediante postbacks y puede atribuir instalaciones de forma probabilística cuando la huella digital determinista no está disponible, por ejemplo en iOS 14.5+ sin consentimiento ATT. Elido no hace atribución probabilística. Si tu equipo de crecimiento ejecuta UA de pago y necesita conciliar instalaciones con gasto publicitario a nivel de cohorte, Branch o un MMP (Adjust, AppsFlyer) es la herramienta adecuada para ese problema específico.

Identificación y coincidencia de dispositivos a nivel de SDK. El SDK de Branch recopila señales del dispositivo (resolución de pantalla, IP, idioma, zona horaria) para identificar un dispositivo durante el gap de instalación sin depender de un referrer de instalación. La coincidencia solo por referrer se degrada en entornos donde el referrer es eliminado: si tu tasa de aciertos de deferred deep link necesita superar el ~80%, el enfoque a nivel de SDK rinde mejor.

Integración profunda con redes publicitarias específicas. Branch tiene integraciones dedicadas con CAPI de Meta, el seguimiento de conversiones de Google y la API de eventos de TikTok que van más allá de lo que cubre el reenvío de conversiones del lado del servidor de Elido. Si tu stack de atribución está estrechamente acoplado a una de esas redes, evalúa la documentación de integración específica de Branch antes de cambiar.

La prueba práctica: si usabas FDL principalmente para enrutar a los usuarios a la pantalla correcta tras la instalación, y tus necesidades de atribución están cubiertas por parámetros UTM en tu herramienta de análisis, Elido reemplaza a FDL a menor coste. Si ejecutas marketing de resultados a escala y la precisión de la atribución impulsa las decisiones de presupuesto, esa es la propuesta de valor real de Branch y los $199/mes compran infraestructura real para ello.

Preguntas frecuentes

Mi app tiene enlaces cortos FDL en las cargas de notificaciones push. ¿Qué ocurre cuando los usuarios los tocan?

Los enlaces apuntan a page.link, que devuelve 404. El sistema operativo pasa el 404 al navegador o al manejador de universal links de tu app, lo que fallará. Necesitas actualizar tu servicio de notificaciones push para generar enlaces cortos de Elido en su lugar. Si generas las cargas push en el servidor (el enfoque correcto), esto es un cambio de una línea para llamar a la API de Elido en vez de a la API de FDL. Si las cargas se generan en el cliente desde plantillas predefinidas, necesitas una actualización de la app.

¿Necesito publicar una actualización de la app para completar la migración?

Para la consulta de deferred deep link (enrutamiento tras la instalación), sí: necesitas reemplazar la llamada al SDK de FDL con la llamada al endpoint de Elido, lo que requiere una actualización de la app. Para Universal Links y Android App Links hacia la app ya instalada, no se necesita actualización una vez que el DNS y los archivos AASA/assetlinks.json estén en su lugar, ya que el SO consulta estos archivos desde el servidor, no desde el binario de la app. La excepción: si tu Info.plist / AndroidManifest.xml todavía no declara tu nuevo dominio como dominio asociado, eso sí requiere una actualización.

¿Qué pasa con los clics en enlaces FDL antiguos después de completar la migración?

Si el enlace antiguo estaba en un dominio page.link: nada, ese dominio está muerto y esos enlaces no se pueden recuperar. Si usabas un dominio personalizado para FDL (menos habitual pero compatible), apunta el CNAME del dominio a Elido y configura reglas de enrutamiento equivalentes; las URLs antiguas volverán a resolverse.

¿Tiene Elido un SDK?

Elido no requiere un SDK para Universal Links ni App Links, ya que son mecanismos nativos del SO. Para el endpoint de consulta de deferred deep link, haces una llamada HTTPS estándar sin dependencia de SDK. Si quieres un cliente tipado, el SDK de Go de Elido, el SDK de TypeScript y el SDK de Python envuelven la API de deep links, pero no hay SDK para iOS/Android y no lo necesitas. Esto es por diseño: cuantos menos SDKs de terceros haya en una app en producción, mejor.

¿Cuánto tiempo tarda la propagación de AASA / assetlinks.json?

Una vez que el DNS se propaga (unos minutos o una hora dependiendo del TTL), los archivos AASA y assetlinks.json están disponibles inmediatamente desde el edge de Elido. iOS actualiza su copia en caché del archivo AASA al instalar la app y periódicamente después; el retraso que notarás en las pruebas es la obsolescencia de la caché de iOS, no la latencia de Elido. Para una prueba limpia, instala la app desde cero después de que el cambio DNS se haya propagado.

---

Si quieres conocer el conjunto completo de características de deep linking, la página /features/deep-links cubre la matriz de compatibilidad de plataformas y la profundidad de las reglas de enrutamiento. Para los detalles de residencia de datos en la UE relevantes para apps móviles que recogen datos de usuarios de la UE, el resumen de cumplimiento tiene el DPA y la lista de subprocesadores que tu equipo de privacidad te pedirá.

Relacionado en el blog

• Deep links sin SDK: cómo funcionan realmente Universal Links y App Links
• Residencia de datos en la UE para herramientas de marketing: lo que realmente pregunta tu DPO
• Smart links explicados: enrutamiento por dispositivo, geo, hora del día y referrer
• Migrar desde Bitly sin romper enlaces: una guía de modos de fallo