Selecciona en qué clase iniciar el SDK

Selecciona si deseas iniciar el SDK en la clase Application global o en la clase Activity:

• Iniciar el SDK en la clase Application global: generalmente, inicializar el SDK en la clase/subclase Application global es una buena práctica porque la clase Application se carga e inicializa antes de que se muestre cualquier interfaz de usuario de la aplicación. Esto garantiza que el SDK pueda iniciarse en cualquier escenario, incluidos los enlaces profundos.
• Iniciar el SDK en una clase Activity (inicio diferido) para permitir a los usuarios optar por compartir datos. Esto se debe a que obtener el consentimiento del usuario requiere una interfaz de usuario (UI) renderizada en una clase Activity.

Selecciona el escenario de inclusión/exclusión opcional

Selecciona un escenario de exclusión opcional que describa cómo llamar a start de una manera que cumpla con las regulaciones de privacidad como el RGPD y el CCPA. Por ejemplo, selecciona entre la exclusión opcional en el escenario de instalación, el escenario de exclusión opcional una sola vez o el escenario de prevención del intercambio de datos con terceros.

Para obtener más información sobre los escenarios de exclusión opcional disponibles, incluidas las muestras de código, consulta Escenarios de inclusión y exclusión opcional.

Instrucciones para desarrolladores de Android

• Informa al desarrollador de tu decisión sobre lo siguiente:
  • ¿En qué clase - Application o Activity - debe iniciarse el SDK?
  • ¿Qué escenario de inclusión/exclusión opcional se debe usar?
• Envía a tu desarrollador los siguientes enlaces de referencia:
  • Cómo realizar el inicio diferido
  • Escenarios comunes de inclusión y exclusión opcional
  • Muestras de código de exclusión opcional

Se crea automáticamente un ID de AppsFlyer para cada nueva instalación de aplicación. No se requiere ninguna acción por parte del marketer.

Puedes utilizar este identificador para realizar las siguientes acciones:

• Enviar eventos in-app de servidor a servidor.
• Vincular el ID de AppsFlyer con los registros de usuarios en tus sistemas de backend.
• Descargar el reporte de raw data de eventos in-app y usa appsflyer_id para analizar el comportamiento y las trayectorias de los usuarios.

Configura tu propio ID de usuario de cliente (CUID) en el SDK de AppsFlyer para hacer referencia cruzada al ID único de tu sistema de Business Intelligence con el ID de AppsFlyer y otros identificadores. El CUID está disponible en los reportes de raw data de AppsFlyer. También puedes usarlo en las API de postback para realizar referencias cruzadas con tus ID internos. 

Consulta las instrucciones para desarrolladores para implementar el CUID.

Referente de instalación de Google Play

La API de referente de instalación de Google Play mejora la precisión de la atribución, protege contra las instalaciones fraudulentas y permite la recuperación segura de los datos de referencia de Google Play (por ejemplo, la versión de la aplicación en el momento en que se instaló por primera vez). 

Recomendamos que proporciones a tu desarrollador instrucciones para agregar la API del referente de instalación de Google Play. 

GAID

A partir del SDK V4.8.0, AppsFlyer recopila automáticamente este identificador de dispositivo.

Con AppsFlyer, puedes atribuir las instalaciones que se originan en tiendas de aplicaciones de terceros, como Amazon, Opera, GetJar, Baidu y Huawei. Esto te permite promocionar tus aplicaciones y llegar a audiencias más grandes en mercados donde Google Play Store no está disponible.

AppsFlyer admite la atribución en el contexto de las tiendas de aplicaciones de terceros de la siguiente manera:

• IMEI o ID de Android: el SDK no recopila automáticamente el IMEI o el ID de Android. Sin embargo, si es necesario recopilar estos identificadores (por ejemplo, para aplicaciones en el mercado nacional chino), tu desarrollador puede implementar uno de los siguientes tipos de recopilación:
  • Recopilación manual: la aplicación transmite el IMEI o el ID de Android al SDK (mediante la API setImeiData o setAndroidIdData). El SDK envía los datos a los servidores de AppsFlyer. 
  • Optar por la recopilación del ID de dispositivo: obliga al SDK a recopilar el IMEI o el ID de Android. 
• OAID: atribuye las instalaciones de tiendas de aplicaciones Android de terceros. Para obtener más información, consulta la guía para implementar el OAID.
• Referentes de instalación: el SDK admite la recuperación de datos de referencia de Samsung Gallery y Huawei AppGallery.

Fondo

A partir de iOS 14.5, la recolección del identificador de anunciante (IDFA) requiere el consentimiento del usuario. En la práctica, esto significa que el acceso al IDFA se regirá por el marco de la Transparencia de seguimiento de aplicaciones (ATT). En los dispositivos iOS 14+, el SDK utiliza el marco de la ATT para obtener acceso al IDFA del dispositivo. 

Para informarte sobre la ATT, consulta Principios de la ATT.

Cuando la atribución se produce utilizando el IDFA, es importante que el IDFA se envíe con el evento del primer inicio. Por esta razón, el SDK proporciona la utilidad waitForATTUserAuthorization.

Descripción general de waitForATTUserAuthorization

waitForATTUserAuthorization te permite configurar cuánto tiempo debe posponer el SDK y esperar el estado de ATT antes de enviar datos a los servidores de AppsFlyer.

Cuando un usuario inicia la aplicación, el estado de ATT es notDetermined. Durante el tiempo de espera de waitForATTUserAuthorization, el SDK pone en cola el evento de inicio y los eventos in-app consecutivos en la memoria, de manera similar a la forma en que se registran los eventos sin conexión:

• Si el usuario da su consentimiento al aviso de la ATT (recopilación del IDFA):
  • El SDK agrega el IDFA a los eventos almacenados en caché.
  • El SDK inicia y envía los eventos almacenados en caché con el IDFA (sin esperar a que finalice el tiempo de espera).
• Si el usuario rechaza el aviso de ATT: el SDK se inicia y envía los eventos almacenados en caché sin el IDFA (sin esperar a que finalice el tiempo de espera).
• Si el tiempo de espera termina y el estado de ATT sigue como notDetermined: el SDK se inicia y envía los eventos almacenados en caché sin el IDFA.

consideraciones

• Si se llama a requestTrackingAuthorization sin configurar waitForATTUserAuthorization, los inicios y eventos se enviarán sin IDFA para dispositivos con iOS 14+.
• Si el usuario mueve la aplicación al fondo durante el tiempo de espera:
  • El temporizador se pone en pausa hasta que la aplicación vuelva al primer plano.
  • Los eventos se almacenan en caché en la memoria.
• Si el usuario cierra la aplicación, se desactiva durante el tiempo de espera:
  • El temporizador se reinicia en el próximo inicio de la aplicación.
  • Los eventos almacenados en caché se pierden.

Puedes personalizar el mensaje de la ATT. Un mensaje que indique claramente el propósito de la solicitud podría ayudar a aumentar las tasas de aceptación de los usuarios.

Ten en cuenta lo siguiente al crear tu mensaje:

• Utiliza el texto que mejor explique a tus usuarios por qué la aplicación solicita el consentimiento del usuario.
• Informa a los usuarios sobre cómo se utilizarán sus datos. Obtén más información sobre la privacidad del usuario y el uso de los datos.

Una vez que tu mensaje esté completo, proporciona a tu desarrollador el texto y las instrucciones de implementación.

Consulta algunos ejemplos externos de mensajes de ATT.

SKAN es una clase que iOS utiliza y para validar las instalaciones de aplicaciones impulsadas por los anunciantes. El proceso de validación de la instalación de la aplicación involucra a la aplicación fuente y a la aplicación anunciada. 

Una aplicación fuente es una aplicación que participa en campañas publicitarias mostrando los anuncios de una red de publicidad. La configuración de tu aplicación para mostrar anuncios no está dentro del alcance del SDK de AppsFlyer. Para configurarla, sigue las instrucciones de Apple.

Para la aplicación anunciada (la aplicación con el SDK de AppsFlyer), la Solución SKAN de AppsFlyer utiliza SKAN para proporcionar el postback de atribución mientras AppsFlyer recopila, traduce y agrega los datos, manteniendo la privacidad del usuario. Al iniciar la aplicación por primera vez, la plataforma de AppsFlyer utiliza la configuración establecida por el marketer para instruir al SDK sobre cómo establecer el valor de conversión de SKAN.

Para utilizar la solución SKAN:

• El marketer debe configurar la medición de SKAN en AppsFlyer. El desarrollador no tiene que realizar ninguna tarea.
• El SDK de AppsFlyer llama automáticamente a las API necesarias de SKAN.
• Asegúrate de desactivar las llamadas de SKAN en otros SDK cuando confíes en AppsFlyer para la atribución de SKAN.
• No se requiere ninguna otra acción o proceso de registro por parte del desarrollador o del marketer en la App Store. 

Para desactivar la atribución de SKAN, indica a tu desarrollador que la deshabilite en el SDK. 

Puedes enviar los ingresos con cualquier evento in-app. Asegúrate de utilizar el parámetro af_revenue para incluir los ingresos. Es el único parámetro de evento que AppsFlyer cuenta como ingresos reales en el panel de control y en los reportes de raw data. Aprender más.

Para obtener instrucciones para desarrolladores, consulta el registro de ingresos.

El SDK de AppsFlyer proporciona verificación de servidor para las compras in-app. Al validar una compra in-app, se envía automáticamente un evento de compra in-app a AppsFlyer. Si envías este evento tú mismo, se crea un reporte de evento duplicado.

Consulta nuestra lista de eventos in-app recomendados por vertical, por ejemplo, viajes, gaming o comercio electrónico.

Para los usuarios que no tienen tu aplicación instalada, OneLink detecta el tipo de dispositivo y los redirige al destino correcto (por ejemplo, Google Play, Apple App Store, tienda de aplicaciones de terceros o página web). Esto se basa en la configuración de la plantilla de OneLink. Aprender más

Para los usuarios con tu aplicación instalada, OneLink abre la aplicación. Además de abrir la aplicación, también puedes establecer deep links entre los usuarios y cualquier actividad o página específica dentro de tu aplicación. Esto requiere que tu desarrollador implemente Unified Deep Linking (UDL).

Nota:

• UDL requiere SDK V6.1+.
• Los clientes que ya usan OneLink para enlaces profundos pueden estar usando el método heredado, en lugar de UDL.

Consulta nuestra guía sobre cómo configurar enlaces profundos y enlaces profundos diferidos.

Para los usuarios que no tienen tu aplicación instalada, OneLink detecta el tipo de dispositivo y los redirige al destino correcto: Google Play, Apple App Store, tienda de aplicaciones de terceros o página web. Una vez que el usuario inicia la aplicación, puedes usar Deferred Deep Linking para redirigirlos a una actividad o página específica dentro de la aplicación.

Esto requiere que tu desarrollador implemente enlaces profundos diferidos extendidos.

Nota:

• UDL requiere SDK V6.1+.
• Los clientes que ya usan OneLink para Deferred Deep Linking pueden estar usando el método heredado, en lugar de UDL.

Consulta nuestra guía sobre cómo configurar enlaces profundos y enlaces profundos diferidos.