چطور مشکلات نرخ تبدیل موبایل را در WooCommerce پیدا کنیم

دو واقعیت که هر صاحب فروشگاه WooCommerce تک‌نفره می‌تواند در داشبورد آنالیتیکس خود ببیند:

• موبایل 70 تا 78 درصد ترافیک شماست.
• نرخ تبدیل موبایل حدود 60 درصد نرخ دسکتاپ است.

حساب‌وکتابش ساده است: فرض کنید ماهانه 10,000 بازدید موبایل با نرخ تبدیل 1.8 درصد و 3,000 بازدید دسکتاپ با نرخ تبدیل 3.0 درصد دارید؛ در این صورت موبایل 180 سفارش و دسکتاپ 90 سفارش می‌سازد. موبایل همین حالا موتور درآمدزای بزرگ‌تر شماست؛ اما یک واحد درصد رشد روی موبایل، دو برابر همان رشد روی دسکتاپ می‌ارزد.

همین حساب نشان می‌دهد که چرا بهینه‌سازی نرخ تبدیل (CRO) موبایل، پراثرترین سرمایه‌گذاری برای یک فروشگاه Woo تک‌نفره است. مشکل این است که تقریباً هر نوشته‌ای درباره «بهینه‌سازی موبایل WooCommerce» در نتایج جستجو، فهرستی 25‌بندی از ترفندهاست. اما وقتی نمی‌دانید کدام مشکل موبایل، مشکل شماست، چنین فهرستی به دردتان نمی‌خورد.

این نوشته یک راهنمای تشخیصی است، نه فهرست ترفند. چهار مشکل موبایل که بر اساس روش تشخیص دسته‌بندی شده‌اند، یک جریان کاری دو‌پنجره‌ای که در 5 دقیقه اجرا می‌شود و پنج گلوگاه موبایلِ متکی بر شواهد، به ترتیب اولویت.

این نوشته به چه پرسش‌هایی پاسخ می‌دهد

• نسبت نرخ تبدیل موبایل به نرخ تبدیل دسکتاپ، به‌عنوان نقطه شروع تشخیص.
• چهار مشکل موبایل، هر کدام با قاعده تشخیص مخصوص خودش (بدون نیاز به GA4).
• ممیزی 5‌دقیقه‌ای موبایل با روش دو‌پنجره‌ای، فقط با گزارش دستگاه‌ها و گزارش صفحه‌های Statnive.
• پنج گلوگاه نرخ تبدیل موبایلِ متکی بر شواهد، به ترتیب اولویت.
• چهار الگوی نادرستی که نتایج جستجو هنوز هم توصیه‌شان می‌کند — و پژوهشی که آن‌ها را رد می‌کند.

از نسبت شروع کنید: نرخ تبدیل موبایل ÷ نرخ تبدیل دسکتاپ

به مسیر WooCommerce ← گزارش‌ها ← سفارش‌ها بروید. بر اساس بازه زمانی فیلتر کنید (برای یک فروشگاه تک‌نفره، 30 روز اخیر منطقی است). سفارش‌ها را بر اساس دستگاه مبدأشان مرتب کنید؛ بیشتر قالب‌های WooCommerce این داده را در فراداده سفارش ثبت می‌کنند و اگر فروشگاه شما این کار را نمی‌کند، قابلیت «انتساب سفارش» (Order Attribution) در WC 8.5 و بالاتر آن را انجام می‌دهد.

محاسبه کنید:

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

بازدیدکننده‌های شما از کجا می‌آیند؟ به مسیر Statnive ← گزارش دستگاه‌ها بروید. تفکیک نوع دستگاه، تعداد بازدیدکننده‌های موبایل و دسکتاپ را به شما می‌دهد.

اعداد مبنا (بر اساس داده‌های مرجع Dynamic Yield که از طریق Oberlo منتشر شده، اکتبر 2024):

• نرخ تبدیل تجارت الکترونیک دسکتاپ: 3.85 درصد
• تبلت: 3.49 درصد
• موبایل: 2.85 درصد
• نسبت موبایل ÷ دسکتاپ ≈ 0.74

برخی منابع برای پوشاک، الکترونیک و جواهرات نسبتی به پایینی 0.50 تا 0.55 گزارش می‌کنند. مرجع درست، نسبت خودِ فروشگاه شما در مقایسه با تاریخچه خودش است، نه یک مبنای جهانی. این نسبت را ماهانه دنبال کنید؛ این مهم‌ترین شاخص کلیدی سلامت موبایل شماست.

چهار مشکل موبایل، هر کدام با روش تشخیص مخصوص خودش

این چارچوب تشخیصی است. بیشتر نوشته‌های «CRO موبایل» مستقیم سراغ راه‌حل‌ها می‌روند؛ اما بُرد واقعی این است که بدانید کدام مشکل را دارید.

مشکل 1 — ترافیکی که هرگز به تسویه‌حساب نمی‌رسد

تشخیص: در گزارش دستگاه‌های Statnive، نشست‌های موبایل تا 15 واحد درصد به تعداد نشست‌های دسکتاپ نزدیک است، اما در WooCommerce ← تحلیل‌ها ← سفارش‌ها، سفارش‌های موبایل کمتر از 30 درصد حجمی است که با توجه به سهم ترافیک انتظارش را دارید.

چه اتفاقی می‌افتد: بازدیدکننده‌های موبایل وارد می‌شوند، شاید یک صفحه را نگاه می‌کنند و بیرون می‌روند؛ آن‌ها هرگز به /cart یا /checkout نمی‌رسند. قیف از بالا نشت می‌کند.

کجا را بعد ببینید: Statnive ← صفحه‌ها ← صفحه‌های ورود، مرتب‌شده بر اساس تعداد ورود. صفحه‌های ورودِ موبایل‌محور را شناسایی کنید (با گزارش دستگاه‌ها مقایسه کنید). اگر این صفحه‌های ورود تعداد خروج بالایی دارند، یک مشکل موبایل در بالای قیف دارید — معمولاً یک صفحه کند، یک هیرو که برای موبایل بهینه نشده، یا یک دکمه فراخوان بالای صفحه که روی نمای 375 پیکسلی دیده نمی‌شود.

مشکل 2 — ترافیکی که به سبد خرید یا تسویه‌حساب می‌رسد اما شکست می‌خورد

تشخیص: بازدیدکننده‌های موبایل به /checkout می‌رسند (در گزارش صفحه‌های شما دیده می‌شود) اما سفارش‌های موبایل همچنان به نسبت کم است. قیف از پایین نشت می‌کند.

چه اتفاقی می‌افتد: بازدیدکننده محصولی را در سبد خرید گذاشته، شاید حتی تسویه‌حساب را شروع کرده، اما وسط فرم آن را رها کرده است. این همان الگوی کلاسیک Baymard است: هزینه‌های اضافی ارسال که خیلی دیر آشکار می‌شوند (39 درصد رهاکننده‌های آمریکایی)، الزام ساخت حساب کاربری (19 درصد)، فرم تسویه‌حساب بیش‌ازحد طولانی (18 درصد) و ناسازگاری ارائه‌دهنده پرداخت.

کجا را بعد ببینید: /checkout فروشگاه‌تان را از یک مرورگر موبایل با نمای 375 پیکسلی باز کنید. کل مسیر را طی کنید. فیلدها را بشمارید. زمان پر‌کردن فرم را اندازه بگیرید. آن را با چک‌لیست تسویه‌حساب موبایل Baymard مقایسه کنید.

مشکل 3 — نرخ پرش موبایل در صفحه محصول

تشخیص: در گزارش صفحه‌های Statnive، صفحه‌های ورودِ محصول (PDP) برتر شما تعداد خروج بالایی دارند. در گزارش دستگاه‌ها، موبایل غالب است. امروز در رابط کاربری هیچ «فیلتر دستگاه روی صفحه‌ها» ساده‌ای وجود ندارد (راه‌حل جایگزین پایین‌تر آمده)، بنابراین این تشخیص از نوع استنتاج دو‌پنجره‌ای است.

چه اتفاقی می‌افتد: بازدیدکننده‌های موبایل روی صفحه محصول شما فرود می‌آیند، اما بدون اسکرول‌کردن دکمه خرید را پیدا نمی‌کنند، یا با لرزش گالری تصویر روبه‌رو می‌شوند، یا برای بارگذاری صفحه زیادی منتظر می‌مانند.

کجا را بعد ببینید: صفحه محصول برتر خود را روی یک دستگاه موبایل واقعی باز کنید (نه یک مرورگر دسکتاپ که به 375 پیکسل باریک شده — تلفن‌های واقعی صفحه‌کلید، لمس و عجایب Safari ITP دارند که شبیه‌سازی دسکتاپ آن‌ها را پنهان می‌کند). LCP را با Google PageSpeed Insights اندازه بگیرید. مطمئن شوید دکمه «افزودن به سبد خرید» بدون اسکرول، بالای صفحه دیده می‌شود. بررسی کنید که گالری تصویر بدون لرزش قابل کشیدن باشد.

مشکل 4 — مخاطب اشتباه از همان ابتدا

تشخیص: سهم ترافیک موبایل بالاست، اما منبع ترافیک یک کانال مشخص است (اغلب تبلیغات شبکه‌های اجتماعی روی Meta) و نرخ پرش در همه صفحه‌های ورودِ موبایل به‌طور یکنواخت بالای 75 درصد است.

چه اتفاقی می‌افتد: تبلیغ‌ها افرادی را هدف گرفته‌اند که آنچه می‌فروشید را نمی‌خواهند، یا خلاقیت تبلیغ با صفحه فرود همخوانی ندارد. تجربه کاربری موبایل فروشگاه شما خوب است؛ مشکل، هدف‌گیریِ بالادست است که خراب است.

کجا را بعد ببینید: Statnive ← ارجاع‌دهنده‌ها ← روی source/medium پارامتر UTM کمپین مشکوک فیلتر کنید. نرخ پرش و مدت‌زمان را با میانگین سایت مقایسه کنید. اگر کمپین در قاعده سلامت کانال رد می‌شود (نرخ پرش بالاتر از میانگین و مدت‌زمان کمتر از میانگین)، مشکل از کمپین است، نه از تجربه کاربری موبایل. برای راهنمای تشخیصی کامل، راهنمای منابع ترافیک را ببینید.

ممیزی 5‌دقیقه‌ای موبایل با روش دو‌پنجره‌ای

این همان جریان کاری است. بدون GA4. بدون داشبورد Lighthouse. بدون ابزار نقشه حرارتی. فقط دو زبانه مرورگر و بخش مدیریت WooCommerce شما.

زبانه 1 — گزارش دستگاه‌های Statnive:

• سهم موبایل از کل نشست‌ها چقدر است؟ (برای بیشتر فروشگاه‌های Woo که مخاطب مصرف‌کننده دارند، باید 60 تا 80 درصد باشد.)
• نرخ پرش موبایل شما در برابر نرخ پرش دسکتاپ چطور است؟ (اختلاف را بر حسب واحد درصد حساب کنید.)
• کدام مرورگرها در موبایل غالب‌اند (Safari موبایل در برابر Chrome اندروید)؟

زبانه 2 — گزارش صفحه‌های Statnive:

• بر اساس تعداد ورود به‌صورت نزولی مرتب کنید. این‌ها صفحه‌های فرود موبایل شما هم هستند (موبایل بخش اعظم ترافیک است).
• بر اساس تعداد خروج به‌صورت نزولی مرتب کنید. هر صفحه /product/، /cart/ یا /checkout را که در 5 مورد برتر باشد، یادداشت کنید.

زبانه 3 — WooCommerce ← تحلیل‌ها ← سفارش‌ها:

• روی 30 روز اخیر فیلتر کنید. تعداد سفارش‌های منتسب به موبایل را یادداشت کنید.
• محاسبه کنید: mobile_orders ÷ (mobile_sessions from Tab 1) = نرخ تبدیل موبایل.
• همین کار را برای دسکتاپ انجام دهید.
• نسبت را حساب کنید. با مبنای 0.60 تا 0.75 مقایسه کنید.

قاعده تصمیم‌گیری:

نسبت	تفسیر	اقدام
0.70 و بالاتر	در محدوده عادی	حفظ وضع موجود — اصلاح فوری موبایل لازم نیست
0.50 تا 0.69	عملکرد کمی پایین‌تر	با مشکل 3 شروع کنید (نرخ پرش موبایل در صفحه محصول)
0.30 تا 0.49	مشکل جدی	هر 4 تشخیص را اجرا کنید؛ معمولاً مشکل 2 یا 4 است
کمتر از 0.30	فاجعه‌بار	احتمالاً مشکل 4 (مخاطب اشتباه) همراه با مشکل 1 است

پنج دقیقه، بدون ابزار شخص ثالث، با یک پاسخ قابل‌دفاع.

یک نکته صادقانه: گزارش صفحه‌ها در رابط کاربری فعلی Statnive قابل فیلتر بر اساس نوع دستگاه نیست — این مقایسه دستی است، نه خودکار. یک نقطه پایانی با قابلیت فیلتر دستگاه در نقشه راه است. تا آن زمان، جریان کاری دو‌پنجره‌ای جایگزین کارآمدی است.

پنج گلوگاه موبایلِ متکی بر شواهد، به ترتیب اولویت

وقتی مشخص کردید کدام مشکل را دارید، صف اولویت اصلاح‌ها این است. هر کدام به پژوهشی مشخص متکی است، نه به حس و گمان.

گلوگاه 1 — LCP موبایل (Largest Contentful Paint) بالای 2.5 ثانیه

شواهد: مطالعه Milliseconds Make Millions از Deloitte/55/Google (اواخر 2019، پیش از Core Web Vitals): هر 0.1 ثانیه بهبود در سرعت موبایل، در 30 میلیون نشست روی 37 سایت برند، 8.4 درصد افزایش نرخ تبدیل خرده‌فروشی و 9.2 درصد افزایش میانگین ارزش سفارش به همراه داشت. این مطالعه پیش از سیگنال رسمی Core Web Vitals انجام شده، اما اثرش هنوز به‌طور گسترده مورد استناد است.

چطور اندازه بگیریم: Google PageSpeed Insights. صفحه ورودِ موبایل برتر خود را وارد کنید. مقدار LCP موبایل (نه دسکتاپ) را یادداشت کنید. هدف، 2.5 ثانیه یا کمتر است؛ به‌روزرسانی‌های آستانه LCP در سال 2026، مقدار «خوب» را روی 2.0 ثانیه یا کمتر قرار می‌دهند.

چطور اصلاح کنیم: بهینه‌سازی تصویر (WebP/AVIF)، بارگذاری تنبل بخش‌های پایین صفحه، افزونه کش سمت سرور (WP Rocket، Cache Enabler) و کاهش JavaScript روی صفحه‌های فرود.

گلوگاه 2 — دکمه فراخوانِ بالای صفحه که روی 375 پیکسل دیده نمی‌شود

شواهد: پژوهش Baymard درباره صفحه محصول موبایل — دکمه فراخوان اصلی باید بدون اسکرول روی نمای 375 پیکسلی در دسترس باشد (عرض iPhone SE یا iPhone Mini). بر اساس پژوهش توجه Nielsen Norman Group، در سایت‌های ریسپانسیو امروزی، 57 درصد زمان مشاهده، بالای صفحه می‌گذرد.

چطور اندازه بگیریم: صفحه محصول برتر خود را در Chrome DevTools با ابعاد 375×667 باز کنید. دکمه خرید را بدون اسکرول می‌بینید؟ اگر نه، یعنی مشکل دارید.

چطور اصلاح کنیم: ارتفاع تصویر هیرو را کم کنید، بلوک عنوان و قیمت را بالاتر بیاورید و مطمئن شوید دکمه فراخوان در ناحیه دسترس انگشت شست است (پایین‌سمت‌راست برای شست راست‌دست).

گلوگاه 3 — اصطکاک گالری تصویر محصول

شواهد: همبستگی Baymard: توانایی مرور روان همه تصویرهای محصول، حدود 0.6 با نرخ افزودن به سبد خرید همبستگی دارد. رایج‌ترین حالت‌های شکست: کار‌نکردن بزرگ‌نمایی، تأخیر در کشیدن انگشت و گالری‌ای که فقط 1 تصویر را بدون هیچ نشانه‌ای از وجود تصویرهای بیشتر نمایش می‌دهد.

چطور اندازه بگیریم: روی یک تلفن واقعی (نه شبیه‌سازی دسکتاپ) یک صفحه محصول را باز کنید. همه تصویرها را با انگشت بکشید. بزرگ‌نمایی را امتحان کنید. اگر چیزی گیر کرد یا کار نکرد، اصلاحش کنید.

چطور اصلاح کنیم: به قالب یا افزونه‌ای با گالری موبایل اثبات‌شده مهاجرت کنید (Astra، Botiga، Storefront 4.x، Kadence). به‌طور خاص روی iOS Safari آزمایش کنید.

گلوگاه 4 — فرم تسویه‌حساب طولانی، الزام گذرواژه و کپچا

شواهد: پژوهش جریان تسویه‌حساب Baymard: میانه تعداد فیلدهای تسویه‌حساب در سایت‌های بزرگ، 14.88 فیلد است؛ کاهش آن به حداقل، در زمینه‌های مخصوص موبایل 25 تا 35 درصد رشد نرخ تبدیل می‌سازد. 24 درصد رهاکننده‌های آمریکایی الزام ساخت حساب کاربری را دلیل می‌آورند و 19 درصد به‌طور مشخص به الزام گذرواژه اشاره می‌کنند.

چطور اندازه بگیریم: فیلدهای الزامیِ دیده‌شده روی /checkout را در موبایل بشمارید. اگر بیش از 8 فیلد است، بالاتر از حد بهینه هستید. بررسی کنید آیا ساخت حساب کاربری الزامی است یا نه.

چطور اصلاح کنیم: به WooCommerce ← تنظیمات ← حساب‌ها و حریم خصوصی بروید و گزینه «به مشتری‌ها اجازه بده بدون ساخت حساب کاربری سفارش ثبت کنند» را فعال کنید. فیلدهای اختیاری (شرکت، خط دوم آدرس، یادداشت سفارش و اغلب تلفن) را در WooCommerce ← تنظیمات ← پیشرفته ← حساب و حریم خصوصی غیرفعال کنید. مطمئن شوید هر فیلد ورودی inputmode درست دارد تا صفحه‌کلید موبایل بهینه شود (عددی برای کد پستی، ایمیل برای ایمیل).

گلوگاه 5 — ناسازگاری ارائه‌دهنده پرداخت

شواهد: پژوهش پذیرش Apple Pay از Stripe نشان می‌دهد وقتی Apple Pay در دسترس باشد، نرخ تبدیل موبایل 8 تا 15 درصد رشد می‌کند که بسته به دسته‌بندی و منطقه متفاوت است. بر اساس داده‌های Stripe و PayPal، خریداران موبایل پرداخت تک‌لمسی را به وارد‌کردن دستی کارت ترجیح می‌دهند.

چطور اندازه بگیریم: /checkout را روی iPhone باز کنید. آیا دکمه Apple Pay دیده می‌شود؟ روی اندروید، Google Pay چطور؟ اگر فقط «کارت اعتباری» نمایش داده می‌شود، یک مشکل اصطکاک پرداخت دارید.

چطور اصلاح کنیم: Apple Pay و Google Pay را از طریق WooPayments، Stripe یا Square فعال کنید. نصب افزونه 5 دقیقه طول می‌کشد؛ اما فعال‌سازی Apple Pay به یک مرحله تأیید دامنه نیاز دارد که 15 دقیقه دیگر اضافه می‌کند.

چهار الگوی نادرست موبایل که باید کنار بگذارید

این‌ها در هر نوشته «بهینه‌سازی موبایل WooCommerce» پیدا می‌شوند. اما پژوهش، آن‌ها را رد می‌کند.

1. «سایت‌تان را ریسپانسیو کنید — همین یعنی بهینه‌سازی موبایل.» بر اساس Nielsen Norman Group، طراحی ریسپانسیو نقطه شروع است، نه راهبرد. ریسپانسیو فقط مطمئن می‌شود سایت روی موبایل بارگذاری می‌شود؛ اما تجربه را برای ورودیِ مبتنی بر انگشت شست، شبکه‌های کندتر یا اولویت‌های نمای کوچک‌تر بهینه نمی‌کند.
2. «یک پاپ‌آپ فقط‌موبایلی برای جمع‌آوری ایمیل اضافه کنید.» بر اساس سیاست تبلیغ‌های تمام‌صفحه مزاحم گوگل (سال 2017)، تبلیغ‌های تمام‌صفحه مزاحم در موبایل می‌توانند جریمه رتبه را فعال کنند. بر اساس پژوهش تجربه کاربری موبایل Baymard، پاپ‌آپ‌های موبایل در مقایسه با معادل دسکتاپ‌شان 23 تا 31 درصد هزینه رهاسازی دارند. به‌جایش روی صفحه‌های بدون قصد خرید از فرم‌های درون‌خطی استفاده کنید؛ روی صفحه محصول، سبد خرید یا تسویه‌حساب هیچ پاپ‌آپی نگذارید.
3. «منوی همبرگری همه‌جا.» بر اساس پژوهش منوی همبرگری NN/g، منوهای پنهان قابلیت کشف را حدود 50 درصد کاهش می‌دهند. ناوبری اصلیِ ضروریِ موبایل (دسته‌بندی، سبد خرید، جستجو) باید دیده شود، نه این‌که پشت یک همبرگر پنهان باشد. همبرگر فقط برای ناوبری ثانویه قابل قبول است.
4. «موبایل‌محور یعنی فونت‌های کوچک‌تر تا چیزهای بیشتری بالای صفحه جا شود.» بر اساس WCAG 1.4.4، متن باید تا 200 درصد قابل بزرگ‌شدن باشد. Apple HIG حداقل 17 پوینت برای متن بدنه را مشخص می‌کند و Material Design حداقل 16sp را. فونت‌های کوچک‌تر هم دسترس‌پذیری را نقض می‌کنند و هم نرخ تبدیل را در میان آن بیش از 50 درصد خریداران موبایلِ بالای 40 سال که اختلال بینایی خفیف دارند، کاهش می‌دهند.

نکته‌های موبایلیِ مخصوص WooCommerce

سه واقعیت درباره قالب و افزونه که نحوه خوانده‌شدن داده‌های موبایل شما را تغییر می‌دهند.

1. تسویه‌حساب بلاکی روی موبایل بهتر از تسویه‌حساب شورت‌کدی است، هم برای تجربه کاربری و هم برای پاکیزگی داده‌های آماری. تسویه‌حساب بلاکی از ابتدا موبایل‌محور بازطراحی شده و فیلدهای دیده‌شده کمتر و مدیریت صفحه‌کلید بهتری دارد. اگر در سال 2026 هنوز روی تسویه‌حساب شورت‌کدی هستید، مهاجرت به نسخه بلاکی پراثرترین تک‌اصلاح موبایلی است که می‌توانید انجام دهید.
2. AMP برای WooCommerce از دید Statnive نامرئی است. صفحه‌های AMP از کش گوگل سرو می‌شوند و یک محیط اجرای JavaScript محدود را اجرا می‌کنند. اسکریپت آماری Statnive روی صفحه‌های AMP اجرا نمی‌شود؛ بنابراین ترافیک AMP در آنالیتیکس شما صفر به نظر می‌رسد. راه‌حل، افزودن یکپارچگی AMP نیست (AMP عملاً منسوخ شده)؛ راه‌حل این است که AMP را غیرفعال کنید و به‌جایش به بهینه‌سازی Core Web Vitals تکیه کنید.
3. در دسترس بودن Apple Pay و Google Pay بسته به درگاه فرق می‌کند. WooPayments (Automattic): هر دو، به‌صورت بومی. Stripe: هر دو، با یک‌بار تأیید دامنه برای Apple Pay. PayPal Payments: Apple Pay از طریق جریان PayPal، نه به‌صورت بومی Apple. Square: منطقه‌ای، فقط آمریکا، کانادا، بریتانیا و استرالیا. پیش از این‌که به مشتری‌ها «Apple Pay در تسویه‌حساب» را وعده دهید، مستندات درگاه خود را بررسی کنید.

گزارش درآمد نسخه v1.0.0 چه چیزی اضافه می‌کند — و هنوز چه چیزی را پوشش نمی‌دهد

از نسخه v1.0.0، قیف سبد خرید تا خرید در گزارش درآمد، افت اصلی تسویه‌حساب را پوشش می‌دهد — مشاهده محصول ← افزودن به سبد خرید ← شروع تسویه‌حساب ← تکمیل خرید، به‌صورت سمت سرور از WooCommerce. می‌توانید گلوگاه موبایل را بلافاصله در سطح هر مرحله ببینید.

دو محدودیت ریزتر هم باقی می‌ماند که صادقانه بیانشان می‌کنیم:

1. زیرمرحله‌های داخل /checkout. قیف Statnive در «شروع تسویه‌حساب» و «تکمیل خرید» متوقف می‌شود. این‌که بازدیدکننده‌های موبایل دقیقاً سرِ انتخاب روش ارسال، انتخاب پرداخت یا بازبینی سفارش رها کرده‌اند یا نه، نشان داده نمی‌شود — یک رویداد checkout_step افزوده‌ای برای آینده است.
2. تحلیل هر تعامل با تصویر. آیا بازدیدکننده‌های موبایل 1 تصویر را با انگشت کشیده‌اند یا هر 5 تصویر را؟ این را با مرور صفحه محصول خودتان روی یک تلفن واقعی می‌فهمید. ثبت رویداد در سطح هر تعامل در نسخه v1.0.0 وجود ندارد.

برای تشخیص اصلیِ موبایل در برابر دسکتاپ، همان چارچوب چهار‌مشکلی، ممیزی دو‌پنجره‌ای و صف اولویت پنج‌گلوگاهی، هنوز اولویت‌بندی را پیش می‌برد. گزارش درآمد، رتبه‌بندی اثر درآمدی را هم روی این‌ها اضافه می‌کند: اصلاح موبایل روی یک قلم از محصولات پرفروش، بیش از همان اصلاح روی یک صفحه محصول کم‌فروش می‌ارزد.

قدم بعدی چیست

1. گزارش دستگاه‌های Statnive را باز کنید. سهم موبایل و نرخ پرش موبایل خود را حساب کنید.
2. WC ← تحلیل‌ها ← سفارش‌ها را باز کنید. نسبت نرخ تبدیل موبایل ÷ نرخ تبدیل دسکتاپ خود را حساب کنید.
3. با جدول تصمیم‌گیری بالا مشخص کنید کدام‌یک از 4 مشکل، مشکل شماست.
4. پراستنادترین اصلاح گلوگاه را برای آن مشکل اعمال کنید.
5. سی روز صبر کنید. تعداد مطلق سفارش‌ها را پیش و پس از اصلاح اندازه بگیرید. اگر رشد 20 درصد یا بیشتر بود، نگهش دارید.

برای حلقه هفتگی گسترده‌تر CRO، مقاله ستون درباره آنالیتیکس حریم‌خصوصی‌محور برای CRO ووکامرس را ببینید. برای حساب‌وکتاب افت مطلق صفحه‌های خروج، صفحه‌های ورود و خروج را بخوانید. برای تصمیم‌های مربوط به کیفیت کانال که به ترافیک موبایل شما خوراک می‌دهند، منابع ترافیک WooCommerce بدون GA4 را ببینید.