সাইলেন্ট পুশ নোটিফিকেশন: কিভাবে কাজ করে, iOS ও Android সেটআপ এবং ব্যবহারের ক্ষেত্র

বেশিরভাগ পুশ নোটিফিকেশন গাইড সেই মেসেজগুলো নিয়ে কথা বলে যেগুলো ইউজার দেখতে পান। কিন্তু সাইলেন্ট পুশ নোটিফিকেশন হলো সেই মেসেজ যেগুলো ইউজার কখনোই দেখেন না — আর এদের কাজটাও সম্পূর্ণ আলাদা।

সহজ করে বলি: একটি সাইলেন্ট পুশ আপনার অ্যাপকে ব্যাকগ্রাউন্ডে (অর্থাৎ ইউজার অ্যাপটি খোলা না থাকা অবস্থায়) জাগিয়ে তোলে, একটি ছোট কাজ চালায়, তারপর আবার অ্যাপটিকে ঘুম পাড়িয়ে দেয়। কোনো অ্যালার্ট নেই, শব্দ নেই, ব্যাজ (অ্যাপ আইকনের উপরের লাল সংখ্যা) নেই। ইউজার যখন অ্যাপটি খোলেন, তখন তিনি দেখেন নতুন কন্টেন্ট আগে থেকেই লোড হয়ে আছে। তিনি জানেনই না যে একটি পুশ এসেছিল — আর এটাই এর আসল উদ্দেশ্য।

এই গাইডে আমরা সহজ ভাষায় দেখব সাইলেন্ট পুশ নোটিফিকেশন iOS ও Android-এ কিভাবে কাজ করে, কোডে এর ইমপ্লিমেন্টেশন কেমন দেখায়, এবং কাস্টমার জার্নি অটোমেশনের অংশ হিসেবে কিভাবে এটি কৌশলগতভাবে ব্যবহার করা যায়। সাথে সাথে দেখবেন Pushwoosh কিভাবে দুই প্ল্যাটফর্মেই সাইলেন্ট পুশ ডেলিভারি সামলায়।

সাইলেন্ট পুশ নোটিফিকেশন কি?

সাইলেন্ট পুশ নোটিফিকেশন হলো সার্ভার থেকে পাঠানো এমন মেসেজ যা ইউজারকে কিছু না দেখিয়েই অ্যাপটিকে ব্যাকগ্রাউন্ডে জাগিয়ে তোলে। কোনো অ্যালার্ট নেই, শব্দ নেই, ব্যাজ নেই। OS (অপারেটিং সিস্টেম, অর্থাৎ iOS বা Android) পুশটি গ্রহণ করে, অ্যাপটিকে অল্প সময়ের জন্য সক্রিয় করে, অ্যাপটি তার ব্যাকগ্রাউন্ড কাজ চালায়, তারপর আবার ঘুমিয়ে পড়ে।

সাধারণ পুশের সাথে পার্থক্যটা একদম সহজ: একটি দৃশ্যমান পুশ হলো ইউজারকে দেওয়া একটি মেসেজ; আর একটি সাইলেন্ট পুশ হলো অ্যাপকে দেওয়া একটি নির্দেশ।

ব্যাকগ্রাউন্ডের ওই কয়েক সেকেন্ডে অ্যাপ কী কী করতে পারে?

• নতুন কন্টেন্ট আনা (fetch)। সর্বশেষ আর্টিকেল, আপডেট হওয়া প্রোডাক্ট ক্যাটালগ, বা নতুন সোশ্যাল ফিড আগে থেকেই টেনে আনে, যাতে ইউজার অ্যাপ খুললেই তা প্রস্তুত থাকে।
• ডেটা সিঙ্ক করা। সার্ভারে বা অন্য চ্যানেলে ঘটে যাওয়া পরিবর্তন দিয়ে অ্যাপের ভেতরের তথ্য হালনাগাদ করা — যেমন ওয়েবসাইটে করা একটি কেনাকাটা, বা ব্যাকএন্ডে স্ট্যাটাসের পরিবর্তন।
• লোকেশন যাচাই করা। ইউজার কোনো নির্দিষ্ট এলাকায় (geofence — মানচিত্রে আঁকা একটি ভার্চুয়াল সীমানা) ঢুকেছেন কি বেরিয়েছেন, তা দৃশ্যমান নোটিফিকেশন ছাড়াই পরীক্ষা করা।
• ইউজার ট্যাগ বা সেগমেন্ট ডেটা আপডেট করা। সর্বশেষ আচরণগত তথ্য (behavioral signals) CDP-তে ফেরত পাঠায়, যাতে টার্গেটিং সঠিক থাকে।
• পরবর্তী দৃশ্যমান নোটিফিকেশনের জন্য কন্টেন্ট আগে থেকে প্রস্তুত রাখা। একটি in-app message বা rich push আগে থেকেই সাজিয়ে রাখে, যাতে ট্রিগার হওয়ামাত্র তা সাথে সাথে দেখায়।

বাস্তব সুবিধা কী? ইউজার এমন একটি অ্যাপ খোলেন যা ইতিমধ্যেই হালনাগাদ। কোনো লোডিং স্পিনার (ঘুরন্ত চাকা) নেই, পুরোনো ডেটা নেই। গতি ও তাজা কন্টেন্টের এই অনুভূতি রিটেনশনে (ইউজার ধরে রাখা) মাপযোগ্য প্রভাব ফেলে — এমনকি ইউজার নিজেও হয়তো বলতে পারবেন না কেন অ্যাপটি ব্যবহার করতে এত ভালো লাগছে।

সাইলেন্ট পুশ নোটিফিকেশন কিভাবে কাজ করে

ডেলিভারির পথটা সাধারণ পুশ নোটিফিকেশনের মতোই: আপনার সার্ভার একটি payload (অর্থাৎ পাঠানো ডেটার প্যাকেট) APNs (iOS-এর জন্য) বা FCM (Android-এর জন্য) সার্ভিসে পাঠায়, সার্ভিসটি তা ডিভাইসে পৌঁছে দেয়, OS সেই অনুযায়ী কাজ করে। পার্থক্য শুধু payload-এর গঠনে এবং OS সেটি পাওয়ার পর কী করে তাতে।

ছোট টীকা: APNs (Apple Push Notification service) হলো Apple-এর পুশ সিস্টেম, আর FCM (Firebase Cloud Messaging) হলো Google-এর। বাংলাদেশে বেশিরভাগ ইউজার Android ব্যবহার করেন, তাই আপনার বেশিরভাগ সাইলেন্ট পুশ যাবে FCM-এর মাধ্যমে — তবু iOS ইউজারদেরও সঠিকভাবে সামলানো জরুরি।

ডেলিভারির ধাপগুলো

1. সার্ভার payload পাঠায়। আপনার ব্যাকএন্ড বা Pushwoosh একটি বিশেষভাবে তৈরি মেসেজ APNs বা FCM-এ পাঠায়।
2. সার্ভিস ডিভাইসে পৌঁছে দেয়। সংরক্ষিত device token (প্রতিটি ডিভাইসের একটি অনন্য পরিচয়) ব্যবহার করে APNs বা FCM সঠিক ডিভাইসে payload পাঠায়।
3. OS অ্যাপ জাগিয়ে তোলে। payload-এ থাকা সাইলেন্ট পুশের চিহ্নগুলো চিনে নিয়ে OS অল্প সময়ের জন্য অ্যাপটিকে ব্যাকগ্রাউন্ডে সক্রিয় করে।
4. অ্যাপ ব্যাকগ্রাউন্ড কাজ চালায়। আপনার কোড চলে: ডেটা আনা, স্টেট সিঙ্ক করা, লোকেশন যাচাই করা, ট্যাগ আপডেট করা।
5. অ্যাপ কাজ শেষ হওয়ার সংকেত দেয়। iOS-এ অ্যাপ একটি completion handler কল করে। Android-এ onMessageReceived() রিটার্ন করে। এরপর OS অ্যাপটিকে আবার ঘুম পাড়িয়ে দেয়।

মনে রাখবেন, ব্যাকগ্রাউন্ডে কাজ করার সময় সীমিত। iOS দেয় প্রায় ৩০ সেকেন্ড। Android-এ এটা ডিভাইস ও ব্যাটারির অবস্থাভেদে বদলায়। তাই ব্যাকগ্রাউন্ড কাজ অবশ্যই দ্রুত হতে হবে, অথবা এই সীমার মধ্যে কাজ করার মতো করে ডিজাইন করতে হবে।

payload-এর পার্থক্য: iOS বনাম Android

iOS-এ সবচেয়ে সাধারণ ভুলটি হলো apns-push-type: background দেওয়ার পাশাপাশি apns-priority: 5 সেট করতে ভুলে যাওয়া। যদি priority 10 থাকে (যা দৃশ্যমান পুশের ডিফল্ট), তাহলে Apple মেসেজটি বাতিল করতে পারে, অথবা অ্যালার্ট না থাকলেও সেটি দৃশ্যমান করে ফেলতে পারে। এই কম priority-ই APNs-কে বলে দেয় যে এটি একটি ব্যাকগ্রাউন্ড কাজ, জরুরি নোটিফিকেশন নয়।

Android-এ নিয়মটি আরও সহজ: FCM payload-এ কোনো notification object রাখবেন না। যদি notification object থাকে, Android সেটিকে সাধারণ পুশ নোটিফিকেশন ধরে নিয়ে দেখিয়ে ফেলবে। সাইলেন্ট পুশ মানে শুধু data — আর কিছু নয়।

Android ইমপ্লিমেন্টেশন

বাংলাদেশ ও পশ্চিমবঙ্গে Android-এর ব্যবহার সবচেয়ে বেশি, তাই আমরা Android দিয়েই শুরু করছি। আপনার অ্যাপের বেশিরভাগ ইউজার সম্ভবত Android-এ — তাই এই অংশটি মন দিয়ে পড়ুন।

FCM সেটআপ ও manifest

আপনার AndroidManifest.xml-এ FirebaseMessagingService যোগ করুন:

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

Kotlin-এ data মেসেজ হ্যান্ডল করা

FirebaseMessagingService extend করুন এবং onMessageReceived ইমপ্লিমেন্ট করুন:

class MyFirebaseMessagingService : FirebaseMessagingService() {

    override fun onNewToken(token: String) {
        // Pushwoosh Android SDK স্বয়ংক্রিয়ভাবে token সাবমিট করে
    }

    override fun onMessageReceived(remoteMessage: RemoteMessage) {
        // সাইলেন্ট পুশ = শুধু data payload, কোনো 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" -> {
                // আপনার সার্ভার থেকে নতুন কন্টেন্ট আনুন
                refreshContentFeed(data["content_id"])
            }
            "segment_update" -> {
                // আপডেট হওয়া ট্যাগ Pushwoosh-এ পাঠান
                syncUserSegmentData()
            }
            "location_check" -> {
                // বর্তমান geofence অবস্থা যাচাই করুন
                evaluateGeofences()
            }
        }
    }
}

সাইলেন্ট পুশের জন্য FCM payload

payload-এ অবশ্যই একটি data object থাকতে হবে এবং কোনো notification object থাকা যাবে না:

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

priority শুধু সময়-সংবেদনশীল ব্যাকগ্রাউন্ড কাজের জন্য ‘high’ করুন। বেশিরভাগ কন্টেন্ট রিফ্রেশের ক্ষেত্রে স্ট্যান্ডার্ড priority-ই যথেষ্ট, আর এতে অযথা ব্যাটারি খরচও এড়ানো যায় — উদীয়মান বাজারে যেখানে অনেক ইউজার বাজেট ফোন ব্যবহার করেন, এই ব্যাটারি বিবেচনা বিশেষভাবে গুরুত্বপূর্ণ।

iOS ইমপ্লিমেন্টেশন

বাংলাদেশে iOS-এর অংশ কম হলেও প্রিমিয়াম সেগমেন্ট ও আন্তর্জাতিক ইউজারদের জন্য এটি গুরুত্বপূর্ণ। cross-platform অ্যাপে iOS সঠিকভাবে সামলানো দরকার।

Xcode কনফিগারেশন

কোড লেখার আগে Xcode-এ Background Modes চালু করুন:

1. আপনার প্রজেক্ট খুলুন এবং app target নির্বাচন করুন।
2. ‘Signing & Capabilities’-এ যান এবং ’+ Capability’-তে ক্লিক করুন।
3. ‘Background Modes’ যোগ করুন এবং ‘Remote Notifications’ টিক দিন।

Apple Developer Portal-এ আপনার App ID-তে Push Notifications চালু থাকতে হবে। এই পরিবর্তনের পর আপনার provisioning profile আবার তৈরি (regenerate) করুন।

remote notification-এর জন্য রেজিস্টার করা

সাইলেন্ট পুশেও 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 স্বয়ংক্রিয়ভাবে token সাবমিট করে
    }
}

সাইলেন্ট পুশ হ্যান্ডল করা

সাইলেন্ট পুশ এলে iOS এই মেথডটি কল করে:

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
        }

        // এখানে আপনার ব্যাকগ্রাউন্ড কাজ চালান
        fetchLatestContent { success in
            completionHandler(success ? .newData : .noData)
        }
    }
}

৩০ সেকেন্ডের সময়সীমা শেষ হওয়ার আগেই সবসময় completionHandler কল করুন। না করলে iOS অ্যাপটি বন্ধ করে দিতে পারে এবং ভবিষ্যতের সাইলেন্ট পুশ থ্রটল করতে পারে। কিছু এনে থাকলে .newData পাঠান, কিছু না বদলালে .noData, আর কাজে ভুল হলে .failed।

সাইলেন্ট পুশের জন্য APNs payload

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

এই payload-এর সাথে প্রয়োজনীয় APNs হেডার:

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

Pushwoosh দিয়ে cross-platform সাইলেন্ট পুশ

iOS ও Android-এ আলাদাভাবে সাইলেন্ট পুশ সামলানো মানে দুটি ভিন্ন payload ফরম্যাট, দুই সেট ডেলিভারি হেডার, আর দুই সেট SDK ইন্টিগ্রেশন রক্ষণাবেক্ষণ করা। ছোট টিমের জন্য — বিশেষত উদীয়মান বাজারের স্টার্টআপে যেখানে ডেভেলপার সংখ্যা সীমিত — এটা বড় বোঝা। Pushwoosh এই জটিলতা আড়াল করে দেয়।

যখন আপনি Pushwoosh-এর মাধ্যমে একটি সাইলেন্ট পুশ ট্রিগার করেন — UI বা API দিয়ে — প্ল্যাটফর্মটি স্বয়ংক্রিয়ভাবে প্রতিটি প্ল্যাটফর্মের জন্য সঠিক payload তৈরি করে। APNs পায় সঠিক হেডারসহ content-available: 1। FCM পায় শুধু data মেসেজ। আপনি ক্যাম্পেইনটি একবারই কনফিগার করেন।

device token ম্যানেজমেন্ট একটি জায়গায় কেন্দ্রীভূত। iOS token, Android token ও web push subscription — সবই এক জায়গায় সংরক্ষিত ও হালনাগাদ হয়। যখন কোনো token বদলায় (অ্যাপ পুনরায় ইনস্টল, OS আপগ্রেড), Pushwoosh নিজেই তা রিফ্রেশ করে নেয়।

যেসব টিম-সদস্য টেকনিক্যাল নন, তাঁদের জন্য Pushwoosh একটি UI দেয় যেখানে কোনো payload না লিখেই সাইলেন্ট পুশ শিডিউল ও ট্রিগার করা যায়। এর ফলে সাইলেন্ট পুশকে Customer Journey Builder ফ্লোতে দৃশ্যমান নোটিফিকেশন ও in-app message-এর পাশাপাশি যুক্ত করা সহজ হয়ে যায়।

কৌশলগত ব্যবহারের ক্ষেত্র

সাইলেন্ট পুশ নোটিফিকেশন তখনই সবচেয়ে মূল্যবান যখন কোনো কিছু দৃশ্যমান করাটা আসলে ক্ষতির কারণ হতে পারত। নিচে এমন কিছু পরিস্থিতি দেওয়া হলো যেখানে সাধারণ পুশের চেয়ে সাইলেন্ট পুশ বেশি উপযুক্ত — সাথে বাংলাদেশের বাজারের পরিচিত উদাহরণ।

RFM মানে কি? RFM হলো Recency (কত সম্প্রতি কিনেছেন), Frequency (কত ঘন ঘন কেনেন) ও Monetary (কত টাকা খরচ করেন) — এই তিনটি দিয়ে গ্রাহকদের ভাগ করার একটি সহজ পদ্ধতি। যেমন একজন নিয়মিত ক্রেতা ও একজন অনেক দিন পর আসা ক্রেতাকে আলাদা মেসেজ পাঠানো।

নিউজ ও মিডিয়া অ্যাপে কন্টেন্ট pre-fetch

ধরুন একটি বাংলা নিউজ অ্যাপ একটি ব্রেকিং নিউজ অ্যালার্ট পাঠাবে। অ্যালার্টটি পাঠানোর ৩০ সেকেন্ড আগে একটি সাইলেন্ট পুশ পাঠালে সুবিধা হয়। সাইলেন্ট পুশটি অ্যাপ জাগিয়ে তোলে, অ্যাপটি আর্টিকেলটি এনে ডিভাইসে জমা (cache) করে রাখে। তারপর যখন দৃশ্যমান অ্যালার্টটি আসে, ইউজার সেটিতে ট্যাপ করামাত্র আর্টিকেলটি সাথে সাথে খুলে যায়। খবরটি লোড হওয়ার জন্য অপেক্ষা করতে হয় না — মোবাইল ডেটা ধীর হলে এই পার্থক্যটা ইউজার স্পষ্ট টের পান।

পার্সোনালাইজড ফিডওয়ালা অ্যাপের ক্ষেত্রে, সাধারণ ঘুম থেকে ওঠার সময়ে একটি সাইলেন্ট পুশ পাঠিয়ে সকালের কন্টেন্ট আগেই এনে রাখা যায়। অ্যাপটি দ্রুত মনে হয়, কারণ এটি সত্যিই দ্রুত — ডেটা আগে থেকেই সেখানে আছে।

দৃশ্যমান ট্রিগার ছাড়াই geofence যাচাই

ধরুন একজন ইউজার Daraz বা চালডাল ধরনের একটি অ্যাপের কোনো পিকআপ পয়েন্টের কাছ দিয়ে হাঁটছেন। সাধারণ পদ্ধতি: একটি লোকেশন-ভিত্তিক পুশ পাঠানো। সমস্যা: ইউজারকে opt-in করা থাকতে হয়, সময়টা ঠিক নাও হতে পারে, আর ইউজারের মনে হতে পারে তাঁকে নজরে রাখা হচ্ছে।

সাইলেন্ট পুশ পদ্ধতি: ইউজার একটি এলাকার মধ্যে এলে সার্ভার একটি সাইলেন্ট পুশ পাঠায়। অ্যাপ ডিভাইসেই (client-side) সুনির্দিষ্ট geofence যাচাই করে। শর্ত মিললে তবেই অ্যাপ সঠিক মুহূর্তে একটি in-app message বা local notification দেখায়। অর্থাৎ দৃশ্যমান যোগাযোগ তখনই হয় যখন লজিক পাস করে — যোগাযোগটাই ট্রিগার নয়।

অ্যাপের বাইরের কার্যকলাপের পর সেগমেন্ট ডেটা সঠিক রাখা

ধরুন একজন ইউজার আপনার ওয়েবসাইটে একটি কেনাকাটা করলেন। তাঁর RFM সেগমেন্ট সাথে সাথে আপডেট হওয়া উচিত। কিন্তু অ্যাপটি এ ব্যাপারে কিছুই জানে না যতক্ষণ না ইউজার অ্যাপটি খোলেন।

ওয়েবে কেনাকাটার পর একটি সাইলেন্ট পুশ পাঠালে সেটি অ্যাপটিকে ব্যাকগ্রাউন্ডে জাগিয়ে তোলে, আর অ্যাপটি সর্বশেষ কেনাকাটার ইভেন্ট Pushwoosh-এ সিঙ্ক করে নেয়। ইউজার রিয়েল-টাইমে সঠিক RFM সেগমেন্টে চলে যান। এরপর একটি ফলো-আপ ক্যাম্পেইন — লয়্যালটি রিওয়ার্ড, ক্রস-সেল, বা ধন্যবাদ সিকোয়েন্স — সঠিক ডেটার ভিত্তিতে ট্রিগার হয়।

in-app message-এর জন্য কন্টেন্ট আগে থেকে লোড করা

যেসব in-app message দেখাতে সার্ভার থেকে ডেটা আনতে হয়, সেগুলোতে লক্ষণীয় বিলম্ব হতে পারে। ইউজার যখন in-app message ট্রিগার করবেন বলে আশা করা হচ্ছে, তার আগে একটি সাইলেন্ট পুশ পাঠিয়ে কন্টেন্টটি এনে ডিভাইসে জমা রাখা যায়। তখন মেসেজটি ট্রিগার হলে সাথে সাথে দেখায়।

এই কৌশলটি বিশেষভাবে ভালো কাজ করে onboarding ফ্লো, নতুন ফিচারের ঘোষণা, এবং প্রমোশনাল ওভারলে-তে — যেখানে কন্টেন্ট পার্সোনালাইজড হয় এবং অ্যাপের ভেতরে আগে থেকে লিখে রাখা যায় না।

সেরা অনুশীলন (best practices)

OS-এর থ্রটলিং সীমা মেনে চলুন

iOS খুব ঘন ঘন আসা সাইলেন্ট পুশ থ্রটল করে (গতি কমিয়ে দেয়)। Apple-এর নির্দেশনা মোটামুটি ঘণ্টায় ২-৩ বার, অর্থাৎ সর্বোচ্চ প্রতি ২১ মিনিটে একটি। এর বেশি পাঠালে আপনার সাইলেন্ট পুশ কোনো এরর ছাড়াই দেরিতে আসতে পারে বা একেবারেই বাদ পড়তে পারে।

Android-এর Doze mode ও App Standby ডিভাইস নিষ্ক্রিয় থাকলে ব্যাকগ্রাউন্ড কাজ সীমিত করে দেয়। high-priority FCM মেসেজ Doze-এর মধ্যেও অ্যাপ জাগাতে পারে, তবে এটি সংযতভাবে ব্যবহার করা উচিত। স্ট্যান্ডার্ড priority-র মেসেজ ডিভাইস Doze থেকে বের হওয়া পর্যন্ত অপেক্ষায় থাকে।

বাস্তব নিয়ম: সাইলেন্ট পুশ তখনই পাঠান যখন ব্যাকগ্রাউন্ড কাজটি সত্যিই সময়-সংবেদনশীল। স্বাভাবিক ছন্দে একবার কন্টেন্ট আগে আনা (যেমন সকালে, বা সার্ভারে আপডেট হওয়ার পর) ঠিক আছে। কিন্তু ডেটা তাজা রাখতে প্রতি ১০ মিনিটে পাঠানো একদমই ঠিক নয়।

payload ছোট ও কাজ দ্রুত রাখুন

সাইলেন্ট পুশের payload একটি সংকেত হওয়া উচিত, ডেটা স্থানান্তরের মাধ্যম নয়। অ্যাপকে শুধু এটুকু বলার মতো ন্যূনতম তথ্য পাঠান যে কী আনতে হবে আর কোথা থেকে। আসল ডেটা আনার কাজটি পুশ পৌঁছানোর পর অ্যাপের ভেতরেই হয়।

ব্যাকগ্রাউন্ড কাজ সময়সীমার ভালোভাবে মধ্যেই শেষ হওয়া উচিত। কোনো কাজে কয়েক সেকেন্ডের বেশি লাগলে সেটিকে থামানো-যায় (interruptible) এমন করে ডিজাইন করুন: অগ্রগতি সেভ করুন, completion handler কল করুন, এবং পরের সুযোগে আবার শুরু করুন। দীর্ঘ ব্যাকগ্রাউন্ড কাজে OS অ্যাপ বন্ধ করে দেওয়ার ঝুঁকি থাকে এবং ব্যাটারিতে এতটাই প্রভাব ফেলতে পারে যে ইউজার টের পান।

বিভিন্ন পাওয়ার স্টেট ও OEM ভ্যারিয়েন্টে টেস্ট করুন

সাইলেন্ট পুশের আচরণ বিভিন্ন Android OEM (ফোন নির্মাতা) ভেদে অনেক বদলায় — আর এটি বাংলাদেশের জন্য বিশেষভাবে গুরুত্বপূর্ণ, কারণ এখানে Xiaomi, realme, Oppo ও Vivo খুবই জনপ্রিয়। এসব নির্মাতার আক্রমণাত্মক ব্যাটারি অপটিমাইজেশন অ্যাপটি whitelist না থাকলে ব্যাকগ্রাউন্ড কাজ একেবারে বন্ধ করে দিতে পারে। তাই শুধু স্টক Android emulator নয়, এসব নির্মাতার আসল ডিভাইসে টেস্ট করুন।

iOS-এ low power mode-এ এবং অ্যাপ force-quit করা অবস্থায় টেস্ট করুন। ওই অবস্থায় সাইলেন্ট পুশ ডেলিভারি কম নির্ভরযোগ্য, তাই আপনার ব্যাকগ্রাউন্ড লজিক এমন হওয়া উচিত যাতে কাজটি না চললেও ইউজার অ্যাপ খোলার সময় সমস্যা না হয়।

পরবর্তী ইভেন্ট দিয়ে কার্যকারিতা মাপুন

সাইলেন্ট পুশ কোনো click metric তৈরি করে না (কারণ দেখানোরই কিছু নেই)। এর কার্যকারিতা মাপুন সেই ইভেন্টগুলো দিয়ে যেগুলো এটি ট্রিগার করার কথা: content_refreshed, segment_updated, geofence_evaluated। সাইলেন্ট পুশ ক্যাম্পেইনের পর যদি এই ইভেন্টগুলো প্রত্যাশিত হারে আসা বন্ধ করে দেয়, তাহলে বুঝবেন ডেলিভারি থ্রটল হচ্ছে অথবা ব্যাকগ্রাউন্ড হ্যান্ডলার ব্যর্থ হচ্ছে।

Pushwoosh Analytics অ্যাপ ইভেন্ট ও ক্যাম্পেইন ডেটা একসাথে দেখায়। পাইপলাইন ঠিকঠাক কাজ করছে কিনা নিশ্চিত হতে আপনার ব্যাকগ্রাউন্ড কাজ শেষ হওয়ার ইভেন্টগুলোকে সাইলেন্ট পুশ পাঠানোর সাথে মিলিয়ে দেখুন।

একক পাঠানো নয়, জার্নি অটোমেশনে যুক্ত করুন

একা পাঠানো একটি সাইলেন্ট পুশ নিছক একটি টেকনিক্যাল কাজ। কিন্তু একটি Customer Journey-তে বসানো সাইলেন্ট পুশ একটি কৌশলগত কাজ। সবচেয়ে কাজের প্যাটার্নগুলো সাইলেন্ট পুশকে এমন একটি ধাপ হিসেবে ব্যবহার করে যা পরে একটি ভালো দৃশ্যমান অভিজ্ঞতা সম্ভব করে: প্রমোশনাল পুশের আগে সেগমেন্ট আপডেট করা, in-app message-এর আগে কন্টেন্ট আগে আনা, লোকেশন-ভিত্তিক অ্যালার্টের আগে geofence যাচাই করা।

Pushwoosh-এর Customer Journey Builder দৃশ্যমান নোটিফিকেশন ও in-app message-এর পাশাপাশি সাইলেন্ট পুশকেও জার্নির ধাপ হিসেবে সমর্থন করে।

Pushwoosh দিয়ে অ্যাপের তাজাভাব ও ক্যাম্পেইন নির্ভুলতা বাড়ান

সাইলেন্ট পুশ নোটিফিকেশন হলো ভালো ইউজার অভিজ্ঞতার নিচের ভিত্তি-স্তর। অ্যাপ খুললেই তাজা কন্টেন্ট, সঠিক সেগমেন্ট ডেটা, ঝামেলাহীন geofence-ভিত্তিক ইন্টারঅ্যাকশন — এর কোনোটিই ব্যাকগ্রাউন্ড আপডেট ছাড়া নির্ভরযোগ্যভাবে কাজ করে না।

Pushwoosh দুই প্ল্যাটফর্মেই সাইলেন্ট পুশ ডেলিভারি, payload ফরম্যাটিং, token ম্যানেজমেন্ট ও Customer Journey ইন্টিগ্রেশন সামলায়। ডেভেলপাররা পান পরিষ্কার SDK অ্যাবস্ট্রাকশন; মার্কেটিং টিম পায় সাইলেন্ট পুশকে অটোমেটেড ফ্লোর একটি পূর্ণাঙ্গ ধাপ হিসেবে। আর Pushwoosh SOC 2 Type I ও ISO 27001:2022 প্রত্যয়িত এবং GDPR সম্মত হওয়ায় আপনার গ্রাহক ডেটা আন্তর্জাতিক মানে সুরক্ষিত থাকে।