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

De un vistazo: 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 dentro de la 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.

Incorporar la clave de desarrollo

Proporciona a tu desarrollador móvil las instrucciones 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 dentro de la aplicación 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.

Nativo de Android Nativo de iOS Unity React Native

Iniciando el SDK en Android nativo

SELECCIONA EN QUÉ CLASE INICIAR EL SDK

Decide si desear iniciar el SDK en la clase global Application o en la clase Activity:

  • Inicia el SDK en la clase global : 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?

Cómo iniciar el SDK en Unity

Envía a tu desarrollador este artículo del Dev Hub 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 obtener más información sobre los diferentes métodos de protección de la privacidad disponibles, consulte 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, revise y siga 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.

Puede utilizar este identificador para realizar las siguientes acciones:

Integrar identificadores únicos de su sistema de BI con AppsFlyer

Configure su propio ID de usuario de cliente (CUID) en el SDK de AppsFlyer para cruzar el ID único de su sistema de BI con el ID de AppsFlyer y otros identificadores. El CUID está disponible en los informes de datos sin procesar de AppsFlyer. También puede usarlo en las API de postback para realizar referencias cruzadas con sus ID internas.

Para aprender más sobre CUID, consulte 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 Referencia de Instalación de Google Play 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 proporcione a su desarrollador instrucciones para agregar la API de Referencia de Instalación de Google Play.

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 le permite promocionar sus 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), su 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 (vea la referencia de funciones en las pestañas a continuación). El SDK envía los datos a los servidores de AppsFlyer.
      Android nativoUnity

      Consulte la referencia del SDK de Android para:

      •  
      •   
  • OAID: Atributa instalaciones desde tiendas de aplicaciones Android de terceros. Para más información, vea 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 de IDFA requiere el consentimiento del usuario. En la práctica, esto significa que el acceso al IDFA está regulado por el marco de Transparencia de Seguimiento de Aplicaciones (ATT). En dispositivos iOS 14+, el SDK utiliza el marco ATT para acceder al IDFA del dispositivo. Para una introducción al ATT, vea los principios del ATT.

iOS nativoUnity

Consulte el Centro de Desarrollo para instrucciones sobre cómo implementar 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.

Visión general de waitForATTUserAuthorization

¡Importante!

No llame a waitForATTUserAuthorization si no tiene intención de invocar el aviso ATT.

waitForATTUserAuthorization te permite configurar el tiempo que el SDK debe posponer y esperar el estado ATT antes de enviar datos a los servidores de AppsFlyer.

Cuando un usuario abre la aplicación, el estado de ATT es no determinado. Durante el período de espera , el SDK almacena en memoria el evento de inicio y los eventos consecutivos dentro de la aplicación, de manera similar a como se registran los eventos sin conexión:

  • Si el usuario acepta la solicitud de 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 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 ATT sigue siendo no determinado: El SDK se activa y envía eventos en caché sin IDFA.

Consideraciones

  • 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 aceptación 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

Soporte para la atribución SKAN

 

Nota

Para admitir completamente la atribución SKAN, actualice 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 red publicitaria. La configuración de su aplicación para mostrar anuncios no está cubierta por el SDK de AppsFlyer. Para configurarla, siga 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 AppsFlyer utiliza la configuración establecida por el comercializador para indicar al SDK cómo establecer el valor de conversión de SKAN.

Para emplear la solución SKAN:

  • El comercializador 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úrese de deshabilitar las llamadas SKAN en otros SDK si confía en AppsFlyer para la atribución SKAN.
  • Ni el desarrollador ni el comercializador necesitan realizar ninguna otra acción o proceso de registro en la App Store.

Para desactivar la atribución SKAN, indique a su desarrollador que la desactive en el SDK.

iOS nativoUnityReact Native

Para desactivar la atribución SKAN use

Registro de eventos en la aplicación

Los eventos dentro de la aplicación (IAE) proporcionan información sobre lo que ocurre en su aplicación. Registrar eventos en la aplicación le ayuda a medir indicadores clave de rendimiento (KPI) como el Retorno sobre la Inversión (ROI) y el Valor de Vida del Cliente (LTV). Le recomendamos que se tome el tiempo necesario para definir los eventos que desea registrar.

Una vez que decidas qué eventos dentro de la aplicación quieres medir, envía los nombres de los eventos y sus parámetros a tu desarrollador, e incluye un enlace a las instrucciones de implementación.

Para saber más sobre los eventos dentro de la aplicación, consulta nuestra Guía completa de eventos dentro de la aplicación.

Todas las plataformas

Registrar ingresos

Puedes asociar ingresos con cualquier evento dentro de la aplicación. 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 panel de control y en los informes de datos sin procesar. Más información.

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 informes de eventos duplicados.

Sectores industriales

Consulta nuestra lista de eventos recomendados dentro de la aplicación por sector, por ejemplo, viajes, juegos o comercio electrónico.

Enlaces profundos con OneLink

OneLink es la solución de AppsFlyer para la atribución multiplataforma, redirección y enlaces profundos.

Todas las plataformas

Detección y redirección de dispositivos

Para usuarios que no tienen instalada su aplicación, OneLink detecta el tipo de dispositivo y los redirige 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 su plantilla OneLink. Más información

Enlaces profundos

Para usuarios que tienen instalada su aplicación, OneLink abre la aplicación. Además de abrir la aplicación, también puede dirigir a los usuarios a una actividad o página específica dentro de la misma. Esto requiere que su desarrollador implemente Enlace profundo unificado (UDL).

Nota:

  • UDL requiere SDK V6.1+.
  • Los clientes ya usando OneLink para enlaces profundos pueden estar utilizando el método heredado, en lugar de UDL.

Consulte nuestra guía sobre cómo configurar enlaces profundos y enlaces diferidos.

Enlaces diferidos

Para usuarios que no tienen instalada su aplicación, OneLink detecta el tipo de dispositivo y los redirige 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, puede usar enlaces diferidos para redirigirlo a una actividad o página específica dentro de la aplicación.

Esto requiere que su desarrollador implemente enlaces diferidos extendidos.

Nota:

  • UDL requiere SDK V6.1+.
  • Clientes que ya utilizan OneLink para enlaces diferidos podrían estar usando el método heredado, en lugar de UDL.

Consulte nuestra guía sobre cómo configurar enlaces profundos y enlaces diferidos.

Acceso a datos de atribución y de enlaces profundos

La siguiente tabla describe los métodos disponibles para obtener datos de atribución y de enlaces profundos:

Método ¿Quién está involucrado? Resultados de retorno Método de recuperación Datos de atribución Datos de enlaces profundos Disponibilidad
API de inserción • Especialista en marketing • Desarrollador back-end Normalmente en cuestión de minutos Back-end No Premium
API de extracción • Especialista en marketing • Desarrollador back-end • Periódico (no en tiempo real). • Puede programar descargas de informes de datos sin procesar. Back-end Premium para informes de datos sin procesar
Repositor de datos • Especialista en marketing • Desarrollador back-end Los informes 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) Premium
Obtener datos de conversión (GCD) • Especialista en marketing • Desarrollador de aplicaciones móviles Ver documentación para desarrolladores Hasta 5 segundos SDK Todas las cuentas
Vinculación profunda unificada (UDL) • Especialista en marketing • Desarrollador de aplicaciones móviles Ver documentación para desarrolladores Hasta 1 segundo SDK No Todas las cuentas

Tenga en cuenta lo siguiente para los usuarios que no consienten en iOS 14.5+:

  • Al usar UDL para medios pagados y propios, los datos de vinculación profunda están disponibles.
  • Al usar GCD para medios pagos, los datos son limitados y no incluyen detalles de atribución ni de vinculación profunda.

Consejo

Recomendamos lo siguiente:

  • Utilice la API Push para recuperar datos de atribución y enviarlos a sus 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.
  • Utilice la API Pull 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, puede acceder al panel de AppsFlyer y, desde la página de Pruebas de Integración del SDK, probar instalaciones orgánicas y no orgánicas, eventos dentro de la aplicación y vinculación profunda (retargeting). Esto asegura que las instalaciones y los eventos dentro de la aplicación se registren y atribuyan correctamente.

Para conocer los escenarios de prueba y las instrucciones, consulte Prueba de integración del SDK.

Nota: Al realizar pruebas de atribución, registre 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.