Apple และ Google กำลังทำอะไรกับการแจ้งเตือนแบบพุช
(jacquescorbytuech.com)- การแจ้งเตือนแบบพุช กำลังเปลี่ยนจากชั้นการส่งต่อแบบเรียบง่าย ไปเป็นช่องทางบรรณาธิการของแพลตฟอร์มที่ Apple และ Google เข้ามาแยกวิเคราะห์ จัดอันดับ สรุป และเขียนใหม่
- APNs และ FCM เริ่มต้นจากโครงสร้างตัวกลางแบบศูนย์กลางเพื่อประหยัดแบตเตอรี่ และการแจ้งเตือนทั้งหมดบน iPhone และ Android ก็ผ่าน เซิร์ฟเวอร์ของแพลตฟอร์ม มาตั้งแต่แรก
- Android channels, Focus·Summary ของ iOS และการเปลี่ยนสิทธิ์ใน Android 13 ได้ลดอำนาจควบคุมของผู้ส่ง และทำให้แพลตฟอร์มเป็นฝ่ายปกป้อง ความสนใจของผู้ใช้
- โมเดลบนอุปกรณ์จะสรุป จัดกลุ่ม และลดระดับการแจ้งเตือนในชั้นการแสดงผล แต่ผู้ส่งแทบไม่มี API สำหรับตรวจจับได้เลยว่าถูกสรุป ถูก Focus กดไว้ หรือถูกลดลำดับความสำคัญหรือไม่
- ในทางปฏิบัติ ควรจำกัดพุชไว้กับการปลุกผู้ใช้ที่ไม่ค่อยใช้งานและการแจ้งเตือนเชิงธุรกรรมที่ไวต่อเวลา พร้อมย้ายน้ำหนักไปยัง การแบ่งกลุ่มย่อย·การปรับให้เหมาะกับแต่ละบุคคล และพื้นที่ที่เป็นเจ้าของเอง เช่น in-app
กระแสที่การแจ้งเตือนแบบพุชกำลังกลายเป็นช่องทางบรรณาธิการของแพลตฟอร์ม
- การแจ้งเตือนแบบพุช กำลังเคลื่อนจากการเป็นชั้นการส่งต่อแบบเรียบง่ายเหมือนอีเมล ไปสู่ช่องทางที่ Apple และ Google เข้ามาแทรกกลางเพื่อแยกวิเคราะห์ จัดอันดับ สรุป และเขียนใหม่
- Apple และ Google เป็นผู้ดำเนินเส้นทางพุชหลักของ iPhone และ Android และในช่วง 5 ปีที่ผ่านมา โมเดลในอุปกรณ์ได้เข้ามาอยู่ระหว่างการส่งกับหน้าจอล็อก เพื่อสรุปและจัดเรียงการแจ้งเตือนใหม่ และในบางหน้าจอก็เขียนใหม่อีกครั้ง
- ในอีเมล ผู้ให้บริการ 4 รายคือ Google, Yahoo, Microsoft และ Apple ได้กลายเป็นตัวกลางเชิงรุกระหว่างแบรนด์กับลูกค้า แต่ในพุช โครงสร้างนี้เหลือผู้เล่น 2 รายคือ Apple และ Google ที่ทำหน้าที่เดียวกัน
สถาปัตยกรรมพุชที่เริ่มต้นจากปัญหาแบตเตอรี่
- พุชถูกออกแบบเป็นโครงสร้างตัวกลางแบบศูนย์กลางตั้งแต่ต้นเพราะ ปัญหาแบตเตอรี่
- ในงาน WWDC ปี 2009 Scott Forstall อธิบายว่า หากทุกแอปที่ติดตั้งไว้ต่างคอย polling เซิร์ฟเวอร์ระยะไกลของตัวเองอยู่เบื้องหลัง iPhone จะรับภาระไม่ไหว และ Apple จึงเสนอ Apple Push Notification Service ที่ให้อุปกรณ์แต่ละเครื่องคงการเชื่อมต่อ TLS แบบต่อเนื่องเพียงเส้นเดียวกับ Apple แล้วให้บุคคลที่สามส่งการแจ้งเตือนผ่านการเชื่อมต่อนั้น
- APNs ถูกประกาศครั้งแรกในเดือนกันยายน 2008 แต่ล่าช้าเพราะปัญหาด้านการขยายระบบ ก่อนจะเปิดตัวพร้อม iPhone OS 3 ในวันที่ 17 มิถุนายน 2009
- Google เลือกเส้นทางที่ต่อเนื่องจาก Cloud to Device Messaging ในปี 2010, Google Cloud Messaging ในปี 2012 และ Firebase Cloud Messaging ในปี 2016
- การแจ้งเตือนทั้งหมดที่ส่งไปยัง iPhone จะผ่านเซิร์ฟเวอร์ของ Apple และการแจ้งเตือนทั้งหมดที่ส่งไปยัง Android จะผ่านเซิร์ฟเวอร์ของ Google
- แพลตฟอร์มมีอำนาจที่จะจำกัด ลบ บันทึก ปฏิบัติด้วยลำดับความสำคัญต่ำ หรือปฏิเสธการแจ้งเตือนได้เสมอ และสิ่งที่เปลี่ยนไปคือ Apple กับ Google ไม่ได้ยับยั้งตัวเองมากเหมือนในอดีตอีกแล้ว
การแทรกแซงของแพลตฟอร์มที่เพิ่มขึ้นตลอด 15 ปี
- ในยุคแรกของการแจ้งเตือนพุชสำหรับผู้บริโภค APNs และบริการของ Google ทำหน้าที่ส่งการแจ้งเตือนไปยังแอปที่ผู้ใช้ติดตั้งไว้ และการกรองในระดับแพลตฟอร์มยังมีจำกัด
- การควบคุมของผู้ใช้เองก็แทบจะเป็นเพียงสวิตช์เปิด/ปิดต่อแอปเท่านั้น
- การแทรกแซงสำคัญครั้งแรกบนอุปกรณ์ของ Android คือ notification channels ใน Android 8 Oreo เมื่อเดือนสิงหาคม 2017
- ก่อน Android 8 การแจ้งเตือนแต่ละรายการมีลำดับความสำคัญที่ผู้ส่งกำหนด แต่หลังจากนั้นนักพัฒนาต้องกำหนดเป็นระดับ channel และผู้ใช้ควบคุมเป็นระดับ channel
- นักพัฒนาต้องประกาศ channel ต่อแอป เช่น ดาวน์โหลด ข้อความ หรือโปรโมชัน และกำหนดระดับความสำคัญให้แต่ละ channel ตั้งแต่
IMPORTANCE_NONEถึงIMPORTANCE_HIGH - ผู้ใช้สามารถตั้งค่าปิดเสียง ลดความสำคัญ ปิด badge หรือบล็อกทั้งหมดราย channel ได้โดยไม่กระทบ channel อื่น
- เมื่อนักพัฒนาตั้งระดับความสำคัญของ channel แล้ว จะไม่สามารถเพิ่มกลับขึ้นภายหลังได้ และแอปที่รองรับ Android 8 หากไม่ประกาศ channel การแจ้งเตือนจะไม่แสดงผล
- Apple เปิดตัว Focus, Scheduled Summary และ interruption taxonomy 4 ระดับใน iOS 15 เมื่อเดือนกันยายน 2021
- ทั้ง 4 ระดับคือ passive, active, time-sensitive และ critical โดยในทางปฏิบัติระดับที่นักพัฒนานำไปใช้ได้จริงคือ time-sensitive
- Apple ระบุชัดว่าไม่ควรใช้ time-sensitive กับงานการตลาด และนโยบายนี้ก็ยังคงอยู่
- Android เปลี่ยน
POST_NOTIFICATIONSให้เป็นสิทธิ์แบบ runtime ใน Android 13 เมื่อเดือนสิงหาคม 2022 ทำให้ต้องได้รับการอนุญาตอย่างชัดเจนจากผู้ใช้แทนการ opt-in แบบโดยนัย- จาก ตัวอย่างอุปกรณ์ 16 ล้านเครื่องของ Pushwoosh แอปเกมสูญเสียฐานที่ยอม opt-in ไปเกือบหนึ่งในสาม และแอปข่าวลดลง 19%
- เกณฑ์อ้างอิงปี 2025 ของ Batch ซึ่งอ้างอิงจากข้อความมากกว่า 8 แสนล้านรายการใน 10,000 แอป ระบุว่าอัตรา opt-in บน Android ลดจาก 85% เหลือ 67% ภายในหนึ่งปี และค่าเฉลี่ยข้ามแพลตฟอร์มอยู่ที่ 61%
- ทุกขั้นตอนเหล่านี้ได้ลดอำนาจควบคุมของผู้ส่งลง และสร้างช่องทางพุชขึ้นใหม่ในทิศทางที่มองว่าความสนใจของผู้รับเป็นทรัพยากรหายากที่แพลตฟอร์มต้องปกป้อง
- พื้นที่การแจ้งเตือนที่สะอาดและทำให้ผู้ใช้ล้าน้อย ช่วยปกป้องอัตราการคงอยู่ของผู้ใช้และระบบนิเวศของแพลตฟอร์ม ลดการลบแอป และเป็นวิธีโชว์ความสามารถ AI ดังนั้นการทำหน้าที่บรรณาธิการของแพลตฟอร์มจึงไม่ได้เป็นเพียงการยืนข้างผู้ใช้อย่างบริสุทธิ์ใจเท่านั้น
การถูกทำให้เป็นตัวกลางที่อีเมลเผชิญมาก่อน
- อีเมลถูกทำให้เป็นตัวกลางก่อนพุช และในพุชก็กำลังเกิดกระแสเดียวกันตามมาโดยช้ากว่าหนึ่งจังหวะ
- พุชเป็นช่องทางที่เสียเปรียบกว่าอีเมล
- อีเมลมีเครื่องมือวัดอย่าง Postmaster Tools และแดชบอร์ดด้านการส่งถึง แต่พุชแทบไม่มีเลย
- อีเมลยังคงอยู่ในกล่องขาเข้าเพื่อให้ผู้ใช้เลื่อนดู ค้นหา และกลับมาอ่านได้ แต่การแจ้งเตือนจะถูกลบ เลื่อนตก ถูกสรุปในศูนย์การแจ้งเตือน และไม่ได้ถูกเก็บไว้อย่างเสถียร
- Gmail เริ่มจัดหมวดหมู่อีเมลที่ถูกต้องตามกฎหมายเป็น Primary, Promotions, Social และ Updates ด้วย tabbed inbox ตั้งแต่ปี 2013 และ Apple Mail ก็เพิ่มการจัดหมวดหมู่ของตนเองในปี 2024
- Mail Privacy Protection ถูกใส่เข้ามาใน iOS 15 เมื่อเดือนกันยายน 2021 ทำให้ Apple Mail ดึงเนื้อหาระยะไกลล่วงหน้าผ่านพร็อกซีที่ Apple ควบคุม โดยไม่เกี่ยวว่าผู้ใช้เปิดอ่านจริงหรือไม่
- วิธีนี้ซ่อน IP address และทำให้กลไก open pixel ที่นักการตลาดพึ่งพาใช้การไม่ได้
- Omeda สังเกตว่าอัตราการเปิดอ่านที่มาจาก Apple เพิ่มจาก 22.6% เป็น 40.5% ในช่วง 6 เดือน แต่เป็นผลจากการ prefetch ไม่ใช่การเพิ่มขึ้นของผู้อ่าน
- อัตราการเปิดอ่านในรูปแบบเดิมไม่อาจกู้คืนได้อีกต่อไป และอัตราการคลิกกับ conversion ขั้นปลายจึงเข้ามาแทนในฐานะสัญญาณการมีส่วนร่วม
- ตั้งแต่ต้นปี 2024 เป็นต้นมา Yahoo และ Google กำหนดให้ผู้ส่งที่ส่งอีเมลในปริมาณมีนัยสำคัญไปยังกล่องขาเข้าส่วนบุคคล ต้องมีการยืนยันตัวตนด้วย SPF และ DKIM, การจัดแนว DMARC, การยกเลิกสมัครแบบคลิกเดียว และต้องรักษาอัตราการถูกรายงานเป็นสแปมให้อยู่ในระดับต่ำ
- อีเมลทำงานอยู่บนโปรโตคอลแบบเปิดและแบบสหพันธ์ แต่การสมัครรับพุชมีอยู่ในรูปของสิทธิ์ที่ผูกกับการติดตั้งเฉพาะบนอุปกรณ์เฉพาะ ภายในแอปเนทีฟ หรือภายในเว็บแอปบนหน้าโฮมหลัง iOS 16.4
- พุชถูกผูกกับโทเค็น APNs หรือ FCM และ Apple หรือ Google สามารถทำให้โทเค็นนั้นใช้ไม่ได้ได้ตามอำเภอใจ โดยผู้ส่งไม่มีรายชื่อที่สามารถย้ายออกไปใช้ที่อื่นได้
- Web push ช่วยขยายขอบเขตผู้ส่งได้เพราะส่งได้โดยไม่ต้องดาวน์โหลดจาก App Store แต่ก็ยังอยู่ในถาดการแจ้งเตือนเดียวกันและถูกบรรณาธิการบนอุปกรณ์แบบเดียวกัน จึงไม่ได้หลุดพ้นจากตัวกลางเหล่านี้
- ในพุชเช่นกัน ผู้ส่งยิ่งรู้ได้ยากขึ้นว่าการแจ้งเตือนของตนถูกสรุปไว้ ถูกซ่อนไว้หลัง Focus mode ถูกลดลำดับความสำคัญโดยโมเดลบนอุปกรณ์ หรือถูกย้ายไปอยู่ในโฟลเดอร์เงียบหรือไม่
ตัวแก้ไขบนอุปกรณ์
- การแก้ไขอีเมลส่วนใหญ่เกิดขึ้นระหว่างการส่ง แต่การแก้ไขการแจ้งเตือนแบบพุชเกิดขึ้นที่ชั้นการแสดงผล
- การจะแสดงการแจ้งเตือนหรือไม่ จะสรุปหรือไม่ จะจัดเป็นลำดับความสำคัญต่ำหรือไม่ และจะจัดกลุ่มหรือไม่นั้น ถูกตัดสินในชั้นการแสดงผลของอุปกรณ์
- แกนหลักไม่ใช่เครือข่าย แต่เป็น โมเดลบนอุปกรณ์ และไม่มีการเปิดเผยค่าน้ำหนักกับสัญญาณที่ใช้
- Apple Intelligence ใช้ foundation language model บนอุปกรณ์ขนาด 3 พันล้านพารามิเตอร์ และใช้เซิร์ฟเวอร์โมเดล Parallel-Track Mixture-of-Experts ที่มีขนาดใหญ่กว่าซึ่งใช้งานได้ผ่าน Private Cloud Compute
- รายงานทางเทคนิค เดือนกรกฎาคม 2025 กล่าวถึง KV-cache sharing และ 2-bit quantization-aware training ที่ปรับให้เหมาะกับ Apple silicon
- ฟีเจอร์ของ Apple Intelligence โดยทั่วไปไม่ได้ใช้โมเดลฐานโดยตรง แต่ระบบปฏิบัติการจะโหลดอะแดปเตอร์สไตล์ LoRA ขนาดเล็กระดับหลายสิบ MB แบบไดนามิก เพื่อให้เชี่ยวชาญงานอย่างการสรุปผล การดึงเอนทิตี การเกลาประโยค และการจัดลำดับความสำคัญของการแจ้งเตือน
- หลัง BBC ร้องเรียนว่าการสรุปสร้างพาดหัวที่ผิดพลาด Apple ได้ปิดการสรุปสำหรับแอป News and Entertainment ใน iOS 18.3 แสดงสรุปจาก AI เป็นตัวเอียง และเพิ่มสวิตช์ปิดรายแอปบนหน้าจอล็อกพร้อมคำเตือนว่าอาจเกิดข้อผิดพลาดได้
- Gemini Nano ของ Google ทำงานภายใน AICore ซึ่งเป็น system service ที่เปิดตัวใน Android 14
- AICore เก็บโมเดลไว้ใน system partition ให้แอปที่มีสิทธิ์แชร์ค่าน้ำหนักได้ แยกแต่ละคำขอ inference ออกจากกัน และไม่เก็บข้อมูลอินพุตหรือเอาต์พุต
- AICore ปฏิบัติตามหลักการของ Android Private Compute Core โดยใช้ package binding แบบจำกัด บล็อกการเข้าถึงอินเทอร์เน็ตโดยตรง และอัปเดตโมเดลผ่าน Google Play System Updates
- Gemini Nano จะถูกส่งงานไปยัง NPU, GPU หรือ CPU ของอุปกรณ์โดยอัตโนมัติ และสามารถปรับให้เหมาะกับฟีเจอร์อย่างการสรุปใน Pixel Recorder การจัดระเบียบการแจ้งเตือน และ smart reply ผ่าน Low-Rank Adaptation โดยไม่ต้องเทรนโมเดลฐานใหม่
- กระบวนการแก้ไขรายรายการแจ้งเตือนเริ่มจากแอปสร้าง payload และส่งไปยัง APNs หรือ FCM จากนั้นระบบปฏิบัติการจะใช้กฎควบคุมของผู้ใช้ก่อน เช่น Focus modes, ตาราง Do Not Disturb, การปิดเสียง channel และการบล็อกรายแอป
- หลังจากนั้น การแจ้งเตือนจะเข้าสู่ตรรกะการจัดอันดับและการแสดงผลของแพลตฟอร์ม และถ้าเปิด Notification Summaries บน iOS ระบบปฏิบัติการอาจส่งข้อความที่รวมกันแล้วไปยังโมเดลบนอุปกรณ์ที่ติดอะแดปเตอร์สรุป และแทนที่หัวข้อกับเนื้อหาต้นฉบับด้วยข้อความที่สร้างขึ้นใหม่
- หากเปิด Priority Notifications ซึ่งใน iOS 18.4 เป็นต้นไปมีค่าเริ่มต้นเป็นปิด ระบบอาจใช้การจัดอันดับรายแอปที่เรียนรู้มาเพื่อตรึงการแจ้งเตือนบางรายการไว้และลดความสำคัญของรายการอื่น
- เมื่อเปิด Reduce Interruptions Focus โมเดลจะประเมินว่าการแจ้งเตือนแต่ละรายการมีความสำคัญเกินเกณฑ์ที่ผู้ใช้ปรับแต่งไว้หรือไม่
- US 11,340,963 ของ Microsoft Technology Licensing LLC และ US 11,609,806, US 8,707,201 ของ Google LLC แสดงให้เห็นว่าแนวทางใช้โมเดลที่เรียนรู้มาเพื่อเขียนแจ้งเตือนใหม่ กำหนดเวลาในการส่ง และจัดลำดับความสำคัญนั้นมีอยู่ก่อนข้อถกเถียงเรื่อง iOS 18 มานานแล้ว
เครื่องมือควบคุมที่ผู้ส่งใช้ได้มีจำกัด
UNNotificationServiceExtensionของ iOS ทำให้โค้ดของแอปสามารถปรับเปลี่ยนการแจ้งเตือนที่ส่งมาได้ในช่วงสั้น ๆ ก่อนแสดงผล และสามารถใช้สำหรับถอดรหัส payload ดึงภาพ และแก้ไขข้อความUNNotificationContentExtensionทำให้สามารถกำหนด UI แบบกำหนดเองสำหรับมุมมองส่วนขยายได้- ส่วนขยายทั้งสองแบบจะไม่ทำงานหลังขั้นตอนการสรุปหรือการจัดลำดับความสำคัญของแพลตฟอร์ม
- เฮดเดอร์
apns-priorityให้ค่าได้สองแบบคือ 5 และ 10 โดย 5 ใช้ส่งการแจ้งเตือนที่ไม่เร่งด่วนในจังหวะที่ประหยัดพลังงาน และ 10 ใช้สำหรับการแจ้งเตือนที่มีลักษณะให้โต้ตอบจริงและต้องส่งทันที - บน Android นักพัฒนาเขียนผ่าน
NotificationManagerและประกาศระดับความสำคัญของ channel ได้ แต่ไม่สามารถหลีกเลี่ยงการจัดประเภทของระบบได้ NotificationListenerServiceเป็น API ระดับระบบที่ OEM และแอปด้านการช่วยการเข้าถึงใช้เพื่ออ่านการแจ้งเตือนที่เข้ามา- ไม่มี API สำหรับตรวจจับว่าการแจ้งเตือนถูกสรุปแล้วหรือไม่ ถูกจัดเข้าไปในหมวด Promotions ของ Notification Organiser หรือไม่ ถูกยับยั้งโดย Focus หรือถูกลดความสำคัญลงแบบเงียบ ๆ โดย Priority Notifications หรือไม่
อุปกรณ์สวมใส่เป็นเพียงส่วนย่อยของสตรีมการแจ้งเตือนบนโทรศัพท์
- โดยค่าเริ่มต้น Apple Watch จะมิเรอร์การแจ้งเตือนจาก iPhone แต่จะเป็นไปตามสถานะ Focus และ Summary ของ iPhone
- ตั้งแต่ watchOS 11 เป็นต้นมา Smart Stack ใช้สัญญาณบนอุปกรณ์ เช่น ตำแหน่ง เวลา และปฏิทิน เพื่อแสดงวิดเจ็ตที่เกี่ยวข้อง
- โดยค่าเริ่มต้น Wear OS จะ bridge การแจ้งเตือนจากโทรศัพท์ไปยังนาฬิกาที่จับคู่ไว้ และมีตัวควบคุมสำหรับนักพัฒนาอย่าง
BridgingConfig,setBridgeTag,setDismissalIdเพื่อป้องกันความซ้ำซ้อนเมื่อมีการติดตั้ง companion watch app - สามารถยับยั้งการส่งต่อการแจ้งเตือนความสำคัญต่ำไปยังนาฬิกาได้ แต่ไม่สามารถบังคับส่งการแจ้งเตือนที่ผู้ใช้ปิดเสียงไว้บนโทรศัพท์ไปยังนาฬิกาได้
- อุปกรณ์สวมใส่เป็นส่วนย่อยที่เคร่งครัดของสตรีมการแจ้งเตือนบนโทรศัพท์ โดยผ่านการแก้ไขของแพลตฟอร์มเดียวกันในฝั่ง upstream และผ่านตัวกรองเพิ่มเติมในฝั่ง downstream คือพฤติกรรมการ bridge และ complication ฝั่งนาฬิกา
วิธีที่ผู้ใช้จัดการกับการแจ้งเตือนจริง ๆ
- การแจ้งเตือนส่วนใหญ่ไม่ได้ทำให้ผู้ใช้สลับไปยังแอปทันที แต่ทำหน้าที่เป็น สัญญาณการรับรู้ ที่ผู้ใช้เห็นแล้วก็กลับไปทำสิ่งที่กำลังทำต่อ
- งานวิจัย CHI 2014 ของ Sahami Shirazi, Henze, Dingler, Pielot, Weber และ Schmidt เรื่อง “Large-Scale Assessment of Mobile Notifications” เก็บการแจ้งเตือนราว 200 ล้านรายการจากผู้ใช้มากกว่า 40,000 คน ผ่านการวัดจาก Android launcher
- การแจ้งเตือนจากแอปส่งข้อความถูกประเมินว่ามีคุณค่ามากที่สุดอย่างสม่ำเสมอ ขณะที่การแจ้งเตือนเชิงโปรโมชันถูกประเมินต่ำที่สุดอย่างสม่ำเสมอ
- จึงเป็นหลักฐานเชิงประจักษ์ว่าควรจัดการข้อความจากบุคคลและข้อความจากแบรนด์บนคนละพื้นผิว
- งานวิจัย MobileHCI 2014 ของ Pielot, Church และ de Oliveira เรื่อง “An In-Situ Study of Mobile Phone Notifications” พบว่า ผู้ใช้ได้รับการแจ้งเตือนเฉลี่ยวันละ 63.5 รายการ ส่วนใหญ่มาจากแอปแชตและอีเมล และถึงแม้โทรศัพท์จะอยู่ในโหมดเงียบ ผู้ใช้ก็มักหันมาสนใจภายในไม่กี่นาที
- Attelia ที่ Okoshi และคณะสร้างขึ้น เป็นมิดเดิลแวร์ที่ตรวจจับจุดหยุดพักของกิจกรรมบนโทรศัพท์ผู้ใช้แล้วพักการแจ้งเตือนไว้จนถึงจุดนั้น ซึ่งในการศึกษาควบคุมช่วยลดภาระทางการรับรู้ได้ 46% และลดได้ 33% ในสภาพแวดล้อมจริง
- ต่อมา ในการใช้งานจริงขนาดใหญ่ภายในแอป Yahoo! Japan เพียงการปรับเวลาในการส่งก็ทำให้อัตราคลิกเพิ่มขึ้นได้สูงสุด 60.7%
- Localytics รายงานว่า 52% ของผู้ใช้ที่ปิดการแจ้งเตือนแบบพุชจะเลิกใช้แอปไปอย่างสิ้นเชิงในที่สุด ช่วงที่เหมาะสมสำหรับแอปส่วนใหญ่คือ 2–5 การแจ้งเตือนต่อสัปดาห์ และกลุ่มเป้าหมายแบบแบ่งเซ็กเมนต์มีอัตราเปิดสูงกว่าการส่งแบบเหวี่ยงทั้งหมดราว 2 เท่า
- Leanplum ซึ่งถูกรวมเข้า CleverTap รายงานว่า อัตราเปิดของการแจ้งเตือนแบบเฉพาะบุคคลสูงกว่าการส่งรวมทั่วไปประมาณ 800% และ 90% ของการแจ้งเตือนแบบพุชที่ถูกเปิดนำไปสู่การกระทำภายใน 1 ชั่วโมง
- รายงานฟินเทคปี 2025 ของ CleverTap ระบุว่าแคมเปญแบบแบ่งเซ็กเมนต์มีอัตราเปิดเฉลี่ย 16.3% ส่วนแคมเปญที่ไม่กำหนดเป้าหมายอยู่ที่ 4.7%
- แม้ตัวเลขที่ผู้ให้บริการรายงานเองควรถูกมองอย่างระมัดระวัง แต่ทิศทางโดยรวมสอดคล้องกัน
- ปริมาณการส่งทำลายสิทธิ์การอนุญาต และความเกี่ยวข้องคือคันโยกที่เสถียรเพียงอย่างเดียวที่ควบคุมได้
- เวลาในการส่งก็สำคัญ แต่สำคัญน้อยกว่าความเกี่ยวข้อง
- สิ่งที่ดูเป็นโปรโมชันมักถูกจัดเป็นโปรโมชัน และบ่อยครั้งการตัดสินนั้นก็ถูกต้อง
- ผู้ใช้ยอมรับการแจ้งเตือนแบบธุรกรรมและแบบสนทนาได้บ่อยกว่าการแจ้งเตือนเชิงโปรโมชันอย่างมาก
- การคัดกรองของแพลตฟอร์มจะทำงานแรงที่สุดกับการส่งแบบเหวี่ยงทั้งหมดและพุชเชิงโปรโมชัน ขณะที่การแจ้งเตือนที่ผู้ใช้ต้องการจริงมักผ่านไปได้ตามปกติหรือแม้แต่ถูกเน้นมากขึ้น
- Live Activities คือเส้นทางอ้อมที่ชัดเจนที่สุด
- เซสชัน ActivityKit ถูกเรนเดอร์บนหน้าจอล็อกและ Dynamic Island ซึ่งเป็นพื้นผิวแยกจากถาดการแจ้งเตือน ดังนั้นตัวสรุปและการจัดกลุ่มจึงไม่เข้าไปแตะต้อง
- Live Updates และ ongoing notifications บน Android ก็ทำหน้าที่แบบเดียวกัน
- สำหรับคอนเทนต์เชิงธุรกรรมที่กำลังดำเนินอยู่จริง เช่น เรียกรถ การจัดส่ง การแข่งขัน หรือไทเมอร์ นี่คือเส้นทางที่สะอาดที่สุดในการหลบตัวคัดกรองของแพลตฟอร์ม
- แต่ใช้ได้เฉพาะกับเหตุการณ์ที่กำลังเกิดขึ้นจริงเท่านั้น ไม่สามารถห่อหุ้มโปรโมชันให้ดูเหมือน Live Activity ได้
- งานวิจัย Media Psychology ปี 2024 ของ Dekker, Baumgartner, Sumter และ Ohme เรื่อง “Beyond the Buzz” รายงานว่า ในการทดลองแบบสุ่มเป็นเวลา 1 สัปดาห์ การปิดการแจ้งเตือนไม่ได้ลดความถี่ในการเช็กโทรศัพท์หรือเวลาหน้าจอ และผู้ใช้ชดเชยด้วยการเข้าแอปโดยตรงแทน
สิ่งที่นักการตลาดมองเห็นได้
- การมองเห็นของนักการตลาดถูกทำให้ต่ำโดยตั้งใจ และกำลังแย่ลงเรื่อย ๆ
- ตัวชี้วัดจะเรียงจากน่าเชื่อถือที่สุดไปน้อยที่สุดเป็น การส่ง, การยอมรับโดยแพลตฟอร์ม, การส่งถึงอุปกรณ์, การแสดงบนอุปกรณ์, การเปิด และคอนเวอร์ชันที่ถูกระบุแหล่งที่มา
- APNs และ FCM ให้รหัสตอบกลับเมื่อส่งจากเซิร์ฟเวอร์ ดังนั้นสถานะการยอมรับโดยแพลตฟอร์มจึงมองเห็นได้ค่อนข้างเสถียร แต่ APNs ไม่ได้ให้การยืนยันการส่งแบบเดียวกับ SMTP และสิ่งที่รู้ได้มีเพียงว่า Apple รับ payload แล้วนำไปเข้าคิว
- FCM ให้ message ID และในบางกรณีมี delivery callback แต่เส้นแบ่งระหว่าง “ส่งถึงอุปกรณ์แล้ว” กับ “แสดงให้ผู้ใช้เห็นแล้ว” ก็ยังไม่โปร่งใสอยู่ดี
- iOS จะเก็บเฉพาะการแจ้งเตือนล่าสุดต่อแอปเมื่ออุปกรณ์ออฟไลน์ ดังนั้นการแจ้งเตือนเก่าอาจถูกลบอย่างเงียบ ๆ ก่อนจะไปถึงผู้ใช้
- แพลตฟอร์ม lifecycle อย่าง Braze, Iterable, OneSignal, Airship, CleverTap, MoEngage, Pushwoosh, Customer.io และ Batch จะเพิ่มการวัดผลที่อิงกับแอป SDK เข้าไป
- SDK จะบันทึกการแสดงการแจ้งเตือน การแตะของผู้ใช้ และการเริ่มเซสชันที่เกิดจากการแตะนั้นหรือไม่
- ความละเอียดของข้อมูลขึ้นอยู่กับว่าบน iOS มีการประกาศ NotificationServiceExtension หรือบน Android มี broadcast receiver ที่เทียบเท่ากันหรือไม่
- หากไม่มีส่วนขยาย “ส่งถึงแล้ว” จะถูกย่อลงกลับไปเป็นเพียง “APNs/FCM ยอมรับแล้ว” ทำให้อัตราการส่งสำเร็จที่เห็นภายนอกสูงเกินจริงเมื่อเทียบกับสิ่งที่ผู้ใช้ได้เห็นจริง
- ตามคู่มือของ OneSignal เอง อัตราคลิกตามธรรมเนียมคำนวณจากจำนวนการแตะหารด้วยจำนวนที่ส่งถึง และคำว่า delivered มักหมายถึง “ผ่าน FCM หรือ APNs แล้ว”
- วิธีนี้รวมถึงการแจ้งเตือนที่ไม่เคยถูกแสดง การแจ้งเตือนที่ถูกปัดทิ้งโดยไม่อ่าน การแจ้งเตือนที่ถูกยกเลิกอย่างเงียบ ๆ และการแจ้งเตือนที่ถูกซ่อนไว้หลัง Focus หรือฟิลเตอร์ Reduce Interruptions
- “confirmed delivery” ของบางแพลตฟอร์มนับการแจ้งเตือนที่ SDK เห็นว่าถูกเรนเดอร์แล้ว จึงใกล้กับความเป็นจริงมากกว่า แต่ก็ยังไม่รู้ว่าผู้ใช้ได้เห็นการแจ้งเตือนที่เรนเดอร์แล้วจริงหรือไม่ก่อนจะปิดทิ้ง
- พาร์ตเนอร์ด้านการวัดผลมือถืออย่าง AppsFlyer, Adjust, Branch, Singular และ Kochava จะใส่ลิงก์ติดตามไว้ใน payload แล้วจับคู่กับเหตุการณ์จาก SDK ภายหลัง เพื่อระบุว่าเซสชันปลายทางมาจากแคมเปญพุชใด
- เครื่องมือวิเคราะห์ในแอปอย่าง Amplitude, Mixpanel, Heap และ PostHog มองเห็นเซสชันปลายทาง แต่ไม่ได้มองเห็นการแจ้งเตือนต้นทางด้วยตัวเอง
- หากส่งเหตุการณ์การส่งและการเปิดจากแพลตฟอร์มพุชเข้าเครื่องมือวิเคราะห์ด้วยตัวระบุผู้ใช้ร่วมกัน ก็จะเชื่อมการแจ้งเตือน เซสชัน และคอนเวอร์ชันเข้าด้วยกันได้ แต่ส่วนกลางของฟันเนลอย่าง “การแจ้งเตือนที่ส่งถึงแล้วถูกแสดง สรุป ลดระดับ ถูก Focus กดไว้ หรือไม่ถูกรับรู้บ่อยแค่ไหน” ยังไม่สามารถกู้กลับมาได้
- มีสัญญาณจำนวนมากที่แพลตฟอร์มไม่ได้ให้มา
- บน iOS การแจ้งเตือนนั้นถูกจัดรวมอยู่ใน Notification Summary หรือไม่
- บน Pixel การแจ้งเตือนนั้นเข้าไปอยู่ในหมวด Promotions ของ Notification Organiser หรือไม่
- Reduce Interruptions ทำให้เงียบลงหรือไม่
- Priority Notifications ลดระดับมันลงหรือไม่
- บน iOS ผู้ใช้ปัดออกจากหน้าจอล็อกโดยไม่อ่านหรือไม่
- ผู้ใช้อยู่ในโหมด Focus ที่กดการแจ้งเตือนนั้นไว้หรือไม่
- มันถูกลบก่อนแสดงเพราะข้อจำกัดการเก็บของ iOS หรือไม่
- Samsung One UI 8.5 สรุปมันไว้หรือไม่
- จุดหนึ่งที่พุชดีกว่าอีเมลคือ delete-intent บน Android
- เมื่อผู้ใช้ปัดเพื่อลบการแจ้งเตือนที่แสดงอยู่ จะเกิดอีเวนต์ขึ้น ทำให้บันทึกการยกเลิกโดยเจตนาได้
- แต่เป็นฟีเจอร์เฉพาะ Android, เกิดขึ้นเฉพาะกับการแจ้งเตือนที่ถูกแสดงแล้ว, และไม่สามารถแยกการปัดอย่างตั้งใจกับการล้างทั้งหมดในครั้งเดียวได้
- การวัดผลพุชในปี 2026 จะคล้ายการวัดผลอีเมลหลัง Mail Privacy Protection คือใช้ข้อมูลคอนเวอร์ชันที่จับได้เฉพาะผู้ใช้ที่ลงมือทำจริง มาปรับเทียบตัวชี้วัดที่อยู่ใต้ชั้นการคัดกรองซึ่งมองไม่เห็น
วิธีเขียนสำหรับโมเดลที่อยู่ในท่อ
- ข้อความส่งทั้งหมดไม่อาจคงอยู่ในสภาพเดิมได้อีกต่อไป
- ตัวสรุปผลบนอุปกรณ์จะบีบอัดการแจ้งเตือนให้เหลือแต่ใจความ ดังนั้นสิ่งที่ถูกส่งต่อจึงไม่ใช่น้ำเสียงของแบรนด์ แต่เป็น ข้อเท็จจริงที่เป็นรูปธรรม
- หากวาง payload หลักอย่างจำนวนเงิน ชื่อ เวลา และการกระทำไว้ด้านหน้า ตัวสรุปก็จะมีสิ่งที่ควรเก็บรักษาไว้
- หากซ่อนประเด็นสำคัญไว้หลังบทเกริ่นแบบแบรนด์ คำอุทาน อีโมจิ หรือมุกเล่นคำ ตัวสรุปอาจเหลือแค่อีโมจิแล้วทิ้งความหมายไป หรือเก็บไว้เพียงครึ่งเดียวแบบผิดๆ
- ควรมองหัวเรื่องเหมือนเป็น structured data field ที่เขียนด้วยภาษาธรรมชาติ
- “Your delivery is 15 minutes away” มีเสถียรภาพสำหรับการสรุป
- “We've got great news!” ไม่เสถียรเพราะไม่ได้บรรจุข้อเท็จจริง
- วิธีตรวจสอบตัวเองแบบหยาบๆ อย่างหนึ่งคือดูว่า แม้จะเหลือเพียงไม่กี่คำแรกของหัวเรื่อง ก็ยังให้ข้อมูลที่เป็นประโยชน์แก่ผู้ใช้หรือไม่
- สิ่งนี้ไม่ใช่การรับประกัน แต่ควรทำให้เป็นนิสัย
- หลักการเดียวกันนี้ใช้กับ Live Activities และ Live Updates โดยข้อเสนอหลักคือฟิลด์อย่าง ETA คะแนน หรือจำนวนก้าว ไม่ใช่การห่อหุ้มด้วยแบรนด์
- เหตุผลที่ไม่ควรใช้ระดับการขัดจังหวะแบบไวต่อเวลาเกินควร มีระบุไว้อย่างชัดเจนในคู่มือนักพัฒนาของ Batch
- “If your time-sensitive notifications are not often interacted with, iOS will prompt your users from the lock screen to let them disable time-sensitive alerts for your app”
- ผู้ใช้สามารถปิดการแจ้งเตือนแบบไวต่อเวลาของแต่ละแอปได้จากหน้าจอล็อกด้วยการแตะครั้งเดียว และไม่มีขั้นตอนอุทธรณ์ที่เท่าเทียมกันสำหรับผู้ส่ง
ขยับจุดศูนย์ถ่วงไปยังพื้นผิวที่เป็นเจ้าของเอง
- พุชควรมีบทบาทเล็กลงในโปรแกรมตลอดวงจรชีวิตผู้ใช้
- พื้นผิวที่เป็นเจ้าของเองภายในแอปสามารถแบ่งได้ตามระดับความรบกวนจากน้อยไปมาก
- การ์ดในผลิตภัณฑ์แบบ passive ภายในฟีดที่ผู้ใช้ตั้งใจเข้ามาเอง
- ศูนย์ข้อความหรืออินบ็อกซ์ในแอปแบบถาวรที่ผู้ใช้กลับมาเปิดดูได้อีก
- ข้อความในแอปแบบเจาะจงตามเหตุการณ์ของเซสชัน ซึ่งแสดงเฉพาะระหว่างเซสชันที่กำลังใช้งานอยู่
- องค์ประกอบข้อความแบบฝังใน product flow ที่วางอยู่บนหน้าจอที่ผู้ใช้เข้ามาอยู่แล้วเพื่อทำงานให้เสร็จ
- พื้นผิวที่เป็นเจ้าของเองเหล่านี้ไม่ผ่าน APNs หรือ FCM และไม่ถูกแตะต้องโดย Apple Intelligence หรือ Gemini Nano
- ไม่มีการสรุปหรือการกดทับจาก Focus และ SDK จะบันทึกเหตุการณ์การเรนเดอร์ การปิด และการโต้ตอบ จึงสังเกตการณ์ได้โดยไม่มีช่องว่างจากตัวกลางของแพลตฟอร์ม
- ข้อจำกัดคือพื้นผิวที่เป็นเจ้าของเองเข้าถึงได้เฉพาะ ผู้ใช้ที่กำลังใช้งานอยู่
- ผู้ใช้ที่ไม่ได้เปิดแอปมา 14 วันจะเข้าถึงด้วยข้อความในแอปไม่ได้ และเข้าถึงได้ด้วยพุชเท่านั้น
- พุชจึงกลายเป็นช่องทางสำหรับดึงผู้ใช้ที่หลับไปแล้วให้กลับมามีส่วนร่วมอีกครั้ง และสำหรับการแจ้งเตือนเชิงธุรกรรมหรือแบบไวต่อเวลาต่อผู้ใช้ที่ยังใช้งานอยู่
- การขายต่อเนื่อง การอัปเซลล์ การค้นพบคอนเทนต์ การให้ความรู้ และการเพิ่มคุณค่า เป็นหน้าที่ของพื้นผิวในผลิตภัณฑ์
- จากข้อมูลปี 2025 ของ Batch อัตราการคลิกของข้อความในแอปสำหรับแคมเปญโค้ดโปรโมชันอยู่ที่ Android 16.1% และ iOS 17.9% ซึ่งสูงกว่า CTR ของพุช
- ในข้อมูลชุดเดียวกัน ข้อความในแอปมีฐานผู้เข้าถึงเล็กกว่าพุช เพราะต้องอาศัยเซสชัน
- พุชมีไว้เพื่อพาผู้ใช้กลับเข้ามาในผลิตภัณฑ์ และเมื่อผู้ใช้เข้ามาแล้ว พื้นผิวที่เป็นเจ้าของเองจะรับช่วงต่อ
การเปลี่ยนแปลงถัดไป: เอเจนต์ที่จัดการการแจ้งเตือน
- โมเดลภาษาบนอุปกรณ์เมื่อถูกติดตั้งแล้ว จะถูกใช้เกินกว่าการสรุปไปสู่หลายกรณีใช้งาน
- Foundation Models framework ของ Apple ทำให้นักพัฒนาสามารถเรียกใช้โมเดลเดียวกับที่ระบบปฏิบัติการใช้ได้ตั้งแต่ iOS 18.4 สำหรับการสรุป การดึงเอนทิตี ความเข้าใจข้อความ การปรับเกลา และบทสนทนาสั้นๆ
- ML Kit GenAI APIs ของ Google บน AICore เปิดให้ใช้การสรุป การตรวจแก้ การเขียนใหม่ และคำอธิบายภาพ
- ขั้นถัดไปคือการให้โมเดลตอบสนองต่อการแจ้งเตือนและลงมือทำแทนผู้ใช้
- การกระทำที่เป็นไปได้ เช่น เปิดแอป ดำเนินการจองให้เสร็จ ปิดการแจ้งเตือน หรือร่างคำตอบ
- การให้เหตุผลที่หนักขึ้นมีแนวโน้มจะรันฝั่งเซิร์ฟเวอร์ เช่น Apple Private Cloud Compute หรือโมเดลคลาวด์ของ Google มากกว่าจะรันอยู่แต่ในอุปกรณ์
- เฟรมเวิร์ก App Intents ของ Apple ทำให้นักพัฒนาสามารถเปิดเผยการกระทำของแอปแบบมีชนิดข้อมูลให้ Siri และ Apple Intelligence ใช้งานได้
- บน Android ความสามารถที่กำลังก่อตัวขึ้นของ App Actions และ Gemini ในการกระทำภายในแอปของบุคคลที่สามทำหน้าที่คู่ขนานกัน
- ผู้ส่งไม่ควรหยุดอยู่แค่การเขียนการแจ้งเตือนที่ตัวสรุปจะไม่ทำพัง แต่ต้องเปิดเผยการกระทำที่อยู่หลังการแจ้งเตือนด้วย เพื่อให้เอเจนต์สามารถจองให้เสร็จหรือปัดการแจ้งเตือนได้ แม้ผู้ใช้จะไม่เปิดแอปก็ตาม
- การแจ้งเตือนจะกลายเป็นทริกเกอร์ที่เอเจนต์นำไปใช้ ไม่ใช่ปลายทาง และตัวชี้วัดอัตราการคลิกซึ่งเป็นศูนย์กลางของการวัดผลพุชมาตลอด 10 ปี จะสูญเสียความหมายไปอย่างมาก
หลักปฏิบัติในการจัดการการแจ้งเตือนแบบพุชสำหรับงานจริง
-
ใช้พุชเฉพาะกับสิ่งที่ช่องทางอื่นทำไม่ได้
- พุชเป็นช่องทางที่เข้าถึงผู้ใช้ที่ไม่ได้เปิดแอปมาหลายสัปดาห์ได้ จึงเหมาะที่สุดสำหรับ ปลุกผู้ใช้ที่ไม่ใช้งานอยู่ และการแจ้งเตือนเชิงธุรกรรมที่ไวต่อเวลาอย่างแท้จริง
- การแจ้งเตือนเพื่อ cross-sell, upsell, ให้ความรู้ หรือการค้นพบก็ทำได้หากมีความทันท่วงทีและการปรับให้เหมาะกับแต่ละบุคคลมากพอ แต่โดยพื้นฐานแล้วจัดเป็นการสื่อสารเชิงโปรโมชัน และเสียเปรียบที่สุดในการแข่งขันเพื่อแย่งชิงงบประมาณความรบกวนของผู้ใช้
- ข้อความเชิงโปรโมชันมีประสิทธิภาพมากกว่าและมีความเสี่ยงต่ำกว่าเมื่ออยู่บนหน้าจอที่ผู้ใช้ตั้งใจเปิดเอง
-
ออกแบบโดยยึดกิจกรรมและคำขอของผู้ใช้เป็นศูนย์กลาง
- การแจ้งเตือนที่ผ่านการตัดต่อคัดกรองของแพลตฟอร์มได้ง่าย มักเป็นสัญญาณที่ผู้ใช้ตั้งค่าเองโดยตรง และเหตุการณ์ที่ผลิตภัณฑ์สร้างขึ้นจากสถานะของผู้ใช้
- การลดราคา, สินค้ากลับมามีสต็อก, รายการสนใจ, threshold trigger, การแจ้งสถานะของรายการที่กำลังรออยู่ ล้วนเป็นสัญญาณที่ผู้ใช้ตั้งค่าเองโดยตรง
- เอกสารที่มีการแชร์, ความคิดเห็นหรือคำตอบบนงานที่ผู้ใช้ทำ, งานที่เสร็จสิ้น, การเกินขีดจำกัด, ขั้นตอนถัดไปของงานที่กำลังดำเนินอยู่ ล้วนเป็นเหตุการณ์ที่ผลิตภัณฑ์สร้างขึ้นจากสถานะของผู้ใช้
- ทั้งสองประเภทนี้ล้วนเป็นการแจ้งเตือนเกี่ยวกับสิ่งที่เป็น “ของตัวผู้รับเอง” จึงผ่านเกณฑ์ความเกี่ยวข้องได้โดยธรรมชาติ และควร deeplink ไปยังตำแหน่งในผลิตภัณฑ์ที่ผู้ใช้สามารถลงมือทำต่อได้ทันที
-
ขอสิทธิ์ภายในบริบท ไม่ใช่ตอนเปิดใช้ครั้งแรก
- หลังจาก Android 13 เปลี่ยนสิทธิ์การแจ้งเตือนให้เป็นการอนุมัติรันไทม์แบบชัดเจน อัตรา opt-in ก็ลดลงมาก
- แทนที่จะขึ้น system prompt ทันทีหลังเปิดใช้ครั้งแรก ควรแสดงคุณค่าก่อนโดยเชื่อมกับฟีเจอร์ที่ผู้ใช้น่าจะอยากได้รับการแจ้งเตือน แล้วค่อยขอสิทธิ์
- สิทธิ์การแจ้งเตือนครอบคลุมทั้งช่องทาง จึงไม่ควรใช้เปลืองไปกับคำขอครั้งแรกที่ผู้ใช้ยังไม่อิน
-
การแบ่งกลุ่มและการปรับให้เหมาะกับแต่ละบุคคลเป็นพื้นฐาน
- ข้อมูลจากผู้ให้บริการเป็นข้อมูลเชิงทิศทาง แต่ตลอด 10 ปีที่ผ่านมาก็ชี้ไปยังข้อสรุปเดียวกันว่า การแจ้งเตือนแบบแบ่งกลุ่ม·ปรับให้เหมาะกับแต่ละบุคคล มีอัตราการเปิดสูงกว่าการส่งแบบ broadcast ราวสองเท่า
- การส่งเป็นชุดแบบทั่วไปให้ผลลัพธ์ต่ำ และใช้สิทธิ์ที่ไม่อาจเรียกคืนได้ไปเปล่าๆ
- ถ้าไม่ใช่ข้อความที่ส่งให้คนใดคนหนึ่งได้ด้วยเหตุผลที่เฉพาะเจาะจง ก็ไม่ควรส่งให้ทุกคน
-
อย่าใช้สิทธิ์ในการรบกวนที่ยังไม่ได้รับมา
- อย่าปลอมข้อความการตลาดให้ดูเหมือน การแจ้งเตือนที่ไวต่อเวลา
- บน iOS ผู้ใช้สามารถปิดการแจ้งเตือนที่ไวต่อเวลารายแอปได้จากหน้าจอล็อก และผู้ส่งไม่อาจคัดค้านได้
- การเพิ่มปริมาณการส่งคือการฆ่าสิทธิ์อนุญาต และคันโยกเดียวที่ผู้ส่งพอจะรักษาไว้ได้คือความเกี่ยวข้อง
-
การมีส่วนร่วมเป็นตัวกำหนดความสามารถในการส่งถึง
- ระบบจัดอันดับของแพลตฟอร์มเรียนรู้ว่าผู้ใช้มีปฏิสัมพันธ์กับการแจ้งเตือนหรือไม่ ดังนั้นฐานผู้รับขนาดใหญ่ที่ไม่แตะเลยจะฝึกให้โมเดลประเมินแอปต่ำลง และผลักให้ผู้ใช้ปิดการแจ้งเตือน
- พุชไม่มีระบบชื่อเสียงผู้ส่งที่เป็นระบบเท่าอีเมล และผลลัพธ์ก็แตกต่างกันไปตามแอปและ OS แต่ทิศทางนั้นเหมือนกัน
- ควรล้างรายชื่อผู้ติดตามที่เงียบไปแล้ว เพราะ ฐานเล็กแต่มีส่วนร่วม รักษาการเข้าถึงในวงกว้างได้ดีกว่าฐานใหญ่ที่ถูกเมิน
-
ให้ข้อเท็จจริงมาก่อนสไตล์การเขียน
- ช่วงต้นของหัวข้อควรใส่ payload ที่เป็นรูปธรรม มากกว่าคำเกริ่นตามโทนแบรนด์: ข้อมูลอย่างจำนวนเงิน ชื่อ เวลา การกระทำ ควรมาก่อน
- ตัวสรุปย่อจะบีบให้เหลือแก่นและรักษาเนื้อหาที่เครื่องอ่านได้ง่ายไว้ ดังนั้นหัวข้อที่ยึดข้อเท็จจริงจึงมีโอกาสรอดจากการถูกเขียนใหม่ได้มากกว่าหัวข้อที่เน้นโทน
- นี่ไม่ใช่กฎที่พิสูจน์ด้วยการวัดผล แต่เป็นค่าเริ่มต้นที่สมเหตุสมผล ยังไม่มีการทดสอบสาธารณะ และหลักฐานก็เป็นเพียงทางอ้อม
-
อย่าหลงเชื่อแดชบอร์ดพุชมากเกินไป
- การเปิดและการคลิกอยู่หลัง ชั้นการตัดต่อคัดกรอง ที่มองไม่เห็น และ conversion ที่วัดได้คือกลุ่มตัวอย่างที่มีอคติของการแจ้งเตือนที่แพลตฟอร์มตัดสินใจเอื้อประโยชน์ให้อยู่แล้ว
- conversion ปลายทางเป็นสัญญาณที่แย่น้อยที่สุด แต่เหตุการณ์ conversion จากพุชนั้นเกิดไม่บ่อย ทำให้ในปริมาณการส่งทั่วไปมักไปไม่ถึงนัยสำคัญทางสถิติระดับรายแคมเปญ
- ถ้าตรวจสอบการเรนเดอร์ด้วย SDK ได้ก็ควรตรวจสอบ มัดรวมแคมเปญเข้าด้วยกันและขยายหน้าต่างการสังเกตการณ์ก่อนจะเชื่อตัวเลข
- การมีส่วนร่วมที่เพิ่มขึ้นอาจอ่านได้ว่าเป็น “ข้อความดีขึ้น” พอๆ กับ “แพลตฟอร์มเชื่อใจฉันมากขึ้น”
-
ย้ายความสำคัญไปยังพื้นที่ที่เป็นเจ้าของเอง
- กล่องข้อความในแอป, หน้าจอผลิตภัณฑ์ที่ล็อกอินแล้ว, ไปรษณีย์จริง, และ พื้นที่ loyalty ที่ดำเนินการเอง ไม่มีโมเดลในท่อคอยคั่นกลาง
- พื้นที่เหล่านี้ไม่ถูกสรุป ไม่ถูกจัดอันดับ ไม่ถูกทำให้เงียบ และวัดผลได้จนสุดทาง
- พุชกับพื้นที่ที่เป็นเจ้าของเองไม่ควรถูกบริหารเป็นช่องทางที่แข่งขันกัน แต่เป็นพอร์ตโฟลิโอเดียวกัน
-
ออกแบบเพื่อเอเจนต์ ไม่ใช่เพื่อหน้าจอล็อก
- เมื่อ Siri และ Gemini เริ่มลงมือทำกับการแจ้งเตือน สิ่งที่เอเจนต์สามารถรันได้คือข้อเสนอที่สะอาดและเครื่องอ่านได้
- การกระทำที่อยู่หลังการแจ้งเตือนไม่ควรถูกฝังไว้ในตำแหน่งที่ต้องแตะสามครั้งใน UI แต่ควรถูกเปิดให้เรียกใช้ได้ผ่าน App Intents ของ iOS หรือ App Actions ของ Android
- ควรเขียนให้โมเดลสามารถดำเนินการตามข้อความได้ แม้ไม่มีมนุษย์เป็นคนอ่าน
บทสรุป
- พุชไม่เคยเป็นช่องทางที่เป็นเจ้าของได้ทั้งหมดแบบอีเมล และใกล้เคียงกับช่องทางที่เช่าน้อยกว่าโซเชียลมากกว่า
- แพลตฟอร์มกำลังตั้งราคาเงื่อนไขการเช่าใหม่ให้เข้าข้างตัวเองในทุกๆ รีลีส
- ผู้ส่งที่จะอยู่รอดในอีก 10 ปีข้างหน้าไม่ใช่ฝ่ายที่ส่งมากที่สุดหรือใช้ได้ฉลาดที่สุด แต่เป็นฝ่ายที่ส่งข้อความซึ่งบรรณาธิการของแพลตฟอร์มสามารถปกป้องได้ เพราะผู้รับต้องการมันอยู่แล้ว
- งานที่ดีที่สุดจะได้เปรียบเมื่อย้ายไปอยู่บนพื้นที่ที่ไม่มีบรรณาธิการยืนขวางอยู่ข้างหน้าไว้แล้ว
- ต้องเขียนเพื่อโมเดลที่มองไม่เห็น และต้องสร้างสำหรับช่องทางที่โมเดลนั้นเอื้อมไม่ถึง
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ถ้าโทรศัพท์ของฉันจะมารบกวนฉัน มันก็ควรหมายความว่ามีใครบางคนต้องการความสนใจจากฉันจริง ๆ ในตอนนี้ ไม่อย่างนั้นก็ไม่ควรมารบกวนเลย การตั้งค่าการแจ้งเตือนของฉันอนุญาตให้มี push notification แค่ โทรศัพท์, ข้อความ, WhatsApp, Apple Health, แอปธนาคาร เท่านั้น
แอปอื่นไม่มีเหตุผลอะไรที่จะต้องเรียกฉันทันที ส่วนใหญ่แอปส่งการแจ้งเตือนไม่ใช่เพราะมีเรื่องสำคัญ แต่เพราะมันต้องการความสนใจจากฉัน
การแจ้งเตือนอย่างสถิติการใช้งานต่อเนื่อง ส่วนลด คำแนะนำ หรืออัปเดตการจัดส่ง ไม่จำเป็นเลย และรอได้จนกว่าฉันจะเลือกเปิดแอปเอง
แต่แอปส่วนใหญ่พิสูจน์มามากพอแล้วว่าไม่สามารถเคารพความสนใจของผู้ใช้ได้ ยิ่งแพลตฟอร์มวางสิ่งกีดขวางระหว่างการแจ้งเตือนที่ไม่จำเป็นกับโทรศัพท์ของฉันมากเท่าไรยิ่งดี ฉันไม่ได้มองว่า Apple หรือ Google เป็นฮีโร่ แต่อย่างน้อยผลประโยชน์ของพวกเขาก็ยังสอดคล้องกับฉันมากกว่าแผนกการตลาดของแอปที่ฉันถูกบังคับให้ติดตั้งเพียงเพราะซื้อตั๋วครั้งเดียว
การแยกบล็อก การแจ้งเตือนที่จำเป็นกับการแจ้งเตือนโฆษณา ไม่ใช่เรื่องง่าย
ฉันคิดแบบนี้ทุกครั้งที่เห็นลูกค้าอยากใส่ การรองรับ WhatsApp ในแอปเชิงพาณิชย์เพื่อ “สื่อสารกับลูกค้า”
ในขณะเดียวกัน แต่ละผู้ใช้ก็มีชุดย่อยของแอปที่อยากได้การแจ้งเตือนไม่เหมือนกัน พนักงานกะต้องรู้เรื่องกะที่ได้รับมอบหมายหรือกะที่เพิ่งเปิดขึ้นมาแบบกะทันหัน สิ่งที่สำคัญมากสำหรับผู้ใช้บางคนอาจเป็นสแปมสำหรับอีกคน
การแจ้งเตือนที่มีประโยชน์เสื่อมสภาพกลายเป็นการแจ้งเตือนการตลาดได้ง่าย ฉันอยากรู้ว่าคนส่งของอยู่ข้างนอก แต่ไม่อยากรู้โปรโมชันพิเศษประจำสัปดาห์นี้
นี่ไม่ใช่ปัญหาที่แก้ได้หมดด้วยเทคนิค ฝั่งที่ทำตัวแย่ก็ทำตัวแย่จริง ๆ ถึงอย่างนั้นระบบก็ควรถูกออกแบบให้ แอปที่มีเจตนาดี ทำงานได้ดี และท้ายที่สุดผู้ใช้ควรเป็นคนตัดสินว่าจะเห็นอะไร ไม่ใช่ Google หรือ Apple
ถ้าสร้างสังคมโดยยึดมาตรฐานต่ำสุดร่วมกัน มันก็จะแย่สำหรับทุกคน เราควรทำให้การลงโทษพฤติกรรมแย่เป็นไปได้ พร้อมกับส่งเสริมพฤติกรรมที่ดีอย่างจริงจัง ไม่ใช่ห้ามทุกอย่างเพียงเพราะ “มันอาจจะแย่ได้”
แอปที่ตั้งค่าแบบนี้ ต่อให้มีการแจ้งเตือนเข้ามา ก็จะไม่มีแบนเนอร์เด้งขึ้นและไม่แสดงบนหน้าจอล็อก ฉันจะเห็นก็ต่อเมื่อเลื่อนลงผ่านการแจ้งเตือนที่ทันเวลาในหน้าจอล็อกด้วยตัวเองเพื่อไล่ดูทั้งหมด
ในทางปฏิบัติมันจึงถูกลดระดับให้กลายเป็นเหมือน “กล่องจดหมายอีเมล” ที่จะเช็กก็ได้ไม่เช็กก็ได้ ต่างจากอีเมล การแจ้งเตือนไม่สามารถเป็นเส้นทางบังคับของ workflow ในแอปได้ ดังนั้นกล่องรับการแจ้งเตือนจึงล้างทิ้งได้ทุกเมื่อโดยไม่ต้องกังวล
มันเป็นโครงสร้างแบบดิบ ๆ ที่แอปจำนวนมากต้องแข่งขันกันเพื่อแย่งพื้นที่หน้าจอเล็กนิดเดียว และ push notification ส่วนใหญ่ก็ไม่ได้บอกอะไรมากไปกว่า “มีอะไรบางอย่างเกิดขึ้น!” ข้อมูลที่ลงมือทำอะไรต่อได้มีน้อย และก็ยังไม่ชัดด้วยว่าเกิดอะไรขึ้นจริง
ผลลัพธ์คือคุณค่าของแนวคิดเรื่องการแจ้งเตือนเองลดลง แม้มีอะไรน่าสนใจผ่านมาก็มักพลาดหรือหาย้อนกลับไปหาได้ยาก
ประสบการณ์ผู้ใช้ของ push notification แย่มาก และยิ่งแย่ลงเรื่อย ๆ เพราะนักพัฒนาแอปใช้อำนาจพิเศษในการรบกวนผู้ใช้อย่างตามใจชอบเกินขอบเขต Apple กับ Google พยายามควบคุมเรื่องนี้ แต่ผลที่เหลืออยู่ก็คือแม้แต่กรณีใช้งานที่ชอบธรรมไม่กี่อย่างก็ยังได้แค่พอใช้
พวกการยืนยันจากธนาคารหรือการยืนยันตัวตนแบบสองขั้นตอน ยังมีประโยชน์ผ่าน deep link เข้าแอป แต่เรื่องอื่นนอกนั้นไม่คุ้มกับการหยุดสิ่งที่ทำอยู่แล้วหันไปมองโทรศัพท์
บนโทรศัพท์ Android ของฉัน แอปที่ใช้บ่อยที่สุดคือ Firefox กับ Gmail และอีกไม่กี่แอป ในฐานะช่องทางแจ้งเตือน กล่องจดหมายอีเมล มีประโยชน์กว่ามือถือ push มาก มันนำไปทำอะไรต่อได้มากกว่า มีข้อมูลมากกว่า และยังยกเลิกรายการรับรายบุคคล กรอง หรือค้นย้อนหลังได้ง่าย แอปส่วนใหญ่ทำได้ทั้งสองแบบอยู่แล้ว ดังนั้น push notification จึงด้อยกว่าและซ้ำซ้อน
บทความนี้อ่านแล้วเหมือนผู้เขียนกำลังโกรธที่ Apple กับ Google มาขัดขวางหรือควบคุมการแจ้งเตือนบางประเภท โดยเฉพาะ การแจ้งเตือนแบบสแปม
บอกว่า “การขายข้าม การขายอัปเกรด การให้ความรู้ และการค้นพบก็ใช้ push ได้” แต่ push notification ควรถูกใช้กับการแจ้งเตือนเชิงธุรกรรมเท่านั้น ฉันไม่อยากได้กล่องรับขยะเพิ่มอีกอัน
น่าจะมีวิธีปิดเฉพาะข้อความการตลาด แต่คนส่วนใหญ่คงไม่รู้และไม่เปลี่ยนมัน หงุดหงิดมาก
บริการอย่าง Uber, Bolt, Airbnb น่าหงุดหงิด เพราะบริการหลักจำเป็นต้องใช้ push แต่ผู้ให้บริการกลับฉวยช่องนั้นมายัด สแปม
ตอนนี้ขยะการตลาดรุกล้ำเกินไป ฉันเลยติดตั้งแอปเฉพาะตอนที่คิดว่าน่าจะต้องใช้ ไม่อย่างนั้นก็ลบทิ้ง การส่งเบอร์เกอร์ก็ดีนะ แต่ที่น่าหงุดหงิดยิ่งกว่าคือบริการนี้ไม่มีอะไรสักอย่างที่ส่งมาถึงบ้านฉันได้จริง ๆ แบบตามตัวอักษร
ผู้คนเฉื่อยชากับสิ่งที่มาขโมยความสนใจของตัวเองเกินไปจนน่าประหลาดใจเสมอ
โทรศัพท์ของฉันเปิด โหมดห้ามรบกวน ตลอด 24 ชั่วโมง ถ้าแอปไหนแจ้งเรื่องไร้สาระก็ลบทิ้งแล้วใช้เว็บไซต์แทน
ฉันยังมีกฎในอีเมลให้ย้ายอีเมลที่มีคำว่า “unsubscribe” ออกจากกล่องจดหมายไปไว้ในพื้นที่แท็กแยกต่างหากด้วย ทุก ๆ สองสามวันก็จะเข้าไปแล้วกดยกเลิกรับทั้งหมดที่เข้ามา
ถ้าที่แคชเชียร์ร้านค้าปลีกมีการขอข้อมูลส่วนตัวหรือเบอร์โทร หรือให้สมัครสมาชิกคลับ ฉันจะถามว่ามีส่วนลดให้ไหม ถ้าไม่มีส่วนลดก็ไม่มีข้อมูลให้ ถ้ามีการเสนอราคาที่เหมาะสมกับข้อมูลของฉันฉันก็อาจพิจารณา แต่จนถึงตอนนี้ยังไม่มีร้านค้าปลีกไหนจ่ายคุ้มค่ากับเวลาและข้อมูลของฉันเลย
https://unfuck.email
การไม่รับโทรศัพท์หรือไม่ตอบข้อความเป็นเรื่องต้องห้ามสำหรับหลายคน เลยถูกบีบให้อยู่ใน การแข่งขันสะสมอาวุธ ที่พวกสแปมเมอร์และแอปโซเชียลบุกเข้ามาจากทุกทาง คนพวกนั้นมองว่าพวกเราที่อยู่ในดินแดนห้ามรบกวน 24 ชั่วโมงน่าหงุดหงิด
ฉันไม่รู้ว่าจะแก้ยังไง แต่ก็เข้าใจมุมมองนั้น
ลองใช้ชีวิตหนึ่งวันโดยปิดทุกอย่างยกเว้นการแจ้งเตือนข้อความดู คุณจะไม่ตายหรอก คุณจะชินกับการคอยเช็กสิ่งที่คุณแคร์จริง ๆ เป็นระยะได้อย่างรวดเร็ว และที่เหลือก็ต้องรอ จนกว่าฉันจะสนใจเอง
ฉันใช้ชีวิตแบบนี้มาหลายปีแล้ว และเพื่อนหรือเพื่อนร่วมงานก็ไม่รู้เรื่องนี้ แถมไม่จำเป็นต้องรู้ด้วย การแจ้งเตือนไม่ได้ช่วยให้ฉันตอบได้เร็วขึ้น แต่มันดึงความสนใจฉันออกจากสิ่งที่กำลังจะทำ
วันนี้ฉันยังไม่ได้เช็กทั้ง Discord และอีเมลเลย ถ้าฉันอยากรู้ว่าเพื่อนพิมพ์มาหรือยัง มีบิลใหม่ไหม หรือมีอะไรที่ต้องติดตามต่อ ฉันก็จะเปิดแอปนั้นแล้วจัดการเอง
ฉันวางโทรศัพท์ไว้ข้าง ๆ เป็นชั่วโมง ๆ โดยไม่เสียสมาธิได้
การสร้างนิสัยคอยเช็กเรื่องสำคัญเป็นระยะยังมีผลข้างเคียงที่ดีด้วย ระบบ เตือนความจำทางจิต ของฉันดีขึ้น เพราะพึ่งพาให้โทรศัพท์ทำแทนน้อยลง และก็ยิ่งเห็นชัดขึ้นด้วยว่าแอปกับบริการที่ฉันเช็กน้อยลงเรื่อย ๆ นั้นจริง ๆ แล้วไม่ได้สำคัญอะไรเลย
ตอนนี้ฉันมีแอปและบัญชีน้อยลงมาก แต่กลับรักษาเวลาโดยรวมได้ดีกว่าเดิม
ส่วนนี้ไม่ตรงกับข้อเท็จจริง: “การแจ้งเตือนมีอยู่แค่ในศูนย์การแจ้งเตือน และศูนย์การแจ้งเตือนก็ลบ ทิ้ง สรุป สิ่งที่ผ่านเข้ามา โดยไม่เก็บอะไรไว้อย่างเสถียรเลย”
ศูนย์การแจ้งเตือนเก็บข้อมูลไว้อย่างเสถียร มีบางอย่างคล้ายกล่องจดหมายซึ่งแม้ในฝั่งผู้ใช้จะมองไม่เห็น แต่มีอยู่จริง: https://www.forbes.com/sites/larsdaniel/2026/04/10/fbi-pulle...
“ตลอด 15 ปีที่ผ่านมา ช่องทางนี้ถูกสร้างใหม่โดยยึดสมมติฐานเดียวเป็นศูนย์กลาง ความสนใจของผู้รับเป็นทรัพยากรที่หายาก และแพลตฟอร์มมีหน้าที่ต้องปกป้องมัน … ในฐานะผู้ส่ง คุณยืนอยู่คนละฝั่งของสมมติฐานนั้น ไม่ว่าการควบคุมจะย้ายไปทางไหนก็ตาม”
น่าสนใจที่ผู้เขียนวางกรอบสถานการณ์อย่างเปิดเผยว่าเป็น ผลประโยชน์ของผู้ส่งกับผู้รับที่ขัดแย้งกัน
อุปกรณ์ที่ปกป้องความสนใจของผู้ใช้อย่างจริงจังอาจบล็อกบางอย่างที่ผู้ใช้อยากเห็นจริง ๆ ได้เป็นครั้งคราว
ถึงอย่างนั้น การแจ้งเตือนส่วนใหญ่ก็เป็นขยะและควรถูกบล็อก
“ผลกระทบทั้งหมดนี้ไม่ได้เกิดอย่างเท่าเทียมกัน การคัดกรองจะตกกับพวกพุชแบบกระจายข่าวหรือโปรโมชันหนักที่สุด ส่วนการแจ้งเตือนที่ผู้คนต้องการจริง ๆ มักจะผ่านไปได้เหมือนเดิม หรือไม่ก็ถูกขยายให้เด่นขึ้น”
สำหรับฉัน ฟังดูโอเคนะ
“ตลอดประวัติศาสตร์ของช่องทางนี้เกือบทั้งหมด แพลตฟอร์มแทบไม่ได้แทรกแซงอย่างเห็นได้ชัด แม้ในเชิงโครงสร้างจะทำได้ แต่ก็แค่เลือกที่จะไม่แทรกแซงมากนักเท่านั้น ช่วงเวลาแห่งความยับยั้งชั่งใจนั้นจบลงแล้ว”
อาจไม่ได้มองเห็นได้ชัดเสมอไป แต่ตั้งแต่แรกก็มีการแทรกแซงไม่ทางใดก็ทางหนึ่งอยู่แล้ว ใน WhatsApp เราติดตามเรื่อง การหน่วงพุช การยับยั้ง และการรวม อยู่เสมอ และถ้าจำไม่ผิด อย่างน้อยมันก็เป็นส่วนหนึ่งของระบบมาตั้งแต่ตอนที่ฉันเข้าร่วมในปี 2011
ถ้ามันทำงานได้ไม่ถูกต้องภายในระบบนั้น ข้อความของผู้ใช้ก็จะไม่ถูกส่งตรงเวลา
บางสิ่งที่เข้ามาแทนที่ การเก็บรวบรวมเมทาดาทาโทรศัพท์แบบมหาศาล ตามมาตรา 215 ของ USA PATRIOT Act ดูเหมือนจะส่งผลต่อโครงสร้างของ Apple Push Notification, Firebase Cloud Messaging และอื่น ๆ
Apple เป็นเจ้าของการเชื่อมต่อถาวรกับ iPhone ทุกเครื่อง และมีเพียง APNs เท่านั้นที่ปลุกแอปได้ ในที่นี้ “self-hosting” หมายถึงการรัน provider backend ของตนเองเพื่อตัดสินใจว่าจะส่งอะไรแล้วส่งต่อไปยัง APNs โดยไม่ฝากไว้กับบุคคลที่สามอย่าง Firebase Cloud Messaging, OneSignal หรือ Pusher แต่ช่วงสุดท้ายไม่เคยเป็นของฉันเลย
สถาปัตยกรรมที่บังคับให้ทราฟฟิกของทุกคนต้องผ่านตัวกลางจำนวนน้อยที่ระบุตัวตนได้ คือ ระบบเก็บรวบรวมเมทาดาทาแบบมหาศาล ที่โดยการออกแบบแล้วก็แค่รอเครื่องมือทางกฎหมายมาใช้งาน
ในเดือนธันวาคม 2023 วุฒิสมาชิก Ron Wyden เปิดเผยว่ารัฐบาลสหรัฐฯ และรัฐบาลต่างประเทศได้บังคับให้ Google และ Apple ส่งมอบข้อมูลการแจ้งเตือนแบบพุช เมทาดาทาการสื่อสาร และบางครั้งรวมถึงเนื้อหาอย่างลับ ๆ สิ่งที่นักพัฒนาต้องใส่ใจคือ หากต้องการส่งการแจ้งเตือนบนแพลตฟอร์มที่ iPhone และ Android พึ่งพาอยู่ ก็ไม่มีทางป้องกันแนวปฏิบัตินี้ได้
Apple ถูกสั่งห้ามเปิดเผยเรื่องนี้จนกว่าโครงการจะถูกเปิดโปง และหลังจากนั้นก็ระบุว่าจะสะท้อนคำขอประเภทนี้ในรายงานความโปร่งใสอย่างละเอียด ดังนั้นสมมติฐานเชิงโครงสร้างนี้จึงไม่ใช่การคาดเดา แต่เป็นกลไกที่ได้รับการยืนยันแล้ว และความต่างจาก Section 215 ก็มีเพียงว่าขอบเขตไม่ใช่การโทรแต่เป็นแอป และเครื่องมือทางกฎหมายไม่ใช่ทฤษฎี business records เฉพาะของ §215 แต่เป็นหมายเรียกทั่วไป คำสั่ง FISA และ NSL
คำพูดที่ว่า “มันก็แค่เมทาดาทา” สุดท้ายก็มาจากบริบทแบบนี้ แน่นอนว่านี่เป็นมุกตลก และไม่มีบุคคลใดเพียงคนเดียวที่ต้องรับผิดชอบต่อเรื่องแบบนี้ แต่มันเป็นผลของเจตจำนงทางการเมืองร่วมกัน และน่าเสียดายที่อาจเป็นสิ่งที่ดีที่สุดที่เราทำได้
https://www.youtube.com/watch?v=9iUdm0QMDM0
https://epic.org/sen-wyden-reveals-government-surveillance-o...