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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

יש שתי שיטות עיקריות להטמעת קטלוג ב-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 Commerce Search.
שימוש בהסתעפויות לגיבויים:
- ענף פעיל יחיד מתמקד בהוספה ובעיבוד רציפים של עדכוני מוצרים כדי לשמור על עדכניות של אינדקס החיפוש של AI Commerce כמעט בזמן אמת.
- ענף נוסף מתמקד ביצירת תמונת מצב יומית של הנתונים שעברו טרנספורמציה ב-AI Commerce Search, ומשמש כמנגנון חזק למקרה של שיבוש נתונים או בעיות בענף 0.
- הענף השלישי מתמקד ביצירת תמונת מצב שבועית של התאריך שעבר המרה. כך הלקוח יכול לקבל גיבוי מלפני יום וגיבוי מלפני שבוע בענפים שונים.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הוספת מאפייני הודעה: כשמפרסמים הודעות בנושא Pub/Sub, כמו עדכוני מוצרים, צריך לכלול מאפיין שמציין את אזור היעד. לדוגמה:
- region: us-central1
- region: us-east1
הגדרת מסנני מינוי: לכל צינור עיבוד נתונים אזורי, מגדירים את המינוי ל-Pub/Sub כך שימשוך רק הודעות שתואמות לאזור שלו באמצעות מסנני הודעות. לדוגמה, המינוי ל-us-central1 Dataflow job יכלול מסנן כמו 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 Commerce Search, לא נשארים עקבות של עדכון המוצרים והמלאי. יכול להיות שהמשתמש ירצה לדעת למה מוצר מסוים לא מוצג כמו שהוא ציפה. אזור זמני שנבנה באמצעות BigQuery עם היסטוריה מלאה של נתונים מאפשר לבצע חקירה וניפוי באגים מהסוג הזה.

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

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

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

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

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

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

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

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

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

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

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

דוגמאות לשגיאות כאלה:
- מאפיין מסוים שלא נכלל בחוזה מופיע פתאום ברכיב הנתונים הגולמיים.
- מאפיין חובה מסוים לא מופיע ברכיב הנתונים הגולמיים.
מאמת את כל פריט בנתונים הגולמיים כדי להפוך אותו לפורמט של AI Commerce Search. יש כמה שדות חובה שנדרשים כדי להטמיע מוצרים ב-AI Commerce Search. עכשיו צריך לבדוק מחדש כל רכיב בנתונים הגולמיים כדי לוודא שאפשר להמיר אותו בהצלחה לפורמט סכמת החיפוש של 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 Commerce Search

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

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

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

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

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

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

כדי לסנכרן את חשבון 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 Commerce Search. כדי לבדוק לאילו חשבונות יש גישה לחשבון 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 Commerce Search. התהליך הזה לא מוחק מוצרים ב-AI Commerce Search שכבר הועלו.

מסוף 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 Commerce Search כדי ליצור טבלה ב-BigQuery בפורמט הנכון ולטעון את הטבלה הריקה עם נתוני הקטלוג. לאחר מכן, מעלים את הנתונים ל-AI Commerce Search.

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

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

תראו לי איך

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

אם מערך הנתונים שלכם ב-BigQuery נמצא בפרויקט אחר, צריך להגדיר את ההרשאות הנדרשות כדי שהתכונה 'AI Commerce Search' תוכל לגשת למערך הנתונים ב-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 Commerce Search.
  
  מומלץ לא לציין ספריות זמניות או ספריות שגיאות, כדי שאפשר יהיה ליצור באופן אוטומטי קטגוריה של 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, והוא כולל אובייקט Status שדומה לדוגמה הבאה:
  
  { "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 Search, צריך לבצע את השלבים הבאים.

פותחים את הדף 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 Commerce Search.

דוגמה לפורמט 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 Commerce Search תומך בייבוא ובניהול של נתוני קטלוג היסטוריים. נתונים היסטוריים של קטלוג יכולים לעזור כשמשתמשים באירועים היסטוריים של משתמשים לאימון מודלים. אפשר להשתמש במידע על מוצרים קודמים כדי להעשיר את נתוני האירועים ההיסטוריים של המשתמשים ולשפר את דיוק המודל.

מוצרים היסטוריים נשמרים כמוצרים שתוקפם פג. הם לא מוחזרים בתגובות לחיפוש, אבל הם גלויים לקריאות ל-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 Commerce Search

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

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

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

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

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

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

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

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

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

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

חוסן ופורנזיקה דיגיטלית

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

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

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

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

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

הרחבת הקטלוג

צווארי בקבוק

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

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

משפחת מוצרים

אחזור מאפיינים

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

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

סנכרון של Merchant Center עם AI Commerce Search

קישור חשבון 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`