שיטות מומלצות

אנחנו שמחים להציג את Merchant API (בטא) – הדור הבא של Content API for Shopping.

קבלת העדכונים האחרונים על תכונות חדשות, תיקוני באגים ועדכוני גרסאות של Merchant API (בטא).

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

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

מתי כדאי להשתמש ב-API

שליחת בקשות באופן פרוגרמטי

בין שאתם מעדיפים להפוך לאוטומטיים את כל חלקי תהליך העבודה שלכם ובין שאתם רוצים ליצור קישור למערכת ה-ERP (Enterprise Resource Planning) שלכם, Content API מאפשר לכם לשלוח עדכונים ברגע שהמלאי שלכם משתנה.

כדי לקבל משוב מיידי

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

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

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

כדי לנהל כמה חשבונות משנה

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

איך משתמשים ב-API?

אל תשתמשו ב-API כמו שמשתמשים בפידים של נתונים

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

אל תשתמשו ב-API כדי לאחזר באופן קבוע את פרטי המוצרים שהעליתם

אם אתם אחראים על ניהול פרטי המוצרים בחשבון Merchant Center מסוים, הימנעו מבקשות קבועות של פרטי מוצרים מ-Content API באמצעות השיטות products.get או products.list. ללקוחות שמעלים מידע, השיטות האלה יכולות לעזור בניפוי באגים בזמן תכנון פתרונות שמשתמשים ב-Content API. עם זאת, הם לא מיועדים לאחזור קבוע של פרטי מוצרים על ידי לקוחות כאלה. צריך להיות לכם מקור אחר לפרטי המוצרים, כמו מסד נתונים מקומי של מוצרים, והמוצרים ב-Merchant Center צריכים לשקף את התוכן של המקור הזה.

אין להשתמש גם בפידים של נתונים וגם ב-Content API כדי לשלוח פריטים של מוצרים

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

האם יש דרך להשתמש ב-API ובפידים של נתונים יחד בצורה בטוחה?

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

דוגמאות נוספות לדרכים מקובלות לשימוש בפיד וב-API יחד:

• ביצוע בקשות לקריאה בלבד (get או list) מה-API: חלק מהמוכרים רוצים להשתמש ב-API כדי לאחזר מידע ועדכוני סטטוס לגבי המוצרים שלהם. זה מקובל כי פרטי המוצרים מתעדכנים רק באמצעות פידים.

• שימוש ב-API כדי לנהל את חשבונות המשנה (AccountsService) ו/או את הגדרות המס והמשלוחים ברמת החשבון (AccounttaxService ו-ShippingsettingsService). אלה לא פונקציות שאפשר לספק באמצעות פידים של נתונים, ולכן אין סתירה לשימוש ב-API לניהול הפונקציות האלה.

איך עוברים משימוש בפידים של נתונים לשימוש רק ב-API או להפך?

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

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

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

איך מטרגטים מוצרים לכמה מדינות באמצעות Content API for Shopping?

כדי לטרגט כמה מדינות באמצעות מודעות וכרטיסי מוצר חינמיים של מוצרים שנשלחו דרך Content API, צריך להגדיר מדינות נוספות בפיד הראשי של Content API ב-Merchant Center או להוסיף את המדינות האלה דרך השדה shipping במשאב products.

בהמשך מופיעה דוגמה לשינוי ההגדרות של הפיד הראשי ב-Content API.

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

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

מוודאים שספריות הלקוח מעודכנות

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

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

ה-Content API מאמץ באופן אוטומטי את הגדרות ברירת המחדל של פיד ה-Content API כפי שהוגדר ב-Merchant Center. אפשר להשתמש במאפייני המוצר includedDestinations או excludedDestinations כדי לקבוע את ההשתתפות בתוכנית ברמת המוצר בפיד או דרך Content API.

אם פיד ה-API שלכם צורף לתוכנית, למשל 'קונים ב-Google' (לשעבר Shopping Actions), אבל אתם רוצים להחריג מוצרים מסוימים, תוכלו להשתמש במאפיין excludedDestinations ולציין את הערך Shopping Actions. אם לא יהיו שגיאות, הפעולה הזו תגרום להחליף את הגדרות ברירת המחדל של הפיד ב-Merchant Center, והפריט הספציפי הזה לא יופיע ב'קונים ב-Google' (לשעבר Shopping Actions). לעומת זאת, אם הפיד לא צורף לתוכנית, למשל שופינג, תוכלו לכלול פריטים ספציפיים באמצעות המאפיין includedDestinations והערך Shopping_ads, והפריט יוצג במודעות שופינג.

מידע נוסף על מאפייני המוצרים includedDestinations ו-excludedDestinations זמין במרכז העזרה.

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

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

אל תמחקו את הפיד של Content API, אחרת יכול להיות שהמוצרים שלכם ייעלמו

בפעם הראשונה שתעלו מוצר עם channel:online דרך Content API, יופיע פיד חדש ב-Merchant Center בשם Content API. בפעם הראשונה שתעלו מוצר עם channel:local דרך Content API, יופיע פיד חדש ב-Merchant Center בשם Content API עם כותרת משנה Local Products. חשוב לוודא שלא מוחקים בטעות את הפיד של Content API אונליין או את הפיד המקומי. בהתאם לפיד שתמחקו, המוצרים אונליין או המוצרים בחנות המקומית שהוספתם ל-Merchant Center דרך Content API יוסרו.

שליחת מספר בקשות ברצף לאותו שירות באמצעות השיטה custombatch

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

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

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

לא לשלוח עדכונים על פריטים שלא השתנו

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

שימוש בפידים משלימים אם המחירים ו/או הזמינות משתנים במהירות

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

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

מתי משתמשים בטוקן רענון

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