---
title: "Résoudre les divergences de données"
description: "Identifier les causes des 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 \{#troubleshooting-algorithm\}

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](export-analytics-api-requests) 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](#product-pricing). Les problèmes d'événements peuvent indiquer des [problèmes côté serveur](#issues-with-server-notifications-and-rtdn).
* Consultez le [flux d'événements](event-feed) 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 \{#issues-with-server-notifications-and-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](enable-app-store-server-notifications) | [Play Store](enable-real-time-developer-notifications-rtdn)) et [attendez](#data-delays) que les stores établissent la connexion.

Vous pouvez [importer manuellement](importing-historical-data-to-adapty) les données App Store Connect manquantes dans Adapty.

## Données manquantes \{#missing-data\}

### Utilisateurs avec des versions d'application obsolètes \{#users-with-out-of-date-app-versions\}

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 \{#integration-issues\}

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 \{#missing-historical-data\}

Adapty n'a pas accès aux données historiques de votre application, sauf si vous les [importez manuellement](importing-historical-data-to-adapty). Si la [plage de dates](controls-filters-grouping-compare-proceeds#set-the-date-range) 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 \{#data-delays\}

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](predicted-ltv-and-revenue)) 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 \{#time-and-calendar\}

#### Dates et fuseaux horaires \{#dates-and-timezones\}

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](general#3-reporting-timezone) pour chaque application.

#### Le calendrier fiscal Apple \{#the-apple-fiscal-calendar\}

Apple utilise son propre [calendrier comptable](https://adapty.io/apple-fiscal-calendar/) 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](controls-filters-grouping-compare-proceeds#set-the-date-range) correspondant à la période de vente concernée.

#### Dates de transaction \{#transaction-dates\}

Certains services (par exemple, AppsFlyer) peuvent appliquer des règles de [cohorte](analytics-cohorts) 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 \{#revenue-calculation\}

### Frais et taxes \{#fees-and-taxes\}

Selon le [paramètre](controls-filters-grouping-compare-proceeds#display-gross-or-net-revenue), 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 \{#cancellations-and-refunds\}

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 \{#sandbox-purchases\}

Le [flux d'événements](event-feed) 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 \{#installs-and-downloads\}

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](general#4-installs-definition-for-analytics).

## Pays et store \{#country-and-store\}

Pour garantir des rapports précis, Adapty [peut déduire](controls-filters-grouping-compare-proceeds#filter-and-group-data) 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](segments) avec l'attribut `Country by store account`, et [filtrer les analytics par segment](controls-filters-grouping-compare-proceeds#filter-and-group-data).

## Tarification des produits \{#product-pricing\}

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 \{#attribution-conflicts\}

Adapty ne peut utiliser [qu'une seule source d'attribution](attribution-integration#prevent-data-issues) 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 \{#differences-in-terminology\}

Différentes plateformes peuvent avoir des noms différents pour le même concept. Les métriques liées aux [revenus](#fees-and-taxes) varient d'une plateforme à l'autre :

| Adapty | App Store Connect | Google Play Console |
|--------|-------------------|----------------------|
| **Revenus bruts** | Sales | Gross Revenue |
| **Revenus après commission du store** | N/A | N/A |
| **Revenus après commission du store et taxes** | Proceeds | Earnings |
| **ARPPU** | Proceeds per paying user | ARPPU |

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](reactivated-subscriptions) 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` \{#new-subscriptions-metric-vs-the-subscription_started-event\}

La métrique [Nouveaux abonnements](reactivated-subscriptions) et l'[événement d'intégration](events) `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.