Building Haya Threads' E-commerce Engine

التحدي

• الكاتالوج ليس مسطحاً. يجب نمذجة المتغيرات مثل الحجم، اللون ومجموعاتها بشكل صحيح على مستوى قاعدة البيانات. إن خطأت في هذا فستقضي حياة المتجر وأنت تصارع عدادات المخزون التي لا تتطابق.
• كان يجب أن يكون المالكين قادرين على إدارته. المتجر الذي لا يستطيع المؤسسون تشغيله بدون مطور ليس مكتملاً، بل هو تبعية. كل إجراء روتيني، من منتج جديد إلى تغيير السعر، كود ترويجي أو تحديث لحالة الطلب، كان يجب أن يكون نموذجاً في لوحة الإدارة بدلاً من تذكرة لنا.
• تحتاج الطلبات إلى إبقاء العملاء على اطلاع. أكبر مصدر لرسائل دعم التجارة الإلكترونية هو السؤال عن مكان الطلب، ويجب على النظام الإجابة على ذلك قبل أن يتم سؤاله.
• لم يكن أحد يبحث عن المتجر. المتجر الجميل بدون حركة مرور هو كتالوج مكلف للغاية. كان بناؤه نصف الموجز فقط.

نهجنا

قمنا ببناء لوحة الإدارة واجهة المتجر كنصفين متساويين لنظام واحد، بدلاً من معاملة الإدارة كفكرة لاحقة مضافة في النهاية، وهو السبب المعتاد لانتهاء مطاف أصحاب المتاجر بمراسلة مطورهم لتغيير سعر.

تمت نمذجة المتغيرات في طبقة البيانات أولاً، قبل وجود أي واجهة، لأن إعادة تركيب التعامل السليم مع المتغيرات في متجر حي تعني ترحيل الطلبات، المخزون، والتاريخ في وقت واحد. تم تصميم تدفقات حالة الطلب كآلة حالة مع إشعارات البريد الإلكتروني المرفقة بكل انتقال، بحيث يسمع العميل من المتجر في كل خطوة.

تم بناء التقييمات لكل منتج مع تقييمات إجمالية معروضة على صفحة المنتج، مما يعطي الدليل الاجتماعي الذي يحدد عمليات شراء الأزياء والبيانات الهيكلية التي تجعل قوائم المنتجات مؤهلة لنتائج غنية في البحث. بعد الإطلاق تولينا تحسين محركات البحث للمتجر، مغطين بنية الفئات، محتوى المنتجات، الأداء التقني ورؤية البحث التي تحول المتجر العامل إلى متجر بياع.

ما بناه

تعمل واجهة المتجر على Next.js لسرعة الصفحة التي يتطلبها التسوق عبر الجوال، مع خلفية Node تتعامل مع الكتالوج، السلة، الطلبات والمدفوعات. يتصفح العملاء الفئات، يختارون المتغيرات، يقرأون التقييمات، يطبقون الأكواد الترويجية ويدفعون من خلال بوابة متكاملة.

لوحة الإدارة هي المكان الذي يعيش فيه العمل حقاً. ينشئ الفريق الفئات والمنتجات مع الوسائط الخاصة بها، يدير المتغيرات ومستويات المخزون، يراقب وصول الطلبات وينقلها عبر حالاتها مع إعلام العملاء تلقائياً مع كل تغيير، وينشئ، يطبق أو يزيل الأكواد الترويجية مع قدوم الحملات وذهابها.

القرارات التقنية والمقايضات

• بناء مخصص بدلاً من منصة استضافة. Shopify و WooCommerce ممتازتان، ونحن نبني على كليهما، لكن هذا المشروع ذهب مخصصاً لأسباب خاصة بالتحكم الإداري ومنطق الأعمال. المقايضة هي أن المتجر المخصص يعني أننا نمتلك الصيانة التي كانت المنصة ستتعامل معها لولا ذلك.
• Next.js لواجهة المتجر. شراء الأزياء محمول، نفاد صبر وغالباً على اتصالات متوسطة. الصفحات المقدمة من الخادم مع تحميلات المنتجات السريعة هي قرار تحويل قبل أن تكون قراراً تقنياً، وهي أيضاً ما يجعل المتجر قابلاً للفهرسة لتحسين محركات البحث.
• الإشعارات المرتبطة بانتقالات الحالة بدلاً من الإرسال اليدوي. كل تغيير في حالة الطلب يطلق رسالته الخاصة تلقائياً، مما يزيل مهمة بشرية يومية بشكل دائم.

النتائج

• متجر يديره المالكين أنفسهم، مع لوحة إدارة تتعامل مع الكتالوج، المخزون، الطلبات والترقيات بدون مشاركة المطور.
• عقد تحسين محركات البحث المستمر، مع قياس نفس الفريق الذي بنى المتجر على أداء البحث الخاص به.
• أرقام يمكننا مشاركتها في مكالمة.

ما نود قوله لصاحب متجر آخر

• قم بنمذجة متغيراتك قبل تصميم أي شيء. الحجم واللون يبدوان كمشاكل واجهة، لكنها مشاكل قاعدة بيانات، وقاعدة البيانات هي الشيء المكلف لتغييره لاحقاً.
• احكم على بناء التجارة الإلكترونية من لوحة الإدارة الخاصة به. ما إذا كان بإمكانك تشغيل عرض ترويجي في ليلة خميس دون الاتصال بأي شخص هو الاختبار الفعلي لما إذا كان البناء مكتملاً.
• ضع ميزانية ليتم العثور عليك، وليس فقط للبناء. رؤية البحث ليست ميزة إضافية للمرحلة الثانية.