כשמוכרים מוצרים דיגיטליים דרך האפליקציה, צריך לקחת בחשבון את חוויית המשתמש הכוללת. שילוב באפליקציה מאפשר לכם להפעיל תהליכי רכישה ולנהל את חוויית המשתמש, אבל חשוב מאוד לעדכן את ה-Backend לגבי ההרשאות שהמשתמשים רוכשים. הנתונים האלה חשובים למעקב אחרי רכישות ולניהול היבטים אחרים של חוויית המשתמש, כמו הרשאות בפלטפורמות שונות.
כדי לעקוב אחרי אירועים במחזור החיים של הרכישה ולהגיב במהירות לשינויים בהרשאות המשתמשים, כדאי לבנות במערכת העורפית מערכת לניהול סטטוס הרכישה, גם למינויים וגם לרכישות חד-פעמיות. המערכת הזו מבטיחה עיבוד מהיר ומאובטח של רכישות, ללא קשר למצב המכשיר, שומרת על הרשאות משתמש עקביות בכל הפלטפורמות ומאפשרת לכם לעיין בהיסטוריית הרכישות ובנתוני ההרשאות בקצה העורפי.
Google Play מציע התראות בזמן אמת למפתחים (RTDN) כדי לעקוב אחרי אירועים במחזור החיים של הרכישות, ואפשר להשתמש בממשקי Play Developer API למינויים ולרכישות מתוך האפליקציה כדי לבצע את הפעולות הנדרשות על סמך האירועים האלה. באמצעות הכלים האלה ובניית מערכת חזקה לניהול מחזור החיים של הרכישות, תוכלו לספק חוויית משתמש חלקה ולנהל את הרכישות וההרשאות בצורה יעילה.
יצירת לקוח של התראות בזמן אמת למפתחים
רכישות שמבוצעות דרך מערכת החיוב של Google Play יכולות לעבור כמה שינויים בהרשאות במהלך מחזור החיים שלהן. יש פעולות שונות שיכולות להפעיל את השינויים האלה, כולל:
- פעולות שהמשתמשים מתחילים באפליקציה.
- פעולות שהמשתמשים מבצעים דרך אפליקציית חנות Play.
- פעולות שמתחילות ישירות ממערכות ה-Backend.
- פעולות שאתם יוזמים דרך Google Play Console.
לדוגמה:
- משתמש מבטל מינוי דרך מרכז המינויים של חנות Play.
- מפתח שדוחה את החיוב על מינוי באמצעות Google Play Developer API.
- מפתח שמנפיק החזר כספי ומבטל את הזכאות לרכישה דרך Google Play Console.
חשוב מאוד שהקצה העורפי שלכם יהיה מודע למצבים השונים שרכישה יכולה לעבור, ושהוא ינקוט את כל האמצעים הנדרשים כדי להתאים את ההרשאה בהתאם ובזמן.
אפשר להשתמש בממשק API של Google Play למפתחים כדי לבדוק את סטטוס הרכישה באופן ידני, אבל להסתמך על בדיקות תקופתיות זה לא יעיל במיוחד למעקב אחרי שינויים, ויש סיכוי גבוה לשגיאות ולעיכובים. הודעות RTDN יכולות לעזור לכם להגיב לשינויים באופן מיידי, בלי שתצטרכו ליצור לוגיקה למעקב אחר מחזור החיים של הרכישות ב-Google Play.
בקטע הזה מוסבר איך ליצור לקוח ל-RTDN. RTDN הוא תכונה שמבוססת על Google Cloud Pub/Sub, ושולחת לשרת העורפי שלכם התראה מיידית כשמצב הזכאות של משתמש משתנה. מערכת Pub/Sub מורכבת ממוציא לאור ששולח התראות ומלקוח שנרשם לקבלת ההתראות האלה. הטמעה של RTDN מאפשרת לעקוב אחרי כל השינויים במצב הזכאות של המשתמש בזמן אמת ולהגיב להם במהירות.
מפרסם נתוני RTDN
הקצה העורפי של Google Play פועל כמוציא לאור של RTDN. כדי להגדיר RTDN באפליקציה, פועלים לפי ההוראות במדריך ההגדרה. השלבים האלה מאפשרים למערכת החיוב של Google Play לפעול כבעל האפליקציה עבור הודעות ה-RTDN של האפליקציה. כדי להשלים את ההגדרה הזו, כדאי להכיר את מסוף Google Cloud Platform כדי להגדיר הגדרת Pub/Sub בסיסית.
מנוי ל-RTDN
אחרי שמגדירים את בעל התוכן הדיגיטלי, צריך להכין את הבק-אנד לצריכת הודעות RTDN. כדי לעשות את זה, צריך ליצור לקוח לקבלת הודעות Google Cloud Pub/Sub. הפונקציה הבסיסית של לקוח RTDN היא קבלת מופעים של PubSubMessage, באמצעות בקשות HTTPS בנקודת קצה רשומה או באמצעות ספריות הלקוח של Cloud Pub/Sub. במסמכי התיעוד של Pub/Sub אפשר לקרוא על שימוש באסטרטגיית push או באסטרטגיית pull, ובמסמכי התיעוד בנושא הגדרת RTDN אפשר לקרוא הנחיות לבחירת האסטרטגיה שהכי מתאימה לצרכים שלכם.
לכל הודעה שמתקבלת, ה-Backend צריך לבצע את הפעולות הבאות:
- פורקים את השדה
dataבקידוד base64, שמכיל את אובייקט ה-RTDN. - צריך לבדוק את הייחודיות של השדה
messageIdולוודא שלא מתבצע עיבוד של התראות כפולות. כך נמנע עיבוד מיותר ולא חורגים ממכסת ה-API. - מפעילים את כל התהליכים הנדרשים בשרת העורפי שקשורים לשינוי בהרשאה שדווח באירוע RTDN.
טיפול במעברים בין מצבי רכישה
לרכישות חד-פעמיות ולרכישות של מינויים יש מחזורי חיים שונים, בהתאם למצבים ולאירועים השונים שיכולים להשפיע עליהם. הודות ל-RTDN, לא צריך לבנות לוגיקה כדי לאשר מעברים בין מצבים. כל מה שצריך לעשות הוא להגדיר מה קורה כששרת הקצה העורפי מקבל כל סוג של התראה.
במדריכים הבאים אפשר למצוא מידע נוסף על התרחישים האלה: