De un vistazo: Trabaja con tu desarrollador de aplicaciones móviles o CTV para integrar e instalar el SDK en aplicaciones Android o iOS. Una vez que se completan las tareas básicas de integración, tu aplicación está lista para la atribución de instalaciones y la medición de eventos in-app.
Lectura relacionada:
Para obtener un panorama completo de la planificación de la integración de SDK con tu aplicación, asegúrate de leer estos artículos:
- Descripción general de la integración del SDK
- Guía básica de integración del SDK (este artículo)
- Integración adicional del SDK
- Descripción general de TV conectada (CTV) y over-the-top (OTT)
Recuperar la clave de desarrollador
Antes de que tu desarrollador pueda instalar e integrar el SDK, debes recuperar la clave de desarrollador. AppsFlyer usa la clave de desarrollador para identificar tu cuenta de manera exclusiva. La clave de desarrollador es obligatoria porque permite que el SDK envíe y recupere datos que pertenecen a tu cuenta de AppsFlyer de manera segura.
Para recuperar tu clave de desarrollador:
- En AppsFlyer, ve a Configuración > Configuración de la aplicación.
- Copia tu clave de desarrollador y envíala a tu desarrollador móvil.
- Proporciona a tu desarrollador móvil estas instrucciones para instalar e integrar el SDK.
¿Dónde iniciar el SDK?
Al planear la integración del SDK de AppsFlyer, la primera decisión que debes tomar es dónde inicializar e iniciar el SDK dentro del flujo de lanzamiento de tu aplicación.
La regla general básica es que el SDK comience a enviar datos lo antes posible después de lanzar la aplicación.Esto garantiza que el SDK capture el evento de instalación y todos los demás eventos in-app que ocurren en la sesión.
Sin embargo, para cumplir con las regulaciones de privacidad como el RGPD y el CCPA, a menudo es necesario retrasar el envío de datos a AppsFlyer hasta que los usuarios den su consentimiento para compartir su información.
Inicio del SDK en Android
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/subclaseApplication
global es una buena práctica porque la claseApplication
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 claseActivity
.
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
oActivity
- debe iniciarse el SDK?
- ¿Qué escenario de inclusión/exclusión opcional se debe usar?
- ¿En qué clase -
- Envía a tu desarrollador los siguientes enlaces de referencia:
Inicio del SDK en iOS
Retrasar el inicio del SDK en iOS
Una consideración importante a la hora de planificar cómo iniciar el SDK es si se debe retrasar el start
hasta que se otorgue el consentimiento del usuario.
El SDK proporciona el método waitForATTUserAuthorization
, que te permite configurar cuánto tiempo debe esperar el SDK para obtener el consentimiento del usuario antes de enviar datos a los servidores de AppsFlyer.
Para obtener más información sobre el flujo de datos del método y su interacción con el marco de ATT de iOS, consulta la sección de soporte sobre cómo configurar la transparencia de seguimiento de aplicaciones (ATT).
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 diferentes escenarios de exclusión opcional disponibles, consulta Escenarios de inclusión y exclusión opcional.
Instrucciones para desarrolladores de iOS
Comparte la siguiente información con tu desarrollador:
- ¿De cuántos segundos es el tiempo de espera antes de enviar datos a AppsFlyer?
- ¿Qué escenario de inclusión/exclusión opcional se debe usar?
- Enlaces para desarrolladores:
- Iniciar el SDK de iOS para la guía del desarrollador y la referencia sobre cómo iniciar el SDK.
-
Configurar el soporte de la transparencia de seguimiento de aplicaciones (ATT) para obtener información sobre el flujo de datos del método
waitForATTUserAuthorization
y cómo este interactúa con el marco de ATT de iOS
-
Habilitación del soporte de la transparencia de seguimiento de aplicaciones (ATT) para la guía del desarrollador y la referencia en
waitForATTUserAuthorization
Atribución
El SDK recopila los identificadores con fines de atribución.Para asegurarte de que las instalaciones se registren y atribuyan correctamente, revisa y sigue estos lineamientos.
Todas las plataformas
Identificador único para instalaciones
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.
Integrar dentificadores únicos de tu sistema de Business Intelligence con AppsFlyer
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.
Solo para Android
En las secciones siguientes se describen las consideraciones de la atribución para Google Play Store o tiendas de aplicaciones de terceros.
Atribución de aplicaciones publicadas en Google Play
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.
Atribución de aplicaciones en tiendas de aplicaciones de terceros
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
osetAndroidIdData
). 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.
- Recopilación manual: la aplicación transmite el IMEI o el ID de Android al SDK (mediante la API
- 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.
Solo para iOS
Las siguientes secciones incluyen información importante sobre la compatibilidad con dispositivos iOS 14+.
Configurar la compatibilidad con la Transparencia de seguimiento de aplicaciones (ATT)
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
¡Importante!
No llames a waitForATTUserAuthorization
si no tienes la intención de invocar el aviso de la ATT.
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 configurarwaitForATTUserAuthorization
, 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.
Personalizar el cuadro de diálogo de consentimiento de la ATT
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.
Compatibilidad con la atribución de SKAN
Nota
Para admitir completamente la atribución de SKAN, actualiza a iOS SDK V6.2.3+.
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.
Registro de eventos in-app
Los eventos in-app (IAE) brindan información sobre lo que está sucediendo en tu aplicación. El registro de eventos in-app te ayuda a medir los KPI como el retorno de la inversión (ROI) y el valor de vida útil (LTV). Te recomendamos que te tomes un tiempo para definir los eventos que deseas registrar.
Una vez que hayas determinado los eventos in-app que deseas medir, envía los nombres y parámetros de los eventos a tu desarrollador e incluye un enlace a las instrucciones de implementación.
Para obtener más información sobre los eventos in-app, consulta nuestra guía Eventos in-app enriquecidos.
Todas las plataformas
Cómo registrar los ingresos
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.
Validar compras in-app
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.
Verticales de la industria
Consulta nuestra lista de eventos in-app recomendados por vertical, por ejemplo, viajes, gaming o comercio electrónico.
Enlaces profundos con OneLink
OneLink es la solución de AppsFlyer para la dirección, los enlaces profundos y la atribución multiplataforma.
Todas las plataformas
Detección y redireccionamiento de dispositivos
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
Enlaces profundos
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.
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.
Acceso a datos de atribución y enlaces profundos
La siguiente tabla describe los métodos disponibles para recuperar datos de atribución y enlaces profundos:
Método | ¿Quién está involucrado? | Devuelve resultados | Método de recuperación | Datos de atribución | Datos de enlaces profundos | Disponibilidad |
---|---|---|---|---|---|---|
API push |
|
Normalmente en cuestión de minutos | Backend | Y | N | Premium |
API pull |
|
|
Backend | Y | Y | Reportes premium de raw data |
Data Locker |
|
Los reportes horarios están disponibles dentro de 1 - 3 horas |
Almacenamiento en la nube a través de una de las siguientes opciones:
|
Y | Y | Premium |
Obtener datos de conversión (GCD) |
|
Hasta 5 segundos | SDK | Y | Y | Todas las cuentas |
Enlaces profundos unificados (UDL) |
|
Hasta 1 segundo | SDK | N | Y | Todas las cuentas |
Ten en cuenta lo siguiente para los usuarios de iOS 14.5+ que no dan su consentimiento:
- Cuando se utiliza UDL para medios pagados y propios, los datos de deep linking están disponibles.
- Cuando se utiliza GCD para medios pagados, los datos son limitados y no incluyen los detalles de atribución y deep linking.
Consejo
Recomendamos lo siguiente:
- Usa la Push API para recuperar los datos de atribución y enviarlos a tus servidores para su procesamiento posterior. Este método espera a que los datos estén disponibles y, por lo tanto, es muy preciso y casi en tiempo real. GCD devuelve datos en tiempo real, pero puede ser inexacto cuando las decisiones finales de atribución se determinan después de más de 5 segundos.
- Usa Pull API para complementar periódicamente (por ejemplo, diariamente) los datos de atribución en tiempo real y para compensar cualquier error de comunicación que pueda ocurrir.
probar tu integración de SDK
Una vez completada la integración del SDK, puedes ir al panel de control de AppsFlyer y, desde la página de pruebas de integración de SDK, probar instalaciones orgánicas y no orgánicas, eventos in-app y enlaces profundos (retargeting). Esto garantiza que las instalaciones y los eventos in-app se registren y atribuyan correctamente.
Si necesitas que tu desarrollador pruebe la integración de SDK, agrega al desarrollador como usuario en tu cuenta, para que pueda acceder al panel de control.
Para ver las instrucciones y situaciones de prueba, consulta Pruebas de integración de SDK .