En raison de la façon différente dont les visites et les lancements d’applications mobiles sont calculés, il est possible de voir des résultats différents dans les rapports.

  • Visites : conçue à l’origine pour les analyses web, une visite représente une période d’activité des visiteurs suivant ou précédant 30 minutes ou plus d’inactivité. Voir Visites pour plus d’informations.
  • Session d’application mobile : en raison des différences dans les modèles d’utilisation des applications mobiles, une session mobile est généralement définie différemment d’une visite Web. Chaque session d’application mobile commence par un événement de lancement et se termine par une période de cinq minutes pendant lesquelles l’application est en arrière-plan ou fermée. Le nombre de sessions mobiles est répertorié comme un nombre d’événements de lancement. Reportez-vous à la section Mesure mobiles pour plus d’informations.

Plus de visites que de lancements - Données datant d’avant Juin 2016

Avant juin 2016, l’application Adobe oubliait les informations relatives à la session après expiration d’une visite (30 minutes d’inactivité). Les données horodatées correspondant à une session terminée sont considérées comme une visite supplémentaire. En juin 2016, Adobe prévoit de conserver des données de session avec horodatage pendant 92 jours. Ce changement ne modifie pas la définition d’une visite. Les visites représentent toujours des groupes d’accès suivant ou précédant 30 minutes ou plus d’inactivité. En revanche, il permet aux accès horodatés tardifs d’être associés correctement à une visite, empêchant ainsi l’inflation des visites.

Les éléments suivants peuvent expliquer pourquoi les visites renvoient des valeurs plus élevées que les lancements pour les données datant d’avant juin 2016 :

  • Antidatage d’informations de session pour SDK 4,1+ : les kits de développement logiciel mobile d’Adobe Analytics collectent des informations sur la durée de chaque session et sur le nombre de pannes qui surviennent. Ces données ne peuvent pas être envoyées aux serveurs de collecte de données avant le début de la session suivante.

    Avant SDK 4,1, les données de la visite précédente étaient envoyées lors de la première requête d’image de la visite suivante. Toutefois, ces données étaient temporairement associées à la visite actuelle au lieu de la visite précédente. Dans SDK 4,1 ainsi que dans les versions ultérieures, les informations concernant la session précédente sont envoyées avec un accès différent et sont horodatées en fonction de la session précédente.

    Bien que l’antidatage soit plus utile pour calculer les mesures mobiles, il peut entraîner un effet secondaire. Cet accès distinct qui fournit plus d’informations sur la visite précédente correspond aux critères d’une nouvelle visite. Si une nouvelle session se produit à plus de 30 minutes d’intervalle de la session mobile précédente, l’accès antidaté est considéré comme étant une visite supplémentaire sans que le nombre de lancements n’augmente.
  • Données en file d’attente / par lots avec suivi hors ligne : si une application est configurée pour la collecte hors ligne de données, le périphérique mobile met en cache le comportement qui se produit hors ligne. Lorsque le périphérique est de nouveau en ligne, le kit de développement logiciel envoie des accès hors ligne mis en cache et commence à envoyer des accès en ligne. Si la période entre les portions hors ligne du comportement de l’utilisateur est supérieure à 30 minutes, une visite supplémentaire sera comptabilisée une fois envoyée aux serveurs de collecte de données.

Nombre de visites supérieur au nombre de lancements - Données datant d’après juin 2016

Certaines applications mobiles fonctionnent aussi en arrière-plan. Si ces appels sont envoyés à plus de 30 minutes d’intervalle (pour rappel, 30 minutes d’inactivité équivalent à une nouvelle visite dans Adobe Analytics) pendant que l’application mobile se trouve en arrière -plan, une nouvelle visite démarre pour chaque appel sans déclencher de lancement. 

Techniquement, il est possible d’afficher une page (ou un lien personnalisé) qui génère une nouvelle visite sans lancement.

Il est très important de comprendre que les visites et les lancements sont calculés différemment :

  • Les visites sont calculées côté serveur, en fonction de l’activité du serveur (horodatage des accès reçus dans le serveur).
  • Les lancements sont calculés côté client, en fonction de l’activité de l’application.

En outre, dans iOS il est possible d’utiliser la méthode keepLifecycleSessionAlive pour signifier au SDK de ne pas démarrer une nouvelle session (lancement) en reprenant son activité après avoir été en arrière-plan, qu’elle que soit la valeur lifecycleTimeout affichée sur le fichier de configuration :

https://marketing.adobe.com/resources/help/fr_FR/mobile/ios/sdk_methods.html

Des données supplémentaires sont désormais automatiquement envoyées de la version 4.13.6 vers le SDK (iOS et Android) sur chaque accès Analytics, indiquant si l’application était au premier plan ou à l’arrière-plan au moment où l’accès a été généré :

https://github.com/Adobe-Marketing-Cloud/mobile-services/releases

Plus de lancements que de visites

En raison des différences d’inactivité entre les sessions mobiles et les visites, plusieurs lancements peuvent être déclenchés en une seule visite. Par exemple, si un utilisateur mobile ouvre et ferme l’application toutes les 15 minutes pendant une longue période, de nombreux lancements sont comptabilisés dans une seule visite.

Alignement des visites et des lancements

Si les appels trackLocation très espacés font augmenter le nombre de visites, il faut réduire le temps entre les appels à moins de 30 minutes ou désactiver la fonction trackLocation.

Si l’ensemble des données implique des données datant d’avant juin 2016, vous devriez envisager d’utiliser des segments et des mesures calculées pour exclure les accès antidatés. Utilisez cette méthode si le nombre de lancements est supérieur au nombre de visites en raison des accès antidatés sur SDK 4,1+.
  1. Créez un segment à partir de l’accès défini par Exclure l’accès quand le lien personnalisé est égal à ADBINTERNAL:SessionInfo
  2. Créez une mesure segmentée et calculée à l’aide du segment ci-dessus par rapport aux visites.
  3. Utilisez cette mesure calculée au lieu des visites régulières lors de la visualisation des rapports.

    Remarque :
    si le segment ci-dessus est appliqué à un rapport en dehors d’une mesure calculée, les effets secondaires suivants se produiront :
    • Les incidents signalent des zéros pour les plages de dates où des accès antidatés se produisent
    • La durée de la session précédente renvoie des zéros pour les périodes où les accès antidatés se produisent
    • Les occurrences sont réduites par le nombre d’accès antidatés
    • Les occurrences de lien personnalisé sont réduites par le nombre d’accès antidatés

Ce produit est distribué sous licence Creative Commons Attribution - Pas d’utilisation commerciale - Partage à l’identique 3.0 non transposé  Les publications Twitter™ et Facebook ne sont pas couvertes par les dispositions Creative Commons.

Mentions légales   |   Politique de confidentialité en ligne