ניהול קטלוג המוצרים

במדריך הזה מוסבר איך להשתמש ב-Google Play Developer API כדי ליצור לנהל קטלוג מוצרים של אפליקציית Play.

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

ממשקי API לניהול קטלוג

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

• מוצרים בחיוב חד-פעמי
• מוצרים מסוג מינוי

מוצרים בחיוב חד-פעמי

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

מוצרים מסוג מינוי

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

שיטות אצווה

inappproducts וmonetization.subscriptions נקודות קצה (endpoints) מספקות כמה שיטות באצווה שמאפשרות לאחזר או לנהל ל-100 ישויות באותה אפליקציה בו-זמנית.

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

עדכון זמן האחזור של ההפצה לעומת התפוקה

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

הגדרת המכסה

יש מספר מגבלות במכסות שצריך לשים לב אליהן כשמשתמשים למפתחים ב-Play API לניהול קטלוג המוצרים:

1. כברירת מחדל, על ממשקי ה-API למפתחים של Google Play יש מגבלה של 200,000 שאילתות יום. מגבלת המכסה הזו חלה על צבירת השימוש בכל נקודות הקצה, כולל ממשקי API לניהול קטלוג.
2. נקודות הקצה (endpoints) של שינויי מוצרים אוכפות גם מגבלה של 7,200 שאילתות לכל שעה. זוהי מגבלה אחת גם למוצרים בחיוב חד-פעמי וגם למינויים ובכל בקשות השינוי, כולל יצירה, עדכון, הפעלה, מחיקה. קריאות לשיטות שינוי בכמות גדולה נספרות כשאילתה אחת עבור המכסה הזו, בלי קשר למספר הבקשות הנפרדות הכלולות או לזמן האחזור שלהן רגישות.
3. גם לשינויים רגישים בזמן אחזור יש מגבלה של 7,200 שינויים לשעה. בשיטות אצווה, כל בקשת שינוי פנימית נספרת בנפרד למטרות המכסה הזו. במכסה הזו יש רק על המשתמשים ב-API באצווה עם ביצועים רגישים לזמן אחזור אחרת, כמו במקרים אחרים, מכסה 2 תמצה לפני או באותה מסגרת במכסה הזאת.

הנה כמה דוגמאות להמחשה של השימוש במכסות בקשות שונות:

• בקשת get יחידה לאחזור פריט אחד תצרוך אסימון אחד של מכסה 1 וגם אין אסימונים במכסה 2 ו-3 (כי מדובר רק בנקודות קצה לשינוי).
• גם בקשת get באצווה לאחזור של עד 100 פריטים תצרוך אסימון אחד של מכסה 1 ואין אסימונים במכסה 2 ו-3.
• בקשת modification אחת לפריט אחד תצרוך אסימון אחד ממכסה 1 , אסימון אחד של מכסה 2. אם הבקשה רגישה לזמן אחזור, תתבצע גם צריכה אסימון אחד ממכסה 3. מכיוון שבמכסה ג' יש אותה גבול כמו מכסה 2, אין השלכות מעשיות על משתמשים שמשתמשים רק בשינוי אחד שיטות.
• בקשת modification באצווה ל-100 פריטים סבילים לזמן אחזור תצרוך 1 אסימון למכסה 1, אסימון 1 למכסה 2. הגדרת המכסה הזו אמורה לספק כמות גדולה של כדי לשמור על קטלוג עדכני, אבל אם האלגוריתם שלכם לא מודע במכסה הזו מעבר לתעריף הזה, יכול להיות שתופיע שגיאה לכל שיחה נוספת.
• בקשת modification באצווה ל-100 פריטים רגישים בזמן אחזור תצרוך אסימון אחד למכסה 1, אסימון אחד למכסה 2 ו-100 אסימונים למכסה 3.

המלצות לשימוש ב- Catalog Management API

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

מעקב אחר השימוש

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

אופטימיזציה של ניצול המכסה ב-API

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

• תבחרו את האסטרטגיה המתאימה לניהול הקטלוג. אחרי שתבינו את ה-API עליכם לבחור את האסטרטגיה המתאימה לאפליקציה ואת היעדים של ניהול הקטלוג שלכם בצורה יעילה.
• כדאי לבצע רק את מספר השיחות המינימלי שדרוש כדי לשקף את השינויים.
• אין לשלוח לממשקי ה-API קריאות שינויים מיותרות או מיותרות. הזה יכול להיות שתצטרכו לשמור יומן שינויים בקטלוג הקצה העורפי.
• מומלץ להישאר מתחת למגבלה של 7,200 שאילתות לשינוי מוצר. אפשר רוצים ליצור תהליכי סנכרון שמחייבים אתכם ליצור כמויות גדולות של מוצרים בפרק זמן קצר (למשל, יצירה). אם צפוי שהתהליכים האלה יחרגו מהמגבלה לשעה, ימתין לפי הצורך כדי להאט את השימוש לרמה בטוחה. כדאי להשתמש שיטות אצווה עם עדכונים סבילים לזמן אחזור, כדי להשיג תפוקה גבוהה יותר.
• היערכות יזומה להתאמה לעומס. ככל שהאפליקציה שלכם תגדל, ייתכן שתצטרכו להתאים את השימוש שלכם ב-API ובנקודות הקצה השונות. קרא את Google מסמכי תיעוד בנושא המכסות של Play Developer API להגדיל את המכסה כשמתקרבים למגבלת השימוש.
• תזמון אסטרטגי של תהליכים מורכבים. כדאי לנסות לתזמן את ההצגה של קטלוג עמוס תהליכים סביב שיאי שימוש קריטיים, לדוגמה, אפשר להימנע מהרצת לבצע סנכרון מלא של הקטלוג במהלך תקופות השיא של המכירות בשבוע.

הוספת לוגיקה לטיפול בשגיאות מכסה

לא משנה עד כמה הלוגיקה של ניהול הקטלוג היא יעילה, כדאי לבצע את הפעולות הבאות להתמודד עם מגבלות מכסה בלתי צפויות, בהינתן שהמכסה היומית שמשותף לנקודות קצה (endpoints) שבהן נעשה שימוש במודולים עצמאיים של השילוב. כדאי לוודא כוללים שגיאות של ויסות מכסות בטיפול בשגיאות, ומטמיעים את המתאימה. כל קריאה לממשקי API של Google Play למפתחים תיצור תגובה. ב במקרה של כשל בשיחה, תקבלו תשובה שנכשלה שכוללת קוד הסטטוס של תשובת HTTP ואובייקט errors, עם פרטים נוספים על דומיין השגיאה והודעת ניפוי באגים. לדוגמה, אם תחרגו מהמגבלה היומית, יכול להיות שתקבלו הודעת שגיאה דומה לנוסחה:

{
  "code" : 403,
  "errors" : [ {
    "domain" : "usageLimits",
    "message" : "Daily Limit Exceeded. The quota will be reset at midnight Pacific Time (PT). You may monitor your quota usage and adjust limits in the API
  Console: https://console.developers.google.com/apis/api/androidpublisher.googleapis.com/quotas?project=xxxxxxx",
  "reason" : "dailyLimitExceeded",
  "extendedHelp" : "https://console.developers.google.com/apis/api/androidpublisher.googleapis.com/quotas?project=xxxxxx"
  } ],
}

הטמעה של ניהול קטלוג

המפתחים משתמשים בנקודות הקצה לפרסום מוצרים של Google Play Developer API כדי לשמור על סנכרון הקטלוג בין הקצה העורפי שלהם לבין Google Play. ייצור חשוב לוודא שקטלוג Google Play תמיד מעודכן לקטלוג של הקצה העורפי למידע העדכני ביותר יש יתרונות ליצירת חוויית משתמש טובה יותר. לדוגמה:

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

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

אסטרטגיות לסנכרון של קטלוג

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

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

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

סוג העדכונים הזה מתאים במיוחד כאשר:

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

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

מתי כדאי להשתמש בעדכונים תקופתיים

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

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

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

יצירת קטלוג מוצרים

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

יצירת מוצרים בחיוב חד-פעמי

כדי ליצור קטלוג גדול של מוצרים חד-פעמיים בפעם הראשונה, מומלץ להשתמש השיטה inappproducts.batchUpdate כשהשדה allowMissing מוגדר לערך true והשדה latencyTolerance מוגדרים לערך PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT. הפעולה הזו תצמצם את הזמן הדרוש ליצירת הקטלוג במסגרת המכסה.

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

יצירת מוצרים מסוג מינוי

ליצירה ראשונית של קטלוג גדול למנויים, מומלץ להשתמש אמצעי תשלום monetization.subscriptions.batchUpdate כשהשדה allowMissing מוגדר ל-true והשדה latencyTolerance מוגדר אל PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT. הפעולה הזו תצמצם את הזמן הדרוש ליצירת הקטלוג במסגרת המכסה.

עבור קטלוגים קטנים יותר של מינויים, Play Developer API מספק monetization.subscriptions.create. אפשר גם ליצור מינויים באמצעות monetization.subscriptions.update עם allowMissing, כפי שמתואר בקטע 'עדכוני מוצרים'.

כל השיטות הקודמות יוצרות מינויים יחד עם המינויים הבסיסיים שלהם (מסופק באובייקט Subscription). המינויים הבסיסיים האלה לא פעיל. ניהול המינויים הבסיסיים אפשר להשתמש נקודת הקצה monetization.subscriptions.basePlans, כולל הפעלת מינוי בסיסי כדי שיהיה זמין לרכישה. בנוסף, נקודת הקצה monetization.subscriptions.basePlans.offers שמאפשר ליצור ולנהל מבצעים.

עדכוני מוצרים

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

עדכון מוצרים בחיוב חד-פעמי

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

• inappproducts.patch : נקודת הקצה של התיקון משמשת לעדכון חלקי של משאב. המשמעות היא יכולים לעדכן שדות ספציפיים שאתם מציינים בגוף הבקשה. התיקון בדרך כלל משתמשים בנקודת הקצה אם צריך לעדכן רק כמה שדות משאב.
• inappproducts.update : נקודת הקצה לעדכון משמשת לעדכון משאב בשלמותו. כלומר צריך לשלוח את כל אובייקט המשאב בגוף הבקשה. בדרך כלל משתמשים בנקודת הקצה המעודכנת כשצריך לעדכן את כל השדות משאב. כאשר הפרמטר allowMissing מוגדר ל-true ומוגדר מזהה המוצר לא קיים כבר. נקודת הקצה תוסיף את המוצר. במקום להיכשל.
• inappproducts.batchUpdate : זוהי גרסת אצווה של נקודת הקצה לעדכון, שמאפשרת לשנות מספר מוצרים עם שאילתה אחת. משתמשים בו יחד עם השדה latencyTolerance הוגדר בתור PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT כדי להשיג תפוקה גבוהה יותר.

עדכון מוצרים מסוג מינוי

כדי לעדכן מינויים קיימים, אפשר להשתמש monetization.subscriptions.patch. השיטה הזו כוללת את הפרמטרים הנדרשים הבאים:

• packageName: שם החבילה של האפליקציה שאליה המינוי שייך.
• productId: מזהה המוצר הייחודי של המינוי.
• regionsVersion: הגרסה של הגדרת האזור.

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

לדוגמה, אם רוצים לעדכן רק כרטיס מוצר מסוג מינוי, עליכם לציין את השדה listings לפרמטר updateMask.

אפשר להשתמש ב-monetization.subscriptions.batchUpdate כדי לעדכן מספר מינויים בו-זמנית. משתמשים בו יחד עם השדה latencyTolerance מוגדר לערך PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT כדי להגיע לרמה גבוהה יותר תפוקה.

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

בנוסף, אפשר לעדכן את המינויים הבסיסיים מבצעים עם monetization.subscriptions.basePlans.offers.patch .

התאמת קטלוג

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

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

הבדלים בהתעניינות ברכישה של המערכת

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

• הבנת המודלים של הנתונים: השלב הראשון הוא להבין את הנתונים של מערכת ניהול התוכן למפתחים ושל ממשק ה-API של Google Play למפתחים. המידע הזה כולל לדעת מהם סוגי הנתונים השונים שמאוחסנים בכל מערכת, ואיך רכיבי הנתונים השונים ממופים זה לזה.
• מגדירים את כללי ההבדלים: אחרי שתבינו את המודלים של הנתונים, תצטרכו מגדירים את כללי ההבדלים. הכללים האלה יקבעו איך הנתונים בשני סוגי הנתונים והשוואה בין מערכות. לדוגמה, ייתכן שתהיה התאמה בין מזהי המוצרים להשוות בין מאפיינים עיקריים של המינוי ושל המינויים הבסיסיים שמשויכים אליו, מבצעים.
• מטמיעים אלגוריתם דיפר: לאחר שמגדירים את כללי ההבדלים, צריכים ליישם את אלגוריתם ההבדלים. האלגוריתם הזה יפיק את הנתונים בין שתי המערכות, ולהשוות אותו לפי הכללים שהגדרתם. כדי לקבל בנתוני הקטלוג מ-Google Play, אפשר להשתמש inappproducts.list inappproducts.batchGet, monetization.subscriptions.list וגם שיטות monetization.subscriptions.batchGet.
• יצירת דוחות הבדלים: אלגוריתם ההבדלים יפיק דוח הבדלים. בדוח הזה יוצגו ההבדלים בין שתי המערכות.
• התאמת הבדלים: אחרי שיוצרים את דוח ההבדלים, צריך כדי לפתור את ההבדלים. ייתכן שיהיה צורך בעדכון הנתונים במערכת ניהול התוכן, או ייתכן שיהיה צורך לעדכן את הנתונים בצד של Google Play באמצעות ה-API למפתחים. ניהול קטלוגים, בהתאם לאופן שבו אתם בדרך כלל מעדכנים בקטלוג. כדי לבצע התאמה של מוצרים שלא סונכרנו, צריך להשתמש בנקודות הקצה לעדכון, כפי שמתואר ב בקטע 'עדכוני מוצרים'.

הוצאה משימוש של מוצר

ממשק ה-API של Google Play למפתחים מציע מספר שיטות לסייע למפתחים ב ולהוציא את המוצרים שלהם משימוש: inappproducts.delete ו- inappproducts.batchDelete למוצרים בחיוב חד-פעמי monetization.subscriptions.delete למינויים. יכול להיות שיהיה צורך להוציא מוצר משימוש בתרחישים שונים , למשל:

• יצירה שגויה.
• ביטול של תכונה או שירות.

מומלץ לשלב את ההוצאה משימוש של המוצר בניהול הקטלוג את האסטרטגיה שלנו.

מוציאים משימוש מוצרים בחיוב חד-פעמי

כדי למחוק מוצרים בחיוב חד-פעמי באמצעות Google Play Developer API, צריך להשתמש ב- ה inappproducts.delete או inappproducts.batchDelete .

הוצאה משימוש של מוצרים מסוג מינוי

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