Résoudre les divergences de données

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

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

Algorithme de dépannage

La plupart des divergences entre Adapty et d’autres plateformes sont attendues et normales. Elles surviennent parce que des sources différentes traitent les mêmes données différemment.

Parfois, elles indiquent un problème dans votre configuration Adapty.

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

• Même les stores peuvent rencontrer des problèmes liés au traitement et à la présentation des données. Accédez aux données de transaction brutes des stores pour une comparaison plus précise.
• Lorsque vous comparez Adapty à une autre plateforme d’analytics, utilisez les rapports de transactions des stores comme source de vérité et base de comparaison.
• Il est plus facile d’identifier les incohérences avec 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 divergence 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 pourrez y remarquer un comportement inattendu.

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

Problèmes avec les notifications serveur et RTDN

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

Effectuez 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 d’application obsolètes

Si certains de vos utilisateurs utilisent une version plus ancienne de votre application sans le SDK Adapty, Adapty ne reçoit pas leurs données. Les chiffres d’Adapty et des autres sources divergeront donc.

Problèmes d’intégration

Certaines intégrations Adapty (par exemple, Adjust ou AppsFlyer) nécessitent du code applicatif supplémentaire pour fonctionner. Si vous configurez le tableau de bord Adapty 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é les données historiques, ses valeurs différeront des autres sources.

Délais de données

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

• Lors de votre 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, il peut y avoir un délai 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.
• Les échanges de données entre Adapty et des tiers ne sont pas toujours instantanés 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’effectue ces calculs que lorsqu’il dispose de suffisamment de données.

Heure et calendrier

Dates et fuseaux horaires

L’une des raisons les plus courantes des divergences de données perçues est une différence de 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 divergeront. La différence diminuera à 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 les mois calendaires. Sélectionnez plutôt une plage de dates personnalisée correspondant à la période de vente concernée.

Dates de transaction

Certains services (par exemple, 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 à laquelle la transaction elle-même a eu lieu.

Calcul des revenus

Frais et taxes

Selon le paramètre, les graphiques Adapty peuvent afficher vos revenus bruts, vos revenus après commission du store ou vos revenus après commission du store et taxes.

Certains stores et plateformes tierces peuvent ne pas être en mesure d’afficher les revenus bruts, ou déduire automatiquement les taxes. Si vous constatez une divergence entre deux graphiques de revenus différents, assurez-vous que la comparaison est valide.

Annulations et remboursements

Les différentes plateformes affichent les données de remboursement différemment. Adapty traite les remboursements comme des revenus négatifs. Si un utilisateur s’abonne et demande un remboursement le lendemain, les deux événements seront reflétés dans les graphiques Adapty — chacun à sa propre date. D’autres plateformes peuvent soustraire la valeur du remboursement de la transaction d’origine.

Achats sandbox

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

Installations et téléchargements

Les stores (en particulier l’Apple App Store) peuvent suivre directement les téléchargements des utilisateurs. Leurs statistiques peuvent inclure les 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 des rapports précis, Adapty peut déduire le pays de l’utilisateur à partir de 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, et filtrer les analytics par segment.

Tarification des produits

Si une tarification incorrecte d’un produit provoque une divergence de revenus, changer le prix ne corrige pas les transactions passées. Pour modifier le prix des transactions existantes, vous devez les remplacer de force en important des données correctes.

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

Conflits d’attribution

Adapty ne peut utiliser qu’une seule source d’attribution par transaction. Vous ne pouvez pas remplacer ces données ultérieurement.

Si votre configuration inclut plusieurs fournisseurs d’attribution qui ne sont pas d’accord entre eux, la même transaction sur deux plateformes différentes peut sembler avoir deux sources de trafic différentes.

Différences de terminologie

Différentes plateformes peuvent avoir des noms différents pour 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 que le premier paiement ait été effectué.
• Rétention :
  • Adapty mesure la rétention sur la base du nombre de renouvellements d’abonnements.
  • App Store Connect considère qu’un utilisateur est retenu s’il ouvre l’application le jour spécifié. Un utilisateur sans abonnement sera comptabilisé, mais l’utilisateur abonné qui n’a pas ouvert l’application ce jour-là ne le sera pas.
  • La métrique « Retained Installers » de Google Play Console mesure la rétention en fonction du 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 comptabilisent des choses différentes, leurs totaux ne correspondent donc pas. La métrique comptabilise à la fois les premiers achats effectués sans 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 essai — lorsqu’un essai est converti en abonnement payant, Adapty envoie trial_converted à la place. En conséquence, le nombre de Nouveaux abonnements est supérieur au nombre d’événements subscription_started dès lors que votre application comporte des conversions d’essai.