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

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:

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.

    af_devkey.png

  3. Proporciona a tu desarrollador móvil estas instrucciones para instalar e integrar el SDK.

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

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.

ATT-flowchart_en-us.png

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.

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.

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 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 configuración de enlaces profundos con OneLink.

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 Unified Deep Linking (UDL).

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 configuración de Deferred Deep Linking con OneLink.

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 backend
Normalmente en cuestión de minutos Backend Y N Premium
API pull
  • Marketer
  • Desarrollador backend
  • 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 backend

Los reportes horarios están disponibles dentro de 1 - 3 horas

Almacenamiento en la nube a través de 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

Ver documentación para desarrolladores

Hasta 5 segundos  SDK Y Y Todas las cuentas
Enlaces profundos unificados (UDL)
  • Marketer
  • Desarrollador móvil

Ver documentación para desarrolladores

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 .

¿Fue útil este artículo?