فروشگاهی که اولین سفارش را میگیرد اما موجودی را کم نمیکند، پرداخت نامعلوم را موفق میزند یا مرجوعی را بلد نیست، هنوز «راهاندازی» نشده است. Launch واقعی یعنی یک مشتری بتواند محصول درست را پیدا کند، قیمت و شرایط را بفهمد، امن پرداخت کند، سفارش درست تحویل بگیرد و در صورت مشکل پاسخ و بازپرداخت قابل پیشبینی داشته باشد—و کسبوکار بداند از این سفارش سود یا یادگیری معنادار گرفته است.
این راهنما مسیر راهاندازی فروشگاه اینترنتی را از انتخاب محصول و مدل اقتصادی تا عملیات، پلتفرم، کاتالوگ، پرداخت، ارسال، انطباق، QA، Soft launch و ۱۰۰ سفارش نخست میسازد. هدف ساختن فهرست بزرگی از Featureها نیست؛ ساخت یک جریان کوچک اما کامل و قابلتطبیق است که Order، Money، Stock و Customer truth در آن با هم آشتی میکنند.
قبل از طراحی سایت: چه چیزی را به چه کسی و با چه اقتصاد واحدی میفروشید؟
«فروش آنلاین پوشاک» هنوز مدل کسبوکار نیست. باید Segment، Job، Assortment، منبع تأمین، مالک موجودی، قیمت، حاشیه، محدوده ارسال، Return policy، کانال جذب و توان عملیاتی را روشن کنید. فناوری بعد از این تصمیمها میآید؛ وگرنه پیچیدگی مبهم را فقط دیجیتال میکنید.
| مدل | سؤال مرکزی | پیچیدگی عملیاتی غالب | ریسک نسخه نخست |
|---|---|---|---|
| Inventory-led B2C | چه موجودیای را خودمان نگه میداریم؟ | خرید، ATP، انبار، ارسال و مرجوعی | Stockout/Overstock و سرمایه خوابیده |
| Dropship/تأمین پس از سفارش | Supplier چه تعهدی درباره قیمت و موجودی دارد؟ | Sync، SLA، بستهبندی و مالک تجربه | فروش کالای ناموجود یا تحویل دیر |
| Marketplace | Seller، Buyer، Platform و تسویه چه نقشی دارند؟ | Onboarding، Commission، Dispute، payout و fraud | اثر شبکه و انطباق چندطرفه |
| Digital goods | حق دسترسی و تحویل چگونه کنترل میشود؟ | License، download، access، refund و piracy | تحویل تکراری یا دسترسی غیرمجاز |
| Subscription | دوره، تمدید، Pause/Cancel و Failed payment چیست؟ | Lifecycle، entitlement، dunning و retention | Churn و تعهد مبهم |
| B2B | قیمت، اعتبار و Approval برای هر Account چیست؟ | Role، quote، credit، invoice، ERP و bulk order | منطق قراردادی پنهان |
| Service/Booking | ظرفیت، زمان، لغو و تحویل خدمت چگونه است؟ | Calendar، resource، reschedule و no-show | Double booking و ظرفیت اشتباه |
از «فروش» به Contribution هر سفارش برسید
GMV یا مبلغ سفارش سود نیست. یک مدل ساده برای هر سفارش نگهداشتهشده:
Contribution = درآمد خالص − بهای کالا − کارمزد پرداخت − بستهبندی − Fulfillment − یارانه ارسال − پشتیبانی متغیر − هزینه مورد انتظار مرجوعی/خرابی
درآمد خالص باید تخفیف، لغو و Refund را درست بازتاب دهد. هزینه جذب مشتری، هزینه ثابت تیم و زیرساخت را جدا نگه دارید و سپس Break-even را بسنجید. برای کالای مرجوعیپذیر، «Contribution per placed order» گمراهکننده است؛ Kept order و Return cohort را نیز ببینید.
| Metric | تعریف عملی | خطای رایج |
|---|---|---|
| AOV | درآمد سفارش / تعداد سفارش با تعریف لغو روشن | بالابردن با تخفیف زیانده |
| Gross margin | درآمد خالص منهای COGS | نادیدهگرفتن Fulfillment و Return |
| Contribution/order | درآمد پس از هزینههای متغیر قابل انتساب | ترکیب با Profit کامل شرکت |
| CAC | هزینه افزایشی جذب / مشتری جدید واجد شرایط | تقسیم Spend بر همه Orderها |
| Return rate | Order/item/value برگشتی با Definition مشخص | یک درصد برای همه Categoryها |
| Repeat rate | مشتری دارای خرید بعدی در Window تعریفشده | مقایسه Cohortهای نابرابر |
| Break-even volume | هزینه ثابت / Contribution متوسط سناریویی | استفاده از Average خوشبینانه |
Assumption ledger بسازید
فرضهایی مانند «مشتری هزینه ارسال را میپردازد»، «تأمینکننده موجودی لحظهای میدهد» یا «مرجوعی زیر ۵٪ است» باید Owner، Evidence، Confidence و تاریخ آزمون داشته باشند. Version نخست برای آزمودن فرض پرریسک است، نه برای اثبات پیشبینی بنیانگذار.
فروشگاه یک سایت نیست؛ زنجیره Order-to-Cash-to-Return است
Journey مشتری و عملیات پشت آن را روی یک Service blueprint قرار دهید. هر مرحله Trigger، Actor، Data، System of Record، State، Exception، Owner، SLA و Evidence دارد.
| مرحله | Frontstage مشتری | Backstage عملیات | حقیقت لازم | شکست نمونه |
|---|---|---|---|---|
| Discover | جستوجو/دسته/کمپین | Feed، SEO، merchandising | Product eligibility و availability | تبلیغ کالای ناموجود |
| Decide | PDP، مقایسه و سیاست | Catalog، price و content governance | SKU/Variant/price/policy | قیمت یا Variant مبهم |
| Commit | Cart، address، shipping، checkout | Quote، stock reservation و risk check | مبلغ نهایی و ATP | تغییر هزینه در آخرین مرحله |
| Pay | انتقال، نتیجه و رسید | Create intent، callback، verify و reconcile | Payment state | Callback موفق بدون Verify |
| Allocate | تأیید سفارش | Reserve/allocate موجودی | Order/Inventory state | فروش آخرین واحد دوباره |
| Fulfill | پیگیری آمادهسازی | Pick، Pack، QA و label | Item/parcel identity | کالای اشتباه در بسته |
| Deliver | رهگیری و دریافت | Handover، carrier event و exception | Delivery state/time | «ارسال شد» بدون تحویل واقعی |
| Recover | لغو، Return، refund و support | Eligibility، inspection، restock و refund | Return/refund state | Refund بدون تطبیق مالی |
| Learn | Review/خرید بعدی | Event/order/payment/finance reconciliation | Outcome/quality truth | Revenue Analytics با حسابداری ناسازگار |
System of Record را برای هر Domain مشخص کنید
اگر سایت قیمت را میگوید، ERP موجودی را و پنل درگاه پرداخت را، باید معلوم باشد در اختلاف کدام مرجع حق دارد و Sync/Reconciliation چگونه عمل میکند. «دوطرفه و Real-time» Requirement نیست؛ Direction، latency، idempotency، retry، duplicate، unknown state و recovery را تعریف کنید.
| Domain truth | Owner نمونه | کلید تطبیق | Reconciliation |
|---|---|---|---|
| Product/SKU/Variant | PIM/Commerce | SKU/GTIN/Variant ID | Catalog diff و exception |
| Price/Promotion | Commerce/Pricing | Price list + rule version | Display/Cart/Invoice match |
| Inventory/ATP | WMS/ERP | SKU×location | On-hand/reserved/available |
| Order | OMS/Commerce | Order ID | Item/amount/state totals |
| Payment | PSP/Gateway + ledger | Order/payment/reference ID | Initiated/verified/settled/refunded |
| Delivery | Carrier/WMS | Parcel/tracking ID | Handover/event/exception |
| Finance | Accounting | Invoice/settlement/refund | Daily order-to-cash close |
Scope نسخه نخست: یک جریان کامل، نه یک Feature list بلند
MVP فروشگاه باید کمترین Scopeای باشد که Value و Risk اصلی را در عملیات واقعی میآزماید. «فقط Home و Product page» MVP نیست اگر سفارش پس از پرداخت دستی گم شود. از Business model و Journey به Requirement بروید: Trigger، Actor، Data، Rule، State، Owner، Acceptance و Metric. برای تعریف عمیق قابلیتها، چکلیست امکانات فروشگاه اینترنتی را مبنا قرار دهید.
| Must برای Pilot | مشروط به مدل | اغلب قابل تعویق |
|---|---|---|
| Catalog truth، Product/Variant، Cart/Quote، Checkout، Payment state، Order، Inventory rule، Shipping، Policy، Admin، Log و Support | Account، Wishlist، Coupon، Review، Multi-warehouse، ERP، Subscription، B2B role، Marketplace settlement | Gamification، Recommendation پیچیده، Loyalty چندسطحی، App native، Personalization گسترده، Automation بدون داده |
پلتفرم را بعد از Knockout انتخاب کنید
SaaS ایرانی، WooCommerce خودمیزبان، Headless/Composable یا توسعه اختصاصی هیچکدام ذاتاً بهترین نیستند. ابتدا Knockoutهای Eligibility، Data ownership، Payment/Shipping integration، Product model، Role، Security، Scale، Operations و Exit را بسنجید؛ سپس TCO و Pilot. Demo زیبا، قابلیت Exception/Refund/Export را ثابت نمیکند. راهنمای انتخاب پلتفرم فروشگاهی با TCO و Pilot این تصمیم را عمیق میکند.
| معیار Platform | سؤال | Evidence پیش از قرارداد |
|---|---|---|
| Commerce fit | Variant، price، stock، return و role شما را مدل میکند؟ | سناریوی واقعی، نه Demo happy path |
| Ownership | Account، Domain، Code، Data و Analytics با کیست؟ | دسترسی سازمانی و بند قرارداد |
| Integration | API/Webhook/Sandbox/Limit/Retry چگونهاند؟ | Spike و contract test |
| Operations | چه کسی Patch، Backup، Monitor و Incident را اداره میکند؟ | RACI، SLA و restore drill |
| Scale | Peak journey تا کجا و با چه هزینهای پاس میشود؟ | Load/soak test و limit sheet |
| Exit | Product/Customer/Order/Media/Redirect چگونه خارج میشوند؟ | Export sample و restore مقصد دوم |
کاتالوگ و صفحه محصول: Product truth را پیش از ورود انبوه بسازید
محصول، Variant و Offer را جدا کنید. یک مدل کفش میتواند Product باشد، سایز/رنگ Variant و قیمت/موجودی یک فروشنده Offer. اگر این مرزها مبهم باشند، فیلتر، URL، موجودی، Schema، Feed، Cart و گزارش با هم ناسازگار میشوند.
| Field | قاعده | Owner | Acceptance |
|---|---|---|---|
| SKU/ID | پایدار، یکتا و مستقل از عنوان | Catalog/ERP | Duplicate صفر و mapping کامل |
| Title | Brand+model+attribute تمایزبخش، طبیعی | Content | قابل تشخیص در list/receipt |
| Variant | Attribute کنترلشده با ترکیب معتبر | Merchandising | انتخاب و URL/state بدون ابهام |
| Price | واحد ریال/تومان، تخفیف و اعتبار زمانی روشن | Pricing | PDP=Cart=Payment=Invoice |
| Inventory | On-hand، reserved، available و backorder rule | Operations | ATP با سفارش همزمان |
| Media | واقعی، مجاز، نسبت/کیفیت و Alt متناسب | Content | نمونه موبایل و Variant درست |
| Specification | Dictionary یکسان در Category | Category owner | Comparison/filter coverage |
| Shipping/Return | شرط قابل فهم پیش از Commit | Legal/Ops | سازگار با Checkout و Policy |
Content باید تردید خرید را کم کند
عکس، اندازه/ابعاد، جنس، سازگاری، محتویات بسته، کاربرد/محدودیت، ضمانت، زمان آمادهسازی و Return condition را متناسب با کالا بدهید. کپی متن Supplier تمایز و شاهد تجربه شما نیست. FAQ باید از سؤال واقعی Support/Sales بیاید و اطلاعات حیاتی را پشت Accordion یا تصویر غیرقابل جستوجو پنهان نکند.
Category، Filter و Search را با داده واقعی طراحی کنید
Taxonomy از مدل ذهنی مشتری و Assortment میآید، نه نمودار سازمان. Filter فقط Attributeهایی را نشان دهد که Coverage و ارزش تصمیم دارند. Empty state، typo، Persian/Arabic ی/ک، فاصله، Brand synonym و عدد را در Search داخلی بیازمایید. Result صفر باید Recovery بدهد، نه بنبست.
Cart و Checkout: Quote قابل اعتماد بسازید
Cart یک فهرست موقت نیست؛ Quote شامل Item/Variant، quantity، unit price، discount، shipping، tax/fee، total، currency، availability و expiry است. قیمت و هزینه نهایی را پیش از رفتن به درگاه روشن کنید. Checkout فیلد و مرحله را بر اساس Risk و Fulfillment لازم نگه دارد، نه علاقه هر واحد به جمعآوری داده.
| مرحله | Requirement | Failure test |
|---|---|---|
| Cart | Price/stock revalidation و پیام تغییر قابل فهم | قیمت یا موجودی بین Add و Pay تغییر کند |
| Identity | Guest/Account متناسب و Recovery امن | OTP دیر/تکراری یا Account موجود |
| Address | استان/شهر/کدپستی/جزئیات و Validation قابل اصلاح | آدرس ناقص یا محدوده خارج سرویس |
| Shipping | هزینه، Promise و شرط قبل از پرداخت | Carrier یا Zone نرخ ندهد |
| Review | Item، مبلغ، Policy و Action نهایی واضح | Double submit یا Back/refresh |
| Payment | Intent، callback، server verify، idempotency و unknown | Timeout، callback تکراری و مبلغ mismatch |
| Confirmation | Order/reference، next step و support | پرداخت موفق اما صفحه نتیجه قطع |
برای کاهش اصطکاک و طراحی Recovery از راهنمای بهینهسازی Checkout استفاده کنید.
پرداخت را با State machine و Reconciliation اداره کنید
Redirect کاربر یا Callback بهتنهایی منبع حقیقت نیست. Server-to-server verification، مبلغ/Order match، Idempotency، timeout، retry محدود، وضعیت Unknown و Reconciliation روزانه لازماند. Success payment، paid order، settled money و refunded order حالتهای جدا هستند. جزئیات در راهنمای اتصال امن درگاه پرداخت آمده است.
صفحه پرداخت و Scriptهای مؤثر بر آن هدف E-skimming هستند. PCI SSC در راهنمای ۲۰۲۵ بر مدیریت Scriptهای صفحه پرداخت و تشخیص تغییر تأکید کرده است؛ Scope دقیق انطباق را با Acquirer/PSP و متخصص مربوط تعیین کنید. منبع: PCI SSC payment page security guidance.
موجودی، Fulfillment، ارسال و مرجوعی را پیش از تبلیغ تمرین کنید
On-hand با Available-to-Promise یکی نیست: ATP = On-hand − Reserved − unavailable + inbound قابل اتکا با قواعد متناسب کسبوکار. آخرین واحد، سفارش همزمان، لغو، timeout پرداخت و Return-to-stock را تست کنید. ارسال نیز فقط انتخاب نام Carrier نیست؛ Cut-off، Zone، package، label، handover، tracking، exception و Proof of delivery دارد.
| سناریو | تصمیم لازم | Evidence |
|---|---|---|
| آخرین واحد | Reserve در چه State و چند دقیقه؟ | Concurrency test و inventory ledger |
| پرداخت Unknown | Stock آزاد شود یا hold بماند؟ | Timeout/reconcile runbook |
| Split shipment | هزینه/پیام/وضعیت چند بسته چیست؟ | Order/parcel state test |
| آدرس نامعتبر | قبل یا بعد پرداخت چگونه اصلاح میشود؟ | Exception queue و contact SLA |
| تحویل ناموفق | Retry، Return-to-origin و هزینه با کیست؟ | Carrier event mapping |
| مرجوعی | Eligibility، inspection، disposition و refund چیست؟ | RMA/return/refund reconciliation |
برای طراحی SKU، ATP/Reservation، Pick-Pack، Carrier، Return و اقتصاد Kept order، راهنمای انبار و Fulfillment فروشگاه را ببینید.
قانون، مجوز، مالیات و اعتماد را به Requirement تبدیل کنید
این بخش مشاوره حقوقی یا مالیاتی نیست. الزامها به نوع کالا/خدمت، شخصیت، محل، روش پرداخت، مخاطب و تغییر مقررات وابستهاند. بهجای کپی یک Checklist عمومی، Legal applicability matrix بسازید: الزام، مرجع، دامنه، Owner، Product requirement، Evidence، تاریخ بررسی و Trigger تغییر.
| حوزه | سؤال | Requirement محصول/عملیات نمونه | مرجع تصمیم |
|---|---|---|---|
| هویت/مجوز | برای فعالیت و کالای ما چه مجوزی لازم است؟ | هویت واقعی، شماره/اعتبار و دامنه منطبق | مرجع رسمی/متخصص |
| اطلاعات قبل خرید | چه چیزی باید قبل از Commit روشن باشد؟ | هویت، کالا، مبلغ نهایی، ارسال، محدودیت و تماس | قانون/Policy جاری |
| لغو/مرجوعی | حق، استثنا، زمان و هزینه چیست؟ | Policy، Eligibility، درخواست و Evidence | قانون و Category rule |
| حریم خصوصی | چه دادهای برای چه Purpose و مدت لازم است؟ | Inventory، notice، consent لازم، access/deletion route | الزام جاری/مشاور |
| مالیات/صورتحساب | ثبتنام، صورتحساب و گزارش چگونهاند؟ | Tax identity، invoice data و reconciliation | سازمان/متخصص مالیاتی |
| پرداخت | پذیرندگی، تسویه و dispute چه شرطی دارد؟ | Merchant truth، state و settlement evidence | PSP/پرداختیار/شاپرک |
| کالای محدود | فروش/تبلیغ/ارسال چه محدودیتی دارد؟ | Eligibility، age/location check و block | تنظیمگر تخصصی |
وضعیت جاری را در سامانه رسمی اینماد، درگاه ملی مجوزها و وبسایت شاپرک بررسی کنید و برای تصمیم حقوقی/مالیاتی به متخصص مرتبط رجوع کنید. راهنمای جامعتر تبدیل قانون ایران به Product requirement در الزامات حقوقی فروشگاه اینترنتی ایران است.
Trust badge جای شفافیت و عملکرد را نمیگیرد
مشتری باید نام و راه تماس واقعی، قیمت و واحد پول، موجودی، زمان/هزینه ارسال، شرایط ضمانت/بازگشت، Privacy، پشتیبانی و وضعیت سفارش را بفهمد. Badge منقضی، تصویر غیرقابل کلیک یا ادعای «۱۰۰٪ امن» اعتماد نمیسازد. Trust promise باید با عملیات پس از پرداخت همخوان باشد.
امنیت، حریم خصوصی و دسترسپذیری از روز نخست
Threat model فروشگاه شامل Account takeover، Credential stuffing، Abuse coupon، Bot/Inventory hoarding، Card testing، Injection/XSS، Dependency compromise، Admin misuse، PII exposure و Fraud/Refund abuse است. MFA ادمین، Least privilege، Secret management، Patch، WAF/rate limit متناسب، Audit log، Backup/restore، incident runbook و امنسازی Integration را در Scope بگذارید.
داده را با Purpose و Retention جمع کنید. CVV/اطلاعات کارت را در سایت ذخیره نکنید؛ Boundary دقیق پرداخت را با Provider رسمی مشخص کنید. Log نیز میتواند PII/Token داشته باشد؛ Redaction و Access لازم است.
Keyboard، Focus، Label، Error identification، Target size، Redundant entry و Accessible authentication در Checkout اهمیت عملی دارند. WCAG ۲.۲ معیارهایی درباره Focus not obscured، Target size، Redundant entry و Accessible authentication اضافه کرده است. منبع: W3C: What’s New in WCAG 2.2.
SEO و Product data را پیش از ورود هزار محصول طراحی کنید
Category/Subcategory/PDP باید با لینک واقعی قابل پیمایش باشند؛ Search box بهتنهایی Discovery موتور جستوجو را تضمین نمیکند. URL/Facet/Variant/Canonical، Pagination، Out-of-stock/Discontinued و Redirect policy را قبل از Scale روشن کنید. Google نیز بر لینک از Menu→Category→Subcategory→Product تأکید دارد. منبع: Google ecommerce site structure.
Product، Offer، price، availability، shipping و return در صفحه، Structured data، Feed و Analytics باید از Product truth یکسان بیایند. Structured data فهم را کمک و Eligibility نمایش غنی را افزایش میدهد، اما نمایش تضمین نیست و تجربهها با کشور/Device متفاوتاند. منبع: Google ecommerce structured data. برای معماری کامل Catalog/Facet/Variant/Schema/Feed/Crawl و Margin، راهنمای سئو فروشگاه اینترنتی را ببینید.
QA فروشگاه: Happy path فقط یک ردیف ماتریس است
| لایه | سناریوهای حداقلی | Acceptance |
|---|---|---|
| Product/Catalog | Variant، unavailable، price change، media و filter | Truth در List/PDP/Cart/Admin یکسان |
| Cart/Promotion | quantity، coupon conflict، expiry و rounding | Total بازسازیپذیر و Explainable |
| Checkout | Guest/account، address error، shipping failure و duplicate submit | داده حفظ و خطا قابل اصلاح |
| Payment | success، failure، cancel، timeout، duplicate callback و unknown | Order/payment state و reconciliation درست |
| Inventory | last unit، concurrent order، cancel و return | No oversell یا policy کنترلشده |
| Fulfillment | partial، damaged، wrong item و carrier exception | Owner/SLA/communication روشن |
| Return/Refund | eligible/ineligible، partial، failed refund و restock | Customer/Order/Payment/Finance همخوان |
| Security/Access | role، MFA، brute force، secret/log و permission | Least privilege و audit evidence |
| Performance/A11y | mobile/slow network/keyboard/error/focus | Critical journey usable |
| SEO/Analytics | HTTP، index، canonical، schema، event و duplicate purchase | Public HTML و data reconciliation |
Soft launch را بهعنوان Pilot عملیاتی اجرا کنید
Google برای راهاندازی Ecommerce گزینههایی مانند Grand reveal، Home-only، عرضه پیش از موجودشدن و Soft launch را توضیح میدهد. Soft launch اجازه میدهد سایت Production-ready با ترافیک محدود آزموده و رویداد بازاریابی بزرگتر بعداً اجرا شود. انتخاب باید با Confidentiality، Index timing و Ops capacity هماهنگ باشد. منبع: Google: How to launch an ecommerce website.
در Pilot، دامنه و حساب واقعی، درگاه Production با سفارش کمریسک، Carrier واقعی و تیم Support واقعی را بسنجید. Test environment برای QA لازم است ولی Settlement، پیامک، Route و رفتار کاربر Production را کامل شبیهسازی نمیکند.
از سفارش صفر تا ۱۰۰: Gateهای رشد
| بازه | هدف | کار | Gate پیش از Scale |
|---|---|---|---|
| ۰ تا ۱۰ سفارش | اثبات End-to-end correctness | Founder/ops watch، تماس پس از سفارش، reconcile روزانه | هیچ پول/Order/Stock گم نیست؛ Incident owner روشن |
| ۱۱ تا ۳۰ | کشف Exception و زمان عملیات | دسته/آدرس/پرداخت/ارسال متنوع، ticket coding | Return/refund/support و fulfillment SLA قابل اجرا |
| ۳۱ تا ۶۰ | اثبات Repeatability | Runbook، shift handoff، cohort و contribution review | کیفیت با Volume افت نمیکند؛ Unit economics قابل توضیح |
| ۶۱ تا ۱۰۰ | آزمون Capacity و Channel fit | کمپین کنترلشده، load/stock/support guardrail | Error/late delivery/return/refund/CAC در محدوده تصمیم |
| پس از ۱۰۰ | انتخاب Scale lever | Automation/assortment/channel/retention بر اساس bottleneck | Hypothesis، owner، guardrail و rollback |
«۱۰۰» عدد جادویی یا آستانه آماری عمومی نیست؛ یک ظرف عملی برای نظمدادن یادگیری است. اگر هر Order ارزش بالا یا چرخه بلند دارد، Gateها را بر Evidence نه Count تنظیم کنید. تبلیغ را زمانی زیاد کنید که عملیات قادر به Fulfill و Recover باشد؛ CAC پایین با تأخیر، لغو و مرجوعی بالا رشد نیست.
اندازهگیری: Event را با Order، Payment و Finance آشتی دهید
GA4 رویدادهای View item/list، Add/remove cart، Begin checkout، Purchase، Refund و Promotion را برای Ecommerce تعریف میکند. Event client-side برای رفتار مفید است، اما منبع حقیقت درآمد نیست؛ Ad blocker، duplicate، network و implementation error وجود دارند. منبع: Google Analytics ecommerce measurement.
| لایه | Metric | منبع حقیقت | Guardrail |
|---|---|---|---|
| Acquisition | Qualified session/CAC | Ads/Analytics/CRM | Brand mix و incrementality |
| Discovery | Search success، filter use، zero result | Product analytics | Latency و dead end |
| Decision | PDP→Cart by item/variant | Events + catalog | Out-of-stock و price cohort |
| Checkout | Step completion/error | Events + server log | Payment/technical failure |
| Commerce | Placed/paid/fulfilled/delivered/kept | OMS/WMS/payment | Cancel، return، refund |
| Economics | Contribution/CAC/payback | Finance + operations | Shipping subsidy و support |
| Quality | Wrong item، late، contact و CSAT | Support/operations | Complaint severity |
| Reliability | Journey success/latency/error | Synthetic/APM/log | Incident/error budget |
Dashboard قیفی بدون Diagnosis کافی نیست
افت Purchase میتواند از Traffic mix، موجودی، قیمت، UI، Payment، Carrier یا Event باشد. هر Metric را با Dimensionهای Channel، Device، Category، SKU، Location، new/repeat، fulfillment method و release annotation تحلیل کنید. عدد کل گلوگاه را پنهان میکند.
بهینهسازی UX بعد از اطمینان از Truth
ابتدا خطا، تناقض و Dead end را رفع کنید؛ سپس Hypothesisهای Discoverability، Comparison، Trust، Form و Recovery را آزمایش کنید. Dark pattern، Preselection پنهان یا Scarcity ساختگی ممکن است Metric کوتاهمدت را بالا و Refund/Complaint/Trust را خراب کند. برای عیبیابی Journey خرید، راهنمای UX فروشگاه اینترنتی را ببینید.
برنامه ۶۰روزه راهاندازی فروشگاه اینترنتی
| بازه | کار | خروجی | Gate |
|---|---|---|---|
| روز ۱ تا ۵ | Segment/Job، مدل، assortment، economics و risk | Commerce charter + assumption ledger | یک Value/Risk اصلی انتخاب شده |
| روز ۶ تا ۱۰ | Service blueprint و Domain truth | Order-to-return map + SoR | State/Owner/Exception روشناند |
| روز ۱۱ تا ۱۵ | Legal applicability، payment/shipping/provider eligibility | Requirement/official-check register | Knockout حل یا تصمیم No-go |
| روز ۱۶ تا ۲۰ | Platform options، TCO، exit و spike | Evidence-weighted selection | Happy/exception/export Pilot شده |
| روز ۲۱ تا ۲۷ | Catalog dictionary، IA، content sample و SEO | نمونه Category/PDP/Variant | Truth و comparison پایدار |
| روز ۲۸ تا ۳۵ | Cart/Checkout/Payment/Order/Inventory/Shipping | End-to-end slice | Success/failure/unknown/reconcile پاس |
| روز ۳۶ تا ۴۱ | Admin، support، return/refund، security و backup | Ops console + runbook | تیم دریافتکننده مستقل کار میکند |
| روز ۴۲ تا ۴۷ | Analytics، schema، feed، monitoring و alert | Event/order/finance map | Duplicate/missing data معلوم است |
| روز ۴۸ تا ۵۲ | Functional/load/a11y/security/recovery QA | Acceptance evidence و defect burn-down | Critical defect صفر و rollback آماده |
| روز ۵۳ تا ۶۰ | Soft launch، ۱۰ سفارش واقعی و review | Go/hold/iterate decision | Order/Money/Stock/Customer truth آشتی دارند |
چکلیست نهایی پیش از Launch
- Segment، Job، Assortment و مدل Inventory/Dropship/Marketplace/B2B روشناند.
- Contribution، CAC scenario، Return cost و Break-even با فرض ثبتشده داریم.
- Journey از Discover تا Return و Learn، Owner/SLA/Exception دارد.
- Product، Price، Inventory، Order، Payment، Delivery و Finance هرکدام System of Record دارند.
- MVP یک جریان کامل است؛ Featureهای بدون Evidence به Backlog رفتهاند.
- Platform با Knockout، TCO، Ops fit، Pilot و Exit انتخاب شده است.
- SKU/Variant/Offer، Taxonomy، Attribute و Content dictionary پایدارند.
- PDP قیمت، موجودی، ویژگی، ارسال، بازگشت و محدودیت را شفاف نشان میدهد.
- Cart یک Quote قابل بازسازی و Checkout خطاپذیر اما قابل Recovery است.
- پرداخت Success/Failure/Cancel/Timeout/Duplicate/Unknown/Refund را درست مدیریت میکند.
- ATP/Reservation، آخرین واحد، لغو، Fulfillment، Delivery exception و Return تست شدهاند.
- مجوز/مالیات/حقوق مصرفکننده/حریم خصوصی از مراجع رسمی و متخصص بررسی شدهاند.
- Admin MFA، Least privilege، Patch، Log، Backup/Restore و Incident runbook دارد.
- Checkout روی موبایل، Keyboard، Slow network و پیام خطای فارسی قابل استفاده است.
- Category→PDP لینکپذیر و Product/Page/Schema/Feed truth همخواناند.
- Eventهای View→Cart→Checkout→Purchase→Refund با Order/Payment/Finance تطبیق میشوند.
- Soft launch دارای Guardrail، Stop condition، Owner و Rollback است.
- تبلیغ گسترده تا اثبات Fulfillment/Support/Recovery و اقتصاد واحد متوقف میماند.
سؤالات متداول
برای راهاندازی فروشگاه اینترنتی از کجا شروع کنیم؟
از Segment/Job، مدل فروش، Assortment، تأمین، Unit economics و عملیات Order-to-return شروع کنید؛ سپس Scope و پلتفرم. خرید قالب یا ورود انبوه محصول پیش از Product truth و جریان عملیات، دوبارهکاری میسازد.
برای شروع چند محصول لازم است؟
عدد ثابتی وجود ندارد. مجموعهای لازم است که تنوع واقعی Category، Variant، قیمت، موجودی، بستهبندی، ارسال و مرجوعی را بیازماید. برای بعضی B2Bها پنج محصول پیچیده از صد SKU ساده آموزندهتر است. Coverage ریسک را معیار قرار دهید.
فروشگاه را با WooCommerce، سایتساز یا توسعه اختصاصی بسازیم؟
بر اساس Commerce fit، Integration، Data ownership، Operations، Security، Scale، TCO و Exit تصمیم بگیرید. سناریوی واقعی Checkout/Refund/Export را Pilot کنید؛ برچسب پلتفرم یا قیمت شروع پاسخ عمومی نمیدهد.
برای فروشگاه اینترنتی در ایران چه مجوزی لازم است؟
به نوع کالا/خدمت، شخصیت، فعالیت، روش پرداخت و مقررات جاری وابسته است. وضعیت را در اینماد، درگاه ملی مجوزها، شاپرک و مرجع تخصصی مربوط بررسی و برای تصمیم الزامآور از مشاور حقوقی/مالیاتی استفاده کنید. Checklist ثابت اینترنتی کافی نیست.
چه زمانی تبلیغات و سئو را شروع کنیم؟
IA، URL، Product data و Measurement از ابتدای طراحی؛ جذب گسترده پس از عبور جریان واقعی از پرداخت، موجودی، Fulfillment، Support و Return. Soft launch با ترافیک محدود هم Index/یادگیری را آغاز میکند و هم جلوی Scale خطای عملیاتی را میگیرد.
جمعبندی
راهاندازی فروشگاه اینترنتی زمانی کامل است که Order، Money، Stock و Customer truth در تمام مسیر از Product تا Refund قابل ردیابی و تطبیق باشند. ابتدا مدل اقتصادی و عملیات را بسازید، سپس یک End-to-end slice را روی پلتفرم مناسب اجرا کنید، انطباق و امنیت را به Requirement تبدیل کنید، Failureها را بیازمایید و با Soft launch ظرفیت واقعی را کشف کنید. رشد بعد از ۱۰۰ سفارش هم افزودن Feature نیست؛ رفع گلوگاهی است که با Outcome و Guardrail ثابت شده است.
