Guía básica de integración del SDK

Para:
Marketers
Última actualización:

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 completadas las tareas básicas de integración, tu aplicación estará lista para la atribución de instalaciones y la medición de eventos in-app.

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:

  1. En AppsFlyer, ve a Configuración > Configuración de la aplicación.
  2. Copia tu clave de desarrollador y envíala a tu desarrollador móvil.

  3. 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 iniciar 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.

Android nativo iOS nativo

Iniciar el SDK en Android nativo

SELECCIONAR 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.

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?

Selecciona tu estrategia de preservación de la privacidad

Selecciona cómo preservar la privacidad del usuario. Por ejemplo, selecciona entre detener el SDK en la instalación, evitar el intercambio de datos con terceros, anonimizar los datos del usuario o deshabilitar identificadores específicos.

Para obtener más información sobre los diferentes escenarios de exclusión opcional disponibles, consulta Escenarios de inclusión y exclusión opcional.

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:

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 establecer referencias con tus ID internos.

Para aprender más sobre el CUID, consulta este artículo.

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 pasa el IMEI o ID de Android al SDK mediante la API setImeiData o setAndroidIdData (consulta la referencia de funciones en las pestañas a continuación). El SDK envía los datos a los servidores de AppsFlyer.
      Android nativoUnity

      Consulta la referencia del SDK de Android para:

  • 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)

ANTECEDENTES

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.

iOS nativoUnity

Consulta el centro de desarrolladores para obtener instrucciones para desarrolladores sobre la implementación de la ATT.

Cuando la atribución se produce utilizando el IDFA, es importante que el IDFA se envíe en el primer inicio. Por esta razón, el SDK proporciona el método 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 posponerse 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 el 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:

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

iOS nativoUnity

Consulta el centro de desarrolladores para obtener instrucciones para desarrolladores para personalizar el cuadro de diálogo de consentimiento de ATT.

Consulta algunos ejemplos externos de mensajes de ATT.

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 para validar las instalaciones de aplicaciones impulsadas por los anunciantes. El proceso de validación de la instalación de la aplicación implica la aplicación fuente y 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 que AppsFlyer recopila, traduce y agrega los datos a la vez que mantiene la privacidad del usuario. Cuando se inicia la aplicación por primera vez, la plataforma AppsFlyer utiliza la configuración establecida por el marketer para instruir al SDK sobre cómo establecer el valor de conversión SKAN.

Para utilizar la solución SKAN:

  • El marketer necesita configurar la medición 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 el App Store.

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

iOS nativoUnityReact Native

Para desactivar la atribución de SKAN, usa disableSKAdNetwork.

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.

Android nativoiOS nativoUnity

Para obtener instrucciones para desarrolladores sobre la definición de eventos de ingresos, consulta aquí.

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 redirecció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 tu 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 enlaces profundos entre los usuarios y cualquier actividad o página específica dentro de tu aplicación. Esto requiere que tu desarrollador implemente Enlaces profundos unificados (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 enlaces profundos diferidos 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 • Marketer • Desarrollador back-end Normalmente en cuestión de minutos Backend Y N Premium
API pull • Marketer • Desarrollador back-end • Periódico (no en tiempo real). • Puedes programar las descargas de reportes de raw data. Backend Y Y Reportes premium de raw data
Data Locker • Marketer • Desarrollador back-end Los reportes horarios están disponibles dentro de 1 - 3 horas Almacenamiento en la nube mediante una de las siguientes opciones: • Bucket propiedad de AppsFlyer en AWS • Almacenamiento de tu propiedad (AWS o GCS) Y Y Premium
Obtener datos de conversión (GCD) • Marketer • Desarrollador móvil Consulta la documentación del desarrollador Hasta 5 segundos SDK Y Y Todas las cuentas
Enlaces profundos unificados (UDL) • Marketer • Desarrollador móvil Consulta la documentación del desarrollador 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.

Nota: Al realizar pruebas de atribución, registra un dispositivo de prueba (Android o iOS) para asegurarte de que cada instalación se registre como una nueva instalación. Un dispositivo de prueba registrado impide que las instalaciones se atribuyan como reinstalaciones.

Consulta también