הטמעת התראות Push על פקיעת מנוי באפליקציות מובייל

כשמשיקים אפליקציה למובייל עם מנויים, מצב טיפוסי: התשלום נכשל, המשתמש אפילו לא שם לב, האפליקציה שותקת. עד 60% מהלקוחות נוטשים בכשלון התשלום האוטומטי הראשון. ללא שרשרת התראות, כמעט בלתי אפשרי לשקם את המנוי. מערכת התראות push מעוצבת היטב שומרת על עד 40% מהמשתמשים שעומדים לבטל. בואו נפרק כיצד להגדיר התראות על פקיעת מנוי באמצעות StoreKit 2, FCM וסגמנטציה נכונה. הניסיון שלנו: 5+ שנים ו-50+ פרויקטי מנויים.

למה התראת Push אחת לא מספיקה

התראה אחת היא אסטרטגיה חלשה. המשתמש עלול להתעלם או לדחות אותה. מחקרים מראים שמפל של 3–4 תזכורות משפר את שיעור החידוש ב-30%. אנחנו משתמשים בשרשרת: 7 ימים לפני → יום אחד לפני → ביום הפקיעה → 3 ימים אחרי. כל שלב כולל קריאה לפעולה ספציפית עם deeplink.

אירועי צד שרת לעומת התראות מקומיות

השאלה הראשונה: איך יודעים מתי המנוי פג? עבור רכישה בתוך האפליקציה (StoreKit), אפל שולחת אירועים לשרת שלך דרך App Store Server Notifications V2. עבור מנויים מותאמים אישית בצד השרת, הלוגיקה היא אצלך.

StoreKit 2 / App Store Server Notifications V2: אפל מספקת אירועי RENEWAL ו-EXPIRED לשרת שלך. עם קבלת DID_FAIL_TO_RENEW — זה האות הראשון לשלוח push. ב-GRACE_PERIOD_EXPIRED — ההזדמנות האחרונה. אפל שולחת כמה התראות מערכת בעצמה, אבל להסתמך רק עליהן אינו מספיק — חייבים לבנות לוגיקה עסקית משלכם לתזכורות.

// Серверная нотификация V2 (декодированный payload)
{
  "notificationType": "DID_FAIL_TO_RENEW",
  "subtype": "GRACE_PERIOD",
  "data": {
    "bundleId": "com.example.app",
    "transactionInfo": {
      ...
    }
  }
}

App Store Server Notifications

התראות מקומיות מתאימות רק אם אין לך שרת בכלל, או לתרחישים לא מקוונים. השתמש ב-UNUserNotificationCenter עם UNCalendarNotificationTrigger — תזמן התראה על // Серверная нотификация V2 (декодированный payload) { "notificationType": "DID_FAIL_TO_RENEW", "subtype": "GRACE_PERIOD", "data": { "bundleId": "com.example.app", "transactionInfo": { ... } } } . בעיה: אם המשתמש מחדש דרך האינטרנט או מכשיר אחר, ההתראה המקומית עדיין תישלח. ללא סנכרון שרת, זה מוביל לתוצאות חיוביות שגויות.

Push מהשרת עדיף פי 3–4 על פני מקומי בדיוק ההגעה ובגמישות התצורה.

שרשרת תזכורות

תוכנית עבודה עבור B2C:

• 7 ימים לפני הפקיעה: "המנוי שלך יפוג ב-15 באפריל — חידש כדי לשמור על הנתונים שלך"
• יום אחד לפני: קריאה לפעולה ספציפית עם deeplink למסך ניהול המנוי
• ביום הפקיעה: התראה עם הצעה לזמן מוגבל (אם זמין)
• 3 ימים אחרי: הפעלה מחדש עם הנחה (אופציונלי)

Deeplink בהתראה הוא חובה. Push ללא פעולה מאבד המרה. ב-iOS: UNNotificationAction עם foreground — פותח את האפליקציה ומעביר userInfo. באנדרואיד: PendingIntent עם Intent מתאים.

// iOS: обработка tap по уведомлению о подписке
func userNotificationCenter(_ center: UNUserNotificationCenter, didReceive response: UNNotificationResponse) async {
    let info = response.notification.request.content.userInfo
    if info["type"] as? String == "subscription_expiry" {
        NavigationRouter.shared.navigate(to: .subscriptionManagement)
    }
}

באנדרואיד דרך FCM, באופן דומה: העבר // iOS: обработка tap по уведомлению о подписке func userNotificationCenter(_ center: UNUserNotificationCenter, didReceive response: UNNotificationResponse) async { let info = response.notification.request.content.userInfo if info["type"] as? String == "subscription_expiry" { NavigationRouter.shared.navigate(to: .subscriptionManagement) } } ב-data payload, ונתב ב-FirebaseMessagingService.onMessageReceived.

class MyFirebaseMessagingService : FirebaseMessagingService() {
    override fun onMessageReceived(message: RemoteMessage) {
        val type = message.data["type"]
        if (type == "subscription_expiry") {
            // Открыть экран подписок
            val intent = Intent(this, SubscriptionActivity::class.java)
            startActivity(intent)
        }
    }
}

מה לעשות אם ה-Push לא נמסר?

בדוק הרשאות התראות (ATT ב-iOS, הגדרות באנדרואיד), מצב ה-device token, ותקינות ה-deeplink. קח בחשבון את אזור הזמן של המשתמש — שלח pushes בשעות היום המקומיות. יישם לוגיקת ניסיון חוזר עם טריגר ידני.

סגמנטציה ותזמון

משתמש עם מנוי חודשי ומשתמש עם מנוי שנתי דורשים גישות שונות. עבור חודשי, חלון של 7 ימים הוא 25% מהתקופה הנותרת — אגרסיבי מדי. עבור שנתי, 7 ימים מתוך 365 זה בסדר.

אזור הזמן של המשתמש הוא קריטי: push ב-3 לפנות בוקר גורם לעצבנות וביטולים. Firebase FCM מאפשר להגדיר delivery_time לפי הזמן המקומי של המכשיר. עבור APNs, זה מטופל בצד השרת באמצעות מתזמן משימות שמכבד את אזור הזמן של המשתמש.

תהליך העבודה שלנו

1. ביקורת על מערכת המנויים הנוכחית שלך: StoreKit / צד שרת / היברידי.
2. הגדר App Store Server Notifications V2 או webhooks לשרת עבור טריגרים של פקיעה.
3. יישם את שרשרת התראות ה-push עם deeplinks למסך המתאים.
4. בדוק בסביבת ה-sandbox של StoreKit וב-FCM חי.
5. נטר והתאם את התזמון לפי אנליטיקה.

מה כלול בעבודה

• הגדרת App Store Server Notifications V2 / webhooks לשרת
• פיתוח שרשרת התראות push (עד 4 שלבים)
• אינטגרציה של deeplinks למסך ניהול המנוי
• רישום אירועים לאנליטיקה
• תיעוד והוראות לצוות שלך
• חודש תמיכה לאחר ההשקה

הערכות זמנים

אינטגרציה עם שרת התראות קיים ו-StoreKit 2 — 2–3 ימים. בניית לוגיקת צד שרת מאפס (מתזמן, סגמנטציית משתמשים) — עד שבוע.

אובדן משתמש אחד עם מנוי שנתי עולה בממוצע $300–$500, ומפל התראות מחזיר 15–20% מהם. יישום שרשרת ההתראות מגדיל את ה-LTV ב-20–30% ומפחית את עלויות רכישת משתמשים חדשים ב-15%.

קבל ייעוץ לפרויקט שלך — צור קשר כדי להעריך את ההיקף ולהציע פתרון. בקש ביקורת על מערכת המנויים הנוכחית שלך.