Pour quel événement une app subscription doit-elle optimiser ?

Meta veut environ 50 événements par ad set par semaine. Google veut dix utilisateurs par jour. Votre événement d’achat se déclenche 17 fois.

L’événement que vous choisissez pour l’optimisation décide quels utilisateurs vous obtenez. Envoyez des installs, et la plateforme trouve des gens qui installent. Envoyez des débuts d’essai, et elle trouve des gens qui démarrent des essais. Envoyez des achats, et elle trouve des acheteurs, mais seulement si elle en voit assez pour apprendre.

C’est cette dernière condition qui fait caler la plupart des comptes subscription. L’événement d’achat est celui qui correspond à votre économie. C’est aussi celui qui se déclenche le moins souvent. Alors les équipes le choisissent et affament l’algorithme, ou reviennent aux installs et remplissent le funnel avec des gens qui n’ouvrent jamais le paywall.

Il existe une règle qui résout ça. Avant la règle, les chiffres.

Ce dont chaque plateforme a besoin avant de pouvoir apprendre

Vérifié le 23 septembre 2026 sur les pages d’aide de chaque plateforme, celle de Meta le 24 septembre. Ça change. La date compte plus que le chiffre.

Deux choses ressortent de ce tableau.

Les seuils ne sont pas les mêmes d’une plateforme à l’autre, donc “50 par semaine” est un chiffre Meta, pas une loi. Je l’utilise comme plancher pour combien de campagnes un compte peut faire tourner, et c’est un plancher pour l’apprentissage, pas pour faire confiance à un résultat. Il fallait 50 achats ou plus à une publicité avant que son ROAS ne prédise la semaine suivante, et même alors, seulement modérément.

Et Apple Ads est complètement en dehors de cette décision. La question de l’événement se pose pour Meta, Google et TikTok.

L’événement que vous choisissez, c’est l’utilisateur que vous obtenez

La plateforme fait exactement ce qu’on lui dit. Passez un compte de l’optimisation achat à l’optimisation essai parce que le volume d’achats par ad set est trop bas, et le coût par essai baisse généralement. Le passage de l’essai au payant baisse souvent avec lui, et le coût par abonné payant peut grimper. La plateforme a trouvé des gens qui démarrent des essais, et certains de ces gens démarrent des essais partout.

Les données 2026 de RevenueCat montrent pourquoi ça fait le plus mal sur les essais courts. Parmi les apps avec un essai de trois jours, 55,4 % des annulations d’essai surviennent au jour 0, et 84 % au jour 1. Une campagne optimisée pour l’essai peut avoir l’air excellente un mardi et ne plus rien valoir le jeudi suivant, et la plateforme ne voit jamais la différence parce que l’annulation n’est pas un événement contre lequel elle optimise. Si l’essai a sa place dans le funnel est une question à part.

Pourquoi l’événement le plus profond est généralement le mauvais premier choix

L’achat est l’événement qui correspond à votre compte de résultat. Si vous pouviez toujours optimiser dessus, vous le feriez.

En général, vous ne pouvez pas, pour deux raisons.

Le volume. Prenons une app subscription illustrative et suivons ses premiers paiements jusqu’à l’ad set.

Une arithmétique illustrative, pas un compte. Elle suppose que chaque dollar est un nouveau premier paiement d’un abonnement annuel à 60 $ et une répartition égale entre les ad sets. Vos propres chiffres prennent sa place. La structure décide autant que la dépense si l’événement profond est utilisable.

Le délai. Le premier paiement d’un essai de sept jours arrive au jour 7 ou 8, et sur iOS, pour les utilisateurs ayant refusé le tracking, le postback qui le rapporte parvient à la plateforme des jours plus tard. La plateforme apprend à partir d’un signal qui décrit ce que vous avez acheté la semaine dernière. Les paramètres de valeur prédite de Meta et les enchères sur la valeur de Google existent pour raccourcir ce délai, et ils ne fonctionnent que si la prédiction a été vérifiée par rapport à des cohortes réellement arrivées à maturité. C’est là que l’optimisation de la valeur déraille quand elle est activée trop tôt. Que SKAN puisse rapporter le paiement après un essai dépend de la durée de l’essai, et j’en parle dans SKAN peut-il mesurer le paiement d’un abonnement après la fin de l’essai gratuit.

Donc l’événement le plus profond est la cible, pas le point de départ.

La règle

Optimisez pour l’événement le plus profond qui soit assez fréquent pour franchir le seuil de la plateforme à votre budget, assez rapide pour arriver dans la fenêtre d’apprentissage, et assez prédictif pour qu’améliorer cet événement améliore le nombre d’abonnés payants.

Les trois conditions à la fois. Un événement fréquent qui ne prédit pas les payeurs est un piège. Un événement prédictif qui se déclenche 17 fois par semaine est un blocage.

En pratique, ça donne une échelle.

Meta, Google et TikTok uniquement. Apple Ads reste en dehors de l’échelle, comme le montre le tableau des plateformes. Quel mode d’enchère convient à quelle app est une décision séparée de celle de l’événement. Dans les campagnes iOS qui utilisent Aggregated Event Measurement, Meta doit aussi marquer l’événement comme éligible avant que vous puissiez optimiser dessus. Je détaille les vérifications dans pourquoi les événements d’essai et d’achat reviennent inéligibles.

Le test pour l’étape 2 est simple. Sortez des cohortes assez anciennes pour avoir 60 jours de revenu. Comparez le taux d’essai vers payant et le revenu par install à 60 jours entre les utilisateurs qui ont déclenché l’événement candidat et ceux qui ne l’ont pas fait. Si l’écart est faible, l’événement ne qualifie personne. Choisissez-en un autre. Si l’écart est important, confirmez-le sur un ensemble de cohortes plus récent avant d’enchérir dessus. Un événement peut prédire les payeurs sans que l’enchère sur cet événement vous en apporte davantage. Sur un compte, la valeur jour 0 a mieux prédit le ROAS J28 que le coût par achat, et c’est exactement le genre de vérification qui vous dit si un signal mérite qu’on optimise dessus.

L’erreur qui ressemble à un succès

Les essais bon marché sont le cas classique. Un coût par essai de 10 $ avec un taux d’annulation jour 0 de 85 % est pire qu’un coût par essai de 30 $ avec un taux d’annulation normal. Le dashboard dit que la première campagne gagne. Le compte en banque dit l’inverse, six semaines plus tard.

La deuxième erreur est plus discrète. Les équipes choisissent l’optimisation achat, la regardent rester en Learning Limited pendant un mois, et concluent que Meta ne fonctionne pas pour elles. Il fonctionne. Il n’a jamais eu assez de données pour essayer.

La troisième consiste à consolider les ad sets pour franchir le seuil, puis à les refragmenter une semaine plus tard pour un test créatif. Chaque modification significative remet le compteur à zéro.

Quel plafond de CPA une app subscription doit-elle fixer avant d’augmenter son budget publicitaire ?

Je ne prends pas ce plafond dans un benchmark. Je le fixe avant de dépenser quoi que ce soit, à partir de vos unit economics, c’est-à-dire de ce qu’un abonné payant rapporte en proceeds après commission du store, taxes et remboursements, moins les coûts variables qu’il occasionne. La page Reconciling with App Store Financial Reports de RevenueCat sépare ainsi les proceeds du revenu, avec des taxes et une commission estimées (vérifié le 29 septembre 2026). Le plafond porte donc sur le coût par abonné payant, et je le juge sur des cohortes assez anciennes pour montrer cette économie.

Avec un événement proxy, traduisez d’abord en coût par abonné payant. Le coût par abonné payant vaut à peu près le coût par essai divisé par le taux d’essai vers payant, tiré de cohortes assez anciennes pour que leurs essais aient eu le temps de convertir.

Avant le test, décidez combien vous acceptez au maximum d’y perdre. Ce chiffre, fixé à l’avance, décide de votre patience ; les premiers jours, non.

Vérifiez ensuite ce que compte l’événement optimisé. Par défaut, l’intégration Meta Ads de RevenueCat envoie Trial Converted, Initial Purchase et Renewal tous comme Subscribe (vérifié le 29 septembre 2026). Un coût par Subscribe dans Ads Manager peut mélanger nouveaux payeurs et renouvellements, et donc paraître plus bas que ce qu’un nouveau payeur a réellement coûté.

Je n’augmente le budget que tant que le coût par abonné payant, à âge de cohorte égal, reste sous le plafond. Le calcul, avec un exemple chiffré pour une app subscription et un autre pour un jeu, se trouve dans comment calculer votre plafond de CPA.

Ce que cette page ne peut pas vous dire

Je n’ai trouvé aucune expérience contrôlée publiée qui maintienne l’audience, le créatif et la dépense constants et compare l’optimisation install, essai et achat sur du revenu subscription arrivé à maturité. Ce qui existe, ce sont les recommandations des plateformes, la recherche sur les proxys court terme pour des résultats long terme, et des benchmarks fournisseurs. La règle ci-dessus est un principe défendable. Ce n’est pas une loi de la nature, et les seuils du tableau seront différents dans six mois.

Ce que vous pouvez faire, c’est appliquer l’échelle à vos propres cohortes, comparées au même âge de cohorte, pour qu’une cohorte d’une semaine ne soit jamais jugée face à une cohorte de trois mois.

Où en est votre compte

Si votre événement d’achat ne franchit pas le seuil et que vous êtes sur l’optimisation essai depuis plus d’un trimestre, c’est généralement une conversation de 90 minutes. Une session payante de 90 minutes couvre votre setup et ce qu’il faut changer, dans quel ordre, réservée sur le même calendrier que l’appel initial. Le tableau complet du paid UA pour les apps subscription et de ce que corrige le signal engineering se trouve sur leurs propres pages.

Sources et périmètre

Seuils de plateforme vérifiés le 23 septembre 2026, la page de Meta le 24 septembre. Meta : About the learning phase, Meta Business Help Center. Selon cette page, les ad sets sortent généralement de la phase d’apprentissage après environ 50 résultats dans la semaine qui suit la dernière modification significative de l’ad set. Google : Best practices guide: Setting up your App campaigns et Set up an App campaign for target return on ad spend, Google Ads Help. TikTok : Tips for Value-Based Optimization for app, TikTok Business Help Center, mise à jour en mai 2026. Apple : Maximize Conversions best practices, Apple Ads. Correspondance par défaut vers Subscribe et définition des proceeds chez RevenueCat : Meta Ads et Reconciling with App Store Financial Reports, RevenueCat Docs, toutes deux vérifiées le 29 septembre 2026. Timing des annulations d’essai : State of Subscription Apps 2026, RevenueCat, plus de 115 000 apps, année civile 2025, produit par RevenueCat, une distribution des annulations, pas une part de l’ensemble des utilisateurs en essai. L’argument des résultats de substitution suit Athey, Chetty, Imbens and Kang, NBER Working Paper 26463, un document de travail. L’exemple à 80K $ est une arithmétique illustrative, pas un compte réel.