بررسی هفتگی آمار WooCommerce در 10 دقیقه

دوشنبه صبح، 10 دقیقه وقت دارید. یا می‌توانید به پنج عدد نگاه کنید و یک تصمیم بگیرید — یا Google Analytics 4 را باز کنید، در داشبورد گم شوید، تب را ببندید و از انجام‌ندادن تحلیل آمار احساس گناه کنید.

این مطلب پادزهر همان حالت است: یک چک‌لیست پنج‌پرسشی که در Statnive و در دقیقاً 10 دقیقه اجرایش می‌کنید. نه تب‌های پر از نمودار. نه گزارش آژانس. نه قالب «خلاصه‌ی اجرایی ماهانه». چاپش کنید. به مانیتورتان بچسبانید. هر دوشنبه اجرایش کنید.

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

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

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

چک‌لیست هفتگی 10 دقیقه‌ای

/wp-admin → Statnive را باز کنید. یک تایمر 10 دقیقه‌ای روشن کنید. به پنج پرسش پاسخ دهید. یک تصمیم بگیرید. یک تغییر را عرضه کنید.

پرسش 1 — آیا چیزی هفته‌به‌هفته تغییر کرده است؟

کجا: Statnive → گزارش نمای کلی. 7 روز اخیر را با 7 روز پیش از آن مقایسه کنید.

قاعده‌ی تصمیم: اگر سهم هر کانال از کل جلسه‌ها هفته‌به‌هفته بیش از 25 درصد جابه‌جا شد، آن را برای پرسش 2 نشانه‌گذاری کنید. در غیر این صورت بروید سراغ بعدی؛ در بیشتر هفته‌ها چیزی تغییر نمی‌کند و این خودش هم اطلاعات مفیدی است.

به‌ترتیب اولویت، دنبال این موارد بگردید:

1. بالا رفتن ناگهانی نرخ پرش روی کانالی که پیش‌تر سالم بود = افت کیفیت. در پرسش 2 ریشه‌یابی کنید.
2. جهش ناگهانی ترافیک با نرخ پرش نزدیک به 100 درصد و مدت نزدیک به صفر = موج ربات. احتمالاً نادیده‌گرفتنش بی‌خطر است؛ اما اگر ادامه پیدا کرد، در تنظیمات Exclusions در Statnive کنارش بگذارید.
3. افت ناگهانی ترافیک روی کانالی که معمولاً پایدار است = چیزی خراب شده؛ مثلاً نمایه‌سازی شما، لینک ایمیلتان یا تأیید کمپین تبلیغاتی‌تان. فوراً ریشه‌یابی کنید.

زمان: 2 دقیقه.

پرسش 2 — این هفته کدام کانال بازدیدکننده‌ی باکیفیت می‌فرستد؟

کجا: Statnive → گزارش ارجاع‌دهنده‌ها. بر اساس جلسه‌ها به‌صورت نزولی مرتب کنید. به ستون‌های پرش و مدت کل نگاه کنید.

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

سه نکته‌ای که کسی نمی‌گوید: کانال را با گروهی هم‌قصد مقایسه کنید (صفحه‌های فرود پولی در برابر دیگر صفحه‌های فرود پولی، نه در برابر میانگین وبلاگتان)؛ پیش از نتیجه‌گیری، حداقل 50 جلسه در یک بازه‌ی 7روزه لازم بدانید؛ و ناکامی‌ها را «اول برای ریشه‌یابی» در نظر بگیرید، نه «اول برای توقف».

دنبال این موارد بگردید:

• یک کانال پرحجم رده‌ی 1 (مستقیم، جستجوی ارگانیک یا ایمیل) که ضعیف عمل می‌کند = پرهزینه‌ترین فرصت ازدست‌رفته‌ی شما.
• ترافیک دستیارهای هوش مصنوعی (دسته‌ی مجزای Statnive که GA4 آن را به مستقیم یا ارگانیک می‌فرستد) که رو به افزایش است = نشانه‌ای از این‌که ابزارهایی مثل ChatGPT/Claude/Perplexity محتوای شما را برداشته‌اند. به الگوی مطلق توجه کنید، نه درصد.

زمان: 2 دقیقه.

پرسش 3 — کدام صفحه بیشترین بازدیدکننده را به‌صورت مطلق از دست می‌دهد؟

کجا: Statnive → گزارش صفحه‌ها. بر اساس تعداد خروج (Exit Count) به‌صورت نزولی مرتب کنید — نه نرخ خروج. صفحه‌ی بالای فهرست را انتخاب کنید که صفحه‌ی تشکر، تأیید فرم تماس یا نتایج جستجو نباشد.

قاعده‌ی تصمیم (همان حساب افت مطلق از مطلب 3): صفحه‌ی بالای فهرست تعداد خروج، اولویت شماست — حتی اگر صفحه‌های دیگر نرخ خروج «بدتری» داشته باشند. صفحه‌ای با 10000 بازدید و نرخ خروج 45 درصد، 4500 جلسه را از دست می‌دهد؛ صفحه‌ای با 500 بازدید و نرخ خروج 90 درصد، 450 جلسه را. اولی را درست کنید.

کدام الگوی خروج است؟

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

زمان: 2 دقیقه.

پرسش 4 — آیا موبایل ضعیف‌تر از دسکتاپ عمل می‌کند؟

کجا: Statnive → گزارش دستگاه‌ها → به جلسه‌ها و نرخ پرش موبایل در برابر دسکتاپ نگاه کنید. WooCommerce → Analytics → Orders → سفارش‌های منتسب به موبایل را بررسی کنید.

قاعده‌ی تصمیم (از مطلب 5): نسبت mobile_CR ÷ desktop_CR را حساب کنید. پایه تقریباً 0.60 تا 0.74 است. اگر نسبت شما زیر 0.50 و سهم موبایلتان بالای 60 درصد است، یک مشکل واقعی در تجربه‌ی کاربری موبایل دارید؛ و این پربازده‌ترین تک‌تغییری است که این هفته می‌توانید عرضه کنید.

میان‌برهای تصمیم:

نسبت	تفسیر	اقدام این هفته
0.70 یا بیشتر	در بازه‌ی عادی	رد کنید — نیازی به رفع فوری موبایل نیست
0.50 تا 0.69	عملکرد اندکی پایین‌تر	برای ممیزی فصل بعد یادداشت کنید
زیر 0.50	مشکل جدی	موبایل به آزمایش پرسش 5 تبدیل می‌شود

زمان: 2 دقیقه.

پرسش 5 — این هفته چه آزمایشی اجرا کنم؟

کجا: در ذهن خودتان، با داده‌های پرسش‌های 1 تا 4.

قاعده‌ی تصمیم: یک تغییر انتخاب کنید. آن را به‌شکل یک فرضیه بیان کنید: «اگر [X] را تغییر دهم، آن‌گاه [متریک] به‌اندازه‌ی [Y] بهتر می‌شود، چون [نشانه‌ای از پرسش‌های 1 تا 4].» عرضه‌اش کنید. تاریخش را یادداشت کنید. هفته‌ی بعد برای خواندن داده‌ها برگردید — اما آزمایش را در نقطه‌ی 30 روز ارزیابی کنید، نه هفتگی.

اصل «یک تغییر» (از مطلب 1، ستون CRO): اگر هر بار یک تغییر اجرا کنید، می‌توانید نتیجه را به همان نسبت دهید. اما اگر هم‌زمان سه تغییر اجرا کنید، نمی‌توانید نتیجه را به هیچ‌کدام نسبت دهید. برای یک فروشگاه Woo تک‌نفره با کمتر از 1000 جلسه در ماه برای هر صفحه، انضباط در انتساب مهم‌تر از سرعت آزمایش است.

زمان: 2 دقیقه.

جمع کل: 10 دقیقه. یک خواندن. یک فرضیه. یک تغییر که این هفته عرضه می‌شود.

چک‌لیست قابل‌چاپ

برای مانیتورتان یا دفترچه‌ی بررسی هفتگی‌تان:

WOOCOMMERCE WEEKLY ANALYTICS REVIEW — 10 MINUTES

□ 1. OVERVIEW — any channel share shifted >25% WoW?
     If yes → flag for Q2.

□ 2. REFERRERS — does any top-3-volume channel fail the
     channel-health rule (bounces ≤ avg AND duration ≥ avg,
     ≥50 sessions)?
     If yes → diagnose, do not pause.

□ 3. PAGES — what's the #1 page by Exit Count (not rate),
     excluding thank-you / contact / search?
     Identify which exit pattern: PDP / cart / checkout.

□ 4. DEVICES — what's mobile_CR ÷ desktop_CR?
     below 0.50 = material mobile problem, becomes Q5.

□ 5. EXPERIMENT — pick ONE change.
     "If I change [X], then [metric] will improve by [Y]
     because [signal]." Ship it. Date it.
     Re-evaluate at 30 days, not next week.

──────────────────────────────────────────────
Total time: 10 minutes. Sips of coffee allowed.

این را به‌صورت یک فایل .txt ذخیره کنید. هر دوشنبه بازش کنید. اجرایش کنید. بعد ببندیدش و بروید آزمایش را عرضه کنید.

اگر زیر 500 جلسه در ماه هستید، چه چیزی را می‌توانید رد کنید

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

• پرسش 4 (دستگاه‌ها) را رد کنید برای هر هفته‌ای که جلسه‌های موبایل زیر 50 است. مخرج کسر بیش‌ازحد کوچک است و نمی‌توان موبایل در برابر دسکتاپ را قابل‌اعتماد خواند؛ به‌جایش ماهانه بازبینی کنید.
• پرسش 2 (ارجاع‌دهنده‌ها) را فقط در سطح دسته‌ی کانال اجرا کنید — تحلیل زیرکانالی UTM زیر 500 جلسه در هفته برای هر کانال، نویز است.
• پرسش‌های 1، 3 و 5 را عیناً نگه دارید — حتی در حجم پایین هم جهت هفته‌به‌هفته و تعداد مطلق خروج همچنان سیگنال‌های معناداری هستند.

چه چیزی را هرگز نباید رد کنید

سه چیزی که هر صاحب فروشگاه Woo تک‌نفره رد می‌کند و بعد پشیمان می‌شود:

1. تعهد به خودِ آزمایش (پرسش 5). خواندن داده‌ها بدون عرضه‌ی یک تغییر، گران‌قیمت‌ترین شکل اهمال‌کاری است. یک آزمایش ناقص در هفته روی هم انباشته می‌شود؛ اما صفر آزمایش بی‌نقص، چیزی نمی‌سازد.
2. ارزیابی مجدد 30روزه‌ی آزمایش ماه گذشته. وقتی تغییر را عرضه می‌کنید، یک یادآور در تقویم بگذارید. وگرنه آزمایش تا ابد اجرا می‌شود و هیچ‌وقت نمی‌فهمید که تغییر جواب داده یا نه.
3. خودِ آهنگ دوشنبه. بررسی 10 دقیقه‌ای در یک «هفته‌ی آرام» همان‌جایی است که سیگنال زودهنگام مشکل هفته‌ی شلوغ را تشخیص می‌دهید. هفته‌های کم‌رونق همان‌جایی‌اند که الگو دیده می‌شود. پس رد نکنید.

نسخه‌ی v1.0.0 چه چیزی به بررسی هفتگی می‌افزاید و چه چیزی هنوز نیازمند مراجعه‌ی متقابل است

از نسخه‌ی v1.0.0 (مه 2026)، دو بخش از بررسی هفتگی فشرده‌تر می‌شوند:

1. درآمد هر کانال درون Statnive. تفکیک کانالی در گزارش درآمد، سفارش‌ها و درآمد و AOV را در همان 8 کانالی به شما می‌دهد که پرسش 2 برای سلامت کانال استفاده می‌کند. بنابراین حالا می‌توانید قاعده‌ی پرسش 2 (نرخ پرش + مدت) را مستقیماً با درآمد هر جلسه به‌تفکیک کانال جفت کنید — دیگر برای عدد اصلی نیازی به مراجعه‌ی دوتبی به WC Analytics نیست.
2. افت در قیف، در چهار مرحله‌ی اصلی. قیف سبد خرید تا خرید، نرخ تبدیل هر مرحله را در طول Viewed product → Added to cart → Started checkout → Completed purchase نشان می‌دهد. در همان بازه‌ی 10 دقیقه‌ای می‌بینید کدام مرحله در سطح فروشگاه ریزش دارد.

اما چه چیزی همچنان نیازمند مراجعه‌ی متقابل است: هر زیرمرحله درون /checkout (ارسال → پرداخت → بازبینی → ثبت) در v1.0.0 نمایش داده نمی‌شود. برای این سطح از جزئیات، WooCommerce → Orders → Abandoned Cart (یا افزونه‌ی بازیابی تسویه‌حساب شما) همچنان منبع است.

گام بعدی چیست

1. چک‌لیست بالا را چاپ کنید. به مانیتورتان بچسبانید.
2. اولین بررسی هفتگی را دوشنبه‌ی بعد اجرا کنید. زمان خودتان را بگیرید.
3. آن یک آزمایش را انتخاب کنید. تاریخش را یادداشت کنید.
4. بعد از 30 روز برگردید، ارزیابی مجدد کنید و بررسی هفته‌ی بعد را اجرا کنید.
5. بعد از 8 هفته، الگوهایی پیدا کرده‌اید که هیچ گزارش آژانسی آن‌ها را آشکار نمی‌کرد — چون شمایید که هر هفته نگاه می‌کنید.

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