GTIN, MPN ו־SKU באיקומרס: איזה מזהה מוצר שמים בכל מערכת?

התשובה הקצרה: SKU הוא קוד פנימי של החנות; GTIN הוא מזהה גלובלי של פריט מסחרי, אם הוקצה לו כזה; MPN הוא מספר חלק שהיצרן הקצה; ו־identifier_exists אינו מזהה אלא הצהרה ל־Merchant Center שלמוצר אין מזהי מוצר ייחודיים. לא מעתיקים ערך משדה לשדה כדי להעלים אזהרה. מאמתים מי הקצה את המזהה ולאיזו יחידת מכירה הוא שייך, ורק אז ממפים אותו ל־Shopify, ל־structured data ולפיד.

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

אותו מוצר יכול להחזיק כמה מזהים בלי שהם יהיו חלופיים

GTIN הוא שם כולל לכמה פורמטים מוכרים, בהם UPC, ‏EAN ו־ISBN. המספר שמתחת לברקוד על האריזה עשוי להיות GTIN, אבל גרפיקת הברקוד והמספר שמקודד בה אינם אותו דבר. SKU, לעומת זאת, יכול להיות SHOE-BLK-42 גם אם אין למוצר שום ברקוד. העובדה ששני הערכים ייחודיים בתוך החנות אינה הופכת אותם לאותו סוג מזהה.

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

מקור המזהה קודם לשם השדה

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

שרשרת מקור תקינה עובדת בכיוון אחד: היצרן או בעל המותג מקצה GTIN או MPN; קטלוג המקור שומר את הערך ואת מקורו; מערכת המסחר משייכת אותו ליחידת המכירה הנכונה; ואז ה־structured data והפיד מפרסמים אותו. ערך שנולד בייצוא ל־Merchant Center אינו הופך לנתון מקור, ו־SKU פנימי אינו הופך ל־GTIN מפני שחסר שדה.

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

מטריצת החלטה לפי סוג המוצר

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

Shopify: איפה שומרים כל מזהה?

ב־Shopify, שדה SKU נמצא ברמת המוצר או הווריאנט ומשמש מלאי, דיווח ותפעול. שדה Barcode מיועד ל־GTIN, למשל UPC או EAN. Shopify מבהירה ש־SKU שונה מברקוד: הראשון נוצר לשימוש פנימי, והשני מייצג בדרך כלל מזהה חיצוני מוכר.

בקטלוג עם וריאנטים, המיפוי צריך להיות ברמת יחידת המכירה. חולצה כחולה במידה M וחולצה כחולה במידה L יקבלו בדרך כלל SKU שונה, ולפי תיעוד Google גם GTIN ייחודי לכל וריאציה כאשר הוקצה כזה. המדריך על זהות וריאנטים באיקומרס מרחיב על הבחירה, ה־URL, המלאי והמדידה. כאן הכלל הוא שכל מזהה נצמד ליחידה שאליה הוקצה בפועל.

MPN אינו שדה ליבה אחיד בכל תצורת Shopify. בחיבור Google & YouTube אפשר לטפל בדרישות GTIN או brand ו־MPN לפי המוצר והערוץ; באינטגרציות אחרות המקור עשוי להיות metafield, מערכת PIM או מיפוי באפליקציית פיד. לכן בודקים את הנתיב הפעיל בחנות במקום להניח שהזנה במקום אחד מגיעה אוטומטית לכל יעד. במסגרת בדיקת SEO ל־Shopify בוחנים את פלט העמוד והפיד, לא רק את מסך הניהול.

Merchant Center: GTIN, ‏MPN, ‏brand ו־identifier_exists

Google מגדירה GTIN, ‏MPN ו־brand כמזהי מוצר ייחודיים. הדרישה המדויקת תלויה בסוג המוצר ובמזהים שהיצרן הקצה. כשקיים GTIN תקף, מומלץ מאוד לספק אותו; מוצרים עם מזהים חסרים או שגויים עלולים לקבל חשיפה מוגבלת או להידחות. כשאין GTIN אבל קיימים מותג ומספר חלק של היצרן, השילוב brand ו־MPN עשוי להיות הנתיב המתאים.

identifier_exists מקבל כברירת מחדל משמעות של ״כן״. מגדירים אותו כ־no או false רק אם בטוחים שלמוצר אין GTIN, ‏MPN או brand שהוקצו. הוא לא אומר ״אין לנו כרגע את הנתון״ ואינו דרך לעקוף איכות קטלוג ירודה.

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

Product structured data אינו הפיד, ושניהם אינם מקור האמת

ב־Product structured data קיימים מאפיינים כמו sku, mpn, gtin8, gtin12, gtin13, gtin14 ו־brand. Google מבקשת להשתמש במאפיין GTIN הספציפי המתאים ולהעביר ערך תקין. הסימון עוזר לסווג את המידע; הוא אינו מקצה מזהה ואינו מתקן ערך שגוי.

הפיד ונתוני העמוד יכולים להגיע ממקורות שונים ולהתעדכן בזמנים שונים. התאמה אינה העתקת JSON-LD לפיד, אלא גרימה לכך ששניהם ייגזרו מאותה רשומת קטלוג. אם ה־schema מציג GTIN אחד והפיד אחר, לא בוחרים ערך לפי הכלי שמציג פחות אזהרות. חוזרים למקור, בודקים איזו יחידת מכירה מתוארת בכל URL ומתקנים את הרשומה שמזינה את המערכות.

העבודה הזו שייכת ל־SEO לאתרי איקומרס כאשר הוא מחובר לקטלוג ול־Merchant Center. הוספת markup לבדה אינה מתקנת זהות מוצר, ורשומה תקינה בפיד אינה מבטיחה שהעמוד הגלוי מתאר את אותו פריט.

חוזה זהות לכל יחידת מכירה

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

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

דוגמה: שלושה מוצרים, שלוש החלטות

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

תיק בד במותג פרטי: אם המותג הקצה GTINs, כל יחידת מכירה מקבלת את הערך שלה. אם לא הוקצו, לא ממציאים אותם; משתמשים ב־brand וב־MPN כאשר זה מתאים לדרישות הערוץ, ומתעדים שאין GTIN.

שולחן בהתאמה אישית: כל הזמנה מיוצרת לפי מידות הלקוח ולא קיבלה מזהי יצרן. ל־Shopify עדיין יש product ID ולמערכת ההזמנות יכול להיות SKU, אבל אין להסיק מכך שקיים GTIN. אם מצהירים identifier_exists=false, ההצהרה מתייחסת למזהי היצרן ולא למזהים הפנימיים.

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

אריזה, חבילה והתאמה אישית: מזהים את מה שנמכר, לא את מה שנמצא לידו

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

כאשר החנות מרכיבה bundle בעצמה, לא מניחים שנוצר GTIN חדש. בודקים את כללי Merchant Center למאפיין is_bundle ואת זהות המוצר הראשי, ושומרים בנפרד את רכיבי החבילה לצורך מלאי. ה־SKU הפנימי של החבילה יכול להיות חדש גם כאשר אין לה GTIN עצמאי. שוב, סוג אחד של מזהה אינו מפצה על היעדרו של סוג אחר.

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

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

אבחון שגיאות Merchant Center לפי הסימפטום

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

סדר יישום ו־QA בלי לשבור את הקטלוג

1. ממפים מקורות: מי יוצר SKU, מאיפה מגיע GTIN, היכן נשמר MPN ואיזה חיבור מפרסם את הפיד.
2. מסווגים מוצרים: מותג חיצוני, מותג פרטי, פריט ללא מזהי יצרן, יד שנייה או מוצר מותאם.
3. מאמתים מדגם: משווים אריזה או מקור יצרן, Shopify, העמוד, structured data ו־Merchant Center.
4. מתקנים את מקור האמת: שינוי ידני בפיד בלבד עלול להידרס בסנכרון הבא.
5. בודקים כפילות והתאמה: אותו SKU פעיל לא מייצג יחידות שונות; GTIN לא מועתק בין וריאנטים בלי הקצאה מתאימה.
6. משחררים בקבוצה קטנה: בודקים סטטוס ערוץ, תצוגת עמוד והזמנה לפני עדכון רוחבי.

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

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