התראות Push שקטות: כיצד הן עובדות, הגדרה ל-iOS ו-Android, ומקרי שימוש אסטרטגיים

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

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

מדריך זה מכסה כיצד התראות push שקטות עובדות ב-iOS וב-Android, כיצד נראה המימוש בקוד, וכיצד להשתמש בהן באופן אסטרטגי כחלק מאוטומציית מסע הלקוח. בדרך, תראה כיצד Pushwoosh מטפלת בהעברת push שקט חוצת-פלטפורמות ומשלבת אותה בזרימות עבודה אוטומטיות.

מהן התראות push שקטות?

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

ההבדל מ-push רגיל פשוט: push גלוי הוא הודעה למשתמש; push שקט הוא הוראה לאפליקציה.

מה יכולה אפליקציה לעשות בשניות הרקע האלה?

• אחזור תוכן חדש. משיכת המאמרים האחרונים, קטלוג מוצרים מעודכן, או פיד חברתי מרענן כך שהוא יהיה מוכן כשהמשתמש יפתח את האפליקציה.
• סנכרון נתונים. עדכון המצב המקומי עם שינויים שהתרחשו בשרת או דרך ערוצים אחרים - רכישה שבוצעה באתר, שינוי סטטוס במערכת backend.
• הערכת מיקום. בדיקה האם המשתמש נכנס לאזור גיאוגרפי (geofence) או יצא ממנו ללא צורך בהתראה גלויה כטריגר.
• עדכון תגיות משתמש או נתוני סגמנט. דחיפת אותות התנהגותיים עדכניים חזרה ל-CDP כדי שהמיקוד יישאר מדויק.
• טעינה מוקדמת של תוכן עבור התראה גלויה קרובה. הכנת הודעה in-app או payload push עשיר כך שיוצג מיד כשיופעל.

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

כיצד עובדות התראות push שקטות

שרשרת ההעברה זהה להתראת push רגילה: השרת שלך שולח payload ל-APNs (iOS) או ל-FCM (Android), השירות מעביר אותו למכשיר, ומערכת ההפעלה פועלת בהתאם. מה שונה הוא מבנה ה-payload ומה שמערכת ההפעלה עושה כשהוא מגיע.

זרימת ההעברה

1. השרת שולח payload. ה-backend שלך או Pushwoosh שולחים הודעה בעלת מבנה מיוחד ל-APNs או ל-FCM.
2. השירות מעביר למכשיר. APNs או FCM מנתבים את ה-payload למכשיר הנכון באמצעות אסימון המכשיר השמור.
3. מערכת ההפעלה מעירה את האפליקציה. בזיהוי דגלי ה-push השקט ב-payload, מערכת ההפעלה מפעילה את האפליקציה לזמן קצר ברקע.
4. האפליקציה מריצה את משימת הרקע. הקוד שלך מתבצע: אחזור נתונים, סנכרון מצב, בדיקת מיקום, עדכון תג.
5. האפליקציה מאותתת על השלמה. ב-iOS, האפליקציה קוראת ל-completion handler. ב-Android, onMessageReceived() מחזיר. מערכת ההפעלה מחזירה את האפליקציה לשינה.

חלון הרקע מוגבל. iOS נותן בערך 30 שניות. Android משתנה לפי המכשיר ומצב הצריכה. משימות רקע חייבות להיות מהירות או מתוכננות לפעול בתוך מגבלות אלה.

הבדלי payload: iOS מול Android

הטעות הנפוצה ביותר ב-iOS היא שכחה להגדיר apns-priority: 5 לצד apns-push-type: background. אם העדיפות מוגדרת ל-10 (ברירת המחדל לדחיפות גלויות), Apple עשויה לדחות את ההודעה או להציגה חזותית גם ללא גוף התראה. העדיפות הנמוכה היא שמאותתת ל-APNs שמדובר במשימת רקע, ולא בהתראה דחופה.

ב-Android, הכלל הקריטי פשוט יותר: ללא אובייקט notification ב-payload של FCM. אם אובייקט notification קיים, Android מטפל בו כהתראת push רגילה ומציג אותה. push שקט = נתונים בלבד.

מימוש ב-iOS

הגדרת Xcode

הפעל Background Modes ב-Xcode לפני כתיבת קוד כלשהו:

1. פתח את הפרויקט שלך ובחר את יעד האפליקציה שלך.
2. עבור ל-‘Signing & Capabilities’ ולחץ על ’+ Capability’.
3. הוסף ‘Background Modes’ וסמן ‘Remote Notifications’.

ה-App ID שלך ב-Apple Developer Portal חייב לכלול Push Notifications מופעל. צור מחדש את פרופילי ה-provisioning לאחר ביצוע שינוי זה.

רישום להתראות מרחוק

push שקט עדיין דורש רישום מכשיר עם APNs. טפל בזה ב-AppDelegate:

import UIKit
import UserNotifications

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {

    func application(_ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions:
            [UIApplication.LaunchOptionsKey: Any]?) -> Bool {

        UNUserNotificationCenter.current().delegate = self
        UNUserNotificationCenter.current().requestAuthorization(
            options: [.badge, .sound, .alert]
        ) { granted, _ in
            if granted {
                DispatchQueue.main.async {
                    application.registerForRemoteNotifications()
                }
            }
        }
        return true
    }

    func application(_ application: UIApplication,
        didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data) {
        let token = deviceToken.map {
            String(format: "%02.2hhx", $0) }.joined()
        // Pushwoosh iOS SDK handles token submission automatically
    }
}

טיפול ב-push השקט

זוהי השיטה ש-iOS קורא לה כאשר push שקט מגיע:

extension AppDelegate {

    func application(_ application: UIApplication,
        didReceiveRemoteNotification userInfo: [AnyHashable: Any],
        fetchCompletionHandler completionHandler:
            @escaping (UIBackgroundFetchResult) -> Void) {

        guard let aps = userInfo["aps"] as? [String: AnyObject],
              aps["content-available"] as? Int == 1 else {
            completionHandler(.noData)
            return
        }

        // Run your background task here
        fetchLatestContent { success in
            completionHandler(success ? .newData : .noData)
        }
    }
}

תמיד קרא ל-completionHandler לפני סגירת חלון 30 השניות. אם לא תעשה זאת, iOS יכול לסיים את האפליקציה ולהגביל push שקט עתידי. העבר .newData אם אחזרת משהו, .noData אם לא השתנה דבר, .failed אם המשימה נכשלה.

payload של APNs ל-push שקט

{
    "aps": {
        "content-available": 1
    },
    "update_type": "content_refresh",
    "content_id": "latest_feed"
}

כותרות APNs נדרשות לצד payload זה:

• apns-push-type: background
• apns-priority: 5

מימוש ב-Android

הגדרת FCM ו-manifest

הוסף את FirebaseMessagingService ל-AndroidManifest.xml שלך:

<service
    android:name=".MyFirebaseMessagingService"
    android:exported="false">
    <intent-filter>
        <action android:name="com.google.firebase.MESSAGING_EVENT" />
    </intent-filter>
</service>

טיפול בהודעות נתונים ב-Kotlin

הרחב את FirebaseMessagingService ומממש את onMessageReceived:

class MyFirebaseMessagingService : FirebaseMessagingService() {

    override fun onNewToken(token: String) {
        // Pushwoosh Android SDK handles token submission automatically
    }

    override fun onMessageReceived(remoteMessage: RemoteMessage) {
        // Silent push = data payload only, no notification object
        if (remoteMessage.data.isNotEmpty()
            && remoteMessage.notification == null) {
            handleSilentPush(remoteMessage.data)
        }
    }

    private fun handleSilentPush(data: Map<String, String>) {
        when (data["update_type"]) {
            "content_refresh" -> {
                // Fetch new content from your server
                refreshContentFeed(data["content_id"])
            }
            "segment_update" -> {
                // Push updated tags to Pushwoosh
                syncUserSegmentData()
            }
            "location_check" -> {
                // Evaluate current geofence status
                evaluateGeofences()
            }
        }
    }
}

payload של FCM ל-push שקט

ה-payload חייב להכיל אובייקט data ולא אובייקט notification:

{
    "to": "DEVICE_TOKEN",
    "data": {
        "update_type": "content_refresh",
        "content_id": "latest_news_feed"
    }
}

הגדר priority ל-‘high’ רק עבור משימות רקע רגישות לזמן. עדיפות רגילה מספיקה לרוב מקרי השימוש של רענון תוכן ומונעת השפעה מיותרת על חיי הסוללה.

push שקט חוצת-פלטפורמות עם Pushwoosh

ניהול push שקט ידני על פני iOS ו-Android פירושו תחזוקה של שני פורמטי payload נפרדים, שתי קבוצות של כותרות העברה, ושתי קבוצות של אינטגרציות SDK. Pushwoosh מפשטת את זה.

כשאתה מפעיל push שקט דרך Pushwoosh - דרך ה-UI או API - הפלטפורמה יוצרת את ה-payload הנכון עבור כל פלטפורמת יעד באופן אוטומטי. APNs מקבל content-available: 1 עם הכותרות הנכונות. FCM מקבל הודעת data בלבד. אתה מגדיר את הקמפיין פעם אחת.

ניהול אסימוני המכשיר מרוכז. אסימוני iOS, אסימוני Android, ומנויי web push כולם מאוחסנים ומעודכנים במקום אחד. כשאסימון משתנה (התקנה מחדש, שדרוג מערכת הפעלה), Pushwoosh מטפלת ברענון.

עבור חברי צוות שאינם טכניים, Pushwoosh מספקת ממשק משתמש לתזמון והפעלת push שקט ללא כתיבת payload. זה הופך את השילוב של push שקט בזרימות עבודה של Customer Journey Builder לצד התראות גלויות והודעות in-app לדבר מעשי.

מקרי שימוש אסטרטגיים

התראות push שקטות בעלות ערך רב ביותר כשנראות תפגע בך בפועל. הנה התרחישים שבהם הן מתאימות יותר מ-push רגיל.

טעינה מוקדמת של תוכן לאפליקציות חדשות ומדיה

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

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

הערכת geofence ללא טריגר גלוי

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

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

שמירה על דיוק נתוני הסגמנט לאחר פעילות מחוץ לאפליקציה

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

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

טעינה מוקדמת של תוכן להודעות in-app

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

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

שיטות עבודה מומלצות

כיבוד מגבלות ההגבלה של מערכת ההפעלה

iOS מגביל push שקט שמגיע בתדירות גבוהה מדי. ההנחיות של Apple הן בערך 2-3 לשעה, או בערך אחת כל 21 דקות לכל היותר. אפליקציות שחורגות מכך עשויות לגלות שה-push השקט שלהן מתעכב או נפל ללא שגיאה.

מצב Doze ו-App Standby של Android מגבילים ביצוע רקע כשהמכשיר במצב סרק. הודעות FCM עם עדיפות גבוהה יכולות להעיר את האפליקציה במהלך Doze, אך יש להשתמש בהן בזהירות. הודעות עדיפות רגילה נדחות עד שהמכשיר יוצא ממצב Doze.

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

שמירה על payload קטנים ומשימות מהירות

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

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

בדיקה על פני מצבי צריכה וגרסאות OEM שונות

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

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

מדידת יעילות דרך אירועים downstream

push שקט לא מייצר מדדי לחיצות. מדוד את יעילותו דרך האירועים שהוא אמור להפעיל: content_refreshed, segment_updated, geofence_evaluated. אם אירועים אלה מפסיקים להופיע בקצב הצפוי לאחר קמפיין push שקט, ההעברה מוגבלת או ה-handler של הרקע נכשל.

Pushwoosh Analytics מציג אירועי אפליקציה לצד נתוני קמפיין. מפה את אירועי השלמת משימת הרקע שלך לשליחות push שקט כדי לאשר שהצינור עובד.

שילוב באוטומציית המסע, לא בשליחות חד-פעמיות

push שקט שנשלח בנפרד הוא פעולה טכנית. push שקט משולב ב-Customer Journey הוא אסטרטגי. הדפוסים השימושיים ביותר משתמשים ב-push שקט כשלב שמאפשר אינטראקציה גלויה טובה יותר במורד הדרך: עדכן את הסגמנט לפני ה-push הפרסומי, אחזר מראש את התוכן לפני הודעת ה-in-app, הערך את ה-geofence לפני ההתראה מבוססת המיקום.

Customer Journey Builder של Pushwoosh תומך ב-push שקט כשלבי מסע לצד התראות גלויות והודעות in-app.

שיפור רעננות האפליקציה ודיוק הקמפיין עם Pushwoosh

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

Pushwoosh מטפלת בהעברת push שקט חוצת-פלטפורמות, עיצוב payload, ניהול אסימונים, ואינטגרציה עם Customer Journey. מפתחים מקבלים הפשטות SDK נקיות; צוותי שיווק מקבלים push שקט כשלב ראשי בזרימות עבודה אוטומטיות.