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