במסמך הזה מפורטות הנחיות לשיטות מומלצות. מידע נוסף זמין בטיפים בנושא ביצועים.
מתי כדאי להשתמש ב-API
כדי לשלוח בקשות באופן פרוגרמטי
בין אם אתם מעדיפים להפוך כל חלק בתהליך העבודה לאוטומטי, או להתחבר למערכת ה-ERP (תכנון משאבים ארגוני) שלכם, ה-Content API מאפשר לכם לשלוח עדכונים ברגע שהמלאי שלכם משתנה.
כדי לקבל משוב מיידי
ב-Content API מקבלים תשובה לכל בקשה באופן מיידי, במקום סיכום באימייל אחרי העיבוד של הפידים. לבקשות גדולות באצווה צפוי זמן אחזור של 5 עד 10 שניות.
כדי לשנות את נתוני המוצרים לעיתים קרובות
בעזרת Content API תוכלו לבצע עדכונים מצטברים למלאי המוצרים שמשתנה במהירות פעמים רבות ביום, אבל לא תוכלו לשלוח את פיד הנתונים כולו בכל פעם. אם עדכונים הופכים לזמינים בנפרד, אפשר לשלוח אותם בנפרד, לא כדאי להמתין עד שיהיו כמה עדכונים כדי שתוכלו לקבץ אותם. בדומה לכך, אם העדכונים זמינים בכמות גדולה, צריך לשלוח אותם בקבוצות, אל תחלקו אותם לבקשות נפרדות.
כדי לנהל כמה חשבונות משנה
חשבונות חדשים ב-Merchant Center הם חשבונות בודדים, ששומרים את קבוצת נתוני המוצרים שלהם. ברוב המקרים זה טוב, אבל ככל שהחשבון גדל, יכול להיות שתצטרכו מערכת ניהול מורכבת יותר למוצרים. במקרה כזה, כדאי להשתמש בחשבון מרובה-לקוחות או בחשבון MCA. באמצעות שירות החשבונות אפשר לנהל ברמת ה-API את החשבון של MCA, ואפשר גם להוסיף ולנהל חשבונות משנה באופן פרוגרמטי. כאן תוכלו לקרוא מידע נוסף על הדרך להשיג חשבון MCA.
איך משתמשים ב-API?
אין להשתמש ב-API כפי שמשתמשים בפידים של נתונים
כשמשתמשים במשאב products, כדאי להימנע מעדכונים יומיים של כל פיד המוצרים.
במקום זאת, כדאי לעדכן באופן ספציפי רק את המוצרים שהנתונים שלהם השתנו בפועל. שליחת פיד הנתונים כולו באמצעות המשאב products צורכת יותר זמן ומשאבים גם ל-Google וגם לכם.
לא משתמשים ב-API כדי לאחזר באופן קבוע את פרטי המוצרים שהעליתם.
אם אתם אחראים לתחזק את פרטי המוצרים בחשבון Merchant Center מסוים, עליכם להימנע מבקשה של פרטי מוצר מ-Content API בשיטות products.get או products.list על בסיס קבוע. בשביל לקוחות שמעלים מידע, ה-methods האלה יכולות לעזור לנפות באגים בבעיות כשמתכננים פתרונות שמשתמשים ב-Content API. עם זאת, הם לא נועדו לאחזר באופן קבוע פרטי מוצרים על ידי לקוחות כאלה. צריך להיות לכם מקור נוסף לפרטי המוצרים, כמו מסד נתונים של מוצרים בחנויות מקומיות, והמוצרים ב-Merchant Center אמורים לשקף את התוכן של המקור הזה.
אין להשתמש גם בפידים של נתונים וגם ב-Content API כדי לשלוח פריטי מוצרים
אם אתם שוקלים לעבור ל-API לשליחת פריטים, כדאי לוודא שאתם לא משתמשים יותר בפידים של נתונים כדי לשלוח פריטי מוצרים. אם תמשיכו לשלוח פריטים בשני האמצעים, יכול להיות שיהיו תוצאות בלתי צפויות.
האם יש דרך להשתמש בבטחה ב-API ובפידים של נתונים ביחד?
אפשר לשנות את הפידים של הנתונים באמצעות שירות Datafeed של ה-API. כך יהיה קל יותר לנהל את פיד הנתונים בקנה מידה נרחב, אבל חשוב לזכור שלא כדאי להוסיף או לעדכן מוצרים באמצעות ה-API בו-זמנית עם פידים, כי התוצאות יכולות להיות בלתי צפויות.
עוד כמה דוגמאות לדרכים קבילות לשימוש בפידים וב-API במשותף:
ביצוע בקשות לקריאה בלבד (קבלה או רשימה) מה-API: מוכרים מסוימים רוצים להשתמש ב-API כדי לאחזר מידע ועדכוני סטטוס לגבי המוצרים שלהם. זה מקובל כי פרטי מוצרים מתעדכנים רק באמצעות פידים.
שימוש ב-API לניהול חשבונות משנה (שירות חשבונות) ו/או הגדרות מס ומשלוח ברמת החשבון (שירות מס חשבון ושירות הגדרות משלוח). אלה לא פונקציות ש-Datafeeds יכול לספק, ולכן אין התנגשות עם השימוש ב-API לניהול הפונקציות האלה.
איך עוברים משימוש בפידים של נתונים לשימוש ב-API בלבד או להיפך?
אם אתם משתמשים כרגע בפידים של נתונים ואתם רוצים לעבור להשתמש רק ב-API כדי לעדכן מוצרים, תצטרכו להעלות מחדש את נתוני המוצרים באמצעות ה-API. כשמשתמשים בשירות המוצרים כדי לעדכן מוצר מסוים, ה-API שולט בפרטי המוצר ומחיקת המוצר מפיד הנתונים או מחיקת פיד הנתונים עצמו לא יגרמו יותר להסרת פרטי המוצר מחשבון Merchant Center. אם רוצים להסיר את המוצר מפיד הנתונים או מפיד הנתונים עצמו, חשוב לוודא שאין עדכונים של פיד הנתונים. אחרת, הבעלות על פיד הנתונים תוחל שוב והסרת המוצר מפיד הנתונים תגרום להסרת המוצר.
אם אתם משתמשים כרגע רק ב-API לפרטי מוצרים, ואתם רוצים להשתמש בפידים של נתונים כמקור הראשי לפרטי המוצרים, תוכלו פשוט להוסיף את פיד הנתונים החדש לחשבון Merchant Center, והוא יקבל בעלות על המוצרים שמופיעים בו. אם יש מוצרים שרוצים להסיר לפני שהתוקף שלהם פג והועלו רק דרך API, צריך למחוק אותם דרך Merchant Center או דרך ה-API.
איך מטרגטים מוצרים לכמה מדינות באמצעות ה-Content API for Shopping?
כדי לטרגט כמה מדינות באמצעות מודעות וכרטיסי מוצר חינמיים למוצרים שנשלחים דרך ה-Content API, צריך להגדיר מדינות נוספות בפיד הראשי של Content API ב-Merchant Center או להוסיף את המדינות הנוספות באמצעות השדה shipping
במשאב products.
בהמשך מוצגת דוגמה לשינוי ההגדרות של הפיד הראשי ב-Content API.
מידע נוסף זמין במאמר טירגוט מודעות שופינג וכרטיסי מוצר חינמיים בכמה מדינות.
צריך לוודא שספריות הלקוח מעודכנות
אם אתם משתמשים בספריית לקוח של 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 עם כותרת משנה של מוצרים בחנויות מקומיות. חשוב לוודא שאתם לא מוחקים בטעות את הפיד של האונליין או את הפיד המקומי של Content API. בהתאם לפיד שתמחק, המוצרים
אונליין או בחנויות המקומיות שהוספת ל-Merchant Center דרך ה-Content API יוסרו.
קיבוץ בקשות מרובות לאותו שירות באמצעות שיטת custombatch
במקום לשלוח הרבה בקשות ברצף או מקבילות לאותו שירות, אפשר ליצור בקשת מותאמת אישית אחת שמכילה את כל הבקשות הרצויות. כך, זמן האחזור לשליחת בקשות לנקודת הקצה ל-API מתרחש רק פעם אחת לקריאה בהתאמה אישית ולא לכל בקשה בנפרד. זה חשוב במיוחד אם שולחים בקשות עוקבות.
לא לשלוח כמה עדכונים לפריט אחד בחבילה אחת
כתוצאה מכך, יכולות להיות תוצאות בלתי צפויות בגלל אי-ודאות לגבי רצף העדכונים, ועלולה לגרום לשגיאת סתירה.
לא לשלוח עדכונים לפריטים שלא השתנו
הקפידו לשלוח בקשות רק לגבי פריטים חדשים, פריטים שהשתנו או פריטים שנמחקו, אלא אם התוקף של הפריטים יפוג אחרת.
אפשר להשתמש בפידים משלימים אם המחירים ו/או הזמינות משתנים במהירות
אם אתם לא מצליחים לעדכן את פרטי המחיר, הזמינות או המבצע של מוצר מסוים, כדאי להשתמש בפידים משלימים במשאב products כדי לשלוח עדכונים רק למאפיינים האלה. מכיוון שעדכוני הפידים המשלימים הם קטנים, אפשר לבצע הרבה יותר עדכונים משלימים בפידים בפרק זמן נתון מאשר עדכונים מלאים של המוצרים. כך תוכלו לשמור על העדכניות של נתוני המחירים והזמינות של המוצרים בדפי הנחיתה.
עוד דרך לעדכון המחיר והזמינות של מוצרים היא להשתמש בעדכונים אוטומטיים של פריטים. כדאי להשתמש בנתונים האלה בנוסף לעדכוני ה-API, כדי למנוע אי-התאמות בין המידע ב-Merchant Center לבין המידע שבדפי הנחיתה של המוצרים. עם זאת, חשוב לזכור שהפתרון הזה נועד לפתור בעיות קטנות ברמת הדיוק במחיר ובזמינות של מוצרים, ולכן עדכונים אוטומטיים של פריטים לא מחליפים גם את המידע הנכון דרך ה-API.
מתי כדאי להשתמש באסימון רענון
אסימון הרענון מוחזר בכותרת ה-HTTP של בקשות ההרשאה. יש בו עוד הרבה מידע שקשור לאימות, אבל אסימון הרענון הוא לעיתים קרובות החלק שמפתחים רוצים לשים עליו את הידיים, כי הוא מבטל את הצורך לבקש מהמשתמש שוב ושוב אימות, כי אסימוני הגישה נמשכים רק 60 דקות לפני שהתוקף שלהם פג.