چرا فروشگاه فروش ندارد؟ عیب‌یابی تا سود

داشبورد GA4 می‌گوید ۳۲۰ خرید ثبت شده، پنل فروشگاه ۲۶۸ سفارش دارد، درگاه فقط ۲۴۱ پرداخت موفق نشان می‌دهد و انبار ۲۲۷ سفارش را قابل‌ارسال می‌داند. تیم تبلیغات «فروش» را زیاد کرده، اما مالی می‌پرسد پول و حاشیه سود کجاست. پیش از تغییر قیمت، طراحی یا بودجه، باید مشخص شود کدام State و کدام منبع، فروش واقعی را تعریف می‌کند.

چرا فروشگاه اینترنتی فروش ندارد؟ ممکن است Demand کم یا ورودی نامرتبط باشد؛ Offer/Price/Availability هم‌ساز نباشد؛ Product finding و Decision fail شود؛ Cart/Checkout/Payment خطا دهد؛ سفارش پس از پرداخت در OMS/انبار گیر کند؛ تحویل/مرجوعی ارزش را از بین ببرد؛ یا Measurement اشتباه باشد. تشخیص حرفه‌ای مسیر Demand→Discovery→Offer→Cart→Payment→Order→Fulfillment→Return→Contribution را با Source of truth و Reconciliation می‌سنجد.

پاسخ کوتاه: ۱۰ لایه عیب‌یابی

1. Incident یا Trend را از Noise جدا کنید؛
2. تعریف فروش و Source of truth را تثبیت کنید؛
3. Event/Order/Payment/Refund را Reconcile کنید؛
4. Demand و کیفیت Acquisition را بسنجید؛
5. Offer، Price، Availability و Unit economics را بررسی کنید؛
6. Catalog/Search/Category و Product decision را تست کنید؛
7. Cart/Checkout/Payment state machine را عیب‌یابی کنید؛
8. Order/Fulfillment/Delivery/Return را دنبال کنید؛
9. Segment، Cohort و Counterfactual بسازید؛
10. Fix را با Outcome و Guardrail آزمایش و پایش کنید.

این صفحه مالک Diagnosis است. بعد از یافتن گلوگاه، برای Intervention و رشد به راهنمای افزایش فروش فروشگاه تا سود واقعی بروید؛ ایده بدون Root cause می‌تواند هزینه مشکل را زیاد کند.

گام صفر: Symptom contract بنویسید

as-of date + timezone
metric/state definition + source
current vs baseline/expected
absolute + rate + value
segment/channel/device/region/product
start time/change point
data freshness/completeness
business impact + guardrails
owner + next decision

«فروش کم است» کافی نیست. نمونه: «از ۱۷ مرداد، نرخ سفارش Paid یکتای موبایل Android از Search برای دسته X نسبت به Median هشت هفته قبل ۳۵٪ کم شده؛ Session ثابت است، begin_checkout ثابت و PSP success افت کرده؛ داده تا ساعت ۱۰:۳۰ کامل است.»

Incident، Seasonality یا تغییر تعریف؟

ابتدا Change log را کنار نمودار بگذارید: Campaign، Price، Inventory، Release، PSP، Consent، تعطیلات، Feed و Algorithm/Policy change.

فروش را به State machine تعریف کنید

cart_created → checkout_started
→ payment_initiated → payment_authorized/captured | failed | unknown
→ order_created → verified → allocated
→ packed → shipped → delivered
→ return_requested → returned → refund_pending → refunded
→ settled/reconciled

purchase در Client یک Observation است، نه الزاماً حقیقت مالی. Business ممکن است «Paid»، «Verified»، «Delivered» یا «Settled minus refund» را برای تصمیم‌های متفاوت لازم داشته باشد. Stateها، Timestamp، Currency، Amount و ID اتصال را نسخه‌دار کنید.

Source of truth matrix

یک Warehouse می‌تواند گزارش مرجع بسازد، اما Truth هر مفهوم از System مسئول و قرارداد Reconciliation می‌آید.

گام ۱: Reconciliation را پیش از Funnel اجرا کنید

مستند جاری Ecommerce در GA4 Eventهایی مانند View، Cart، Checkout، Purchase و Refund و Item/transaction_id را تعریف می‌کند. پیاده‌سازی Event به‌تنهایی فروش را معتبر نمی‌کند.

per order/payment:
analytics transaction_id
↔ commerce order_id
↔ PSP payment/reference
↔ OMS status
↔ WMS allocation/shipment
↔ finance settlement/refund

checks:
count | gross/net amount | currency
duplicates | missing | orphan | delayed
state transition | item-level quantity/value

Refresh صفحه تشکر، Callback تکراری، Client blocker، Consent، Offline return، Refund جزئی و Late event اختلاف می‌سازند. اختلاف باید Classification و Owner داشته باشد، نه «طبیعی است».

Reconciliation report نمونه

Data quality gate برای تحلیل

• Freshness و processing delay؛
• Completeness در Event/Item/Order؛
• Uniqueness transaction/order/payment؛
• Validity State/amount/currency/ID؛
• Consistency بین Systemها؛
• Referential integrity Order↔Item↔Payment؛
• Consent/coverage و Segment bias؛
• Timezone/روز شمسی/میلادی و Cutoff مالی؛
• IRR/IRT و Minor unit contract؛
• Version/Owner/incident log.

اگر Data gate رد شد، تصمیم قطعی درباره UX/Marketing نگیرید؛ ابتدا Range عدم قطعیت را گزارش کنید.

گام ۲: Demand را از Traffic جدا کنید

Session زیاد با Intent اطلاعاتی، شهر خارج پوشش، محصول ناموجود یا Coupon hunter ممکن است Purchase کمی بسازد و مشکل UX نباشد.

Search و Landing را Query-level ببینید

• Query/Page/Device/Country/Search appearance؛
• Brand vs non-brand و Category/Product/Guide intent؛
• Position/Impression/CTR بدون فرض رتبه ثابت؛
• Landing→Product view→Cart→Verified order؛
• Availability/price/variant در زمان ورود؛
• ۴۰۴/canonical/noindex/render/internal link؛
• Revenue/Contribution/Return با Attribution limits.

برای معماری Catalog و SEO فنی از راهنمای سئو فروشگاه اینترنتی استفاده کنید. CTR یا Engagement به‌تنهایی فروش و رتبه را اثبات نمی‌کنند.

Paid/Social/Affiliate؛ Click ارزان را پاداش ندهید

spend → eligible landing sessions → product decision
→ cart → verified paid order → delivered
→ net revenue → contribution after return
guardrails: fraud, coupon leakage, support, cancellation

UTM و Click ID را به Order-level با محدودیت Privacy متصل کنید. Last-click کل Journey را توضیح نمی‌دهد؛ برای Budget decision حداقل Blended و Incremental evidence را کنار Platform attribution ببینید.

گام ۳: Offer و Unit economics

net revenue
- COGS
- discount
- payment fee
- pick/pack/shipping subsidy
- return/refund loss
- support/fraud
- variable acquisition
= contribution

افزایش Revenue با تخفیف یا ارسال رایگان می‌تواند Contribution را منفی کند. «فروش ندارد» را برای Revenue، Profit یا Cashflow دقیق کنید.

Price و Availability باید یک Truth داشته باشند

اختلاف قیمت/موجودی میان Feed، Landing، Structured data، Cart و Checkout هم اعتماد و هم Eligibility را خراب می‌کند. راهنمای Merchant Center درباره Price mismatch توضیح می‌دهد Google قیمت Feed را با Landing/Structured data مقایسه می‌کند و mismatch می‌تواند Product را Disapprove کند.

PIM/ERP source
→ catalog/API/cache
→ server HTML + visible page
→ JSON-LD Product/Offer
→ Merchant feed/API
→ cart/checkout/order snapshot
→ invoice/refund

Timestamp، Currency، Variant، Region و Promotion effective window را در هر مرحله ثبت کنید. Cache قدیمی و JS دیرهنگام مشکل واقعی‌اند.

Product structured data حقیقت را جایگزین نمی‌کند

Google Merchant listing structured data Price، Availability، Shipping و Return information را برای Eligibility توضیح می‌دهد. Markup باید با محتوای دیده‌شده و State خرید هماهنگ باشد؛ Rich result تضمین‌شده نیست.

گام ۴: Catalog، Search و Category

• Taxonomy بر زبان/Job خریدار، نه انبار؛
• Variant/duplicate/canonical و URL پایدار؛
• Internal search با Persian normalization و typo؛
• Zero-result query و پیشنهاد بازیابی؛
• Filterهای تصمیم‌ساز، نه Attribute noise؛
• Sort و Default قابل‌توضیح؛
• Stock/price/delivery visible در List؛
• Mobile filter state و Back behavior؛
• Unavailable/Discontinued alternative؛
• Analytics برای query/filter/result/click/outcome.

جست‌وجوی داخلی «کفش دویدن ۴۲» که صفر نتیجه می‌دهد در حالی که کالا با برچسب متفاوت موجود است، مشکل Demand نیست.

Diagnostic funnel یافتن محصول

landing/category/search
→ list_view with result_count
→ item_impression
→ item_select
→ product_view eligible
→ variant selected/in-stock
→ add_to_cart accepted

Denominator را فقط Userهایی بگیرید که واقعاً Eligible و Exposed بوده‌اند. Add-to-cart کم برای محصول ناموجود یک Signal متفاوت از محصول موجود است.

گام ۵: Product decision page

Copy تأمین‌کننده، Review ساختگی و Countdown resetشونده Decision quality نمی‌سازند. Task-based usability و سؤال پشتیبانی را وارد محتوا کنید.

گام ۶: Cart را یک Quote نسخه‌دار ببینید

cart_id/version
items/variant/quantity
unit price/discount/tax
shipping estimate/region
inventory/expiry/reservation
total/currency
promotion eligibility
owner/source/timestamp

Cart باید تغییر Price/Stock/Promotion را با پیام و Choice روشن مدیریت کند. Silent replacement یا تغییر مبلغ آخر کار Trust را خراب می‌کند.

Checkout diagnostic tree

برای UX/State/Recovery عمیق از راهنمای بهینه‌سازی Checkout استفاده کنید.

Payment state؛ موفق/ناموفق کافی نیست

created → initiated → redirected
→ authorized/captured | declined | cancelled | timeout | unknown
→ verified/reconciled
→ order created | orphan payment
→ settled | reversed | refunded

Callback تکراری باید Idempotent باشد. اگر PSP پول گرفته و Order ساخته نشده، Incident مالی و تجربه مشتری است؛ Dashboard Funnel به‌تنهایی کافی نیست.

Payment synthetic و Controlled transaction

• موفق با مبلغ/Variant کنترل‌شده؛
• انصراف در PSP؛
• Timeout/قطع شبکه و بازگشت دیر؛
• Refresh/Back/دوبار کلیک؛
• Callback duplicate/out-of-order؛
• PSP paid/no order و recovery؛
• Refund کامل/جزئی؛
• Notification fail؛
• موبایل/Browser/ISP مختلف متناسب؛
• تطبیق PSP/OMS/Finance.

در Production با هماهنگی مالی و مبلغ کنترل‌شده اجرا کنید؛ Test data/Order را از KPI واقعی جدا علامت بزنید.

Performance و JavaScript failure

Average load time مشکل یک Journey/Device را پنهان می‌کند. PDP/Cart/Checkout را با RUM بر Device/Network/Template/Version ببینید:

• LCP برای Evidence/Price/Product image؛
• INP و Action response؛
• CLS روی Variant/Add/Checkout؛
• JS/API errors و Hydration؛
• Third-party/Tag/Chat/Experiment impact؛
• Timeout/retry/offline recovery.

Deploy marker را با Conversion/Errors مقایسه کنید، بدون اینکه Correlation را Cause قطعی بدانید.

گام ۷: Order تا Delivery

Purchase رخ داده اما Sale باارزش هنوز کامل نیست. برای معماری عملیاتی به راهنمای انبار، Fulfillment، ارسال و مرجوعی مراجعه کنید.

Promise vs actual؛ حلقه اعتماد

promised ship/delivery window at checkout
↔ actual allocation/dispatch/delivery
↔ proactive status/exception communication
↔ support contacts
↔ cancellation/return/repeat behavior

اگر وعده تحویل غیرواقعی Conversion را بالا ببرد اما Cancel/Complaint/Repeat را خراب کند، Intervention شکست خورده است.

Return reason را «مرجوعی» جمع نزنید

• Size/fit؛
• Damaged/wrong item؛
• Not as described/image mismatch؛
• Quality expectation؛
• Late delivery؛
• Changed mind؛
• Duplicate/order error؛
• Fraud/abuse؛
• Policy/service failure.

Reason quality را با Product/Variant/Channel/Supplier/Cohort و Contribution متصل کنید. کاهش Return با سخت‌کردن مسیر مرجوعی موفقیت نیست.

خرید مجدد؛ Cohort و Reorder cycle

Repeat rate را بر اساس Category و چرخه طبیعی مصرف بسنجید. Cohortها:

• اولین خرید ماه/کانال/Offer؛
• Product/Category/Supplier؛
• Delivered on-time vs late؛
• Returned/refunded/support contacted؛
• Discounted vs full-price؛
• New vs returning device/account؛
• Region و delivery promise.

Repeat پایین برای کالای با خرید ده‌ساله مانند Repeat پایین کالای مصرفی نیست.

Segment matrix؛ Simpson’s paradox را جدی بگیرید

Aggregate Conversion ممکن است افت کند چون Mix Channel تغییر کرده، در حالی که هر Segment ثابت است؛ یا برعکس.

Lost demand را اندازه بگیرید

zero-result searches
out-of-stock views
unavailable variant selections
notify-me/backorder requests
delivery-region rejections
price/stock mismatch
failed coupon/payment/shipping
support asking for unavailable products
competitor/referral exits (where observable)

فقط Orders موجود را Forecast نکنید؛ Stockout، Assortment gap و Coverage failure Demand سانسورشده می‌سازند.

Root cause tree؛ از Symptom به Evidence

low net contribution
├─ low eligible demand
├─ low discovery/traffic quality
├─ weak offer/price/stock/delivery
├─ poor findability/product decision
├─ cart/checkout/payment failure
├─ order/fulfillment/cancel/return loss
└─ measurement/reconciliation error

برای هر شاخه یک Falsifiable hypothesis، Evidence موافق/مخالف، Confidence و Next cheapest test بنویسید.

اولویت با Severity × Reach × Evidence × Recoverability

Payment orphan با Reach کم ممکن است از رنگ CTA با Reach زیاد اولویت بالاتری داشته باشد.

Incident mode و Improvement mode را جدا کنید

هنگام خرابی پرداخت، A/B test رنگ دکمه اجرا نکنید.

روش آزمون Fix

because evidence...
for eligible segment...
changing system/content/offer...
will improve verified business state...
measured by primary metric...
without harming guardrails...
during window/sample...
decision: rollback/hold/scale/iterate

برای Issue فنی از Rollout مرحله‌ای و Monitoring استفاده کنید؛ برای UX از Usability و Experiment؛ برای Price/Promo از Contribution و Incrementality؛ برای Operations از Pilot region/category.

Guardrailهای فروش

• Contribution/margin؛
• Cancel/return/refund؛
• Payment/order discrepancy؛
• Delivery lateness؛
• Support/complaint؛
• Fraud/abuse؛
• Privacy/consent؛
• Accessibility/exclusion؛
• Performance/error؛
• Repeat/trust.

برنامه عیب‌یابی ۷۲ساعته

۰ تا ۴ ساعت: صحت و Incident

PSP/OMS/WMS/Finance status، Deploy/change، Synthetic purchase، Error/latency و Data freshness را کنترل و در صورت آسیب Contain کنید.

۴ تا ۱۲ ساعت: Reconciliation

Order-level Analytics↔PSP↔OMS↔WMS و اختلاف Count/Amount/State را دسته‌بندی کنید.

۱۲ تا ۲۴ ساعت: Segment

Device/Channel/Region/Product/Payment/Release را با Baseline و Mix مقایسه کنید.

روز دوم: Journey evidence

Search/Product/Cart/Checkout/Payment/Delivery را با Log، RUM، Support و Task observation بررسی کنید.

روز سوم: Decision

Root cause candidates، Confidence، Mitigation، Owner، Metric/Guardrail و Recheck time را ثبت کنید.

برنامه ۳۰روزه تثبیت

1. Source-of-truth و State dictionary را تصویب کنید؛
2. Reconciliation روزانه Payment/Order/Refund بسازید؛
3. Top failure را با Incident/Recovery monitor کنید؛
4. Price/Stock truth را در Feed/Page/Schema/Checkout هم‌ساز کنید؛
5. یک Journey پرارزش را End-to-end تست کنید؛
6. Lost demand و Return reason را ساختاری کنید؛
7. Order-level contribution و Cohort را بسازید؛
8. یک Fix را با Rollout/Experiment و Guardrail ارزیابی کنید؛
9. Runbook و Owner هر Data/State را مستند کنید؛
10. بازبینی ماهانه Root cause و تصمیم را اجرا کنید.

چه زمانی بازطراحی لازم است؟

افت فروش به‌تنهایی مجوز Rebuild نیست. اگر Root cause یک PSP callback، موجودی Cache، Content gap یا Mobile form است، Repair متمرکز کم‌ریسک‌تر است. Replatform/Redesign وقتی موجه‌تر است که چند Journey اصلی، Content/IA، Data/Integration، Quality و Operating model به‌صورت ساختاری مانع‌اند و گزینه Configure/Repair/Pilot جواب نمی‌دهد.

برای تصمیم جامع از راهنمای تصمیم بازطراحی و بودجه استفاده کنید.

خطاهای رایج عیب‌یابی فروش کم

• GA4 purchase به‌عنوان پول قطعی؛
• Revenue بدون Refund/Contribution؛
• Funnel خطی بدون Order/Fulfillment؛
• Session زیاد به‌عنوان Demand مناسب؛
• Aggregate بدون Segment/Mix؛
• Price/Stock متفاوت در Feed/Page/Cart؛
• Product schema قدیمی؛
• Discount پیش از Offer diagnosis؛
• Cart abandonment benchmark به‌عنوان Target؛
• Payment failed/unknown در یک State؛
• Disable button به‌جای Idempotency؛
• Order بدون Reconciliation؛
• Return به‌عنوان یک Reason؛
• Experiment هنگام Incident؛
• Rebuild پیش از Root cause.

منابع و وضعیت زمانی

این راهنما در ۱۲ اوت ۲۰۲۶ بازبینی شده است. Event، Merchant policy، Payment و مقررات بازار تغییر می‌کنند؛ Version و Scope را ثبت و منابع جاری را بررسی کنید.

• Google Analytics: Measure ecommerce
• Google Search Central: Merchant listing structured data
• Google Merchant Center: Mismatched product price
• Google Merchant Center: Landing page requirements

سؤالات متداول فروش نداشتن فروشگاه

چرا فروشگاه بازدید دارد ولی فروش ندارد؟

Traffic ممکن است Intent/Region/Product نامناسب داشته باشد؛ Offer، Price/Stock/Delivery یا Product decision ضعیف باشد؛ Checkout/Payment Fail کند؛ یا Analytics فروش را غلط بسنجد. Session→Verified paid/delivered/contribution را Segment و Reconcile کنید.

از کجا بفهمیم مشکل سایت است یا محصول و بازار؟

Demand/query، eligibility و traffic quality را جدا از Product view→Cart→Payment بررسی کنید. اگر Audience واجد صفحه را می‌بیند و Evidence/Price/Stock/Delivery را رد می‌کند، Offer محتمل است؛ اگر Action می‌کند و System fail می‌شود، Journey فنی/عملیاتی محتمل‌تر است.

نرخ تبدیل خوب فروشگاه اینترنتی چقدر است؟

عدد جهانی مفیدی وجود ندارد؛ Category، Price، Channel، Device، Region، خرید تکراری و تعریف Conversion فرق می‌کنند. Baseline و Distribution خود را بسازید و Verified outcome، Contribution و Guardrail را در Segmentهای قابل‌مقایسه دنبال کنید.

چطور مشکل درگاه پرداخت را تشخیص دهیم؟

Payment initiated/redirected/authorized/captured/failed/cancelled/timeout/unknown/verified را ثبت و PSP را با Payment ledger و Order تطبیق دهید. سناریوی موفق، انصراف، قطع شبکه، Callback تکراری و PSP-paid/no-order را کنترل‌شده تست کنید.

آیا برای افزایش فروش باید سایت را بازطراحی کنیم؟

نه پیش از Root cause. Repair محتوا، قیمت/موجودی، Search، Form، Payment یا Operations ممکن است کافی باشد. Redesign/Replatform وقتی شواهد نشان دهد چند قابلیت و Journey به‌طور ساختاری گرفتار IA/Platform/Data/Quality/Operating model هستند.

جمع‌بندی: فروش یک Event نیست، زنجیره State و ارزش است

عیب‌یابی از یک Funnel زیبا شروع نمی‌شود؛ از تعریف Truth و تطبیق پول، سفارش، موجودی، تحویل و مرجوعی شروع می‌شود. سپس Demand، Offer، Product finding، Checkout و Operations را در Segment درست می‌سنجید و Fix را با Outcome و Guardrail ارزیابی می‌کنید.

همین امروز ده سفارش اخیر را از Analytics تا PSP، OMS، انبار و Finance دنبال کنید. اگر برای یک Order نمی‌توانید State، Amount، Owner و Evidence را توضیح دهید، بهترین نقطه شروع «تبلیغ بیشتر» نیست؛ ساختن یک Truth قابل‌اعتماد است.