Bâtir une stratégie d'analytiques des apps à abonnement dans iOS 14.5+

Les services d'abonnement sont en plein essor avec une dépense mensuelle moyenne de 20 $ par client. Bien que seulement 1 % des applications tirent leurs revenus des abonnements, plus de 90 % des dépenses des consommateurs mobiles proviennent des applications à abonnement. Face à de tels revenus potentiels, les développeurs se doivent d'optimiser leur funnel avec la plus grande efficacité.

Comme nous l'avions indiqué dans un article récent avec gamesindustry.biz, il est encore plus important que les applications monétisant via des abonnements disposent d'une bonne stratégie de consentement utilisateur à partir d'iOS 14.5+  pour s'assurer de collecter des données déterministes tout au long du cycle de vie des utilisateurs. Pour les applications à abonnement, le parcours utilisateur est généralement plus long et complexe que dans les autres stratégies de monétisation, et il vous faut donc obtenir autant de données que possible.

Mais il est également important de définir un plan SKAdNetwork efficace pour les utilisateurs non consentants afin de pouvoir analyser la LTV utilisateur avec une certaine confiance.

Obtenir le consentement

Les applications obtenant des taux de consentement élevés prendront le pas sur la concurrence, car elles seront non seulement en mesure d'accéder aux données factuelles et déterministes de leurs utilisateurs, mais aussi de créer des modèles basés sur le comportement des utilisateurs consentants.

Grâce aux invites avant autorisation, les utilisateurs comprendront plus facilement l'intérêt de donner leur accord au suivi. Nous avons réuni pour vous de nombreux conseils pour créer la meilleure invite avant autorisation possible.

Pour optimiser vos applications à abonnement, il vous faut disposer de certaines informations essentielles sur les utilisateurs ; par exemple, les moments où leur méthode de paiement a échoué, où ils ont mis en pause, annulé ou réactivé leurs abonnements, etc. La solution Adjust de tracking des abonnements vous permet de visualiser le cycle de vie des utilisateurs de façon inédite. Toutefois, sans l'IDFA, il est chaque jour plus difficile de dégager des données fiables sur le parcours parfois sinueux des utilisateurs vers la conversion.

Utiliser SKAdNetwork

Pour les applications générant des revenus via les abonnements, iOS 14.5+ présente une difficulté double. Il est d'abord complexe de différer le délai SKAdNetwork au-delà de 24 heures, même s'il est possible d'en tirer parti pour rassembler des informations utiles sur vos utilisateurs.

Vous pouvez toujours de gagner du temps en utilisant un bit pour prolonger la fenêtre de conversion, en déclenchant simplement une mise à jour de la valeur de conversion périodiquement (p. ex. de 000001 à 000011 et ainsi de suite) pour relancer une nouvelle période de 24 heures, mais cela exige que l'utilisateur se connecte quotidiennement afin que le déclenchement de valeur de conversion puisse s'exécuter avec l'application en arrière-plan. Si l'utilisateur ne rouvre pas l'application, la valeur de conversion n'est pas mise à jour et vous perdez les données que vous espériez obtenir pour prolonger le délai de collecte.

Ensuite, il est également difficile d'obtenir suffisamment de données sur l'utilisateur dans les 24 premières heures pour établir des prévisions à long terme. Avec un nombre limité de points de contact, en raison du nombre restreint de valeurs possibles en 6 bits, vous devez vous concentrer sur celles qui vous paraissent les plus importantes et exploiter au maximum les 24 premières heures.

Signal VS bruit

Vous pouvez utiliser les 6 bits du SKAdNetwork de deux façons : La première consiste à utiliser une approche de « masquage de bits » : vous affectez chacun des six bits à un événement et, lorsque le bit est défini sur 0 ou sur 1, vous savez si un événement s'est produit ou pas.

Notre solution SKAdNetwork standard vous permet de mapper des événements de conversion aux événements d'abonnement que vous avez déjà suivis dans le dashboard Adjust.

La deuxième option consiste à affecter des plages de valeurs aux différentes valeurs de conversion, ce qui vous permet de créer des « buckets » d'utilisateurs (séparés en fonction des plages qui leur correspondent). Notre système de gestion avancée des valeurs de conversion prend en charge la création de schémas personnalisés pour définir ces buckets.

Pour les applications de streaming vidéo ou de rencontres, l'engagement utilisateur compte parmi les métriques les plus importantes. Certains clients basent leur optimisation sur l'emploi des conditions « sessions » dans notre solution avancée.

Une condition « sessions » vous permet de suivre le nombre total de sessions réalisées. Dans l'exemple ci-dessous, une valeur de conversion « 3 » sera renvoyée si l'utilisateur comptabilise entre 5 et 10 sessions.

"sessions": { "count_min": 5, "count_max": 10 }

• count_min (par défaut, 1) – Le montant total de sessions suivies ne doit pas être inférieur au montant spécifié ;
• count_max (par défaut, illimité) – Le montant total de sessions suivies ne doit pas dépasser le montant spécifié ;

Création d'un modèle

La modélisation prédictive de la LTV utilise le comportement d'un utilisateur lors de son premier jour d'utilisation de l'app pour prédire les revenus à moyen terme. De tels modèles prédictifs fonctionnent mieux avec les buckets ou les catégories plus larges.

Pour cette raison, les applications à abonnement peuvent utiliser « trial start» comme signal SKAdNetwork pour l'optimisation, car il peut survenir de manière plus fiable dans la fenêtre où vous avez de la visibilité, mais aussi parce qu'il s'agit d'une action dans cette fenêtre initiale pleine d'intentions.

Toutefois, vous limiter à utiliser « trial start » peut vous mener sur la mauvaise pente. Et sans informations sur les événements se produisant pendant l'essai, dans l'après-IDFA, il va devenir encore plus délicat d'estimer qu'un essai gratuit fait nécessairement apparaître un utilisateur générant des revenus.

L'essai

Pour cette raison, considérez plutôt « trial start » comme un signal supplémentaire et connexe susceptible d'enrichir le type d'essai. Par exemple, un utilisateur peut déclencher « trial start » et recevoir une valeur de conversion initiale. Vous pouvez ensuite mettre à jour la valeur de conversion s'il annule l'essai pendant la fenêtre de valeur de conversion. Ce mode opératoire permet d'écarter un grand nombre de personnes peu susceptibles de payer, et de créer un bucket d'utilisateurs « canceled trial » dont nous savons que la LTV est vraisemblablement plus faible.

En usant d'une approche différente, vous pouvez souhaiter suivre les personnes ayant souscrit à un essai gratuit et inclure leurs informations de paiement. Celles qui donnent leurs informations de paiement expriment déjà une prédisposition à la conversion et peuvent devenir des utilisateurs payants sur le long terme.

Si vous avez des questions sur l'implémentation d'iOS 14.5+, n'hésitez pas à contacter votre CSM ou Account Manager. Notre guide est disponible au téléchargement ici ou consultez notre centre de ressources iOS 14.5+.