چطور با صفحه‌های ورود و خروج، فروش WooCommerce را بیشتر کنیم

یک آزمایش کوچک. آنالیتیکس فروشگاه WooCommerce خود را باز کنید. گزارش صفحه‌های خروج را پیدا کنید. بر اساس نرخ خروج، به‌صورت نزولی مرتب کنید. به نتیجهٔ بالای فهرست نگاه کنید.

تقریباً به‌طور قطع یک صفحه تشکر است، یا یک صفحه فرود کوچک که هیچ‌کس بازدیدش نمی‌کند، یا یک صفحه نتایج جستجو با 30 بازدید و یک کاربر بازگشتی. اینجا جایی نیست که باید درستش کنید.

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

همین جابه‌جایی — از نرخ به تعداد — مؤثرترین تغییری است که یک صاحب فروشگاه تک‌نفرهٔ WooCommerce می‌تواند در فرایند CRO خود ایجاد کند. هزینه‌ای ندارد. اما همه‌چیز را عوض می‌کند. و همین، قلب این مقاله است.

این مقاله به چه چیزی پاسخ می‌دهد

• چرا مرتب‌کردن صفحه‌های خروج بر اساس نرخ یک دام است، و در عوض باید بر اساس چه چیزی مرتب کنید.
• تفاوت پرش و خروج که هیچ‌کس واقعاً درکش نمی‌کند (و مرجع رسمی CXL).
• سه الگوی صفحه خروج در قیف WooCommerce (محصول، سبد خرید، تسویه‌حساب) و راهکار مستند برای هرکدام.
• چهار ضدالگویی که در هر مقاله دیگر CRO می‌بینید — و پژوهشی که آنها را رد می‌کند.
• نکته‌های ریز ویژهٔ WooCommerce که باعث می‌شوند آنالیتیکس استاندارد روی برخی پوسته‌ها و تنظیمات تسویه‌حساب به شما دروغ بگوید.

پرش در برابر خروج — پرسوءتفاهم‌ترین جفت در آنالیتیکس

طبق راهنمای رسمی مؤسسهٔ CXL، قاعده در یک جمله است: «همهٔ پرش‌ها خروج هستند، اما همهٔ خروج‌ها پرش نیستند.»

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

نتیجهٔ عملی این است:

• نرخ خروج 100% روی صفحه /thank-you سالم است — سفارش تمام شده؛ ما خودمان می‌خواهیم بروند.
• نرخ خروج 60% روی /cart یا /checkout فاجعه است — آماده خرید شده‌اند و بعد رفته‌اند.
• نرخ پرش 90% روی یک نوشته وبلاگ خوب است — جستجوی خواننده پاسخ گرفته.
• نرخ پرش 70% روی یک صفحه فرود تبلیغاتی زنگ خطر است — هزینهٔ تبلیغات هدر رفته.

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

حساب کتاب: بازدید × تعداد خروج = زیان مطلق درآمد

این همان بخشی است که در آموزش صفحه‌های خروج WP Statistics، نوشته‌های CRO مربوط به MonsterInsights یا وبلاگ Independent Analytics پیدایش نمی‌کنید. همهٔ آنها بر اساس نرخ خروج مرتب می‌کنند. همین، دام است.

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

صفحه	بازدید	نرخ خروج	تعداد خروج (نشست‌های ازدست‌رفته)
/product/popular-shirt/	10,000	45%	4,500
/product/niche-mug/	500	90%	450

ماگ کم‌فروش نرخ بدتری دارد. اما پیراهن پرفروش، ده برابر بیشتر نشست از دست می‌دهد. اول پیراهن پرفروش را درست کنید. هر نشست بازیافته همان پتانسیل درآمدی را دارد؛ شما می‌خواهید کل مخزن مطلق را بازیابی کنید، نه اینکه نرخ را بهینه کنید.

Statnive این کار را به‌طور ضمنی برای شما انجام می‌دهد. گزارش صفحه‌ها به‌جای نرخ خروج، تعداد خروج را به‌عنوان یک ستون نشان می‌دهد. آن را به‌صورت نزولی مرتب کنید، و بالای فهرست همان صف اولویت شماست — که از پیش بر اساس ترافیک وزن‌دهی شده. اگر نرخ را برای زمینهٔ تشخیصی می‌خواهید، دستی حسابش کنید (exit count ÷ views)، اما هرگز از آن به‌عنوان معیار رتبه‌بندی استفاده نکنید.

عامل تعیین‌کننده در جایگاه قیف، طبق چارچوب‌های اولویت‌بندی PIE/ICE در CXL: وقتی دو صفحه تعداد خروج مشابهی دارند، به صفحه‌های پایین قیف وزن بیشتری بدهید. غافلگیری از هزینهٔ ارسال روی /cart (فروش همین حالا از دست رفته) ارزش بیشتری دارد از یک خروج مردد روی نوشته وبلاگ (فروشی که شاید بعداً، شاید هیچ‌وقت). یک ضریب کاربردی: PDP × 1.2، سبد خرید × 1.5، تسویه‌حساب × 1.5 در برابر خروج‌های وبلاگ که 1.0 هستند.

سه الگوی صفحه خروج (و راهکار مستند برای هرکدام)

هر فروشگاه تک‌نفرهٔ WooCommerce در سه جای قابل‌تشخیص درآمد از دست می‌دهد: صفحه جزئیات محصول (PDP)، سبد خرید و تسویه‌حساب. هرکدام راهکار متفاوتی دارند.

الگوی 1 — خروج‌های صفحه محصول (PDP)

این‌طور به نظر می‌رسد: تعداد ورود بالا، مدت‌زمان متوسط (15–60 ثانیه)، تعداد خروج بالا بدون رویدادهای add_to_cart. بازدیدکننده آن‌قدر خوانده که تصمیم بگیرد «نه» و بعد رفته است.

طبق پایگاه دادهٔ کاربردپذیری تسویه‌حساب Baymard، پرشواهدترین راهکارهای PDP اینها هستند:

• پشتهٔ اعتماد روی خودِ صفحه. نظرها (طبق Baymard، 95% خریداران پیش از خرید آنها را می‌خوانند)، برآورد تاریخ تحویل (24% رشد)، نشان مرجوعی قابل‌مشاهده (27% رشد). صاحبان تک‌نفرهٔ Woo مدام در این بخش کم‌سرمایه‌گذاری می‌کنند، چون فرض می‌کنند خریدار از قبل به آنها اعتماد دارد.
• شفافیت هزینهٔ ارسال و قیمت بالای صفحه. پنهان‌کردن هزینهٔ ارسال تا تسویه‌حساب، بزرگ‌ترین دلیل رهاکردن سبد خرید است (39% از کسانی که سبد را رها می‌کنند). آن را در PDP حل کنید، نه در سبد خرید.
• گالری موبایل‌محور + دکمهٔ CTA بالای صفحه. پژوهش توجه گروه Nielsen Norman نشان می‌دهد 57% زمان دیدن، بالای صفحه است؛ و طبق Baymard، 71% کاربران روی موبایل اصلاً در PDP اسکرول نمی‌کنند. دکمهٔ «افزودن به سبد خرید» باید بدون اسکرول روی نمایشگر 375 پیکسلی در دسترس باشد.

الگوی 2 — خروج‌های صفحه سبد خرید

این‌طور به نظر می‌رسد: تعداد ورود بالا روی /cart (یا نشانی سفارشی سبد خرید شما)، خروج‌های ‎≥40%‎. به سبد خرید رسیده‌اند و بعد رفته‌اند.

فهرست راهکارهای مستند، به‌ترتیب اولویت:

• هزینهٔ نهایی کامل (محصول + ارسال + مالیات) را روی صفحه سبد خرید نشان دهید. نه در تسویه‌حساب. در سبد خرید. Baymard این را دلیل شمارهٔ یک رهاکردن می‌داند، و حلش در نمونه‌مطالعه‌های آنها 5–11% رشد نرخ تبدیل می‌سازد. الگوی «هزینهٔ ارسال غافلگیرکننده در تسویه‌حساب» کشنده‌ترین الگو در WooCommerce است.
• تسویه‌حساب مهمان واقعی، نه «اول تسویه کن، بعد ازت می‌خواهیم ثبت‌نام کنی». 24% از رهاکنندگان آمریکایی، اجبار به ساختن حساب کاربری را دلیل رهاکردن می‌دانند؛ میانهٔ رشدی که Baymard از افزودن یک تسویه‌حساب مهمان واقعی گزارش می‌کند 14% است.
• فیلد کد تخفیف را به‌طور پیش‌فرض جمع کنید، یا حذفش کنید. 27% خریداران آمریکایی گزارش می‌دهند وقتی یک فیلد کد تخفیف برجسته می‌بینند، سایت را برای پیدا کردن کد تخفیف ترک می‌کنند. این فیلد ذهن خریدار را روی «باید کمتر از این بپردازم» قفل می‌کند — و او می‌رود تا کدی را پیدا کند که شاید اصلاً وجود نداشته باشد.

الگوی 3 — خروج‌های صفحه تسویه‌حساب

این‌طور به نظر می‌رسد: خریداران به /checkout می‌رسند و تعداد خروج بالا می‌رود. تسویه‌حساب را شروع کرده‌اند و وسط فرم بیرون زده‌اند.

طبق تحلیل جریان تسویه‌حساب Baymard:

• تسویه‌حساب را به 7–8 فیلد فرم کاهش دهید. میانهٔ پایگاه دادهٔ Baymard 14.88 فیلد است؛ کاهش به حداقل، میانهٔ 35.26% رشد نرخ تبدیل می‌سازد. تسویه‌حساب پیش‌فرض WooCommerce این موارد را می‌خواهد: نام، نام خانوادگی، شرکت، کشور، آدرس خط 1، آدرس خط 2، شهر، استان، کد پستی، تلفن، ایمیل، یادداشت سفارش — 12 فیلد. آنهایی را که لازم ندارید (شرکت، آدرس خط 2، یادداشت سفارش، اغلب تلفن) در «WooCommerce ← تنظیمات ← حساب‌ها و حریم خصوصی» غیرفعال کنید.
• درگاه پرداختی را که بازدیدکننده انتظارش را دارد فراهم کنید. اگر بازدیدکنندگان شما عمدتاً موبایلی و اروپایی‌اند، یعنی Apple Pay + Klarna + SEPA، نه «همهٔ درگاه‌ها فعال». افزودن گزینه‌های بیش از حد، خستگی تصمیم‌گیری می‌آورد.
• الزام به رمز عبور را بردارید و inputmode درست را روی هر فیلد بگذارید. 19% از رهاکنندگان آمریکایی، اجبار به ساختن حساب کاربری را دلیل می‌دانند (که معمولاً یعنی «یک رمز عبور بگذار»)؛ ارائهٔ تسویه‌حساب بدون رمز (از طریق لینک ایمیل یا شبکه‌های اجتماعی) 6–9% رشد می‌سازد.

چهار ضدالگو که باید نادیده بگیرید

این‌ها در هر فهرست «بهینه‌سازی نرخ تبدیل فروشگاه‌های اینترنتی» پیدا می‌شوند. اما پژوهش ردشان می‌کند.

1. پنهان‌کردن هزینهٔ ارسال تا تسویه‌حساب. این دلیل شمارهٔ یک رهاکردن طبق Baymard است. انجام عمدی‌اش یعنی خرابکاری علیه خودتان. هزینهٔ نهایی را روی PDP نشان دهید، دوباره روی سبد خرید، پیش از شروع تسویه‌حساب.
2. اجبار به ساختن حساب کاربری پیش از تسویه‌حساب. 24% از رهاکنندگان آمریکایی همان لحظه که دیوار «اول ثبت‌نام کن» را می‌بینند می‌روند. تسویه‌حساب مهمان واقعی — بدون حساب، بدون رمز عبور، فقط یک ایمیل تأیید — غیرقابل‌مذاکره است.
3. افزودن پاپ‌آپ قصد خروج به هر صفحه. پژوهش دو دسته است. روی یک نوشته وبلاگ یا صفحه دسته‌بندی، یک پاپ‌آپ قصد خروج با پیشنهاد مرتبط می‌تواند جمع‌آوری ایمیل را بیشتر کند. اما روی PDP، سبد خرید یا تسویه‌حساب، خصمانه است — طبق پژوهش هم‌پوشانی NN/g و تست‌های فروشگاهی Speero، پاپ‌آپ‌های قصد خروج روی صفحه‌های با قصد خرید، نرخ تبدیل را فعالانه کاهش می‌دهند و به اعتماد به برند آسیب می‌زنند. روی /product/*، /cart و /checkout از آنها صرف‌نظر کنید.
4. اعمال خودکار کدهای تخفیف سراسری برای «بازیابی» سبدهای رهاشده. برخلاف تصور. طبق Baymard و Speero، تخفیف‌های فراگیر مشتری را عادت می‌دهند که صبر کند، ذهن همه را روی قیمت پایین‌تر قفل می‌کنند و حاشیهٔ سود را می‌خورند بدون اینکه سبدهای رهاشدهٔ زیادی را بازگردانند. کدهای تخفیف را برای پیشنهادهای مشخص و زمان‌دار که به رفتاری خاص گره خورده‌اند نگه دارید (مثلاً «30 روز غیرفعال بماند، بعد یک کد تخفیف برایش ایمیل کنیم»). هرگز خودکار اعمالشان نکنید.

نکته‌های ریز ویژهٔ WooCommerce (آنهایی که آنالیتیکس استاندارد را به دروغ‌گویی می‌اندازند)

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

1. صفحه‌های تشکر به‌ازای هر سفارش یک ردیف در گزارش صفحه‌ها می‌سازند. نشانی صفحه تشکر در WooCommerce به این شکل است: /checkout/order-received/{order_id}/. هر سفارش یک نشانی منحصربه‌فرد می‌سازد. گزارش صفحه‌های شما صدها ردیف مجزا برای یک صفحهٔ منطقی واحد نشان می‌دهد. برای شمردن بازدیدهای صفحه تشکر، بر اساس الگوی نشانی (/order-received/) فیلتر کنید، نه بر اساس نامک دقیق.
2. سبد خرید با نامک سفارشی و پوسته‌های کشوی AJAX، الگوی /cart/ را می‌شکنند. از WooCommerce نسخه 8.0 به بعد می‌توانید نشانی سبد خرید را در «تنظیمات ← پیشرفته» تغییر دهید، و بلوک‌های سبد خرید/تسویه‌حساب اجازه می‌دهند سبد را در صفحهٔ نخست جا دهید (هیچ نشانی /cart/ اصلاً وجود ندارد). Astra، Botiga، Flatsome، Blocksy و Storefront مدرن از کشوهای سبد خرید کشویی AJAX استفاده می‌کنند که هرگز یک بازدید صفحه /cart/ ثبت نمی‌کنند. حدود نیمی از فروشگاه‌های مدرن WooCommerce اصلاً یک ردیف /cart/ نمی‌بینند. از نسخه v1.0.0، قیف سبد خرید تا خرید در گزارش درآمد، رویدادهای wc_add_to_cart و wc_checkout_start را سمت سرور از WooCommerce می‌خواند — تسویه‌حساب بلوک‌محور، پوسته‌های سبد کشویی و نامک‌های سفارشی همگی آنجا درست شمرده می‌شوند، مستقل از بازدید صفحه.
3. حالت‌های یک محصول متغیر در نامک والد جمع می‌شوند. یک محصول متغیر روی /product/t-shirt/ با رشته‌های پرس‌وجوی ?attribute_pa_color=red و ?attribute_pa_size=large به‌صورت یک ردیف در گزارش صفحه‌ها ثبت می‌شود، نه سه ردیف. این واحد درستی برای CRO صفحهٔ محصول والد است («آیا این تی‌شرت فروش دارد؟») و واحد نادرستی برای تحلیل حالت‌ها («قرمز می‌فروشد ولی آبی نه؟»). تحلیل در سطح حالت‌ها هنوز یک نقطهٔ مبهم شناخته‌شده در گزارش صفحه‌هاست — برای دادهٔ حالت‌ها در سطح خرید، گزارش درآمد ← محصولات برتر زیر والد گروه‌بندی می‌کند، که با گروه‌بندی خودِ WooCommerce هماهنگ است اما باز هم به‌ازای هر حالت تفکیک نمی‌کند.

اگر گزارش آنالیتیکس‌تان در هفتهٔ اول «ناجور» به نظر رسید، این فهرست معمولاً علتش را توضیح می‌دهد — و علت، پوسته/تنظیمات است، نه اسکریپت آماری.

ریتم CRO تک‌نفرهٔ Woo: یک صفحه، یک راهکار، یک ماه

بیشتر توصیه‌های CRO فرض می‌کنند یک تیم CRO و یک ابزار تست A/B دارید. اما ندارید. طبق راهنمای معناداری آماری CXL، با کمتر از 1000 نشست به‌ازای هر صفحه در ماه نمی‌توانید در بازهٔ معقولی از تست A/B به‌طور قابل‌اتکا به معناداری برسید. اشکالی ندارد — فقط ریتم را عوض می‌کند.

ریتم برای صفحه‌ای با کمتر از 1000 نشست:

1. گزارش صفحه‌ها را بر اساس تعداد خروج به‌صورت نزولی مرتب کنید. صفحه‌ای را از بالای فهرست انتخاب کنید که صفحه تشکر / تأیید فرم تماس / نتایج جستجو نباشد.
2. تشخیص دهید با کدام‌یک از سه الگوی صفحه خروج جور درمی‌آید (PDP / سبد خرید / تسویه‌حساب).
3. از چک‌لیست Baymard برای آن الگو، پرشواهدترین راهکار را که در کمتر از 4 ساعت می‌توانید پیاده‌سازی کنید انتخاب کنید.
4. راهکار را در یک تاریخ مشخص اجرا کنید.
5. ‏30 روز قبل را با 30 روز بعد بسنجید، بر اساس سفارش‌های مطلق (پیشخوان Woo) و تعداد خروج آن صفحه (Statnive). اگر رشد مطلق ‎≥20%‎ بود، تغییر را نگه دارید.
6. به صفحهٔ بعدی فهرست بروید.

یک صفحه، یک راهکار، یک ماه. دوازده راهکار در سال. به‌طور طراحی‌شده این از دفترچهٔ بازی آژانس‌ها کندتر است و خیلی معتبرتر: در پایان 12 ماه یک فهرست از 12 راهکار دارید، هرکدام با یک قبل/بعد 30روزه بر اساس سفارش‌های مطلق، و یک شهود واقعی از اینکه چه چیزی روی فروشگاه شما تفاوت محسوسی می‌سازد، نه روی یک پنل 50000 نفری Baymard.

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

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

1. می‌توانید خروج‌ها را با درآمد پیوند بزنید. گزارش صفحه‌ها را برای کار تشخیصی بر اساس تعداد خروج مرتب کنید، بعد گزارش درآمد ← محصولات برتر را باز کنید تا ببینید آیا همان محصولات بخش زیادی از درآمد را می‌سازند. یک PDP پرخروج که هم‌زمان یک محصول پردرآمد است، پرتأثیرترین هدف CRO است — همان صفحه‌ای که کم‌کردن خروج‌هایش بیشترین اثر ریالی را دارد.
2. قیف نشان می‌دهد در کدام گام تسویه‌حساب مشتری را از دست می‌دهید. قیف 4 مرحله‌ای — wc_product_view → wc_add_to_cart → wc_checkout_start → wc_purchase — سمت سرور از WooCommerce خوانده می‌شود و نرخ تبدیل هر گام را نشان می‌دهد. دیگر لازم نیست «ارسال یا پرداخت؟» را از روی تعداد خروج /checkout حدس بزنید.

ریتم یک‌صفحه‌یک‌راهکار‌یک‌ماه هنوز تعیین می‌کند کدام صفحه را درست کنید. گزارش درآمد حالا تعیین می‌کند راهکار واقعاً چقدر درآمد را جابه‌جا کرده است (نه فقط خروج‌ها را).

قدم بعدی چیست

1. اگر هنوز نصب نکرده‌اید، Statnive را از WordPress.org نصب یا باز کنید.
2. گزارش صفحه‌ها را باز کنید. بر اساس تعداد خروج به‌صورت نزولی مرتب کنید.
3. تشخیص دهید کدام‌یک از 3 صفحه خروج برتر شما PDP است، کدام سبد خرید و کدام تسویه‌حساب.
4. یکی را انتخاب کنید. چک‌لیست Baymard را برای آن الگو بیرون بکشید (در بالا لینک شده). پرشواهدترین راهکاری را که امروز می‌توانید اجرا کنید انتخاب کنید.
5. اجرایش کنید. تاریخ را یادداشت کنید. 30 روز بعد برگردید.
6. مقالهٔ ستون دربارهٔ آنالیتیکس حریم‌خصوصی‌محور برای CRO در WooCommerce را بخوانید تا حلقهٔ هفتگی کامل 7مرحله‌ای را که این کار بخشی از آن است ببینید.

بر اساس تعداد مرتب کنید، نه نرخ. یک چیز را درست کنید. 30 روز صبر کنید. کل مقاله همین است.