Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

ייבוא פרטי קטלוג

בדף הזה מוסבר איך לייבא את פרטי הקטלוג ולעדכן אותם.

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

אפשר לייבא את נתוני המוצרים מ-BigQuery או לציין את הנתונים בשורה בבקשה. כל אחת מהפעולות האלה היא ייבוא חד-פעמי, למעט קישור חשבון Merchant Center. כדאי לתזמן ייבוא קטלוג קבוע (רצוי מדי יום) כדי לוודא שהקטלוג עדכני.

מידע נוסף מופיע במאמר בנושא שמירה על קטלוג עדכני.

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

לפני שמתחילים

לפני שמתחילים לייבא את הקטלוג, צריך:

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

מידע נוסף זמין במאמר תנאים מוקדמים להגדרה.

שיקולים לגבי ייבוא קטלוג

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

BigQuery	תיאור	ייבוא נתונים מטבלת BigQuery שנפרסה בעבר ומשתמשת בסכימת חיפוש מסחרי מבוסס-AI. אפשר לבצע את הפעולה באמצעות מסוף Google Cloud או curl.
	מתי כדאי להשתמש במאפיין הזה	אם יש לכם קטלוגים של מוצרים עם הרבה מאפיינים. הייבוא ל-BigQuery מתבצע באמצעות סכימת החיפוש של AI Commerce, שכוללת יותר מאפייני מוצר מאפשרויות ייבוא אחרות, כולל מאפיינים מותאמים אישית של מפתח/ערך. אם יש לכם נפחים גדולים של נתונים. אין הגבלה על כמות הנתונים שניתן לייבא מ-BigQuery. אם אתם כבר משתמשים ב-BigQuery.
	מגבלות	נדרש שלב נוסף של יצירת טבלה ב-BigQuery שממופה לסכימה של חיפוש מסחרי מבוסס-AI.
Cloud Storage	תיאור	ייבוא נתונים בפורמט JSON מקבצים שנטענו לקטגוריה ב-Cloud Storage. כל קובץ צריך להיות בגודל של 2GB או פחות, ואפשר לייבא עד 100 קבצים בכל פעם. אפשר לבצע את הייבוא באמצעות מסוף Google Cloud או curl. משתמש בפורמט הנתונים `Product` JSON, שמאפשר מאפיינים מותאמים אישית.
	מתי כדאי להשתמש במאפיין הזה	אם אתם צריכים לטעון כמות גדולה של נתונים בשלב אחד.
	מגבלות	השיטה הזו לא מתאימה במיוחד לקטלוגים שבהם יש עדכונים תכופים של מלאי ומחירים, כי השינויים לא משתקפים באופן מיידי.
ייבוא בתוך השורה	תיאור	ייבוא באמצעות קריאה ל-`Product.import`. משתמש באובייקט `ProductInlineSource`, שיש לו פחות מאפיינים של קטלוג מוצרים מאשר לסכימת החיפוש של AI Commerce, אבל הוא תומך במאפיינים בהתאמה אישית.
	מתי כדאי להשתמש במאפיין הזה	אם יש לכם נתוני קטלוג שטוחים ולא רלציוניים, או אם אתם מעדכנים את הכמויות או המחירים בתדירות גבוהה.
	מגבלות	אפשר לייבא עד 100 פריטים לקטלוג בכל פעם. אבל אפשר לבצע הרבה שלבי טעינה, אין הגבלה על מספר הפריטים.

מדריכים

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

סרטון הדרכה

בסרטון הזה מוסבר איך לייבא קטלוג באמצעות AI Commerce Search API.

מדריך לייבוא קטלוג מ-BigQuery

במדריך הזה מוסבר איך להשתמש בטבלה ב-BigQuery כדי לייבא כמויות גדולות של נתוני קטלוג ללא הגבלות.

בלחיצה על תראו לי איך תקבלו הסבר מפורט על המשימה ישירות ב-Cloud Shell Editor:

תראו לי איך

מדריך לייבוא קטלוג מ-Cloud Storage

במדריך הזה נסביר איך לייבא מספר גדול של פריטים לקטלוג.

בלחיצה על תראו לי איך תקבלו הסבר מפורט על המשימה ישירות ב-Cloud Shell Editor:

תראו לי איך

מדריך לייבוא נתוני קטלוג בתוך השורה

במדריך הזה מוסבר איך לייבא מוצרים לקטלוג בתוך השורה.

בלחיצה על תראו לי איך תקבלו הסבר מפורט על המשימה ישירות ב-Cloud Shell Editor:

תראו לי איך

שיטות מומלצות לייבוא קטלוגים

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

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

חשוב להבחין היטב בין מוצרים ראשיים לבין וריאציות. לפני שמעלים נתונים, כדאי לעיין במאמר בנושא רמות המוצרים.
- לשנות את ההגדרה ברמת המוצר אחרי שהשקעתם מאמץ משמעותי בייבוא נתונים. פריטים ראשיים – לא וריאציות – מוחזרים כתוצאות חיפוש או כהמלצות.
- דוגמה: אם קבוצת המק"טים הראשית היא חולצת וי, מודל ההמלצות יחזיר חולצת וי, ואולי גם חולצות עם צווארון עגול וצווארון סקופ. אבל אם לא משתמשים בווריאציות וכל מק"ט הוא ראשי, כל שילוב של צבע או מידה של חולצת וי מחזיר פריט נפרד בחלונית ההמלצות: חולצת וי חומה, מידה XL, חולצת וי חומה, מידה L עד חולצת וי לבנה, מידה M, חולצת וי לבנה, מידה S.
- המערכת יכולה לזהות קולקציות אם כוללים בהן מזהי וריאציות ארוכים לצד מזהי המוצרים הראשיים ב-collectionMemberIds[]. כתוצאה מכך, אוסף מוצרים שממנו המשתמש רכש מוצר אחד או יותר נרשם באירוע המשתמש, והרכישה משויכת לאוסף כולו. כך קל יותר להציג לאותו משתמש מוצרים אחרים באוסף נתון בשאילתה קשורה עתידית.
- דוגמה: משתמש רכש בעבר כיסוי שמיכה, ולכן המערכת מחזירה מוצרים תואמים מקולקציית מצעים, כמו ציפיות.
שימו לב למגבלות על ייבוא פריטי מוצרים.
- לייבוא בכמות גדולה מ-Cloud Storage, הגודל של כל קובץ צריך להיות 2GB או פחות. אפשר לכלול עד 100 קבצים בכל בקשת ייבוא בכמות גדולה.
- בייבוא מוטבע, אפשר לייבא עד 5,000 פריטי מוצרים בכל פעם.
חשוב לוודא שהפרטים הנדרשים בקטלוג כלולים ונכונים. אל תשתמשו בערכים זמניים לשמירת מקום (placeholder).
כדאי לכלול כמה שיותר פרטים אופציונליים בקטלוג.
חשוב לוודא שבכל האירועים מוגדר מטבע אחד, במיוחד אם אתם מתכננים להשתמש בGoogle Cloud מסוף כדי לקבל מדדי הכנסות. ‫AI Commerce Search API לא תומך בשימוש בכמה מטבעות לכל קטלוג.
חשוב לעדכן את הקטלוג באופן קבוע, רצוי מדי יום. תזמון של ייבוא קטלוגים תקופתי עוזר לשמור על איכות המודל לאורך זמן. כשמייבאים את הקטלוג באמצעות AI Commerce Search במסוף Gemini Enterprise for Customer Experience, אפשר לתזמן ייבוא אוטומטי חוזר. אפשר גם להשתמש ב-Google Cloud Scheduler כדי לייבא נתונים באופן אוטומטי.
אל תתעדו אירועים של משתמשים לגבי פריטי מוצר שעדיין לא יובאו.
אחרי שמייבאים את פרטי הקטלוג, צריך לבדוק את המידע על דיווח שגיאות ורישום ביומן בפרויקט. אם מופיעות יותר מכמה שגיאות, צריך לבדוק אותן ולתקן את הבעיות בתהליך שגרמו לשגיאות.

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

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

ייבוא בכמות גדולה, סטרימינג בזמן אמת או שניהם?

יש שתי שיטות עיקריות להטמעת קטלוג ב-AI Commerce Search:

ייבוא בכמות גדולה
סטרימינג בזמן אמת

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

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

הפונקציונליות של ייבוא בכמות גדולה תומכת בשלושה מקורות נתונים שונים:

‫BigQuery: ‏ BigQuery מאפשר לשנות במהירות את נתוני הקטלוג, לציין תאריכי חלוקה למחיצות במהלך הייבוא ולבצע המרה יעילה של נתונים באמצעות שאילתות SQL.
‫Google Cloud Storage: כדי להשתמש ב-Cloud Storage, צריך להקפיד על פורמטים ספציפיים, כמו JSON, ועל הגבלות על קבצים. המשתמשים אחראים לניהול מבני הדליים, לחלוקת הקבצים לחלקים ולשאר ההיבטים של תהליך הייבוא. בנוסף, עריכה ישירה של הקטלוג ב-Cloud Storage יכולה להיות מסורבלת, ולמרות שהיא עשויה להיות חסכונית, היא לא גמישה כמו שיטות אחרות.
נתונים מוטבעים: בקטלוגים גדולים, ייבוא מוטבע לא תמיד יהיה האפשרות הכי טובה בגלל מגבלות גודל. כדאי להשתמש בהם רק לעדכונים קלים או לבדיקות ניסיוניות.

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

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

אסטרטגיות הסתעפות לניהול קטלוג

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

אלה אסטרטגיות נפוצות של הסתעפות שיעילות לניהול קטלוגים.

עדכונים של ענף יחיד

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

החלפת הסתעפות

יש כמה אפשרויות לניהול של ענפים שונים:

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

מחיקה לצמיתות של ענפים בקטלוג

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

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

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

עוברים לדף Data במסוף AI Commerce Search ב-Gemini Enterprise for Customer Experience.

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

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

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

מתחילה פעולה ממושכת למחיקת נתונים מענף הקטלוג. בסיום פעולת ההסרה, סטטוס ההסרה מוצג ברשימה Product catalog (קטלוג המוצרים) בחלון Activity status (סטטוס הפעילות).

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

עדכונים לגבי מלאי שטחי פרסום בחיפוש מסחרי מבוסס-AI

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

סטרימינג בזמן אמת

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

עדכונים אסינכרוניים

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

עדכונים לא תקינים

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

בדיקות מקדימות של קטלוג המוצרים לביצוע בדיקות A/B מהימנות בחיפוש מסחרי מבוסס-AI

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

שמירה על עקביות בעדכוני הקטלוג

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

השגת שוויון בנתוני הקטלוג

העומק והדיוק של מודל חיפוש של מסחר אלקטרוני בהבנת מוצרים תלויים בעושר ובאיכות של המידע בקטלוג המוצרים הבסיסי שלו. ככל שנתוני המוצרים בקטלוג מקיפים יותר, כך המודל מצויד טוב יותר להבנה ולסיווג יעיל של מוצרים.
לכן, כהכנה לבדיקת A/B, חשוב לוודא שנתוני המוצרים שהועלו לקטלוג מדור קודם (קמפיין הבקרה) ולקטלוג של חיפוש מסחרי מבוסס-AI (קמפיין הניסוי) זהים. הבדלים בפרטי המוצרים בין שני הסביבות האלה עלולים להטות באופן משמעותי את תוצאות בדיקת ה-A/B.
לדוגמה, אם מנוע החיפוש מדור קודם נהנה מקטלוג עשיר או נרחב יותר בהשוואה לחיפוש מסחרי מבוסס-AI, נוצר יתרון לא הוגן. מידע חסר בקטלוג של חיפוש מסחרי מבוסס-AI יכול להיות קריטי להבנה ולסיווג של מוצרים, ועלול להוביל לתוצאות חיפוש לא מדויקות ולהשוואות מטעות של ביצועים. קשה לזהות פערים כאלה באמצעות כלים חיצוניים, ולרוב נדרשת בדיקה ידנית קפדנית של שני הקטלוגים.
אם קמעונאים יקפידו לוודא שבשני הקטלוגים יש נתוני מוצרים זהים עם אותה רמת פירוט, הם יוכלו ליצור תנאים שווים לבדיקות A/B בחיפוש מסחרי מבוסס-AI. הגישה הזו מאפשרת השוואה הוגנת ונטולת הטיה בין שני מנועי החיפוש, ומקלה על הערכה מדויקת של הביצועים והיכולות של כל אחד מהם.

תכנון התאוששות מאסון (DR)

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

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

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

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

תכנון להשגת זמינות גבוהה

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

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

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

כך מטמיעים את העיצובים האלה באמצעות Pub/Sub ו-Dataflow:

שירותים גלובליים: חלק מהשירותים, כמו Pub/Sub, פועלים באופן גלובלי. Google Cloud מנהלת את הזמינות שלהם בהתאם להסכמי רמת השירות (SLA) הספציפיים שלהם.
שירותים אזוריים: שירותים אחרים, כמו Dataflow, שבהם אתם עשויים להשתמש כדי לשנות נתונים ולהטמיע אותם בחיפוש AI Commerce, הם אזוריים. באחריותכם להגדיר את הרכיבים האלה לזמינות גבוהה ולשחזור אחרי אסון.

לדוגמה, כשמשתמשים ב-BigQuery כדי לשמור נתונים, אפשר להגדיר אותו כך שיהיה במספר אזורים, כדי ש Google Cloudיטפל אוטומטית בשכפול הנתונים ובזמינות שלהם. באופן דומה, כשמשתמשים ב-Cloud Storage, אפשר להגדיר אותו כך שיפעל במספר אזורים.

עיצוב פעיל/פעיל

בארכיטקטורה מסוג פעיל/פעיל נעשה שימוש במאפייני הודעות של Pub/Sub ובמסנני מינויים כדי להבטיח שכל הודעה תעובד בדיוק פעם אחת על ידי משימת Dataflow פעילה באזור מסוים.

הוספת מאפייני הודעה: כשמפרסמים הודעות בנושא Pub/Sub, כמו עדכוני מוצרים, צריך לכלול מאפיין שמציין את אזור היעד. לדוגמה:
- region: us-central1
- region: us-east1
הגדרת מסנני מינוי: לכל צינור עיבוד נתונים אזורי, מגדירים את המינוי ל-Pub/Sub כך שימשוך רק הודעות שתואמות לאזור שלו באמצעות מסנני הודעות. לדוגמה, המינוי למשימת us-central1 Dataflow יכלול מסנן כמו attributes.region = "us-central1".
מעבר לגיבוי (Failover): אם אזור מסוים לא זמין, צריך לעדכן את מערכת הפרסום במעלה הזרם כדי לתייג את כל ההודעות החדשות עם מאפיין של אזור תקין. הפעולה הזו מעבירה את עיבוד ההודעות למופע Dataflow באזור המעבר לגיבוי.

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

עיצוב פעיל/סביל

העיצוב הזה כולל צינור עיבוד נתונים אזורי אחד של Dataflow ששולף הודעות מ-Pub/Sub בכל זמן נתון.

צירוף מינוי אחד: מוודאים שרק המינוי ל-Pub/Sub של משימת Dataflow באזור הפעיל מצורף ושולף הודעות. צריך ליצור מינויים למשימות Dataflow באזורים פסיביים, אבל הם צריכים להישאר מנותקים.
מעבר לגיבוי (Failover): אם מתרחש כשל באזור הפעיל, באופן ידני או באמצעות תוכנה:
- מבטלים את הצירוף של מינוי Pub/Sub שמשויך לעבודת Dataflow באזור שנכשל.
- מצרפים את מינוי Pub/Sub שמשויך למשימת Dataflow באחד מהאזורים הפסיביים (המתנה).

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

יכולת התמודדות וניתוח משפטי

שימוש ב-BigQuery בתכנון של הטמעת הנתונים יכול לעזור בטיפול בחוסן וביצירת יכולת לניתוח משפטי ולניפוי באגים. המונח 'המוצרים והמלאי מוזנים ישירות באמצעות API‏ patch ו-addLocalInventory' מציין שכאשר הנתונים נשלחים לחיפוש מבוסס-AI למסחר, לא נשארים עקבות של עדכון המוצרים והמלאי. יכול להיות שהמשתמש ירצה לדעת למה מוצר מסוים לא מוצג כמו שהוא ציפה. אזור זמני שנבנה באמצעות BigQuery עם היסטוריה מלאה של נתונים מאפשר לבצע חקירה וניפוי באגים מהסוג הזה.

תרשים עזר לארכיטקטורה

דוגמה לארכיטקטורה של ענפים בסטרימינג וב-batch

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

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

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

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

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

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

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

כדי להשיג את המטרה הזו, הלוגיקה של Dataflow צריכה להיות בנויה כך:

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

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

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

בדוגמה הזו מוצגת סכימת טבלה לדוגמה ב-BigQuery לשמירת כל הכשלים לצורך ניפוי באגים:

הצגת סכימת טבלה לדוגמה ב-BigQuery

[
    {
      "mode": "REQUIRED",
      "name": "ingestedTimestamp",
      "type": "TIMESTAMP"
    },
    {
      "mode": "REQUIRED",
      "name": "payloadString",
      "type": "STRING"
    },
    {
      "mode": "REQUIRED",
      "name": "payloadBytes",
      "type": "BYTES"
    },
    {
      "fields": [
        {
          "mode": "NULLABLE",
          "name": "key",
          "type": "STRING"
        },
        {
          "mode": "NULLABLE",
          "name": "value",
          "type": "STRING"
        }
      ],
      "mode": "REPEATED",
      "name": "attributes",
      "type": "RECORD"
    },
    {
      "mode": "NULLABLE",
      "name": "errorMessage",
      "type": "STRING"
    },
    {
      "mode": "NULLABLE",
      "name": "stacktrace",
      "type": "STRING"
    }
  ]

בדיקות מאמץ ומדרגיות

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

אירועים עם תנועה גבוהה

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

מבצעים לזמן קצר

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

הרחבת הקטלוג

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

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

צריך להעריך את הביצועים של צינור העברת הנתונים וליצור בסיס למדדים הבאים:

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

צווארי בקבוק

בודקים אם אפשר להגדיל או להקטין את הצינורות בצורה נכונה.
בודקים אם המגבלה המקסימלית על מספר המופעים גבוהה או נמוכה מדי.
כדי לבדוק אם מערכת AI Commerce Search מגבילה את קצב הבקשות, מחפשים את קוד ה-HTTP‏ 429.
כדאי לבדוק אם צריך להגדיל מכסות מסוימות של API כדי לצמצם את מגבלות הקצב.

מבנה נתוני המוצרים להעלאה לקטלוג

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

מוצרים עיקריים

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

מזהה המוצר הראשי
מזהה מוצר (זהה למזהה המוצר הראשי)
כותרת
תיאור

מידע נוסף זמין במאמר מידע על מאפייני מוצרים.

משפחת מוצרים

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

מאפייני החובה כוללים:

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

מידע נוסף זמין במאמר מידע על מאפייני מוצרים.

שליפת מאפיינים

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

דירוג רלוונטיות

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

התאמת וריאציות בתוצאות החיפוש

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

סנכרון של Merchant Center עם חיפוש מסחרי מבוסס-AI

Merchant Center הוא כלי שמאפשר לכם להעלות את נתוני החנות והמוצרים שלכם ל-Google, כך שניתן יהיה להציג אותם במודעות שופינג ובשירותים אחרים של Google.

כדי לבצע סנכרון רציף בין Merchant Center לבין חיפוש מסחרי מבוסס-AI, אתם יכולים לקשר את חשבון Merchant Center לחיפוש מסחרי מבוסס-AI.

כשמגדירים סנכרון של Merchant Center לחיפוש מסחרי מבוסס-AI, צריך להקצות את תפקיד האדמין ב-IAM ב-Merchant Center. למרות שרמת גישה רגילה מאפשרת לכם לקרוא את הפידים של Merchant Center, כשאתם מנסים לסנכרן את Merchant Center עם AI Commerce Search, מוצגת הודעת שגיאה. לכן, כדי לסנכרן את חשבון Merchant Center עם AI Commerce Search, צריך לשדרג את התפקיד.

קישור חשבון Merchant Center

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

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

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

סנכרון חשבון Merchant Center

מסוף Cloud

עוברים לדף Data במסוף AI Commerce Search ב-Gemini Enterprise for Customer Experience.

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

אם לא מציינים פידים, המערכת מייבאת מבצעים מכל הפידים (כולל פידים עתידיים).
אופציונלי: כדי לייבא רק מוצרים שמטרגטים מדינות או שפות מסוימות, מרחיבים את הצגת אפשרויות מתקדמות ובוחרים את מדינות המכירה והשפות ב-Merchant Center שרוצים לסנן.
בוחרים את הענף שאליו רוצים להעלות את הקטלוג.
לוחצים על Import.

curl

צריך לוודא שלחשבון השירות בסביבה המקומית יש גישה גם לחשבון Merchant Center וגם לחיפוש מבוסס-AI למסחר. כדי לבדוק לאילו חשבונות יש גישה לחשבון Merchant Center שלכם, אפשר לעיין במאמר בנושא הרשאות גישה למשתמשים ב-Merchant Center.
משתמשים בשיטה MerchantCenterAccountLink.create כדי ליצור את הקישור.
```
curl -X POST \
-H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
-H "Content-Type: application/json; charset=utf-8" \
 --data '{
  "merchantCenterAccountId": MERCHANT_CENTER_ID,
  "branchId": "BRANCH_ID",
  "feedFilters": [
    {"dataSourceId": DATA_SOURCE_ID_1}
    {"dataSourceId": DATA_SOURCE_ID_2}
  ],
  "languageCode": "LANGUAGE_CODE",
  "feedLabel": "FEED_LABEL",
 }' \
 "https://retail.googleapis.com/v2alpha/projects/PROJECT_ID/locations/global/catalogs/default_catalog/merchantCenterAccountLinks"
```
- ‫MERCHANT_CENTER_ID: המזהה של חשבון Merchant Center.
- ‫BRANCH_ID: המזהה של הענף שאליו רוצים לקשר את החשבון. אפשר להזין את הערכים '0',‏ '1' או '2'.
- ‫LANGUAGE_CODE: (אופציונלי) קוד השפה בן שתי האותיות של המוצרים שרוצים לייבא. כפי שמופיע ב-Merchant Center בעמודה Language של המוצר. אם לא מגדירים שפות, כל השפות מיובאות.
- ‫FEED_LABEL: (אופציונלי) תווית הפיד של המוצרים שרוצים לייבא. תווית הפיד מופיעה ב-Merchant Center בעמודה תווית פיד של המוצר. אם לא מגדירים תוויות, כל התוויות של הפיד מיובאות.
- ‫FEED_FILTERS: (אופציונלי) רשימה של פידים ראשיים שמתוכם יובאו מוצרים. אם לא בוחרים פידים, כל הפידים בחשבון Merchant Center משותפים. אפשר למצוא את המזהים במקור הנתונים של Content API או להיכנס ל-Merchant Center, לבחור פיד ולקבל את מזהה הפיד מהפרמטר afmDataSourceId בכתובת האתר. לדוגמה, mc/products/sources/detail?a=MERCHANT_CENTER_ID&afmDataSourceId=DATA_SOURCE_ID.

כדי לראות את חשבון Merchant Center המקושר, עוברים אל הדף נתונים במסוף AI Commerce Search ב-Gemini Enterprise for Customer Experience ולוחצים על הלחצן Merchant Center בפינה השמאלית העליונה של הדף. תיפתח החלונית חשבונות Merchant Center מקושרים. אפשר גם להוסיף עוד חשבונות Merchant Center מהחלונית הזו.

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

הצגת הקישורים לחשבון Merchant Center

מסוף Cloud

עוברים לדף Data במסוף AI Commerce Search ב-Gemini Enterprise for Customer Experience.

מעבר לדף Data
לוחצים על הלחצן Merchant Center בפינה השמאלית העליונה של הדף כדי לפתוח רשימה של חשבונות Merchant Center המקושרים.

curl

אפשר להשתמש בשיטה MerchantCenterAccountLink.list כדי להציג את משאב הקישורים.

curl -X GET \
 -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
 -H "Content-Type: application/json; charset=utf-8" \
 "https://retail.googleapis.com/v2alpha/projects/PROJECT_NUMBER/locations/global/catalogs/default_catalog/merchantCenterAccountLinks"

ביטול הקישור של חשבון Merchant Center

ביטול הקישור של חשבון Merchant Center יפסיק את הסנכרון של נתוני הקטלוג עם חיפוש AI למסחר. התהליך הזה לא מוחק מוצרים בחיפוש מסחרי מבוסס-AI שכבר הועלו.

מסוף Cloud

עוברים לדף Data במסוף AI Commerce Search ב-Gemini Enterprise for Customer Experience.

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

curl

כדי להסיר את המשאב MerchantCenterAccountLink, משתמשים בשיטה MerchantCenterAccountLink.delete.

curl -X DELETE \
 -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
 -H "Content-Type: application/json; charset=utf-8" \
 "https://retail.googleapis.com/v2alpha/projects/PROJECT_NUMBER/locations/global/catalogs/default_catalog/merchantCenterAccountLinks/BRANCH_ID_MERCHANT_CENTER_ID"

מגבלות על קישור ל-Merchant Center

אפשר לקשר חשבון Merchant Center לכל מספר של ענפי קטלוג, אבל כל ענף קטלוג יכול להיות מקושר רק לחשבון Merchant Center אחד.
חשבון Merchant Center לא יכול להיות חשבון מרובה לקוחות (MCA). אבל אפשר לקשר חשבונות משנה בנפרד.
הייבוא הראשון אחרי קישור חשבון Merchant Center יכול להימשך כמה שעות. משך הזמן תלוי במספר המוצרים בחשבון Merchant Center.
האפשרות לבצע שינויים במוצרים באמצעות שיטות API מושבתת בסניפים שמקושרים לחשבון Merchant Center. כל שינוי בנתוני קטלוג המוצרים בסניפים האלה צריך להתבצע באמצעות Merchant Center. לאחר מכן, השינויים האלה מסתנכרנים אוטומטית עם AI Commerce Search.
אין תמיכה בסוג המוצר 'אוסף' בסניפים שמקושרים ל-Merchant Center.
כדי לשמור על דיוק הנתונים, אפשר לקשר את חשבון Merchant Center רק לענפים ריקים בקטלוג. כדי למחוק מוצרים מענף בקטלוג, אפשר לעיין במאמר בנושא מחיקת פרטי מוצרים.

ייבוא נתוני קטלוג מ-BigQuery

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

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

בלחיצה על תראו לי איך תקבלו הסבר מפורט על המשימה ישירות ב-Cloud Shell Editor:

תראו לי איך

כדי לייבא את הקטלוג:

אם מערך הנתונים שלכם ב-BigQuery נמצא בפרויקט אחר, צריך להגדיר את ההרשאות הנדרשות כדי שהתכונה 'חיפוש מבוסס-AI למסחר' תוכל לגשת למערך הנתונים ב-BigQuery. מידע נוסף
מייבאים את נתוני הקטלוג אל AI Commerce Search.
מסוף Cloud
1. עוברים לדף Data במסוף AI Commerce Search ב-Gemini Enterprise for Customer Experience.
  
  מעבר לדף Data
2. לוחצים על ייבוא כדי לפתוח את החלונית ייבוא נתונים.
3. בוחרים באפשרות קטלוג מוצרים.
4. בוחרים באפשרות BigQuery כמקור הנתונים.
5. בוחרים את הענף שאליו רוצים להעלות את הקטלוג.
6. בוחרים באפשרות סכימת קטלוגים של מוצרים קמעונאיים. זו סכימת המוצרים ל-AI Commerce Search.
7. מזינים את הטבלה ב-BigQuery שבה נמצאים הנתונים.
8. אופציונלי: בקטע הצגת אפשרויות מתקדמות, מזינים את המיקום של קטגוריה של Cloud Storage בפרויקט בתור מיקום זמני לנתונים.
  
  אם לא מציינים מיקום, המערכת משתמשת במיקום ברירת המחדל. אם מציינים את האזור, קטגוריית Cloud Storage ו-BigQuery צריכות להיות באותו אזור.
9. אם לא הפעלתם את האפשרות 'חיפוש' ואתם משתמשים בסכימה של Merchant Center, בוחרים ברמת המוצר.
  
  חובה לבחור ברמת המוצר אם זאת הפעם הראשונה שאתם מייבאים את הקטלוג או אם אתם מייבאים מחדש את הקטלוג אחרי שמחקתם אותו. מידע נוסף על רמות מוצרים שינוי רמות המוצרים אחרי ייבוא נתונים דורש מאמץ משמעותי.
  
  חשוב: אי אפשר להפעיל חיפוש בפרויקטים עם קטלוג מוצרים שנוסף כווריאציות.
10. לוחצים על Import.
curl
1. אם זו הפעם הראשונה שאתם מעלים את הקטלוג, או אם אתם מייבאים מחדש את הקטלוג אחרי שמחקתם אותו, אתם צריכים להגדיר את רמות המוצרים באמצעות השיטה Catalog.patch. כדי לבצע את הפעולה הזו, צריך תפקיד אדמין בחשבון קמעונאי.
  
  ‫ingestionProductType: תומך בערכים primary (ברירת מחדל) ו-variant.
  
  ‫merchantCenterProductIdField: תומך בערכים offerId ו-itemGroupId. אם אתם לא משתמשים ב-Merchant Center, אתם לא צריכים להגדיר את השדה הזה.
  
  curl -X PATCH \ -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \ -H "Content-Type: application/json; charset=utf-8" \ --data '{ "productLevelConfig": { "ingestionProductType": "PRODUCT_TYPE", "merchantCenterProductIdField": "PRODUCT_ID_FIELD" } }' \ "https://retail.googleapis.com/v2/projects/PROJECT_ID/locations/global/catalogs/default_catalog"
2. יוצרים קובץ נתונים עם פרמטרי הקלט לייבוא.
  
  משתמשים באובייקט BigQuerySource כדי להפנות למערך הנתונים ב-BigQuery.
  
  ‫DATASET_ID: המזהה של מערך הנתונים ב-BigQuery.
  
  ‫TABLE_ID: המזהה של הטבלה ב-BigQuery שמכילה את הנתונים.
  
  ‫PROJECT_ID: מזהה הפרויקט שבו נמצא מקור הנתונים ב-BigQuery. אם לא מציינים את מזהה הפרויקט, הוא עובר בירושה מהבקשה הראשית.
  
  ‫STAGING_DIRECTORY: אופציונלי. ספרייה ב-Cloud Storage שמשמשת כמיקום זמני לנתונים לפני שהם מיובאים ל-BigQuery. משאירים את השדה הזה ריק כדי ליצור באופן אוטומטי ספרייה זמנית (מומלץ).
  
  ‫ERROR_DIRECTORY: אופציונלי. ספרייה ב-Cloud Storage למידע על שגיאות שקשורות לייבוא. מומלץ להשאיר את השדה הזה ריק כדי ליצור באופן אוטומטי ספרייה זמנית.
  
  ‫dataSchema: במאפיין dataSchema, משתמשים בערך product (ברירת מחדל). תשתמשו בסכימת AI לחיפוש מסחר אלקטרוני.
  
  מומלץ לא לציין ספריות זמניות או ספריות שגיאות, כדי שאפשר יהיה ליצור באופן אוטומטי קטגוריה של Cloud Storage עם ספריות זמניות וספריות שגיאות חדשות. הספריות האלה נוצרות באותו אזור כמו מערך הנתונים ב-BigQuery, והן ייחודיות לכל ייבוא (מה שמונע ממשימות ייבוא מרובות להכין נתונים באותה ספריה, ואולי לייבא מחדש את אותם נתונים). אחרי שלושה ימים, ה-bucket והספריות נמחקים אוטומטית כדי לצמצם את עלויות האחסון.
  
  שם הקטגוריה שנוצר באופן אוטומטי כולל את מזהה הפרויקט, האזור של הקטגוריה ושם סכימת הנתונים, מופרדים באמצעות קווים תחתונים (לדוגמה, 4321_us_catalog_retail). הספריות שנוצרות באופן אוטומטי נקראות staging או errors, עם מספר בסוף (לדוגמה, staging2345 או errors5678).
  
  אם מציינים ספריות, הקטגוריה של Cloud Storage צריכה להיות באותו אזור כמו מערך הנתונים ב-BigQuery, אחרת הייבוא ייכשל. צריך לציין את ספריות ההעברה והשגיאות בפורמט gs://<bucket>/<folder>/. הן צריכות להיות שונות.
  
  { "inputConfig":{ "bigQuerySource": { "projectId":"PROJECT_ID", "datasetId":"DATASET_ID", "tableId":"TABLE_ID", "dataSchema":"product"} } }
3. מייבאים את פרטי הקטלוג על ידי שליחת בקשת POST לשיטת Products:import REST, ומציינים את שם קובץ הנתונים (כאן, מוצג כ-input.json).
  
  curl -X POST \ -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \ -H "Content-Type: application/json; charset=utf-8" -d @./input.json \ "https://retail.googleapis.com/v2/projects/PROJECT_NUMBER/locations/global/catalogs/default_catalog/branches/0/products:import"
  
  אפשר לבדוק את הסטטוס באופן פרוגרמטי באמצעות ה-API. אמורים לקבל אובייקט תגובה שנראה בערך כך:
  
  { "name": "projects/PROJECT_ID/locations/global/catalogs/default_catalog/operations/import-products-123456", "done": false }
  
  השדה name הוא המזהה של אובייקט הפעולה. כדי לבקש את הסטטוס של האובייקט הזה, מחליפים את השדה name בערך שמוחזר על ידי method import, עד שהשדה done מחזיר את הערך true:
  
  curl -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \ "https://retail.googleapis.com/v2/projects/PROJECT_ID/locations/global/catalogs/default_catalog/operations/import-products-123456"
  
  כשהפעולה מסתיימת, לאובייקט שמוחזר יש ערך done של true, והוא כולל אובייקט סטטוס שדומה לדוגמה הבאה:
  
  { "name": "projects/PROJECT_ID/locations/global/catalogs/default_catalog/operations/import-products-123456", "metadata": { "@type": "type.googleapis.com/google.cloud.retail.v2.ImportMetadata", "createTime": "2020-01-01T03:33:33.000001Z", "updateTime": "2020-01-01T03:34:33.000001Z", "successCount": "2", "failureCount": "1" }, "done": true, "response": { "@type": "type.googleapis.com/google.cloud.retail.v2.ImportProductsResponse", }, "errorsConfig": { "gcsPrefix": "gs://error-bucket/error-directory" } }
  
  אפשר לבדוק את הקבצים בספריית השגיאות ב-Cloud Storage כדי לראות אם התרחשו שגיאות במהלך הייבוא.

הגדרת גישה למערך הנתונים ב-BigQuery

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

פותחים את הדף IAM במסוף Google Cloud .

כניסה לדף IAM
בוחרים את הפרויקט של AI Commerce Search.
מחפשים את חשבון השירות עם השם Retail Service Agent.

אם לא הפעלתם בעבר פעולת ייבוא, יכול להיות שחשבון השירות הזה לא יופיע ברשימה. אם חשבון השירות הזה לא מופיע, צריך לחזור למשימת הייבוא ולהתחיל את הייבוא. אם הפעולה נכשלת בגלל שגיאות הרשאה, צריך לחזור לכאן ולהשלים את המשימה הזו.
מעתיקים את המזהה של חשבון השירות, שנראה כמו כתובת אימייל (לדוגמה, service-525@gcp-sa-retail.iam.gserviceaccount.com).
עוברים לפרויקט BigQuery (באותו דף IAM & Admin) ולוחצים על Grant Access.
בקטע New principals (ישויות חדשות), מזינים את המזהה של חשבון השירות של AI Commerce Search ובוחרים בתפקיד BigQuery > BigQuery User (משתמש ב-BigQuery).
לוחצים על Add another role (הוספת תפקיד נוסף) ובוחרים באפשרות BigQuery > BigQuery Data Editor (BigQuery > עריכת נתונים ב-BigQuery).

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

סכמת מוצרים

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

צפייה בסכימת המוצר של AI Commerce Search

[
  {
    "name": "name",
    "type": "STRING",
    "mode": "NULLABLE"
  },
  {
    "name": "id",
    "type": "STRING",
    "mode": "REQUIRED"
  },
  {
    "name": "type",
    "type": "STRING",
    "mode": "NULLABLE"
  },
  {
    "name": "primaryProductId",
    "type": "STRING",
    "mode": "NULLABLE"
  },
  {
    "name": "collectionMemberIds",
    "type": "STRING",
    "mode": "REPEATED"
  },
  {
    "name": "gtin",
    "type": "STRING",
    "mode": "NULLABLE"
  },
  {
    "name": "categories",
    "type": "STRING",
    "mode": "REPEATED"
  },
  {
    "name": "title",
    "type": "STRING",
    "mode": "REQUIRED"
  },
  {
    "name": "brands",
    "type": "STRING",
    "mode": "REPEATED"
  },
  {
    "name": "description",
    "type": "STRING",
    "mode": "NULLABLE"
  },
  {
    "name": "languageCode",
    "type": "STRING",
    "mode": "NULLABLE"
  },
  {
    "name": "attributes",
    "type": "RECORD",
    "mode": "REPEATED",
    "fields": [
      {
        "name": "key",
        "type": "STRING",
        "mode": "NULLABLE"
      },
      {
        "name": "value",
        "type": "RECORD",
        "mode": "NULLABLE",
        "fields": [
          {
            "name": "text",
            "type": "STRING",
            "mode": "REPEATED"
          },
          {
            "name": "numbers",
            "type": "FLOAT",
            "mode": "REPEATED"
          }
        ]
      }
    ]
  },
  {
    "name": "tags",
    "type": "STRING",
    "mode": "REPEATED"
  },
  {
    "name": "priceInfo",
    "type": "RECORD",
    "mode": "NULLABLE",
    "fields": [
      {
        "name": "currencyCode",
        "type": "STRING",
        "mode": "NULLABLE"
      },
      {
        "name": "price",
        "type": "FLOAT",
        "mode": "NULLABLE"
      },
      {
        "name": "originalPrice",
        "type": "FLOAT",
        "mode": "NULLABLE"
      },
      {
        "name": "cost",
        "type": "FLOAT",
        "mode": "NULLABLE"
      },
      {
        "name": "priceEffectiveTime",
        "type": "STRING",
        "mode": "NULLABLE"
      },
      {
        "name": "priceExpireTime",
        "type": "STRING",
        "mode": "NULLABLE"
      }
    ]
  },
  {
    "name": "rating",
    "type": "RECORD",
    "mode": "NULLABLE",
    "fields": [
      {
        "name": "ratingCount",
        "type": "INTEGER",
        "mode": "NULLABLE"
      },
      {
        "name": "averageRating",
        "type": "FLOAT",
        "mode": "NULLABLE"
      },
      {
        "name": "ratingHistogram",
        "type": "INTEGER",
        "mode": "REPEATED"
      }
    ]
  },
  {
    "name": "expireTime",
    "type": "STRING",
    "mode": "NULLABLE"
  },
  {
    "name": "ttl",
    "type": "RECORD",
    "mode": "NULLABLE",
    "fields": [
      {
        "name": "seconds",
        "type": "INTEGER",
        "mode": "NULLABLE"
      },
      {
        "name": "nanos",
        "type": "INTEGER",
        "mode": "NULLABLE"
      }
    ]
  },
  {
    "name": "availableTime",
    "type": "STRING",
    "mode": "NULLABLE"
  },
  {
    "name": "availability",
    "type": "STRING",
    "mode": "NULLABLE"
  },
  {
    "name": "availableQuantity",
    "type": "INTEGER",
    "mode": "NULLABLE"
  },
  {
    "name": "fulfillmentInfo",
    "type": "RECORD",
    "mode": "REPEATED",
    "fields": [
      {
        "name": "type",
        "type": "STRING",
        "mode": "NULLABLE"
      },
      {
        "name": "placeIds",
        "type": "STRING",
        "mode": "REPEATED"
      }
    ]
  },
  {
    "name": "uri",
    "type": "STRING",
    "mode": "NULLABLE"
  },
  {
    "name": "images",
    "type": "RECORD",
    "mode": "REPEATED",
    "fields": [
      {
        "name": "uri",
        "type": "STRING",
        "mode": "REQUIRED"
      },
      {
        "name": "height",
        "type": "INTEGER",
        "mode": "NULLABLE"
      },
      {
        "name": "width",
        "type": "INTEGER",
        "mode": "NULLABLE"
      }
    ]
  },
  {
    "name": "audience",
    "type": "RECORD",
    "mode": "NULLABLE",
    "fields": [
      {
        "name": "genders",
        "type": "STRING",
        "mode": "REPEATED"
      },
      {
        "name": "ageGroups",
        "type": "STRING",
        "mode": "REPEATED"
      }
    ]
  },
  {
    "name": "colorInfo",
    "type": "RECORD",
    "mode": "NULLABLE",
    "fields": [
      {
        "name": "colorFamilies",
        "type": "STRING",
        "mode": "REPEATED"
      },
      {
        "name": "colors",
        "type": "STRING",
        "mode": "REPEATED"
      }
    ]
  },
  {
    "name": "sizes",
    "type": "STRING",
    "mode": "REPEATED"
  },
  {
    "name": "materials",
    "type": "STRING",
    "mode": "REPEATED"
  },
  {
    "name": "patterns",
    "type": "STRING",
    "mode": "REPEATED"
  },
  {
    "name": "conditions",
    "type": "STRING",
    "mode": "REPEATED"
  },
  {
    "name": "publishTime",
    "type": "STRING",
    "mode": "NULLABLE"
  },
  {
    "name": "promotions",
    "type": "RECORD",
    "mode": "REPEATED",
    "fields": [
      {
        "name": "promotionId",
        "type": "STRING",
        "mode": "NULLABLE"
      }
    ]
  }
]

ייבוא נתוני קטלוג מ-Cloud Storage

כדי לייבא נתוני קטלוג בפורמט JSON, יוצרים קובץ JSON אחד או יותר שמכילים את נתוני הקטלוג שרוצים לייבא, ומעלים אותם ל-Cloud Storage. משם אפשר לייבא אותו לחיפוש מסחרי מבוסס-AI.

דוגמה לפורמט JSON של פריט מוצר מופיעה במאמר פורמט נתוני JSON של פריט מוצר.

לקבלת עזרה בהעלאת קבצים ל-Cloud Storage, אפשר לעיין במאמר בנושא העלאת אובייקטים.

חשוב לוודא שלחשבון השירות של AI Commerce Search יש הרשאה לקרוא ולכתוב בקטגוריה.

חשבון השירות של AI Commerce Search מופיע בדף IAM במסוף Google Cloud בשם Retail Service Agent. כשמוסיפים את החשבון להרשאות של קטגוריית היעד, צריך להשתמש במזהה של חשבון השירות, שנראה כמו כתובת אימייל (לדוגמה, service-525@gcp-sa-retail.iam.gserviceaccount.com).
מייבאים את נתוני הקטלוג.
מסוף Cloud
1. עוברים לדף Data במסוף AI Commerce Search ב-Gemini Enterprise for Customer Experience.
  
  מעבר לדף Data
2. לוחצים על ייבוא כדי לפתוח את החלונית ייבוא נתונים.
3. בוחרים באפשרות קטלוג מוצרים כמקור הנתונים.
4. בוחרים את הענף שאליו רוצים להעלות את הקטלוג.
5. בוחרים באפשרות Retail Product Catalogs Schema (סכימת קטלוגים של מוצרים קמעונאיים).
6. מזינים את המיקום של הנתונים ב-Cloud Storage.
7. אם לא הפעלתם את החיפוש, בוחרים את רמות המוצרים.
  
  חובה לבחור את רמות המוצרים אם זו הפעם הראשונה שאתם מייבאים את הקטלוג או אם אתם מייבאים מחדש את הקטלוג אחרי שמחקתם אותו. מידע נוסף על רמות מוצרים שינוי רמות המוצרים אחרי ייבוא נתונים דורש מאמץ משמעותי.
  
  חשוב: אי אפשר להפעיל חיפוש בפרויקטים עם קטלוג מוצרים שנוסף כווריאציות.
8. לוחצים על Import.
curl
1. אם זו הפעם הראשונה שאתם מעלים את הקטלוג, או אם אתם מייבאים מחדש את הקטלוג אחרי שביצעתם בו ניקוי, אתם צריכים להגדיר את רמות המוצרים באמצעות השיטה Catalog.patch. מידע נוסף על רמות מוצרים
  
  ‫ingestionProductType: תומך בערכים primary (ברירת מחדל) ו-variant.
  
  ‫merchantCenterProductIdField: תומך בערכים offerId ו-itemGroupId. אם אתם לא משתמשים ב-Merchant Center, אתם לא צריכים להגדיר את השדה הזה.
  
  curl -X PATCH \ -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \ -H "Content-Type: application/json; charset=utf-8" \ --data '{ "productLevelConfig": { "ingestionProductType": "PRODUCT_TYPE", "merchantCenterProductIdField": "PRODUCT_ID_FIELD" } }' \ "https://retail.googleapis.com/v2/projects/PROJECT_ID/locations/global/catalogs/default_catalog"
2. יוצרים קובץ נתונים עם פרמטרי הקלט לייבוא. משתמשים באובייקט GcsSource כדי להפנות לקטגוריה של Cloud Storage.
  
  אפשר לספק כמה קבצים או רק קובץ אחד. בדוגמה הזו נעשה שימוש בשני קבצים.
  
  ‫INPUT_FILE: קובץ או קבצים ב-Cloud Storage שמכילים את נתוני הקטלוג.
  
  ‫ERROR_DIRECTORY: ספרייה ב-Cloud Storage למידע על שגיאות שקשורות לייבוא.
  
  השדות בקובץ הקלט חייבים להיות בפורמט gs://<bucket>/<path-to-file>/. ספריית השגיאות צריכה להיות בפורמט gs://<bucket>/<folder>/. אם ספריית השגיאות לא קיימת, היא נוצרת. הבאקט חייב להיות קיים.
  
  { "inputConfig":{ "gcsSource": { "inputUris": ["INPUT_FILE_1", "INPUT_FILE_2"] } }, "errorsConfig":{"gcsPrefix":"ERROR_DIRECTORY"} }
3. כדי לייבא את פרטי הקטלוג, שולחים בקשת POST לשיטת REST‏ Products:import ומציינים את שם קובץ הנתונים (במקרה הזה, input.json).
  
  curl -X POST \ -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \ -H "Content-Type: application/json; charset=utf-8" -d @./input.json \ "https://retail.googleapis.com/v2/projects/PROJECT_NUMBER/locations/global/catalogs/default_catalog/branches/0/products:import"
  
  הדרך הקלה ביותר לבדוק את הסטטוס של פעולת הייבוא היא באמצעות Google Cloud המסוף. איך בודקים את הסטטוס של פעולת אינטגרציה ספציפית
  
  אפשר גם לבדוק את הסטטוס באופן פרוגרמטי באמצעות ה-API. אמור להתקבל אובייקט תגובה שנראה בערך כך:
  
  { "name": "projects/PROJECT_ID/locations/global/catalogs/default_catalog/operations/import-products-123456", "done": false }
  
  השדה name הוא המזהה של אובייקט הפעולה. מבקשים את הסטטוס של האובייקט הזה, ומחליפים את השדה name בערך שמוחזר על ידי שיטת הייבוא, עד שהשדה done מחזיר את הערך true:
  
  curl -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \ "https://retail.googleapis.com/v2/projects/PROJECT_ID/locations/global/catalogs/default_catalog/operations/[OPERATION_NAME]"
  
  כשהפעולה מסתיימת, לאובייקט שמוחזר יש ערך done של true, והוא כולל אובייקט סטטוס שדומה לדוגמה הבאה:
  
  { "name": "projects/PROJECT_ID/locations/global/catalogs/default_catalog/operations/import-products-123456", "metadata": { "@type": "type.googleapis.com/google.cloud.retail.v2.ImportMetadata", "createTime": "2020-01-01T03:33:33.000001Z", "updateTime": "2020-01-01T03:34:33.000001Z", "successCount": "2", "failureCount": "1" }, "done": true, "response": { "@type": "type.googleapis.com/google.cloud.retail.v2.ImportProductsResponse" }, "errorsConfig": { "gcsPrefix": "gs://error-bucket/error-directory" } }
  
  אפשר לבדוק את הקבצים בספריית השגיאות ב-Cloud Storage כדי לראות אילו סוגי שגיאות התרחשו במהלך הייבוא.

ייבוא נתוני קטלוג בתוך השורה

curl

כדי לייבא את פרטי הקטלוג בשורה, שולחים בקשת POST לשיטת REST‏ Products:import, ומשתמשים באובייקט productInlineSource כדי לציין את נתוני הקטלוג.

כל מוצר צריך להופיע בשורה נפרדת. כל מוצר צריך להיות בשורה נפרדת.

דוגמה לפורמט JSON של פריט מוצר מופיעה במאמר פורמט נתוני JSON של פריט מוצר.

יוצרים את קובץ ה-JSON של המוצר וקוראים לו ./data.json:

{
"inputConfig": {
"productInlineSource": {
    "products": [
      { PRODUCT_1 }
      { PRODUCT_2 }
    ]
  }
}
}

מבצעים קריאה לשיטת POST:

curl -X POST \
 -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
 -H "Content-Type: application/json; charset=utf-8" \
 --data @./data.json \
"https://retail.googleapis.com/v2/projects/PROJECT_NUMBER/locations/global/catalogs/default_catalog/branches/0/products:import"

Java

public static String importProductsFromInlineSource(
    List<Product> productsToImport)
    throws IOException, InterruptedException, ExecutionException {
  ProductServiceClient productClient = getProductServiceClient();

  ProductInlineSource inlineSource = ProductInlineSource.newBuilder()
      .addAllProducts(productsToImport)
      .build();

  ProductInputConfig inputConfig = ProductInputConfig.newBuilder()
      .setProductInlineSource(inlineSource)
      .build();

  ImportProductsRequest importRequest = ImportProductsRequest.newBuilder()
      .setParent(IMPORT_PARENT)
      .setRequestId(REQUEST_ID)
      .setReconciliationMode(ReconciliationMode.INCREMENTAL)
      .setInputConfig(inputConfig)
      .build();

  String operationName = productClient
      .importProductsAsync(importRequest).getName();

  productClient.shutdownNow();
  productClient.awaitTermination(2, TimeUnit.SECONDS);

  return operationName;
}

פורמט נתוני JSON של פריט מוצר

הערכים של Product בקובץ ה-JSON צריכים להיראות כמו בדוגמאות הבאות.

כל מוצר צריך להופיע בשורה נפרדת. כל מוצר צריך להיות בשורה נפרדת.

שדות חובה:

      {
        "id": "1234",
        "categories": "Apparel & Accessories > Shoes",
        "title": "ABC sneakers"
      }
      {
        "id": "5839",
        "categories": "casual attire > t-shirts",
        "title": "Crew t-shirt"
      }

צפייה באובייקט המלא

      {
        "name": "projects/PROJECT_NUMBER/locations/global/catalogs/default_catalog/branches/0/products/1234",
        "id": "1234",
        "categories": "Apparel & Accessories > Shoes",
        "title": "ABC sneakers",
        "description": "Sneakers for the rest of us",
        "attributes": { "vendor": {"text": ["vendor123", "vendor456"]} },
        "language_code": "en",
        "tags": [ "black-friday" ],
        "priceInfo": {
          "currencyCode": "USD", "price":100, "originalPrice":200, "cost": 50
        },
        "availableTime": "2020-01-01T03:33:33.000001Z",
        "availableQuantity": "1",
        "uri":"http://example.com",
        "images": [
          {"uri": "http://example.com/img1", "height": 320, "width": 320 }
        ]
      }
      {
        "name": "projects/PROJECT_NUMBER/locations/global/catalogs/default_catalog/branches/0/products/4567",
        "id": "4567",
        "categories": "casual attire > t-shirts",
        "title": "Crew t-shirt",
        "description": "A casual shirt for a casual day",
        "attributes": { "vendor": {"text": ["vendor789", "vendor321"]} },
        "language_code": "en",
        "tags": [ "black-friday" ],
        "priceInfo": {
          "currencyCode": "USD", "price":50, "originalPrice":60, "cost": 40
        },
        "availableTime": "2020-02-01T04:44:44.000001Z",
        "availableQuantity": "2",
        "uri":"http://example.com",
        "images": [
          {"uri": "http://example.com/img2", "height": 320, "width": 320 }
        ]
      }

נתונים היסטוריים של קטלוג

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

מוצרים היסטוריים נשמרים כמוצרים שתוקפם פג. הם לא מוחזרים בתגובות לחיפושים, אבל אפשר לראות אותם בקריאות ל-API של Update, List ו-Delete.

ייבוא נתונים היסטוריים של קטלוג

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

מומלץ להשתמש בשיטות הבאות לייבוא נתונים היסטוריים של קטלוג:

הפעלת method‏ `Product.Create`

משתמשים ב-method‏ Product.Create כדי ליצור רשומה של Product עם השדה expireTime שמוגדר לחותמת זמן מהעבר.

ייבוא מוצרים שפג תוקפם בתוך הגיליון

השלבים זהים לייבוא מוטבע, אלא שבמוצרים צריך להגדיר את השדות expireTime לסימן זמן מהעבר.

כל מוצר צריך להופיע בשורה נפרדת. כל מוצר צריך להיות בשורה נפרדת.

דוגמה לשימוש ב-./data.json בבקשת ייבוא מוטבעת:

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

{
"inputConfig": {
  "productInlineSource": {
      "products": [
          {
            "id": "historical_product_001",
            "categories": "Apparel & Accessories > Shoes",
            "title": "ABC sneakers",
            "expire_time": {
              "second": "2021-10-02T15:01:23Z"  // a past timestamp
            }
          },
          {
            "id": "historical product 002",
            "categories": "casual attire > t-shirts",
            "title": "Crew t-shirt",
            "expire_time": {
              "second": "2021-10-02T15:01:24Z"  // a past timestamp
            }
          }
      ]
    }
  }
}

ייבוא מוצרים שתוקפם פג מ-BigQuery או מ-Cloud Storage

אפשר להשתמש באותן פעולות שמתוארות במאמרים בנושא ייבוא נתוני קטלוג מ-BigQuery או ייבוא נתוני קטלוג מ-Cloud Storage. עם זאת, חשוב להקפיד להגדיר את השדה expireTime לחותמת זמן מהעבר.

שומרים על קטלוג עדכני

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

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

כדי לעדכן פריט בודד, אפשר לעיין במאמר בנושא עדכון פרטי מוצר.

חבילת עדכונים

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

מעקב אחר תקינות הייבוא

כדי לעקוב אחרי הטמעת הקטלוג והתקינות שלו:

בדף נתונים של AI Commerce Search ב-Gemini Enterprise for Customer Experience, אפשר לראות מידע מצטבר על הקטלוג ולצפות בתצוגה מקדימה של מוצרים שהועלו.

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

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

כניסה לדף 'איכות הנתונים'
כדי ליצור התראות שיעדכנו אתכם אם משהו לא בסדר בהעלאות הנתונים, פועלים לפי ההוראות במאמר הגדרת התראות ב-Cloud Monitoring.

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

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

לפני שמתחילים

שיקולים לגבי ייבוא קטלוג

מדריכים

סרטון הדרכה

מדריך לייבוא קטלוג מ-BigQuery

מדריך לייבוא קטלוג מ-Cloud Storage

מדריך לייבוא נתוני קטלוג בתוך השורה

שיטות מומלצות לייבוא קטלוגים

ייבוא בכמות גדולה, סטרימינג בזמן אמת או שניהם?

אסטרטגיות הסתעפות לניהול קטלוג

עדכונים של ענף יחיד

החלפת הסתעפות

מחיקה לצמיתות של ענפים בקטלוג

עדכונים לגבי מלאי שטחי פרסום בחיפוש מסחרי מבוסס-AI

סטרימינג בזמן אמת

עדכונים אסינכרוניים

עדכונים לא תקינים

בדיקות מקדימות של קטלוג המוצרים לביצוע בדיקות A/B מהימנות בחיפוש מסחרי מבוסס-AI

שמירה על עקביות בעדכוני הקטלוג

השגת שוויון בנתוני הקטלוג

תכנון התאוששות מאסון (DR)

תכנון להשגת זמינות גבוהה

עיצוב פעיל/פעיל

עיצוב פעיל/סביל

יכולת התמודדות וניתוח משפטי

תרשים עזר לארכיטקטורה

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

בדיקות מאמץ ומדרגיות

אירועים עם תנועה גבוהה

מבצעים לזמן קצר

הרחבת הקטלוג

צווארי בקבוק

מבנה נתוני המוצרים להעלאה לקטלוג

מוצרים עיקריים

משפחת מוצרים

שליפת מאפיינים

דירוג רלוונטיות

התאמת וריאציות בתוצאות החיפוש

סנכרון של Merchant Center עם חיפוש מסחרי מבוסס-AI

קישור חשבון Merchant Center

סנכרון חשבון Merchant Center

מסוף Cloud

curl

הצגת הקישורים לחשבון Merchant Center

מסוף Cloud

curl

ביטול הקישור של חשבון Merchant Center

מסוף Cloud

curl

מגבלות על קישור ל-Merchant Center

ייבוא נתוני קטלוג מ-BigQuery

מסוף Cloud

curl

הגדרת גישה למערך הנתונים ב-BigQuery

סכמת מוצרים

צפייה בסכימת המוצר של AI Commerce Search

ייבוא נתוני קטלוג מ-Cloud Storage

מסוף Cloud

curl

ייבוא נתוני קטלוג בתוך השורה

curl

Java

פורמט נתוני JSON של פריט מוצר

נתונים היסטוריים של קטלוג

ייבוא נתונים היסטוריים של קטלוג

הפעלת method‏ Product.Create

ייבוא מוצרים שפג תוקפם בתוך הגיליון

ייבוא מוצרים שתוקפם פג מ-BigQuery או מ-Cloud Storage

שומרים על קטלוג עדכני

חבילת עדכונים

מעקב אחר תקינות הייבוא

המאמרים הבאים

ייבוא פרטי קטלוג

הפעלת method‏ `Product.Create`