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

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

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

Catalog Management APIs

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

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

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

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

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

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

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

שיטות לביצוע פעולות בקבוצות

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

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

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

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

הגדרת מכסות

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

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

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

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

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

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

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

חשוב לשים לב לתהליכים שצורכים הרבה משאבים. לדוגמה, בתחילת השילוב, סביר להניח שנקודות הקצה לניהול הקטלוג יצרכו יותר מכסה כדי ליצור את הקטלוג הראשוני המלא, וזה עלול להשפיע על השימוש בייצור בנקודות קצה אחרות, כמו API של סטטוס הרכישה, אם אתם קרובים למגבלת השימוש הכוללת. צריך לעקוב אחרי ניצול המכסה כדי לוודא שלא חורגים מהמכסות של ה-API. יש כמה דרכים לעקוב אחרי השימוש. לדוגמה, אפשר להשתמש בלוח הבקרה של המכסות של ממשקי Google Cloud APIs, או בכל כלי אחר לניטור 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 מאפשרות לכם לעדכן את הקטלוג כשמתרחשים שינויים. לפעמים תצטרכו להשתמש בגישה של עדכונים תקופתיים, שבה אתם שולחים סדרה של שינויים באותו תהליך. כל גישה דורשת בחירות עיצוביות שונות. כל אסטרטגיית סנכרון מתאימה יותר לחלק מהתרחישים מאשר לאחרים, ויכול להיות שיהיו לכם צרכים שיתאימו לשתי האסטרטגיות, בהתאם למצב. לפעמים תרצו לעדכן מוצר ברגע שתגלו שינוי חדש, למשל כדי לעבד עדכון דחוף של מוצר (כלומר, צריך לתקן מחיר שגוי בהקדם האפשרי). במקרים אחרים, אפשר להשתמש בסנכרון תקופתי ברקע כדי לוודא שהקטלוגים של ה-Backend ושל Play תמיד עקביים. כדאי לקרוא על כמה תרחישי שימוש נפוצים שבהם כדאי להטמיע את אסטרטגיות הניהול השונות של הקטלוג.

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

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

העדכונים האלה יכולים להועיל לכם אם:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • monetization.onetimeproducts.batchUpdate
  • ‫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, יכול להיות שיהיו מצבים שבהם הקטלוג לא יהיה מסונכרן עם הקטלוג בהגדרות האפליקציות שלכם ב-Play. זה יכול לקרות בין אם אתם בוחרים לעדכן את הקטלוג של Google Play בכל פעם שמשתנה הקטלוג של ה-Backend, או באופן תקופתי. יכול להיות שהסיבה לכך היא שינויים ידניים דחופים בקטלוג ב-Console, הפסקת פעולה במערכת לניהול הקטלוג או אובדן של הנתונים האחרונים.

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

התייחסות למערכת ההבדלים

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

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

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

ממשק Google Play Developer API מספק את השיטות הבאות שיעזרו לכם להוציא את המוצרים שלכם משימוש:

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

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

יכול להיות שיהיה צורך להוציא מוצר משימוש בתרחישים שונים, למשל:

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

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