Intégrer le SDK

Découvrez comment initialiser et démarrer le SDK iOS.

Recommandé

Get started with our SDK integration wizard

  • Vous devez installer le SDK Android.
  • Vérifiez que dans le fichier build.gradle de votre app, applicationIda une valeur defaultConfig (dans le bloc) qui correspond à l'ID d'app AppsFlyer.
  • Récupérez la clé dev AppsFlyer. Vous en aurez besoin pour pouvoir initialiser le SDK.

Initialisation du SDK Android

Il est recommandé d'initialiser le SDK dans la classe/sous-classe d'app globale. Cela permet de s'assurer que le SDK peut démarrer dans n'importe quel scénario (par exemple, le deep linking).

Étape 1 : importer AppsFlyerLib

Dans votre classe d'app globale, importez AppsFlyerLib:

import com.appsflyer.AppsFlyerLib;
import com.appsflyer.AppsFlyerLib

Étape 2 : initialiser le SDK
Dans l'application globale onCreate, call init avec les arguments suivants :

AppsFlyerLib.getInstance().init(<YOUR_DEV_KEY>, null, this);
AppsFlyerLib.getInstance().init(<YOUR_DEV_KEY>, null, this)
  1. Le premier argument est votre clé dev AppsFlyer.
  2. Le second argument est de type Nullable. AppsFlyerConversionListener. Si vous n'avez pas besoin de données de conversion, nous vous recommandons de passer un fichier null comme deuxième argument. Pour plus d'informations, veuillez consulter les Données de conversion.
  3. Le troisième argument est le contexte d'app.

Démarrage du SDK Android

Dans la méthode onCreate de l'app, après avoir appelé init, call start et passez-lui le contexte de l'app comme premier argument :

AppsFlyerLib.getInstance().start(this);
AppsFlyerLib.getInstance().start(this)

Deferring SDK start

OPTIONNELLE
Vous pouvez différer l'initialisation du SDK en appelant start depuis une classe Activity, au lieu de l'appeler depuis la classe Application. init devra toujours être appelé dans la classe Application.

Le démarrage différé du SDK est généralement utilisé lorsqu'une app attend le consentement de l'utilisateur avant de collecter des données dans l'Activité principale, et qu'elle appelle start après avoir obtenu le consentement de l'utilisateur.

⚠️

Avis important

Lorsque l'app appelle start depuis une activité, elle doit transmettre le contexte d'activité au SDK. Si le contexte d'activité n'est pas transmis, le SDK ne se déclenchera pas, les données d'attribution et événements in-app seront alors perdus.

Starting with a response listener

Pour recevoir la confirmation que le SDK a bien été lancé, créez un objet AppsFlyerRequestListener passez-le comme troisième argument de start:

AppsFlyerLib.getInstance().start(getApplicationContext(), <YOUR_DEV_KEY>, 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, <YOUR_DEV_KEY>, 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)
    }
})
  • The onSuccess() La méthode de callback est invoquée toutes les 200 réponses à une demande d'attribution opérée par le SDK.
  • The onError(String error) La méthode de callback est invoquée pour toute autre réponse et renvoie la réponse comme chaîne d'erreur.

Exemple complet

L'exemple suivant montre comment initialiser et démarrer le SDK à partir de la classe Application.

import android.app.Application;
import com.appsflyer.AppsFlyerLib;
// ...
public class AFApplication extends Application {
    // ...
    @Override
    public void onCreate() {
        super.onCreate();
        // ...
        AppsFlyerLib.getInstance().init(<YOUR_DEV_KEY>, null, this);
        AppsFlyerLib.getInstance().start(this);
        // ...
    }
    // ...
}
import android.app.Application
import com.appsflyer.AppsFlyerLib
// ...
class AFApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        // ...
        AppsFlyerLib.getInstance().init(<YOUR_DEV_KEY>, null, this)
        AppsFlyerLib.getInstance().start(this)
        // ...
    }
    // ...
}

Lien github

Setting the Customer User ID

OPTIONNELLE

The Customer User ID (CUID) is a unique user identifier created by the app owner outside the SDK. It can be associated with in-app events if provided to the SDK. Once associated with the CUID, these events can be cross-referenced with user data from other devices and applications.

Set the customer User ID

Once the CUID is available, you can set it by calling  setCustomerUserId.


...
AppsFlyerLib.getInstance().init(<YOUR_DEV_KEY>, conversionListener, this);  
AppsFlyerLib.getInstance().start(this , <YOUR_DEV_KEY> );
...
// Do your magic to get the customerUserID...
...
AppsFlyerLib.getInstance().setCustomerUserId(<MY_CUID>);

The CUID can only be associated with in-app events after it was set. Since start was called before setCustomerUserID, the install event will not be associated with the CUID. If you need to associate the install event with the CUID, see the below section.

Associate the CUID with the install event

If it’s important for you to associate the install event with the CUID, you should set it before calling start.

You can set the CUID before start in two ways, depending on whether you start the SDK in the Application or the Activity class.

When starting from the application class

If you started the SDK from the Application class (see: Starting the Android SDK) and you want the CUID to be associated with the install event, put the SDK in waiting mode to prevent the install data from being sent to AppsFlyer before the CUID is provided.

To activate the waiting mode, set waitForCustomerUserId to true after init and before start.

⚠️

Important

It's important to remember that putting the SDK in a waiting mode may block the SDK from sending the install event and consequently prevent attribution. This can occur, for example, when the user launches the application for the first time and then exits before the SDK can set the CUID.

AppsFlyerLib.getInstance().init(<YOUR_DEV_KEY>, getConversionListener(), getApplicationContext());
AppsFlyerLib.getInstance().waitForCustomerUserId(true);
AppsFlyerLib.getInstance().start(this);

After calling start, you can add your custom code that makes the CUID available.

Once the CUID is available, the final step includes setting the CUID, releasing the SDK from the waiting mode, and sending the attribution data with the customer ID to AppsFlyer. This step is performed using the call to setCustomerIdAndLogSession.

AppsFlyerLib.getInstance().setCustomerIdAndLogSession(<CUSTOMER_ID>, this);

Other than setCustomerIdAndLogSession, do not use setCustomerUserId or any other AppsFlyer SDK functionality, as the waiting SDK will ignore it.

Note

If you wish to remove the waiting mode from the SDK initialization flow, it is not enough to delete the call to waitForCustomerUserId(true). It is also required to replace it with waitForCustomerUserID(false). Simply removing the call is insufficient because the 'waitForCustomerUserId' boolean flag is stored in the Android Shared Preferences.

Example code

public class AFApplication extends Application {
  @Override
  public void onCreate() {
    super.onCreate();
    AppsFlyerConversionListener conversionDataListener = 
    new AppsFlyerConversionListener() {
      ...
    };
    AppsFlyerLib.getInstance().init(<YOUR_DEV_KEY>, getConversionListener(), getApplicationContext());
    AppsFlyerLib.getInstance().waitForCustomerUserId(true);
    AppsFlyerLib.getInstance().start(this);
    // Do your magic to get the customerUserID
    // any AppsFlyer SDK code invoked here will be discarded
    // ...
    // Once the customerUserID is available, call setCustomerIdAndLogSession(). 
    // setCustomerIdAndLogSession() sets the CUID, releases the waiting mode,
    // and sends the attribution data with the customer ID to AppsFlyer.
    AppsFlyerLib.getInstance().setCustomerIdAndLogSession(<CUSTOMER_ID>, this);
  }
}

When starting from the Activity class

If you started the SDK from an Activity (see: Deferring SDK start) class and you want the CUID to be associated with the install event, set the CUID beforestart.

Log sessions

The SDK sends an af_app_opened message whenever the app is opened or brought to the foreground. Before the message is sent, the SDK makes sure that the time passed since sending the last message is not smaller than a predefined interval.

Setting the time interval between app launches

Appelez setMinTimeBetweenSessions to set the minimal time interval that must lapse between two af_app_opened messages. The default interval is 5 seconds.

Logging sessions manually

You can log sessions manually by calling logSession.

Activation du mode débogage

OPTIONNELLE
Vous pouvez activer les journaux de débogage en appelant setDebugLog:

AppsFlyerLib.getInstance().setDebugLog(true);
AppsFlyerLib.getInstance().setDebugLog(true)

📘

Remarque

Pour que les journaux de débogage soient complets, veillez à appeler setDebugLog avant d'invoquer d'autres méthodes du SDK.

Voir l'exemple.

🚧

Avertissement

Pour éviter la fuite d'informations sensibles, assurez-vous que les journaux de débogage sont désactivés avant de distribuer l'app.

Test de l'intégration

OPTIONNELLE
Pour obtenir des instructions détaillées sur les tests d'intégration, vous pouvez consulter notre guide du test de l'intégration SDK Android.