Integración de SDK de Android para desarrolladores

Usa uno de los siguientes métodos para agregar el SDK a tu aplicación:

• [Mejores prácticas] Uso de Gradle
• Agregar el SDK manualmente

El referente de instalación de Android mejora la precisión de la atribución, protege contra las instalaciones fraudulentas y mucho más. Es compatible con la versión 4.8.6 del SDK de AppsFlyer para Android.

Existen dos maneras de agregar el referente de instalación a tu aplicación:

• Usar Gradle (recomendado)
• Agregar manualmente el referente de instalación

Agregar permisos ayuda a aumentar la velocidad del modelo probabilístico de atribución. Esto también permite que el SDK envíe más datos como los datos de redes de proveedores y WiFi. Puedes encontrar estos datos en los reportes de raw data y usarlos para analizar y optimizar las campañas.

Agrega los permisos necesarios

1. Agrega los siguientes permisos a AndroidManifest.xml:
   

   <uses-permission android:name="android.permission.INTERNET" />
   <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
   <uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
   

El BroadcastReceiver obtiene información de Google Play que AppsFlyer usa para la atribución. Al usar el BroadcastReceiver, se aumenta la velocidad de atribución.

Las siguientes dos opciones están disponibles para implementar el receptor de transmisión de referencia de instalación:

<application>
	<receiver android:name="com.appsflyer.SingleInstallBroadcastReceiver" android:exported="true">
		<intent-filter>
			 <action android:name="com.android.vending.INSTALL_REFERRER" />
		 </intent-filter>
	</receiver>
</application>

<application>
	<receiver android:name="com.appsflyer.MultipleInstallBroadcastReceiver" android:exported="true">
		<intent-filter>
			<action android:name="com.android.vending.INSTALL_REFERRER" />
		</intent-filter>
	</receiver>
</application>

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.

¡Atención! El uso de una clave de desarrollador errónea o incorrecta tiene impacto en todo el tráfico enviado desde el SDK y causa problemas de atribución y de reportes.

Para recuperar tu clave de desarrollador:

1. Ve al panel de control de tu aplicación. 
2. En el panel de control, en Configuración, haz clic en Configuración de la aplicación.
3. Copia tu clave de desarrollador.
   

   

Registrar la clase de aplicación global

En el archivo AndroidManifest.xml, dentro de la etiqueta application, agrega la siguiente línea:

android:name="<APP.PACKAGE.NAME>.<AFApplication>"

• <APP.PACKAGE.NAME>: reemplaza esto por el nombre del paquete de aplicaciones.
• <AFApplication>: reemplaza esto por el nombre que has establecido para la clase de aplicación global.

Esta línea en el manifest.xml indica a la aplicación cuál es la aplicación global. Como mencionamos anteriormente, al hacer esto, el SDK de AppsFlyer SDK queda accesible a nivel global en toda la aplicación.

Inicializar el SDK

Te recomendamos inicializar el SDK dentro de la clase global de la aplicación. Esto permite que el SDK se inicialice en todos los escenarios, incluidos los enlaces profundos.

Los pasos que se enumeran a continuación tienen lugar dentro de la clase global de la aplicación.

1. Dentro de la clase global de la aplicación, importa las siguientes bibliotecas:
   

   import android.app.Application;
   import android.util.Log;
   import com.appsflyer.AppsFlyerLib;
   import com.appsflyer.AppsFlyerConversionListener;
   import java.util.Map;

2. Dentro de la clase global, asigna tu clave de desarrollador a una variable, de preferencia con el nombre AF_DEV_KEY. 
   
   Importante: es crucial usar la clave de desarrollador correcta al inicializar el SDK. El uso de una clave de desarrollador errónea o incorrecta tiene impacto en todo el tráfico enviado desde el SDK y causa problemas de atribución y de reportes.
   
   
   Java Kotlin

   public class AFApplication extends Application {
       private static final String AF_DEV_KEY = "qrdZGj123456789";
       
       //...
       
   }
   

   class AFApplication : Application() {
       private val devKey = "qrdZGj123456789";
   
       //...
       
   }
   

3. Dentro de la clase global , después de la llamada a super.onCreate(), implementa el AppsFlyerConversionListener. Consulta el código a continuación en el paso 4.
4. Dentro de la clase global, después del ConversionListener, inicializa el SDK usando el método init(). 
   
   Java Kotlin

   public class AFApplication extends Application {
       private static final String AF_DEV_KEY = "qrdZGj123456789";
       
       @Override
       public void onCreate() {
           super.onCreate();
           AppsFlyerConversionListener conversionListener = new AppsFlyerConversionListener() {
               @Override
               public void onConversionDataSuccess(Map<String, Object> conversionData) {
               
                       for (String attrName : conversionData.keySet()) {
                       Log.d("LOG_TAG", "attribute: " + attrName + " = " + conversionData.get(attrName));
                   }
               }
   
               @Override
               public void onConversionDataFail(String errorMessage) {
   		   Log.d("LOG_TAG", "error getting conversion data: " + errorMessage);
               }
   
               @Override
               public void onAppOpenAttribution(Map<String, String> attributionData) {
                   for (String attrName : attributionData.keySet()) {
                       Log.d("LOG_TAG", "attribute: " + attrName + " = " + attributionData.get(attrName));
                   }
               }
   
               @Override
               public void onAttributionFailure(String errorMessage) {
                   Log.d("LOG_TAG", "error onAttributionFailure : " + errorMessage);
               }
           };
           
           AppsFlyerLib.getInstance().init(AF_DEV_KEY, conversionListener, this);
   
       }
   }
                 

   class AFApplication : Application() {
       private val devKey = "qrdZGj123456789";
   
       override fun onCreate() {
           super.onCreate()
           val conversionDataListener  = object : AppsFlyerConversionListener{
               override fun onConversionDataSuccess(data: MutableMap<String, Any>?) {
                   data?.let { cvData ->
                       cvData.map {
                           Log.i(LOG_TAG, "conversion_attribute:  ${it.key} = ${it.value}")
                       }
                   }
               }
   
               override fun onConversionDataFail(error: String?) {
                   Log.e(LOG_TAG, "error onAttributionFailure :  $error")
               }
   
               override fun onAppOpenAttribution(data: MutableMap<String, String>?) {
                   data?.map {
                       Log.d(LOG_TAG, "onAppOpen_attribute: ${it.key} = ${it.value}")
                   }
               }
   
               override fun onAttributionFailure(error: String?) {
                   Log.e(LOG_TAG, "error onAttributionFailure :  $error")
               }
           }
   
           AppsFlyerLib.getInstance().init(devKey, conversionDataListener, this)
       }
   }
   

5. Dentro de la clase global de la aplicación, llama a start().
   
   Java Kotlin

   AppsFlyerLib.getInstance().start(this);
   

   AppsFlyerLib.getInstance().start(this)

Para retrasar la inicialización del SDK, puedes llamar a start desde la clase Actividad.

Esta opción puede utilizarse si, por ejemplo, es necesario posponer el start hasta que se reciba el consentimiento del usuario debido a los requisitos del RGPD o la CCPA, etc.

Al invocar start en la clase Actividad:

• Asegúrate de pasar la instancia de actividad como un argumento y no aplicación.
• Si planeas usar las funciones de enlaces profundos, agrega la API start() a cualquier otra Actividad para la que puedas establecer enlaces profundos y que no tenga start.

Antes de empezar a probar las instalaciones, registra el dispositivo de prueba.

Las instalaciones orgánicas son instalaciones sin atribuir que, por lo general, son instalaciones directas desde tiendas de aplicaciones.

Para simular una instalación orgánica

1. Asegúrate de tener un dispositivo móvil conectado a tu computadora.
2. En Android Studio, abre el Logcat.
3. Desde Android Studio, instala la aplicación en el dispositivo o emulador.
4. Espera a que se inicie la aplicación.
5. En el Logcat, busca el nombre de paquete de tu aplicación.

Deberías ver lo siguiente:

La parte resaltada en la captura de pantalla indica que el SDK notifica una instalación orgánica. Estos datos provienen del método onConversionDataSuccess en la clase AFApplication. Más adelante en esta guía, se explica cómo obtener datos de conversión.

Nota: A partir del SDK V5, onConversionDataSuccess es el nombre del método para obtener datos de conversión. Si estás utilizando una versión del SDK inferior a 5.0.0, el nombre del método es onInstallConversionDataLoaded. Recomendamos que actualices al SDK 5.0.0. Para aprender más, haz clic aquí.

Ahora debería aparecer una instalación orgánica en la página de Información general del panel de control de la aplicación.

Si no ves ninguna instalación en el panel de control, consulta nuestra guía de resolución de problemas del SDK.

Una instalación no orgánica es una instalación atribuida que, por lo general, tiene lugar después de una instancia de captación (engagement) de un anuncio. Para simular una instalación no orgánica, puedes usar enlaces de atribución.

Para simular una instalación no orgánica:

1. En el manifiesto, averigua cuál es el nombre de paquete de tu aplicación, p. ej., com.company.app.
   • En la siguiente URL, reemplaza <app_id> por el nombre del paquete de tu aplicación:
     

     https://app.appsflyer.com/<app_id>?pid=Test&c=Test

     Por ejemplo:

     https://app.appsflyer.com/id0123456789?pid=Test&c=Test

   • El parámetro c especifica el nombre de la campaña.
   • El parámetro pid especifica el nombre de la fuente de medios a la que se atribuye la instalación.
   • Si se prueba el clic desde una computadora, se debe agregar un ID de publicidad de Google (GAID) (agregando &advertising_id=<GAID> al final del enlace en el paso 1).
2. Envía esta URL al dispositivo.  Por ejemplo, puedes hacer esto por correo electrónico o WhatsApp. 
3. En el dispositivo, haz clic en la URL.
   • Si la aplicación figura en la tienda de aplicaciones, se te redirigirá a la tienda de aplicaciones. No descargues e instales la aplicación desde la tienda de aplicaciones. Sigue con el paso 5.
   • Si la aplicación no figura en la tienda de aplicaciones y aún se encuentra en desarrollo, la pantalla muestra un mensaje de que la aplicación no se encuentra disponible en la tienda de aplicaciones. Simplemente sigue con el paso 5.
4. En Android Studio, abre el Logcat.
5. Conecta el dispositivo a tu computadora con un cable USB.
6. Desde Android Studio, instala la aplicación en el dispositivo.
7. En el Logcat, busca el nombre de paquete de tu aplicación.

Deberías ver lo siguiente:

Ahora debería aparecer una instalación no orgánica en la página de Información general del panel de control de la aplicación.

El SDK tiene dos interfaces relacionadas con los eventos in-app:

• AFInAppEventType: constantes para nombres de eventos in-app.
• AFInAppEventParameterName: constantes para nombres de parámetros de eventos in-app.

Es muy recomendable que uses estas dos interfaces por los siguientes motivos:

• La nomenclatura estándar permite que AppsFlyer asigne automáticamente eventos a redes de autorreporte (SRN) como Facebook, Google, Twitter y Snapchat.
• Compatibilidad con versiones anteriores: si AppsFlyer decide cambiar el nombre de cualquier evento o parámetro de evento, tu implementación será compatible con las versiones anteriores.

Para usar estas dos interfaces, es necesario que las importes:

import com.appsflyer.AFInAppEventParameterName;
import com.appsflyer.AFInAppEventType;

Aquí encontrarás la lista de estructuras y nombres de eventos recomendados.

Puedes enviar los ingresos con cualquier evento in-app. Usa el parámetro de evento af_revenue (AFInAppEventParameterName.REVENUE) para incluir los ingresos en el evento in-app. Puedes llenarlo con cualquier valor numérico, positivo o negativo.

af_revenue es el único parámetro de evento que AppsFlyer cuenta como ingreso real en los raw data (datos sin procesar) y en el panel de control. Para más detalles, haz clic aquí.

Cuando envíes eventos con ingresos, ten en cuenta lo siguiente:

• Si estableces el código de divisa (mira el ejemplo a continuación), debe ser un código ISO 4217 de 3 caracteres. (la opción predeterminada es USD).
• Puedes establecer el código de divisa para todos los eventos llamando el siguiente método: AppsFlyer.setCurrencyCode("ZZZ"). Para obtener información sobre la configuración, visualización y conversión de divisas, consulta nuestra guía sobre las divisas de los ingresos..
• El valor de los ingresos no debe contener comas separadoras, signos de divisas ni texto. Por ejemplo, un evento generador de ingresos debería ser similar a 1234.56.

Ejemplo: evento de compra in-app con ingresos

Map<String, Object> eventValue = new HashMap<String, Object>();
eventValue.put(AFInAppEventParameterName.REVENUE,1234.56);
eventValue.put(AFInAppEventParameterName.CONTENT_TYPE,"Shirt");
eventValue.put(AFInAppEventParameterName.CONTENT_ID,"1234567");
eventValue.put(AFInAppEventParameterName.CURRENCY,"USD");
AppsFlyerLib.getInstance().logEvent(getApplicationContext() , AFInAppEventType.PURCHASE , eventValue);

val eventValue = HashMap<String, Any>() 
eventValue.put(AFInAppEventParameterName.REVENUE,1234.56)
eventValue.put(AFInAppEventParameterName.CONTENT_TYPE,"Shirt")
eventValue.put(AFInAppEventParameterName.CONTENT_ID,"1234567")
eventValue.put(AFInAppEventParameterName.CURRENCY,"USD")
AppsFlyerLib.getInstance().logEvent(getApplicationContext() , AFInAppEventType.PURCHASE , eventValue)

El evento de compra anterior tiene asociados $1234,56 en ingresos y aparece como ingresos en el panel de control.

Registro de ingresos negativos

Puede haber situaciones en las que quieras registrar ingresos negativos.

Por ejemplo, un usuario recibe un reembolso por un par de zapatos que te compró.

Map<String, Object> eventValue = new HashMap<String, Object>();
eventValue.put(AFInAppEventParameterName.REVENUE,-200);
eventValue.put(AFInAppEventParameterName.CONTENT_TYPE,"shoes");
eventValue.put(AFInAppEventParameterName.CONTENT_ID,"4875");
eventValue.put(AFInAppEventParameterName.CURRENCY,"USD");
AppsFlyerLib.getInstance().logEvent(getApplicationContext() , "cancel_purchase" , eventValue);

val eventValue = HashMap<String, Any>()
eventValue.put(AFInAppEventParameterName.REVENUE, -200)
eventValue.put(AFInAppEventParameterName.CONTENT_TYPE, "category_a")
eventValue.put(AFInAppEventParameterName.CONTENT_ID, "1234567")
eventValue.put(AFInAppEventParameterName.CURRENCY, "USD")
AppsFlyerLib.getInstance().logEvent(applicationContext,  "cancel_purchase", eventValue)

El SDK de AppsFlyer proporciona validación de recibos del servidor para las compras in-app. Para validar una compra, llama a validateAndLogInAppPurchase.

Esta llamada genera automáticamente un evento in-app de tipo af_purchase, dado que la compra está validada.

public static void validateAndLogInAppPurchase(Context context, 
String publicKey, String signature, String purchaseData, 
String price, String currency, HashMap<String, String> additionalParameters);

Parámetros de método

• String publicKey: clave pública de la consola para desarrolladores de Google
• String signature: firma de transacción (devuelta por la API de Google cuando se finaliza la compra)
• String purchaseData: producto comprado en formato JSON (devuelto por la API de Google cuando se finaliza la compra)
• String price: ingresos del evento in-app que deben notificarse a AppsFlyer.
• String currency: divisa del evento in-app que debe notificarse a AppsFlyer
• HashMap<String, String> additionalParameters: parámetros adicionales del evento in-app que aparecen en el campo event_value de los raw data del evento in-app.

Devoluciones de llamadas para indicar intentos de validación de compras satisfactorios o con errores

Si quieres saber si el intento de validar la compra es satisfactorio o no, implementa registerValidatorListener en la clase de tu aplicación. Este elemento de escucha tiene dos bloques de devolución de llamada, uno para indicar que el intento es "satisfactorio" y otro para indicar que hubo un "error" (por cualquier motivo, incluido un error de validación).

AppsFlyerLib.getInstance().registerValidatorListener(this,new
   AppsFlyerInAppPurchaseValidatorListener() {
     public void onValidateInApp() {
       Log.d(TAG, "Purchase validated successfully");
     }
     public void onValidateInAppFailure(String error) {
       Log.d(TAG, "onValidateInAppFailure called: " + error);
     }
});

AppsFlyerLib.getInstance().registerValidatorListener(this, object : AppsFlyerInAppPurchaseValidatorListener {
    override fun onValidateInApp() {
       	Log.d(LOG_TAG, "Purchase validated successfully")
    }

    override fun onValidateInAppFailure(error: String) {
        Log.d(LOG_TAG, "onValidateInAppFailure called: $error")
   }
})

Ejemplo de uso de la validación de compra:

// Purchase object is returned by Google API in onPurchasesUpdated() callback
private void handlePurchase(Purchase purchase) {
    Log.d(LOG_TAG, "Purchase successful!");
    Map<String, String> additional_event_values = new HashMap<>();
    additional_event_values.put("some_parameter", "some_value");
    String price= "10";
    String currency = "USD";
    AppsFlyerLib.getInstance().validateAndLogInAppPurchase(getApplicationContext(), PUBLIC_KEY, purchase.getSignature(), purchase.getOriginalJson(), revenue, currency, additional_event_values);
}

// Purchase object is returned by Google API in onPurchasesUpdated() callback
private fun handlePurchase(Purchase purchase) {
   Log.d(LOG_TAG, "Purchase successful!");
   val additional_event_values = HashMap<String, String>()
   additional_event_values.put("some_parameter", "some_value");
   val price= "10";
   val currency = "USD";
   AppsFlyerLib.getInstance().validateAndLogInAppPurchase(this, PUBLIC_KEY, purchase.getSignature(), purchase.getOriginalJson(), revenue, currency, additional_event_values);
}

Al validar una compra in-app, se envía automáticamente un evento de compra in-app a AppsFlyer. Mira a continuación una muestra de los datos que se pasan en el parámetro event_value:

{
   "some_parameter":"some_value", // from additional_event_values
   "af_currency":"USD", // from currency
   "af_content_id":"test_id", // from purchase
   "af_revenue":"10", // from revenue
   "af_quantity":"1", // from purchase
   "af_validated":true // flag that AF verified the purchase
}

• Nombre del evento: hasta 45 caracteres
• Valor del evento: no debe superar los 1000 caracteres; si es más largo, es probable que lo trunquemos.
• Precios e ingresos: usa solo dígitos y decimales, p. ej. 5 o 5.2.
• Los valores de precios e ingresos pueden tener hasta 5 dígitos después del punto, p. ej., 5.12345
• Se admiten caracteres no ingleses, en eventos in-app, otras API de SDK, a partir de Android SDK V4.8.1.

Puedes registrar eventos in-app al llamar a trackEvent con el nombre de evento y los parámetros de valor. Consulta la documentación sobre eventos in-app para conocer más detalles.

A continuación, te mostramos un ejemplo de cómo registrar un evento de compra. Para ver una lista completa de fragmentos de código listos por segmento vertical, consulta nuestra guía de eventos in-app enriquecidos por segmento vertical.

Ejemplo: evento de compra in-app

Map<String,Object> eventValues = new HashMap<>();
eventValues.put(AFInAppEventParameterName.REVENUE, 1200);
eventValues.put(AFInAppEventParameterName.CURRENCY, "JPY");
eventValues.put(AFInAppEventParameterName.CONTENT_TYPE, "Shoes");
AppsFlyerLib.getInstance().logEvent(this, AFInAppEventType.PURCHASE, eventValues);

val eventValues = HashMap<String, Any>();
eventValues.put(AFInAppEventParameterName.REVENUE, 1200)
eventValues.put(AFInAppEventParameterName.CURRENCY, "JPY")
eventValues.put(AFInAppEventParameterName.CONTENT_TYPE, "Shoes")
AppsFlyerLib.getInstance().logEvent(this, AFInAppEventType.PURCHASE, eventValues)

Si un usuario inicia un evento cuando no tiene conexión a Internet, AppsFlyer igualmente podrá registrarlo. Así es como funciona:

1. El SDK envía los eventos a los servidores de AppsFlyer y espera una respuesta.
2. Si el SDK no recibe una respuesta 200, el evento se almacena en el caché.
3. Una vez recibida la respuesta 200, el evento almacenado se vuelve a enviar al servidor.
4. Si hay múltiples eventos en el caché, se envían al servidor uno tras otro.

Puedes configurar un agente de escucha al atribuir eventos in-app. El agente de escucha te permite definir la lógica para dos escenarios:

• Evento in-app registrado con éxito.
• Error en el registro de un evento in-app.

AppsFlyerLib.getInstance().logEvent(getApplicationContext(), AFInAppEventType.PURCHASE, eventValue, new AppsFlyerRequestListener() {
                    @Override
                    public void onSuccess() {
                        Log.d(LOG_TAG, "Event sent successfully");
                    }
                    @Override
                    public void onError(int i, @NonNull String s) {
                        Log.d(LOG_TAG, "Event failed to be sent:\n" +
                                "Error code: " + i + "\n"
                                + "Error description: " + s);
                    }
                });

AppsFlyerLib.getInstance().logEvent(getApplicationContext(), AFInAppEventType.PURCHASE, eventValue, object : AppsFlyerRequestListener {
            override fun onSuccess() {
                Log.d(LOG_TAG, "Event sent successfully")
            }
            override fun onError(errorCode: Int, errorDesc: String) {
                Log.d(LOG_TAG, "Event failed to be sent:\n" +
                        "Error code: " + errorCode + "\n"
                        + "Error description: " + errorDesc)
            }
        })

En caso de que se produzca un error durante la grabación del evento in-app, 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.

OneLink detecta el tipo de dispositivo al hacer clic y redirige al usuario al destino correspondiente, p. ej., Google Play, tienda de aplicaciones iOS, mercados fuera de la tienda o páginas web.

En la guía sobre redireccionamiento de OneLink, analizamos la implementación de enlaces de atribución multiplataforma (sin necesidad de codificación del SDK). También es la base para los enlaces profundos.

Los enlaces profundos te permiten enviar a usuarios hacia actividades específicas y ofrecerles contenido personalizado. Esto resulta particularmente útil cuando se ejecutan campañas de retargeting.

Para configurar enlaces profundos con OneLink, un marketer con acceso al panel de control de AppsFlyer y un desarrollador con acceso a la aplicación deben trabajar juntos.

Consulta nuestra guía sobre configuración de enlaces profundos con OneLink.

Los enlaces profundos diferidos te permiten establecer enlaces profundos con usuarios nuevos y ofrecerles contenido personalizado después de que instalen la aplicación. Esto es diferente con respecto a los enlaces profundos normales, en los que la aplicación ya debe estar instalada en el dispositivo del usuario.

Para configurar enlaces profundos diferidos con OneLink, el desarrollador también necesita acceso al panel de control de AppsFlyer.

La configuración de enlaces profundos diferidos es prácticamente igual a la de los enlaces profundos regulares. La única diferencia es que necesitas implementar una lógica adicional en la aplicación a fin de establecer enlaces profundos con los usuarios y ofrecerles contenido personalizado después de que instalen e inicien la aplicación.

Consulta nuestra guía sobre enlaces profundos diferidos para aprender más.

El SDK te proporciona los datos de conversión o captación (engagement) después de cada instalación o evento de enlaces profundos. Puedes usar estos datos para personalizar el contenido y el comportamiento de la aplicación de manera programática.

Para obtener datos de enlaces profundos cuando se usa el enlace profundo directo y se abre la aplicación, implementa el método onAppOpenAttribution.

Para obtener datos de re-engagement de enlaces profundos manualmente en cualquier momento, implementa el método performOnAppAttribution.Esto permite el acceso a los datos de re-engagement sin registrar un re-engagement nuevo.

Consulta nuestra guía sobre datos de enlaces profundos para aprender más.

El método addPushNotificationDeepLinkPath proporciona a los propietarios de aplicaciones una interfaz flexible para configurar cómo se extraen los enlaces profundos de las cargas útiles de notificaciones push.

De forma predeterminada, el SDK busca un valor de enlace profundo en la clave af de la carga útil JSON de una notificación push. Sin embargo, muchos proveedores de push usan esquemas propios de JSON que el SDK no puede resolver sin una configuración adicional.

addPushNotificationDeepLinkPath permite configurar qué clave de la carga útil de la notificación push usa el SDK para el valor de enlace profundo.

Usa este método si estás integrando tu aplicación con proveedores push que no usan el esquema JSON de notificación push predeterminado que el SDK espera.

Al llamar a addPushNotificationDeepLinkPath, el SDK verifica lo siguiente:

• La clave requerida existe en la carga útil.
• La clave contiene una URL válida de OneLink.

addPushNotificationDeepLinkPath debe llamarse antes de llamar a start().

Configuración básica

Considera la siguiente llamada a addPushNotificationDeepLinkPath

AppsFlyerLib.getInstance().addPushNotificationDeepLinkPath("deeply", "nested", "deep_link");                       

AppsFlyerLib.getInstance().addPushNotificationDeepLinkPath("deeply", "nested", "deep_link");

y estas situaciones.

Situación 1

Tu aplicación se invoca a través de notificación push. Contiene una carga útil estructurada de la siguiente manera.

{
    ...
    "deeply": {
        "nested": {
            "deep_link": "https://yourdeeplink2.onelink.me"
        }
    }
    ...
}

En este escenario, el SDK extrae el valor de deep_link y procede con el flujo de enlaces profundos.

Situación 2

Tu aplicación se invoca a través de notificación push. Contiene una carga útil estructurada de la siguiente manera.

{
    ...
    "deeply": {
        "nested": {
            "banana": "https://yourdeeplink2.onelink.me"
        }
    },
    ...
}

En este escenario, cuando la llamada se ejecuta, el SDK no puede encontrar la clave deep_link en la carga útil. Por lo tanto, no pasa nada.

Situación 3

Tu aplicación se invoca a través de notificación push. Contiene una carga útil estructurada de la siguiente manera.

{
    ...
    "deeply": {
        "nested": {
            "deep_link": "Corrupted url or regular string"
        }
    },
    ...
}

En este escenario, aunque el SDK encuentra la clave deep_link, su valor de enlace profundo no es válido. Por lo tanto, cuando la llamada anterior se ejecuta, no ocurre nada.

Configuración avanzada

Para configurar varias estructuras de carga útil posibles, llama a addPushNotificationDeepLinkPath varias veces:

• Se utiliza la primera llamada que produce un valor de enlace profundo válido
• Se ignoran las otras llamadas

Si ninguna de las estructuras de la carga útil coincide o no se encuentra una URL de OneLink válida en la carga útil, no ocurre nada.

Por ejemplo, considera la siguiente carga útil:

{
    ...
    "deeply": {
        "nested": {
            “deep_link”: “https://yourdeeplink2.onelink.me”
        }
    },
    “this”: {
        “is”: {
            "banana": "phone"
        }
    }
    ...
}

y las siguientes llamadas a addPushNotificationDeepLinkPath.

// this.is.deep_link key isn’t found - nothing happens
AppsFlyerLib.getInstance().addPushNotificationDeepLinkPath("this", "is", "deep_link");
// this.is.banana key found, but contains invalid OneLink URL - nothing happens
AppsFlyerLib.getInstance().addPushNotificationDeepLinkPath("this", "is", "banana");
// deeply.nested.deep_link key found and contains valid OneLink URL - proceed deep linking flow
AppsFlyerLib.getInstance().addPushNotificationDeepLinkPath("deeply", "nested", "deep_link");

// this.is.deep_link key isn’t found - nothing happens
AppsFlyerLib.getInstance().addPushNotificationDeepLinkPath("this", "is", "deep_link");
// this.is.banana key found, but contains invalid OneLink URL - nothing happens
AppsFlyerLib.getInstance().addPushNotificationDeepLinkPath("this", "is", "banana");
// deeply.nested.deep_link key found and contains valid OneLink URL - proceed deep linking flow
AppsFlyerLib.getInstance().addPushNotificationDeepLinkPath("deeply", "nested", "deep_link");

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.

Cómo obtener un ID de usuario de cliente:

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

Retrasar la inicialización del SDK para customerUserID

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() // devuelve true si el SDK está parado, caso contrario, false

AppsFlyerLib.getInstance().isStopped // devuelve true si el SDK está parado, caso contrario, false

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 los anunciantes para excluir a 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.