במסמך הזה מפורטות הנחיות לשיטות מומלצות. מידע נוסף זמין בטיפים בנושא ביצועים.
מתי כדאי להשתמש ב-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. אפשר להיעזר בשיטות האלה בלקוחות שמעלים מידע כדי לנפות באגים בזמן תכנון פתרונות שמשתמשים ב-Content API. עם זאת, הם לא מיועדים לאחזור קבוע של פרטי המוצרים על ידי הלקוחות. צריך להיות לכם מקור נוסף לפרטי המוצרים, כמו מסד נתונים של מוצרים בחנויות מקומיות, והמוצרים ב-Merchant Center אמורים לשקף את התוכן של המקור.
אסור להשתמש גם בפידים של נתונים וגם ב-Content API כדי לשלוח פריטים של מוצרים
אם אתם שוקלים לעבור ל-API לצורך שליחת פריטים, עליכם לוודא שאתם לא משתמשים יותר בפידים של נתונים לשליחת פריטים של מוצרים. אם תמשיכו לשלוח פריטים בשני המדיום, ייתכן שיתקבלו תוצאות בלתי צפויות.
האם יש דרך שבה אפשר להשתמש בבטחה ב-API ובפידים של נתונים ביחד?
אפשר לשנות את הפידים של הנתונים באמצעות שירות פיד הנתונים של ה-API. זה יקל מאוד על ניהול פיד הנתונים בקנה מידה נרחב, אבל חשוב לזכור שלא מוסיפים או מעדכנים מוצרים באמצעות ה-API בו-זמנית עם פידים, כי יכולות להיות תוצאות לא צפויות.
דוגמאות נוספות לשימוש מקובל בפידים וב-API יחד:
ביצוע בקשות לקריאה בלבד (קבלה או רשימה) מה-API: חלק מהמוכרים רוצים להשתמש ב-API כדי לאחזר מידע ועדכוני סטטוס לגבי המוצרים שלהם. זה מצב קביל, כי פרטי המוצרים מתעדכנים רק באמצעות פידים.
שימוש ב-API לניהול חשבונות המשנה (Accounts Service) והגדרות המס והמשלוח ברמת החשבון (Accounttax Service ו-Shippingsettings Service). אלו לא פונקציות שאפשר לספק ב-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
במקום לשלוח בקשות רבות במקביל לאותו שירות, צריך ליצור בקשת custombatch אחת שמכילה את כל הבקשות הרצויות. כך, זמן האחזור לשליחת בקשות לנקודת הקצה ל-API מתרחש רק פעם אחת לקריאה מותאמת אישית במקום לכל בקשה בנפרד, חשוב במיוחד אם אתם שולחים בקשות רציפות.
אין לשלוח מספר עדכונים לפריט אחד באצווה אחת
כתוצאה מכך, יכולות להיות תוצאות בלתי צפויות בגלל אי-ודאות לגבי רצף העדכונים, ועלולה לגרום לשגיאה של התנגשות.
לא לשלוח עדכונים לפריטים שלא השתנו
חשוב לשלוח בקשות רק לפריטי מוצר חדשים, ששונו או שנמחקו, אלא אם התוקף שלהם יפוג.
שימוש בפידים משלימים אם המחירים או הזמינות משתנים במהירות
אם אתם לא מצליחים לעדכן את נתוני המחיר, הזמינות או המבצע של מוצר מסוים, מומלץ להשתמש בפידים משלימים במשאב products כדי לשלוח עדכונים רק למאפיינים האלה. מכיוון שעדכוני הפיד המשלימים קטנים, אפשר לבצע הרבה יותר עדכונים משלימים בפרק זמן נתון מאשר עדכונים מלאים של המוצרים. כך תוכלו להתאים את המחירים והזמינות של המוצרים לדפי הנחיתה.
דרך נוספת לעדכון המחיר והזמינות של מוצרים היא באמצעות עדכונים אוטומטיים של פריטים. אפשר להשתמש בו בנוסף לעדכוני API, כדי למנוע אי-התאמות בין המידע ב-Merchant Center לבין המידע בדפי הנחיתה של המוצרים. עם זאת, חשוב לזכור שמטרת המדיניות הזו נועדה לתקן בעיות קטנות בדיוק של נתוני מחיר וזמינות של מוצרים, ולכן עדכונים אוטומטיים של פריטים לא באים במקום גם לספק את המידע הנכון דרך ה-API.
מתי כדאי להשתמש באסימון רענון
אסימון הרענון מוחזר בכותרת ה-HTTP של בקשות להרשאות. הוא מכיל הרבה מידע נוסף שקשור לאימות, אבל הרבה פעמים מפתחים רוצים להשתמש באסימון הרענון, כי הוא מבטל את הצורך לבקש מהמשתמש לבצע אימות שוב ושוב, כי אסימוני הגישה תקפים רק 60 דקות לפני שהתוקף שלהם פג.