פיד מוצרים
קובץ מובנה שמתאר את קטלוג המוצרים לפלטפורמת הפרסום.
חוקי פיד
Feed rules
שכבת תיקון שיושבת בין הקטלוג שלכם לבין הפיד שנשלח, ומשנה ערכים בלי לגעת באתר. שימושית כשמערכת החנות לא יודעת להוציא שדה מסוים, ומסוכנת כשהיא מסתירה בעיה אמיתית במקור.
עודכן:
שכבה שמתקנת בדרך
חוקי פיד הם קבוצת הוראות שרצות על הקובץ אחרי שיצא מהחנות ולפני שהוא נקלט. הן לא נוגעות באתר, לא נוגעות במסד הנתונים, ולא דורשות מפתח. הן מקבלות ערך ומחזירות ערך אחר.
המבנה תמיד זהה: מאיזה שדה לקחת, מה לעשות איתו, ולאיזה שדה לכתוב. להוסיף טקסט קבוע בהתחלה, לחתוך אורך, להחליף ערך אחד באחר, למזג שני שדות לאחד, או לקבוע ערך כשהמקור ריק.
למה זה קיים בכלל: מערכות חנות רבות לא בנו שדה למה שהמפרט מבקש. אין אצלן שדה למצב הפריט, המידה יושבת בתוך התיאור, והמותג נמצא בטקסונומיה ולא בשדה. בלי שכבת התיקון האפשרויות היחידות הן פיתוח או ויתור, ושתיהן יקרות.
הכוח שלהן הוא גם החולשה שלהן. ברגע שהקובץ שיוצא מהחנות אינו מה שנקלט, נוצר פער בין מה שאתם רואים בממשק הניהול לבין מה שקוראים עליכם.
מה הן פותרות באמת
מילוי שדה שלא קיים במקור. הדוגמה הנפוצה היא מצב הפריט: כל הקטלוג חדש, המערכת לא שואלת על זה, ושורה אחת קובעת ערך אחיד. זה שימוש נקי לחלוטין.
התאמת ערכים לרשימה סגורה. החנות כותבת שלוש מילים בעברית על מלאי, והמפרט מכיר מילים מוגדרות בלבד. מיפוי בין השניים הוא בדיוק מה שהשכבה הזו נועדה לו.
בנייה של שם פריט בעל מבנה. זה השימוש שמחזיר הכי הרבה, והוא מפורט בכותרת מוצר בפיד: לחבר מותג, דגם ומאפיין לפי סדר קבוע, במקום לשלוח את מה שהעורך הקליד באתר.
וניקוי של שאריות. שם שנגרר אליו קוד פנימי, תיאור שמכיל תגיות עיצוב, כתובת תמונה עם פרמטר שמוריד את הרזולוציה. אלה תיקונים משעממים שאיש לא יבנה בשבילם פיתוח.
מתי הן הופכות לכיסוי על בעיה
הקו נמצא במקום אחד: האם התיקון משנה ניסוח, או משנה עובדה. חוק שמסדר את סדר המילים בשם הפריט מנסח. חוק שכותב שהפריט במלאי כשבחנות הוא אזל משקר, וזה לא תיאור דרמטי אלא תיאור מדויק של מה שקורה.
יש גם אזור אפור שכדאי לזהות. חוק שממלא ערך חסר בערך סביר, למשל מותג ברירת מחדל לכל הפריטים בקטגוריה, נכון היום ויהפוך לשגוי ברגע שתוסיפו ספק שני. אף אחד לא יזכור שהחוק קיים.
והבעיה השקטה ביותר: החוקים לא מתועדים. הם נכתבים בממשק, בשלבים, על ידי כמה אנשים לאורך שנים. אחרי שנתיים אף אחד לא יודע למה השם של הפריט נראה כמו שהוא נראה, ולמה הוא לא תואם למה שכתוב באתר.
למה זה נוגע לתשובות ולא רק למודעות
הקובץ המתוקן הוא הניסוח הנקי ביותר שקיים של הקטלוג שלכם, והוא בדיוק סוג המידע שמנוע זקוק לו כשנשאלת שאלת קנייה: ערכים אחידים שאפשר להשוות, במקום טקסט חופשי שצריך לפרש. זה אחד הקצוות של העבודה על הופעה בשאלות קנייה.
כאן צריך להיות מדויקים לגבי מה מתועד. גוגל מתארת בפומבי שחוויות הקנייה במצב ה-AI שלה נשענות על גרף הקניות, ושגרף הקניות ניזון מקטלוגים של סוחרים לצד סריקת רשת. ל-OpenAI יש מפרט משלה להגשת מוצרים על ידי מוכרים, וזה ערוץ נפרד לגמרי ולא קריאה של חשבון הקטלוג שלכם בגוגל.
כל השאר הוא הסקה שלנו, ואנחנו מסמנים אותה ככזו: מכונה שקוראת קטלוג מסודר עושה פחות ניחושים ממכונה שקוראת עמוד מוצר. אין הצהרה של אף פלטפורמה שקושרת בין חוקי הפיד שלכם לבין מה שנאמר עליכם בתשובה, ומי שמוכר קשר כזה כעובדה חורג ממה שידוע.
מה שכן נובע ישירות: סתירה בין מה שהקובץ מצהיר לבין מה שכתוב בעמוד היא שני מקורות שחלוקים על אותה עובדה. זה מצב שאתם יצרתם, וחוקי הפיד הם המקום שבו הכי קל ליצור אותו בלי לשים לב.
איך זה נראה בפועל
תרחיש מומצא: חנות מקוונת לכלי עבודה, כשלושת אלפים פריטים משבעה ספקים. השמות שמגיעים מהספקים לא אחידים בכלל. אחד כותב מותג ואז דגם, אחר פותח בקטגוריה, ושלישי דוחף לשם את קוד המוצר הפנימי שלו.
כדי לסדר את זה נכתבים שני חוקים. הראשון מוחק מהשם רצף של אותיות וספרות שנראה כמו קוד פנימי. השני בונה שם חדש: מותג, סוג הכלי, ואז המאפיין המרכזי.
העבודה מצליחה, ושנה אחר כך מתווסף ספק שמוכר סדרה שבה קוד הדגם הוא חלק מהשם המסחרי. החוק הראשון מוחק אותו. עכשיו יש בקטלוג שמונים פריטים ששמם המוצהר אינו מזהה איזה דגם הוא זה, ובעמוד באתר הדגם מופיע בבירור.
אף מערכת לא מסמנת שגיאה, כי מבחינת המפרט הכול תקין: יש שם, הוא באורך סביר, והוא אינו ריק. מה שנשבר הוא ההתאמה לשאלה. קונה ששואל על דגם מסוים לא יקבל את החנות הזאת כתשובה, והסיבה יושבת בשורה שנכתבה שנה קודם בשביל בעיה אחרת לגמרי.
זוויות שונות
לחנות קטנה
כשיש מאה פריטים, לעיתים קרובות זול יותר לתקן בחנות עצמה מאשר לבנות שכבת חוקים. היתרון בתיקון במקור הוא שהאתר והקובץ אומרים אותו דבר, וזה מצב שקל לתחזק. שכבת חוקים בחנות קטנה נוטה להפוך לתיק של החלטות שאיש לא זוכר.
לחנות עם ספקים מרובים
כאן השכבה הזו כמעט בלתי נמנעת, כי הנתונים מגיעים בשבעה סגנונות. הכלל שעובד הוא לכתוב חוקים לפי ספק ולא לפי הקטלוג כולו, גם אם זה מייגע יותר. חוק רוחבי שנכתב בגלל ספק אחד נוחת בסוף גם על הפריטים של השאר.
למותג שמוכר ישירות
יש לכם שליטה מלאה על הנתונים, ולכן רוב התיקונים בכלל לא צריכים לחיות בשכבה הזו. מה שכן שווה כאן הוא אחידות של שמות על פני קטגוריות, וזה דווקא נוח לעשות במקום אחד. חוק אחד לכל קטגוריה קריא יותר מעורך שממציא כל פעם מחדש.
מה זה אומר בפועל
החזיקו מסמך אחד, פשוט, שבו לכל חוק כתובים שלושה דברים: מה הוא עושה, מתי נכתב, ובשביל איזו בעיה. זה נשמע בירוקרטי עד הפעם הראשונה שבה מישהו מנסה להבין למה הקטלוג מתנהג מוזר. כלל שני: כל חוק שנכתב בגלל ספק אחד מוגבל לפריטים של אותו ספק. וכלל שלישי, והוא החשוב: כשחוק מתקן עובדה ולא ניסוח, סמנו אותו כחוב ותקנו במקור. שכבת התיקון היא מקום מצוין לסדר בו נתונים, ומקום גרוע להחזיק בו את האמת.
איך בודקים את זה לבד
- פתחו את רשימת החוקים הפעילים וספרו אותם. אם המספר מפתיע אתכם, זה כבר ממצא.
- לכל חוק שאלו מה קורה לפריט חדש שייכנס מחר. חוקים רבים נכתבו למצב שכבר לא קיים.
- בחרו חמישה פריטים מקטגוריות שונות, והשוו שדה מול שדה בין מה שיוצא מהחנות לבין מה שנקלט. ההבדלים הם החוקים בפעולה.
- חפשו חוקים שכותבים ערך קבוע לשדה שאמור להשתנות. ערך קבוע במלאי או במחיר הוא הדבר החמור ביותר שאפשר למצוא כאן.
- השוו שם של פריט בקובץ מול הכותרת באתר. אם הם רחוקים זה מזה, בדקו שההבדל מכוון ולא תוצר לוואי.
- שמרו עותק של הקובץ לפני ואחרי. חודש קדימה, כשמשהו יישבר, ההשוואה בין שני העותקים תמצא את הסיבה בדקות.
המלכודת
המלכודת המרכזית היא שהשכבה הזו מסתירה במקום לטפל. תיקון בקובץ נראה כמו פתרון, והבעיה נשארת בחנות, ממשיכה להופיע באתר, ונוחתת בכל ערוץ אחר שקורא אתכם. אחרי שנתיים של תיקונים כאלה יש לכם שני קטלוגים שונים ואף אחד לא יודע איזה מהם נכון. המלכודת השנייה היא חוק רוחבי שנכתב בגלל מקרה פרטי: הוא עובד מצוין על עשרה פריטים ופוגע בשלוש מאות. והשלישית היא היעדר תיעוד, שהופך כל חוק ישן לסיכון, כי אף אחד לא מעז לגעת בו ואף אחד לא יודע מה יקרה אם ימחק.
מתי זה לא רלוונטי לכם
מי שמוכר שירות, ייעוץ או עבודה מותאמת אין לו קובץ ואין לו מה לתקן. גם חנות קטנה עם קטלוג נקי, שהשדות בה מלאים כמו שצריך במקור, לא צריכה שכבה נוספת, והוספתה תיצור רק מקום שני שבו מחזיקים אמת. ומי שמוכר בלעדית בשוק מקוון של צד שלישי מקבל את מבנה הנתונים מהפלטפורמה, ואין לו את הידית הזו בכלל.
שאלות נפוצות
עדיף לתקן בחוקים או בחנות?
בחנות, כשאפשר, כי אז האתר והקובץ מסכימים וכל ערוץ אחר נהנה מהתיקון. בחוקים, כשמדובר בהתאמה לפורמט שרלוונטית רק לערוץ הזה, או כשתיקון במקור דורש פיתוח שלא מוצדק.
חוקים משפיעים על מה שמנועי AI יודעים עליי?
אין הצהרה של אף מנוע שקושרת בין השניים, וכל טענה כזו היא הסקה. מה שכן ידוע: גוגל מתארת את גרף הקניות שלה כניזון מקטלוגים של סוחרים, ושהוא משמש את חוויות הקנייה במצב ה-AI. מעבר לזה אנחנו לא מתיימרים.
כמה חוקים זה יותר מדי?
אין מספר. המבחן אינו כמות אלא האם אפשר להסביר כל אחד מהם בשורה. עשרים חוקים מתועדים הם מצב בריא יותר משלושה חוקים שאיש לא יודע למה נכתבו.
מה קורה כשחוק סותר את מה שכתוב באתר?
במערכות שמשוות בין הקובץ לעמוד הפריט עלול להיפסל. מעבר לפסילה, זו סתירה בין שני מקורות שאתם אחראים לשניהם, וזה בדיוק המצב שמוריד את הערך של נתונים מסודרים.
מי אמור להיות אחראי על זה?
אדם אחד עם הקשר עסקי וגישה טכנית. הכשל הנפוץ הוא פיצול בין שיווק לפיתוח, שבו מי שכותב את החוקים לא יודע מה השתנה בקטלוג, ומי שמשנה את הקטלוג לא יודע שהחוקים קיימים.
מונחים קשורים
פיד מובנה
קובץ או ממשק שמתאר כל מוצר בשדות קבועים ולא בטקסט חופשי: שם, מחיר, מטבע, זמינות, מזהים, כתובת עמוד ותמונה.
כותרת מוצר בפיד
השדה שנשלח כשם הפריט, ולא בהכרח הכותרת שמופיעה באתר.
Google Merchant Center
המערכת שאליה מעלים את קטלוג המוצרים אצל גוגל, ומשם הוא מוזרם למודעות שופינג ולקמפייני Performance Max.
זמינות מלאי
השדה שמצהיר אם הפריט במלאי, אזל או בהזמנה מראש.
מזהי מוצר
שלושת השדות שמזהים פריט: מותג, מספר קטלוגי של היצרן ומזהה גלובלי.
להרחבה
הערך נבדק מול המקורות הרשמיים של הפלטפורמות. כשמשהו אינו ידוע, כתוב כאן שהוא אינו ידוע. שינויים מתועדים בארכיון העדכונים.
בואו נדבר.
בלי מצגת, בלי התחייבות ובלי שיחת מכירה. עשרים דקות שבסופן תדעו אם יש כאן משהו בשבילכם.
- מה המוצר ומי הלקוח שלכם
- איך נמדדת אצלכם המרה היום
- מאיזה תקציב זה מתחיל להיות הגיוני
לא בקטע של טפסים? info@boostit.co.il