WooCommerce · Parhum Khoshbakht

WooCommerce のモバイルコンバージョン問題を見つける方法

モバイルは WooCommerce トラフィックの 70〜78% を占め、コンバージョン率はデスクトップの約 60% です。Statnive のデバイスレポートとページレポートだけで、4 つのモバイル問題のどれが自分のストアの課題かを診断できます。GA4 不要、ヒートマップ不要、Lighthouse ダッシュボード不要。

Statnive デバイスレポート — Device Distribution ドーナツチャート（Desktop が優勢、Mobile、Tablet、その他）と Bot vs Human ドーナツチャート

ソロ WooCommerce オーナーがアクセス解析ダッシュボードで誰でも確認できる 2 つの事実：

  • モバイルはトラフィックの 70〜78%。
  • モバイルのコンバージョン率はデスクトップの約 60%。

算術：月間 10,000 のモバイル訪問が 1.8% でコンバージョンし、月間 3,000 のデスクトップ訪問が 3.0% でコンバージョンするなら、モバイルは 180 件、デスクトップは 90 件の注文を生み出します。モバイルはすでに大きい売上エンジン — ただし、モバイルでの 1 ポイントの引き上げは、デスクトップで同じ引き上げの 2 倍の価値があります。

その算術が、モバイル CRO がソロ Woo ストアにとって最高にレバレッジの効く単一投資である理由です。問題は、SERP のほぼすべての「WooCommerce モバイル最適化」記事が 25 項目の戦術リスティクルだということです。それは どの モバイル問題が自分のものか分からないときには役立ちません。

この記事は診断であり、リスティクルではありません。検出方法でランク付けされた 4 つのモバイル問題、5 分で回せる 2 ペインワークフロー、優先順位付けされた 5 つのエビデンスベースのモバイルボトルネック。

この記事で答える内容

  • 診断の出発点としてのモバイル CR 対デスクトップ CR の比率。
  • 4 つのモバイル問題、それぞれ独自の検出ルール（GA4 不要）。
  • Statnive のデバイスレポート + ページレポートだけで行う 5 分の 2 ペインモバイル監査。
  • 優先順位付けされた 5 つのエビデンスベースのモバイルコンバージョンボトルネック。
  • SERP がいまだに推奨する 4 つのモバイルアンチパターン — それらを論破する研究。

比率から始める：モバイル CR ÷ デスクトップ CR

WooCommerce Reports → Orders を開きます。日付範囲で絞り込みます（ソロストアでは直近 30 日が妥当）。注文をソースデバイス別に並べ替えます — ほとんどの WooCommerce テーマは注文メタデータにこれを記録しますし、自分のストアが記録しない場合は WC 8.5+ の Order Attribution 機能が記録します。

計算：

mobile_orders ÷ mobile_visitors = mobile_CR
desktop_orders ÷ desktop_visitors = desktop_CR
mobile_CR ÷ desktop_CR = your ratio

訪問者はどこから来るのか？Statnive → デバイスレポートを開きます。Device Type の内訳が mobile_visitors と desktop_visitors を与えます。

ベースライン数値（Dynamic Yield のベンチマークデータ、Oberlo 経由、2024 年 10 月）：

  • デスクトップ ecommerce コンバージョン：3.85%
  • タブレット：3.49%
  • モバイル：2.85%
  • モバイル ÷ デスクトップ ≈ 0.74

一部のソースはアパレル、家電、ジュエリーで 0.50〜0.55 まで低い比率を報告しています。正しい基準は普遍的なベンチマークではなく、自分のストアの比率を自分の過去と比較したものです。比率を毎月追跡してください。それが最重要のモバイル健全性 KPI です。

4 つのモバイル問題、それぞれ独自の検出方法

これが診断フレームワークです。ほとんどの「モバイル CRO」記事は修正に直行しますが、本当の勝ちはどの問題を持っているかを知ることです。

問題 1 — チェックアウトに決して到達しないトラフィック

検出： Statnive のデバイスレポートで、モバイルセッションがデスクトップセッション数の 15 ポイント以内に収まっているのに、WooCommerce Analytics → Orders ではモバイル注文がトラフィックシェアから期待される量の 30% を下回っている。

何が起きているか： モバイル訪問者が着地し、おそらく 1 ページだけ見て直帰している — /cart や /checkout に決して到達しない。ファネルの上部で漏れています。

次に見る場所： Statnive → Pages → エントリーページを Entry Count で並べ替え。モバイル比率の高いエントリーページを特定（デバイスレポートとクロスリファレンス）。それらのエントリーで出口数が高ければ、ファネル上部のモバイル問題 — 通常は遅いページ、モバイル非最適化のヒーロー、または 375px ビューポートで見えないファーストビュー CTA です。

問題 2 — カート / チェックアウトに到達するが失敗するトラフィック

検出： モバイル訪問者は /checkout に到達している（ページレポートで確認可能）が、モバイル注文はそれでも比例して低い。ファネルの下部で漏れています。

何が起きているか： 訪問者は商品をカートに入れ、ひょっとしてチェックアウトを開始さえし、フォーム途中で離脱した。これは古典的な Baymard パターンです：追加の送料が遅すぎて明らかにされた（米国の放棄者の 39%）、強制アカウント作成（19%）、チェックアウトフォームが長すぎる（18%）、決済プロバイダのミスマッチ。

次に見る場所： 375px ビューポートのモバイルブラウザでストアの /checkout を開きます。歩いて通り抜けます。フィールドを数えます。フォームを時間計測します。Baymard のモバイルチェックアウトチェックリストと比較します。

問題 3 — 商品ページのモバイル直帰

検出： Statnive のページレポートで、トップ PDP エントリーページに高い出口数。デバイスレポートでモバイルが優勢。現状の UI ではページに対する簡単な「デバイス絞り込み」がない（以下に回避策）ため、これは 2 ペインの推論です。

何が起きているか： モバイル訪問者が商品ページに着地し、スクロールせずに購入ボタンを見つけられない、または画像ギャラリーのジャンクに当たる、またはページのロードを長く待たされる。

次に見る場所： 実機のモバイル端末（デスクトップブラウザを 375px に絞ったものではない — 実機はキーボード、タッチ、Safari ITP のクセを持ち、デスクトップエミュレーションでは隠れる）でトップ PDP を開きます。Google PageSpeed Insights で LCP を計測。「カートに追加」ボタンがスクロールなしでファーストビュー内に見えるか確認。画像ギャラリーがジャンクなくスワイプできるかチェック。

問題 4 — そもそも間違ったオーディエンス

検出： モバイルトラフィックシェアは高いが、トラフィックソースは特定の 1 チャネル（多くは Meta の有料ソーシャル）に集中し、直帰率がすべてのモバイルエントリーページで普遍的に 75% を超えている。

何が起きているか： 広告があなたの売るものを欲しがらない人にターゲットしている、または広告クリエイティブがランディングページと合っていない。ストアのモバイル UX は問題なく、上流のターゲティングが壊れています。

次に見る場所： Statnive → Referrers → 疑わしいキャンペーンの UTM source/medium にフィルター。直帰 + 滞在時間をサイト平均と比較。キャンペーンがチャネル健全性ルールに失敗していれば（直帰が平均超、滞在時間が平均以下）、問題はモバイル UX ではなくキャンペーンです。完全な診断はトラフィックソースプレイブックを参照。

5 分の 2 ペインモバイル監査

これがワークフローです。GA4 なし。Lighthouse ダッシュボードなし。ヒートマップツールなし。ブラウザタブ 2 枚と WooCommerce 管理画面。

タブ 1 — Statnive デバイスレポート：

  • 全セッションに占めるモバイルシェアは？（ほとんどの消費者向け Woo ストアで 60〜80% であるはず。）
  • モバイル直帰率対デスクトップ直帰率は？（ポイント差分を計算。）
  • モバイルで優勢なブラウザは（モバイル Safari 対 Android Chrome）？

Statnive デバイスレポート — Browsers テーブル（Chrome、Firefox、Edge、Headless Chrome、Chrome Mobile、Safari）と Operating Systems テーブル（Windows、Mac、GNU/Linux、Android、iOS）

タブ 2 — Statnive ページレポート：

Statnive ページレポート — ページごとの訪問者、ビュー、平均滞在時間を示す Top Content テーブル

  • Entry Count 降順で並び替え。これがモバイルランディングページでもあります（モバイルがトラフィックの大半）。
  • Exit Count 降順で並び替え。トップ 5 に /product/、/cart/、/checkout ページがあれば記録。

タブ 3 — WooCommerce Analytics → Orders：

  • 直近 30 日にフィルター。モバイル帰属注文数を記録。
  • 計算：mobile_orders ÷ (タブ 1 からの mobile_sessions) = モバイル CR。
  • デスクトップでも同じ。
  • 比率を計算。ベースライン 0.60〜0.75 と比較。

意思決定ルール：

比率解釈アクション
0.70+正常範囲内維持 — 緊急のモバイル修正なし
0.50〜0.69わずかな不調問題 3（PDP モバイル直帰）から始める
0.30〜0.49重大な問題4 つの問題検出を全部走らせる。通常は問題 2 か 4
< 0.30壊滅的問題 4（間違ったオーディエンス）と問題 1 が複合している可能性が高い

5 分、サードパーティツールなし、根拠ある答え。

正直な注釈： ページレポートは現状の Statnive UI ではデバイスタイプで絞り込めません — クロスリファレンスは自動化されていない手動作業です。デバイス絞り込みエンドポイントはロードマップにあります。それまでは 2 ペインワークフローが代替です。

優先順位付けされた 5 つのエビデンスベースのモバイルボトルネック

どの問題かを特定したら、修正の優先キューがこれです。それぞれ特定の研究に紐付き、ノリではありません。

ボトルネック 1 — モバイル LCP（Largest Contentful Paint）が 2.5 秒超

エビデンス： Deloitte/55/Google の Milliseconds Make Millions 研究（2019 年後半、Core Web Vitals 前）：0.1 秒のモバイル速度改善で 37 ブランドサイトの 3,000 万セッション横断で 8.4% の小売コンバージョン向上と 9.2% の AOV 向上が得られました。研究は正式な Core Web Vitals シグナルに先行しますが、効果は今も広く引用されます。

計測方法： Google PageSpeed Insights。トップのモバイルエントリーページを入力。モバイル（デスクトップではない）LCP を記録。目標 2.5 秒以下；2026 年の LCP しきい値更新では「良好」が 2.0 秒以下に設定されています。

修正方法： 画像最適化（WebP/AVIF）、ファーストビュー以下を遅延ロード、サーバーキャッシュプラグイン（WP Rocket、Cache Enabler）、ランディングページの JavaScript を削減。

ボトルネック 2 — 375px でファーストビュー CTA が見えない

エビデンス： Baymard のモバイル PDP 研究 — プライマリ CTA は 375px ビューポート（iPhone SE / iPhone Mini 幅）でスクロールなしに届かなければなりません。Nielsen Norman Group のアテンション研究によれば、モダンなレスポンシブサイトで閲覧時間の 57% がファーストビューにあります。

計測方法： Chrome DevTools の 375×667 でトップ PDP を開きます。スクロールせずに購入ボタンが見えるか？No = 問題。

修正方法： ヒーロー画像の高さを減らす、タイトルと価格ブロックを上に移動、CTA を親指ゾーン（右利きの右下）に置く。

ボトルネック 3 — 商品画像ギャラリーの摩擦

エビデンス： Baymard の相関：商品画像をすべてスムーズに閲覧できる能力は、カート追加率と約 0.6 で相関します。最も一般的な失敗モード：ズームが効かない、スワイプが遅延、ギャラリーが他の画像があることを示さずに 1 枚しか表示しない。

計測方法： 実機（デスクトップエミュレーションではない）で PDP を開きます。すべての画像をスワイプ。ズームを試す。何かがカクついたり動かなければ、直します。

修正方法： 実証されたモバイルギャラリーを持つテーマ / プラグイン（Astra、Botiga、Storefront 4.x、Kadence）に変更。iOS Safari で特にテスト。

ボトルネック 4 — チェックアウトフォームが長すぎ、パスワード要件、captcha

エビデンス： Baymard のチェックアウトフロー研究：大規模サイトの中央値は 14.88 フィールド、最小に削ればモバイル特有のコンテキストで 25〜35% のコンバージョン向上を生みます。米国の放棄者の 24% が強制アカウント作成を挙げ、19% がパスワード要件を明示的に挙げています。

計測方法： モバイルで /checkout の可視必須フィールドを数えます。8 を超えていれば最適を超えています。アカウント作成が必須かチェック。

修正方法： WooCommerce → Settings → Accounts & Privacy → 「アカウントなしで注文を許可」を有効化。WooCommerce → Settings → Advanced → Account & Privacy で任意フィールド（会社名、住所 2 行目、注文メモ、しばしば電話番号）を無効化。各入力に正しい inputmode を設定し、モバイルキーボードが最適化されるようにする（郵便番号は numeric、メールは email）。

ボトルネック 5 — 決済プロバイダのミスマッチ

エビデンス： Stripe の Apple Pay 採用研究は、Apple Pay が利用可能なときに 8〜15% のモバイルコンバージョン向上を示唆します（カテゴリと地域で変動）。Stripe と PayPal のデータによれば、モバイルショッパーは手入力カードよりワンタップ決済を好みます。

計測方法： iPhone で /checkout を開きます。Apple Pay ボタンが見えるか？Android なら Google Pay は？「クレジットカード」しか表示されなければ、決済摩擦の問題があります。

修正方法： WooPayments、Stripe、または Square 経由で Apple Pay + Google Pay を有効化。プラグインのインストールは 5 分、Apple Pay の有効化はドメイン検証ステップが加わってさらに 15 分。

スキップすべき 4 つのモバイルアンチパターン

これらはすべての「モバイル WooCommerce 最適化」記事に登場します。研究がそれらを論破します。

  1. 「サイトをレスポンシブにする — それがモバイル最適化。」 Nielsen Norman Group によれば、レスポンシブデザインは出発点であり、戦略ではありません。レスポンシブはサイトがモバイルでロードされることを保証しますが、親指入力、遅いネットワーク、小さいビューポート優先順位のために体験を最適化はしません。
  2. 「メール獲得のためにモバイル専用ポップアップを追加。」 Google の 侵入型インタースティシャルポリシー（2017 年）により、フルスクリーンのモバイルインタースティシャルはランキングペナルティをトリガーすることがあります。Baymard のモバイル UX 研究では、モバイルポップアップはデスクトップ等価物に対して 23〜31% の放棄コストを持ちます。代わりに非コマース意図ページでインラインフォームを使い、PDP、カート、チェックアウトではポップアップしないこと。
  3. 「ハンバーガーメニューを至るところに。」 NN/g のハンバーガーメニュー研究によれば、隠されたメニューは発見性を約 50% 低下させます。モバイル必須のプライマリナビゲーション（カテゴリ、カート、検索）はハンバーガーの後ろに隠さず、可視であるべきです。ハンバーガーはセカンダリナビにのみ許容されます。
  4. 「モバイルファーストとはファーストビューに収めるためのより小さいフォントのこと。」 WCAG 1.4.4により、テキストは 200% にリサイズ可能でなければなりません。Apple HIG は最低 17pt の本文を、Material Design は 16sp を指定します。小さいフォントはアクセシビリティに反し、軽度視覚障害のある 40 歳以上のモバイルショッパー（50% 超）のコンバージョンを低下させます。

WooCommerce 固有のモバイルゴッチャ

モバイルデータの読み方を変える 3 つのテーマ + プラグインの事実。

  1. モバイルではブロックベースのチェックアウト > ショートコードチェックアウト、UX とアクセス解析の清潔さの両面で。ブロックベースのチェックアウトは可視フィールドが短く、キーボードハンドリングがより良いモバイルファースト再設計です。2026 年にまだショートコードチェックアウトを使っているなら、移行は実行できる最高にレバレッジの効くモバイル修正です。
  2. WooCommerce 用 AMP は Statnive に不可視です。 AMP ページは Google のキャッシュから配信され、制限された JavaScript ランタイムで動きます。Statnive の計測スクリプトは AMP ページで発火しないため、AMP トラフィックはアクセス解析でゼロに見えます。修正は AMP 連携を追加することではなく（AMP は事実上廃止）、AMP を無効化して代わりに Core Web Vitals 最適化に頼ることです。
  3. Apple Pay / Google Pay の可用性はゲートウェイで異なります。 WooPayments（Automattic）：両方、ネイティブ。Stripe：両方、Apple Pay 用に 1 回のドメイン検証。PayPal Payments：Apple Pay は PayPal のフロー経由、Apple ネイティブではない。Square：地域限定、US/CA/UK/AU のみ。顧客に「チェックアウトで Apple Pay」を約束する前にゲートウェイのドキュメントを確認してください。

v1.0.0 の Revenue Report が追加するもの — そしてまだカバーしないもの

v1.0.0 時点で、Revenue Report の カート→購入ファネル は見出しのチェックアウト離脱をカバーします — 商品閲覧 → カートに追加 → チェックアウト開始 → 購入完了、WooCommerce からサーバー側で。ステージレベルでモバイルボトルネックを即座に確認できます。

依然として残る 2 つのより細かい制限、正直に枠付け：

  1. /checkout 内のサブステップごと。 Statnive のファネルは「チェックアウト開始」/「購入完了」で止まります。モバイル訪問者が配送選択、決済選択、注文確認のどこで離脱したかは具体的に表出しません — checkout_step イベントは将来の追加です。
  2. 画像インタラクションごとの分析。 モバイル訪問者は 1 枚をスワイプしたか、5 枚すべてか？自分の PDP を実機で歩いて通り抜けてください。インタラクションごとのイベント計測は v1.0.0 にはありません。

見出しのモバイル対デスクトップ診断には、4 問題のフレームワーク + 2 ペイン監査 + 5 ボトルネックの優先キューが依然として優先順位付けを駆動します。Revenue Report はその上に売上インパクトのランキングを加えます：Top Products 項目のモバイル修正は、ロングテール PDP の同じ修正よりも価値があります。

次にすべきこと

  1. Statnive デバイスレポートを開く。モバイルシェア + モバイル直帰を計算。
  2. WC Analytics → Orders を開く。モバイル CR ÷ デスクトップ CR の比率を計算。
  3. 上の意思決定テーブルで 4 つの問題のどれが自分のものかを特定。
  4. その問題に対するエビデンス最高のボトルネック修正を適用。
  5. 30 日待つ。前後の絶対注文数を計測。20% 以上の向上があれば維持。

より広い週次 CRO ループは WooCommerce CRO のためのプライバシー重視のアクセス解析のピラー記事を参照。出口ページの絶対損失計算はエントリーページと出口ページを参照。モバイルトラフィックを供給するチャネル品質の意思決定は GA4 なしの WooCommerce トラフィックソースを参照。

Statnive を無料で入手