Le playbook CRO WooCommerce solo (modèle gratuit)
Le système d'exploitation hebdomadaire complet de CRO pour boutiques WooCommerce solos à moins de 50 000 $/mois. Douze articles d'analyse étayée distillés en une boucle en 7 étapes que vous pouvez exécuter en 10 minutes. Respectueux de la vie privée, sans GA4, sans consultants, sans tableaux de bord à 99 $/mois — juste le rituel qui compose.
Il y a trois semaines, ce blog comptait zéro article sur le CRO WooCommerce.
Aujourd’hui, vous avez un système d’exploitation complet. Douze articles. Quarante heures de recherche sous-jacente. La boucle hebdomadaire en 7 étapes qu’une boutique WooCommerce solo peut exécuter en 10 minutes. Les cinq goulets d’étranglement mobiles étayés par la recherche. Les quatre anti-modèles de pages de sortie que personne d’autre ne démonte. La réconciliation de revenus Klaviyo-vs-Woo à 86 000 $/24 000 $. La règle de santé du canal avec trois mises en garde que les SERP se trompent.
Si vous avez lu depuis l’article 1, vous avez déjà absorbé l’essentiel de tout cela. Si vous atterrissez ici en premier, c’est l’article qui relie tout — la distillation imprimable, partageable, à donner à votre VA, de tout le sprint.
Depuis la v1.0.0 (mai 2026), le Rapport Revenu WooCommerce est livré gratuitement sur WordPress.org — Commandes, Revenu (net), Panier moyen, Total et Taux de remboursement, Revenu par canal sur 8 canaux (dont un canal dédié Assistants IA couvrant 14 hôtes), Top Produits, et un Tunnel Panier-vers-Achat en 4 étapes. Les commandes historiques se remplissent automatiquement à la première ouverture du rapport. La boucle en 7 étapes ci-dessous est mise à jour pour utiliser le Rapport Revenu là où un croisement existait avant ; la liste d’attente du tier Growth/payant ci-dessous est pour les couches opérationnelles (alertes d’anomalies, alertes Slack/Telegram sur le revenu, MER de dépenses publicitaires, résumé exécutif par IA) qui se greffent par-dessus.
Ce que ce playbook vous donne
- La boucle hebdomadaire CRO complète en 7 étapes, avec chaque étape liée à l’article pilier plus profond.
- Une fiche imprimable d’une page de chaque règle de décision du sprint.
- La liste honnête de ce que le Rapport Revenu v1.0.0 couvre et de ce qui reste sur la feuille de route du tier Growth.
- La liste à éviter — 9 choses à NE PAS faire, avec la recherche qui démonte chacune.
- La liste d’attente du tier Growth pour les couches opérationnelles (alertes d’anomalies, alertes Slack/Telegram sur le revenu, MER de dépenses publicitaires, résumé exécutif par IA).
La boucle hebdomadaire CRO en 7 étapes, complètement développée
Ouvrez /wp-admin → Statnive chaque lundi matin. Exécutez-les dans l’ordre. La version ci-dessous ajoute le « pourquoi » plus profond pour chaque étape ; la version 10 minutes est la forme courte imprimable.
Étape 1 — Lire l’ambiance (Vue d’ensemble)
Où : Statnive → rapport Vue d’ensemble. 7 derniers jours vs 7 jours précédents.
Règle de décision : tout glissement de part de canal > 25 % d’une semaine à l’autre = signal pour l’étape 2. La plupart des semaines, rien ne change ; c’est en soi un signal.
Pourquoi cela compte : au moment où un canal casse silencieusement (Google a désindexé une page, une publicité payante a été rejetée, un e-mail a atterri en spam), le premier signal est dans l’écart d’une semaine à l’autre de la Vue d’ensemble — souvent une semaine entière avant que l’impact sur le revenu en aval n’apparaisse dans l’admin WooCommerce. L’attraper dans la Vue d’ensemble épargne une semaine de saignée.
Lecture plus profonde : Analyse web respectueuse de la vie privée pour le CRO WooCommerce (article pilier 1).
Étape 2 — Auditer la qualité du canal (Sources)
Où : Statnive → rapport Sources. Triez par Sessions décroissant.
Règle de décision (règle de santé du canal) : un canal est sain si les rebonds ≤ moyenne du site ET la durée ≥ moyenne du site, avec ≥ 50 sessions sur une fenêtre de 7 jours. Les canaux qui échouent aux deux critères sont diagnostiqués — pas mis en pause.
Trois mises en garde que personne ne mentionne : (1) comparez à des cohortes d’intention équivalentes, pas à l’ensemble du site ; (2) exigez ≥ 50 sessions avant de tirer une conclusion ; (3) cadrez les échecs comme « d’abord diagnostiquer » plutôt que « d’abord mettre en pause ».
Pourquoi cela compte : Statnive livre 8 canaux auto-regroupés (Direct, Assistants IA, Recherche organique, Réseaux sociaux, E-mail, Référent, Recherche payante, Social payant) — y compris Assistants IA que GA4 route toujours vers Direct ou Organique. Pour les boutiques Woo solos à moins de 50 000 $/mois, l’attribution regroupée par canal est plus fiable que la modélisation multi-touch.
Lecture plus profonde : Trouver les meilleures sources de trafic WooCommerce sans GA4 (article de support 2).
Étape 3 — Trouver votre fuite prioritaire (Pages — Nombre de sorties)
Où : Statnive → rapport Pages. Triez par Nombre de sorties décroissant (pas par taux de sortie).
Règle de décision : la première page par Nombre de sorties est votre priorité — même si d’autres pages ont des taux de sortie « pires ». Une page avec 10 000 vues et 45 % de taux de sortie perd 4 500 sessions ; une page de 500 vues à 90 % en perd 450. Corrigez la première.
Pourquoi cela compte : chaque autre blog CRO trie par taux. C’est le piège. Trier par nombre = votre file de priorité pondérée par le trafic. Le calcul est implacable — et le rapport Pages de Statnive affiche le Nombre de sorties comme colonne, donc le classement est automatique.
Tie-breaker de position dans le tunnel (selon CXL PIE/ICE) : quand deux pages ont des Nombres de sorties similaires, pondérez plus haut les pages en bas de tunnel. PDP × 1,2, panier × 1,5, checkout × 1,5 contre les sorties de blog à 1,0.
Lecture plus profonde : Pages d’entrée et de sortie pour les ventes WooCommerce (article pilier 3) + Analyser les pages produit WooCommerce (article de support 4).
Étape 4 — Diagnostiquer mobile vs bureau (Appareils)
Où : Statnive → rapport Appareils. Croisez avec WooCommerce Analytics → Commandes.
Règle de décision : calculez mobile_CR ÷ desktop_CR. Référence 0,60-0,74. En dessous de 0,50 avec une part mobile au-dessus de 60 % = problème matériel.
Les 4 schémas de détection de problèmes mobiles :
- Trafic qui n’atteint jamais le checkout = problème d’UX mobile en haut de tunnel.
- Trafic qui atteint le checkout mais échoue = problème de checkout en bas de tunnel.
- Rebond mobile sur la page produit = UX spécifique à la PDP.
- Mauvais public dès le départ = problème de ciblage en amont, pas d’UX mobile.
Pourquoi cela compte : le mobile représente 70-78 % du trafic WooCommerce en 2026. Un gain d’un point de pourcentage sur mobile vaut deux fois le même gain sur bureau. Les 5 goulets étayés par la recherche, par ordre de priorité : LCP > 2,5 s, CTA au-dessus de la ligne de flottaison sur 375 px, friction de galerie d’images, formulaire/mot de passe/captcha de checkout, mauvais fournisseur de paiement.
Lecture plus profonde : Problèmes de conversion mobile dans WooCommerce (article pilier 5).
Étape 5 — Repérer l’hygiène UTM + le gaspillage publicitaire payant (Sources UTM)
Où : Statnive → rapport Sources → dimensions UTM (Source, Médium, Campagne).
Règle de décision : si votre part de Direct est > 25 %, vous avez presque certainement des lacunes de balisage UTM. Si une campagne payante a un trafic élevé mais échoue à la règle de santé du canal sur rebonds + durée, diagnostiquez avant de mettre en pause.
Les 3 défaillances d’hygiène UTM les plus courantes :
- Casse mixte —
utm_source=Facebooketutm_source=facebookdeviennent 2 canaux dans tout outil d’analyse. - Contamination par UTM sur liens internes — mettre des UTM sur des liens entre vos propres pages écrase la source d’origine.
- Fuite dark social — les clics sur les liens Slack, WhatsApp et clients e-mail atterrissent comme Direct parce que les applis de messagerie suppriment les sources. Le correctif est un balisage UTM cohérent sur chaque lien partageable que vous publiez.
Lecture plus profonde : Arrêter de gaspiller du budget publicitaire avec UTM (WooCommerce) (article de support 6).
Étape 6 — Géographie + Langues pour la localisation (mensuel, pas hebdomadaire)
Où : Statnive → rapports Géographie + Langues.
Règle de décision : tout pays fournissant ≥ 5 % des sessions avec une durée ≥ 80 % de vos visiteurs domestiques justifie un test de localisation. Affichage de la devise d’abord (POWR estime jusqu’à 40 % de gain), traduction complète ensuite.
Pourquoi mensuel, pas hebdomadaire : le signal de localisation est lent à bouger. Le faire mensuellement suffit.
Lecture plus profonde : Quels pays méritent d’être localisés (article de support 7) + Données de géographie pour réduire les coûts d’expédition (article de support 10).
Étape 7 — Formuler une hypothèse d’expérience (chaque semaine)
Où : dans votre tête, avec les données des étapes 1 à 6.
Règle de décision : choisissez un seul changement. Formulez ainsi : « Si je change [X], alors [métrique] s’améliorera de [Y] grâce à [signal des étapes 1 à 6]. » Livrez. Notez la date. Réévaluez à 30 jours, pas chaque semaine.
Pourquoi un seul : lancer un changement à la fois signifie que vous pouvez attribuer le résultat. Trois changements à la fois signifie que vous ne pouvez en attribuer aucun. Les boutiques solos sous 1 000 sessions par page par mois ne devraient jamais faire de test A/B (le calcul ne supporte pas la significativité en temps raisonnable). Heuristique d’abord, un correctif par semaine, fenêtre de mesure à 30 jours.
L’assistance IA : la bibliothèque de 12 invites est faite exactement pour cette étape — collez votre export CSV de n’importe quel rapport Statnive, récupérez une liste d’hypothèses. À associer avec l’article 8 sur la méthodologie des invites IA pour les principes de prompting qui n’hallucinent pas.
La fiche d’une page (imprimable)
THE SOLO WOOCOMMERCE CRO PLAYBOOK
────────────────────────────────────────────────
WEEKLY (every Monday, 10 min):
1. Overview — channel share shift >25% WoW? → diagnose
2. Referrers — does top-3 channel fail bounces+duration rule
with ≥50 sessions? → diagnose, don't pause
3. Pages — #1 by Exit Count (not rate), excl. thank-you
4. Devices — mobile_CR ÷ desktop_CR < 0.50?
→ mobile is this week's experiment
5. Experiment — pick ONE, frame as "If X then Y because Z"
Ship. Note date. Re-eval at 30 days.
MONTHLY (one Monday per month, +20 min):
6. UTM hygiene — any inconsistent casing or duplicates?
7. Geography — countries ≥5% share + ≥80% domestic duration
8. Languages — browser-lang vs site-lang mismatch
9. 30-day re-evaluation — what worked, what to keep
QUARTERLY (one Monday per quarter, +60 min):
10. Mobile LCP audit via PageSpeed Insights (mobile, target ≤2s)
11. Baymard checkout-checklist walkthrough on your live store
12. Channel-spend reallocation based on 90-day quality data
THE 10 DECISION RULES:
- Sort exits by COUNT, not rate
- Compare bounces to INTENT cohort, not site avg
- Require ≥50 sessions before drawing conclusions
- "First to diagnose" not "first to pause"
- Mobile CR ÷ desktop CR < 0.50 = material problem
- One change per week, one re-eval at 30 days
- Cost transparency at PDP (not checkout)
- True guest checkout, password optional
- ≤8 visible checkout fields
- Skip heatmaps, session recording, GA4 import,
cookie-based cross-device trackingEnregistrez en .txt. Imprimez. Scotchez à l’écran. Fait.
Les 9 choses à ne JAMAIS faire (avec sources)
La liste à éviter du sprint, consolidée :
- N’ajoutez pas d’outil de heatmap ou d’enregistrement de session. Contredit le positionnement vie privée ; minimum de 1 000 sessions/page pour un signal significatif (selon la documentation de Hotjar lui-même) ; génère du bruit aux volumes des boutiques solos.
- N’importez pas de données GA4. Réinstalle exactement les pertes de bandeau de cookies + ad-blocker dont vous vous êtes éloigné.
- Ne suivez pas le cross-device avec des cookies. Même raison.
- Ne triez pas les sorties par taux. Triez par nombre absolu. (Voir l’étape 3 ci-dessus.)
- Ne mettez pas tous les CTA en rouge. Selon CXL, c’est le contraste, pas la couleur, qui pilote la performance des CTA.
- N’ajoutez pas de carrousel d’accueil. 84 % des clics atterrissent sur la diapositive 1 ; CTR total ~1 % (selon NN/g).
- N’ajoutez pas de compte à rebours trompeur. L’étude Growth Suite sur 847 boutiques a trouvé que cela augmente l’abandon de 23 % et réduit les achats répétés de 41 %.
- N’ajoutez pas de pop-ups uniquement mobile sur les pages à intention commerciale. Pénalité des interstitiels intrusifs de Google 2017 + coût d’abandon mobile de 23 à 31 % (Baymard).
- Ne faites pas de tests A/B sur des PDP sous 1 000 sessions/PDP/mois. Le calcul ne supporte pas la significativité en temps raisonnable (selon CXL). Heuristique d’abord, à la place.
Ce que la v1.0.0 a ajouté — et ce qui reste sur la feuille de route du tier Growth
La sortie v1.0.0 (mai 2026) a livré les quatre décompositions liées aux événements pour lesquelles ce playbook faisait du croisement vers l’admin WooCommerce. Tout gratuit, sur WordPress.org :
- Revenu par canal à l’intérieur de Statnive. La règle de santé du canal de l’étape 2 s’associe à la décomposition Canal du Rapport Revenu — Commandes, Revenu, Panier moyen par canal dans un seul onglet.
- Tunnel Panier-vers-Achat. Le nombre de sorties sur
/checkoutde l’étape 3 est désormais étayé par le tunnel en 4 étapes (Produit vu → Ajouté au panier → Checkout démarré → Achat finalisé) avec taux de conversion par étape. La sous-étape à l’intérieur de/checkout(livraison vs paiement vs revue) reste inférée. - Demande au niveau produit vs revenu. L’analyse « Échecs attractifs » de l’article 4 peut associer directement le rapport Pages et la Top Produits du Rapport Revenu — sans croisement CSV pour la vue produit parent.
- Invites IA qui raisonnent sur le revenu. La bibliothèque d’invites de l’article 8 incorpore déjà les données du Rapport Revenu (revenu par canal, décrochage de tunnel, RPV).
Toujours sur la feuille de route du tier Growth (prévu 2026, payant) :
- Alertes d’anomalies sur le revenu + écarts de trafic
- Alertes Slack / Telegram sur le revenu
- Import CSV des dépenses publicitaires + MER (Marketing Efficiency Ratio)
- Résumé exécutif hebdomadaire par IA (exécute la bibliothèque d’invites automatiquement et envoie par e-mail le rapport consolidé)
- Meta CAPI côté serveur
- Comparaison côte à côte mobile-vs-bureau
- Linter d’hygiène UTM (signale automatiquement les incohérences de casse)
- Dimension revenu par pays sur le Rapport Revenu
La liste d’attente du tier Growth
Si vous voulez être averti quand ces couches opérationnelles arrivent, la liste d’attente est ci-dessous. Le plugin gratuit reste gratuit, y compris le Rapport Revenu v1.0.0 et tout ce qui est dans ce playbook. Growth est pour les boutiques qui veulent les alertes + l’automatisation par-dessus.
Les 12 articles du sprint, liés à la boucle
Que faire ensuite
- Mettez cette page en favori.
- Imprimez la fiche.
- Ouvrez Statnive lundi prochain matin. Exécutez la revue hebdomadaire en 10 minutes (étape 1, 2, 3, éventuellement 4, puis 7).
- Choisissez une expérience. Livrez-la. Notez la date.
- Revenez dans 30 jours. Réévaluez. Exécutez la revue de la semaine suivante.
- Rejoignez la liste d’attente Pro ci-dessus si vous voulez savoir quand le revenu-par-canal + les événements de tunnel par étape arrivent.
Vous avez maintenant le système d’exploitation que la plupart des boutiques WooCommerce solo ne construisent jamais. La composition commence le premier lundi où vous l’exécutez vraiment.