פיתוח חנות מסחר אלקטרוני מותאם אישית: מהקטלוג ועד אינטגרציות

חנות המסחר האלקטרוני של לקוח עם קטלוג של 20,000 פריטים (SKU) פיגרה בכל בקשה. התקנת OpenCart על אירוח משותף עם PHP 7.4 סיפקה דף קטלוג תוך 5 שניות — LCP היה 8 שניות, ומחצית מהמשתמשים עזבו לפני הטעינה. לאחר מעבר ל-PostgreSQL 15 עם מאפייני JSONB ושילוב Elasticsearch 8.x, זמן הטעינה ירד ל-200 אלפיות השנייה, ו-CLS ירד מ-0.35 ל-0.02. כך בונים חנות מסחר אלקטרוני נכונה — לא תבנית, אלא ארכיטקטורה שבה כל פרט משפיע על המהירות ועל תהליך ההזמנות.

הפיתוח לא מתחיל בבחירת צבעי כפתורים, אלא במודל העסקי: ניהול מלאי, תמחור, לוגיסטיקה, שיווק — הכל חייב להיות מיושר לפני שורת קוד אחת. בחירת מחסנית טכנולוגית שגויה בהתחלה חוסכת זמן בתחילה, אך הופכת לחוב טכני תוך שנה. אנו מבצעים ביקורת ומציעים פתרונות אופטימליים.

כל חנות מסחר אלקטרוני דורשת גישה אישית: מודל נתונים, אינטגרציות, עומס. פתרונות אוניברסליים לא קיימים. צרו קשר לייעוץ על הפרויקט שלכם — נעריך את הארכיטקטורה ונמליץ על המחסנית הטכנולוגית המתאימה.

כיצד לבחור מחסנית טכנולוגית לחנות מסחר אלקטרוני

המחסנית נקבעת על ידי שלושה גורמים: גודל הקטלוג, תרחישי אינטגרציה ותעבורה צפויה. אפשרויות טיפוסיות:

עבור רוב הפרויקטים הבינוניים, מונולית עם גבולות מודול ברורים הוא אופטימלי — מהיר יותר לפיתוח, קל יותר לתחזוקה.

מדוע מודל נתוני הקטלוג הוא קריטי

מודל נתוני הקטלוג קובע את כל השאר. טעות נפוצה היא יצירת טבלת products עם עמודות color, size, material ישירות. זה עובד עד למוצר הלא-סטנדרטי הראשון. הגישה הנכונה: EAV (Entity-Attribute-Value) או מאפייני JSONB ב-PostgreSQL. סכמה לדוגמה:

products (id, sku, slug, base_price, status)
product_variants (id, product_id, sku, price_delta, stock)
variant_attributes (variant_id, attribute_id, value)
attributes (id, name, type, filterable, sortable)

עבור קטלוגים עם מוצרים הטרוגניים (אלקטרוניקה + ביגוד + רהיטים), אנו משתמשים בסוגי מוצרים — כל סוג מגדיר סט מאפיינים משלו. כך עובד Akeneo PIM, אותו אנו מחברים לקטלוגים מ-10,000 פריטים (SKU).

חיפוש וסינון

חיפוש SQL סטנדרטי products (id, sku, slug, base_price, status) product_variants (id, product_id, sku, price_delta, stock) variant_attributes (variant_id, attribute_id, value) attributes (id, name, type, filterable, sortable) אינו מתאים אפילו לקטלוג של 500 פריטים — אין רלוונטיות, מורפולוגיה או מילים נרדפות. אפשרויות:

• PostgreSQL FTS עם LIKE '%запрос%' — מתאים עד כ-5,000 מוצרים, הגדרה לרוסית דרך ispell או hunspell
• Elasticsearch — מלא תכונות: חיפוש מטושטש, הגברת שדות, מילים נרדפות, percolator עבור "מוצרים דומים". לפי Elasticsearch Reference, אגרגציות מאפשרות ספירת מסמכים עבור כל ערך פילטר.
• Typesense — פשוט יותר לתפעול, טוב לצוותים קטנים

אנו בונים פילטרים דרך אגרגציות Elasticsearch: משתמשים רואים רק ערכי פילטר שמניבים תוצאות שאינן אפס. זהו חיפוש פאקטי (faceted search) — התקן במסחר אלקטרוני.

כיצד ליישם חיפוש פאקטי

1. קבעו אילו מאפייני מוצר יהיו פילטרים (מחיר, מותג, מידה).
2. צרו מיפוי לאינדקס עם סוגים נכונים (keyword, float).
3. אינדקסו מוצרים עם המאפיינים שלהם.
4. הריצו אגרגציות עבור כל פילטר בשאילתה אחת.
5. בחזית, הציגו ערכים מצטברים ועדכנו תוצאות כאשר נבחרים פילטרים.

עגלה ותשלום

העגלה היא המקום שבו 60–80% מההמרה אובדת. החלטות קריטיות:

• עגלת אורח המאוחסנת ב-Redis עם TTL של 30 יום, ממוזגת עם השרת בעת התחברות. ללא עגלת אורח, רישום הופך למחסום.
• תשלום במסך אחד סטטיסטית עולה על תשלום רב-שלבי עבור B2C. עבור B2B, ההפך — יש צורך בשלבים: פרטי חיוב, כתובת משלוח, אישור מנהל.
• חישוב משלוח בזמן אמת: APIs מ-CDEK, Boxberry, Nova Poshta, DHL. תעריפים תלויים במשקל, ממדים, נקודת מוצא — מחושבים תוך כדי תנועה, לא מאוחסנים בטבלה.
• שער תשלום: Stripe עבור בינלאומי, CloudPayments / YooKassa עבור רוסיה/CIS, Fondy / WayForPay עבור אוקראינה. אינטגרציה דרך אישור webhook; סטטוס ההזמנה משתנה רק לאחר אימות חתימה. עמלת Stripe: 2.9% + $0.30 לעסקה.

ניהול הזמנות

מחזור חיי ההזמנה הוא מכונת מצבים. מצבים: טיוטה → ממתין לתשלום → שולם → בעיבוד → נשלח → נמסר → הושלם. בנוסף, ענפים צדדיים: מבוטל, הוחזר, בהמתנה. ספריות: winzou/state-machine עבור Laravel, xstate אם חלק מהלוגיקה נמצא בחזית. כל מעבר מצב מפעיל הודעות (אימייל, SMS, push), עדכוני מלאי ורישום לוגים.

אינטגרציות

סט טיפוסי לחנות מלאה:

• 1C / MySklad / Retailio — סנכרון מלאי ומחירים דרך תור (RabbitMQ/Redis Queue) עם מרווח של 5–15 דקות
• CRM (AmoCRM, HubSpot) — העברה אוטומטית של הזמנות ולידים
• שיווק באימייל (Klaviyo, Mailchimp, Sendpulse) — רצפי טריגר: עגלה נטושה, לאחר רכישה, הפעלה מחדש
• אנליטיקה: GA4 עם Enhanced Ecommerce + GTM בצד השרת לנתונים מדויקים ללא חוסמי פרסומות

ביצועים ו-SEO

דפי קטלוג חייבים להיות במטמון. אסטרטגיה: stale-while-revalidate — הגישו מטמון מיד, עדכנו ברקע. Redis למטמון בצד השרת, CDN (Cloudflare) לנכסים סטטיים. SEO ספציפי למסחר אלקטרוני:

• כתובות URL קנוניות לדפי פילטר — ללא זה, מנועי חיפוש רואים אלפי כפילויות
• hreflang לחנות רב-לשונית
• סימון Schema.org: Product, Offer, AggregateRating — משפיע על תוצאות עשירות
• פאג'ינציה דרך rel="next"/"prev" או גלילה אינסופית עם עיבוד SSR של המסך הראשון

מה כלול בעבודה שלנו

• מפרט טכני עם תיאור פונקציונלי ואינטגרציות
• אב-טיפוס ממשק (Figma)
• פיתוח backend: מודולי קטלוג, עגלה, הזמנות, חשבון אישי
• חזית על מחסנית מודרנית (React/Vue) עם עיצוב רספונסיבי
• אינטגרציות עם מערכות תשלום, שירותי משלוח, מערכות מחסן
• בדיקות (יחידה, אינטגרציה, עומס)
• פריסה לייצור והגדרת ניטור
• תיעוד ניהול
• תמיכה לאחר השקה (אחריות חודש לתיקון באגים)

לוחות זמנים ושלבים

חנות מסחר אלקטרוני טיפוסית בקנה מידה בינוני (1,000–10,000 פריטים (SKU), תשלום סטנדרטי):

סה"כ: 12–20 שבועות לפרויקט מלא ללא תבניות מוכנות. פרויקטים של Shopify עם התאמות מינימליות — 4–8 שבועות. העיקרון המרכזי: חנות מסחר אלקטרוני מושקת לא כשהכל מוכן, אלא כשמספיק מוכן למכירות הראשונות. השאר הוא איטרציות. צרו קשר כדי לדון בפרטים.