Le ROAS de votre app compte encore les achats qu'Apple et Google ont remboursés, alors enchérissez sur le ROAS net

Les tableaux de bord publicitaires enregistrent un achat intégré au moment où il a lieu, et la plupart ne l'annulent jamais. Quand Apple ou Google remboursent ensuite cet achat, l'argent quitte votre versement mais reste dans les revenus de la campagne, et le ROAS continue de créditer l'annonce qui a fait la vente. Le ROAS net, revenus après remboursements divisés par les dépenses publicitaires, est le chiffre qui vous dit quelles campagnes ont vraiment rapporté. Vous devez le construire vous-même, car le signal de remboursement arrive sur votre serveur, pas sur le réseau publicitaire.

Pourquoi le ROAS surestime les revenus quand les remboursements sont ignorés

Le ROAS divise les revenus attribués par les dépenses publicitaires. Les revenus sont généralement enregistrés une seule fois, à l'achat, par un SDK sur l'appareil ou par un import de conversions depuis le store. Un remboursement est un événement ultérieur qui se produit hors de l'appareil, entre le client et Apple ou Google. Si rien ne le rattache à la même campagne, l'achat continue de compter.

Ce serait sans conséquence si les remboursements étaient rares et répartis uniformément. Ils le sont rarement. Une création qui promet plus que ce que l'app offre, une offre montrée à la mauvaise audience ou une source de trafic pleine de cartes volées concentrent les remboursements sur certaines campagnes. Le ROAS brut masque précisément cet écart.

Qu'est-ce que le ROAS net ?

Le ROAS net est le même ratio, avec les remboursements retirés de la ligne du haut : les revenus attribués à une campagne, moins les remboursements sur ces mêmes achats, divisés par le coût de la campagne. Certaines équipes retirent aussi la commission du store et les taxes. Quoi que vous retiriez d'autre, ce sont les remboursements qui changent la campagne gagnante.

Où les remboursements se perdent entre le store et votre tableau de bord publicitaire

Firebase enregistre les remboursements Google Play, pas ceux de l'App Store

La liste des événements collectés automatiquement par Google comprend in_app_purchase, qui se déclenche lorsqu'un utilisateur finalise un achat intégré, y compris un abonnement initial, traité par l'App Store d'Apple ou par Google Play. Son pendant pour les remboursements, app_store_refund, se déclenche lorsqu'un achat intégré est remboursé par Google Play, et Google l'indique comme réservé à Android. Ni app_store_refund ni les événements d'abonnement automatiques ne sont exportés vers BigQuery.

La même page indique qu'Analytics ne mesure pas automatiquement les revenus et les remboursements des apps payantes, et que les revenus affichés peuvent différer de ceux de la Google Play Developer Console. Sur iOS, rien ne déduit automatiquement un remboursement de l'App Store d'un achat déjà enregistré par Firebase.

Google Ads enregistre le montant de l'achat comme valeur de conversion

Pour les apps Android qui utilisent la facturation intégrée, Google Ads peut suivre les achats intégrés des personnes qui ont cliqué sur votre annonce, sans code dans l'app. Google précise que le montant de l'achat est automatiquement remonté comme valeur de conversion. Pour les abonnements, seul le premier achat est enregistré comme conversion, et seul le montant du premier paiement est enregistré. L'article d'aide ne mentionne pas les remboursements.

Google Ads dispose bien d'un outil de correction. Les ajustements de conversion permettent de corriger la valeur d'une conversion sans modifier leur nombre, ou de la rétracter, ce qui ramène sa valeur à 0.00 et alimente les stratégies d'enchères au CPA comme au ROAS. Google précise que les conversions en ligne ne peuvent être ajustées que si vous avez utilisé un ID de transaction, et qu'une conversion rétractée ne peut plus être ajustée. Cette page ne mentionne pas les conversions d'apps, alors vérifiez que votre configuration de conversions accepte les ajustements avant de vous appuyer dessus.

Les postbacks publicitaires d'Apple se ferment avant l'arrivée de nombreux remboursements

AdAttributionKit prévoit trois fenêtres de conversion qui commencent au premier lancement de l'app : jours 0 à 2, jours 3 à 7 et jours 8 à 35. L'app peut mettre à jour sa valeur de conversion jusqu'à la fin de chaque fenêtre. Apple envoie ensuite le postback après un délai aléatoire, de 24 à 48 heures pour le premier et de 24 à 144 heures pour le deuxième et le troisième. Si l'app verrouille une valeur trop tôt, le système ignore les mises à jour suivantes dans cette fenêtre.

La valeur de conversion détaillée n'apparaît que dans le premier postback. Les suivants contiennent au mieux une valeur approximative. Un achat effectué le jour 1 et remboursé par Apple le jour 10 a été déclaré dans un postback qui ne peut plus changer.

Quand arrivent les remboursements d'apps, et qui les décide

Les remboursements ne suivent pas un calendrier unique. Certains arrivent quelques heures après l'achat, d'autres des mois plus tard, ce qui explique pourquoi le ROAS d'une cohorte continue de baisser alors que le rapport de campagne semblait définitif.

Ce que coûte un ROAS aveugle aux remboursements

Prenez deux campagnes avec le même budget. Les chiffres ci-dessous sont une illustration, pas une référence du marché.

Le ROAS brut vous dit de basculer le budget vers A. Le ROAS net montre que B a conservé davantage de chaque dollar. Si vos enchères reposent sur la valeur brute, l'algorithme continue de trouver davantage d'acheteurs comme ceux de A, car rien ne lui signale jamais qu'ils ont demandé à être remboursés.

Les dépenses publicitaires ne sont que la première facture. Un client remboursé laisse aussi derrière lui :

• Les commissions. Les accords avec les affiliés, créateurs et influenceurs rémunérés à l'achat paient généralement sur la vente, pas sur la vente moins les remboursements, sauf clause contraire du contrat.
• Le calcul, les appels d'API et le stockage. Un utilisateur remboursé a sollicité vos serveurs, vos API tierces payantes et votre stockage jusqu'à la révocation de son accès. Ces factures-là ne sont pas remboursées.
• Le coût des rétrofacturations. Depuis le 3 août 2026, Google reporte sur le développeur le prix de l'achat contesté ainsi que les frais bancaires, donc une source de trafic Android riche en litiges coûte plus que les revenus qu'elle fait perdre.
• Un ciblage dégradé. Des enchères basées sur la valeur, entraînées sur des achats remboursés, partent à la recherche de profils semblables à ceux qui ont été remboursés.

Un taux de remboursement élevé sur une campagne, fraude ou promesse non tenue ?

Souvent, c'est la promesse. Le revocationReason d'Apple vous indique de quel côté tombe un remboursement. Un 0 signifie que l'App Store a remboursé la transaction pour d'autres raisons, par exemple un achat accidentel. Un 1 signifie qu'il l'a remboursée en raison d'un problème réel ou perçu dans votre app. Une concentration de 1 sur une campagne pointe généralement vers la création publicitaire ou l'onboarding vers lequel elle mène. Une concentration de signalements de débits non autorisés sur Google Play pointe vers la source de trafic.

Comment construire le ROAS net d'une app

Pas besoin d'un nouvel outil pour commencer. Il vous faut quelques jointures que vos données ne font probablement pas encore.

• Rattachez la campagne à l'utilisateur. Stockez le résultat d'attribution à côté de votre propre ID utilisateur dès l'installation, afin que toute transaction ultérieure puisse être reliée à une campagne.
• Rattachez la transaction à l'utilisateur. Définissez un appAccountToken sur les achats iOS et un ID de compte obscurci sur les achats Google Play, afin que chaque événement du store corresponde à votre utilisateur sans approximation.
• Écoutez les remboursements côté serveur. Traitez la notification REFUND d'Apple issue des App Store Server Notifications V2 et les notifications d'achats annulés de Google Play. Interrogez la Voided Purchases API en filet de sécurité, car elle ne renvoie que les annulations des 30 derniers jours.
• Présentez le brut et le net côte à côte, par cohorte d'achat. Imputez chaque remboursement à la campagne et à la date d'achat qui l'ont généré, pas au jour où le remboursement est apparu.
• Envoyez des corrections là où la plateforme les accepte. Si vos conversions Google Ads portent un ID de transaction, corrigez ou rétractez celles qui ont été remboursées. Là où une plateforme n'accepte pas de corrections, déplacez son budget en fonction des chiffres nets.
• Répondez à temps aux deux demandes de preuves. RefundHalt répond au CONSUMPTION_REQUEST d'Apple dans la fenêtre de 12 heures et à l'examen des rétrofacturations de Google Play sous 24 heures, pour que les remboursements contestables reçoivent votre version des faits.

Faut-il compter les remboursements à la date d'achat ou à la date de remboursement ?

Pour les décisions de campagne, à la date d'achat. Un remboursement est un fait qui concerne un achat, et l'achat appartient à une campagne. La finance l'enregistre à la date du remboursement, c'est pourquoi votre rapport de ROAS et votre versement ne concorderont pas un jour donné. Gardez les deux vues et nommez-les clairement.

Quand le ROAS net d'une cohorte est-il définitif ?

Il se stabilise par étapes. La fenêtre de remboursement en libre-service de Google se ferme après 48 heures, Apple annonce aux clients une réponse à leur demande de remboursement sous 24 à 48 heures, et un signalement de débit non autorisé sur Google Play peut intervenir dans les 120 jours suivant la transaction. Considérez les premiers chiffres comme provisoires et revérifiez la même cohorte plus tard.