Integración de SDK de Android para marketers

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 raw data y en el panel de control. Para más detalles, haz clic aquí.

Para obtener instrucciones para desarrolladores, consulta el registro de ingresos.

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.

Si tu aplicación pertenece a una vertical como viajes, gaming o comercio electrónico, consulta nuestra lista de eventos in-app recomendados por vertical.

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

Para los usuarios con tu aplicación instalada, OneLink abre la aplicación. Además de abrir la aplicación, también puedes enlazar profundamente a los usuarios 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 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.

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 enlaces profundos diferidos para aprender más.

AppsFlyer admite la medición de las campañas de notificaciones push de todos los proveedores y también puede admitir a los desarrolladores que utilizan Google Cloud Messaging o los servicios de notificaciones push de Apple directamente. Las conversiones, definidas como aplicaciones que se abren a partir de mensajes de notificaciones push, se muestran en el dashboard de retargeting.

Puedes usar OneLink para medir el re-engagement de usuarios a través de notificaciones push. Consulta nuestra guía sobre la medición de campañas de re-engagement de notificaciones push.

Con AppsFlyer, puedes atribuir instalaciones para aplicaciones Android fuera de la tienda. Esto te permite promocionar tus aplicaciones y llegar a audiencias más grandes en mercados en los que Google Play no está disponible. 

Para conocer más detalles sobre cómo atribuir instalaciones para aplicaciones fuera de la tienda, lee aquí.

En las campañas de instalación previa, los propietarios de aplicaciones pueden solicitarles a los fabricantes de dispositivos que preinstalen sus aplicaciones en los dispositivos antes de salir de fábrica.

Con AppsFlyer, puedes atribuir instalaciones de aplicaciones preinstaladas con facilidad. Cuando los usuarios inician tu aplicación por primera vez, AppsFlyer atribuye la instalación al fabricante como fuente de medios.

Para conocer más detalles, haz clic aquí.

Para saber cómo configurar la medición de desinstalaciones, lee aquí.

Si quieres recibir una confirmación de que los servidores de AppsFlyer recibieron la solicitud correctamente, implementa el agente de escucha AppsFlyerRequestListener.

El método de devolución de llamada onRequestSuccess() se invoca para cada respuesta 200 a una solicitud de atribución por parte del SDK.

El método de devolución de llamada onRequestFailure(String error) se invoca para cualquier otra respuesta y devuelve la respuesta como la cadena de error.

Ejemplo de implementación

AppsFlyerLib.getInstance().start(getApplicationContext(), "devKey", new AppsFlyerRequestListener() {
            @Override
            public void onSuccess() {
                Log.d(LOG_TAG, "Launch sent successfully, got 200 response code from server");
            }
            @Override
            public void onError(int i, @NonNull String s) {
                Log.d(LOG_TAG, "Launch failed to be sent:\n" +
                                "Error code: " + i + "\n"
                                + "Error description: " + s);
            }
        });

AppsFlyerLib.getInstance().start(this, "devKey", object : AppsFlyerRequestListener {
            override fun onSuccess() {
                Log.d(LOG_TAG, "Launch sent successfully")
            }
            override fun onError(errorCode: Int, errorDesc: String) {
                Log.d(LOG_TAG, "Launch failed to be sent:\n" +
                        "Error code: " + errorCode + "\n"
                        + "Error description: " + errorDesc)
            }
        })

En caso de que se produzca un error durante la escucha de la solicitud, se proporciona un código de error y una descripción de la cadena, como se indica en la tabla que figura a continuación.

La API setAdditionalData es necesaria para integrarse a nivel del SDK con varias plataformas de partners externos, como Segment, Adobe y Urban Airship.
Usa esta API solo si el artículo de integración de la plataforma indica específicamente que se necesita la API setAdditionalData.

Ejemplo de código de setAdditionalData:

HashMap<String,Object> CustomDataMap = new HashMap<>();
CustomDataMap.put("custom_param_1","value_of_param_1");
AppsFlyerLib.getInstance().setAdditionalData(CustomDataMap);

val customDataMap = HashMap<String, Any>()
customDataMap.put("custom_param_1","value_of_param_1")
AppsFlyerLib.getInstance().setAdditionalData(customDataMap)

Los propietarios de aplicaciones que usan App Links para deep linking (sin OneLink) y tienen un dominio asociado con su aplicación pueden atribuir sesiones iniciadas a través de este dominio mediante el método appendParametersToDeepLinkingURL.

Por ejemplo, un usuario busca en Google y hace clic en tu dominio, www.ejemplo.com:

• Si el usuario no tiene la aplicación instalada, será direccionado al sitio web (www.ejemplo.com).
• Si el usuario tiene la aplicación instalada en su dispositivo, tendrá enlaces profundos a la aplicación asociada con www.ejemplo.com. La sesión se atribuye a la fuente de medios (parámetro pid) especificada en appendParametersToDeepLinkingURL.

Consulta la referencia del SDK de Android para obtener más información.

Nota: Los Smart Banners ayudan a los propietarios de aplicaciones a convertir a los visitantes del sitio web en usuarios de la aplicación.

De manera predeterminada, deben pasar por lo menos 5 segundos entre 2 instancias de inicio de la aplicación para que cuenten como 2 sesiones separadas (más información acerca del recuento de sesiones).

Usa la siguiente API para establecer el tiempo mínimo entre sesiones:

AppsFlyerLib.setMinTimeBetweenSessions(int seconds);

Establecer un valor alto para el tiempo personalizado entre inicios podría afectar negativamente las API que dependen de los datos de sesión, como los enlaces profundos.

Puedes usar este método de SDK para notificar sobre nuevas sesiones de usuario. Por ejemplo, esto puede resultar útil para aplicaciones utilitarias que se ejecutan en segundo plano.

Usa esta API en la función onCreate() de tu actividad:

public void logSession(Context context);

Ejemplo de Uso:

AppsFlyerLib.getInstance().logSession(context);

Algunos servicios de terceros, como los proveedores de servicio de correo electrónico encapsulan enlaces en los mensajes de correo electrónico con sus propios dominios de registro de clics. Algunos incluso te permiten configurar tus propios dominios de registro de clics. Si OneLink está encapsulado en tales dominios, su funcionalidad podría verse limitada.

Para resolver este problema, puedes usar la API setResolveDeepLinkURLs. Usa esta API para obtener el OneLink de los dominios de clics que inician la aplicación.  Asegúrate de llamar a esta API antes de la inicialización del SDK.

Por ejemplo, tienes tres dominios de clics que redirigen a tu OneLink, que es https://mysubdomain.onelink.me/abCD. Usa esta API para obtener el OneLink al cual redirigen tus dominios de clics. Este método de API recibe una lista de dominios que el SDK resolverá. Agrega el siguiente código antes de la inicialización del SDK.

AppsFlyerLib.getInstance().setResolveDeepLinkURLs("clickdomain.com", "myclickdomain.com", "anotherclickdomain.com");

El código anterior te permite usar tu dominio de clics y, al mismo tiempo, preservar la funcionalidad de OneLink. Los dominios de clics son responsables de iniciar la aplicación. A su vez, la API obtiene el OneLink de estos dominios de clics y, a continuación, tú puedes usar los datos de este OneLink para establecer enlaces profundos y personalizar el contenido de los usuarios.

Con AppsFlyer, puedes medir notificaciones push como parte de las campañas de retargeting.

Para activar esta función, llama al método sendPushNotificationData dentro del método onCreate de cada actividad que se inicia tras hacer clic en la notificación:

AppsFlyerLib.getInstance().sendPushNotificationData(this);

Para obtener más información sobre la medición de notificaciones push, lee aquí.

Permitir que tus usuarios actuales inviten a sus amigos y contactos como nuevos usuarios de tu aplicación puede ser un factor de crecimiento clave para tu aplicación. Con AppsFlyer, puedes atribuir y registrar instalaciones que se originen a partir de invitaciones de usuarios dentro de tu aplicación.

Para conocer más detalles, consulta el artículo sobre atribución de invitaciones de usuarios.

Un ID de AppsFlyer se crea para cada instalación nueva de una aplicación. Puedes usar este ID de AppsFlyer con diversos fines:

• Enviar eventos in-app de servidor a servidor.
• Vincular el ID de AppsFlyer con los registros de usuarios en tus sistemas de backend.
• Asignar entradas cuando se fusionan datos de las Pull API y Push API.

Usa la siguiente API para obtener el ID de AppsFlyer:

public String getAppsFlyerUID(Context context);

Ejemplo de uso:

String appsFlyerId = AppsFlyerLib.getInstance().getAppsFlyerUID(this);

Para configurar tu ID de usuario de cliente:

public void setCustomerUserId(String id);

Ejemplo de uso:

AppsFlyerLib.getInstance().setCustomerUserId("myId");

Te recomendamos configurar el ID de usuario de cliente lo antes posible en el flujo de tu aplicación, ya que solo se asocia con los eventos reportados después de su configuración:

• Si se llama a setCustomerUserId antes de llamar a start, el ID de usuario de cliente aparece en los reportes de raw data de instalaciones y eventos.
• Si se configura después, el ID de usuario de cliente se asocia solo con eventos registrados después de configurar dicho ID.

Para evitar configurar el valor del ID de usuario de cliente nuevamente después del primer inicio, y reducir las llamadas a tu servidor para obtener el ID de usuario de cliente, puedes verificar si su valor está vacío, o no, de la siguiente forma:

AppsFlyerProperties.getInstance().getString(AppsFlyerProperties.APP_USER_ID)

Para obtener más información sobre el ID de usuario de cliente, haz clic aquí.

Puedes retrasar la inicialización del SDK hasta que se configure el customerUserID.

Para indicar que el SDK debe retrasar la inicialización en espera del ID de usuario de cliente, llama a:

AppsFlyerLib.getInstance().waitForCustomerUserId(true);

inmediatamente antes del método init(). El resto de la inicialización del SDK debe mantenerse sin cambios.

Una vez proporcionado el customerUserID, llama a

AppsFlyerLib.getInstance().setCustomerIdAndLogSession("customer_id", this);

Para proporcionar al SDK el ID de usuario de cliente correspondiente e iniciar el SDK.

El código debería verse como se muestra a continuación:

public class AFApplication extends Application {
  private static final String AF_DEV_KEY = "qrdZGj123456789";
  @Override
  public void onCreate() {
    super.onCreate();
    AppsFlyerConversionListener conversionDataListener = 
    new AppsFlyerConversionListener() {
      ...
    };
    AppsFlyerLib.getInstance().waitForCustomerUserId(true);
    //WARNING! Removing above line doesn't cancel its effect.
    // Replace with this to stop waiting for CUID:
    // AppsFlyerLib.getInstance().waitForCustomerUserId(false);
    AppsFlyerLib.getInstance().init(AF_DEV_KEY, getConversionListener(), getApplicationContext());
    AppsFlyerLib.getInstance().start(this);
    // Do your magic to get the customerUserID
    // ...
    // any AppsFlyer SDK code invoked here will be discarded
   //Call the following API once the customerUserID is available:
 AppsFlyerLib.getInstance().setCustomerIdAndLogSession("customer_id", this);
  }
}

class AFApplication: Application() {
 private val afDevKey = ""

 override fun onCreate() {
  super.onCreate()
  val conversionDataListener = object: AppsFlyerConversionListener {
   ...
  }
  AppsFlyerLib.getInstance().waitForCustomerUserId(true);
  //WARNING! Removing above line doesn't cancel its effect.
  // Replace with this to stop waiting for CUID:
  // AppsFlyerLib.getInstance().waitForCustomerUserId(false);
  AppsFlyerLib.getInstance().init(afDevKey, conversionDataListener, this)
  AppsFlyerLib.getInstance().start(this)
  // Do your magic to get the customerUserID
  // ...
  // any AppsFlyer SDK code invoked here will be discarded
  // Call the following API once the customerUserID is available:
  AppsFlyerLib.getInstance().setCustomerIdAndLogSession("customer_id", this)
 }
}

Para aprender más acerca de cómo retrasar la inicialización del SDK hasta que esté disponible el ID de usuario de cliente, ve aquí.

Desde la versión 4.8.0 del SDK, AppsFlyer recopila automáticamente el google_advertising_id.

El requisito de recopilar el ID de Publicidad de Google solo es relevante para SDK versiones 4.7.X e inferiores.

Se debe recopilar al menos un identificador de dispositivo exclusivo para permitir la atribución. Los siguientes identificadores están disponibles: ID de publicidad de Google (GAID), ID de Android, IMEI y OAID.

GAID: ID de publicidad de Google

Se recopila automáticamente de las aplicaciones que contienen Google Play Services. Si el GAID está disponible, el IMEI y el ID de Android NO deben ser recopilados por la aplicación, para evitar la violación de la política de Google Play .

IMEI y ID de Android

Desactivado por defecto. SOLO se puede recopilar para aplicaciones que NO contienen Google Play Services.
Nota: A partir de Android 10 (nivel de API 29), lanzado a finales de 2019, el acceso al parámetro IMEI está restringido.

Para enviar estos ID a AppsFlyer:

1. En la aplicación abierta, recopila el IMEI del dispositivo y/o el ID de Android.
2. Llama a las siguientes API ANTES de llamar al método start:
   

   AppsFlyerLib.getInstance().setImeiData("IMEI_HERE");
   AppsFlyerLib.getInstance().setAndroidIdData("ANDROID_ID_HERE");

OAID: Identificador de anunciante abierto

Guía para implementar OAID

Optar por no recopilar el ID del dispositivo

Los desarrolladores pueden optar por no recopilar el IMEI, ID de Android y OAID utilizando las siguientes API: 

AppsFlyerLib.getInstance().setCollectIMEI(false);
AppsFlyerLib.getInstance().setCollectAndroidID(false);
AppsFlyerLib.getInstance().setCollectOaid(false);

En algunos casos extremos, tal vez necesites desactivar todo el registro del SDK para cumplir con la ley y las políticas de privacidad. Puedes hacer esto con la API stop. Una vez invocada esta API, el SDK deja de funcionar y ya no se comunica con los servidores de AppsFlyer.

AppsFlyerLib.getInstance().stop(true, getApplicationContext());

AppsFlyerLib.getInstance().stop(true, applicationContext);

Existen varios casos para que un usuario opte por la exclusión. Es muy recomendable que sigas las instrucciones exactas para la situación correspondiente a tu aplicación.

El SDK se puede reactivar llamando a:

AppsFlyerLib.getInstance().stop(false, getApplicationContext());
AppsFlyerLib.getInstance().start(getApplicationContext(), <AF_DEV_KEY>);

AppsFlyerLib.getInstance().stop(false, applicationContext);
AppsFlyerLib.getInstance().start(applicationContext, <AF_DEV_KEY>);

No coloques start si stop está configurado como true. Puedes verificar el estado actual del SDK llamando a:

AppsFlyerLib.getInstance().isStopped() // returns true if SDK is stopped, false otherwise

AppsFlyerLib.getInstance().isStopped // returns true if SDK is stopped, false otherwise

Usa esta API durante la Inicialización del SDK para anonimizar explícitamente las instalaciones, los eventos y las sesiones de un usuario:

public void anonymizeUser(boolean isDisabled);

Ejemplo de uso:

AppsFlyerLib.getInstance().anonymizeUser(true);

Para reiniciar el registro, puedes llamar a anonymizeUser configurado en false.

En algunos casos, es posible que los anunciantes deseen dejar de compartir datos a nivel de usuario con las redes de publicidad o los partners para usuarios específicos. Las razones para esto incluyen: 

• Políticas de privacidad como la CCPA o el RGPD
• Mecanismos de exclusión opcional de los usuarios
• Competencia con algunos partners (redes de publicidad, terceros)

AppsFlyer proporciona dos métodos de la API para dejar de compartir datos con algunos o todos los partners:

• setSharingFilter: Utilizado por los anunciantes para establecer algunas (una o más) redes/partners integrados para excluir de la obtención de datos.
• setSharingFilterForAllPartners: utilizado por anunciantes para excluir todas las redes/partners integrados de la obtención de datos.

Estos métodos de filtrado son compatibles a partir del SDK V5.4.1.

El método de filtrado debe llamarse cada vez que se inicializa el SDK y afecta a toda la sesión. Si se necesita tiempo para determinar si es necesario configurar los filtros de compartición, entonces retrasa la inicialización del SDK. 

Cuando el método se activa antes de la primera llamada a start:

• Los usuarios de SRN se atribuyen como orgánicos, y sus datos no se comparten con los partners integrados.
• Los usuarios que hacen clic en las redes de publicidad (no SRN) se atribuyen correctamente en AppsFlyer, pero no se comparten con las redes de publicidad a través de postbacks, API, reportes de raw data o por cualquier otro método.

Actualmente, los datos de desinstalación no pueden filtrarse con estos métodos. Sin embargo, puedes dejar de enviar los eventos de desinstalación a los partners usando sus páginas de configuración en AppsFlyer.