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

Para:
Marketers
Última actualización:

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.

  1. En AppsFlyer, desde el menú lateral, elige Configuración > Configuración de la aplicación.
  2. 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.

Android nativo iOS nativo Unity React Native

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 global Application es, generalmente, una buena práctica, ya que la clase Application 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 o Activity - iniciar el SDK?
    • ¿Qué escenario de inclusión/exclusión voluntaria utilizar?
  • Envía al desarrollador el siguiente enlace de referencia:

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:

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 o setAndroidIdData (mira 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:

    • 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).
      Android nativoUnityReact Native

      Consulta la referencia del SDK de Android para:

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

iOS nativoUnity

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. waitForATTUserAuthorizationPor 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 configurar waitForATTUserAuthorization 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:

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

iOS nativoUnity

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.

iOS nativoUnityReact Native

Para desactivar la atribución SKAN utiliza disableSKAdNetwork

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:

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.

Android nativoiOS nativoUnity

Para obtener instrucciones para desarrolladores sobre cómo definir eventos de ingresos, consulta aquí.

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

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.

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.

Lee también