כללי הצבת מוצרים נשברים בשלב הסנכרון
כללי הצבת מוצרים כמעט אף פעם לא נשברים בשלב ההגדרה — הם נשברים בייצוא הקטלוג, כאשר הנתונים נשלחים שוב למרקטפלייס. התמונה האופיינית: המוצר קיים ב-1С, קיים ב-Битрикс, ובפלטפורמה מופיעה כרטיסייה שלישית עם אותו מק"ט.
הסיבה — מפתחות התאמה שונים: במקום אחד הקישור נעשה לפי קוד, במקום אחר לפי שם, ואחרי עריכה ידנית של השם הסנכרון מפסיק לזהות את המוצר ויוצר חדש. כפילויות של כרטיסיות הן התקלה היקרה ביותר: הן מפזרות את המיקומים בחיפוש של הפלטפורמה, שוברות ביקורות שנצברו ודורשות איחוד ידני.
הקבוצה השנייה של שגיאות — מאפיינים שאבדו. כללי הצבת מוצרים בפלטפורמה דורשים שדות חובה: מידות, משקל, הרכב, מדינה, ברקוד. אם בקטלוג השדה ריק או מלא במאגר אחר, הייצוא עובר, אבל הכרטיסייה נשלחת למודרציה או למוסתרים.
בקנה מידה רחב זה נראה כך: חלק מהמבחר פשוט לא מופיע למכירה, ואף אחד לא שם לב עד שמשווים את הייצוא עם חלון הראווה.
התקלה השלישית — חוסר סנכרון של מלאי ומחירים. סנכרון המלאי פועל לפי לוח זמנים, והמכירה בפלטפורמה ובקמעונאות מתרחשת בין ההרצות. המוצר נמכר פעמיים, המלאי ירד למינוס, הפלטפורמה הסירה את הכרטיסייה מהמכירה בגלל נתונים לא תקינים.
עם המחירים זה גרוע יותר: כללי הצבת מוצרים במרקטפלייס מחשבים מחיר מבסיסים שונים — בהתחשב במבצע, בהנחת נאמנות או בעמלה. אם ב-1С המחיר אחד, ולפלטפורמה נשלח אחר, המוצר או נמכר בהפסד, או מפסיד במחיר למתחרה.
את כל שלוש התקלות מאחד דבר אחד: הן אינן נראות ברגע ההגדרה ומתגלות רק בזרימה. מפרקים כיצד זה נסגר ברמת כללי החלפה, ולא עריכות ידניות.
מה נותנת הגדרה נכונה של כללי הייצוא
כללי הצבת מוצרים שהוגדרו כראוי הם לא הגדרה חד-פעמית, אלא מנגנון שקובע כמה זמן עובר משינוי בקטלוג ועד להופעת הכרטיס בזירת המסחר וכמה פעמים הוא נדחה על ידי המודרציה.
כאשר הכללים מתארים מאפיינים חובה, יחידות מידה, קטגוריות ומגבלות של הזירה, הייצוא מתבצע ללא תיקונים ידניים: המוצר מפורסם באותו מחזור סנכרון, ולא לאחר שמנהל מתקן ידנית את השם והמאפיינים.
ההשפעה המדידה הראשונה היא מהירות הפרסום. עם כללים נכונים פריט חדש יוצא לזירה יחד עם הסנכרון הקרוב, ללא תור לעיבוד ידני. זמן התגובה לשינוי במלאי מצטמצם מימים לשעות: מחיר, תיאור וזמינות מתעדכנים במסגרת מחזור סנכרון אחד, ולא כמשימה נפרדת.
ההשפעה השנייה היא שיעור הכרטיסים הנדחים. המודרציה דוחה מוצרים בגלל אי-עמידה בדרישות הזירה: שדות חובה ריקים, קטגוריה שגויה, יחידות שגויות, ניסוחים אסורים בתיאור. הכללים חוסמים סיבות אלו לפני השליחה — הכרטיס יוצא כבר תקין, ואחוז הדחיות יורד באופן צפוי, ולא "כפי שיצא".
ההשפעה השלישית היא עדכניות היתרות. הכללים מקשרים את ניהול המלאי לזירה כך שפריט שנמכר מוסר מהמכירה באותו מחזור, ולא נשאר זמין להזמנה. זה מסיר סוג של דחיות שבו הקונה מזמין מוצר שכבר אינו קיים, ומפחית את העומס על התמיכה.
בסך הכל, אוטומציה של הייצוא מעבירה את ההצבה מתהליך ידני לתהליך מנוהל: המלאי משתנה — הזירה משקפת זאת ללא מעורבות אדם, והצוות עוסק במוצר, ולא בתיקון כרטיסים.
דרכים להגדרת כללים: השוואת גישות
בפועל, כללי הצבת מוצרים בשוקי מקוונים לעיתים רחוקות מוגדרים בדרך אחת — לרוב משלבים כמה, והבחירה תלויה בהיקף הקטלוג, בתדירות השינויים ובמידת ההקפדה של השוק המקוון בבדיקת הכרטיסים. נבחן ארבע אפשרויות עבודה ואת מגבלותיהן, כדי לא להחליף כלי במקום שבו די להגדיר את הקיים.
במה נבדלות הגישות
כללים ידניים חיים ישירות בממשק — המנהל מגדיר תנאים וחריגים לפי קטגוריות, מותגים, מחסנים. זה מהיר להתחלה ומובן לצוות לא-טכני, אך עם צמיחת הקטלוג הוא הופך לעשרות רשומות לא מתואמות שאיש אינו סוקר.
תבניות החלפה (כללי התאמת מאפיינים, יחידות מידה, שיעורי מע"מ) נותנות תוצאה צפויה בזרימה ומנוהלות בגרסאות יחד עם התצורה, אך דורשות משמעת: כל שדה חדש בייצוא יש לתאר מראש.
סקריפטים לייצוא מכסים לוגיקה לא סטנדרטית — חישוב מחיר לפי כמה מחסנים, סינון לפי מלאי, השמת מאפיינים מטבלאות חיצוניות. כוחם בגמישות, חולשתם בתמיכה: ללא בדיקות ותיעוד הם נשברים בשקט בשינוי הראשון של הפורמט.
שירותים חיצוניים לוקחים על עצמם את הספציפיקה של השוק המקוון ואת העדכונים לפי דרישות הפלטפורמות, אך מוסיפים תלות במערכת חיצונית והשהיה בין שינוי במערכת החשבונאות לפרסום.
השוואת האפשרויות
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| כללים ידניים | קטלוג קטן, עריכות נדירות, תחילת מכירות | אינה מתרחבת, אין היסטוריית שינויים, שגיאות אינן מנוטרות |
| תבניות החלפה | זרימת מוצרים יציבה, קטגוריות טיפוסיות | דורשות תיאור של כל השדות, מתקשות עם מקרים לא סטנדרטיים |
| סקריפטים לייצוא | לוגיקה מורכבת של מחירים, מלאי, מאפיינים | נדרשים בדיקות וניטור, נשברים בשינוי פורמט |
| שירותים חיצוניים | פלטפורמות רבות, שינויים תכופים בדרישות | תלות בספק, השהיה בפרסום, גישה מוגבלת לנתונים |
בפועל, לרוב משלבים תבניות החלפה לקטגוריות טיפוסיות וסקריפטים לחריגים — כך עיקר המוצרים עוברים במסלול צפוי, ומקרים לא סטנדרטיים אינם שוברים את הזרימה הכללית.
שלבי יישום כללי הצבת מוצרים
העבודה מתבצעת ברצף: כל שלב נשען על התוצרים של השלב הקודם, ולכן דילוג על כל צעד מתגלה כשגיאות כבר בפרודקשן — כפילויות של כרטיסים, מלאי שגוי או פריטים שנדחו על ידי המודרציה.
- ביקורת הקטלוג. משווים את מבנה המדורים, המאפיינים וההצעות המסחריות לדרישות הפלטפורמות: מאפיינים חובה, יחידות מידה, ברקודים, מידות. מתעדים אילו שדות חסרים והיכן הערכים מולאו שלא לפי התבנית.
- תכנון סכמת הייצוא. קובעים אילו מאפיינים ומדריכים הופכים למקור האמת, כיצד ממופות קטגוריות הקטלוג לקטגוריות הפלטפורמה, ולפי איזה סימן מוצר נכנס לייצוא או מוחרג ממנו.
- הגדרת הכללים. מנסחים את כללי הצבת המוצרים: חובת שדות, ערכי ברירת מחדל, טיפול במאפיינים ריקים, מגבלות על אורך התיאורים והכותרות. הכללים מנוהלים בגרסאות, כדי שניתן יהיה להחזיר שינוי לאחור.
- ייצוא בדיקה. מריצים מדגם מוגבל — בדרך כלל כמה עשרות פריטים מקטגוריות שונות — ובוחנים מה נשלח לפלטפורמה: אילו שדות מולאו, אילו נזרקו, והיכן פעל ערך ברירת המחדל.
- בדיקת הכללים. משווים את התוצאה לדרישות הפלטפורמה, מנתחים את החריגות, ומטפלים במקרי הקצה: מוצרים ללא מלאי, פריטים עם כמה הצעות, ומק"טים שהופסק ייצורם.
- מסירת התיעוד. מוסרים את תיאור הסכמה, רשימת הכללים והוראות העריכה של הקטלוג — כדי שהמנהל יוכל להוסיף מוצר או לשנות מאפיין בלי לשבור את הייצוא.
לאחר המסירה הכללים חיים יחד עם הקטלוג: עם הופעת קטגוריה חדשה או שינוי בדרישות הפלטפורמה מרחיבים את הסכמה, ולא כותבים אותה מחדש מאפס.
מה הלקוח מקבל לאחר ההגדרה
הגדרת כללי פרסום המוצרים אינה מסתיימת ב"מודול מופעל", אלא במערכת של ארטיפקטים שלפיהם ניתן להפעיל את המערכת ולהעביר אותה לצוות אחר. להלן מה שנשאר אצל הלקוח במאגר ובמסמכים.
- תצורות סנכרון — ייצוא פריטים, מחירים, מלאי ומאפיינים ממערכת החשבונאות לקטלוג האתר ובחזרה, עם לוח זמנים להרצות וטיפול בהרצות שהצליחו חלקית.
- סכמות התאמה — טבלאות התאמה של קטגוריות, מאפיינים ויחידות מידה בין מערכת החשבונאות לפלטפורמות המסחר, כולל כללים לפריטים ללא קטגוריה.
- מדיניות הרשאות — תפקידים למנהלים, לעורכי תוכן ולקבלני משנה: מי עורך את הכרטיס, מי משנה את כללי הייצוא, מי רואה את יומן הפעולות.
- נהלי עדכון — סדר התיקונים עם הופעת קטגוריה או פלטפורמה חדשה: היכן משתנה הכלל, כיצד נבדקת התוצאה, מה נחשב לחזרה לאחור.
- הוראות לעובדים — תרחישים שלב-אחר-שלב למצבים טיפוסיים: המוצר לא יוצא, המחיר התפצל, הכרטיס עבר למודרציה.
- תיעוד והתראות — אילו אירועים נרשמים, למי מגיעה התראה על שגיאת סנכרון ובאיזו תדירות נבדקת התור.
- סביבת בדיקה לכללים — קונטור בדיקה שבו כלל חדש מורץ על סט מוגבל של פריטים לפני פרסום בקטלוג הראשי.
כל ארטיפקט מנוהל בגרסאות יחד עם הקוד, ולכן שינויים בכללי פרסום המוצרים נראים בהיסטוריה וניתנים לחזרה לאחור בפעולה אחת. הדבר מסיר את התלות במהנדס מסוים: מומחה חדש מתמצא לפי התיעוד, ולא לפי התכתבות.
בנפרד אנו מתעדים נקודות בקרה — פער בכמות הפריטים בין המערכות, שיעור הכרטיסים עם שגיאות מאפיינים, זמן מעבר סנכרון מלא. לפיהם ניתן לראות אם הסכמה עובדת לאחר תיקונים, ומתי הגיע הזמן להתערב.
מקרה בוחן: כיצד צומצם שיעור הכרטיסים הנדחים
הלקוח — יצרן מוצרים לבית, מכירות דרך מרקטפלייסים. הכרטיסים פורסמו ידנית: מנהל הוציא פריטים ממערכת הנה"ח, ערך תיאורים ומאפיינים בהתאם לדרישות כל פלטפורמה והעלה דרך אזור אישי.
בקטלוג של כמה אלפי פריטים פעילים זה יצר זרם מתמיד של דחיות — הפלטפורמות החזירו כרטיסים בגלל שדות חובה שלא מולאו, אי-התאמה לקטגוריה, כפילויות לפי ברקוד והפרות בתיאורים.
מה היה לפני השינויים
שיעור הכרטיסים הנדחים עמד על כ-30% מהכרטיסים שנשלחו בתקופה. כל דחייה — משמעה מעבר חוזר של המנהל: לאתר את הסיבה בתשובת הפלטפורמה, לתקן מאפיין, לשלוח מחדש. כרטיס אחד דרש בממוצע 40-50 דקות עבודה ידנית, וחלק מהפריטים "נתקעו" בתור לפרסום למשך כמה ימים. סיבות הדחיות לא תועדו בשום מקום — אותן שגיאות חזרו על עצמן מאצווה לאצווה.
מה שינו
העברנו את כללי פרסום המוצרים מהוראות ומזיכרון המנהלים אל הקונפיגורציה: מאפיינים חובה, ערכים מותרים, דרישות לתיאורים וקשרי "קטגוריה — מאפיינים" עבור כל פלטפורמה.
הייצוא ממערכת הנה"ח עובר כעת בדיקה מקדימה לפי כללים אלה לפני השליחה — כרטיס עם מאפיין חסר או כפילות ברקוד אינו יוצא לפלטפורמה, אלא נכנס לדוח עם ציון השדה המדויק.
בנפרד הוגדרה התאמה של קטגוריות ומאפיינים בין מערכת הנה"ח למדריכים של הפלטפורמות, כך שהערכים מוזנים אוטומטית ולא נבחרים ידנית. לוגים של דחיות נאספים במקום אחד — מהם רואים אילו כללים מופעלים לעתים קרובות יותר ואילו שדות במערכת הנה"ח מתמלאים באופן חלקי.
מה נהיה אחרי
שיעור הכרטיסים הנדחים ירד ל-4-6% מהכרטיסים שנשלחו — נותרו בעיקר אי-התאמות שהפלטפורמה מפרשת לפי כללים פנימיים שלה. זמן הפרסום הממוצע של פריט הצטמצם מכמה ימים לכמה שעות, מכיוון שהבדיקה והייצוא מתבצעים במעבר אחד.
מספר התיקונים הידניים לאצווה ירד פי חמישה בערך: המנהלים מטפלים רק בכרטיסים שנכנסו לדוח הבדיקה המקדימה.
את הפרויקט הוביל מהנדס האינטגרציות שלנו עם מערכות הנה"ח והמרקטפלייסים; כללי הפרסום מתוארים בקונפיגורציה ולא בתקנון על הנייר, — ולכן הם מיושמים על כל ייצוא באופן אוטומטי.
במה נבדלים הכללים בין מרקטפלייסים שונים?
הפלטפורמות נבדלות בשלושה דברים: מאפיינים חובה של הכרטיס, כללי מתן שמות ומבנה הקטגוריות. מרקטפלייס אחד דורש ברקוד ומק"ט ספק בשדה נפרד, אחר — קינון קטגוריות אך ורק לפי הטקסונומיה שלו, ושלישי דוחה כרטיס ללא ארץ ייצור מלאה. המוצר פיזית הוא אחד, אך הדרישות לתיאורו — שלוש קבוצות שונות.
משום כך לא ניתן לייצא את הקטלוג "כפי שהוא": אותה פריט עובר מודרציה בפלטפורמה אחת ונשלח לדחייה באחרת. הסיבה כמעט תמיד אינה בנתונים עצמם, אלא בפריסתם לפי שדות — הערך קיים, אך מונח במקום שהפלטפורמה אינה מצפה לו.
קטלוג אחיד פותר זאת באמצעות שכבת כללים בין מערכת החשבונאות לפלטפורמות. המוצר נשמר פעם אחת ב-1С או ב-Bitrix, וכללי הפרסום מתארים כיצד להרכיב ממנו כרטיס עבור כל פלטפורמה: אילו מאפיינים הם חובה, כיצד ממופות קטגוריות, מה לעשות עם ערכים חסרים. הקטלוג אינו משוכפל, ודרישות המרקטפלייסים מתקיימות בהגדרות נפרדות.
ההבדלים בין הפלטפורמות משתנים — מופיעים שדות חובה חדשים, קטגוריות עוברות מקום. כאשר התאמת הקטלוג מתוארת בכללים, התיקון מתבצע בפרופיל ייצוא אחד, ולא בהרכבה מחדש של כרטיסים ידנית. קטלוג אחיד עם פריסה ניתנת להגדרה לכל פלטפורמה — זו התשובה לשאלה: הכללים שונים, מקור הנתונים אחד.
שאלות טכניות נפוצות בנוגע להגדרת כללים
כללי הצבת מוצרים כמעט אף פעם לא קיימים בוואקום: הם מצטלבים עם מלאי, מחירים, קטגוריות ומבצעים, ובמוקדם או במאוחר שני כללים מתחילים לתבוע את אותו מוצר. להלן שאלות טכניות שעולות לרוב בשלב ההגדרה ואחרי ההפעלה.
מה קורה אם שני כללים מתנגשים זה עם זה?
כללים מיושמים לפי עדיפות, ולא לפי סדר היצירה: המנוע בודק את התנאים ברצף ועוצר בהתאמה הראשונה. אם שני כללים מצטלבים בתנאים ובעלי אותה משקל, המוצר עלול להיכנס לקטגוריה שגויה או לקבל סט מאפיינים לא נכון.
אנו מגדירים עדיפויות מפורשות ומוסיפים בדיקת הצטלבויות — בעת שמירת הקונפיגורציה המערכת מתריעה על תנאים כפולים, ולא בוחרת בשקט באחד הכללים.
האם ניתן לעדכן כללים בלי לעצור את האתר ואת הייצואים?
כן. הכללים נשמרים בנפרד מנתוני הקטלוג, ולכן עריכתם אינה דורשת השבתה: השינויים מיושמים במחזור החלפת הנתונים הבא, והייצואים הנוכחיים ל-Marketplace ממשיכים לפעול לפי הקונפיגורציה הקודמת.
אנו מריצים את גרסת הכללים החדשה על עותק בדיקה של הקטלוג, משווים את התוצאה לפי מדגם ביקורת של מוצרים, ורק לאחר מכן מפעילים אותה בסביבת העבודה. החזרה לאחור — שחזור הקונפיגורציה הקודמת, היא אורכת דקות ואינה משפיעה על פריטים שכבר יוצאו.
מי אחראי לטעויות בכללים וכיצד הן מנוטרות?
אנו מחלקים את האחריות בשלב ההפעלה: לוגיקת הכללים ותקינותה — באחריותנו, עדכניות נתוני המקור במערכת החשבונאית — בצד הלקוח. כל הפעלה של כלל מתועדת בלוג: ניתן לראות איזה תנאי הופעל, איזה מוצר עובד ומה השתנה.
לפי הלוגים הללו אנו מנתחים תקלות בלי התכתבות בסגנון "אצלנו הכול תקין" — יש רשומה קונקרטית ותנאי קונקרטי.
מה יקרה למוצרים שלא נכנסו לאף כלל?
עבורם מוגדר כלל ברירת מחדל: בדרך כלל קטגוריה נפרדת או החרגה זמנית מהייצוא. כך המוצר לא נעלם מהקטלוג בשקט — הוא או עובר לקבוצת רזרבה, או נשאר בקטגוריה הקודמת עד לבדיקה ידנית. בנפרד אנו מנהלים רשימה של פריטים כאלה, כדי לראות אם ה"זנב" גדל והאם הגיע הזמן להרחיב את התנאים.
נדון במשימה שלכם להצגת מוצרים
כדי שהשיחה תהיה עניינית ולא "ספרו בשתי מילים", כדאי לאסוף מראש מינימום של נתוני פתיחה. להלן — מה מבררים ואיזה נתונים מכינים, כדי לחזור עם הערכה ותוכנית, ולא עם מילים כלליות.
מה מבררים בשלב ההתחלתי
- אילו פלטפורמות כבר מחוברות ואילו מתוכננות: מערך כללי הצגת המוצרים שונה מערוץ לערוץ.
- מאין מגיעה הנומנקלטורה: ייצוא מ-1С, מסד נתונים נפרד או ניהול ידני — מכך תלוי מערך ההתאמה.
- כיצד מכינים כעת כרטיסים: תבניות תיאורים, דרישות לתמונות, מאפיינים חובה לפי קטגוריות.
- מי אחראי על התוכן ומי מאשר את הכללים — נדרש בעל החלטה אחד, אחרת האישורים מתארכים.
- מה כואב יותר: פריטים שנדחו, כפילויות, פערי מחירים ומלאי או תיקון ידני לפני כל פרסום.
מה להכין
- ייצוא נומנקלטורה עם קטגוריות ומאפיינים — בצורה שבה היא יוצאת לפלטפורמות כעת.
- דוגמאות לכרטיסים שנדחו עם הניסוחים מהפלטפורמה: מהם רואים אילו כללים אינם מתקיימים.
- רשימת שדות חובה לכל קטגוריה, אם היא כבר קבועה.
- מערך החלפה בין מערכת הנה"ח לאתר: באיזו תדירות ובאיזה כיוון עוברים הנתונים.
- גישות לסביבת בדיקה — עליה בודקים כללים לפני פרסום, בלי לגעת בקטלוג העובד.
שלבים הבאים
- מתקשרים ומנתחים את תהליך ההצגה הנוכחי: היכן הכללים מוגדרים, היכן מופרים, היכן מתקנים ידנית.
- משווים את הנתונים שלכם לדרישות הפלטפורמות ומוצאים פערים.
- קובעים את רשימת הכללים: מאפיינים חובה, פורמטים, מגבלות לפי קטגוריות.
- מכינים הערכה ותוכנית יישום עם שלבים ונקודות בדיקה.
- מתאמים את סדר העבודות ומפעילים על סביבת הבדיקה.
תארו את המשימה — אילו פלטפורמות, מאין הנומנקלטורה ומה מפריע כעת. נחזור עם הערכה ותוכנית שבה יהיה ברור אילו כללים מגדירים ובאיזה סדר.