Silent push notification: หลักการทำงาน การตั้งค่า iOS และ Android และกรณีใช้งานเชิงกลยุทธ์

คู่มือ push notification ส่วนใหญ่จะพูดถึงข้อความที่ผู้ใช้มองเห็น แต่ silent push notification คือข้อความที่ผู้ใช้ไม่เคยเห็นเลย — และมันทำหน้าที่คนละแบบกันโดยสิ้นเชิงครับ

silent push จะปลุกแอปของคุณให้ทำงานเบื้องหลัง ทำงานตามที่สั่ง แล้วก็กลับไปพักต่อ — ไม่มีการแจ้งเตือน ไม่มีเสียง ไม่มี badge ผู้ใช้เปิดแอปมาก็พบเนื้อหาใหม่โหลดพร้อมอยู่แล้ว โดยไม่รู้เลยว่ามี push เกิดขึ้น นั่นแหละคือจุดประสงค์ของมัน

คู่มือนี้จะอธิบายว่า silent push notification ทำงานอย่างไรบน iOS และ Android หน้าตาของการ implement ในโค้ดเป็นแบบไหน และจะใช้มันเชิงกลยุทธ์ในการทำ customer journey automation ได้อย่างไร ระหว่างทางคุณจะได้เห็นว่า Pushwoosh จัดการการส่ง silent push ข้ามแพลตฟอร์มและรวมเข้ากับ workflow อัตโนมัติได้อย่างไร — สิ่งที่ทีมในไทยมักนำไปใช้คู่กับช่องทางอย่าง LINE Official Account เพื่อให้ทุกอย่างทำงานสอดประสานกัน

silent push notification คืออะไร?

silent push notification คือข้อความที่เซิร์ฟเวอร์ส่งมาเพื่อปลุกแอปให้ทำงานเบื้องหลัง โดยไม่แสดงอะไรให้ผู้ใช้เห็นเลย ไม่มีการแจ้งเตือน ไม่มีเสียง ไม่มี badge ระบบปฏิบัติการรับ push เข้ามา ปลุกแอปขึ้นมาทำงานสั้นๆ แอปทำงานเบื้องหลังเสร็จแล้วก็กลับไปพัก

ความต่างกับ push ทั่วไปนั้นเข้าใจง่ายมากครับ: push ที่มองเห็นคือ “ข้อความถึงผู้ใช้” ส่วน silent push คือ “คำสั่งถึงแอป”

แล้วในช่วงเวลาเบื้องหลังไม่กี่วินาทีนั้น แอปทำอะไรได้บ้าง?

• ดึงเนื้อหาใหม่ ดึงบทความล่าสุด แคตตาล็อกสินค้าที่อัปเดต หรือฟีดที่รีเฟรชใหม่ให้พร้อมตอนผู้ใช้เปิดแอป
• ซิงค์ข้อมูล อัปเดต state ในเครื่องด้วยการเปลี่ยนแปลงที่เกิดขึ้นบนเซิร์ฟเวอร์หรือผ่านช่องทางอื่น — เช่นการซื้อบนเว็บไซต์ หรือการเปลี่ยนสถานะในระบบหลังบ้าน
• ตรวจสอบตำแหน่ง เช็กว่าผู้ใช้เข้าหรือออกจาก geofence แล้วหรือยัง โดยไม่ต้องใช้การแจ้งเตือนที่มองเห็นเป็นตัวกระตุ้น
• อัปเดต tag หรือข้อมูล segment ของผู้ใช้ ส่งสัญญาณพฤติกรรมล่าสุดกลับไปยัง CDP เพื่อให้การ targeting แม่นยำเสมอ
• เตรียมโหลดเนื้อหาล่วงหน้าสำหรับการแจ้งเตือนที่จะแสดงในภายหลัง จัดเตรียม in-app message หรือ payload ของ rich push ให้แสดงผลทันทีเมื่อถูก trigger

คุณค่าในทางปฏิบัติคือ: ผู้ใช้เปิดแอปที่อัปเดตพร้อมอยู่แล้ว ไม่มีวงกลมหมุนรอโหลด ไม่มีข้อมูลเก่าค้าง ความรู้สึก “เร็วและสดใหม่” นี้มีผลต่อ retention อย่างวัดได้จริง แม้ผู้ใช้จะอธิบายไม่ได้ว่าทำไมแอปถึงใช้แล้วรู้สึกดี

silent push notification ทำงานอย่างไร

ห่วงโซ่การส่งเหมือนกับ push notification ทั่วไปครับ: เซิร์ฟเวอร์ของคุณส่ง payload ไปยัง APNs (iOS) หรือ FCM (Android) บริการนั้นส่งต่อไปยังอุปกรณ์ ระบบปฏิบัติการก็ดำเนินการตามนั้น สิ่งที่ต่างคือโครงสร้างของ payload และสิ่งที่ระบบปฏิบัติการทำเมื่อ payload มาถึง

ขั้นตอนการส่ง

1. เซิร์ฟเวอร์ส่ง payload ระบบหลังบ้านของคุณหรือ Pushwoosh ส่งข้อความที่จัดรูปแบบมาเป็นพิเศษไปยัง APNs หรือ FCM
2. บริการส่งต่อไปยังอุปกรณ์ APNs หรือ FCM ส่ง payload ไปยังอุปกรณ์ที่ถูกต้องโดยใช้ device token ที่เก็บไว้
3. ระบบปฏิบัติการปลุกแอป เมื่อตรวจพบ flag ของ silent push ใน payload ระบบปฏิบัติการจะปลุกแอปขึ้นมาทำงานเบื้องหลังสั้นๆ
4. แอปทำงานเบื้องหลัง โค้ดของคุณทำงาน: ดึงข้อมูล ซิงค์ state เช็กตำแหน่ง อัปเดต tag
5. แอปส่งสัญญาณว่าเสร็จแล้ว บน iOS แอปเรียก completion handler ส่วน Android onMessageReceived() คืนค่า ระบบปฏิบัติการก็พาแอปกลับไปพัก

ช่วงเวลาทำงานเบื้องหลังมีจำกัด iOS ให้เวลาประมาณ 30 วินาที ส่วน Android จะต่างกันไปตามอุปกรณ์และสถานะพลังงาน งานเบื้องหลังจึงต้องเร็วหรือออกแบบมาให้ทำงานได้ภายในข้อจำกัดเหล่านั้น

ความต่างของ payload: iOS เทียบกับ Android

ข้อผิดพลาดที่พบบ่อยที่สุดบน iOS คือลืมตั้ง apns-priority: 5 ควบคู่ไปกับ apns-push-type: background ถ้าตั้ง priority เป็น 10 (ค่าเริ่มต้นของ push ที่มองเห็น) Apple อาจปฏิเสธข้อความหรือแสดงผลให้เห็นแม้จะไม่มี alert body ก็ตาม การตั้ง priority ต่ำคือสิ่งที่บอก APNs ว่านี่เป็นงานเบื้องหลัง ไม่ใช่การแจ้งเตือนเร่งด่วน

บน Android กฎสำคัญง่ายกว่า: อย่ามี notification object ใน FCM payload ถ้ามี notification object อยู่ Android จะจัดการมันเป็น push notification ทั่วไปและแสดงผลทันที silent push = ใช้ data เท่านั้น

การ implement บน iOS

การตั้งค่า Xcode

เปิด Background Modes ใน Xcode ก่อนเขียนโค้ดใดๆ:

1. เปิดโปรเจกต์แล้วเลือก app target ของคุณ
2. ไปที่ ‘Signing & Capabilities’ แล้วคลิก ’+ Capability’
3. เพิ่ม ‘Background Modes’ แล้วติ๊ก ‘Remote Notifications’

App ID ของคุณบน Apple Developer Portal ต้องเปิด Push Notifications ไว้ด้วย อย่าลืมสร้าง provisioning profile ใหม่หลังจากเปลี่ยนแปลงนี้

การลงทะเบียนสำหรับ remote notification

silent 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 จัดการการส่ง token ให้อัตโนมัติ
    }
}

การจัดการ silent push

นี่คือ method ที่ iOS เรียกเมื่อ silent 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
        }

        // รันงานเบื้องหลังของคุณตรงนี้
        fetchLatestContent { success in
            completionHandler(success ? .newData : .noData)
        }
    }
}

เรียก completionHandler ให้ทันก่อนหน้าต่างเวลา 30 วินาทีจะปิดเสมอ ถ้าไม่ทำ iOS อาจปิดแอปและ throttle silent push ในอนาคต ส่ง .newData ถ้าดึงข้อมูลมาได้ ส่ง .noData ถ้าไม่มีอะไรเปลี่ยน และ .failed ถ้างานเกิดข้อผิดพลาด

APNs payload สำหรับ silent push

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

APNs headers ที่ต้องส่งควบคู่กับ payload นี้:

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

การ implement บน 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>

การจัดการ data message ใน Kotlin

extend FirebaseMessagingService แล้ว implement onMessageReceived:

class MyFirebaseMessagingService : FirebaseMessagingService() {

    override fun onNewToken(token: String) {
        // Pushwoosh Android SDK จัดการการส่ง token ให้อัตโนมัติ
    }

    override fun onMessageReceived(remoteMessage: RemoteMessage) {
        // silent push = มีแค่ 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" -> {
                // ส่ง tag ที่อัปเดตกลับไปยัง Pushwoosh
                syncUserSegmentData()
            }
            "location_check" -> {
                // ประเมินสถานะ geofence ปัจจุบัน
                evaluateGeofences()
            }
        }
    }
}

FCM payload สำหรับ silent push

payload ต้องมี data object และไม่มี notification object:

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

ตั้ง priority เป็น ‘high’ เฉพาะงานเบื้องหลังที่ต้องทำทันเวลาเท่านั้น สำหรับกรณีรีเฟรชเนื้อหาทั่วไป priority มาตรฐานก็เพียงพอและช่วยหลีกเลี่ยงการกินแบตเตอรี่โดยไม่จำเป็น

silent push ข้ามแพลตฟอร์มด้วย Pushwoosh

การจัดการ silent push ด้วยมือทั้งบน iOS และ Android หมายถึงต้องดูแล payload สองรูปแบบ headers การส่งสองชุด และการเชื่อม SDK สองชุด Pushwoosh ช่วยซ่อนความซับซ้อนนี้ให้

เมื่อคุณ trigger silent push ผ่าน Pushwoosh — ไม่ว่าผ่าน UI หรือ API — แพลตฟอร์มจะสร้าง payload ที่ถูกต้องสำหรับแต่ละแพลตฟอร์มเป้าหมายให้โดยอัตโนมัติ APNs ได้ content-available: 1 พร้อม headers ที่ถูกต้อง ส่วน FCM ได้ข้อความแบบ data-only คุณตั้งค่าแคมเปญแค่ครั้งเดียว

การจัดการ device token รวมศูนย์อยู่ที่เดียว ทั้ง iOS token, Android token และ web push subscription ถูกเก็บและอัปเดตในที่เดียวกัน เมื่อ token เปลี่ยน (ติดตั้งใหม่ หรืออัปเกรด OS) Pushwoosh จัดการรีเฟรชให้

สำหรับสมาชิกในทีมที่ไม่ใช่สายเทคนิค Pushwoosh มี UI สำหรับตั้งเวลาและ trigger silent push โดยไม่ต้องเขียน payload เอง ทำให้นำ silent push ไปรวมกับ workflow ใน Customer Journey Builder ควบคู่กับการแจ้งเตือนที่มองเห็นและ in-app message ได้จริง ซึ่งทีมการตลาดไทยมักใช้ออกแบบ journey ที่ต่อยอดไปยัง LINE ในจังหวะถัดไป

กรณีใช้งานเชิงกลยุทธ์

silent push notification มีค่ามากที่สุดเมื่อ “การแสดงผลให้เห็น” จะกลายเป็นผลเสียมากกว่าผลดี ต่อไปนี้คือสถานการณ์ที่ silent push เหมาะกว่า push ทั่วไป

ดึงเนื้อหาล่วงหน้าสำหรับแอปข่าวและสื่อ

แอปข่าวที่ส่งการแจ้งเตือนข่าวด่วนจะได้ประโยชน์จาก silent push ที่ส่งล่วงหน้า 30 วินาที silent push จะปลุกแอปให้ดึงบทความมา cache ไว้ในเครื่อง เมื่อการแจ้งเตือนที่มองเห็นยิงออกมา การแตะที่การแจ้งเตือนจะเปิดบทความได้ทันที ไม่ต้องรอเรื่องโหลด

สำหรับแอปที่มีฟีดแบบเฉพาะบุคคล silent push ในช่วงเวลาที่ผู้ใช้มักตื่นนอนจะดึงเนื้อหายามเช้ามาล่วงหน้าก่อนผู้ใช้จะเปิดแอป แอปจึงรู้สึกเร็ว เพราะมันเร็วจริง — ข้อมูลพร้อมอยู่แล้ว

ประเมิน geofence โดยไม่ต้องมี trigger ที่มองเห็น

ลองนึกถึงแอปท่องเที่ยวหรือแอปโรงแรมในไทย เมื่อนักท่องเที่ยวเดินเข้าใกล้สถานที่ท่องเที่ยวหรือบริเวณรีสอร์ท วิธีมาตรฐานคือส่ง push ตามตำแหน่ง แต่ปัญหาคือผู้ใช้ต้อง opt-in ไว้ จังหวะอาจไม่พอดี และอาจรู้สึกว่าถูกติดตาม

วิธีแบบ silent push คือ: เซิร์ฟเวอร์ส่ง silent push เมื่อผู้ใช้อยู่ในพื้นที่ที่กำหนด แอปเช็ก geofence แบบละเอียดฝั่ง client ถ้าตรงเงื่อนไข แอปจึงค่อยแสดง in-app message หรือ local notification ในจังหวะที่เหมาะ เช่น แนะนำคาเฟ่ใกล้เคียงหรือโปรโมชันร้านอาหารในรีสอร์ท การสื่อสารที่มองเห็นจะเกิดขึ้นต่อเมื่อ logic ผ่านเท่านั้น ไม่ใช่ใช้ตัวมันเองเป็น trigger

รักษาความแม่นยำของข้อมูล segment หลังกิจกรรมนอกแอป

ลองนึกถึงร้าน e-commerce ไทยที่ลูกค้าซื้อสินค้าบนเว็บไซต์ RFM segment ของเขาควรอัปเดตทันที แต่แอปไม่รู้จนกว่าผู้ใช้จะเปิดมัน

silent push ที่ส่งหลังการซื้อบนเว็บจะปลุกแอปให้ทำงานเบื้องหลัง ซิงค์ event การซื้อล่าสุดไปยัง Pushwoosh ผู้ใช้ย้ายเข้า RFM segment ที่ถูกต้องแบบเรียลไทม์ จากนั้นแคมเปญต่อเนื่อง — รางวัล loyalty, cross-sell, หรือลำดับข้อความขอบคุณ — จะยิงโดยอ้างอิงจากข้อมูลที่แม่นยำ และยังต่อยอดส่ง follow-up ผ่าน LINE Official Account ได้อย่างราบรื่นเพราะข้อมูล segment ตรงกัน

เตรียมโหลดเนื้อหาล่วงหน้าสำหรับ in-app message

in-app message ที่ต้องดึงข้อมูลจากเซิร์ฟเวอร์ก่อนแสดงผลอาจมีดีเลย์ที่สังเกตเห็นได้ silent push ที่ส่งก่อนเวลาที่คาดว่าผู้ใช้จะ trigger in-app message จะดึงเนื้อหามาเก็บไว้ในเครื่องล่วงหน้า เมื่อข้อความยิง มันจึงแสดงผลทันที

รูปแบบนี้ใช้ได้ดีกับ onboarding flow, การประกาศฟีเจอร์ใหม่ และ promotional overlay ที่เนื้อหาเป็นแบบเฉพาะบุคคลและ hardcode ลงในตัวแอปไม่ได้ ตัวอย่างเช่น แอปธนาคารที่ต้องการแสดงข้อเสนอสินเชื่อเฉพาะบุคคลตอนผู้ใช้เปิดแอป ก็โหลดเนื้อหานั้นล่วงหน้าไว้ได้

แนวปฏิบัติที่ดี

เคารพขีดจำกัดการ throttle ของ OS

iOS จะ throttle silent push ที่มาถึงถี่เกินไป คำแนะนำของ Apple อยู่ที่ประมาณ 2-3 ครั้งต่อชั่วโมง หรือราวทุก 21 นาทีเป็นอย่างมาก แอปที่ส่งเกินกว่านี้อาจพบว่า silent push ถูกหน่วงหรือถูกทิ้งไปโดยไม่มี error แจ้ง

Doze mode และ App Standby ของ Android จำกัดการทำงานเบื้องหลังเมื่ออุปกรณ์อยู่เฉย ข้อความ FCM แบบ high priority สามารถปลุกแอประหว่าง Doze ได้ แต่ควรใช้อย่างเลือกสรร ส่วนข้อความ priority มาตรฐานจะถูกเลื่อนจนกว่าอุปกรณ์จะออกจาก Doze

กฎในทางปฏิบัติคือ: ส่ง silent push เฉพาะเมื่องานเบื้องหลังต้องทำทันเวลาจริงๆ การดึงเนื้อหาล่วงหน้าในจังหวะธรรมชาติ (ตอนเช้า หรือหลังเซิร์ฟเวอร์อัปเดต) นั้นโอเค แต่การส่งทุก 10 นาทีเพื่อให้ข้อมูลสดนั้นไม่โอเค

ทำให้ payload เล็กและงานเสร็จไว

payload ของ silent push ควรเป็น “สัญญาณ” ไม่ใช่ “การถ่ายโอนข้อมูล” ส่งเท่าที่จำเป็นเพื่อบอกแอปว่าต้องดึงอะไรและจากที่ไหน ส่วนการดึงข้อมูลจริงเกิดขึ้นในแอปหลัง push มาถึง

งานเบื้องหลังควรเสร็จภายในขีดจำกัดเวลาอย่างสบายๆ ถ้างานต้องใช้เวลาเกินไม่กี่วินาที ให้ออกแบบให้ขัดจังหวะได้: บันทึกความคืบหน้า เรียก completion handler แล้วทำต่อในโอกาสถัดไป งานเบื้องหลังที่ยืดยาวเสี่ยงต่อการถูก OS ปิด และอาจกินแบตเตอรี่จนผู้ใช้สังเกตได้

ทดสอบในหลายสถานะพลังงานและรุ่น OEM ต่างๆ

พฤติกรรม silent push ต่างกันมากในแต่ละ OEM ของ Android ทั้ง Xiaomi, Huawei และ OnePlus ล้วนมีการ optimize แบตเตอรี่ที่ดุดัน ซึ่งอาจขัดขวางการทำงานเบื้องหลังทั้งหมดสำหรับแอปที่ไม่ได้อยู่ใน whitelist เรื่องนี้สำคัญเป็นพิเศษในไทย เพราะแบรนด์เหล่านี้ครองส่วนแบ่งตลาด Android สูง ควรทดสอบบนอุปกรณ์จริงจากผู้ผลิตเหล่านี้ ไม่ใช่แค่ stock Android emulator

บน iOS ให้ทดสอบใน low power mode และตอนที่แอปถูก force-quit การส่ง silent push ในสถานะเหล่านั้นเชื่อถือได้น้อยกว่า และ logic เบื้องหลังของคุณควรรองรับกรณีที่งานไม่ได้ทำงานก่อนผู้ใช้เปิดแอป

วัดประสิทธิภาพผ่าน event ปลายทาง

silent push ไม่สร้าง click metric วัดประสิทธิภาพของมันผ่าน event ที่มันควรจะ trigger แทน: content_refreshed, segment_updated, geofence_evaluated ถ้า event เหล่านี้หยุดยิงในอัตราที่คาดหวังหลังแคมเปญ silent push แสดงว่าการส่งถูก throttle หรือ handler เบื้องหลังกำลังล้มเหลว

Pushwoosh Analytics แสดง event ของแอปควบคู่กับข้อมูลแคมเปญ จับคู่ event ที่ทำงานเบื้องหลังเสร็จกับการส่ง silent push เพื่อยืนยันว่า pipeline ทำงานปกติ

รวมเข้ากับ journey automation ไม่ใช่ส่งครั้งเดียวจบ

silent push ที่ส่งแบบโดดๆ คือการทำงานเชิงเทคนิค แต่ silent push ที่ฝังอยู่ใน Customer Journey คือกลยุทธ์ รูปแบบที่มีประโยชน์ที่สุดคือใช้ silent push เป็นขั้นตอนที่ปูทางให้การโต้ตอบที่มองเห็นในจังหวะถัดไปดีขึ้น: อัปเดต segment ก่อนส่ง push โปรโมชัน, ดึงเนื้อหาล่วงหน้าก่อน in-app message, ประเมิน geofence ก่อนการแจ้งเตือนตามตำแหน่ง

Customer Journey Builder ของ Pushwoosh รองรับ silent push เป็นขั้นตอนใน journey ควบคู่กับการแจ้งเตือนที่มองเห็นและ in-app message

เพิ่มความสดใหม่ของแอปและความแม่นยำของแคมเปญด้วย Pushwoosh

silent push notification คือชั้น infrastructure ที่อยู่เบื้องหลังประสบการณ์ผู้ใช้ที่ดีกว่า เนื้อหาสดใหม่เมื่อเปิดแอป ข้อมูล segment ที่แม่นยำ การโต้ตอบที่ trigger ด้วย geofence อย่างลื่นไหล — ทั้งหมดนี้ทำงานได้เชื่อถือไม่ได้เลยหากไม่มีการอัปเดตแอปเบื้องหลัง

Pushwoosh จัดการการส่ง silent push ข้ามแพลตฟอร์ม การจัดรูปแบบ payload การจัดการ token และการรวมเข้ากับ Customer Journey นักพัฒนาได้ SDK ที่ซ่อนความซับซ้อนไว้อย่างสะอาด ส่วนทีมการตลาดได้ silent push เป็นขั้นตอนชั้นหนึ่งใน workflow อัตโนมัติ — และสำหรับทีมในไทย มันทำงานสอดประสานกับช่องทางที่ลูกค้าใช้ทุกวันอย่าง LINE ได้อย่างเป็นธรรมชาติครับ