Beaucoup d'entreprises font tourner un site et une application mobile, les mesurent avec deux outils différents, et découvrent que les deux ne s'accordent jamais sur quoi que ce soit. La réponse habituelle est de retenir le chiffre qui soutient l'argument du moment. Voici ce qui va réellement de travers, et ce qui doit être vrai d'un outil pour qu'il couvre les deux sans vous mentir.

Les quatre choses qui diffèrent vraiment

Il est tentant de traiter une application comme un site avec un moins bon navigateur. Quatre différences font tomber cette hypothèse, et tout outil qui mesure les deux doit avoir une réponse pour chacune.

Il n'y a pas d'URL. Un site a une adresse de page qui sert en même temps de nom, de hiérarchie et de moyen de regrouper les choses. Une application a des écrans, dont vous choisissez les noms et que vous pouvez changer. Rien n'impose la cohérence : Checkout, checkout et CheckoutViewController finissent donc en trois écrans dans le même rapport.

Il n'y a pas de chargement de page. Sur le web, une navigation est un événement évident et observable que le navigateur annonce. Dans une application, passer d'un écran à l'autre est un appel de fonction. Si rien ne l'instrumente, rien n'est enregistré, et aucune erreur n'est levée.

Le réseau n'est pas fiable. Un onglet de navigateur est généralement en ligne. Une application ne l'est régulièrement pas : un tunnel, un avion, une zone morte. Les événements doivent être mis en file sur l'appareil et envoyés plus tard, ce qui veut dire qu'un outil qui suppose que l'ordre d'arrivée est l'ordre du temps les mettra dans le désordre, et qu'un outil qui n'a aucune idée qu'un événement a été mis en file l'horodatera de travers.

Les sessions se terminent différemment. Une session web expire après une période d'inactivité, conventionnellement trente minutes. Une application passe en arrière-plan, et peut y rester des jours avant de revenir au premier plan avec son processus toujours vivant. Une règle de session naïve rapporte une session qui a duré quatre jours.

Ce que « au même endroit » devrait vouloir dire, et ce que cela veut dire d'habitude

La plupart des outils qui annoncent les deux font l'une de deux choses, et la différence compte davantage que ce que le marketing laisse entendre.

La première est un tableau de bord partagé au-dessus de deux jeux de données entièrement séparés. Vous obtenez un seul identifiant de connexion. Vous n'obtenez pas un seul chiffre, parce que les deux côtés comptent des choses différentes et que rien ne les réconcilie.

La seconde est un seul jeu de données avec une colonne de plateforme, pour qu'un rapport puisse être filtré ou découpé. C'est ce que les gens croient habituellement acheter.

Il y a un troisième dispositif, et il vaut la peine d'être énoncé clairement parce que c'est celui qui provoque les disputes : une application et un site sont vraiment des choses différentes, et les forcer dans une seule entité produit des rapports où ni l'une ni l'autre n'est juste. Un écran vu n'est pas une page vue. Une application a des versions, un site n'en a pas. Une application plante ; un site renvoie un 500.

Le dispositif utile est qu'ils sont des entités séparées avec leurs propres identifiants, mesurées par le même produit, rapportées dans la même interface, facturées depuis le même compte. Vous pouvez regarder l'un sans que la forme de l'autre ne déteigne dessus, et vous pouvez regarder les deux.

Des questions qui valent la peine d'être posées à un fournisseur

  • Comment le SDK se comporte-t-il hors ligne ? Précisément : met-il en file, combien d'événements, que se passe-t-il quand la file est pleine, et préserve-t-il l'horodatage d'origine plutôt que l'heure d'envoi ?
  • Qu'advient-il d'un événement mal formé ? Un SDK qui réessaie éternellement un événement définitivement rejeté est un problème de batterie et de forfait data pour vos utilisateurs. Le bon comportement est de l'abandonner et de compter l'abandon.
  • Le format de fil est-il versionné ? Les applications ne se mettent pas à jour en un jour. Une fraction de vos utilisateurs sera sur une compilation d'il y a un an, et le serveur doit continuer d'accepter ce que cette compilation envoie.
  • Comment le nom d'un écran est-il décidé ? Si la réponse est « ce que vous passez », demandez ce que l'outillage fait pour le garder cohérent.
  • Quelle est la règle de session après un passage en arrière-plan ? Un chiffre précis, pas « nous gérons cela ».

Cette troisième question attrape plus de vrais problèmes que toutes les autres réunies, et c'est celle que personne ne pose. Un traceur web peut être changé en modifiant une page et est en ligne l'après-midi même. Un SDK d'application part quand l'application part, est adopté sur des semaines ou des mois, et n'atteint jamais tout le monde. Casser le format que vos anciennes compilations envoient n'est pas un bug que vous pouvez corriger à chaud ; c'est une flotte d'installations qui cessent de rapporter.

Où Skomi se situe

Skomi traite une application mesurée comme sa propre entité, avec son propre espace de clés, à côté des sites plutôt qu'à l'intérieur. Les rapports vivent dans le même compte et se parcourent de la même façon, mais une application n'est jamais décrite comme un site et ses écrans ne sont jamais appelés des pages.

Il y a des SDK pour les plateformes courantes, et le format de fil qu'ils parlent est versionné et figé, précisément parce qu'une ancienne compilation ne peut pas être réparée à distance. La page App Analytics couvre ce qui est mesuré et quelles plateformes sont prises en charge.

Les crédits sont partagés sur tout le compte (sites et applications indifféremment), si bien qu'ajouter une application n'est pas un second abonnement. La page des tarifs contient l'arithmétique.

Les deux moitiés gardent leur propre vocabulaire là où elles diffèrent (un site a des pages vues, une application a des écrans vus), et partagent la fenêtre de session qui les rend comparables.