Skip to main content

Vue d’ensemble

Les SDK mobiles construisent les événements avec des helpers typés et les envoient au même collecteur que le tag web. Une seule instance gère la collecte et la personnalisation : l’identité est donc partagée.
Sur toutes les plateformes, un événement se construit puis s’envoie en deux temps : un builder retourne l’événement, send() l’envoie. La construction n’a aucun effet de bord : vous pouvez enrichir ou abandonner l’événement avant l’envoi. Les instructions d’installation de chaque plateforme sont sur les pages Android, iOS et Flutter.

Constructeurs d’événements

L’ordre des arguments de purchase diffère selon la plateforme : Android attend transId avant labels, iOS et Flutter l’attendent en dernier. Utilisez les arguments nommés quand le langage le permet.
Les labels sont des paires clé/valeur String stockées comme labels interrogeables sur l’événement. Réservez-les aux dimensions que vous filtrez dans un Workflow — locale, magasin, version de l’application — et non aux données à forte cardinalité.

Identité

setUser() stocke l’identité sur l’appareil (SharedPreferences sur Android, UserDefaults sur iOS, shared preferences sur Flutter) et envoie un événement identify lorsque la valeur change. Appelez-la après le login et après restauration d’une session au démarrage — les appels répétés avec la même valeur n’ont aucun effet. D’ici là, les événements ne portent que l’identité anonyme de l’appareil (tmpId) : l’identifiant publicitaire sur Android quand le suivi est autorisé, identifierForVendor sur iOS, sinon un identifiant aléatoire généré une fois et persisté.
iOS expose ReelevantAnalytics.clearStorage() pour effacer l’identifiant utilisateur stocké, l’identifiant temporaire et la file de retry — à appeler à la déconnexion sur un appareil partagé.

Contexte d’écran

Chaque événement porte un champ url. Dans une application il vaut unknown par défaut : renseignez-le à la navigation pour pouvoir filtrer les événements par écran.
Utilisez un schéma et une structure de chemin stables : le champ est indexé en texte, des chemins cohérents simplifient les filtres dans un Workflow.

Garanties de livraison

Les trois SDK se comportent de la même façon en cas d’échec : send() ne remonte pas les échecs de transport à l’appelant : ils sont journalisés et mis en file. La méthode peut en revanche lever une erreur si elle est appelée avant que le SDK ait initialisé l’identité de l’appareil ; encadrez donc les appels effectués tôt dans le cycle de vie de l’application.

Ressources associées