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

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

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

Catalog Management APIs

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

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

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

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

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

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

נקודת הקצה monetization.subscriptions עוזרת לכם לנהל מוצרים למינוי מהקצה העורפי של המפתחים. אתם יכולים לבצע פעולות כמו יצירה, עדכון ומחיקה של מינויים, או לשלוט בזמינות ותמחור לפי אזור (RAAP) שלהם. בנוסף לנקודת הקצה 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, אין לה השלכות מעשיות על משתמשים שמשתמשים רק בשיטות שינוי יחידות.
  • בקשת Batch 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"
  } ],
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כל ה-methods הקודמים יוצרים מינויים יחד עם תוכניות הבסיס שלהם (שמסופקות באובייקט Subscription). המינויים הבסיסיים האלה לא פעילים בהתחלה. כדי לנהל את הסטטוס של מינויים בסיסיים, אפשר להשתמש בנקודת הקצה monetization.subscriptions.basePlans, כולל הפעלת מינוי בסיסי כדי להפוך אותו לזמין לרכישה. בנוסף, נקודת הקצה 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, או אם אתם בוחרים לעדכן אותו באופן תקופתי. יכול להיות שהסיבה לכך היא שינויים ידניים דחופים בקטלוג במסוף, הפסקה זמנית בשירות במערכת לניהול הקטלוג או אובדן של הנתונים האחרונים.

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

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

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

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

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

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

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

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

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

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

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