منصة تجارة إلكترونية متكاملة

السياق الأعمق: ما الذي كان على المحك؟

العميل كان شركة تجارية متوسطة الحجم لها 12 سنة من النشاط في السوق العربي. كانت علامتها التجارية قوية في محلات التجزئة الفيزيائية، لكن تواجدها الرقمي كان ضعيفاً — موقع قديم مبني على WooCommerce قديم مع ثيم غير محسّن، يعاني من انقطاعات متكررة خلال الجمعة البيضاء وعروض رمضان. في 2024، قرر مجلس الإدارة أن 40% من الإيرادات يجب أن تأتي من القناة الرقمية بحلول 2026 — وكان لدينا 4 أشهر لإطلاق منصة جديدة تحقق هذا الهدف.

التحليل الأولي: ما الذي اكتشفناه

أجرينا 3 أسابيع من البحث الأولي قبل أي كتابة كود:

• تحليل Google Analytics السابق: 72% من الزوار يغادرون قبل تحميل الصفحة بالكامل (LCP > 5s).
• Heat maps على 30 مستخدم فعلي: 85% يحاولون استخدام البحث قبل التصفح، لكن خاصية البحث القديمة كانت بطيئة وغير ذكية.
• مقابلات مع 15 عميل: 12 منهم ذكروا أن "عملية الدفع مربكة" كسبب رئيسي للتخلي عن السلة.
• فحص بوابات الدفع: كان هناك بوابة واحدة فقط لا تدعم mada أو Apple Pay.

القرارات التقنية الرئيسية

لماذا Next.js وليس Shopify Plus؟

العميل كان يفكر في الهجرة لـShopify Plus ($24,000/سنة). بعد حساب الـTCO على 5 سنوات، Shopify Plus كانت ستكلف $120,000 مقابل $45,000 لحل Next.js مخصص. بالإضافة، Shopify لا يدعم الفوترة الإلكترونية ZATCA Phase 2 من داخل النظام، مما يتطلب إضافة خارجية مكلفة.

لماذا Redis؟

التوقع كان 50,000 مستخدم شهري. في البداية، Next.js caching الافتراضي كان كافياً. لكن الاختبارات الحملية (load testing) أظهرت أن في الذروات (رمضان + الجمعة البيضاء) يمكن أن نصل لـ2,000 طلب/ثانية. Redis أضاف طبقة caching للـproducts API تقلل الحمل على PostgreSQL بنسبة 85%.

لماذا Stripe مع Tap للخليج؟

Stripe لبطاقات العالم (Visa، Mastercard، Amex) وApple Pay. Tap للسوق السعودي (mada، STC Pay، Tabby). هذا المزيج غطى 98% من بوابات الدفع المطلوبة في المنطقة.

الجدول الزمني الفعلي

• الأسبوع 1-3: Discovery، تحليل المنافسين، wireframes
• الأسبوع 4-6: تصميم UI/UX + اعتماد العميل
• الأسبوع 7-10: Backend + API + قاعدة البيانات
• الأسبوع 8-13: Frontend (بالتوازي)
• الأسبوع 13-15: تكامل بوابات الدفع + اختبار
• الأسبوع 15-16: QA + إصلاح bugs + إطلاق ناعم
• الأسبوع 17: الإطلاق الرسمي + مراقبة مكثفة

التحديات خلال التنفيذ

التحدي 1: ترحيل 8,500 منتج بدون توقف

كان على الموقع القديم ما يقارب 8,500 منتج موزع في 200 فئة، مع صور ومراجعات. بناء script ترحيل آلي استغرق 5 أيام، شمل: تحويل تنسيق الصور لـWebP، ترجمة أسماء الفئات، ودمج المنتجات المكررة. العملية تمت على مراحل (stages) خلال ليلة واحدة بـ2 ساعة توقف فقط.

التحدي 2: معدل التخلي عن السلة

بعد الإطلاق، لاحظنا أن معدل التخلي ما زال مرتفعاً (65%). تحليل الـheatmaps كشف أن زر "أكمل الشراء" كان تحت الطية (below the fold) على الموبايل. تحريكه لأعلى + إضافة شريط تقدم رقّم (Progress indicator) قلل معدل التخلي إلى 42%.

التحدي 3: SEO للمنتجات القديمة

الموقع القديم كان يحتل المرتبة الأولى في Google لـ200+ كلمة مفتاحية. الانتقال لـdomain جديد كان سيفقدها. الحل: 301 redirects من كل URL قديم إلى مكافئه الجديد، مع الحفاظ على نفس الـdomain. النتيجة: 0% خسارة في الترتيب.

النتائج المفصلة بعد 12 شهر

• زيادة المبيعات: +340% (من $180,000/شهر إلى $790,000/شهر)
• معدل التحويل: من 1.8% إلى 4.2% (ضعفين)
• وقت تحميل LCP: من 5.1s إلى 0.8s (84% تحسن)
• معدل التخلي عن السلة: من 75% إلى 42%
• المستخدمين الشهريين: من 12,000 إلى 50,000+
• ROI بعد 12 شهر: 580% (الاستثمار $45,000، الأرباح الإضافية $260,000+)

الدروس المستفادة

• البحث الأولي يستحق وقته: 3 أسابيع discovery وفّرت أشهر من إعادة العمل لاحقاً.
• Mobile-first ليس شعاراً: 78% من الزوار من الموبايل — كل قرار UX يجب أن يُختبر على الموبايل أولاً.
• Performance = Revenue: تحسين LCP من 5s إلى 1s ارتبط مباشرة بزيادة التحويل.
• بوابات دفع متعددة = عملاء أكثر: كل بوابة إضافية كسبت عملاء جدد من فئات لم يكن الموقع القديم يخدمها.