Analytics

Analytics enregistre les écrans et les actions importantes de ton app. Tu exploites ensuite ces événements dans le dashboard : suivi, funnel, tableau de bord.

Le SDK suit seul les installations, les mises à jour et les sessions ; tu déclares les écrans et les événements métier. Aucun compte externe : une fois le SDK initialisé, les événements arrivent dans ton projet Appwin.

Installation

1. 1

   Installe Appwin Core et Analytics

   Analytics repose sur Appwin Core. Pas encore installé ? Commence par le Quickstart, qui installe Core et tes modules pour chaque plateforme.

   Compatibilité et paquets par plateforme

   Plateforme	Appwin Core	Module Analytics
   iOS 16+	produit SPM AppwinCore	produit SPM AppwinAnalytics
   Android 7.0+ (API 24)	io.appwin:appwin-core	io.appwin:appwin-analytics
   Flutter 3.35+	appwin_core	appwin_analytics
   React Native 0.75+	@appwin/react-native	inclus dans le même paquet
   Web (navigateurs récents)	@appwin/web	inclus dans le même paquet

2. 2

   Initialise Analytics

   Appelle initialize() au démarrage, après Appwin Core. Le résultat indique si Analytics est actif pour ton plan ; la collecte démarre au verdict ready.

   iOSFlutterAndroidReact NativeWeb

   swift

   import AppwinAnalytics
   
   let result = await AppwinAnalytics.initialize()
   guard result.isReady else { return }
   

   Un appel répété est sans danger : le SDK garde le dernier verdict pour démarrer hors ligne.

Méthodes disponibles

Vérifier l'état du module

Sur iOS et Android, isReady relit le dernier verdict sans relancer initialize(). React Native expose la méthode asynchrone isReady(). Flutter n'a pas d'accesseur séparé : garde le résultat d'initialize().

Choisir les événements à suivre

Un événement décrit un fait utile à l'analyse, pas la forme de l'interface : onboarding_completed survit à un changement de bouton ou d'étapes.

Trois règles pour un plan de tracking exploitable :

1. un nom stable en snake_case, formulé comme une action accomplie ;
2. les valeurs variables dans les propriétés, pas dans le nom ;
3. un déclenchement unique, à l'action confirmée.

Ce que le SDK enregistre automatiquement

Core les envoie dès configure, quels que soient les modules installés : aucun initialize() n'est nécessaire. Ne les envoie pas toi-même. screen_view et install_referrer sont aussi réservés : le premier vient de screen(), le second est géré automatiquement.

Sur le web, un site ne s'installe pas : app_install et app_update ne sont jamais envoyés, et push_opt_in et push_opened n'existent pas. Les sessions et app_open / app_background (onglet visible ou masqué) démarrent dès createAppwin, avant analytics.initialize(). À la place, chaque page ouverte produit un screen_view nommé d'après son chemin (/pricing), navigations d'une single-page app comprises. La query string n'est jamais enregistrée. Passe initialize({ pageViews: false }) pour appeler screen() toi-même. Une session couvre tous les onglets ouverts du site.

Envoyer un événement

AppwinCore.track() prend le nom de l'événement et, au besoin, quelques propriétés pour filtrer ou comparer ensuite. C'est le même appel pour tous les modules.

AppwinCore.track("onboarding_completed", props: [
  "steps_count": 4,
  "notifications_enabled": true,
])

L'événement part dans une file persistée sur l'appareil, sans attendre le réseau : hors ligne, le SDK renverra plus tard.

Les propriétés acceptent seulement des chaînes, des nombres et des booléens. Pas d'objet imbriqué, de tableau, ni de donnée personnelle inutile.

:::note AppwinAnalytics.track (appwin.analytics.track() sur le web) marche encore mais est déprécié : il passe par le même flux qu'AppwinCore.track(). N'appelle que l'un des deux pour un même événement, sinon il est compté deux fois. :::

Enregistrer les écrans consultés

Appelle screen() quand l'utilisateur arrive réellement sur un écran. Le nom décrit sa fonction et reste stable même si son titre change.

AppwinAnalytics.screen("home")

Chaque appel produit un événement screen_view, ensuite disponible dans les filtres et les étapes d'un funnel. Sur le web, les pages sont déjà enregistrées : screen() sert aux vues qui ne sont pas des pages, comme une modale ou une étape.

Relier les événements à un utilisateur

Les événements utilisent l'appareil et la session gérés par Appwin Core : pas besoin d'ajouter un identifiant dans chaque événement.

Quand ton app connaît l'utilisateur connecté, rattache la session à son compte via Identité. Ses événements sont alors reconnus sur ses différents appareils.

Configurer le consentement

Le consentement se règle avec AppwinCore.setConsent(state, purpose), par finalité : analytics (stockage dans Analytics, replay, fil d'Ariane des crashs), marketing (parcours) et advertising (régies). Sans finalité, l'appel règle les trois.

Le SDK utilise granted par défaut. Ce choix technique n'est pas un conseil juridique : l'état initial dépend de tes finalités, de ta configuration et des règles applicables à ton app.

Pour attendre une décision, appelle setConsent(unknown) avant configure : le SDK garde les premiers événements sur l'appareil, sans les envoyer, jusqu'au passage à granted.

AppwinCore.setConsent(.unknown)

AppwinCore.setConsent(.granted) // envoie les événements en attente
AppwinCore.setConsent(.denied)  // purge la file et arrête la collecte

AppwinCore.setConsent(.denied, for: .marketing) // seulement le marketing

Les états s'appliquent à chaque finalité. Si aucune finalité n'est accordée, rien n'est envoyé et la file est vidée ; sinon un événement part une fois, avec les finalités accordées à cet instant. Un refus purge aussi le replay déjà enregistré. advertising n'est pas AppwinAttribution.setAdvertisingConsent : voir Attribution.

:::note AppwinAnalytics.setConsent est déprécié : il règle les trois finalités, comme AppwinCore.setConsent(state). AnalyticsConsent (AppwinAnalyticsConsent sur Flutter et React Native) est un alias déprécié de ConsentState ; sur Android, c'est un typealias Kotlin, donc le code Java doit passer à ConsentState. :::

Vérifier la réception des données

Lance l'app, ouvre un écran, déclenche un événement de test. Dans le dashboard, ouvre Analytics → All charts : les noms reçus apparaissent à la création d'un graphique ou d'un funnel.

L'envoi est automatique : toutes les 30 secondes, à partir de 20 événements, au passage en arrière-plan ou au retour du réseau.

Forcer l'envoi pendant un test

flush() envoie immédiatement les événements en attente. Utilise-la pour vérifier une intégration, pas après chaque événement.

Si un événement manque, vérifie dans l'ordre :

1. initialize() a répondu ready ;
2. le consentement n'est ni denied ni unknown ;
3. le nom respecte les règles ci-dessous ;
4. le réseau est revenu.

Règles et limites

Un nom invalide ou réservé est ignoré et produit une trace en développement. Le SDK ne lève pas d'exception : une mesure ne doit pas interrompre l'app.

Pays d'un événement

Chaque événement porte un country (filtre et découpage, code ISO), posé par Appwin à la réception : le pays du compte store que lit le SDK (storefront de l'App Store, Play Billing si votre app l'embarque), sinon celui de l'IP d'où part l'événement. Seul le pays est gardé, jamais l'IP. Vide quand aucun des deux n'est connu : événements envoyés avant le 9 novembre 2026, ou app dont le SDK précède le pays du store et dont l'IP n'est pas localisable. Géolocalisation IP par DB-IP (CC BY 4.0).

Suite