واقعیت افزوده زمانی برای فروشگاه ارزش دارد که یک ابهام مشخص خرید را کم کند: «این مبل در فضای من جا میشود؟»، «این عینک روی صورت چگونه دیده میشود؟» یا «این دستگاه نسبت به میز من چه ابعادی دارد؟». اگر مدل سهبعدی مقیاس یا رنگ نادرست داشته باشد، قابلیت AR میتواند بهجای اعتماد، انتظار غلط و مرجوعی بیشتر بسازد.
پاسخ کوتاه: AR را برای همه محصولات و با وعده افزایش قطعی فروش اجرا نکنید. یک دسته با عدمقطعیت دیداری/ابعادی بالا انتخاب کنید، دارایی 3D دقیق بسازید، مسیرهای WebXR/Quick Look و Fallback را روی دستگاه واقعی تست کنید، اجازه دوربین و داده را حداقلی نگه دارید و اثر را با Experiment روی کل کاربران واجد شرایط بسنجید. در بسیاری از فروشگاهها، Viewer سهبعدی خوب پیش از AR کامل ارزش ایجاد میکند.
Snapshot فنی: این راهنما در ۶ اوت ۲۰۲۶ بازبینی شده است. WebXR Device API در این تاریخ همچنان Candidate Recommendation Draft است؛ پشتیبانی Browser/OS/Device و مسیرهای Native تغییر میکند. Compatibility را با Feature detection و Device lab خود بسنجید، نه جدول ثابت اینترنتی.
AR، 3D Viewer و پرو مجازی را جدا کنیم
| تجربه | کاری که میکند | نیاز اصلی | محدودیت |
|---|---|---|---|
| 3D Viewer | چرخش و Zoom محصول روی صفحه | مدل سهبعدی و Renderer | محصول را در محیط واقعی نشان نمیدهد |
| Placement AR | قرار دادن شیء روی سطح/فضا | Tracking، Scale و Grounding | ابعاد مدل و تشخیص سطح باید دقیق باشد |
| Face try-on | قرار دادن عینک/آرایش روی چهره | Landmark و Calibration | نور، پوست، دوربین و Privacy اثرگذارند |
| Body try-on | نمایش لباس/اکسسوری روی بدن | Pose، Garment model و Fit logic | ظاهر را نشان میدهد؛ الزاماً اندازه مناسب را نه |
| 3D Configurator | رنگ، جنس یا قطعه را تغییر میدهد | Variant mapping و Rule | قیمت/موجودی باید با Catalog همگام شود |
| AR measurement | فاصله یا ابعاد را تخمین میزند | Sensor/Calibration | جای ابزار اندازهگیری دقیق را نمیگیرد |
AR با VR نیز فرق دارد: AR محتوای دیجیتال را با محیط واقعی ترکیب میکند؛ VR کاربر را در محیط مجازی قرار میدهد. برای خرید موبایلی، اصطکاک ورود و سازگاری مهمتر از برچسب فناوری است.
کدام مسئله کسبوکار ارزش AR دارد؟
از Feature شروع نکنید؛ از Decision مشتری شروع کنید. یک Hypothesis خوب این ساختار را دارد:
اگر مشتری بتواند اندازه و سبک مبل را در اتاق خود ببیند، عدمقطعیت ابعاد کاهش مییابد؛ بنابراین تکمیل خرید در کاربران دستگاه سازگار بیشتر و مرجوعی با دلیل «اندازه نامناسب» کمتر میشود، بدون اینکه زمان بارگذاری یا نرخ خطا بدتر شود.
Use case قوی
- ابعاد و تناسب فضایی واقعاً در انتخاب مهم است؛
- ظاهر محصول از چند زاویه روی تصمیم اثر دارد؛
- مرجوعی Reason code مرتبط با رنگ/اندازه/تناسب دارد؛
- SKU عمر و حاشیه کافی برای جبران هزینه 3D دارد؛
- تعداد Variant قابلمدیریت و داده Catalog سالم است؛
- بخش معناداری از کاربران دستگاه و شبکه سازگار دارند.
Use case ضعیف
- محصول Commodity کمقیمت و تصمیم بسیار ساده است؛
- داده اندازه، تصویر و موجودی فعلی ناقصاند؛
- عامل اصلی ریزش هزینه ارسال، اعتماد یا پرداخت است؛
- SKUها بسیار زود عوض میشوند و Asset قابلبازیافت نیست؛
- AR فقط برای نمایش نوآوری خواسته شده و KPI ندارد.
اگر صفحه محصول اطلاعات پایه، تصویر، اندازه یا ارسال ضعیفی دارد، ابتدا مسائل Journey را با راهنمای UX فروشگاه اینترنتی اصلاح کنید.
واقعیت افزوده فروشگاهی چه چیزی را تضمین نمیکند؟
عددهای Conversion یک فروشگاه یا گزارش فروشنده را نمیتوان به همه دستهها تعمیم داد. کاربرانی که داوطلبانه AR را باز میکنند معمولاً Intent بالاتری دارند؛ مقایسه آنها با کاربران دیگر Selection bias ایجاد میکند.
| ادعا | چرا قطعی نیست؟ | روش اثبات |
|---|---|---|
| AR نرخ تبدیل را بالا میبرد | Novelty، Intent و Category متفاوتاند | Randomized experiment روی Eligible users |
| مرجوعی را کم میکند | مرجوعی ممکن است از کیفیت یا ارسال باشد | Return rate با Reason code و Window کافی |
| وفاداری میسازد | استفاده یکباره با Retention فرق دارد | Cohort و خرید مجدد با Guardrail |
| مقیاس واقعی نشان میدهد | Unit، Bounding box و Tracking ممکن است خطا داشته باشد | QA با شیء فیزیکی و چند Device |
| WebAR برای همه کار میکند | Browser/OS/API/Permission متفاوت است | Feature detection و Device matrix |
معماری تجربه AR در وب
یک صفحه محصول میتواند ابتدا Thumbnail و 3D Viewer را نشان دهد و سپس با تعامل کاربر وارد حالت AR شود. بسته به دستگاه، تجربه داخل Browser یا Viewer بومی باز میشود.
| مسیر | دارایی متداول | مزیت | محدودیت |
|---|---|---|---|
| Inline 3D | glTF/GLB | Fallback گسترده و قابلکنترل | AR محیطی نیست |
| WebXR immersive-ar | glTF/GLB + Web app | تجربه داخل Web و Interaction سفارشی | Support و Featureها وابسته به UA/Device |
| Android Scene Viewer | glTF/GLB | Viewer Native در دستگاه سازگار | Context switch و کنترل کمتر |
| Apple Quick Look | USDZ | مسیر بومی iPhone/iPad | قابلیت/Integration متفاوت از WebXR |
| App اختصاصی | Asset/SDK پلتفرم | کنترل و Feature بیشتر | هزینه نصب، توسعه و نگهداری |
WebXR Device API جریان بررسی پشتیبانی و درخواست Session با اقدام کاربر را تعریف میکند؛ خود سند وضعیت Draft دارد. بنابراین تجربه باید قبل از نمایش CTA، قابلیت را تشخیص دهد و در خطا به 3D/تصویر برگردد.
const supported =
navigator.xr &&
await navigator.xr.isSessionSupported('immersive-ar');
showArButton(supported);
show3dFallback(true);
این فقط Feature detection ساده است؛ HTTPS، Permission، Hit test، DOM overlay و Device capability هرکدام Test جدا میخواهند.
glTF/GLB و USDZ؛ یک Master، چند خروجی
glTF Registry از Khronos، glTF را قالب تحویل Runtime دارایی سهبعدی تعریف میکند. GLB بسته Binary آن است و برای Web/Android رایج است. Apple Quick Look فایل USDZ را نمایش میدهد؛ مستندات Apple Quick Look نمونه و مسیر وب را ارائه میکند.
یک فایل را Master تولید تلقی نکنید. Pipeline بهتر:
- Source با بالاترین کیفیت: CAD، Scan، Photogrammetry یا Modeling؛
- Master دارای Unit، Material، Naming و Variant مشخص؛
- نسخه تحویل Web در GLB/glTF با Texture و Geometry بهینه؛
- نسخه USDZ برای Quick Look در صورت نیاز؛
- Thumbnail و تصویر ۳۶۰ برای Fallback؛
- Metadata نسخه، SKU، Dimension و QA status.
کیفیت مدل سهبعدی؛ زیبا کافی نیست
| بعد کیفیت | سؤال QA | اثر خطا |
|---|---|---|
| Scale/Unit | سانتیمتر/متر و Bounding box درست است؟ | انتظار اشتباه از اندازه |
| Origin/Pivot | روی کف/دیوار درست قرار میگیرد؟ | شناوری یا فرو رفتن |
| Geometry | Silhouette و جزئیات ضروری حفظ شده؟ | ظاهر نادرست یا فایل سنگین |
| Material/PBR | زیر نورهای مختلف طبیعی است؟ | رنگ و جنس گمراهکننده |
| Texture | Resolution/Color space مناسب است؟ | Blur، Banding یا مصرف حافظه |
| Variant | رنگ/جنس با SKU و موجودی منطبق است؟ | خرید Variant اشتباه |
| Animation | Loop و State قابلکنترل است؟ | مصرف CPU و سردرگمی |
| Accessibility | توضیح و Alternative وجود دارد؟ | حذف کاربران بدون AR |
رنگ دقیق یک وعده پرریسک است
دوربین، نمایشگر، نور اتاق، White balance، Texture و Material همگی رنگ را تغییر میدهند. برای محصول حساس به رنگ، Disclaimer روشن، تصویر کالیبرهشده، نمونه رنگ فیزیکی یا سیاست مرجوعی مناسب لازم است. AR نباید تنها منبع تصمیم باشد.
اندازه و Fit
مدل مبلمان میتواند مقیاس فضایی را بهتر نشان دهد؛ اما اندازهگیری Sensor خطا دارد. در پوشاک، Overlay ظاهر جای Size recommendation مبتنی بر اندازه بدن و جدول واقعی را نمیگیرد. عبارت «پرو مجازی» را دقیق تعریف کنید: Visual try-on، Fit prediction یا هر دو؟
Pipeline تولید دارایی 3D
انتخاب روش تولید
| روش | مناسب برای | مزیت | ریسک |
|---|---|---|---|
| CAD conversion | مبلمان/دستگاه با فایل مهندسی | Dimension دقیق | Geometry بسیار سنگین و Material ناقص |
| Photogrammetry | شیء با Texture پیچیده | ظاهر واقعگرایانه | بازتاب، سطح شفاف و Cleanup |
| Manual modeling | محصول استاندارد/Variant زیاد | کنترل Topology و Style | زمان و خطای انسانی |
| Procedural/configurable | خانواده محصول با Rule | بازیافت Asset | پیچیدگی Engine و Catalog |
| AI-assisted reconstruction | Prototype یا Base mesh | سرعت اولیه | دقت، IP و Consistency نیازمند QA |
Definition of Done هر Asset
- SKU/Variant mapping و Owner مشخص؛
- ابعاد با کالای فیزیکی در Tolerance تعریفشده تطبیق دارد؛
- GLB و USDZ روی Device matrix باز میشوند؛
- بودجه فایل، Texture، Memory و Render پاس شده؛
- Thumbnail، Alt/Description و Fallback موجود است؛
- License مواد/Texture/مدل ثبت شده؛
- نسخه و تاریخ Re-QA با تغییر محصول مشخص است.
بودجه عملکرد؛ مدل را قبل از نیاز دانلود نکنید
فایل 3D، Renderer و Texture میتوانند LCP، Data مصرفی و حافظه را بدتر کنند؛ بهخصوص روی موبایل متوسط و شبکه ناپایدار. عدد ثابت KB/Polygon برای همه محصولات درست نیست، اما Budget و Gate لازم است.
- صفحه ابتدا Poster/تصویر سبک نشان دهد؛
- Viewer پس از نزدیکشدن به Viewport یا تعامل Load شود؛
- AR asset فقط پس از CTA و Compatibility check دریافت شود؛
- Geometry و Texture بر اساس Device/Use case بهینه شوند؛
- CDN، Cache-Control، CORS و MIME type صحیح باشند؛
- Loading progress، Cancel، Timeout و Retry محدود وجود داشته باشد؛
- Memory و Thermal روی Device واقعی سنجیده شود؛
- Fail شدن 3D خرید عادی را مسدود نکند.
<model-viewer> مسیرهای WebXR، Scene Viewer و Quick Look را در مستندات AR خود توضیح میدهد، اما استفاده از Component هم نیاز به Version pin، CSP، Asset QA و Regression test دارد.
Core Web Vitals و Analytics
AR نباید Metric صفحه محصول را پنهان کند. این Eventها را با Data dictionary ثبت کنید:
| Event | Property ضروری | هدف |
|---|---|---|
ar_eligible | device/os/browser/mode | Denominator واقعی |
viewer_loaded | asset_version/load_ms/bytes | Performance |
ar_start | entry/mode/sku | Activation |
ar_placed | time_to_place/error | Task success |
ar_variant_change | from/to | Exploration |
ar_exit | duration/reason | Friction |
add_to_cart | exposure/sku | Funnel outcome |
return_completed | reason/sku/exposure | Post-purchase outcome |
نباید تصویر دوربین یا داده محیط را داخل Analytics بفرستید. Event taxonomy، QA و Experiment در راهنمای UX دادهآگاه توضیح داده شده است.
سازگاری؛ Progressive enhancement نه صفحه بنبست
مسیر پیشنهادی:
- تصویر محصول و مشخصات برای همه؛
- 3D Viewer در Browserهای پشتیبانیشده؛
- CTA واقعیت افزوده فقط پس از Feature detection؛
- انتخاب WebXR/Scene Viewer/Quick Look بر اساس قابلیت؛
- پیام خطای قابلفهم و بازگشت به Product page؛
- QR انتقال از Desktop به Mobile در صورت نیاز، بدون اجبار Login؛
- Fallback و خرید عادی همیشه در دسترس.
Device matrix واقعی
حداقل Android پایین/میانی/بالا، چند نسخه iPhone/iPad، Browserهای رایج، دوربین محدودشده، Permission denied، شبکه کند، جهت RTL و حالت Battery saver را تست کنید. Browser user-agent را جای Feature detection نگذارید.
Privacy و امنیت دوربین/فضا
دوربین و Sensor میتوانند اطلاعات محیط خانه، چهره یا بدن را آشکار کنند. «همهچیز روی دستگاه است» را فقط وقتی بگویید که معماری و SDK آن را ثابت میکند.
| پرسش Privacy | تصمیم لازم |
|---|---|
| چه دادهای پردازش میشود؟ | Frame، Landmark، Depth، Device ID یا فقط Pose؟ |
| کجا پردازش میشود؟ | On-device، Browser، Vendor cloud یا Server شما؟ |
| چه چیزی ذخیره میشود؟ | ترجیحاً تصویر خام نه؛ Retention و Log دقیق |
| چرا لازم است؟ | Purpose روشن پیش از Permission |
| چه کسی دسترسی دارد؟ | SDK، Analytics و Subprocessor inventory |
| کاربر چه کنترلی دارد؟ | Cancel، حذف، ادامه خرید بدون AR |
- Permission را Contextual و پس از اقدام کاربر بخواهید؛
- قبل از دوربین، ارزش و نوع استفاده را شفاف توضیح دهید؛
- HTTPS، CSP، Dependency integrity و SDK review داشته باشید؛
- Screenshot/Share پیشفرض را از نظر PII محیط بررسی کنید؛
- Face/body داده را بدون نیاز ذخیره یا به Marketing وصل نکنید؛
- برای کودک/داده حساس ارزیابی حقوقی و اخلاقی مستقل انجام دهید.
Accessibility؛ AR مسیر انحصاری نباشد
کاربری که دوربین، حرکت، دید، Device سازگار یا فضای فیزیکی مناسب ندارد باید همان اطلاعات تصمیم را از مسیر دیگری بگیرد.
- تصویر چندزاویه، ویدئو، Dimension و متن کامل؛
- کنترل Keyboard برای 3D Viewer و Focus visible؛
- نام Accessible برای دکمههای Rotate/Zoom/AR؛
- عدم اتکا به حرکت Device بهعنوان تنها Input؛
- Respect برای Reduced motion و جلوگیری از Animation اجباری؛
- پیام خطا و Permission به زبان ساده؛
- Contrast و Target size مناسب در Overlay؛
- پرهیز از Motion شدید و ارائه Exit فوری.
هدف WCAG این است که اطلاعات و عمل خرید در دسترس بماند؛ خود تجربه فضایی ممکن است Alternative متفاوت بخواهد. AR را در تست کاربردپذیری با کاربران و تواناییهای متنوع ارزیابی کنید.
یکپارچهسازی با Catalog و تجارت الکترونیک
دارایی 3D باید بخشی از Product data باشد، نه فایل دستی پراکنده در Media library.
| فیلد | نمونه | قاعده |
|---|---|---|
| SKU/Variant | SOFA-3S-BLUE | Mapping یکبهیک یا Rule مستند |
| Asset URL | GLB/USDZ | Versioned و Cacheable |
| Dimension | W×D×H cm | Source of truth Catalog |
| Material/Color | Fabric 12 | همگام با موجودی |
| Asset status | draft/qa/published | Gate انتشار |
| Compatibility | webxr/quicklook | Fallback مشخص |
| Revision | v2026.08.1 | Rollback و Analytics attribution |
اگر کاربر داخل AR رنگ را عوض میکند، همان Variant باید با قیمت، موجودی، تصویر، سبد و سفارش Sync شود. Race موجودی یا انتخاب Variant ناموجود اعتماد را از بین میبرد.
جای AR در Journey خرید
- Badge کوچک روی کارت محصول میتواند قابلیت را نشان دهد، اما Model را Preload نکند؛
- CTA اصلی در صفحه محصول کنار Gallery/Dimension باشد؛
- اولینبار Microcopy کوتاه «مشاهده در فضای شما» بهتر از اصطلاح فنی است؛
- پس از خروج، Variant انتخابشده و Scroll context حفظ شود؛
- Add to cart در AR باید قیمت/Variant نهایی را واضح نشان دهد؛
- Checkout به دوربین یا Session AR وابسته نشود.
برای جلوگیری از شکستن مسیر خرید، راهنمای بهینهسازی Checkout را بهعنوان Guardrail اجرا کنید.
چگونه اثر AR را بدون Selection bias بسنجیم؟
جمعیت واجد شرایط
ابتدا کاربرانی را تعریف کنید که Device سازگار، SKU دارای Asset و Session مناسب دارند. تقسیم Control/Treatment باید پیش از کلیک AR انجام شود؛ مقایسه «کلیککنندگان AR» با «بقیه» اثر Intent را با Feature مخلوط میکند.
Metric tree
| نوع | شاخص | نکته |
|---|---|---|
| Primary | Purchase/eligible session یا Revenue/visitor | پیش از تست یکی انتخاب شود |
| Mechanism | Viewer load، AR start، Place success | چرایی اثر را نشان میدهد |
| Post-purchase | Return rate و Reason code | Window طولانی و Order-level join |
| Guardrail | LCP/INP، Crash، Error، Checkout completion | ضرر پنهان را میگیرد |
| Cost | Asset + CDN + Vendor + Support | برای Contribution margin |
| Equity | اثر بر Device/Network segment | حذف کاربران ضعیف را آشکار میکند |
Novelty و زمان آزمون
روزهای اول ممکن است کنجکاوی موقت ایجاد کند. Test را بهاندازه چرخه خرید و حجم نمونه ادامه دهید و Peeking را کنترل کنید. مرجوعی بعد از تحویل رخ میدهد و به Window طولانیتر نیاز دارد.
محاسبه TCO و ROI
هزینه فقط SDK نیست:
- عکاسی/Scan/CAD cleanup و Modeling؛
- Optimization و تبدیل GLB/USDZ؛
- QA فیزیکی، Device lab و Accessibility؛
- Integration Catalog/Analytics/Checkout؛
- CDN، Storage، Vendor fee و API؛
- Update Asset با تغییر محصول؛
- Support، Incident، Privacy review و خروج Vendor.
Incremental contribution =
(خرید افزایشی × حاشیه مشارکت)
+ صرفهجویی خالص مرجوعی
- هزینه متغیر AR
ROI دوره =
(Incremental contribution - هزینه ثابت دوره) / هزینه ثابت دوره
Revenue خام را سود فرض نکنید. هزینه ارسال/مرجوعی، تخفیف، تولید Asset و Depreciation را در Cohort درست لحاظ کنید.
Build، Buy یا Hybrid؟
| مدل | مناسب برای | مزیت | ریسک |
|---|---|---|---|
| استاندارد وب/Component | Placement ساده و تیم فنی | کنترل و Portability بیشتر | QA و Compatibility با تیم |
| SaaS AR | Pilot سریع و عملیات آماده | Pipeline/Viewer مدیریتشده | هزینه، داده و Lock-in |
| App native | Feature عمیق و کاربر تکرارشونده | Sensor/UX کنترلشده | نصب و دو Codebase |
| Hybrid | Web discovery + Native AR | پوشش دستگاه متنوع | Behavior و Analytics چندمسیره |
سؤالهای Vendor due diligence
- مالک Source/Master و فایل خروجی کیست؟
- GLB/USDZ قابلExport و بدون Viewer قابلاستفادهاند؟
- داده دوربین/چهره کجا پردازش و ذخیره میشود؟
- Browser/Device matrix و SLA چگونه Verify شده؟
- Asset version، Variant و Catalog sync چگونه کار میکند؟
- Analytics خام و Experiment integration قابلدسترسی است؟
- در تحریم/قطع سرویس، Fallback و Exit plan چیست؟
- قیمت بر SKU، View، Bandwidth یا Conversion است؟
ملاحظات پیادهسازی برای بازار ایران
شبکه و دستگاه
Test فقط روی پرچمدار و Wi‑Fi دفتر کافی نیست. موبایل میانرده، حافظه محدود، شبکه همراه ناپایدار، VPN و Browserهای رایج را در Device lab قرار دهید. دانلود Asset را با Data مصرفی شفاف و قابللغو کنید.
سرویس خارجی و دسترسی
SDK، CDN، License server یا Viewer خارجی ممکن است از داخل ایران ناپایدار یا برای حساب تجاری محدود شود. وابستگی Runtime را فهرست، Self-host/Export را ارزیابی و Kill switch برای بازگشت به تصاویر داشته باشید.
واحد، ابعاد و زبان
Dimension را با سانتیمتر/میلیمتر روشن، متن و عدد مختلط را RTL-safe و CTA/Permission/Error را فارسی کنید. یکسانسازی تومان/ریال، Variant و موجودی در AR ضروری است.
تولید Asset محلی
برای 3D studio یا پیمانکار، نمونه فیزیکی، Color reference، Tolerance ابعاد، Naming، NDA/IP و Acceptance criteria تعریف کنید. فایل Master و خروجی فقط در حساب پیمانکار نماند.
Pilot کمریسک پیشنهادی
هفته ۱: Discovery
- تحلیل Funnel و Reason code مرجوعی؛
- انتخاب یک Category و ۱۰ تا ۲۰ SKU پایدار؛
- مصاحبه/تست مسئله با مشتری؛
- تعریف Hypothesis، Primary metric و Guardrail.
هفته ۲ تا ۳: Asset و Prototype
- ساخت سه Asset نماینده ساده/متوسط/پیچیده؛
- 3D Viewer + دو مسیر AR + Fallback؛
- QA Scale/Material/Variant و Privacy؛
- Budget عملکرد و Device matrix.
هفته ۴: Usability و Instrumentation
- Task: پیدا کردن AR، Place، تغییر Variant و Add to cart؛
- تست Permission denied، نور کم و سطح نامناسب؛
- Event QA و Order/Return join؛
- رفع Issueهای Severity بالا.
هفته ۵ تا ۸: Experiment
- Randomization روی Eligible population؛
- Monitoring خطا، Performance و Checkout؛
- پرهیز از تغییر همزمان صفحه محصول؛
- تحلیل کلی و Segment از پیشتعریفشده؛
- تصمیم Scale، Iterate یا Stop.
خطای Viewer، Device و Asset را با Version و Trace به داشبورد وصل کنید؛ راهنمای Observability برای طراحی Signal و Alert کمک میکند.
Scorecard انتخاب Use case و راهکار
| حوزه | وزن نمونه | Gate |
|---|---|---|
| شدت عدمقطعیت مشتری | ۲۰ | شاهد تحقیق/مرجوعی |
| کیفیت و پایداری Catalog | ۱۵ | Dimension/Variant صحیح |
| پوشش Device/Network | ۱۵ | PoC کاربران هدف |
| دقت Asset | ۱۵ | QA با کالای فیزیکی |
| Performance و UX | ۱۰ | Budget و Task success |
| Privacy/Accessibility | ۱۰ | Fallback و Data flow |
| Portability/Operations | ۵ | Export، Version و Kill switch |
| Economics | ۱۰ | Incremental margin > TCO |
یک Gate بحرانی مثل مقیاس اشتباه، نبود Fallback یا ارسال تصویر دوربین بدون ضرورت با امتیاز کل جبران نمیشود.
اشتباههای رایج
- عدد Conversion فروشنده را Forecast قطعی میدانند: Category، Device و طراحی تست فرق دارد.
- همه SKUها را از روز اول مدل میکنند: Pipeline پیش از اثبات ارزش مقیاس میگیرد.
- ظاهر را با Fit اشتباه میگیرند: Overlay لباس اندازه مناسب را تضمین نمیکند.
- مدل را در Page load دانلود میکنند: کاربران غیرمصرفکننده هزینه Performance میدهند.
- فقط دستگاه تیم را تست میکنند: Failure واقعی در Device/Network دیگر پنهان میماند.
- Fallback ندارند: کاربر بدون Permission یا Support از خرید حذف میشود.
- Asset را فایل تزئینی میدانند: Version/Variant/QA از Catalog جدا میشود.
- دوربین را بیخطر فرض میکنند: Data flow و SDK ثالث ممیزی نمیشود.
سوالات متداول واقعیت افزوده فروشگاهی
آیا واقعیت افزوده نرخ تبدیل را افزایش میدهد؟
ممکن است در Use case مناسب عدمقطعیت را کم کند، اما اثر قطعی نیست. باید کاربران واجد شرایط را پیش از کلیک Randomize و Conversion، Performance و مرجوعی را با Guardrail بسنجید.
برای AR فروشگاهی اپلیکیشن لازم است؟
نه همیشه. 3D Viewer، WebXR، Scene Viewer و Apple Quick Look مسیرهای وب/بومی دارند؛ اما پشتیبانی و قابلیتها متفاوتاند. برای Featureهای پیچیده یا کاربر تکرارشونده، App اختصاصی ممکن است مناسب باشد.
GLB بهتر است یا USDZ؟
رقیب مستقیم عمومی نیستند. GLB/glTF برای تحویل سهبعدی Web و بسیاری از مسیرهای Android رایج است؛ Quick Look اپل از USDZ استفاده میکند. معمولاً Master مشترک و خروجی QAشده برای هر مسیر لازم است.
AR میتواند مرجوعی پوشاک را حذف کند؟
خیر. Visual try-on ظاهر را نشان میدهد، اما Fit به اندازه بدن، الگوی لباس، جنس و ترجیح شخص وابسته است. اثر را فقط روی Reason code مرتبط و با داده پس از تحویل بسنجید.
از چند محصول برای Pilot شروع کنیم؟
تعداد ثابت وجود ندارد؛ ۱۰ تا ۲۰ SKU پایدار و نماینده معمولاً برای آزمایش Pipeline مناسبتر از Catalog کامل است. بهتر است سه سطح پیچیدگی Asset و حجم کافی برای Experiment داشته باشید.
جمعبندی
AR یک ابزار تصمیم است، نه تزئین فروشگاه. ارزش آن از تطابق Use case، دقت Asset، پوشش دستگاه، UX کماصطکاک، Privacy و سنجش اثر افزایشی میآید. با یک Pilot محدود و Fallback کامل شروع کنید؛ فقط وقتی Incremental margin و تجربه کاربر از TCO بهتر بود مقیاس دهید. برای طراحی PoC، معماری 3D/WebAR و برنامه سنجش فروشگاه خود، درخواست مشاوره محصول و تجارت الکترونیک را ثبت کنید.
