Expert Quiz Funnel
Skill expert pour concevoir, auditer, coder et optimiser un quiz funnel + paywall haute-conversion. Couvre stratégie, copy, personnalisation, intégration paywall, benchmarks 2026, A/B test playbook et stack technique.
Le quiz funnel est l'arme n°1 de conversion mobile/SaaS 2024-2026. Cal AI (30 M$ ARR), Noom (750 M$ ARR), Flo (9 M$/mois), Opal, Stoic, BetterMe, Blinkist tournent tous sur ce pattern : quiz → plan personnalisé → paywall. Ce skill encode ce qui marche.
Quand utiliser ce skill
Déclencheurs :
- « Concevoir un quiz funnel / onboarding quiz / tunnel d'abonnement »
- « Optimiser un paywall (app mobile, SaaS web, freemium, période d'essai) »
- « Auditer un onboarding existant »
- « Personnaliser un paywall selon les réponses utilisateur »
- « Choisir hard paywall vs freemium vs soft paywall »
- « Définir les mécaniques d'essai (3j vs 7j vs 14j vs reverse trial) »
- « Faire un teardown style Noom / Cal AI / Blinkist »
- « Coder un quiz funnel Next.js »
- « Page de tarification SaaS (style Linear, Notion, Anthropic) »
- Sous-skill Dashboard Réponse : « back-office quiz », « dashboard admin quiz », « voir les réponses », « voir les leads / sessions », « drop-off rate par étape », « completion rate », « distribution des réponses par question », « export CSV des leads », « page admin pour une session » → rediriger vers 12-admin-dashboard.md.
NE PAS déclencher pour :
- Onboarding produit B2B post-inscription pur (utiliser
onboarding-cro) - Flux d'annulation / rétention churn (utiliser
churn-prevention) - Page d'atterrissage publique sans quiz (utiliser
landing-page-expert)
Thèse centrale (à imprimer dans la mémoire de l'agent)
- L'onboarding est une conversion de croyance, pas un tour de produit. Chaque écran doit déplacer l'utilisateur d'un état « incertitude » vers « ce produit comprend mon cas, peut me donner un résultat, vaut le prochain engagement ».
- Le questionnaire est un asset de conversion uniquement s'il produit une personnalisation visible. Si une réponse ne change ni le plan, ni le paywall, ni le segment, ni l'expérience → la question doit disparaître.
- Les 5 écrans avant le paywall comptent plus que le paywall lui-même (Stormy, 4500+ A/B tests). Onboarding + paywall = un seul funnel.
- Day 0 est tout : 90% des débuts d'essai arrivent J0 (Adapty 2026), 84% des annulations arrivent J0-1 sur essai 3j (RevenueCat 2026). Si l'aha n'est pas dans la première session, c'est mort.
- Hard paywall n'a pas de pénalité de rétention vs freemium (RevenueCat 2026, 115 000 apps : rétention Y1 ~27% vs ~28%). La légende « freemium retient mieux » est morte. Choix = fonction du CAC, pas d'idéologie.
- Un long quiz convertit SI chaque question paie son loyer. Noom = 113 écrans qui marchent. La majorité des quiz longs ne sont que de la friction.
Workflow par défaut quand on invoque ce skill
Étape 1 — Diagnostic
Avant tout output, comprendre :
- Modèle économique : abonnement mobile / SaaS B2B / SaaS B2C / hybride web-to-app / achat unique ?
- Plateforme : iOS seulement / Android seulement / hybride / web seulement ?
- CAC & LTV cibles : si CAC > 30 € → hard paywall probablement ; si CAC < 5 € et viralité → soft/freemium.
- Catégorie : Santé & Fitness / Éducation / Productivité / IA / Finance / Lifestyle / Dating / SaaS dev tools / SaaS PLG / Enterprise vente assistée ? Les benchmarks et patterns dominants varient.
- Aha moment : quelle est l'action qui corrèle le plus avec la rétention J7 ? (À faire trouver à l'utilisateur si pas clair.)
- État actuel : zéro / quiz existant à auditer / paywall existant à optimiser / redesign complet ?
- Contraintes Apple/Google : hard paywall iOS Jan 2026 = toggle paywall mort (rejet Guideline 3.1.2), close button obligatoire, etc. Voir reference 04.
Si plusieurs infos manquent et bloquent → demander à l'utilisateur en un seul tour groupé (3-5 questions max). Sinon avancer avec des hypothèses explicitées.
Étape 2 — Choix structurels (avant la copy)
Décider dans cet ordre, en s'appuyant sur les références :
| Décision | Référence | Default 2026 |
|---|---|---|
| Hard / soft / freemium / reverse trial | 05 §Hard vs soft | Hard pour mobile B2C abonnement si CAC justifie ; reverse trial pour SaaS PLG mature ; freemium pour produit réseau/social |
| Longueur du quiz | 02 §Long vs court | 8-12 questions Santé/Éducation ; 4-6 utilitaires ; 30+ style Noom si justifié |
| Placement du paywall | 04 §Placement | Après plan personnalisé (pattern dominant) ; FitnessAI/Rootd ont +2x install-to-trial avec paywall avant onboarding (à tester) |
| Durée d'essai | 04 §Trial mechanics | 3j (config top Adapty : hebdomadaire + essai 3j) ou 7j (sweet spot général) ; 14-30j Productivité/Business |
| Forfaits visibles | 05 §Number of plans | Un seul forfait visible + lien « Voir tous les forfaits » dépasse souvent 3-forfaits en mobile ; SaaS = 3 self-serve + Enterprise |
| Forfait par défaut | — | Annuel présélectionné → 2-3x mix annuel, +70% revenus annuels (Sunflower/Stormy) |
| Texte CTA | 08 | « Continuer » bat descriptif +111% (Stormy) ; « Commencer l'essai gratuit » / « Essayer pour 0,00 $ » / « Obtenir [Nom du forfait] » |
| Affichage prix | 05 §Price framing | Cadrage par semaine (39,99 $/an → « 0,76 $/semaine ») + badge « ÉCONOMISEZ 75% » ; arrondi pour SaaS premium (20 $, 30 $) |
| Web-to-app vs IAP | 04 §Web-to-app | Hybride IAP+web sur iOS US (web-only perd 6,5% net vs IAP) ; web-to-app standard pour Santé/Éducation/IA à haute LTV |
Étape 3 — Architecture du flow (livrable principal)
Cartographier le funnel écran par écran avec, pour CHAQUE écran :
- Objectif/croyance convertie (ex. « L'application comprend mon contexte »)
- Type d'écran (entrée / question / micro-insight / chargement / résultat / paywall / engagement)
- Question + 4-5 options (si Q) ou copy headline + sous-titre (si insight/résultat/paywall)
- Personnalisation déclenchée : quelle variable cet écran alimente en aval
- Risque de drop-off + mitigation
- Suivi d'événement (voir 11)
Modèle de flow gagnant (à adapter) :
[Promesse d'entrée : axée résultat, 1 écran max]
→ Question d'objectif (objectif principal)
→ Situation actuelle (état actuel)
→ Friction (blocage principal)
→ MICRO-INSIGHT #1 (utiliser réponses 1-3 → « On va adapter ton plan pour… »)
→ Question de niveau/contexte
→ Préférence/fréquence
→ MICRO-INSIGHT #2 (preuve sociale segmentée : « Les [segment] obtiennent +X en Y semaines »)
→ Question d'engagement (engagement léger)
→ Écran de chargement (3-7s, « On construit ton plan… »)
→ Résultat personnalisé / aperçu (score + plan + calendrier)
→ [Optionnel : Première petite action / aperçu]
→ PAYWALL personnalisé (titre = objectif, puces = points douleur, CTA = verbe d'action)
→ Compte/email (pour sauvegarder/synchroniser, jamais avant)
→ Permission au moment de l'usage
→ Accueil avec prochaine action
Étape 4 — Copy concrète
Pour chaque écran, livrer une copy précise (voir 08-copy-library.md pour la bibliothèque) :
- Pas de fonctionnalités → résultats / bénéfices
- Une idée par question, 4-5 options mutuellement exclusives
- Questions sensibles : précéder d'un « On te demande ça pour adapter le plan, pas pour te juger »
- Toujours offrir une échappatoire : « Passer » / « Je ne sais pas encore » / « Autre »
- Copy de chargement honnête : « On calcule ton plan à partir de tes réponses » (pas « Analyse en cours » générique)
- Titre du paywall = objectif personnalisé : « Débloque ton plan 14 jours [objectif] » pas « Choisissez un forfait »
Étape 5 — Logique de personnalisation
Décrire le mapping réponses → outputs :
- Variables collectées (typées) → ID de segment
- Segment → modèle de plan / variante de paywall / tarification
- Pattern de code réutilisable (voir 03-personalization-engine.md pour des exemples Next.js+Zustand)
Test de validité : si deux utilisateurs avec des réponses opposées voient le même résultat, ce n'est pas une vraie personnalisation. À supprimer ou refactoriser.
Étape 6 — Design et intégration du paywall
Voir 04-paywall-integration.md. En résumé :
- Layout : single-page, pas de scroll, 3-5 puces avec icônes (pas de tableau sur mobile), liste horizontale des forfaits, badge « Le plus populaire » sur la cible.
- Mécanique d'essai : iOS = pas de toggle paywall (mort Jan 2026, rejet 3.1.2). Utiliser Blinkist timeline pattern (Aujourd'hui → Rappel Jour X → Débit Jour Y) → +23% conversion essai prouvé, -55% de plaintes.
- Cadrage des prix : présélection annuelle, affichage par semaine (« 0,76 $/semaine »), badge « ÉCONOMISEZ 75% ».
- Preuve sociale : nombre d'utilisateurs + 4.2-4.5★ + nombre d'avis + 1-2 témoignages.
- CTA : « Continuer » / « Commencer l'essai gratuit » / « Essayer pour 0,00 $ » + « Aucun engagement, annulez à tout moment ».
- Bouton de fermeture visible (Apple HIG, sinon rejet Review).
- Tiroir de sortie (reformuler → downsel → OTO 25-33%) capable de capter +15-20% de revenus, mais limiter à 2-3 expositions et audit Apple.
Étape 7 — Backlog A/B test priorisé
Ne pas tester au hasard. Prioriser par taux de gain Adapty 2026 :
| Type de test | Taux de gain LTV | Priorité |
|---|---|---|
| Localisation | 62,3% | #1 (le plus sous-estimé) |
| Structure d'essai | 59,6% | #2 |
| Durée du forfait | 58,7% | #3 |
| Nombre de forfaits | 57,1% | #4 |
| Changements de prix | 45,5% LTV / 28,3% conv brute | #5 (hausse $, pas %) |
| Visuel/copy uniquement | 34,6% | #6 (bas) |
Les apps qui réalisent 14,7+ expériences/an gagnent jusqu'à 40x de revenus vs les non-testeurs. Voir 09-ab-test-playbook.md.
Étape 8 — Instrumentation analytics
Taxonomie d'événements minimum :
onboarding_started
onboarding_step_viewed (step_index, step_label)
onboarding_step_completed
question_answered (question_id, answer_id, segment)
insight_viewed (insight_id)
loading_viewed
result_viewed (segment, score, plan_id)
paywall_viewed (paywall_variant, segment, trial_duration, plan_interval, price)
paywall_plan_selected
paywall_closed (reason: x | back | scroll_off)
trial_started
purchase_completed (price, currency, plan_interval)
exit_offer_viewed
exit_offer_accepted
permission_priming_viewed
permission_granted
signup_completed
first_value_completed
d0_returned, d1_returned, d7_retained
trial_cancelled (Day 0/1/2…)
refund_requested
first_renewal
Ne JAMAIS optimiser sur le début d'essai sans regarder paiement + remboursement + premier renouvellement + rétention D7. Voir 11-metrics-and-tracking.md.
Étape 9 — Backend admin « Dashboard Réponse » (sous-skill)
GA4 / Mixpanel ne suffisent pas pour une équipe support/produit/sales : il faut un back-office maison qui montre, par session, les réponses brutes + l'état de conversion + un funnel par étape avec drop-off + la distribution des réponses par option. C'est le sous-skill Dashboard Réponse (12-admin-dashboard.md).
Déclencheurs spécifiques : « back-office », « dashboard admin », « voir les réponses », « drop-off rate par étape », « completion rate », « voir une session », « export CSV des leads ».
Le sous-skill livre, fonctionnant avec n'importe quel quiz funnel (schema-agnostic) :
- Data model Prisma :
QuizSession(identité + réponses JSON + UTM + état conversion + resultData) +QuizEvent(journal des événements granulaire pour le vrai funnel et le temps par étape). - Configuration unique du quiz (
lib/quiz/config.ts) — source de vérité partagée front/admin pour les labels des questions et options. - 35+ métriques calculées : volume (24h/7j/30j), engagement (moyenne/médiane étape atteinte, rebond, complétion, étape de sortie principale), capture d'email, conversion (taux, temps jusqu'au paiement, remboursement), funnel par étape avec drop-off absolu et %, distribution des réponses par option × écart de conversion vs taux global, meilleures sources UTM/pays/appareil, tendance journalière 14j, segments convertisseurs.
- 4 pages admin : aperçu KPI/funnel/trend, liste des sessions filtrable, détail de session (toutes réponses + événements chronologiques + JSON brut), distribution des réponses par question.
- Export CSV sécurisé (
/api/admin/export). - Auth fail-closed via middleware Basic Auth (ou NextAuth/Clerk) — refuser 503 si secret absent.
- Checklist d'intégration en 8 étapes pour brancher le sous-skill sur un projet existant.
À utiliser en complément de l'étape 8 (instrumentation événements) : les événements alimentent le dashboard, le dashboard alimente la décision growth.
Étape 10 — Format de sortie
Selon la requête, livrer :
- Audit → framework SCORE (Specific / Commitment / Output / Reduced friction / Experimentation), section par section, avec problème → impact → recommandation → priorité.
- Stratégie → cartographie du funnel + écran par écran + copy + logique de personnalisation + séquencement du paywall + événements + backlog A/B + risques.
- Code → composants React/Next.js avec store Zustand typé + persistance + analytics câblés + événements de suivi. Stack de référence : Next.js 14 App Router + TypeScript + Tailwind + Framer Motion + Zustand persist + Prisma/Postgres + webhook Stripe. Voir 10-tech-stack.md.
- Teardown → cartographie du flow + copy textuelle + tactiques psycho + chiffres connus + ce qui s'applique au cas utilisateur.
Tableau de référence rapide — chiffres clés 2026 à connaître
| Chiffre | Source | Utilisation |
|---|---|---|
| Hard paywall 5x conversion vs freemium (D35 10,7% vs 2,1%) | RevenueCat 2026 | Argument pour basculer freemium → hard si CAC le permet |
| Rétention Y1 identique hard ~27% vs freemium ~28% | RevenueCat 2026 | Démontrer le mythe « freemium retient mieux » |
| Apps 14,7+ exp/an = jusqu'à 40x revenus | Adapty 2026 | Justifier l'investissement dans les tests |
| 89,4-90% débuts d'essai Day 0 | RevenueCat / Adapty 2026 | Prioriser Day 1 experience sans faille |
| 84% annulations J0-1 sur essai 3j | RevenueCat 2026 | Trial design critique : heure de réveil, pas jour J+1 |
| Localisation = 62,3% win rate LTV | Adapty 2026 | Priorité #1 d'expérimentation (surtout DACH/JP/KR/FR) |
| Changement nombre de forfaits = 57,1% win rate | Adapty 2026 | Tester « 1 forfait + lien voir tout » vs 3 forfaits |
| Bouton de fermeture du paywall augmente la conversion | Divers | Paradoxe : réduire l'anxiété augmente le passage à l'acte |
| Perte 6,5% net iOS US web-only vs IAP | (analyse 2025-26) | Plaidoyer pour hybride IAP + web si seuils Apple dépassés |
| 111% lift « Continuer » vs CTA descriptif | Stormy | Changer la copy du CTA devrait être un test permanent |