ソロ WooCommerce CRO プレイブック（無料テンプレート）

3 週間前、このブログには WooCommerce CRO の記事がゼロでした。

今日、完全なオペレーティングシステムがあります。12 本の記事。40 時間の裏付け研究。ソロ WooCommerce ストアが 10 分で実行できる 7 ステップの週次ループ。5 つのエビデンスベースのモバイルボトルネック。誰も論破しない 4 つの出口ページアンチパターン。Klaviyo 対 Woo の $86K/$24K 売上整合。SERP が間違える 3 つの注釈付きのチャネル健全性ルール。

投稿 1 から読んでいるなら、すでにこの大半を吸収しています。最初にここに着地したなら、これがすべてを結びつける投稿です — スプリント全体の印刷可能、共有可能、VA に渡せる凝縮版。

v1.0.0（2026 年 5 月）時点で、WooCommerce Revenue Report は WordPress.org で無料で出荷されます — 注文、純売上、平均注文金額、返金合計 + 率、8 チャネル（14 ホストを網羅する AI Assistants 専用チャネル含む）横断の Revenue by Channel、トッププロダクト、4 ステージのカート→購入ファネル。過去注文は Revenue Report の初回オープン時に自動でバックフィルされます。下の 7 ステップループは、クロスリファレンスがあった場所で Revenue Report を使うよう更新されました。下の Growth/有料プラン待機リストは、その上に乗る運用層（異常検知アラート、Slack/Telegram 売上アラート、広告費 MER、AI エグゼクティブサマリー）用です。

このプレイブックが提供するもの

• すべてのステップがより深いピラー投稿にマッピングされた、完全な 7 ステップ週次 CRO ループ。
• スプリントのすべての意思決定ルールを 1 ページに印刷可能なチートシート。
• v1.0.0 の Revenue Report がカバーするものと、まだ Growth プランロードマップにあるものの正直なリスト。
• 拒否リスト — それぞれを論破する研究付きで、すべきでない 9 つのこと。
• 運用層用の Growth プラン待機リスト（異常検知アラート、Slack/Telegram 売上アラート、広告費 MER、AI エグゼクティブサマリー）。

完全展開の 7 ステップ週次 CRO ループ

毎週月曜の朝、/wp-admin → Statnive を開きます。順番に実行。下のバージョンは各ステップにより深い「なぜ」を追加；10 分版 は印刷可能なショート版です。

ステップ 1 — 状況を読む（Overview）

場所： Statnive → Overview レポート。直近 7 日対前 7 日。

意思決定ルール： チャネルシェアの変動が週次で 25% を超えたら = ステップ 2 へフラグ。ほとんどの週は何も変わらない；それ自体がシグナル。

なぜ重要： チャネルが静かに壊れた瞬間（Google がページをデインデックスした、有料広告が拒否された、メールがスパムに落ちた）、最初のシグナルは Overview の週次差分にある — 下流の売上影響が WooCommerce 管理画面に現れる完全 1 週間前であることが多い。Overview で捕まえることが、出血の 1 週間を節約します。

より深い読み物： WooCommerce CRO のためのプライバシー重視のアクセス解析（ピラー投稿 1）。

ステップ 2 — チャネル品質を監査する（Referrers）

場所： Statnive → Referrers レポート。セッション降順で並び替え。

意思決定ルール（チャネル健全性ルール）： チャネルが健全なのは、直帰 ≤ サイト平均 AND 滞在時間 ≥ サイト平均、7 日ウィンドウで 50 セッション以上のとき。両方を失敗するチャネルは診断対象 — 停止ではない。

誰も言及しない 3 つの注釈：（1）サイト全体ではなく意図一致コホートと比較；（2）結論を出す前に 50 セッション以上を要求；（3）失敗を「停止が最初」ではなく「診断が最初」と枠付け。

なぜ重要： Statnive は 8 つの自動グループ化チャネルを出荷します（Direct、AI Assistants、Organic Search、Social、Email、Referral、Paid Search、Paid Social） — GA4 がまだ Direct や Organic にルーティングする AI Assistants を含む。月商 5 万ドル未満のソロ Woo ストアにとって、チャネルグルーピングの帰属はマルチタッチモデリングより信頼できます。

より深い読み物： GA4 なしの最良の WooCommerce トラフィックソースを探す（サポート投稿 2）。

ステップ 3 — 優先漏れを見つける（Pages — Exit Count）

場所： Statnive → Pages レポート。Exit Count 降順 で並び替え（離脱率ではない）。

意思決定ルール： Exit Count トップのページが優先 — 他のページの出口率が「より悪く」ても。10,000 ビューで離脱率 45% のページは 4,500 セッションを失う；500 ビューで 90% のページは 450 を失う。1 つ目を直す。

なぜ重要： 他のすべての CRO ブログは率で並び替えます。それが罠です。カウントで並び替え = トラフィックで重み付けされた優先キュー。算術は容赦ありません — Statnive の Pages レポートは Exit Count をカラムとして表示するため、ランキングは自動です。

ファネル位置のタイブレーカー（CXL PIE/ICE による）： 2 つのページの Exit Count が似ているとき、ファネル下部のページを重く評価。ブログ出口 1.0 に対して、PDP × 1.2、カート × 1.5、チェックアウト × 1.5。

より深い読み物： WooCommerce 売上のためのエントリーページと出口ページ（ピラー投稿 3） + WooCommerce 商品ページを分析する（サポート投稿 4）。

ステップ 4 — モバイル対デスクトップを診断する（Devices）

場所： Statnive → Devices レポート。WooCommerce Analytics → Orders とクロスリファレンス。

意思決定ルール： mobile_CR ÷ desktop_CR を計算。ベースライン 0.60〜0.74。モバイルシェア 60% 超で 0.50 未満 = 重大な問題。

4 つのモバイル問題検出パターン：

1. チェックアウトに到達しないトラフィック = ファネル上部のモバイル UX 問題。
2. チェックアウトに到達するが失敗するトラフィック = ファネル下部のチェックアウト問題。
3. 商品ページのモバイル直帰 = PDP 固有 UX。
4. そもそも間違ったオーディエンス = モバイル UX ではなく上流のターゲティング問題。

なぜ重要： モバイルは 2026 年の WooCommerce トラフィックの 70〜78%。モバイルでの 1 ポイント引き上げは、デスクトップで同じ引き上げの 2 倍の価値。優先順位の 5 つのエビデンスベースのボトルネック：LCP 2.5 秒超、375px ファーストビュー CTA、画像ギャラリーの摩擦、チェックアウトフォーム / パスワード / captcha、決済プロバイダのミスマッチ。

より深い読み物： WooCommerce のモバイルコンバージョン問題（ピラー投稿 5）。

ステップ 5 — UTM 衛生 + 有料広告の無駄を発見する（Referrers UTM）

場所： Statnive → Referrers レポート → UTM ディメンション（Source、Medium、Campaign）。

意思決定ルール： Direct シェアが 25% を超えたら、ほぼ確実に UTM タグのギャップがあります。有料キャンペーンがトラフィックは高いが直帰 + 滞在時間のチャネル健全性ルールに失敗したら、停止前に診断。

3 つの最も一般的な UTM 衛生失敗：

1. 混在ケーシング — utm_source=Facebook と utm_source=facebook は、どのアクセス解析ツールでも 2 チャネルになる。
2. 内部リンクの UTM 汚染 — 自分のページ間のリンクに UTM を付けると元のリファラーを上書き。
3. ダークソーシャル漏洩 — Slack、WhatsApp、メールクライアントのリンククリックは、メッセージングアプリがリファラーを剥がすため Direct に着地。修正は公開するすべての共有可能リンクで一貫した UTM タグ付け。

より深い読み物： UTM で広告費の無駄を止める（WooCommerce）（サポート投稿 6）。

ステップ 6 — ローカライゼーションのための地理 + 言語（毎週ではなく毎月）

場所： Statnive → Geography + Languages レポート。

意思決定ルール： セッションの 5% 以上を供給し、滞在時間が国内訪問者の 80% 以上ある国はローカライゼーションテストに値する。通貨表示が先（POWR は最大 40% の引き上げを見積もる）、完全翻訳が後。

なぜ毎週ではなく毎月： ローカライゼーションシグナルは動きが遅い。毎月実行で十分。

より深い読み物： どの国がローカライゼーションに値するか（サポート投稿 7） + 送料を削減するための地理データ（サポート投稿 10）。

ステップ 7 — 1 つの実験仮説を立てる（毎週）

場所： ステップ 1〜6 のデータを手元に、頭の中で。

意思決定ルール： 1 つ の変更を選ぶ。次の形で枠付け：「もし [X] を変えれば、[ステップ 1〜6 のシグナル] により [メトリクス] が [Y] 改善する。」 出荷。日付を記録。週次ではなく 30 日で再評価。

なぜ 1 つ： 一度に 1 つの変更を実行することで、結果を帰属できます。一度に 3 つの変更は、どれも帰属できません。月間 PDP あたり 1,000 セッション未満のソロストアは A/B テストを決して行うべきではありません（算術が妥当な時間内の有意性をサポートしない）。ヒューリスティック優先、週 1 修正、30 日計測ウィンドウ。

AI アシスト： 12 プロンプトライブラリ はこのステップ専用に作られています — 任意の Statnive レポートからの CSV エクスポートを貼り付け、仮説リストを得る。幻覚しないプロンプティング原則は AI プロンプト方法論の投稿 8 と組み合わせて。

1 ページのチートシート（印刷可能）

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 tracking

.txt として保存。印刷。モニターに貼る。完了。

決してすべきでない 9 つ（出典付き）

スプリントからの拒否リスト、統合版：

1. ヒートマップやセッションリプレイツールを追加しないこと。 プライバシーポジショニングと矛盾；意味あるシグナルにはページあたり 1,000 セッション最低（Hotjar 自身のドキュメントによる）；ソロストアの量ではノイズを生む。
2. GA4 データをインポートしないこと。 まさに切り替えた理由の Cookie バナー + 広告ブロッカー損失を再導入する。
3. Cookie でクロスデバイス計測しないこと。 同じ理由。
4. 出口を率で並び替えないこと。 絶対カウントで並び替え。（上のステップ 3 参照。）
5. すべての CTA を赤くしないこと。 CXL によれば、色ではなくコントラストが CTA パフォーマンスを駆動。
6. ホームページカルーセルを追加しないこと。 クリックの 84% がスライド 1 に着地；合計 CTR 約 1%（NN/g による）。
7. 欺瞞的なカウントダウンタイマーを追加しないこと。 Growth Suite の 847 ストア研究によれば、これは放棄を 23% 増加 させ、リピート購入を 41% 減少。
8. コマース意図ページにモバイル専用ポップアップを追加しないこと。 Google の 2017 年侵入型インタースティシャルペナルティ + 23〜31% のモバイル放棄コスト（Baymard）。
9. 月間 PDP セッション 1,000 未満で PDP の A/B テストを実行しないこと。 算術が妥当な時間内の有意性をサポートしない（CXL による）。代わりにヒューリスティック優先。

v1.0.0 が追加したもの — そしてまだ Growth プランロードマップにあるもの

v1.0.0 リリース（2026 年 5 月）は、本プレイブックが WooCommerce 管理画面とクロスリファレンスしていた 4 つのイベント対応内訳を出荷しました。すべて無料、WordPress.org で：

1. Statnive 内のチャネル別売上。 ステップ 2 のチャネル健全性ルールは Revenue Report のチャネル内訳と組み合わせ — 1 タブで注文、売上、チャネル別 AOV。
2. カート→購入ファネル。 ステップ 3 の /checkout 出口数は、ステップ別コンバージョン率を持つ 4 ステージファネル（商品閲覧 → カートに追加 → チェックアウト開始 → 購入完了）で裏付けされます。/checkout 内のサブステップ（配送 vs 決済 vs 確認）はまだ推論。
3. 商品レベルの需要対売上。 投稿 4 の「魅力的な失敗」分析は、Pages レポートを Revenue Report のトッププロダクトと直接組み合わせられます — 親商品ビューでは CSV クロスリファレンス不要。
4. 売上について推論する AI プロンプト。 投稿 8 のプロンプトライブラリはすでに Revenue Report データ（チャネル売上、ファネル離脱、RPV）を取り込んでいます。

まだ Growth プランロードマップ（2026 年予定、有料）：

• 売上 + トラフィック差分の異常検知アラート
• Slack / Telegram 売上アラート
• 広告費 CSV インポート + MER（Marketing Efficiency Ratio）
• 週次 AI エグゼクティブサマリー（プロンプトライブラリを自動実行し、統合レポートをメール）
• Meta CAPI サーバーサイド
• モバイル対デスクトップの並列比較オーバーレイ
• UTM 衛生リンター（ケーシング不一致を自動フラグ）
• Revenue Report の国別売上ディメンション

Growth プラン待機リスト

それらの運用層が出荷されるときに知らせてほしいなら、待機リストは下にあります。無料プラグインは無料のままで、v1.0.0 Revenue Report と本プレイブックのすべてを含みます。Growth は、その上にアラート + 自動化を求めるストア向けです。

スプリントの 12 投稿、ループへのマッピング

ステップ	投稿	タイプ
1、2、3（基盤）	投稿 1 — WC CRO のためのプライバシー重視のアクセス解析	ピラー
2（チャネル品質）	投稿 2 — GA4 なしで最良の WC トラフィックソースを探す	サポート
3（優先漏れ）	投稿 3 — WC 売上のためのエントリー & 出口ページ	ピラー
3（商品ページ分析）	投稿 4 — 複雑なダッシュボードなしで WC 商品ページを分析する	サポート
4（モバイル診断）	投稿 5 — WC のモバイルコンバージョン問題	ピラー
5（UTM + 無駄）	投稿 6 — UTM で広告費の無駄を止める（WC）	サポート
6（ローカライゼーション）	投稿 7 — どの国がローカライゼーションに値するか	サポート
7（AI アシスト）	投稿 8 — WC アクセス解析 & CRO のための AI プロンプト	ピラー
アドホック（ローンチ）	投稿 9 — WC ローンチ中のリアルタイムアクセス解析	サポート
6（配送）	投稿 10 — WC 送料を削減するための地理データ	サポート
すべてのステップ（運用形式）	投稿 11 — 10 分週次 WC アクセス解析レビュー	サポート
すべてのステップ（本投稿）	ソロ WC CRO プレイブック（ここにいます）	ピラー

次にすべきこと

1. このページをブックマーク。
2. チートシートを印刷。
3. 次の月曜の朝、Statnive を開く。10 分週次レビュー（ステップ 1、2、3、オプションで 4、そして 7）を実行。
4. 1 つの実験を選ぶ。出荷。日付を記録。
5. 30 日後に戻る。再評価。次週のレビューを実行。
6. 売上チャネル別 + ファネルステップイベントが出荷されたら知りたいなら、上の Pro 待機リストに参加。

ほとんどのソロ WooCommerce ストアが決して構築しないオペレーティングシステムが手に入りました。複利は実際に実行する最初の月曜から始まります。