← Volver al blog
Guía

Deferred deep linking sin SDK: cómo funciona realmente por dentro

Puedes llevar el contexto de un enlace a través de una instalación sin incrustar un SDK de atribución. Esto es lo que sobrevive a la frontera de la tienda en Android e iOS, lo que se rompe y el coste en privacidad de cada alternativa.

14 de agosto de 202611 min de lectura

El contexto muere en la frontera de la tienda

Alguien toca un enlace a /product/42. La app no está instalada, así que tu redirección lo envía a la tienda. Instala, abre la app y aterriza en una pantalla de inicio genérica. La petición HTTP que llevaba su intención terminó en la ficha de la tienda: la app recién instalada arranca sin URL, sin cookie, sin referrer. Nada del clic sobrevivió.

Llevar ese contexto a través de la instalación es el deferred deep linking, y la respuesta estándar es "incrusta un SDK de MMP". Muchos equipos no quieren esa respuesta — el hilo 772811 de los Apple Developer Forums es uno de tantos preguntando cómo hacerlo sin SDK de terceros — y la audiencia creció en agosto de 2026, cuando AppsFlyer sacó el deferred deep linking de su plan gratuito. ¿Se puede construir? En Android, sí, de forma limpia y oficial. En iOS, más o menos, con soluciones que tienen costes reales.

Una nota de alcance: qué es el deferred deep linking y cuándo compensa lo cubrimos en otro artículo. Este post trata solo de la fontanería: qué transporte puede pasar un token a través de una instalación y cuánto puedes fiarte de cada uno.

Qué sobrevive a la instalación y qué no

Con install referrerEnlace de tienda simplecontexto perdidoToqueToqueTiendaTiendaInstalaciónInstalaciónPrimera aperturaPrimera apertura
Carril superior: un token viaja en el parámetro referrer de Play y sale al otro lado en la primera apertura. Carril inferior: un enlace de tienda simple, donde el contexto del clic desaparece al cargar la ficha.

Android: la Install Referrer API es la buena noticia honesta

Google Play lo resuelve de forma nativa. La URL de la tienda acepta un parámetro referrer, Play guarda esa cadena junto a la instalación y la app la lee literal tras el primer arranque mediante la Install Referrer API. Ese es todo el mecanismo: sin fingerprinting, sin portapapeles, sin adivinar.

No es exactamente "cero código": leer el valor requiere la librería com.android.installreferrer, un artefacto pequeño que habla localmente con la app de Play Store. No hace llamadas de red a nadie ni es un SDK de analítica; no añade nada a tus declaraciones de privacidad más allá de lo que hagas con la cadena.

Qué poner en el parámetro es cosa tuya: un ID de enlace, una campaña, un destino codificado. Mantenlo corto y URL-encoded — el referrer en play.google.com/store/apps/details?id=com.example&referrer=tok_8f2 vuelve exactamente como se envió.

El ciclo completo, de extremo a extremo

  1. 1Al tocar el enlace, tu redirección añade referrer=<token> a la URL de Play; el token apunta al contexto del clic guardado en tu servidor.
  2. 2En el primer arranque, la app conecta un InstallReferrerClient y lee la cadena installReferrer.
  3. 3La app intercambia el token en tu API por el contexto guardado — ruta del deep link, campaña — y enruta al usuario.
  4. 4Tu servidor marca el token como consumido. La cadena persiste en el dispositivo, así que el uso único debe vivir en el servidor.

Los límites son estrechos y predecibles: la API solo cubre instalaciones hechas a través de Google Play. Sideloads, Huawei AppGallery y otras tiendas no llevan referrer de Play, y el valor debe leerse una vez poco después del primer arranque.

iOS: sin equivalente oficial, tres alternativas ordenadas

Apple no ofrece nada parecido al Install Referrer. Una ficha del App Store no transporta parámetros arbitrarios a través de la instalación; todo lo siguiente es un rodeo construido sobre esa ausencia. De menos malo a más nicho:

Paso por portapapeles

01 · fiabilidad media, con permiso

Tu página de clic escribe un token corto en el portapapeles — tras un toque de botón, porque Safari exige gesto de usuario para copiar — y reenvía al App Store. En la primera apertura, la app lee el portapapeles, encuentra el token y lo intercambia con tu servidor.

El problema llegó con iOS 16: leer el portapapeles dispara el aviso de pegado del sistema. El usuario ve "¿Permitir pegar desde Safari?" en la primera pantalla de una app instalada hace treinta segundos, y muchos lo rechazan. El rechazo es pérdida silenciosa: no puedes distinguirlo de "no había token". UIPasteboard.detectPatterns comprueba patrones sin preguntar, pero no lee el valor. Además, el portapapeles puede sobrescribirse entre el toque y la apertura. Funciona con frecuencia medible, pero tiene una segunda cara visible.

Matching probabilístico

02 · fiabilidad baja–media, hostil a la privacidad

Al hacer clic, el servidor registra IP, modelo de dispositivo y versión de OS del user agent, y un timestamp. En la primera apertura la app llama a tu endpoint, que busca un clic con señales coincidentes en una ventana corta, normalmente menos de media hora. No viaja ningún token: la coincidencia es una conjetura.

Lo describimos porque los vendedores lo venden, no porque debas construirlo. Las señales se degradan: iCloud Private Relay enmascara IPs, el CGNAT junta miles de usuarios tras una dirección y los modelos de dispositivo son categorías gruesas. Apple desaconseja explícitamente el fingerprinting y, en la era del privacy manifest, recoger estas señales es algo que App Review puede pedirte justificar. La precisión cae cada año y los falsos positivos llevan a usuarios reales a la pantalla equivocada.

App Clips y otras vías nicho

03 · fiable pero estrecho

Un App Clip invocado desde tu enlace recibe la URL completa y puede pasar el contexto a la app completa mediante un contenedor compartido tras la instalación. En su nicho es la vía más fiable de iOS, pero exige construir y mantener un App Clip y solo encaja en flujos donde una experiencia instantánea tiene sentido. Las shared web credentials resuelven la continuidad de sesión, no el contexto general del enlace. Vale la pena conocerlo; rara vez es la respuesta.

El patrón de diseño que vale para cualquier mecanismo

Sea cual sea el transporte del token — cadena referrer, portapapeles o un ID de coincidencia probabilística — la arquitectura de servidor es la misma, y acertarla importa más que el transporte. No metas el deep link entero en el canal: guarda el contexto en tu servidor y mueve solo una clave de vida corta.

01

Guarda el contexto bajo un token aleatorio

Al hacer clic, escribe {deep_link, campaña, timestamp} bajo un token corto y aleatorio, y pon solo el token en el transporte. Las cargas quedan pequeñas, los datos de campaña no acaban en portapapeles ni en logs, y puedes cambiar qué significa "contexto" sin tocar el cliente.

02

Expira agresivamente

Un TTL de 30 a 60 minutos cubre el viaje real de toque a instalación. Una ruta diferida resuelta una semana después del clic se equivoca más veces de las que acierta.

03

Impón el uso único

Consume el token en el primer intercambio. Las cadenas referrer persisten y el portapapeles puede leerse dos veces; sin uso único, una reinstalación o un segundo dispositivo puede reproducir el contexto de otra persona.

04

Falla hacia el defecto, no hacia una conjetura

Sin token, token expirado o permiso rechazado: lleva al usuario a la pantalla de inicio normal. Una primera apertura genérica decepciona un poco; acabar en el carrito de otro usuario es un ticket de soporte.

Fiabilidad, dicha con honestidad

Cifras aproximadas de equipos que ejecutan esto en producción. Tu mezcla de fuentes, retraso de instalación y versión de iOS de tu audiencia mueven cada número.

MecanismoPlataformaFiabilidadNotas
Play Install ReferrerAndroidAltaAPI oficial, sobrevive a instalaciones tardías, sin aviso al usuario. Solo instalaciones de Play.
Token en portapapelesiOSMediaCondicionada por el aviso de pegado de iOS 16+; los rechazos son silenciosos; el portapapeles es volátil.
Matching probabilísticoiOSBaja–mediaIP + modelo + ventana temporal. Se degrada con Private Relay y CGNAT; Apple lo desaconseja.
Relevo por App ClipiOSAlta, estrechaDeterminista, pero solo para flujos que justifiquen construir un App Clip.

Qué significa esto para tu stack

Si tu necesidad es solo Android, necesitas muy poco: un enlace que añada el parámetro referrer, la pequeña librería y un endpoint de intercambio de tokens. Es una tarde de trabajo y es genuinamente libre de SDK en el sentido que importa: sin código de terceros observando a tus usuarios.

iOS es donde las soluciones gestionadas se ganan el sueldo, porque allí los rodeos son el producto: mantener la infraestructura de matching, diseñar alrededor del aviso de pegado y seguir cada versión de OS que mueve el suelo. Por eso se cotiza como infraestructura: Appy ofrece deferred deep linking en el nivel Enterprise, donde ese mantenimiento es problema del proveedor.

Sé honesto sobre qué problema tienes. Si lo que necesitas es que "los usuarios que ya tienen la app aterricen en la pantalla correcta", eso es deep linking estándar, sin frontera de instalación. El shim de deep links de Appy cubre ese caso en el plan Pro por 9,99 $/mes, con fallback a tienda y sin SDK. Mide cuánta parte de tu embudo es realmente instalación nueva con contexto antes de comprar la maquinaria pesada.

Preguntas frecuentes

¿Funciona el Install Referrer desde un escaneo de QR?

Sí, siempre que el QR se resuelva a través de un enlace que añada el parámetro referrer a la URL de Play. Al mecanismo no le importa cómo empezó el clic — escaneo, toque o NFC — solo que la URL de la tienda llevara el referrer al abrirse Play. Un QR que apunta a una URL de Play desnuda no lleva nada.

¿Por qué se rompió de repente mi enfoque de token en portapapeles?

Casi seguro, el aviso de pegado de iOS. Desde iOS 16, la primera lectura del portapapeles dispara un diálogo de permiso y una parte significativa de usuarios lo rechaza. Tu código no empeoró; tu lectura ahora tiene un humano en el circuito. Comprueba si tu tasa de tokens encontrados bajó en vez de irse a cero: esa es la firma.

¿Está permitido el matching por fingerprint en iOS?

Es zona gris y el terreno se mueve en contra. Las directrices de Apple prohíben el fingerprinting para tracking, los privacy manifests exigen declarar las señales que recoges y App Review ha rechazado apps por ello. Algunos vendedores lo siguen ofreciendo. Si lo construyes tú, el riesgo es tuyo, y asume que la precisión seguirá cayendo.

¿Necesito deferred deep linking siquiera?

Solo si la pantalla de aterrizaje tras la instalación cambia materialmente tu embudo. Si la mayoría de instalaciones viene de campañas genéricas sin destino concreto, un buen onboarding rinde más. Mide primero: cuenta los clics con destino real de deep link y app no instalada. Si el número es pequeño, invierte el esfuerzo en otra parte.

Seguir explorando

Guía
May 14, 2026
9 min de lectura

Deferred deep linking: cómo funciona y cuándo usarlo

Conserva la intención original del enlace tras la instalación para que los nuevos usuarios aterricen en la pantalla correcta y no en la home por defecto.

deferred deep linking
install referrer
deep linking
mobile attribution
Leer artículo
Tutorial
Oct 10, 2025
12 min de lectura

Guía completa de Universal Links para iOS y Android

Guía completa sobre universal links, deep links y app links, con implementación y buenas prácticas para marketing móvil.

universal links
deep linking
ios
android
Leer artículo
Guía
Aug 13, 2026
10 min de lectura

Link Tracking Protection en iOS 26: ¿qué parámetros de URL sobreviven?

Safari elimina click IDs como gclid y fbclid mientras los UTM pasan. Qué significa para la medición de instalaciones y cómo los enlaces first-party mantienen la atribución.

ios 26
link tracking protection
utm parameters
attribution
Leer artículo

¿Buscas otra cosa? Explora todos los temas en el blog.

Enruta las instalaciones que ya ganaste

Deep links estándar con fallback a tienda en Pro y deferred deep linking en Enterprise, ambos sin meter un SDK en tu app.

Empieza con Appy