المتسوق الذي يصل إلى صفحة المنتج يملأ الفجوات بنفسه. يقرأ الصورة، يستنتج المادة من العلامة التجارية، يفترض أن تقدير التسليم ينطبق على رمز بريده، ويسأل إذا كان غير متأكد.
الوكيل الذي يشتري نيابة عن ذلك المتسوق لا يفعل أيًا من هذا. يقرأ ما نشرته في شكل منظم، وكل ما هو غائب — من وجهة نظره — غير صحيح. إذا كانت خاصية المادة مملوءة في 40% من وحدات SKU، فأنت غير مرئي لـ 60% من استعلامات التصفية حسب المادة. إذا كانت نوافذ التسليم نصوصًا سردية، فلا يمكن مقارنتها.
بالنسبة لأي شخص يدير MedusaJS، هذا وضع ملائم: أنت تتحكم في نموذج البيانات وواجهة برمجة التطبيقات مباشرة بدلاً من التفاوض مع آراء منصة ما. إليك ما يجب فعله بهذا.
يستهدف Medusa 2.x. لا يزال مشهد البروتوكولات — ACP، UCP، MCP — في طور التوحيد، لذا اعتبر التكاملات المحددة حالة حالية والعمل على البيانات أدناه دائمًا بغض النظر عن البروتوكول الذي ينتصر.
السمات هي المنتج الآن
في كتالوج Medusa، الإغراء هو السماح لواجهة المتجر بحمل معنى لا تحمله البيانات — جدول مواصفات مصمم جيدًا مجمع من وصف نصي. هذا يعمل للبشر ويفشل للآلات.
الانضباط:
- نمذج السمات كبيانات من الدرجة الأولى ومصنفة، وليس كنص حر في وصف. كل ما قد يفلتره العميل أو يقارنه أو يسأل عنه يحتاج إلى حقل خاص به.
- استخدم مفردات محكومة. ثلاثة آلاف قيمة لون نص حر مختلفة لا تجمع إلى شيء. أربع وعشرون خيارًا محددًا تشكل فلترًا قابلاً للاستخدام وسمات قابلة للمقارنة.
- املأ المعرفات. GTIN، MPN والعلامة التجارية هي كيفية مطابقة منتجك مع نفس المنتج في مكان آخر. المعرفات المفقودة تعني أن الوكيل لا يمكنه التأكد من أنه ينظر إلى ما يعتقده.
- عبّر عن الوحدات بوضوح.
2.5ليست طولًا.2.5 mهي طول. - كن صادقًا بشأن المتغيرات. إذا كان الحجم واللون مستقلين حقًا، نمذجهما بشكل مستقل بدلاً من قائمة مسطحة من الخيارات المجمعة مسبقًا.
معظم هذا هو نفس عمل الكتالوج الذي يحسن البحث داخل الموقع والتنقل الم faceted، وهو الجزء المطمئن — فهو يعود بالنفع سواء ظهر مرور الوكلاء لفئتك أم لا. نصف خط أنابيب الإثراء نفسه في تنظيف كتالوج كبير بالذكاء الاصطناعي؛ تختلف المنصة النموذجية، لكن الطريقة لا تختلف.
يجب أن يكون التوفّر حقيقياً لا متفائلاً
هذه هي النقطة التي تعاقب فيها قنوات الوكلاء المتاجر التي يغفرها البشر. الشخص الذي يطلب شيئًا معلمًا كمخزون ويتلقى بريد تأخير يكون منزعجًا قليلاً. الوكيل الذي أجرى المعاملة على هذا الأساس قد التزم نيابة عن العميل باستخدام معلومات نشرتها كحقائق.
- اعرض المخزون الحقيقي، حسب الموقع إذا كنت تفي بالطلبات من أكثر من مكان — يدعم وحدة المخزون في Medusa هذا بشكل صحيح، لذا استخدمها بدلاً من دمج الأرقام في رقم واحد.
- انشر توقعات التسليم التي يمكنك الاعتماد عليها، محسوبة بناءً على الموقع وحالة المخزون بدلاً من وعد ثابت في كتلة CMS.
- ميز بين نفاد المخزون والتوقف عن التصنيع. فهما يستدعيان سلوكاً مختلفاً تماماً من الوكيل.
- حافظ على حداثة المعلومات بدقة. قيمة التوفر المخزنة مؤقتاً والتي تتأخر ساعة هي إجابة خاطئة تُقدم بثقة.
حدد موقفك من البيع الزائد قبل فتح قناة الوكيل، وليس بعدها. التسامح الذي كان مقبولاً عندما كان البشر يتعاملون مع الاحتكاك يصبح مشكلة دقة منهجية عندما يقدم لك آلة المعلومات.
يجب أن تكون السياسات بيانات لا ملفات PDF
نوافذ المرتجعات، شروط الضمان، عتبات الشحن والقيود عادة ما تكون صفحة من النصوص القانونية. الوكيل الذي يُسأل هل يمكن لعملياءي إرجاع هذا يحتاج إلى إجابة منظمة.
على الأقل، اجعلها قابلة للقراءة آلياً: نافذة المرتجعات بالأيام، من يتحمل تكلفة الشحن للمرتجعات، الفئات المستثناة، فترة الضمان، عتبة الشحن المجاني، وأي وجهات لا تشحن إليها. انشرها كحقول منظمة يمكن لواجهة برمجة التطبيقات الخاصة بك إرجاعها، و— بشكل منفصل — كعلامات schema.org على واجهة المتجر، حتى تتفق القناتان.
السبب التجاري واضح: الوكيل الذي يقارن بين منتجين حيث ينشر أحدهما سياسة مرتجعات لمدة 30 يوماً والآخر لا ينشر شيئاً، سيفضل المنتج الذي يمكنه الاستدلال عليه.
نطاق API الذي يحتاجه الوكيل
واجهة برمجة تطبيقات المتجر في Medusa مصممة بشكل موارد، وهذا مناسب للواجهة لكنه غير مناسب للوكيل. الوكيل يريد عمليات موجهة للمهام: ابحث لي عن منتجات تطابق هذا الوصف، أخبرني إذا كان هذا متوفراً بهذا الحجم لهذا الرمز البريدي، ما هو موقف المرتجعات بشأن هذا.
ابنِ طبقة رقيقة فوق وحدات Medusa الخاصة بك تكشف عن هذه العمليات، واعتبر تلك الطبقة منتجاً مستقلاً بمعاييره التصميمية الخاصة. نشرح كيفية تصميمها — بما في ذلك ما يجب ألا يُكشف أبداً — في منتجك يحتاج إلى خادم MCP.
ملاحظتان خاصتان بـ Medusa. أولاً، نظام الوحدات يجعل هذا سهلاً حقاً: الطبقة الموجهة للوكيل تستهلك وحدات المنتج والمخزون والتسعير الخاصة بك بدلاً من أن تكون نسخة منها. ثانياً، حافظ على فصلها عن واجهة برمجة تطبيقات المتجر — أنماط الوصول، حدود المعدل، ونموذج الأذونات كلها مختلفة، ودمجها يضر كلاهما.
الظهور مقابل إتمام عملية الشراء
هذان مشروعان مختلفان وغالباً ما يخلط الفرق بينهما.
- الظهور — مساعد يوصي بمنتجك في إجابة. يعتمد على بيانات واجهة المتجر المنظمة والقابلة للزحف: علامات schema.org، صفحات منتج نظيفة، محتوى حقيقي، وسياسة زحف تسمح بالوكلاء المناسبين. غالباً ما يكون مجالاً مرتبطاً بتحسين محركات البحث.
- الشراء — يكمل الوكيل عملية شراء عبر أنظمتك. يعتمد على تصميم الواجهة، المصادقة، معالجة الدفع، والبروتوكولات الناشئة.
الأول متاح لكل متجر اليوم وله عائد واضح على المدى القريب؛ نغطيه في كيفية توصية منتجاتك عبر ChatGPT وPerplexity. الثاني لا تزال معاييره في تطور. قم بالأول الآن بغض النظر.
ترتيب عمل منطقي
- راجع اكتمال السمات عبر الكتالوج ورتب السمات حسب ما إذا كان البحث أو التصفية أو المقارنة يستخدمها فعلاً.
- صحح القواميس المنظمة قبل إثراء أي شيء — وإلا فأنت تضيف صفوفاً إلى تصنيف غير متناسق.
- أثرِ الفجوات، مع أخذ عينات من المخرجات بدلاً من الوثوق بها بالكامل.
- نظم السياسات وانشرها كحقول API وكعلامات على واجهة المتجر.
- تحقق من دقة التوفر مقابل الواقع لمدة شهر. إذا كانت خاطئة للبشر، فستكون خاطئة للآلات بشكل أسرع وأكثر علانية.
- ثم ابنِ طبقة واجهة برمجة التطبيقات الموجهة للوكيل، وبعدها فقط فكر في البروتوكول الذي ستستخدمه.
الخطوات من واحد إلى خمسة تستحق التنفيذ سواء أصبح التجارة عبر الوكلاء مهمة في فئتك أم لا، وهذا ما يجعلها استثماراً آمناً في مجال لا يزال غير مستقر.
ممارستنا في MedusaJS وفريق تطوير Medusa يبنيان هذه الكتالوجات والواجهات فوقها، مع فريق الهندسة الذكية الاصطناعية لدينا على جانب النماذج، وعملنا الأوسع في تكامل الذكاء الاصطناعي الذي يغطي مكان هذا ضمن الاستراتيجية التجارية.
الأسئلة الشائعة
هل تحقق وكلاء التسوق المدعومون بالذكاء الاصطناعي مبيعات ذات مغزى حتى الآن؟
يختلف الأمر اختلافاً كبيراً حسب الفئة والإجابة الصادقة لمعظم المتاجر اليوم هي ليس بعد، لكن أكثر قابلية للقياس من العام الماضي. سبب التصرف الآن هو أن العمل التمهيدي — اكتمال السمات، دقة التوفر، السياسات المنظمة — يحسن البحث داخل الموقع، التصفية، والرؤية العضوية بغض النظر عن تطور قناة الوكيل.
ما الذي يقدمه MedusaJS لنا هنا ولا تقدمه منصة SaaS؟
التحكم المباشر في نموذج البيانات وواجهة API. يمكنك إضافة سمات معرفة بأنواع دون الصراع مع تجريد الحقول الوصفية، وإتاحة عمليات مُشكَّلة على هيئة مهام فوق وحداتك الخاصة، والحفاظ على واجهة مواجهة الوكلاء منفصلة عن واجهة الـstorefront. على منصة مُدارة تعمل ضمن ما قرّره المزود ليُكشف.
هل يجب أن نمنع زواحف الذكاء الاصطناعي؟
ميّز بين برامج الزحف التي تَستشهد بمصادرك وتلك التي تقتطع المحتوى دون ذلك. المنع العشوائي يزيلك تماماً من إجابات الذكاء الاصطناعي، وما يعتبره معظم تجار التجزئة تبادلاً خاطئاً. قرّر لكل برنامج زحف على حدة، وثّق قرارك، وعاوده المراجعة؛ هذه مسألة سياسة وليست إعداداً افتراضياً.
هل يستحق تنفيذ بروتوكولات إتمام الشراء الخاصة بالوكلاء الآن؟
البروتوكولات لا تزال تتبلور، لذا أي شيء تبنيه اعتماداً على بروتوكول محدد يحمل مخاطرة إعادة العمل. عمل البيانات وواجهة API التحتي لا يحمل هذه المخاطرة ويستغرق وقتاً أطول. قم بذلك أولاً؛ واعتماد بروتوكول فوق أساس نظيف يكون أسرع نسبياً.
ما مدى دقة بيانات المخزون المطلوبة؟
أكثر دقة مما تعمل به معظم المتاجر حالياً. المتلقي لرسالة تأخير يشعر بالاستياء؛ والوكيل الذي أبرم معاملة بناءً على توافر منشور قد قطع التزاماً نيابةً عن العميل اعتماداً على بياناتك كما لو كانت حقيقة. حدّد مستوى تحمّلك للّبيع الزائد صراحةً قبل فتح القناة.
ابدأ بتدقيق السمات
أرسل لنا معدلات ملء السمات في كتالوج Medusa الخاص بك وسنخبرك بما يمكن للوكيل رؤيته حالياً وما لا يمكنه. عادة ما يكون أقل مما تتوقع الفرق. تحدث إلى فريقنا؛ نرد خلال يوم عمل.