---
title: "Événements de remboursement"
description: "Gérez les événements de remboursement dans Adapty pour réduire le churn et optimiser vos revenus."
---

Le graphique des événements de remboursement indique combien d'achats et d'abonnements ont été remboursés. Adapty associe chaque événement de remboursement à la date à laquelle le remboursement a été émis, et non à la date de début de l'abonnement.

## Calcul \{#calculation\}

Adapty comptabilise chaque achat ou abonnement remboursé au cours de la période sélectionnée. Chaque remboursement est attribué à la date à laquelle il a eu lieu, et non à la date de début de l'abonnement. Les remboursements liés aux périodes d'essai sont exclus, car celles-ci ne génèrent aucun revenu.

## Traitement des remboursements par métrique \{#how-metrics-handle-refunds\}

Les différentes métriques traitent les remboursements de manière distincte. Un même événement de remboursement peut faire baisser un graphique immédiatement, en modifier un autre de façon rétroactive (en changeant les valeurs des périodes passées), ou n'en affecter un troisième d'aucune façon. Le tableau ci-dessous présente les règles par métrique.

| Métrique | Remboursements pris en compte ? | Date d'attribution | Peut être négatif ? | Remarques |
| --- | --- | --- | --- | --- |
| [Revenus](revenue) | Oui | Date du remboursement — et non la date d'achat initiale | Oui — les jours où les remboursements dépassent les nouveaux revenus | Revenus = total des transactions − remboursements. |
| [MRR](mrr) | Oui, de façon rétroactive | L'abonnement est retiré de toutes les périodes où il était actif | Non | Les valeurs des périodes passées peuvent diminuer après un remboursement. |
| [ARR](arr) | Oui, de façon rétroactive | Identique au MRR | Non | Les valeurs des périodes passées peuvent diminuer après un remboursement. |
| [ARPU](arpu) | Oui | Date du remboursement | Oui (dans les périodes avec beaucoup de remboursements) | Les remboursements sont soustraits du numérateur des revenus. |
| [ARPPU](arppu) | Oui, numérateur uniquement | Date du remboursement | Oui (dans les périodes avec beaucoup de remboursements) | Les remboursements sont soustraits du numérateur des revenus. Un utilisateur remboursé est toujours comptabilisé dans le dénominateur des utilisateurs payants, ce qui peut faire baisser l'ARPPU plus vite que prévu en cas de nombreux remboursements. |
| [Abonnements actifs](active-subscriptions) | Oui, de façon rétroactive | L'abonnement est retiré du comptage | Non | |
| [Nouveaux abonnements](reactivated-subscriptions) | **Non** | — | Non | Le comptage inclut les abonnements ultérieurement remboursés. Comparez avec [Événements de remboursement](refund-events) pour mesurer l'impact net. |
| [Montant remboursé](refund-money) / [Événements de remboursement](refund-events) | Les remboursements **sont** la donnée | Date du remboursement | Non (toujours ≥ 0) | |
| [Rétention](analytics-retention) | **Non** | — | Non | Les utilisateurs remboursés restent comptabilisés dans la courbe de rétention. Cela peut donner l'impression que la rétention est plus élevée que les [Abonnements actifs](active-subscriptions) ou les [Revenus](revenue) pour la même cohorte. |
| [Revenus par cohorte](analytics-cohorts) | Oui, de façon cumulative | Date du remboursement | Non (les soustractions cumulatives ne font pas passer les revenus de cohorte en négatif) | Les remboursements sont déduits des revenus de la cohorte au fur et à mesure. Pour les autres métriques de cohorte, voir [Cohortes > Gestion des remboursements](analytics-cohorts#refund-handling). |
| [Métriques de paywall](paywall-metrics) / [Métriques de test A/B](results-and-metrics) (comptages) | **Non** | — | Non | Les comptages d'abonnés, d'abonnés payants et d'ARPPU sur ces pages ne déduisent pas les remboursements. |
| Exports GCS / S3 | Remboursement sous forme de ligne d'événement distincte | `event_datetime` = horodatage du remboursement | Les colonnes nettes peuvent être négatives lors de l'agrégation | La ligne de remboursement porte `is_refund = true` (S3/GCS) ou le type d'événement `subscription_refunded` (webhooks). |

### Valeurs négatives \{#negative-values\}

Dans les vues agrégées (graphique des revenus, analyses personnalisées sur les exports), une métrique peut afficher une valeur négative pour une période ou un regroupement donné lorsque les remboursements de ce segment dépassent les nouveaux revenus de la même période. Ce n'est pas un bug — c'est l'arithmétique qui fonctionne normalement.

Par exemple : un pays n'a enregistré aucun nouvel achat un mardi, mais un remboursement de 100 $ correspondant à un achat antérieur a été traité ce jour-là. Les revenus du pays pour ce mardi afficheront donc −100 $.

## Filtres et regroupements disponibles \{#available-filters-and-grouping\}

:::link
Article principal : [Contrôles analytiques](controls-filters-grouping-compare-proceeds)
:::

- ✅ Filtrer par : Attribution, Audience, Motif du remboursement, Pays, Type d'offre, ID d'offre, Type de remise de l'offre, Paywall, Tests A/B, Placement, Période, Segment, Store, Produit et Durée.
- ✅ Regrouper par : Motif du remboursement, Produit, Pays, Store, Paywall, Audience, Placement, Durée, Type d'offre, Type de remise de l'offre, ID d'offre, Segment et Attribution.

## Métriques similaires \{#similar-metrics\}

Pour une comparaison côte à côte de ces métriques, consultez le [Tableau de comparaison des métriques](metric-comparison-table#revenue).

- [Montant remboursé](refund-money)
- [Problème de facturation](billing-issue)
- [Délai de grâce](grace-period)