ios - significa - los atributos alt

Enlace profundo diferido en iOS

Question

Estamos tratando de implementar enlaces profundos diferidos en una de nuestras aplicaciones de iOS para alentar a los usuarios a invitar a sus amigos a usar la aplicación y recompensar a los usuarios según la cantidad de instalaciones que se realicen desde su enlace de referencia. Básicamente similar al producto de TapStream .

Considera este ejemplo:

Por lo tanto, UserA comparte su enlace, "ourappURL.com/refer?id=userA", en cualquier red que desee. El usuario B hace clic en ese enlace, que los llevará a Safari y luego los enviará a la página de la App Store donde el usuario B descargará la aplicación.

Cuando el Usuario B abre la aplicación, la aplicación verifica en qué ID de referencia entraron (si corresponde). En este ejemplo, la ID de referencia sería "userA" ya que esa es la identificación que estaba en el enlace de referencia. La aplicación luego envía esto a nuestros servidores y otorgamos UserA con un crédito de referencia.

Estoy tratando de romper este problema en sus partes centrales. Creo que la primera parte es obtener la página web del enlace de referencia del usuario para guardar la ID de referencia en algún lugar donde la aplicación pueda acceder. Pero no estoy seguro de que esto sea posible debido a la naturaleza de espacio aislado de iOS.

Sé que esto es fundamentalmente posible porque muchos proveedores de anuncios ofrecen la capacidad de realizar un seguimiento de las instalaciones desde una campaña publicitaria (consulte el seguimiento de aplicaciones móviles, por ejemplo).

Answer 1

Hay una buena solución aquí: http://blogs.innovationm.com/deferred-deep-linking-in-ios-with-universal-link/

Flujo de trabajo básico:

• El usuario selecciona el enlace de dominio en la web.
• El enlace establece la ID de referencia en la cookie.
• Usuario redirigido a la tienda de aplicaciones.
• Al iniciar la aplicación, carga la página de referencia en SFSafariViewController.
• La página de referencias comprueba si hay cookies y, si existen, establece un enlace profundo a la aplicación con la ID de referencia.

Answer 2

Hemos utilizado con éxito el portapapeles (NSPasteboard) para lograr esto: la página web que procesa el redireccionamiento a la tienda de aplicaciones pega en el portapapeles del dispositivo móvil antes de permitir que el usuario descargue la aplicación. Una vez que la aplicación está instalada, usa NSPasteboard en el primer lanzamiento para verificar si hay una cadena adecuadamente codificada. Esta cadena puede contener el texto de interés o, de forma más segura, un token utilizado para obtener datos interesantes del back-end. En el Objetivo C:

UIPasteboard *pasteboard = [UIPasteboard generalPasteboard];
NSString *pasteboardString = pasteboard.string;

El portapapeles se puede borrar una vez que la aplicación haya terminado, para evitar repetir la misma acción.

Answer 3

Mi respuesta de HERE

Apple ya no es compatible con Deep Links. Ahora se llama Universal Links y funciona de manera diferente.

Fuente

Ahora que Apple ya no es compatible con los esquemas de URI para enlaces profundos, los desarrolladores deben implementar los enlaces universales para realizar un enlace profundo en iOS. Si ya está utilizando esquemas de URI, consulte nuestro blog sobre la transición a enlaces universales.

De: HERE

Y HERE hay otro artículo sobre enlaces universales y lo que son.

Answer 4

También hemos intentado hacer esto nosotros mismos y trataré de desglosar los diferentes pasos aquí.

Volviendo a su ejemplo, tiene razón acerca de "recordar" la identificación del dispositivo y todos los datos relevantes "id = userA". También tiene razón acerca de la "naturaleza de espacio aislado de iOS", que supongo que significa que una página web no puede almacenar información fuera de la aplicación del navegador (Safari) y las aplicaciones (su aplicación) no pueden acceder a la información almacenada por otras aplicaciones ( Safari).

Nuestra solución a esto es almacenar este dispositivo en el par clave-valor de datos en un entorno que sea accesible tanto por el navegador como por su aplicación, es decir, su servidor backend.

El siguiente desafío, que sigue siendo el mayor desafío, es cómo identificar de forma única este dispositivo a partir de la información que se puede obtener del navegador. Los JavaScript ocultos en los navegadores, a diferencia de las aplicaciones nativas, no tienen acceso a los IDFA que podrían usarse para identificar de manera única un dispositivo iOS. Para superar esto, uno puede imaginar el uso de una combinación de información común que está disponible tanto para la aplicación del navegador como para su aplicación nativa, es decir, tipo de sistema operativo, IP pública, tamaño de pantalla, etc. Tenga en cuenta una clave compuesta de estos campos de datos no garantizan la exclusividad (imagine dos iPhone 6 visitando esta página web a través del mismo enrutador). Por lo tanto, su servidor backend (suponiendo que lo esté usando para almacenar este par clave-valor), querrá tener una estrategia sobre cómo manejar colisiones en claves, es decir, la segunda clave borra la primera clave o permite que exista colisión al tener una cola de valores para una sola clave. Esto realmente depende de cómo planee usar esta tecnología.

El último paso es formar esta clave compuesta en su aplicación utilizando exactamente los mismos campos que utilizó anteriormente en el navegador para realizar una "búsqueda" en su servidor back-end para recuperar el valor previamente almacenado.

Aquí hay un resumen de los pasos:

1. El usuario 1 invita al usuario 2 enviando el siguiente enlace a 2: example.com?inviter=1
2. Usuario 2 visita la página web P
3. P construye y envía el siguiente par clave-valor a su servidor S iOS | 55.55.55.55 | 750 × 1334 -> inviter_id = 1
4. El usuario 2 va a la tienda de aplicaciones y descarga su aplicación A
5. Después de 2 primeros lanzamientos, A, A se pone en contacto con S con la misma clave (suponiendo que la IP no haya cambiado).
6. S encuentra el valor inviter_id = 1 usando esta clave pasada y, digamos, recompensa al Usuario 1 cinco puntos por invitar a 2.

¡Espero que esto ayude!

Editar 04/24:

Como Derrick lo mencionó en los comentarios, creo que aprovecharía esta oportunidad para terminar nuestra historia aquí.

Volviendo al comienzo de mi respuesta, donde mencioné que hemos intentado hacer esto nosotros mismos. Teníamos un prototipo funcional basado en nuestra arquitectura de sistema actual (que de todos modos no está optimizado o destinado a optimizarse para almacenar y analizar datos de enlaces profundos como este), finalmente decidimos no asignar ningún recurso de ingeniería adicional a este proyecto.

Debido a la naturaleza heurística de este proceso de coincidencia, encontramos que este proyecto necesita depuración, ajuste y optimización constante para un ROI decreciente. Más importante aún, hemos encontrado otras compañías que son más especializadas y hacen un trabajo mucho mejor que nosotros.

Han pasado probablemente 6 meses desde que dejamos de usar nuestro sistema interno y no nos hemos arrepentido de haber tomado tal decisión.

Durante este proceso, hemos trabajado con varios proveedores, Appsflyer, Adjust, TapStream y finalmente hemos terminado con Branch Metrics https://branch.io .

Si usted debe hacer bricolaje o trabajar con otra compañía de nuevo depende de su objetivo específico. Finalmente decidimos quedarnos con Branch, no solo porque los otros proveedores cobraron entre $ 500 y miles de dólares por mes, mientras que Branch es completamente gratuito, sino que el nivel de asistencia que brindan es simplemente sin paralelo.