Résoudre les écarts de données

Les utilisateurs d’Adapty peuvent rencontrer des écarts lorsqu’ils comparent des ensembles de données similaires provenant de sources différentes. Cela peut notamment se produire lorsque vous comparez :

• Les graphiques Adapty aux rapports des stores
• Les graphiques Adapty à des graphiques tiers
• Différents graphiques au sein d’Adapty

Algorithme de résolution des problèmes

La plupart des écarts entre Adapty et d’autres plateformes sont attendus et normaux. Ils se produisent parce que différentes sources traitent les mêmes données différemment.

D’autres fois, ils indiquent un problème dans votre configuration Adapty.

Si vous suspectez que vos données varient d’une plateforme à l’autre, la meilleure approche est d’exporter les données brutes et de comparer les fichiers.

• Même les stores peuvent rencontrer des problèmes de traitement et de présentation des données. Consultez les données de transaction brutes des stores pour une comparaison aussi précise que possible.
• Pour comparer Adapty à une autre plateforme d’analytics, utilisez les rapports de transactions des stores comme référence.
• Il est plus facile de repérer des incohérences sur un jeu de données limité. Comparez de petits volumes de données — concentrez-vous sur un produit spécifique et une seule journée.
• Déterminez si votre écart provient d’une différence de tarification ou de nombre d’événements. Les problèmes de tarification peuvent être résolus par une mise à jour du produit. Les problèmes d’événements peuvent indiquer des problèmes côté serveur.
• Consultez le flux d’événements pour surveiller les événements entrants — vous pourriez y observer un comportement inattendu.

Après avoir identifié l’endroit où les données divergent, vous pouvez examiner les causes courantes suivantes :

Problèmes avec les notifications serveur et les RTDN

Adapty ne reçoit pas les données d’événements nécessaires si vous n’avez pas correctement configuré les connexions au store. Cela concerne notamment les événements qui surviennent sans intervention directe de l’utilisateur — renouvellements d’abonnement, problèmes de facturation, etc.

Finalisez la configuration serveur à serveur dès que possible (App Store | Play Store) et attendez que les stores établissent la connexion.

Vous pouvez importer manuellement les données App Store Connect manquantes dans Adapty.

Données manquantes

Utilisateurs avec des versions obsolètes de l’application

Si certains de vos utilisateurs utilisent une ancienne version de votre application sans le SDK Adapty, Adapty ne reçoit pas leurs données. C’est pourquoi les chiffres d’Adapty et ceux d’autres sources divergeront.

Problèmes d’intégration

Certaines intégrations Adapty (par exemple, Adjust ou AppsFlyer) nécessitent du code supplémentaire dans l’application pour fonctionner. Si vous configurez l’Adapty Dashboard sans mettre à jour votre application, les données nécessaires n’apparaîtront pas dans Adapty.

Données historiques manquantes

Adapty n’a pas accès aux données historiques de votre application, sauf si vous les importez manuellement. Si la plage de dates d’un graphique commence avant votre intégration d’Adapty et que vous n’avez pas importé de données historiques, ses valeurs différeront de celles d’autres sources.

Délais de données

Adapty vise à fournir une analyse en quasi temps réel de l’économie de votre application. Les limitations et exceptions suivantes s’appliquent :

• Lors de la première intégration d’Adapty, les données peuvent ne pas apparaître immédiatement.
• Lors de l’activation d’une intégration avec une plateforme tierce, un délai peut survenir avant que les données soient entièrement synchronisées.
• Une fois qu’Adapty reçoit les données du store, il faut encore 15 à 30 minutes pour qu’elles soient traitées et affichées sur la page Analytics.
• L’échange de données entre Adapty et des tiers n’est pas toujours instantané en raison du nombre de variables en jeu.
• Les calculs de certaines métriques avancées (comme les prédictions de cohorte) nécessitent une certaine quantité de données. Adapty n’effectuera ces calculs que lorsqu’il aura rassemblé suffisamment de données.

Métriques qui évoluent dans le temps

Les métriques basées sur les cohortes regroupent les utilisateurs selon une action qu’ils ont effectuée — une installation, une vue de paywall, un démarrage d’essai ou un premier paiement — puis continuent de mesurer ce que font ces utilisateurs par la suite. Les taux de conversion, les cohortes, la rétention et la LTV fonctionnent toutes ainsi ; le tableau de comparaison des métriques indique lesquelles le sont et lesquelles ne le sont pas. Un utilisateur qui s’installe en mars et s’abonne en juillet fait monter le taux « Installation vers payant » de mars en juillet.

Comparer un mois vieux de deux ans avec le mois dernier revient donc à comparer un chiffre stabilisé avec un chiffre provisoire. Lisez plutôt chaque période après le même délai écoulé.

Installation vers essai se stabilise en quelques jours, tandis qu’Installation vers payant et Essai vers payant continuent d’augmenter pendant des mois. Comparer les mois dans vos rapports explique combien de temps attendre avant de comparer.

Temps et calendrier

Dates et fuseaux horaires

L’une des raisons les plus courantes de discordances de données perçues est une différence dans les paramètres de fuseau horaire.

Adapty comptabilise les jours selon le fuseau horaire UTC. Si une autre plateforme utilise un fuseau horaire différent, les calculs seront différents. L’écart diminue à mesure que vous augmentez l’échelle.

Vous pouvez modifier le paramètre de fuseau horaire pour chaque application.

Le calendrier fiscal Apple

Apple utilise son propre calendrier comptable pour déterminer les périodes de vente et les dates de paiement.

Chaque « mois » du calendrier est composé de 4 ou 5 semaines et peut inclure des jours des mois calendaires voisins. Les paiements sont généralement émis 30 à 45 jours après la fin de la période de vente.

Par exemple, la période de vente « janvier 2026 » commence le 28 décembre 2025 — 4 jours avant le début du mois calendaire. La date de paiement estimée pour cette période est le 5 mars.

Ne comparez pas les données des rapports de paiement Apple avec des mois calendaires. Sélectionnez plutôt une plage de dates personnalisée correspondant à la période de ventes concernée.

Dates des transactions

Certains services (comme AppsFlyer) peuvent appliquer des règles de cohorte lors de l’affichage des transactions, et les attribuer à la date d’installation de l’application plutôt qu’à la date réelle de la transaction.

Calcul des revenus

Frais et taxes

Selon le paramètre, les graphiques Adapty peuvent afficher votre chiffre d’affaires brut, chiffre d’affaires après commission du store, ou chiffre d’affaires après commission du store et taxes.

Certains stores et plateformes tierces peuvent ne pas être en mesure d’afficher le chiffre d’affaires brut, ou déduire automatiquement les taxes. Si vous constatez un écart entre deux graphiques de revenus différents, vérifiez que la comparaison est pertinente.

Annulations et remboursements

Les plateformes affichent les données de remboursement de manières différentes. Adapty traite les remboursements comme des revenus négatifs. Si un utilisateur s’abonne puis demande un remboursement le lendemain, les deux événements apparaîtront dans les graphiques Adapty — chacun à sa propre date. D’autres plateformes peuvent déduire le montant du remboursement de la transaction d’origine.

Achats sandbox

Le fil d’événements affiche les achats effectués par des comptes sandbox. Les graphiques d’analyse, eux, ne le font pas. Cependant, si vos données d’importation historiques contiennent des achats sandbox, Adapty ne pourra pas les distinguer, et ses graphiques refléteront ces achats sandbox historiques.

Installations et téléchargements

Les stores (l’App Store d’Apple en particulier) peuvent suivre les téléchargements directement. Leurs statistiques peuvent inclure des cas où l’application a été installée, mais jamais lancée.

Adapty ne peut enregistrer une installation que lorsqu’un utilisateur lance l’application, quelle que soit votre définition des installations.

Pays et store

Pour garantir la précision des rapports, Adapty peut déduire le pays de l’utilisateur depuis son adresse IP. Les stores attribuent toujours les téléchargements et les achats à un app store spécifique.

Si vous avez besoin de distinguer clairement les deux, vous pouvez créer un nouveau segment d’utilisateurs avec l’attribut Country by store account, puis filtrer les analyses par segment.

Tarification des produits

Si une tarification incorrecte d’un produit entraîne un écart de revenus, modifier le prix ne corrige pas les transactions déjà enregistrées. Pour mettre à jour le prix des transactions existantes, vous devez les écraser de force en important les données correctes.

Lorsqu’un utilisateur restaure un ancien achat après un changement de prix, Apple peut signaler une valeur incorrecte pour cet achat. Vous devez importer les données historiques pour qu’Adapty affiche la valeur correcte.

Conflits d’attribution

Adapty ne peut utiliser qu’une seule source d’attribution par transaction. Ces données ne peuvent pas être remplacées ultérieurement.

Si votre configuration inclut plusieurs fournisseurs d’attribution qui ne concordent pas, la même transaction peut apparaître avec deux sources de trafic différentes sur deux plateformes distinctes.

Différences de terminologie

Les différentes plateformes peuvent utiliser des noms différents pour désigner le même concept. Les métriques liées aux revenus varient d’une plateforme à l’autre :

D’autres métriques peuvent également différer dans leur définition :

• Abonnements :
  • Adapty ne comptabilise pas les nouveaux essais comme des abonnements. Un nouvel abonnement commence toujours par une transaction financière.
  • D’autres plateformes, comme Google Play Console, peuvent comptabiliser chaque essai comme un nouvel abonnement, même avant le premier paiement.
• Rétention :
  • Adapty mesure la rétention en fonction du nombre de renouvellements d’abonnement.
  • App Store Connect considère qu’un utilisateur est fidèle s’il ouvre l’application le jour spécifié. Un utilisateur sans abonnement est comptabilisé, mais un abonné qui n’a pas ouvert l’application ce jour-là ne l’est pas.
  • La métrique « Retained Installers » de Google Play Console mesure la rétention selon le nombre de jours pendant lesquels l’application reste installée sur l’appareil de l’utilisateur. Les utilisateurs qui n’ouvrent pas l’application sont pris en compte dans cette métrique.

Métrique « Nouveaux abonnements » vs l’événement subscription_started

La métrique Nouveaux abonnements et l’événement d’intégration subscription_started ne comptabilisent pas les mêmes choses, c’est pourquoi leurs totaux ne correspondent pas. La métrique comptabilise à la fois les premiers achats effectués sans période d’essai et les conversions d’essai en abonnement payant. L’événement subscription_started ne se déclenche que pour les premiers achats effectués sans période d’essai — lorsqu’un essai est converti en abonnement payant, Adapty envoie trial_converted à la place. Par conséquent, le nombre de Nouveaux abonnements est supérieur au nombre d’événements subscription_started dès lors que votre application enregistre des conversions d’essai.