Comment calculer un plafond de CPA avant de scaler une app ? Il vient des proceeds, pas d'un benchmark.

Prenons une app subscription avec un plan annuel illustratif à 59,99 $. Elle peut se permettre un payeur à 26,87 $ ou un payeur à 53,81 $, avec les mêmes prix, les mêmes commissions de store et le même taux de remboursement. La seule donnée qui change est le temps pendant lequel elle peut attendre son argent. Le maximum qu’un utilisateur payant peut vous coûter, c’est le plafond de CPA, et je le fixe avant d’augmenter la dépense sur n’importe quel compte.

Il vient de trois chiffres que vous avez déjà. Ce qu’un payeur paie. Ce qui vous parvient après le store, les taxes et les remboursements. Combien de temps vous pouvez attendre. Une cible de plateforme, un benchmark et un ratio de 3:1 ne sont aucun de ces trois chiffres. Vous fixez d’abord le plafond, puis la cible de la plateforme en dessous, et l’écart entre les deux dépend de l’âge de vos cohortes. Chaque chiffre des exemples est de l’arithmétique sur une hypothèse déclarée comme telle, pas un compte réel.

Qu’est-ce qu’un plafond de CPA, et qu’est-ce qu’il n’est pas ?

Un plafond de CPA est un coût par utilisateur payant, pas un coût par install ou par essai. Les installs et les essais sont des proxys, et je ne convertis le plafond en installs et en essais qu’à la fin, avec des taux de conversion mesurés sur des cohortes assez anciennes pour avoir converti.

On le confond avec trois choses :

• Une cible de plateforme. Google dit clairement qu’avec le CPA cible, certaines conversions coûtent plus que la cible et d’autres moins. La cible est une donnée d’entrée de l’enchère. Elle ne sait pas ce qu’un payeur vaut pour vous.
• Un benchmark. Un CPI ou un coût par essai médian décrit d’autres apps, avec d’autres prix et d’autres paliers de commission. L’article sur les marchés Tier 2 montre qu’un CPI de 2 $ avec 3 % d’installs qui paient bat un CPI de 15 $ avec 4 %. Cela fait 67 $ contre 375 $ par payeur. Même benchmark, verdicts opposés.
• Un ratio. J’ai déjà qualifié de repère approximatif le ratio LTV/CAC de 3:1, et je continuerai à le faire. Un ratio cache si le revenu est brut ou en proceeds, et quand il arrive. Ce sont les deux choses pour lesquelles un plafond existe.

Comment calculer les proceeds par utilisateur payant ?

Chaque élément du plafond est une déduction du prix, et ces déductions sont plus importantes et plus variées que la plupart des modèles ne le supposent.

Commission du store. Ce n’est pas un chiffre unique. Elle change selon le programme, la durée pendant laquelle l’abonné a payé et la région.

Un taux fixe de 30 % dans le modèle est faux pour la plupart des apps la plupart du temps, et faux dans le sens qui vous fait enchérir trop bas.

Taxes. Là où le prix inclut la TVA, le store calcule la commission une fois la taxe retirée, donc un plan à 59,99 € en Allemagne et un plan à 59,99 $ au Texas ne produisent pas les mêmes proceeds.

Remboursements. Un remboursement reprend ce qui vous est parvenu. Sur Google Play, Google restitue ses frais de service sur une commande remboursée. Dans les rapports de ventes d’Apple, un remboursement enregistre des unités négatives à votre taux de proceeds, donc ce que vous perdez, c’est votre part, pas le prix payé par le client. Le rapport 2026 de RevenueCat place la plupart des catégories entre 3 % et 4 %, avec des valeurs extrêmes de 9 % à 18 %, et davantage de remboursements sur les prix plus élevés.

Coûts variables. Tout ce qui augmente avec un utilisateur payant : l’inférence pour une app d’IA, les licences de contenu, le support. Les coûts fixes restent à l’écart. Le plafond est le seuil de rentabilité par payeur, et l’écart que vous gardez en enchérissant sous ce seuil, c’est ce qui paie le loyer.

Ce qui reste après ces quatre éléments, ce sont les proceeds par payeur. RevenueCat sépare les niveaux de la même façon, le revenu net des remboursements, puis les proceeds après taxes et commission estimées, et je construis le plafond sur le dernier. L’argent met ensuite du temps à arriver. Apple verse dans les 45 jours suivant la fin du mois fiscal où la vente a eu lieu, donc une vente peut vous parvenir des semaines plus tard, et Google Play verse vers le 15 du mois suivant.

Combien de temps pouvez-vous attendre votre argent ?

Aucun benchmark ne peut y répondre à votre place. C’est là que je passe le plus de temps avec un nouveau compte.

Ma règle dépend du plan. Un plan annuel se rentabilise dès le premier paiement ou ne se rentabilise jamais, donc la fenêtre est immédiate. Les plans hebdomadaires et mensuels placent une grosse part de leur valeur dans le premier paiement et le reste arrive avec les renouvellements, donc je les lis sur des cohortes hebdomadaires et je ne fais jamais confiance à une seule semaine. Ma règle empirique, tirée du playbook Andromeda, est que l’abonné hebdomadaire ou mensuel moyen rapporte à peu près le prix annuel avec le temps. Les apps qui vendent des produits additionnels en plus de l’abonnement récupèrent plus vite leur mise, parce que le deuxième achat arrive avant le renouvellement.

Ensuite, cela dépend de l’entreprise. Pour un débutant, récupérez tout dans le même mois. Vous ne connaissez pas encore votre courbe de renouvellement, et le store ne vous paiera pas avant des semaines, donc un plafond qui s’appuie sur la deuxième année est un prêt que vous vous êtes fait à vous-même. Une app établie peut s’étirer vers deux ans. Établie, cela veut dire deux choses à la fois. Vous avez au moins un an de données de renouvellement, donc la courbe est connue et non devinée, et vous avez la trésorerie ou le financement pour attendre. L’une sans l’autre ne suffit pas.

Compter deux ans de proceeds ne revient pas à attendre deux ans pour juger. La cible reste à D30 ou D60, comme dans ce playbook, et la courbe mesurée de là jusqu’au renouvellement couvre le reste. La fenêtre, c’est ce que le plafond compte. Le jour, c’est le moment où vous jugez.

Mesurez la courbe de renouvellement, car le raccourci habituel du revenu par mois divisé par le churn suppose que le churn reste constant, et dans les cohortes d’abonnement ce n’est pas le cas. Fader et Hardie ont montré que les taux de rétention augmentent avec le temps parce que les gens les plus susceptibles de partir partent en premier. Les médianes sont basses aussi. Le rapport 2026 de RevenueCat donne une médiane du premier renouvellement annuel entre 23 % et 40 % dans les principales catégories. Si votre plafond suppose davantage, je veux voir la cohorte.

À quoi ressemble le plafond pour une app subscription à 59,99 $ ?

Chaque donnée ci-dessous est illustrative, sauf si la dernière colonne cite une source. Remplacez le reste par votre propre grille tarifaire, votre propre palier de commission et vos propres taux arrivés à maturité.

Le premier bloc est le plafond du débutant, avec un payback dans le même mois. Le second est celui de l’app établie, et il n’est accessible qu’à une app qui a suivi une cohorte pendant un an et peut attendre la deuxième année. J’ai gardé la commission de 30 % sur les sept paiements mensuels parce que les plans mensuels atteignent rarement le palier de 15 %.

Ce que fait le palier de commission. Au palier de 15 %, que ce soit via le Small Business Program ou pour un abonnement Google Play, le même premier paiement vaut 32,63 $ par payeur au lieu de 26,87 $. Un cinquième de marge en plus à partir d’une ligne du modèle que la plupart des gens laissent à 30 %.

Grille tarifaire illustrative issue des tableaux ci-dessus, conditions standard d'Apple. Une barre pleine vaut 53,81 $.

La fenêtre a doublé le plafond. Le palier de commission l’a déplacé d’un cinquième. Le taux d’essai vers payant, la donnée dont la plupart des équipes débattent, ne l’a pas déplacé du tout, parce qu’il ne fait que convertir le plafond en enchère. Réglez la fenêtre et la commission avant de toucher aux taux du funnel.

À quoi ressemble le plafond pour un jeu mobile avec du revenu publicitaire ?

Les jeux se pilotent au ROAS, et un soft launch doit prouver que les installs se rentabilisent dans la fenêtre. Le plafond est donc le CPI qui atteint encore le retour dont vous avez besoin à la date où vous en avez besoin, achats et revenu publicitaire comptés ensemble. Le revenu publicitaire ne porte aucune commission de store, ce qui explique en partie pourquoi les jeux hybrides peuvent payer chaque install plus cher que ne le suggère leur taux de payeurs.

Données illustratives : 3 % des installs paient d’ici le jour 30, un payeur dépense 35 $ bruts d’ici là, soit 24,50 $ après une commission de 30 %, et l’install moyen rapporte 0,40 $ de revenu publicitaire d’ici le jour 30. Les achats donnent 3 % × 24,50 $ = 0,74 $ par install, la publicité ajoute 0,40 $, donc un install vaut environ 1,14 $ d’ici le jour 30.

Si le payback au jour 30 est la règle, le plafond de CPI est d’environ 1,14 $. Si vous avez besoin de 130 % d’ici le jour 30 pour financer la cohorte suivante, il est d’environ 0,87 $. Par payeur, divisez la valeur d’un install par les 3 % qui paient, ce qui donne environ 38 $ avec le revenu publicitaire compté, contre 24,50 $ sur les achats seuls. Un modèle qui ne compte que les achats in app sous-évalue ce jeu d’un tiers.

Sur l’un de mes comptes de jeu, le CPI est resté stable alors que le ROAS D0 a été divisé par deux, parce que la valeur des commandes a baissé. C’est ce qui plaide pour construire le plafond sur la valeur par install et non sur le CPI.

Le plafond de CPA doit-il être le même dans chaque pays ?

Un par pays, partout où le volume permet de le lire. Les prix diffèrent, le traitement fiscal diffère, la commission du store peut différer, et le mix de plans diffère, puisque le rapport 2026 de RevenueCat place les plans annuels à 40 % des abonnements vendus en Amérique du Nord et à 19 % au Moyen-Orient et en Afrique. Chacun de ces éléments change les proceeds par payeur, et un plafond blended cache l’écart. Dans mon audit par pays, un pays avait tourné à 28 % de ROAS pendant trois mois dans une campagne qui affichait 70 % en blended. Sur le compte Videa, j’ai fixé les cibles de ROAS par pays et laissé le budget suivre le payback par marché.

Quand un pays est trop petit pour être lu, regroupez-le avec ses voisins et lisez le groupe. Un pays avec 80 $ de dépense a un ROAS bruité, pas un verdict.

Comment transformer un plafond de CPA en cible Meta ou Google ?

Le plafond est par payeur et la plateforme veut une cible par événement, donc convertissez d’abord. Avec une optimisation sur l’essai, cible de coût par essai = plafond × taux d’essai vers payant arrivé à maturité. Avec une optimisation sur l’achat, vérifiez ce que l’événement compte. L’intégration Meta de RevenueCat envoie par défaut les conversions d’essai, les premiers achats et les renouvellements tous comme Subscribe, donc un coût par Subscribe peut se situer sous ce qu’un nouveau payeur a réellement coûté, comme l’explique l’article sur l’événement d’optimisation.

Fixez ensuite la cible sous le plafond. L’ampleur de l’écart dépend de l’âge des cohortes. Tant que les cohortes sont jeunes, trois choses restent inconnues. Le taux d’essai vers payant par lequel vous avez multiplié est un benchmark ou une supposition, l’écart d’attribution n’est pas mesuré, et les remboursements ne sont pas encore arrivés. À ce stade, l’écart sous le plafond remplit deux fonctions à la fois. Il absorbe ces inconnues, et c’est le seul argent qui reste pour les coûts fixes. Je le laisse donc large, et je le resserre une fois que quelques semaines de cohortes appariées ont confirmé les taux. Dans l’exemple, un quart sous le plafond du premier paiement donne environ 20 $ par payeur et 7,50 $ par essai pour un compte jeune, et un dixième sous le plafond donne environ 24 $ et 9 $ une fois les taux connus. Ces marges sont illustratives. Le sens ne l’est pas.

Dans l’app de fitness dont j’ai parlé, la cible était de 15 $ par essai et je n’ai pas réussi à faire descendre le compte sous 30 $. Que 30 $ constitue un échec ou un résultat correct dépendait de ce qu’un essai valait pour cette app. C’est le chiffre qu’un plafond vous donne avant de dépenser, pas après le jour 25. Et quand une cohorte le manque, le diagnostic me sert à trouver ce qui a bougé avant de couper.

Les plateformes décrivent leurs cibles de la même façon, si vous lisez les petits caractères. La page d’aide de Meta présente l’objectif de coût par résultat et l’objectif de ROAS comme des données d’entrée de l’enchère publicitaire, sans garantie que le compte les atteigne. Le guide de configuration de Google vous dit de fixer votre tCPA 20 % plus haut que le CPA observé une fois les données disponibles. C’est un conseil pour gagner du volume. Seul le plafond vous dit si vous pouvez vous le permettre.

Sur Google, je commence sans cible. Dans mon test à 100K $, Max Conversion Value a battu tROAS sur les deux plateformes et sur tous les marchés, parce que tROAS restreint le volume avant que Google n’ait appris quoi que ce soit. Le plafond était la ligne contre laquelle je jugeais les résultats, pas une donnée d’enchère, et je n’ai ajouté une cible qu’une fois qu’il y avait un retour à tenir. Les propres règles de Google vont dans le même sens. Le tROAS sur les campagnes d’app exige le SDK Firebase et au moins 10 conversions par jour ou 300 sur 30 jours.

À partir de quand une cohorte est-elle assez ancienne pour être jugée face au plafond ?

Un plafond construit sur un taux d’essai vers payant de 37,4 % est un plafond pour des cohortes dont les essais ont eu le temps de convertir. Jugez une cohorte âgée de trois jours face à ce plafond et elle échouera à chaque fois, et vous couperez une campagne qui allait bien. Je compare le coût par payeur à âge de cohorte égal, comme l’étude D0 contre D28 compare les campagnes, et je ne laisse le chiffre précoce remplacer le tardif qu’une fois que la courbe propre au compte, du jour 0 au jour 28, est connue. La routine de cohortes elle-même, même âge, proceeds et un seuil d’achats, se trouve dans quelles cohortes se rentabilisent réellement.

L’erreur inverse est tout aussi courante. Un coût par essai bas avec un taux d’annulation jour 0 de 85 % est pire qu’un coût par essai élevé avec un taux normal, parce que 55,4 % des annulations dans les essais de trois jours surviennent au jour 0 et que ceux qui démarrent des essais bon marché sont souvent ceux qui annulent. C’est précisément pour cette raison que le plafond est par payeur.

Quels chiffres me faut-il avant de scaler un compte ?

1. Proceeds par payeur. Prix par plan et par pays, votre palier de store, taxes et remboursements, blended selon votre vrai mix de plans. Un taux fixe de 30 % et le revenu brut placent tous deux le plafond au mauvais endroit.
2. La fenêtre. Combien de temps vous pouvez attendre, et si vous avez un an de vos propres données de renouvellement pour justifier de compter plus que le premier paiement.
3. Taux arrivés à maturité. Essai vers payant et install vers payeur, issus de cohortes assez anciennes pour avoir converti, par pays quand le volume le permet.
4. Les trois plafonds. Par payeur, par essai et par install, et de combien chacun bouge si le palier de commission ou la fenêtre change.
5. L’écart avec la cible. De combien la cible de la plateforme se situe sous le plafond, et l’âge de cohorte auquel vous resserrez cet écart.
6. L’âge auquel vous jugez. Le coût par payeur à âge de cohorte égal, jamais sur le seul événement de la plateforme.

Si vous pouvez remplir ces six lignes, vous pouvez scaler. Sinon, le growth audit est l’endroit où je les remplis pour un compte, et vous pouvez le réserver seul, quel que soit le niveau de dépense.

Sources et périmètre

Toutes vérifiées les 4 et 5 octobre 2026. Les conditions des stores changent souvent, donc vérifiez la date avant de citer un taux. Les exemples chiffrés sont de l’arithmétique sur des hypothèses déclarées comme telles, pas un compte réel. Les chiffres de comptes vers lesquels je renvoie viennent chacun d’un seul compte, pas d’expériences contrôlées.

• Apple : App Store Small Business Program.
• Apple : Auto renewable subscriptions.
• Apple : Changes for apps in the European Union, mis à jour le 18 août 2026.
• Apple : Summary sales report, App Store Connect Help.
• Apple : Overview of receiving payments, App Store Connect Help.
• Google : Service fees, Play Console Help.
• Google : Order processing and payouts, Play Console Help.
• Google : Manage your app’s orders and issue refunds, Play Console Help.
• Google : About Target CPA bidding, About Target ROAS bidding, About bidding in App campaigns et Choose a bid strategy for your App campaign, Google Ads Help.
• Meta : About cost and bid controls, Meta Business Help Center.
• RevenueCat : Taxes and commissions et Meta Ads integration, RevenueCat Docs.
• RevenueCat : State of Subscription Apps 2026, 115 000 apps, données 2025, les propres clients de RevenueCat, étude observationnelle.
• Fader et Hardie : How to Project Customer Retention, Journal of Interactive Marketing, 2007.