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

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

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

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

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

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

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

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

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

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

שיטות באצווה

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

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

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

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

הגדרת מכסות

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

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

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

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

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

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

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

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

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

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

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

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

לא משנה כמה יעיל יהיה הלוגיקה של ניהול הקטלוג, חשוב להבטיח שהיא תהיה עמידה במכסות בלתי צפויות, מכיוון שהמכסה היומית משותפת לנקודות קצה שמשמשות במודולים עצמאיים של השילוב. חשוב לכלול את השגיאות של הגבלת המכסות בטיפול בשגיאות, ולהטמיע את זמני ההמתנה המתאימים. כל קריאה לממשקי ה-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 תמיד מעודכן עם המידע העדכני ביותר מהקטלוג בקצה העורפי, כדי לשפר את חוויית המשתמש. לדוגמה:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כדי לעדכן מינויים קיימים, אפשר להשתמש ב-method‏ 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. הסיבה לכך יכולה להיות שינויים ידניים דחופים בקטלוג במסוף, הפסקה זמנית בשירות של מערכת ניהול הקטלוג או אובדן הנתונים האחרונים.

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

שיקולים לגבי מערכת diff

מומלץ ליצור מערכת diff כדי לזהות אי-עקביות וליישר קו בין שתי המערכות. ריכזנו כאן כמה דברים שכדאי לשקול כשיוצרים מערכת diff כדי לשמור על סנכרון בין הקטלוגים:

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

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

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

  • היצירה נוצרה בטעות.
  • הפסקת השימוש בתכונה או בשירות.

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

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

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

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

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