עדכון קטלוג: איך לעדכן מאות מוצרים בלי לשבור את הקטלוג?

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

להבין למה עדכון קטלוג שובר דברים רחוקים

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

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

• שינוי בשם מותג מנתק את המוצר מהפילטר שמסנן לפי מותג
• שינוי במק"ט מייצר מוצר חדש במקום לעדכן קיים
• שינוי בקטגוריה מוציא את המוצר מכל דף מקשר שהצביע עליו
• שינוי בשדה מלאי מסתיר קוביית מוצר מהגריד בלי הודעה
• שינוי בכותרת שובר קישורים פנימיים שהצביעו על הכתובת הישנה

ברגע שמבינים את שרשרת התלויות הזאת, ההיגיון של העבודה משתנה. לא בודקים אם הקובץ נכון אלא בודקים אם האתר אחרי הייבוא נראה כמו שתכננתם.

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

למפות את השדות לפני שנוגעים בשורה אחת

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

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

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

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

בגדול, המיפוי הזה הוא גם מה שמאפשר לכם להעביר את העבודה למישהו אחר. בלי מפה כל עדכון תלוי באדם אחד שזוכר מה מחובר למה, ועם מפה זה הופך למשימה שאפשר למסור.

לעבוד על עותק ולא על הקטלוג החי

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

מה שקורה בפועל בלי הצעד הזה הוא שאין נקודת חזרה. כשמתגלה שהעדכון פגע ב-40 מוצרים, אין קובץ שמראה איך הם נראו לפני, ומשחזרים לפי זיכרון.

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

העותק הגולמי הוא גם כלי הבדיקה הכי מדויק שיש. אחרי הייבוא מייצאים שוב, משווים את שני הקבצים, ורואים שחור על גבי לבן אילו שדות באמת השתנו.

בחנות כלי עבודה עם 2,000 מק"טים שעברתי עליה, ההשוואה הזאת גילתה שייבוא של מחירים בלבד שינה בשקט גם את שדה יצרן ב-180 מוצרים, כי העמודה הוזזה בקובץ שהגיע מהספק. בלי ההשוואה זה היה מתגלה רק כשמישהו היה מנסה לסנן לפי יצרן.

לזהות מה בדיוק אמור להשתנות

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

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

1. אילו שורות בדיוק נכללות, לפי תנאי שאפשר לסנן לפיו
2. אילו שורות מוחרגות במפורש ולמה
3. אילו עמודות מותר לגעת בהן וכל השאר קפוא
4. מה הערך החדש, ומאיפה הוא מגיע
5. איך בודקים אחרי הייבוא שזה עבד

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

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

לסנן במקום להחליף גורף

מצא-החלף על כל הקובץ הוא המקור הנפוץ ביותר לנזק בעדכון קטלוג. המחרוזת שחיפשתם מופיעה גם בתיאור של מוצר לא קשור, גם בשם קובץ תמונה, וגם באמצע מק"ט של סדרה אחרת.

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

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

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

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

לבדוק על קבוצה קטנה לפני הכל

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

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

• מוצר עם וריאציות ומוצר בלי
• מוצר במבצע ומוצר במחיר רגיל
• מוצר ששייך לכמה מחלקות ומוצר ששייך לאחת
• מוצר עם מפרט מלא ומוצר עם שדות ריקים
• מוצר שהיה אזל מהמלאי לאחרונה

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

שווה לבדוק גם את דף הקטגוריה שמעל, לא רק את דף המוצר. הגריד הוא המקום שבו רואים מיד אם קוביית מוצר איבדה תמונה או אם מוצר קפץ למקום לא הגיוני בסדר התצוגה, ובמובייל עם 2 מוצרים בשורה זה בולט אפילו יותר.

לשמור על המק"ט כעוגן יציב

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

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

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

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

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

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

להפריד בין עדכון נתונים לעדכון מבנה

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

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

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

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

למדוד מה קרה אחרי הייבוא

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

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

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

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

לתעד את מה שעשיתם בזמן אמת

תיעוד נשמע כמו מותרות עד הפעם הראשונה שמישהו שואל למה מוצר מסוים נעלם לפני חודשיים. שורה אחת ליומן אחרי כל ייבוא פותרת את זה לחלוטין.

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

1. תאריך ושעה של הייבוא
2. אילו עמודות נגעו ובכמה שורות
3. שם קובץ הגיבוי שנשמר לפני
4. מה נבדק אחרי ומה נמצא
5. מה נשאר פתוח לסבב הבא

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

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

לתעדף מוצרים לפי מכירות ולא לפי סדר בקובץ

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

מהחנויות שעברתי עליהן, בערך 30% מהמק"טים מייצרים את רוב ההזמנות, והשאר יושבים על המדף הדיגיטלי בלי לזוז. הסדר הנכון הוא להתחיל מהקבוצה שמזיזה כסף.

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

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

לוותר על עדכון ידני של מה שחוזר כל חודש

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

לא צריך לקפוץ ישר לאוטומציה מלאה. השלב הראשון הוא פשוט לקבע את התהליך: אותו קובץ, אותן עמודות, אותה בדיקה, אותו סדר.

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

לטפל בשגיאות ייבוא לפי סוג ולא לפי שורה

דוח שגיאות אחרי ייבוא נראה מפחיד כשיש בו 400 שורות, אבל כמעט תמיד מדובר בשלוש או ארבע בעיות שחוזרות. מיון לפי סוג השגיאה מכווץ את הרשימה למשהו שאפשר לטפל בו בשעה.

במקום לתקן שורה שורה, מתקנים את הסיבה בקובץ המקור ומייבאים שוב. אחרת אותה שגיאה תחזור בייבוא הבא בדיוק באותו מקום.

• שדה חובה ריק, בדרך כלל בגלל עמודה שהוזזה
• ערך שלא קיים ברשימת הערכים המותרים
• מק"ט כפול או מק"ט עם רווח נסתר בסוף
• פורמט מספר או תאריך שהמערכת לא מזהה
• קידוד שבור שהופך עברית לג'יבריש

כשיש חשד לכפילויות, שווה לעבור על זיהוי מוצרים כפולים לפני הייבוא הבא, כי כפילות שנכנסה פנימה עולה הרבה יותר להוציא מאשר למנוע.

לוודא שהתוכן לא נמחק יחד עם הנתונים

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

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

• למחוק מהקובץ כל עמודת תוכן שלא מתכוונים לעדכן
• לבדוק על מוצר בודד מה קורה כשהתא ריק
• לשמור ייצוא נפרד של עמודות התוכן בלבד
• לא לתת לקובץ ספק לדרוס תיאורים שנכתבו בחנות
• לבדוק גם ALTים וגוגל טייטל, לא רק את גוף התיאור

התוכן הוא הנכס היקר ביותר בקטלוג כי הוא היחיד שאי אפשר לייצא שוב מהספק. במסגרת A+Master אני רואה שדפים שעברו כתיבה מלאה מביאים שיפור המרות של 15-30%, וייבוא רשלני אחד מוחק את זה בלי אזהרה.

שאלות נפוצות על עדכון קטלוג בהיקף גדול

כמה מוצרים בטוח לעדכן בייבוא אחד

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

האם צריך גיבוי לפני כל עדכון קטלוג

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

מה עושים כשעדכון קטלוג מחק מוצרים בטעות

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

כל כמה זמן כדאי לעשות סבב עדכון קטלוג יזום

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

קטלוג מעודכן הוא תוצאה של שיטה, לא של יום ארוך מול אקסל

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

אחרי 10 שנים ו-60+ חנויות אני יכול להגיד שרוב הנזקים שראיתי בקטלוגים לא נגרמו מחוסר ידע טכני אלא מדילוג על אחד מהשלבים האלה בגלל לחץ זמן. הדילוג תמיד חוזר, ותמיד בעיתוי גרוע יותר.

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

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