app-offer

Que fait app-offer ?

Exécutez-la une fois de bout en bout. Écrivez une offre recommandée dans un fichier et placez les alternatives dans son annexe.

Fichiers

Fichier	Quand le lire
reference/frameworks.md (F§)	Quand une étape dit « Lire F§n ». Répertoire des frameworks avec traductions pour applications, rubriques et exemples ; F§16 liste les idées jugées non applicables ; F§17 contient les formules de référence.
reference/app-store-constraints.md (C§)	Avant les étapes 7, 8 et 9, et avant d'écrire un prix, une affirmation, un minuteur, une garantie ou un nom. Il a une date « en date du ». Revérifiez tout ce qui sera expédié.
reference/100m-offers-transcript.txt	Facultatif. Utilisez grep pour trouver un détail. La compétence doit fonctionner sans. Ne citez jamais plus de 15 mots consécutifs.

Règles strictes (chaque étape)

1. Honnêteté uniquement. Pas de faux minuteurs, compteurs ou rareté ; pas de faux avis, témoignages écrits par IA ou non attribués, et divulguez toute incitation derrière un avis ; pas de prix « avant » ou de raisons inventés ; pas de conditions de renouvellement cachées ; pas de fonctionnalités qui ne sont pas dans le build. Enfreindre cela entraîne le rejet des apps (Apple 2.3.1, 5.6 ; Google Comportement trompeur) et enfreint les règles EU/UK/FTC (C§7, C§8).
2. Chaque valeur monétaire nécessite une justification : heures économisées x valeur horaire de l'utilisateur, prix de l'alternative réelle, ou prix réel autonome. Pas de justification, pas de chiffre. Les éléments non valorisés comptent pour zéro dans chaque ratio. N'ajoutez jamais de nombres pour réussir un test.
3. Le montant facturé est le prix le plus visible. Les équivalents par jour ou par mois sont petits et secondaires (C§2).
4. Signalez ces risques partout où ils apparaissent :
   • Réclamations de résultat + délai : les réseaux publicitaires les restreignent (C§7) ; l'App Review supprime les affirmations que l'app ne peut pas délivrer ou étayer (2.3.1).
   • Réclamations de santé, cognitives, financières ou de revenus nécessitent une justification (C§7). Ne revendiquez que les gains de compétences mesurés dans l'application, pas le transfert vers le travail, l'école ou le cerveau.
   • Enfants ou adolescents : Catégorie Enfants, portail parental, COPPA et lois sur l'âge des États, qui s'appliquent aux utilisateurs de moins de 18 ans dans toute catégorie (C§10).
   • Données sensibles (financières, de santé, intimes, de localisation) : C§16.
5. Une garantie doit être payable sur chaque plateforme et chaque formule où elle est affichée (C§5).
6. Marché > offre > persuasion. Corrigez d'abord le maillon le plus faible.
7. Paraphrasez le livre. Citez au maximum 15 mots à la fois, et rarement.
8. Posez au maximum 3 questions, uniquement si l'utilisateur cible ou le travail principal ne peut pas être déduit ; l'une d'elles peut également regrouper les chiffres du fondateur à l'étape 0.7 lorsque le canal d'acquisition est inconnu. Sinon, étiquetez les hypothèses [A], les substituts de référence de C§14 [B], et continuez.
9. Connecteurs : n'interrogez pas les connecteurs d'analytique ou de revenu sauf si l'utilisateur confirme que l'ID du projet ou de l'app appartient à cette application. Sinon, demandez ou marquez [A].
10. Style et longueur : simple et direct, tableaux pour les rubriques, pas de remplissage. Corps d'environ 3 000 à 4 000 mots plus les tableaux ; le surplus va dans les annexes.

Étape 0 : Collecte et hypothèses

1. Classifiez l'entrée : une phrase / doc / URL / dépôt existant. Le répertoire de travail est celui du projet de cette application uniquement si l'entrée le nomme ou si son code et ses notes correspondent à l'idée. Sinon, traitez l'entrée comme une nouvelle idée : ne fouillez pas le répertoire de travail et écrivez dans ./<slug-app>-grand-slam-offer.md.
2. Application existante : basez-vous sur les preuves avant de concevoir quoi que ce soit.
   • Produits et prix : grep -rniE 'purchases_flutter|revenuecat|Purchases\.|offering|entitlement|productId|product_id|weekly|annual|lifetime|StoreKit|BillingClient' --include='*.dart' --include='*.swift' --include='*.kt' --include='*.ts' --include='*.tsx' --include='*.json' --include='*.storekit' --exclude-dir={build,Pods,.dart_tool,node_modules,.git} .
   • Paywall et onboarding : fichiers nommés *paywall* *onboard* *intro* *upgrade* *pro* *premium*, plus les copies localisées (.arb, .strings, strings.xml). Enregistrez les langues expédiées.
   • Analytics : track(, logEvent, appels Mixpanel/Amplitude/Firebase ; notez lesquels des événements paywall_view, trial_start, purchase, cancel et retention existent.
   • Notes : CLAUDE.md, README*, docs/, research/, fichiers mémoire, fastlane/metadata, CHANGELOG, et fichiers correspondant à *brand* *voice* *tone* *style* *listing* *aso* *keyword* *mascot* *pricing* *monetis* *paywall (images aussi).
3. Mode preuve. Avec WebSearch/WebFetch : consacrez environ 12 recherches sur 5 à 10 concurrents (prix et notes), les thèmes d'avis 1 à 3 étoiles pour les 3 premiers, et un fil de discussion communautaire ; citez l'URL et la date dans l'Annexe B. Sans web : étiquetez chaque élément [A : mémoire, non vérifié] et listez-le sous « À vérifier avant la tarification ». Pas de données en direct : utilisez des lignes C§14 nommées comme substituts [B] (taux de remboursement = ligne de remboursement de la catégorie ; périodes payées par F§17.1 ; trafic = installations x part atteignant le paywall). Pré-lancement : l'analyse des avis est « n/a : pré-lancement » ; analysez plutôt les avis des concurrents.
4. Offre actuelle selon les trois parties du livre : ce qu'ils obtiennent, comment ils paient, les conditions (F§1.2). Nouvelle idée : « avant » = l'idée telle qu'énoncée (fonctionnalité nue, pas d'offre).
5. Application existante : auditez le paywall et l'onboarding actuels par rapport à C§2, C§7 et C§8 (licenciement, divulgations, estimations étiquetées, résultats implicites, badges). Listez les violations dans §0. Elles sont expédiées en premier, indépendamment de l'offre.
6. Décisions antérieures trouvées dans les notes ou la mémoire deviennent des contraintes dans §0, chacune marquée comme conservée ou contestée (avec une raison). Ne les remplacez jamais silencieusement ; placez le contestataire dans l'Annexe A.
7. Chiffres du fondateur (valeurs par défaut [A]) : objectif de revenu (100 000 $/an net de frais) ; canal d'acquisition (organique) ; capacité de build (seul, à temps partiel) ; frais de store (15 % si Small Business Program, sinon 30 % ; Google selon C§1) ; part de TVA sur le brut (selon le mix storefront, sinon 8 %) ; taux d'impôt sur le revenu (30 %) ; valeur horaire de l'avatar (salaire médian local) ; vues du paywall par semaine (mesurées, sinon 300).
8. Drapeaux : utilisateurs enfants ou adolescents ; réclamations de santé, cognitives ou financières ; données sensibles ; coût variable par utilisateur (inférence, minutes humaines, SMS, données tierces ou frais d'API tels que l'agrégation bancaire, l'OCR ou le KYC, stockage) ; produit multi-utilisateur (couple, famille, équipe, classe : qui doit se joindre pour la valeur, qui paie) ; mauvaise utilisation possible contre un utilisateur vulnérable (coercition, surveillance, mineurs).

Écrit §0, plus la colonne « avant » utilisée dans §11 et §12.

Étape 1 : Test de marché « foule affamée » (Lire F§2)

Test	1	3	5	Preuve
Douleur	Agréable à avoir, personne ne se plaint	Désagrément récurrent	Désespéré, coûteux ou embarrassant ; soulevé sans y être invité	Avis 1-3 étoiles des concurrents, Reddit, termes de recherche
Pouvoir d'achat	Le payeur ne peut pas payer (enfants, chômeurs)	Mixte	Le payeur a de l'argent et une raison (carrière, examen, santé, parent)	Payeur vs utilisateur, mix storefront, LTV géographique de l'utilisateur (C§14)
Facile à cibler	Pas de lieu de rassemblement, pas de mot-clé	Quelques canaux	Propre cluster de mots-clés, communautés, créateurs ; une page produit personnalisée pourrait ne parler qu'à eux	Popularité des mots-clés ASA, subreddits, créateurs
En croissance	En déclin, ou sur le point d'être absorbé par l'OS ou l'IA gratuite	Stable	Vent favorable (démographique, plateforme, saison, réglementation)	Tendances de catégorie, risque « Sherlock »

• Mappez l'application à la santé, la richesse ou les relations. Divertissement pur : dites-le ; la tarification basée sur la douleur y est plus faible.
• Notez les candidats : le marché tel que décrit (application existante : l'échelon que l'actuelle fiche et marque servent) plus 2 à 4 sous-groupes.
• Verdict. Il juge le marché tel que décrit (application existante : l'échelon que l'actuelle fiche et marque servent). Vérifiez dans cet ordre :
  1. PIVOT : aucun candidat n'a chaque test à 3+. Dites-le clairement ; l'offre ne peut pas le réparer.
  2. GO : le marché tel que décrit a chaque test à 3+ et un total de 14+. GO (marché normal) : il a chaque test à 3+, un total de 12-13, et aucun sous-groupe avec chaque test à 3+ ne score plus haut ; l'offre le porte (F§2.7).
  3. NICHE DOWN : sinon. Prenez le sous-groupe le mieux noté avec chaque test à 3+ ; indiquez son score, s'il atteint GO, l'écart et ce qui le comblerait.
• Application existante sur NICHE DOWN : gardez le paywall principal sur l'échelon actuel sauf si l'utilisateur demande de repositionner. Ajoutez le sous-groupe comme une piste d'objectif d'onboarding, une page produit personnalisée et sa propre Offre ; ne le promouvez qu'après l'expédition de son contenu et la réussite d'un test.
• Évaluez marché / offre / persuasion comme excellent / normal / mauvais. Indiquez où va l'effort en premier.
• Échelle de niche : 4 échelons du générique à l'hyper-spécifique, avec l'implication de prix de chacun. Attendez-vous à une prime d'environ 2 à 5x sur l'échelle, pas le 100x du livre (F§16). L'échelon auquel vous vous engagez est le marché tel que décrit sur GO, sinon le sous-groupe NICHE DOWN (application existante : la règle ci-dessus).
• Avatar : 4 qualificatifs concrets, pour qui il N'EST PAS, et qui pourrait être blessé par le produit ou son utilisation abusive (et quels éléments de l'offre deviennent facultatifs ou exclus).
• Positionnement : « Nous aidons [avatar] à obtenir [résultat] grâce à [mécanisme unique] sans [peur la plus profonde]. »
• TAM : payeurs atteignables x LTGP par payeur = plafond. Nouvelle idée : LTGP provisoire = prix annuel médian de la catégorie x (1 - frais) x (1 - part TVA) x 1,3 périodes [A] ; recalculez à l'étape 7 et mettez à jour §1.3 si le verdict change. Planifiez une niche adjacente uniquement si le plafond calculé, pas un plateau, est inférieur à l'objectif ; un plateau signifie améliorer d'abord l'offre.
• Engagez-vous. Les autres avatars deviennent des pages produit personnalisées ou des pistes d'onboarding plus tard. Ne sautez pas de niches après un test échoué.

Écrit §1.

Étape 2 : Vérification de la standardisation (Lire F§1.6, F§4.10, F§4.12)

• Listez au moins 5 substituts, y compris les gratuits : 2-3 applications concurrentes nommées, YouTube/TikTok, ChatGPT ou une autre IA gratuite, la fonctionnalité de l'OS, le stylo et le papier / un livre / un tuteur, et ne rien faire. Rassemblez les prix et les thèmes d'avis selon l'étape 0.3.
• Tableau : substitut | coût monétaire | temps pour le résultat | effort | rêve / probabilité / temps / effort notés 0, 0,5 ou 1 (1 = favorise l'acheteur : grand rêve, forte probabilité, temps court, faible effort) | total /4 | pourquoi quelqu'un le choisit.
• Répondez : (1) Comment un prospect compare-t-il ces options dans la recherche du store (icône, capture d'écran 1, note, prix) ? (2) Où cette application gagne-t-elle en temps ou en effort ? Rapide bat gratuit. (3) Quelle phrase en fait une catégorie à part (méthode nommée + avatar + résultat + intervalle) ? Si elle nécessite une explication, elle échoue.

Écrit §2.

Étape 3 : Audit de l'équation de valeur (Lire F§4)

Valeur = (Résultat rêvé x Probabilité perçue) / (Délai x Effort et sacrifice). Notez chaque moteur de 1 à 5 ; plus haut est toujours meilleur, donc le temps et l'effort sont notés sur leur petitesse. Calibrez selon le rythme naturel de l'app (jeu quotidien, budget hebdomadaire, rapport mensuel) ; F§4.11 a des exemples pour trois types d'applications.

Moteur	Mesure de l'app	1	5
Résultat rêvé	Le résultat tel que les pairs ou le partenaire de l'utilisateur le remarqueraient	Une fonctionnalité (« Débloquer Pro »)	Un résultat spécifique et un intervalle, dans une scène qui compte pour le groupe de pairs ou le partenaire de l'utilisateur
Probabilité	Note et nombre d'avis, statistiques de résultats mesurés, base de référence personnelle, plan personnalisé, démo du résultat, signaux d'adéquation, renversement du risque	Aucune preuve	Données de base + « les gens comme vous » + plan + garantie
Délai	Temps jusqu'à la première victoire ressentie ; un gain mesuré avant la fin de l'essai ou le premier renouvellement ; progrès visibles	Aucune victoire ressentie avant la première facturation	Victoire ressentie dans la première session (cible en secondes) ; gain mesuré avant la fin de l'essai
Effort & sacrifice	Taps, saisie, compte, configuration, autorisations, minutes par cycle, volonté, embarras	Compte + configuration + murs d'autorisation avant la valeur ; longues sessions	Seulement les étapes dont le travail principal a vraiment besoin, aucune avant la valeur ; les erreurs restent privées

• Pour chaque moteur à 3 ou moins, listez les correctifs logiques (changer le build) et psychologiques (barres de progression, écran de plan, compte à rebours avant le prochain déblocage, cadrage par jour, renommage). Essayez d'abord le psychologique ; c'est moins cher.
• Poussez le dénominateur vers zéro : à quoi ressemblerait la version « fait pour vous » ?
• Nommez le rêve à long terme et les avantages pour lesquels les gens restent, avec des jalons au rythme de l'app (par exemple jour 1 / 3 / 7 / 30).

Écrit §3 (scores avant ; scores après ajoutés à l'étape 11).

Étape 4 : Inventaire des problèmes (Lire F§7.2)

1. Parcourez le parcours : découverte > page store > installation > onboarding > première session > (multi-utilisateur : invitation envoyée > deuxième utilisateur rejoint) > jour 2 > première semaine > plateau ou ennui > facturation et renouvellement > événements de la vie (voyage, semaine chargée, nouveau téléphone, appareil partagé) > partage > le problème suivant après le succès.
2. À chaque étape, vérifiez quatre catégories : pas rentable (rêve) ; ça ne marchera pas pour moi / je ne vais pas persévérer (probabilité) ; trop difficile / j'aurai l'air stupide (effort) ; trop lent / pas de temps (temps).
3. Écrivez chaque obstacle dans les propres mots de la croyance limitante de l'utilisateur. Fouillez les avis, Reddit, les e-mails de support, les raisons d'annulation, l'abandon à l'onboarding (pré-lancement : les avis des concurrents).
4. Étiquetez chacun avec son moteur. Visez 20+ ; 30-60 est normal. Classez par fréquence x sévérité.

Corps : les 25 premières lignes (# | étape | mots de l'utilisateur | moteur | source). Le reste va à l'Annexe D.

Écrit §4.

Étape 5 : Solutions et véhicules de livraison (Lire F§6, F§7.3-7.8)

1. Transformez chaque problème en « Comment [bénéfice] même si [obstacle] ». Le corps montre les 10 premiers ; le reste va à l'Annexe D.
2. Listez les véhicules pour chaque problème : au moins 3 pour chacun des 10 premiers et au moins 1 pour chacun des autres, avant de juger aucun (diverger, puis converger). Regroupez les problèmes qui partagent un véhicule. Utilisez le cube de livraison :

Axe	Options
Attention	1:1 (fondateur, coach humain, tuteur IA) / petit groupe (duel d'amis, ligue familiale, cohorte) / 1:nombreux (fonctionnalité, contenu, classement, événement en direct)
Effort	Outil DIY / Plan guidé DWY ou coach IA / Automatisation DFY
Support	In-app, widget, notification, montre, écran verrouillé / Live Activity, e-mail, chat, voix, session en direct, imprimable
Vitesse de réponse	Instantané 24/7 (logiciel, IA) / même jour / hebdomadaire

3. Exercice de la brique : changez un attribut à la fois (surface, format, durée de session, taille sociale, audience, payeur) et notez les nouvelles idées.
4. Test 10x / 1/10 : que livreriez-vous à 10x le prix ? Comment les utilisateurs gagneraient-ils encore à 1/10 ? Gardez la meilleure idée de chaque extrémité.

Écrit §5 : problème | ligne « comment » | véhicules (codes du cube).

Étape 6 : Tailler et empiler (Lire F§7.9-7.11)

• Tailler : retirez tout ce qui ne sert pas le résultat principal de l'avatar et du positionnement de l'étape 1. Supprimez les fonctionnalités que les utilisateurs ne paieraient pas pour. Supprimez les fonctionnalités que les substituts gratuits fournissent mieux. Tout ce qui reste doit être soit le résultat, soit une étape mesurable non substituable vers celui-ci. Appliquez les 4 questions de F§7.9.
• Empiler : commencez par un résultat de base pour lequel le substitut le moins cher facture. Au-dessus, empilez les accélérateurs (vitesse, guidage, responsabilité, personnalisation). Ajoutez une proposition de résultat (promesse + garantie). Enfin, la « cerise sur le gâteau » (délice, prestige, identité, tribu). Chaque couche augmente le prix sans en augmenter proportionnellement le coût. Ne dépassez jamais 7 éléments dans la pile principale ; au-delà, regroupez-les ou déplacez-les en bonus.
• Ordre des couches : fonctionnalité de base > résultat attendu > résultat garanti > résultat étendu > résultat extrême. L'offre est nommée d'après la couche expédiée (F§7.11).

Écrit §6 : la pile de base de 5 à 7 couches montre chaque couche, ce qu'elle comprend, l'augmentation de prix par rapport à la couche précédente, et le coût marginal de livraison.

Étape 7 : Tarification et paliers (Lire F§3, F§5, F§15)

1. Prix de base = (valeur du substitut + valeur du temps économisé + valeur de l'aversion à la perte) x part de l'utilisateur s'il atteint le résultat. La valeur du substitut provient de l'étape 2. Le temps économisé provient de F§3.5. Formules des couches dans F§5.9.
2. Paliers : commencement (juste assez pour un résultat), standard (le meilleur rapport qualité-prix, la valeur ajoutée la plus élevée), professionnel (tout, plus la couche de prestige). L'écart de prix entre le début et le professionnel doit être de 10x-20x. Le standard devrait être 3-4x plus cher que le début. Si vous avez des coûts variables par utilisateur, créez un quatrième palier (entreprise ou plateforme) qui les couvre (F§5.5).
3. Abonnements : 4 périodes de facturation (hebdomadaire, mensuelle, trimestrielle, annuelle). Calculez le prix annuel comme s/hebdomadaire x 48, s/mensuel x 12, s/trimestriel x 4. Le rapport entre le plus cher et le moins cher (par période) doit être d'au moins 4x ; 6-8x est meilleur. Ne facturez jamais un abonnement pour un résultat unique (F§15.3).
4. Frais de store et TVA : soustrayez 15 % ou 30 % selon le programme, plus la part de TVA des étapes 0.7/0.8. Le prix que vous définissez est le prix brut. Le net doit couvrir votre coût plus la marge de distribution. Si la marge est < 50 %, augmentez les prix ou réduisez les coûts.
5. Essai gratuit ou freemium : un essai gratuit nécessite une carte de crédit (C§3). La première période de facturation après l'essai doit être plus courte que la période standard (par exemple, un essai d'une semaine suivi d'un mois) pour réduire le choc. Le freemium ne fonctionne que si les utilisateurs gratuits génèrent du contenu ou de la valeur réseau pour les utilisateurs payants.
6. Lien avec l'étape 1 : le plafond de revenu de l'étape 1 est (payeurs atteignables x prix annuel moyen x part retenue). Si ce chiffre est inférieur à l'objectif de revenu, vous devez soit augmenter les prix, soit élargir le marché. Ajustez §1.3.
7. Ancrage : montrez le prix le plus élevé en premier, puis le prix recommandé. Ou montrez le prix unitaire le plus bas en premier (prix dégressifs). Testez les deux.

Écrit §7 : tableau des paliers et des prix avec les prix bruts, les frais de store, la TVA, le net, la marge et le nombre de clients nécessaire pour atteindre l'objectif. Annexes des tests de prix.

Étape 8 : Rareté, urgence, bonus (Lire F§9, F§10, F§12)

• Rareté : légitime uniquement. Nombre limité de places dans une cohorte, invite uniquement, offre de lancement, édition limitée. Pas de faux compteurs de stock. La rareté doit avoir une date de fin et doit être supprimée après expiration (ou réaffectée, marquée comme réaffectation).
• Urgence : minuterie (durée de l'offre, pas de session). Doit être vérifiable (par exemple, date de lancement). Ne l'utilisez pas pour les abonnements renouvelés automatiquement. Une minuterie en ligne avec une date/heure réelles est préférable à un compte à rebours stocké localement.
• Bonus : supplémentaires à la pile principale (pas de re-package). Reliez-les à des déclencheurs d'action (achat dans les 24 heures, partage, évaluation). Donnez-leur une valeur perçue (prix du marché réel). Maximum 3. Ils doivent être expédiés avec le produit principal. Pas de bonus vides (futurs livres électroniques, listes de contrôle que vous n'écrivez pas).

Écrit §8.

Étape 9 : Garantie (Lire F§11)

• Par plateforme : (1) Paiement initial : remboursement intégral dans les X jours via le système de remboursement du store (Apple : demandez au support de l'utilisateur, pas d'automatisation ; Google : automatisez via le Play Console après X jours). (2) Renouvellement : annulation à tout moment, remboursement au prorata de la période non utilisée (si la loi ou les règles du store l'exigent). (3) Abandon du service : remboursement intégral de la période non utilisée plus un crédit de 10 % sur un achat futur.
• Par résultat : « Si vous suivez le plan et n'atteignez pas [résultat] dans [intervalle], remboursement intégral plus [crédit] sur votre prochain achat. » Doit être payable sur les deux stores si listé sur les deux. Pas de garanties conditionnelles (par exemple, « si vous montrez la preuve que vous l'avez fait ») – elles sont trop restrictives.
• Conformité : C§5. Ajoutez les conditions de la garantie en petits caractères lors du paiement. Affichez la garantie sur la page du store (pas de capture d'écran, utilisez un badge).

Écrit §9 : texte de la garantie, petits caractères, conditions de paiement.

Étape 10 : Nommer (Lire F§13)

• Nom de l'app et nom de l'offre (palier). Le nom de l'app doit être mémorisable, épelable, de marque déposable et non un nom générique. Le nom de l'offre (palier) doit déclarer le résultat (« Maitre », « Elite » ou « Pro » n'est pas un résultat. « L'Accélérateur de Carrière » ou « l'Exterminateur de Mauvaises Habitudes » en est un).
• Sous-titre : précise l'avatar, l'intervalle et le résultat (par exemple, « Pour les développeurs qui veulent un poste de Lead Dev en 6 mois »). Le sous-titre peut être testé A/B dans la fiche du store.
• Positionnement : nom de l'app – sous-titre – nom de l'offre. Assurez-vous que les noms ne sont pas déjà utilisés dans la même catégorie (C§11).

Écrit §10 : nom de l'app proposé, sous-titre, nom de l'offre pour chaque palier et justification.

Étape 11 : Paywall par emplacement (Lire F§14)

• Emplacement 1 : fiche du store. Le paywall est le prix (pas de paywall avant téléchargement). Les pages produit personnalisées (pour les sous-groupes de niche) peuvent montrer des offres différentes. La note, les captures d'écran et la description de l'app doivent correspondre à l'offre (pas de promesses qu'elle ne tient pas).
• Emplacement 2 : onboarding. L'écran de bienvenue (titre) + écran de proposition de valeur (le résultat) + écran de l'offre (prix et palier) + écran de paiement. Montrez la garantie et la rareté/urgence avant le paiement. Option : essai gratuit ou paiement initial différé (par exemple, « 7 jours gratuits, puis 9,99 $/mois »).
• Emplacement 3 : premier résultat. Le paywall n'apparaît qu'après que l'utilisateur a ressenti la première victoire (ou au moment où il en a besoin). Pour les applications de productivité, après avoir saisi 3 tâches. Pour les applications de fitness, après avoir terminé la première séance d'entraînement. C'est le meilleur emplacement pour les applications avec un nombre élevé d'utilisateurs gratuits convertis après avoir vu la valeur.
• Emplacement 4 : paywall de fonctionnalités. Utilisateur tape sur une fonctionnalité verrouillée -> paywall avec le nom de la fonctionnalité et un avantage. Bon pour les paliers avec des fonctionnalités verrouillées.
• Emplacement 5 : paywall de renouvellement. Avant la fin de l'essai ou de la période d'abonnement, rappelez aux utilisateurs ce qu'ils obtiendront/perdront. Offrez une remise de renouvellement (par exemple, 30 % de réduction pour une année complète).
• Emplacement 6 : paywall de rattrapage. Après une séquence d'échecs (par exemple, l'utilisateur n'a pas ouvert l'application depuis 3 jours), offrez une remise ou un rappel « Vous êtes sur le point de perdre votre progression ».

Écrit §11 : pour chaque emplacement, l'écran, le texte, le prix et l'offre montrés, et pourquoi. L'offre recommandée est celle de l'emplacement choisi. Les autres sont en annexe.

Étape 12 : Gain rapide à l'onboarding (Lire F§14.2)

• Le gain rapide est la première victoire ressentie par l'utilisateur (pas la configuration). Elle doit arriver (a) dans la première session et (b) dans les 60 secondes suivant l'ouverture de l'application. Pour les applications complexes (par exemple, l'édition vidéo), le gain rapide peut être un modèle ou une automatisation qui produit un résultat immédiat.
• Chemin de gain rapide : (1) Ouvrir l'application -> (2) Configuration minimale (0-2 écrans) -> (3) L'application fait le travail ou guide l'utilisateur à travers un modèle -> (4) L'utilisateur voit le résultat (fichier, progression, analyse, etc.) -> (5) « Vous l'avez fait. » Célébration.
• Barrière à l'entrée : Abaissez-la. Pas de connexion obligatoire si une démonstration en local fonctionne. Pas de configuration de notifications dès le départ. Reportez les autorisations après la valeur.
• Test : chronométrez l'arrivée du gain rapide. Si cela prend plus de 60 secondes, simplifiez.

Écrit §12 : script du gain rapide, temps moyen au premier gain rapide en secondes.

Étape 13 : Plan de test (Lire F§15)

• Ce qu'il faut tester : prix, offres, emplacements de paywall, timing du gain rapide, texte de garantie, noms. Au moins 3 tests pour le premier mois. Un seul changement à la fois (A/B).
• Comment tester : (1) Pages produit personnalisées (Store) pour différentes offres. (2) Paywall A/B (server-side). (3) Tests d'onboarding (server-side). (4) Tests in-app (feature flag).
• Métriques : taux de clic sur le paywall, taux de paiement, taux d'annulation, LTV, conversion d'essai à payant, taux de rétention à 7 jours. Chaque test nécessite une taille d'échantillon de N=300 par variante (ou N=100 si l'effet est > 50 %).
• Calendrier : test sur 2 semaines. Analyse le lundi suivant. Décide du gagnant. Déploie.

Écrit §13 : tableau des tests avec l'hypothèse, la variante A/B, la métrique, la taille d'échantillon, la durée, le critère de réussite.

Étape 14 : Plan d'expédition

• Avant l'expédition : auditez les violations (étape 0.5). Corrigez-les. Vérifiez les prix et les garanties sur chaque store. Vérifiez les conditions de service et la conformité légale. Obtenez l'approbation d'un avocat pour les affirmations garanties.
• Expédition : mettez à jour la fiche du store avec la nouvelle offre sous la forme d'un nouveau build OU d'une mise à jour des métadonnées (pas besoin de re-build pour les prix). Activez les pages produit personnalisées. Activez les tests.
• Après l'expédition : surveillez les commentaires. Recueillez les retours des utilisateurs sur le paywall et les prix. Si le taux de désabonnement à 7 jours dépasse 20 %, revoyez la garantie et l'onboarding.

Écrit §14 : liste de contrôle, calendrier d'expédition, plan de surveillance post-expédition.

Annexes

• Annexe A : Décisions contestées (de l'étape 0.6) avec la raison de la contestation et l'alternative.
• Annexe B : Sources de recherche (de l'étape 0.3) avec URL, date, et bref résumé de ce qui a été trouvé.
• Annexe C : Offres alternatives (pour les emplacements de paywall de l'étape 11 et les paliers). Tableau : offre | prix | emplacement | justification.
• Annexe D : Inventaire complet des problèmes et solutions (de l'étape 4, après les 25 premières). Tableau : problème | solution | véhicules.
• Annexe E : Résultats des tests (de l'étape 13) après que les tests ont été exécutés. Tableau : test | résultat | décision.

Sortie

Écrivez le corps principal (étapes 0 à 14) dans offer/grand-slam-offer.md (ou ./<slug-app>-grand-slam-offer.md). Les annexes sont écrites dans le même fichier après le corps principal.