Monétisation et IAP dans iOS 14.5+

En avril dernier, le marketing mobile a connu une petite révolution lorsque Apple a finalement dévoilé les règles de son framework AppTrackingTransparency (ATT).

Pour les applications tirant leurs revenus des achats in-app, l'amenuisement des données déterministes a rendu bien plus délicate la prise de décisions.

En matière de revenus réels, iOS 14.5+ ne devrait pas impacter le montant des dépenses des utilisateurs in-app. Les achats in-app conserveront le même coût et les utilisateurs pourront encore acquérir des biens in-app, comme des pièces d'or ou des vies supplémentaires. Toutefois, le manque d'attribution déterministe concernant les utilisateurs non consentants pourrait compliquer la tâche des éditeurs d'applications pour déterminer la quantité exacte de revenus générée par chaque campagne.

Il est aujourd'hui plus difficile de relier chaque achat in-app à une installation initiale ou une réattribution, et donc parfois plus difficile de déterminer les canaux d'acquisition d'utilisateurs performants ou encore d'estimer la LTV au niveau utilisateur.

Mais il existe différentes stratégies pour tirer le meilleur parti des données dont vous disposez dans le monde de l'après-IDFA. Par exemple, maximiser le nombre d'utilisateurs consentants pour maintenir une base de données déterministes exploitables (à des fins de modélisation ou de prévisions), ou encore identifier les points essentiels à optimiser afin d'utiliser le SKAdNetwork d'Apple à votre avantage.

SKAdNetwork et achats in-app

Apple a présenté SKAdNetwork en 2018, sans vraiment susciter d'engouement, avec une nouvelle approche consistant à mesurer les campagnes sans utiliser de données au niveau utilisateur. Avec iOS 14.5+, Apple a imposé SKAdNetwork (et ses fonctionnalités étendues) comme le seul moyen d'accéder aux données sur les performances publicitaires dans les cas où les utilisateurs choisissent de limiter l'accès des développeurs à l'IDFA.

SKAdNetwork fournit de l'espace pour 6 bits de métriques en aval, un nombre entre 0 et 63 (ou entre 000000 et 111111 en binaire), avec un délai initial de 24 heures. Cette « valeur de conversion » peut recevoir n'importe quelle valeur exprimée en binaire. Dès que la valeur de conversion est mise à jour vers un nouveau code 6 bits défini dans l'application, la fenêtre du délai est rallongée de 24 heures supplémentaires.

Lorsque cette fenêtre de valeur de conversion expire, un deuxième délai de 24 heures pour l'attribution commence à se décompter. Dans cet intervalle, le SKAdNetwork renvoie les données d'attribution de manière aléatoire. L'idée de ce délai aléatoire est de masquer l'heure de l'installation et ainsi d'éviter que les déclencheurs d'événements ne soient liés à des utilisateurs individuels. Le système SKAdNetwork partage ces données sous forme agrégée, sans qu'aucune donnée granulaire ne soit accessible au niveau utilisateur.

Pour les applications tirant leurs revenus des achats in-app, cette courte fenêtre sur le comportement des utilisateurs peut s'avérer problématique. Dans de nombreux jeux, accueillir un utilisateur et lui expliquer la valeur des achats in-app est une démarche pouvant demander plus de 24 heures. Si un utilisateur est disposé à acheter des vies supplémentaires, ce besoin ne surviendra peut-être pas avant qu'il n'atteigne les niveaux les plus difficiles. Dans ce cas, avec un recul limité à 24 heures après l'installation, le tracking n'est pas tâche aisée.

Il est toujours possible 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 dans cette fenêtre, 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.

Réconcilier SKAdNetwork et les IAP

Selon le niveau de précision souhaité, vous avez deux méthodes pour suivre le comportement des achats in-app (IAP) avec SKAdNetwork.

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. C'est l'approche retenue par notre mapping de valeur de conversion simple.

Si votre suivi se limite à six événements IAP, alors cette technique convient (un bit est simplement relié à chaque événement) et vous pouvez suivre ces conversions. De même, si votre stratégie repose sur de grandes étapes (par exemple, « terminer le didacticiel », « terminer le niveau 1 » et « faire un achat », alors une approche à masquage de bits est également adaptée.

Mais si vous souhaitez des informations plus détaillées sur des plages de valeurs, vous pouvez créer des buckets « d'achats » ou d'autres métriques. Un système de valeur de conversion basé sur des buckets vous permet de définir des valeurs trackant le nombre d'utilisateurs effectuant des dépenses dans les premières 24 heures. Pour les verticales du gaming, de l'e-commerce, de la livraison ou de la réservation de voyages, la valeur moyenne des commandes (AOV) est un KPI communément utilisé qui permet de mesurer le montant dépensé par les utilisateurs in-app. Si vous cherchez à optimiser l'AOV, il est judicieux d'utiliser des buckets qui portent sur différentes valeurs d'achat totales.

Dans une approche basée sur les buckets, vous pouvez configurer des plages comprises entre 1-5 €, 6-10 €, etc., avec une valeur renvoyée dans le postback de la valeur de conversion qui correspond à chacun de ces buckets.

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. Il vous faut créer des définitions élargies de réussite possible et filtrer les utilisateurs en fonction de leurs comportements. En utilisant des buckets relativement génériques, par exemple en séparant les utilisateurs « publivores » des « non publivores », il devient possible d'exploiter leurs comportements initiaux.

Maximiser le nombre d'utilisateurs consentants constitue la première étape dans l'acquisition des données déterministes que vous pouvez utiliser dans la modélisation, les prévisions et l'utilisation efficace de SKAdNetwork. Avec ces données, il vous est possible de tracker le comportement IAP par masquage de bits ou en créant des buckets d'achats. Tout repose finalement sur la façon dont vous définissez votre stratégie et sur les événements IAP (et leur quantité) que vous choisissez de prioriser et de tracker.

Pour plus d'informations sur la façon dont Adjust soutient votre croissance, consultez notre guide ou accédez à notre centre de ressources iOS 14.5+ ici.