בדף הזה מוסבר על השיטות המומלצות ליצירת פרטי הקטלוג ולאכלוס נתוני הקטלוג.
סקירה כללית
הקטלוג הוא אוסף של אובייקטים של מוצרים.
לנתוני הקטלוג שמייבאים ל-AI Commerce Search יש השפעה ישירה על איכות המודל שמתקבל, ולכן על איכות תוצאות החיפוש וההמלצות. ככלל, ככל שפרטי הקטלוג מדויקים וספציפיים יותר, כך איכות המודל גבוהה יותר.
חשוב לשמור על עדכניות הקטלוג. אפשר להעלות שינויים בקטלוג בתדירות שנדרשת, ורצוי מדי יום לקטלוגים שמשתנים בתדירות גבוהה. אפשר להעלות (patch) פריטי מוצרים קיימים, ורק השדות שהשתנו יעודכנו. העלאת פרטי הקטלוג לא כרוכה בתשלום. מידע נוסף מופיע במאמר בנושא שמירה על עדכניות הקטלוג.
ענפים בקטלוג
מעבר בין ענפים עלול להשפיע לרעה על תוצאות החיזוי.ענפים של קטלוגים עם חיפוש
אם אתם משתמשים בחיפוש, אתם יכולים להשתמש בענפי קטלוג כדי לבדוק נתונים חדשים שהעליתם אופליין לפני שאתם מפרסמים אותם באתר.
אפשר להשתמש בעד שלושה סניפים, שמזוהים בתור 0, 1 ו-2. האתר הפעיל שלך מפנה אל default_branch לקבלת נתוני הקטלוג. מציינים איזה ענף הוא default_branch (ברירת המחדל היא ענף 0) באמצעות setDefaultBranch או הכרטיסייה 'נתונים' במסוף AI Commerce Search ב-Gemini Enterprise for Customer Experience. לאחר מכן, האתר שלכם משתמש בנתוני הקטלוג שסופקו על ידי הענף שאליו default_branch מצביע.
לדוגמה, נניח שהערך של default_branch הוא מזהה הסניף 0, כך שהאתר שלכם משתמש בנתוני הקטלוג שהעליתם לסניף הזה. אפשר להעלות נתוני קטלוג חדשים לענף 1 ולצפות בהם בתצוגה מקדימה. אחרי שמוודאים שהקטלוג הועלה בצורה תקינה, אפשר לעבור לענף 1 כאל default_branch הפעיל.
יכולות לעבור עד 30 דקות עד שהמטמון של הקטלוג יתעדכן אחרי מעבר בין ענפים.
אם אתם משתמשים בהמלצות, כדאי להשתמש רק בענף ברירת המחדל בגלל העיכוב בעדכון בזמן המעבר בין ענפים. אם יש הבדל גדול בנתונים בין הענפים, עיכוב בעדכון יכול להשפיע לרעה על תוצאות התחזית.
פרטי המוצר הנדרשים
השדות הבאים הם שדות חובה, ועליכם לספק להם ערכים כשאתם יוצרים פריטי מוצרים בקטלוג. הם גם צריכים להיות זהים לערכים שמשמשים במסד הנתונים הפנימי של המוצרים, ולשקף בצורה מדויקת את המוצר שמיוצג, כי הם נכללים באימון המודלים.
במקרים מסוימים, יש למלא גם שדות אחרים. רשימה מלאה של כל שדות המוצרים מופיעה בדף העזר בנושא Product.
כל פרטי המוצר שתספקו יכולים לשמש לשיפור האיכות של ההמלצות ותוצאות החיפוש. חשוב למלא כמה שיותר שדות.
| שדה | הערות |
|---|---|
name
|
השם המלא והייחודי של משאב המוצר. חובה לכל השיטות של Product, למעט import. במהלך
הייבוא, השם נוצר באופן אוטומטי ואין צורך לספק אותו באופן ידני.
|
id
|
מזהה המוצר שמשמש במסד הנתונים של המוצרים. השדה 'מזהה' חייב להיות ייחודי בכל הקטלוג. אותו ערך משמש כשמתעדים אירוע של משתמש, והוא גם מוחזר על ידי השיטות predict ו-search.
|
title
|
שם המוצר מתוך מסד נתוני המוצרים. מחרוזת מקודדת ב-UTF-8. מוגבל ל-1,250 תווים. |
categories
|
קטגוריות מוצרים. כל מוצר חייב להיות משויך לקטגוריה אחת לפחות.
אם מוצר שייך ליותר מקטגוריה אחת, צריך לחזור על השדה לכל קטגוריה.
הערך צריך להיות מחרוזת לא ריקה בקידוד UTF-8, באורך של עד 5,000 תווים. תמיד מציינים את הנתיב המלא של הקטגוריה, לדוגמה:
["Sports & Fitness > Athletic Clothing > Shoes"].
|
קטגוריות בקטלוג
בקטע הזה מתוארת מבנה הקטלוג ומוסבר איך להגדיר אותו לשימוש בטקסונומיה ובסינון.
מבנה הקטלוג
השדה categories בקטלוג צריך להכיל את נתיב הקטגוריה המפורט ביותר לכל מוצר. אין צורך בקטגוריות הורה, ואסור לכלול אותן.
דוגמה למבנה של קטלוג:
- נכון:
categories: ["Flowers, Cards, Occasion > Seasonal Items > Christmas"] - לא נכון:
categories: ["Flowers, Cards, Occasion", "Flowers, Cards, Occasion > Seasonal Items", "Flowers, Cards, Occasion > Seasonal Items > Christmas"]
קטגוריות הורה
קטגוריות האב של מוצר מסוים לא צריכות להיכלל בשדה categories. כדי לסנן את המוצרים שמוצגים בדפדפן, צריך להשתמש במאפיינים מותאמים אישית אחרים.
שמות של קטגוריות
צריך לבחור את שמות הקטגוריות בקפידה כדי למנוע הוספה של מילות מפתח שגויות ולשפר את הביצועים. שימוש במונחים ספציפיים ומדויקים יותר משפר את הרלוונטיות ומפחית את הבעיות.
- מומלץ: Frozen Food > Frozen Fruits
- לא מומלץ: Frozen Fruits & Vegetables > Frozen Fruits
מבנה ספציפי לפרויקט ברמת הקטלוג
יוצרים קטלוג אחד לכל שפה. אם העסק שלכם פועל בכמה מדינות, אתם יכולים להשתמש באותו קטלוג כדי לספק תוצאות חיפוש במדינות שונות.
צריך לספק מחירים שנקבעים לפי המלאי בחנויות המקומיות, באותו מטבע בכל המדינות. אם המחירים שונים במדינות שונות, צריך ליצור מלאי בחנות המקומית לכל מדינה. מציינים שם את המחירים.
כדי לשפר את תוצאות החיפוש, צריך לציין את שם כל מדינה בתור SearchRequest.entity ובתור UserEvent.entity. השתמשו בישויות של מדינות למטרות דירוג בלבד.
מבנה המוצר
כשמנהלים את קטלוג המוצרים ב-AI Commerce Search, חשוב להבין איך המערכת מטפלת במאפיינים של מוצרים ראשיים ושל וריאציות של מוצרים, כדי שהחיפוש וההמלצות יהיו יעילים. הגדרות המק"ט של המוצר קובעות את היררכיית הקטלוג.

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


היררכיות של סיווג מוצרים
יש שלוש היררכיות עיקריות לסיווג מוצרים, שמבוססות על שלושת הסוגים ברמת המוצר:
- המוצר הראשי: המוצר הראשי הוא כמעט תמיד רק placeholder של מידע (משותף), והמוצרים המשניים הם מק"טים בפועל שאפשר לרכוש. לדוגמה, חולצות טי-שירט יתאימו יותר למבנה היררכי, כפריטים ראשיים עם קבוצת הווריאציות התואמת שלהם. כל וריאנט מייצג מק"ט נפרד (לכל מידה), וכל פריט ראשי מייצג קבוצה של מק"טים, כאשר כל מק"ט הוא מידה שונה של סגנון חולצת טי כולל. הארגון הזה לפי מבנה מק"ט מאפשר להציג בחלוניות של תוצאות החיפוש וההמלצות מגוון של סגנונות חולצות טי. הוא מאפשר לקונים להתמקד בפריט ראשי מסוים (סגנון) כדי לבחור את הווריאציה (גודל) שהם רוצים לקנות.
- רק ראשי: לפי סוגי ייעודי המוצרים האלה, מוצרי מכולת מתאימים יותר לקטלוג כמוצרים ראשיים, שכל אחד מהם מורכב ממוצר עם מק"ט יחיד, כמו
"bananas, fresh". - אוספים: אוספים מקבצים מוצרים קשורים שלקוחות עשויים לקנות. כדי לייצג אותם בצורה מדויקת במודל הדירוג מחדש, AI Commerce Search כולל לוגיקה שמזכה אותם ברכישות. לדוגמה: קונה לוחץ על מוצרים בסט מצעים, ואז מוסיף לעגלת הקניות או רוכש מוצר ראשי באוסף הזה. הרכישה משויכת לאוסף, והמודל מייצג בצורה מדויקת את הפופולריות והערך של האוספים.
מוצרים עם וריאציה
אם למוצרים יש וריאציה, כדאי להגדיר אותם כפריט ראשי עם וריאציה, כי יש לכך כמה יתרונות, כולל:
- בדף החיפוש יש תוצאות מגוונות שמוצגות למשתמשי הקצה. אחרת, אם הווריאציות היו מוצגות כמוצרים ראשיים, דף תוצאות החיפוש היה מלא באותם מוצרים.
- למוצרים יש תוכנית דירוג עשירה יותר, כי מוצרים ראשיים עם וריאציות מדורגים טוב יותר אם וריאציה מסוימת מקבלת יותר אינטראקציות. המידע הזה עוזר לבצע דירוג מחדש ואופטימיזציה של הרווחים.
- קלות התחזוקה של הקטלוג. אם יש שינוי במאפיין של קבוצת מוצרים שההבדל ביניהם הוא רק במידה, אפשר לבצע את השינוי באמצעות מבנה של וריאציות ראשיות. למשל, אפשר לשנות את המאפיין ברמה הראשית במקום לשנות כמה וריאציות ראשיות.
- תכונות API ושדות של תשובות לחיפוש של מפתחות איחוד לתצוגה אחת של וריאציות ושדות שאפשר לאחזר נתמכים רק בווריאציות.
- התשובה לחיפוש מכילה פרטים מינימליים על הפריט הראשי ופרטים נוספים על הווריאציות. לכן תמיד צריך להוסיף או להרחיב את התשובה לחיפוש עם פרטים נוספים, שאפשר לקבל מ-AI Commerce Search אם הם מסומנים כפרטים שאפשר לאחזר.
הגדרת קטלוג המוצרים
כשמתכננים את קטלוג המוצרים, צריך להחליט אם הוא יכיל מוצרים שמוגדרים רק כראשיים, מוצרים שמוגדרים כראשיים ווריאציות, או שילוב של שתי האפשרויות. אפשר לחשוב על זה במונחים של מבנה המק"טים של המוצרים. המוצרים שלכם יכולים להיות פריטים ראשיים, שיכולות להיות להם וריאציות.
בהתאם לאופן שבו מוגדרים המק"טים של המוצרים, כדאי לבדוק את האפשרויות להגדרת קטלוג המוצרים:
- רוצים שהמק"ט יוצג כתוצאת חיפוש או כהמלצה נפרדת: SKU=primary
- המק"ט צריך להיות חלק מקבוצה של מק"טים דומים: מק"ט=וריאציה, קבוצת מק"טים=ראשי
- שילוב של שתי האפשרויות: SKU=primary, SKU=variant, group of SKUs=primary

אם בדף פרטי המוצר מוצג בורר אפשרויות, מידות או צבעים, בדרך כלל האפשרויות האלה מועלות כווריאציות לקטלוג המוצרים. כדאי לחשוב אם אתם רוצים שסוגים שונים של אותו מוצר עם מאפיינים שונים כמו גודל וצבע יופיעו כתוצאת חיפוש אחת או כתוצאות חיפוש נפרדות. לדוגמה, אם אתם מוכרים ספר בכריכה רכה ובכריכה קשה, אתם יכולים להחליט אם אתם רוצים שכל מהדורה תופיע כתוצאת חיפוש נפרדת (מק"ט = ראשי), או ששתיהן יופיעו כתוצאה אחת (מק"ט = וריאציה, קבוצת מק"טים = ראשי).
כשמגדירים את קטלוג המוצרים, חשוב לזכור שההמלצות ותוצאות החיפוש כוללות רק פריטים ראשיים.
מוצרים עיקריים מינימליים
אם הגעתם למסקנה שצריכים להיות בקטלוג גם פריטים ראשיים וגם וריאציות, כלומר קבוצות מק"טים ומק"טים, אבל יש לכם כרגע רק מק"טים, תצטרכו ליצור פריטים ראשיים לקבוצות המק"טים. הצבעים העיקריים האלה נקראים לפעמים צבעים עיקריים וירטואליים או צבעים עיקריים מזויפים.
מספיק שפריטים ראשיים יכילו מידע מינימלי: id, title ו-categories.
אם לא מציינים את הערך type, סוג המוצר מוגדר כברירת מחדל כראשי. אם אתם מייבאים, אתם לא צריכים לציין את name. מידע נוסף זמין בקטע הקודם, פרטי מוצר נדרשים.
ייבוא קטלוג
אם הקטלוג שלכם נמצא ב-Cloud Storage, ב-BigQuery או במקום אחסון אחר, אתם יכולים לייבא נתונים בכמות גדולה.
מידע מפורט על העלאת קטלוג זמין במאמר ייבוא פרטי קטלוג.
האם כתובת ה-URL של המוצר נכונה
השדה product.uri הוא כתובת ה-URL הקנונית שמקשרת ישירות לדף פרטי המוצר. הוא צריך להיות URI שניתן לסריקה באופן ציבורי, ולא להיות מוסתר מאחורי חומת אש שדורשת התחברות או הרשאה. הסיבה לכך היא שהקצה העורפי סורק את דף האינטרנט של ה-URI ומפיק כמה שיותר מידע, שמשמש לדירוג הרלוונטיות והפופולריות. הקצה העורפי גם קובע את אופן האינטראקציה עם ה-URI באינטרנט, כולל קישורים נכנסים. שם הדומיין ברמה העליונה צריך להיות זהה בכל כתובות ה-URI של המוצרים.
אם אותו מוצר מופיע בכמה אתרים של באנרים, כדאי להשתמש בתכונה 'מספר ישויות'. צריך לפנות לצוות ניהול החשבון בנושא הזה.
AI Commerce Search משתמש בכתובות URL של מוצרים כדי להעשיר את תיאורי המוצרים. אם אתם משתמשים בכתובת URL שונה בקטלוג המוצרים מאשר באתר עצמו, אתם צריכים לוודא ששתי כתובות ה-URL מפנות לאותו מוצר ושהמידע בהן כמעט זהה.
כתובות URL של מוצרים משפרות את הקטלוגים בכך שהן:
- העשרת נתוני מוצרים: AI Commerce Search מחלץ מידע נוסף על ידי סריקת ה-URI של המוצר, מזהה המשאב הייחודי שמאחורי המיקום המדויק של כל מוצר באינטרנט (כתובת URL). התהליך הזה עוזר להפיק פרטים ואותות נוספים מדפי האינטרנט המקושרים. ההבנה המעמיקה יותר של המוצרים שמתקבלת באמצעות סריקת URI תורמת ישירות לאיכות הנתונים בקטלוג.
- שיפור האיכות והרלוונטיות של החיפוש: אותות מהאינטרנט שנאספים מכתובות ה-URL שנסרקו משמשים לשיפור איכות החיפוש. בסוף התהליך, המערכת משתמשת במידע שנסרק, כולל האינטראקציה עם ה-URI באינטרנט, למשל כשמשתמש לוחץ על קישורי חזרה, כדי לתת ציון רלוונטיות ופופולריות בתוצאות החיפוש.
- מספקות בסיס לאימון המודל: בנוסף למזהה המוצר, לשם הפריט, להיררכיית הקטגוריות ולמחיר, כתובות ה-URL נחשבות לאחד מהשדות העיקריים שמשמשים כקלט לאימון המודל.
כדי להפיק את המרב מכתובות ה-URL של המוצרים, כדאי לפעול לפי השיטות המומלצות הבאות:
- דף האינטרנט המקושר צריך להיות נגיש לציבור ולהיטען בצורה תקינה, ולא להיות ממוקם מאחורי חומת תשלום או חומת אימות.
- כל מזהה URI צריך להיות ייחודי ולהפנות באופן עקבי לדף האינטרנט הנכון של המוצר. התוכן שלו צריך לשקף בצורה מדויקת את פרטי המוצר בקטלוג. שם הדומיין ברמה העליונה צריך להיות זהה בכל כתובות ה-URI של המוצרים.
מלאי מוצרים
מלאי המוצרים כולל:
המחיר, כולל המחיר הנוכחי והמחיר המקורי
זמינות, למשל במלאי, חסר במלאי, בהמתנה להשלמת מלאי והזמנה מראש
כמות זמינה
פרטי אספקה כמו איסוף בחנות, משלוח לחנות ומשלוח ביום המחרת
יש שני סוגים של מלאי: ברמת המוצר וברמת החנות המקומית.
מלאי ברמת המוצר
קמעונאים שמוכרים רק אונליין צריכים לציין את המלאי ברמת המוצר. המחיר, הזמינות ונתוני מלאי אחרים מוגדרים לכל מוצר בקטלוג.
מידע נוסף על מלאי ברמת המוצר, כולל איך לשמור על נתוני המלאי, זמין במאמר עדכון המלאי ל-AI Commerce Search.
מלאי בחנות מקומית
קמעונאים שיש להם חנויות פיזיות וחנות וירטואלית צריכים לשמור את פרטי המלאי לפי חנות. הם משתמשים במלאי בחנויות מקומיות כדי לעשות את זה.
יש שני שדות מוצר שאפשר להשתמש בהם כדי לאחסן מלאי בחנות מקומית. שני השדות הם רשימות של מיקומים (מזהי מקומות) עם פרטי מלאי משויכים:
Product.fulfillmentInfo. שיטות איסוף ומשלוח בכל מיקום חנות
Product.localInventories. פרטי מחיר, מאפייני מוצר ושיטות איסוף ומשלוח בכל מיקום חנות
אתם יכולים להשתמש בשדה אחד או בשני השדות כדי לספק את פרטי החנות.
מידע נוסף על מלאי בחנות מקומית זמין במאמר עדכון מלאי בחנות מקומית ב-AI Commerce Search.
מבנה מלאי של וריאציית מוצר ראשית
מבנה הנתונים של מלאי מוצרים ראשיים עם וריאציות מורכב ממוצרים ראשיים, מוצרים עם וריאציות ומוצרים במלאי בחנויות מקומיות:
מוצרים ראשיים: נתוני המוצרים הראשיים מאוחסנים בלי מחירים.
משפחות מוצרים (עם המחיר הכי נמוך במדינה): לדוגמה, לווריאציה של המאפיין הראשי (צבע, מידה) צריך להיות המחיר הכי נמוך במדינה. נתוני המחירים של הווריאציות מצורפים לנתוני המוצרים הראשיים, והמחיר הראשי משמש לדירוג. המערכת מתעלמת ממחירים שספציפיים למיקום.
מלאי בחנויות מקומיות (תמחור ספציפי לאזור או לחנות): שימוש בפרטי המחיר מנתוני המלאי בחנויות מקומיות לצורך דירוג מחדש בזמן הצגת המודעה
מאפייני מוצר ראשיים: מוצרים ראשיים צריכים לכלול רק מאפיינים שמשותפים לכל הווריאציות המשויכות שלהם.
נכונות נתוני הזמינות של המוצר
שדה הזמינות נקבע על ידי מערכת עדכון המלאי כשהסטטוס של המוצר במלאי משתנה. לעקוב אחרי כל המוצרים שנמצאים במצב IN_STOCK וOUT_OF_STOCK.
אם רוב המוצרים הם OUT_OF_STOCK, בתגובה לחיפוש יופיעו הרבה מוצרים שאינם במלאי, ואחרי הוספת מסנן, ערכי הזיכרון יקטנו. אם המוצר אזל מהמלאי אבל הסטטוס שלו בקטלוג הוא IN_STOCK, המשתמשים יראו שהמוצר זמין, אבל סביר להניח שהם ייתקלו בבעיות בזמן הקנייה או ההוספה לעגלת הקניות. השינוי הזה משפיע יותר על חוויית הלקוח מאשר על אימון המודל. חשוב לעדכן את השדה Product.availability ככל האפשר באמצעות ממשקי ה-API של patchProduct או ממשקי API של ייבוא עם readMask.
סכימת מוצרים
כשמייבאים קטלוג מ-BigQuery, צריך להשתמש בסכימת המוצרים הבאה של AI Commerce Search כדי ליצור טבלה ב-BigQuery בפורמט הנכון ולטעון אותה עם נתוני הקטלוג. לאחר מכן, מייבאים את הקטלוג.
שימוש בשדות מובנים במקום במאפיינים מותאמים אישית
לכל שאר מאפייני המוצר שלא נכללים בסכימת פרטי המוצר, משתמשים בProduct.attributes (מאפיינים בהתאמה אישית).
לשדות המוצר המובנים כמו שם הפריט, התיאור והמותגים יש השפעה גדולה יותר על קלות החיפוש וזמינות להוספה לאינדקס, בהשוואה למאפיינים מותאמים אישית.
במילים אחרות, לשרת העורפי יש הבנה מעמיקה יותר של השדות המובנים מאשר של המאפיינים המותאמים אישית. המערכת העורפית לוקחת בחשבון את המידע בשדות המובנים כדי לבצע אופטימיזציה של הרלוונטיות. לכן, מומלץ להשתמש בשדות המובנים. כלומר, כדאי למפות את פרטי המוצרים לשדות מובנים ככל האפשר, ולהשתמש במאפייני לקוחות רק כשצריך.
לדוגמה, הגדרת המותגים בשדה Product.brands משפיעה על החיפוש וההיזכרות הרבה יותר מהגדרת אותו מידע במאפיין מותאם אישית. עדיף להשתמש במאפיינים בהתאמה אישית במקום במאפיין כמו sleeve length, שלא נתמך באופן מובנה.
שימוש בשדה המותג
השדה 'מותג' בפרטי המוצר, שאפשר לחפש אותו, להוסיף אותו לאינדקס ולסנן לפיו כברירת מחדל, הוא אות חזק לדירוג ולרלוונטיות. אחוז גבוה של שאילתות חיפוש הן מהצורה brand query או query brand, ויש שיגידו שהמותג הוא אחד מההיבטים הנפוצים ביותר.
יחסי ההמרה של קליקים ורכישות מושפעים מאוד אם שדה המותג של המוצר נכון. לכן חשוב לוודא ששדה המותג מלא במידע הנכון, ואם אפשר, לא להשאיר אותו ריק אף פעם. מה שגורם נזק רב יותר הוא מילוי שמות המותגים במילות קישור אקראיות כמו "NA" או "Not available" או "Miscellaneous". הקישור הזה יוצר אסוציאציה חזקה בין המוצר לבין הטקסט שמופיע בשדה המותגים, מה שעלול להוביל להבנה שגויה של המוצר ולזכירה לא טובה שלו.
אם מוצר מסוים לא משויך למותג כלשהו, עדיף להשאיר את השדות ריקים. עם זאת, חשוב לוודא שהמוצרים האלה של מותגים ריקים מהווים אחוז קטן ממוצרי הקטלוג.
שימוש בשדה 'קהל'
יש שני שדות משנה בשדה הקהל של פרטי המוצר. יש Audience.gender וגם Audience.ageGroup. יעיל הרבה יותר למלא את השדות האלה בנתונים המתאימים, כדי לעזור למודל להבין את קהל היעד של המוצר.
ההיסטוריה הזו משחקת תפקיד חשוב כשההתאמה האישית מופעלת. הוספת gender ו-ageGroup עוזרת לפלח את המוצרים בצורה טובה יותר ולמודל לזכור את המוצר הנכון עבור המשתמש המתאים.
הנתונים של Audience שימושיים גם כשמדובר בשאילתות כמו חולצות לנשים או גרביים לגברים. אחרי שהמידע על הקהל מתעדכן, ההבנה של המוצר משתפרת משמעותית והמודל משפר את היכולת שלו לשלוף מידע לגבי שאילתות שקשורות למגדר.
חיפוש מוצרים עם שמות כפולים
השדה Product.title הוא כנראה החשוב ביותר, כי רוב שאילתות החיפוש יחפפו במידה רבה את מה שמוגדר כProduct.title. זה כנראה המידע הראשון שמשתמשי הקצה יראו ויבצעו איתו אינטראקציה בתצוגת צפייה בדף הפרטים, ולכן מומלץ לשמור על הייחודיות של שם המוצר ולכלול בו מידע טקסטואלי שהכי רלוונטי למוצר.
אם יש שני מוצרים (מוצרים ראשיים) עם אותו שם, זה משפיע על יכולת החיפוש ועל הרלוונטיות של התוצאות שמוחזרות. אם יש שני מוצרים ראשיים נפרדים עם הבדלים משמעותיים, כדאי להשאיר את שמות הפריטים שונים. אם המוצרים זהים אבל נבדלים רק בכמה מאפיינים כמו צבע, גודל או מבנה, צריך להגדיר את המוצרים כסוגים ראשיים וסוגי וריאציות.
הגדרות שפה
AI Commerce Search תומך בכמה שפות. עם זאת, לכל פרויקט יכול להיות רק קטלוג אחד. כל קטלוג יכול להיות רק בשפה אחת.
לכן, הקטלוג ושאילתת החיפוש צריכים להיות באותה שפה. אין תרגום בין שפות של שאילתות או של מידע מהקטלוג. לדוגמה, אם הקטלוג שלכם הוא בספרדית, גם שאילתת החיפוש צריכה להיות בספרדית.
לכן חשוב לסמן את קוד השפה בפרטי המוצר בהתאם, אחרת השפה תוגדר לאנגלית (en-US) כברירת מחדל. זה חשוב לשימוש באמצעי בקרה של חיפוש כמו spellCorrectionSpec, כי אם השפה לא מוגדרת, מתקבלת התנהגות לא רצויה. הדבר חשוב מאוד גם להבנת הכוונה של השאילתה.
מידע על הגדרות שפה מעורבות זמין במאמר שפות נתמכות.
הגדרות של מידע על מחירים
חשוב למלא את השדה Product.priceInfo בצורה מדויקת ומלאה ככל האפשר. המידע הזה על המחירים משמש להפקת אותות שקשורים להנחות, ומשמש לאופטימיזציה של ההכנסות. זה חשוב במיוחד לגבי שאילתות גלישה.
במבנה מוצר עם וריאציה ראשית, צריך למלא את המחיר של וריאציה אחת לפחות.
אם אין למוצר מחיר ברמת המוצר וכל המחירים מופיעים במלאי בחנות המקומית, כלומר החיפוש תמיד קשור למלאי בחנות המקומית, צריך למלא את פרטי מחיר החציון של כל המחירים ברמת המלאי בפרטי המחיר ברמת המוצר.
מדדים של איכות הנתונים בקטלוג
בדף איכות הנתונים במסוף AI Commerce Search ב-Gemini Enterprise for Customer Experience מוצגת הערכה לגבי הצורך לעדכן את נתוני הקטלוג כדי לשפר את איכות תוצאות החיפוש ולפתוח רמות ביצועים של חיפוש.
בטבלה הבאה מפורטים מדדי האיכות שבהם נעשה שימוש ב-AI Commerce Search כדי לעזור לכם להעריך את נתוני המוצרים. פרטים על הצגת מדדים של איכות הנתונים ורמות הביצועים של החיפוש במסוף AI Commerce Search ב-Gemini Enterprise for Customer Experience זמינים במאמר הפעלת רמות ביצועים של חיפוש.
| מדד איכות הקטלוג | כלל איכות | הערות |
|---|---|---|
| ה-URI קיים ונגיש | למוצר יש Product.uri תקין. ה-URI צריך להיות נגיש ולהתאים לדומיין שלכם. |
חיפוש Google משתמש באותות מהאינטרנט שנסרקו באמצעות מזהה ה-URI הזה כדי לשפר את איכות החיפוש. |
| עמידה בדרישות התאימות לזמן | הערך של Product.availableTime מוקדם מהשעה הנוכחית, והערך של Product.expireTime מאוחר מהשעה הנוכחית. |
רק מוצרים שעומדים בדרישות הזמן זמינים לחיפוש. |
| מאפיין שאפשר לחפש מופיע | למוצר יש לפחות attribute אחד שמוגדר כניתן לחיפוש. |
אפשר לחפש מאפיינים מותאמים אישית שמסומנים כמאפיינים שאפשר לחפש באמצעות שאילתות טקסט. |
| קיים תיאור | המוצר כולל את המאפיין Product.description עם ערך. |
תיאור מקיף עוזר לשפר את איכות החיפוש. |
| הכותרת מורכבת משתי מילים לפחות | הערך Product.title מורכב משתי מילים לפחות. |
כותרת מקיפה עוזרת לשפר את איכות החיפוש. |
| יש וריאציה עם תמונה | למוצר variant יש לפחות Product.image. אפשר להתעלם מהמדד הזה אם כל המוצרים שלכם הם ברמה primary. |
המדד הזה מיועד למטרות מידע בלבד, והוא לא משפיע על איכות החיפוש. |
| יש וריאציה עם פרטי מחיר | המוצר variant כולל את הערך Product.priceInfo. אפשר להתעלם מהמדד הזה אם כל המוצרים שלכם הם ברמה primary. |
המדד הזה מיועד למטרות מידע בלבד, והוא לא משפיע על איכות החיפוש. |