En bref : La mesure des sessions est utilisée par les annonceurs pour mesurer l'engagement des utilisateurs d'applications au cours d'une période donnée.
Principes de comptage des sessions
Le nombre de sessions, ou lancements, effectuées par les utilisateurs est un indicateur important qui sert à mesurer l'engagement des utilisateurs envers l'application. Elle est disponible via plusieurs rapports et tableaux de bord. Les sessions sont utilisées pour calculer les paramètres suivants :
- Utilisateurs actifs quotidiens (DAU)
- Utilisateurs actifs mensuels (MAU)
- Rétention
- Utilisateurs loyaux utilisant le réglage par défaut de l'ouverture de 3 applications
Attention ! Dans le cas des sessions organiques, l'indicateur est disponible dans les tableaux de bord Activité et Cohorte, mais pas dans le tableau de bord Vue d'ensemble.
Calcul des sessions
La mesure des sessions est calculée à l'aide de l'événement af_app_opened reporté par le SDK. Un intervalle minimal entre les sessions contrôle les sessions enregistrées côté serveur.
L'événement af_app_opened s'affiche comme un lancement dans les données brutes des sessions disponibles via Data Locker. Les sessions ne sont pas disponibles via d'autres outils de reporting. Pour faciliter la compréhension, nous utiliserons dans cet article le terme af_app_opened.
Rapport sur les sessions
Une session est signalée par le SDK lorsque l'une des situations suivantes se produit :
- L'utilisateur lance l'app.
- Lorsque l'app passe de l'arrière-plan au premier plan. Le développeur peut modifier le comportement des rapports en appelant setMinTimeBetweenSessions .
- Un rapport de session explicite par le développeur dans les applications Android. C'est le cas, par exemple, des applications utilitaires qui sont toujours en arrière-plan.
Mesure des sessions
La métrique des sessions est comptabilisée en tenant compte d'un mécanisme de temps minimum entre les sessions avec une durée par défaut de 10 minutes comme décrit dans l'exemple qui suit.
Mécanisme de délai minimum entre les sessions
Le mécanisme a une incidence sur le nombre de sessions. Attention ! Si le temps minimum entre deux sessions est long (plus d'une heure) et que les utilisateurs n'ouvrent pas l'application plusieurs fois par jour, certains indicateurs liés aux sessions, tels que le DAU et la fidélisation, peuvent être affectés. Cela est particulièrement vrai dans le cas des applications que les utilisateurs ouvrent généralement une fois par jour.
Description et exemple
Le mécanisme régit les sessions qui sont comptabilisées. Une session est comptabilisée si le temps minimum autorisé entre les sessions s'est écoulé.
Le flux est le suivant : Une session est comptée → Un compte à rebours démarre → Les sessions signalées pendant le compte à rebours ne sont pas prises en compte.
Exemple
Supposition: Le délai minimum autorisé entre les réglages des sessions est de 10 minutes.
| Exemple de cas | Heures d’enregistrement de la session (nombre de minutes depuis 00:00) | Nombre de sessions comptabilisées | Les sessions ne sont pas prises en compte |
|---|---|---|---|
| A | 0, 10, 20, 30 | 4 | Aucun |
| B | 0, 1, 9, 11 | 2 | 1, 9 |
| C | 0, 10, 15, 21 | 3 | 15 |
Réglage de la minuterie
- Valeur par défaut : 10 minutes
-
Les valeurs possibles sont les suivantes :
-
<1-60 Minutes
-
1-24 heures
-
Pour définir le temps minimum autorisé entre les sessions :
- Dans AppsFlyer, dans le menu latéral, sélectionnez Paramètres > Paramètres de l'application.
- Définir le délai minimum entre les sessions.
- Cliquez sur Enregistrer les paramètres.
Le changement prend effet dans l'heure.
Thèmes liés aux sessions
Sessions de retargeting
- Les sessions de retargeting sont disponibles à partir du 12 juillet 2020.
-
Sessions de retargeting disponibles
- Retargeting et type de vue unifiée dans le tableau de bord.
-
Les vues de la cohorte concernée, c'est-à-dire retargeting et unifié.
- Dans le cas d'un affichage unifié, si les sessions ont été attribuées à un UA et à une source média de retargeting, la source média de retargeting prévaut et l'UA ne s'affiche pas.
- Fraîcheur des données* Tous les jours à 13:00 UTC.
-
Data Locker : Les rapports sur les sessions de retargeting peuvent être activés ; ils comprennent les sessions de réengagement et de réattribution.
- Fraîcheur des données* Décalage de 6 heures.
- Pendant les fenêtres de réengagement, les sessions sont attribuées à la fois à l'UA et à la source média de retargeting. De même, d'autres événements de réengagement in-app sont doublement attribués.
- Dans le cas de Google Ads et X Ads, pour éviter les postbacks dupliqués, l'événement af_app_opened n'est envoyé qu'une seule fois.
Sessions postbacks de sessions vers les partenaires
Vous pouvez envoyer des postbacks de sessions partenaires de manière à ce qu'un postback soit envoyé pour chaque session comptabilisée.
- Pour envoyer le postback : associer explicitement af_app_opened à un événement partenaire. Attention ! Dans le rapport de données brutes d'AppsFlyer disponible via Data Locker, cet événement est considéré comme un lancement.
- Il faut tenir compte du fait qu'il s'agit d'un événement à fort volume et que de nombreux partenaires ne souhaitent pas le recevoir.
Remarque
Le mappage de af_app_opened n'est pris en charge que par les partenaires dont les sessions d'envoi sont activées.
Rapport de session par l'application (SDK)
Côté application : Le SDK envoie af_app_opened chaque fois que l'application est ouverte ou mise au premier plan après avoir pris en compte le paramètre setMinTimeBetweenSessions du SDK.
Côté serveur : Les sessions rapportées par l'application sont comptées et enregistrées après avoir pris en compte le mécanisme de temps minimum entre les sessions. Les sessions comptabilisées sont attribuées selon les mêmes règles d'attribution que les autres événements in-app.
Signalement explicite des sessions par le développeur (applications Android uniquement)
Utilisez logSession dans Android pour signaler explicitement une session. Un appel équivalent n'est pas disponible sous iOS.
- Les applications qui fonctionnent en permanence en arrière-plan peuvent nécessiter une certaine logique mise en œuvre par le développeur pour signaler les sessions. Par exemple, les applications utilitaires telles que les économiseurs de batterie, les lanceurs, les verrouillages d'écran et les applications antivirus. Pour ces types d'applications, envisagez de déclarer une session tous les jours à minuit ou à un autre intervalle approprié à l'application.
- Dans d'autres cas, vous pouvez vouloir compter les sessions lorsque les utilisateurs effectuent une action dans l'application, par exemple en appuyant sur le bouton d'effacement de la mémoire, etc.
Fixer un délai minimum entre les lancements d'applications
Dans le SDK, définissez le temps minimum qui peut s'écouler entre deux sessions pour qu'elles soient signalées séparément.
Utiliser setMinTimeBetweenSessions, c'est-à-dire l'événement af_app_opened, pour contrôler le temps minimum qui doit s'écouler entre les sessions afin que chacune d'entre elles soit signalée.
- [Par défaut] cinq secondes. Cela signifie qu'au moins 5 secondes doivent s'écouler avant qu'une autre session ne soit signalée.
- L'API permet de définir le temps minimum requis entre les sessions.
Le setMinTimeBetweenSessions référence SDK :
VoirsetMinTimeBetweenSessions dans la référence du SDK Android
Voir minTimeBetweenSessions dans la référence du SDK iOS
Voir setMinTimeBetweenSessions référence du SDK Unity pour