En resumen: Colabora con tu desarrollador de aplicaciones móviles o CTV para integrar e instalar el SDK en aplicaciones de Android o iOS. Cuando las tareas básicas de integración estén completas, tu aplicación estará lista para la atribución de instalaciones y la medición de eventos in-app.
Implementación de la clave de desarrollo en tu aplicación
AppsFlyer utiliza la clave de desarrollo para identificar de manera única tu cuenta. La clave de desarrollo es esencial porque permite que el SDK envíe y recupere datos de forma segura, pertenecientes a tu cuenta. Tu desarrollador debe instalar e integrar el SDK, e incluir la clave de desarrollo.
Recuperar la clave de desarrollo
Antes de que tu desarrollador pueda instalar e integrar el SDK, debes recuperar la clave de desarrollo.
- En AppsFlyer, desde el menú lateral, elige Configuración > Configuración de la aplicación.
- Copia tu clave de desarrollo y envíala a tu desarrollador móvil.
Proporciona la clave de desarrollo a tu desarrollador
Proporciona la clave de desarrollo, el ID de la aplicación y el token de la API v2 de AppsFlyer a tu desarrollador móvil con instrucciones para:
- Utiliza el asistente de integración de SDK para la instalación e integración automatizada del SDK.
- Utiliza las instrucciones paso a paso para instalar e integrar el SDK.
¿Dónde iniciar el SDK?
Al planificar 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 inicio de tu aplicación.
La regla general es que el SDK comience a enviar datos tan pronto como sea posible después de iniciar la aplicación. Esto asegura que el SDK capture el evento de instalación y todos los demás eventos in-app que se produzcan durante la sesión.
No obstante, para cumplir con las normativas de protección de la privacidad, como GDPR y CCPA, a menudo es necesario retrasar el envío de datos a AppsFlyer hasta que los usuarios consientan compartir su información.
Iniciando el SDK en Android nativo
SELECCIONA EN QUÉ CLASE INICIAR EL SDK
Decide si quieres iniciar el SDK en la clase global Application
o en la clase Activity
:
-
Inicia el SDK en la clase global
Application
: Inicializar el SDK en la clase/subclase globalApplication
es, generalmente, una buena práctica, ya que la claseApplication
se carga e inicializa antes de que cualquier interfaz de usuario de la aplicación se muestre. Esto asegura que el SDK pueda iniciarse en cualquier situación, incluso con enlaces profundos. -
Inicia el SDK en una clase (inicio diferido) para permitir que los usuarios opten por compartir datos. Esto se debe a que para obtener el consentimiento del usuario es necesaria una interfaz de usuario (UI) en una clase
Activity
.
INSTRUCCIONES PARA DESARROLLADORES DE ANDROID
- Informa al desarrollador sobre tu decisión respecto a lo siguiente:
- ¿En qué clase -
Application
oActivity
- iniciar el SDK? - ¿Qué escenario de inclusión/exclusión voluntaria utilizar?
- ¿En qué clase -
- Envía al desarrollador el siguiente enlace de referencia:
Cómo iniciar el SDK en iOS nativo
RETRASAR EL INICIO DEL SDK EN IOS
Una consideración clave al planificar el inicio del SDK es si se debe retrasar start
hasta obtener el consentimiento del usuario.
El SDK proporciona el método waitForATTUserAuthorization
, que te permite configurar cuánto tiempo debe esperar para que el usuario consienta antes de enviar datos a los servidores de AppsFlyer.
Para más información sobre el flujo de datos del método y su interacción con el framework ATT de iOS, consulta la sección Configurar soporte para App Tracking Transparency (ATT).
INSTRUCCIONES PARA DESARROLLADORES DE IOS
Comparte con tu desarrollador la siguiente información:
- ¿Cuánto tiempo en segundos es el tiempo de espera antes de enviar datos a AppsFlyer?
- Enlaces para desarrolladores:
- Inicio del SDK para iOS, guía para desarrolladores sobre cómo iniciar el SDK.
-
Configurar el soporte para App Tracking Transparency (ATT) para información sobre el flujo de datos del método
waitForATTUserAuthorization
y su interacción con el framework ATT de iOS. -
Habilitación del soporte para App Tracking Transparency (ATT), guía y referencia para desarrolladores en
waitForATTUserAuthorization
.
Cómo iniciar el SDK en Unity
Envía este artículo del Dev Hub a tu desarrollador sobre cómo iniciar el SDK.
Cómo iniciar el SDK en React Native
Envía a tu desarrollador este artículo del Dev Hub sobre cómo iniciar el SDK.
Elige tu estrategia de preservación de la privacidad
Selecciona cómo preservar la privacidad del usuario. Por ejemplo, elige entre detener el SDK durante la instalación, evitar el intercambio de datos con terceros, anonimizar los datos del usuario o desactivar identificadores específicos.
Para más información sobre los diferentes métodos de protección de privacidad disponibles, consulta Métodos de preservación de la privacidad en el SDK.
Atribución
El SDK recopila identificadores con el propósito de atribución. Para asegurar que las instalaciones se registren y atribuyan correctamente, revisa y sigue estas pautas.
Todas las plataformas
Identificador único para instalaciones
Un ID de AppsFlyer se crea automáticamente para cada nueva instalación de la aplicación. No se requiere ninguna acción por parte del responsable de marketing.
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 eventos in-app con raw data y usar appsflyer_id para analizar el comportamiento y el viaje de los usuarios.
Integrar identificadores únicos de ttu sistema de BI con AppsFlyer
Configura tu propio ID de usuario de cliente (CUID) en el SDK de AppsFlyer para cruzar el ID único de tu sistema de BI 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 APIs de postback para realizar referencias cruzadas con tus IDs internas.
Para aprender más sobre CUID, consulta este artículo.
Solo para Android
Las siguientes secciones describen consideraciones de atribución para Google Play Store o tiendas de aplicaciones de terceros.
Atribuir aplicaciones publicadas en Google Play
REFERENCIA DE INSTALACIÓN DE GOOGLE PLAY
La API de Google Play Install Referrer mejora la precisión de la atribución, protege contra el fraude de instalación, y permite la recuperación segura de datos de referencia de Google Play (por ejemplo, la versión de la aplicación en el momento de su instalación inicial).
Se recomienda que proporciones a tu desarrollador instrucciones para agregar la API de Google Play Install Referrer.
GAID
A partir del SDK V4.8.0, AppsFlyer recopila automáticamente este identificador de dispositivo.
Atribuir aplicaciones en tiendas de aplicaciones de terceros
Con AppsFlyer, puedes atribuir instalaciones que se originan en tiendas de aplicaciones de terceros, como Amazon, Opera, GetJar, Baidu, y Huawei. Esto te permite promocionar tus aplicaciones y alcanzar audiencias más amplias en mercados donde Google Play Store no está disponible.
AppsFlyer admite la atribución en el contexto de tiendas de aplicaciones de terceros de la siguiente manera:
-
IMEI o ID de Android: El SDK no recopila automáticamente ni el IMEI ni el ID de Android. Sin embargo, si es necesario recopilar estos identificadores (por ejemplo, para aplicaciones en el mercado local chino), tu desarrollador puede implementar uno de los siguientes métodos de recopilación:
- Recopilación manual: La aplicación transfiere el IMEI o el ID de Android al SDK utilizando la API
setImeiData
osetAndroidIdData
(mira la referencia de funciones en las pestañas a continuación). El SDK envía los datos a los servidores de AppsFlyer.Consulta la referencia del SDK de Android para:
Consulta la referencia del SDK de Unity para:
- Participar en la recopilación de ID de dispositivo: Obliga al SDK a recopilar el IMEI o ID de Android mediante setCollectIMEI y setCollectAndroidID (mira la referencia de funciones en las pestañas a continuación).
Consulta la referencia del SDK de Android para:
Consulta la referencia del SDK de Unity para:
Consulta la referencia de React Native para:
- Recopilación manual: La aplicación transfiere el IMEI o el ID de Android al SDK utilizando la API
- OAID: Atribuye instalaciones desde tiendas de aplicaciones Android de terceros. Para más información, lee la guía para implementar OAID.
- Referencias de instalación: El SDK soporta la recuperación de datos de referencia de Samsung Gallery y Huawei AppGallery.
Sólo iOS
Las siguientes secciones incluyen información esencial sobre el soporte para dispositivos iOS 14+.
Configurar el soporte para App Tracking Transparency (ATT)
ANTECEDENTES
Desde iOS 14.5, la recopilación del IDFA requiere el consentimiento del usuario. En la práctica, esto significa que el acceso al IDFA está regulado por el framework de App Tracking Transparency (ATT). En dispositivos iOS 14+, el SDK utiliza el framework de la ATT para acceder al IDFA del dispositivo. Para una introducción a la ATT, lee los principios de la ATT.
Consulta el Centro de Desarrollo para instrucciones sobre cómo implementar la ATT.
Consulta el Centro de Desarrollo para instrucciones sobre cómo implementar la ATT.
Cuando la atribución se realiza utilizando IDFA, es crucial que el IDFA se envíe en el primer lanzamiento. waitForATTUserAuthorization
Por esta razón, el SDK ofrece el método waitForATTUserAuthorization
.
Vista general de waitForATTUserAuthorization
¡Importante!
No llames a waitForATTUserAuthorization
si no tienes intención de invocar el aviso de la ATT.
waitForATTUserAuthorization
te permite configurar el tiempo que el SDK debe posponer y esperar el estado de la ATT antes de enviar datos a los servidores de AppsFlyer.
Cuando un usuario abre la aplicación, el estado de la ATT es notDetermined. Durante el período de espera waitForATTUserAuthorization
, el SDK almacena en memoria el evento de inicio y los eventos consecutivos in-app, de manera similar a como se registran los eventos offline:
- Si el usuario acepta la solicitud de la ATT (recopilación de IDFA):
- El SDK añade el IDFA a los eventos en caché.
- El SDK se activa y envía eventos con IDFA sin esperar a que finalice el tiempo de espera.
- Si el usuario rechaza la solicitud de la ATT: El SDK se activa y envía eventos en caché sin IDFA sin esperar a que finalice el tiempo de espera.
- Si el período de espera finaliza y el estado de la ATT sigue siendo notDetermined: El SDK se activa y envía eventos en caché sin IDFA.
Consideraciones
- Llamar a
requestTrackingAuthorization
sin configurarwaitForATTUserAuthorization
resultará en el envío de inicios y eventos sin IDFA para dispositivos iOS 14+. - Si el usuario coloca la aplicación en segundo plano durante el período de espera:
- El temporizador se pausa hasta que la aplicación regresa al primer plano.
- Los eventos se almacenan en memoria.
- Si el usuario cierra la aplicación durante el período de espera:
- El temporizador se reinicia en el siguiente inicio de la aplicación.
- Se pierden los eventos en caché.
Personalizar el diálogo de consentimiento de ATT
Puedes personalizar el mensaje de la solicitud ATT. Un mensaje que explique claramente el propósito de la solicitud podría ayudar a aumentar las tasas de opt-in por parte de los usuarios.
Ten en cuenta lo siguiente al crear tu mensaje:
- Usa una redacción que explique claramente a tus usuarios por qué la aplicación solicita su consentimiento.
- Informa a los usuarios sobre cómo se utilizarán sus datos. Infórmate más sobre la privacidad del usuario y el uso de datos.
Una vez que tu mensaje esté terminado, proporciona a tu desarrollador el texto y las instrucciones de implementación.
Consulta el Hub de Desarrolladores para instrucciones sobre cómo personalizar el diálogo de consentimiento de la ATT.
Consulta el Hub de Desarrolladores para instrucciones sobre cómo personalizar el diálogo de consentimiento de la ATT.
Soporte para la atribución SKAN
Nota
Para admitir completamente la atribución SKAN, actualiza a iOS SDK V6.2.3+.
SKAN es una clase utilizada por iOS para validar instalaciones de aplicaciones promovidas por anunciantes. El proceso de validación de instalación de la aplicación involucra tanto la aplicación fuente como la aplicación anunciada.
Una aplicación fuente es aquella que participa en campañas publicitarias mostrando anuncios de una ad network. La configuración de tu aplicación para mostrar anuncios no está cubierta por el SDK de AppsFlyer. Para configurarla, sigue las instrucciones de Apple.
Para la aplicación anunciada (la que incorpora el SDK de AppsFlyer), la solución SKAN de AppsFlyer utiliza SKAN para proporcionar la atribución mientras AppsFlyer recopila, traduce y agrega los datos, protegiendo la privacidad del usuario. Cuando la aplicación se inicia por primera vez, la plataforma de AppsFlyer utiliza la configuración establecida por el marketer para indicar al SDK cómo establecer el valor de conversión de SKAN.
Para emplear la solución SKAN:
- El marketer debe configurar la medición SKAN en AppsFlyer. El desarrollador no tiene que llevar a cabo ninguna tarea.
- El SDK de AppsFlyer llama automáticamente a las APIs de SKAN necesarias.
- Asegúrate de deshabilitar las llamadas al SKAN en otros SDKs si confías en AppsFlyer para la atribución SKAN.
- Ni el desarrollador ni el marketer necesitan realizar ninguna otra acción o proceso de registro en la App Store.
Para desactivar la atribución SKAN, dile a tu desarrollador que lo desactive en el SDK.
Para desactivar la atribución SKAN utiliza disableSKAdNetwork
Para desactivar la atribución SKAN utiliza disableSKAdNetwork
Para desactivar la atribución SKAN utiliza disableSKAd
Registro de eventos in-app
Los eventos in-app (IAE) proporcionan insights sobre lo que ocurre en tu aplicación. Registrar eventos in-app te ayuda a medir KPIs como el Retorno de la Inversión (ROI) y el Lifetime Value (LTV). Les recomendamos que se tomen el tiempo necesario para definir los eventos que desean registrar.
Una vez que decidas qué eventos in-app quieres medir, envía los nombres de los eventos y sus parámetros a tu desarrollador, e incluye un enlace a:
- El asistente de instalación del SDK que tiene un viaje dedicado para eventos in-app.
- Las instrucciones de implementación paso a paso para eventos in-app en el SDK.
Para aprender a definir eventos in-app y enviarlos a tu desarrollador, consulta nuestra guía de eventos enriquecidos in-app.
Todas las plataformas
Registrar ingresos
Puedes asociar 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 ingreso real en el dashboard y en los reportes de raw data. Saber más.
Para obtener instrucciones para desarrolladores sobre cómo definir eventos de ingresos, consulta aquí.
Para obtener instrucciones para desarrolladores sobre cómo definir eventos de ingresos, consulta aquí.
- Para instrucciones generales para desarrolladores sobre eventos dentro de la aplicación, consulta aquí.
- Para instrucciones específicas sobre ingresos en iOS y Android, consulta las pestañas de Android e iOS.
Validar compras in-app
El SDK de AppsFlyer ofrece verificación del servidor para compras in-app. Al validar una compra in-app, se envía automáticamente un evento de compra a AppsFlyer. Si envías este evento tú mismo, se generarán reportes de eventos duplicados.
Verticales de la industria
Consulta nuestra lista de eventos in-app recomendados por vertical, por ejemplo, viajes, juegos o e-commerce.
Deep linking con OneLink
OneLink es la solución de AppsFlyer para la atribución multiplataforma, redirección y deep linking.
Todas las plataformas
Detección y redirección de dispositivos
Para usuarios que no tienen instalada tu aplicación, OneLink detecta el tipo de dispositivo y los redirecciona al destino correcto (por ejemplo, Google Play, Apple App Store, una tienda de aplicaciones de terceros o una página web). Esto se basa en la configuración de tu plantilla OneLink. Saber más
Deep linking
Para usuarios que tienen instalada tu aplicación, OneLink abre la aplicación. Además de abrir la aplicación, también puedes enviar a los usuarios a una actividad o página específica dentro de la misma. Esto requiere que tu desarrollador implemente Deep Linking Unificado (UDL):
- El asistente de instalación del SDK que tiene un recorrido dedicado para la implementación de deep linking, o
- Las instrucciones de implementación del SDK paso a paso para deep linking unificado.
Nota:
- UDL requiere SDK V6.1+.
- Los clientes ya usando OneLink para deep linking pueden estar utilizando el método heredado, en lugar de UDL.
Consulta nuestra guía sobre cómo configurar deep linking y deferred deep linking.
Deferred deep linking
Para usuarios que no tienen instalada tu aplicación, OneLink detecta el tipo de dispositivo y los redirecciona al destino correcto: Google Play, Apple App Store, una tienda de aplicaciones de terceros o una página web. Una vez que el usuario inicia la aplicación, puedes usar deferred deep linking para redireccionarlo a una actividad o página específica dentro de la aplicación.
Esto requiere que tu desarrollador implemente deferred deep linking.
- El asistente de instalación del SDK que tiene un recorrido dedicado para la implementación de deep linking, o
- Las instrucciones de implementación del SDK paso a paso para deferred deep linking.
Nota:
- UDL requiere SDK V6.1+.
- Clientes que ya utilizan OneLink para deferred deep linking podrían estar usando el método heredado, en lugar de UDL.
Consulta nuestra guía sobre cómo configurar deep linking y deferred deep linking.
Acceso a datos de atribución y de deep linking
La siguiente tabla describe los métodos disponibles para obtener datos de atribución y de deep linking:
Método | ¿Quién está involucrado? | Resultados de retorno | Método de recuperación | Datos de atribución | Datos de deep linking | Disponibilidad |
---|---|---|---|---|---|---|
Push API | • Marketer • Desarrollador back-end | Normalmente en cuestión de minutos | Back-end | Sí | No | Premium |
Pull API | • Marketer • Desarrollador back-end | • Periódico (no en tiempo real). • Puede programar descargas de informes de datos sin procesar. | Back-end | Sí | Sí | Premium para reportes de raw data |
Data Locker | • Marketer • Desarrollador back-end | Los reportes de horarios están disponibles en un plazo de 1 a 3 horas. | Almacenamiento en la nube mediante una de las siguientes opciones: • Espacio propiedad de AppsFlyer en AWS • Almacenamiento propio (AWS o GCS) | Sí | Sí | Premium |
Obtener datos de conversión (GCD) | • Marketer • Desarrollador de aplicaciones móviles Ver documentación para desarrolladores | Hasta 5 segundos | SDK | Sí | Sí | Todas las cuentas |
Deep Linking Unificada (UDL) | • Marketer • Desarrollador de aplicaciones móviles Ver documentación para desarrolladores | Hasta 1 segundo | SDK | No | Sí | Todas las cuentas |
Ten en cuenta lo siguiente para los usuarios que no dan su permiso en iOS 14.5+:
- Al usar UDL para medios de pago y propios, los datos de deep linking están disponibles.
- Al usar GCD para medios de pago, los datos son limitados y no incluyen detalles de atribución ni de deep linking.
Consejo
Recomendamos lo siguiente:
- Utiliza la Push API para recuperar datos de atribución y enviarlos a tus servidores para procesamiento adicional. Este método espera a que los datos estén disponibles, siendo muy preciso y casi en tiempo real. GCD proporciona 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.
- Utiliza la Pull API para complementar periódicamente (por ejemplo, diariamente) los datos de atribución en tiempo real, compensando cualquier error de comunicación que pueda ocurrir.
Prueba de integración del SDK
Una vez terminada la integración del SDK, puedes acceder al dashboard de AppsFlyer y, desde la página de Pruebas de Integración del SDK, probar instalaciones orgánicas y no orgánicas, eventos in-app y deep linking (retargeting). Esto asegura que las instalaciones y los eventos in-app se registren y atribuyan correctamente.
Para conocer los escenarios de prueba y las instrucciones, consulta Prueba de integración del SDK.
Nota: Al realizar pruebas de atribución, registra un dispositivo de prueba (Android o iOS) para asegurarse de que cada instalación se registre como una nueva instalación. Un dispositivo de prueba registrado evita que las instalaciones se registren como reinstalaciones.