วิธีเพิ่มการแจ้งเตือนในแอปของคุณ: ในแอป อีเมล และ Push

การเพิ่มการแจ้งเตือนให้เว็บแอปควรเริ่มจาก การแจ้งเตือนในแอป: ตารางการแจ้งเตือนในฐานข้อมูลของคุณและไอคอนกระดิ่งที่แสดงรายการที่ยังไม่ได้อ่าน เพิ่ม อีเมล สำหรับเรื่องที่ผู้ใช้ควรรู้เมื่อไม่ได้อยู่หน้าแอป โดยใช้ผู้ให้บริการอีเมล และเพิ่ม web push เฉพาะเมื่อการแจ้งเตือนทันเวลาสำคัญจริงๆ เพราะต้องใช้ service worker การอนุญาตจากผู้ใช้ และบน iPhone ต้องบันทึกแอปลงหน้าจอโฮม ไม่ว่าคุณจะใช้ช่องทางใด ให้สร้างการแจ้งเตือนทุกอย่างจากจุดเดียวบนเซิร์ฟเวอร์ และให้ผู้ใช้เลือกว่าอยากรับอะไร

คู่มือนี้เปรียบเทียบช่องทางต่างๆ แสดงสถาปัตยกรรมแบบง่าย และให้พรอมต์ที่ใช้กับเครื่องมือสร้างแอปด้วย AI ได้

ช่องทางหลักเมื่อเปรียบเทียบกัน

แอปส่วนใหญ่ต้องการทั้งการแจ้งเตือนในแอปและอีเมล Push และ SMS คุ้มค่าเมื่อจังหวะเวลาสำคัญจริงๆ เช่น การเตือนการจอง หรือคำสั่งซื้อที่พร้อมแล้ว

ระบบการแจ้งเตือนทำงานร่วมกันอย่างไร

ให้เรียบง่ายและรวมศูนย์:

1. มีเหตุการณ์เกิดขึ้น มีการโพสต์ความคิดเห็น การชำระเงินล้มเหลว หรือการจองในวันพรุ่งนี้
2. เซิร์ฟเวอร์ของคุณเรียกฟังก์ชันเดียว เช่น notify(user, type, data)
3. ฟังก์ชันนั้นตรวจการตั้งค่าของผู้ใช้ และเขียนแถวลงตาราง notifications (สำหรับกระดิ่ง)
4. จากนั้นส่งไปยังช่องทางอื่น ที่ผู้ใช้เปิดไว้สำหรับประเภทนั้น: อีเมลผ่านผู้ให้บริการ และ push ผ่าน Push API
5. ฝั่งหน้าบ้านแสดงการแจ้งเตือนที่ยังไม่ได้อ่าน และทำเครื่องหมายว่าอ่านแล้วเมื่อเปิดดู

จุดเข้าถึงเดียวทำให้คุณเพิ่มช่องทาง เปลี่ยนข้อความ หรือเคารพการตั้งค่าได้โดยไม่ต้องไล่หาในโค้ดทั้งหมด

สิ่งที่ควรเก็บ

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

การแสดงการแจ้งเตือนใหม่

• โหลดเมื่อเปิดหน้าและ poll ทุก 30–60 วินาที ง่ายและเชื่อถือได้
• อัปเดตแบบเรียลไทม์ ด้วย WebSocket หรือ server-sent events ให้ความรู้สึกทันที แต่เพิ่มส่วนที่ต้องดูแล เริ่มด้วย polling ไว้ก่อน เว้นแต่การอัปเดตทันทีสำคัญจริงๆ

การแจ้งเตือนทางอีเมล

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

• ส่งจากเซิร์ฟเวอร์ อย่าใส่คีย์ของผู้ให้บริการในเบราว์เซอร์เด็ดขาด
• รวมเหตุการณ์ที่ถี่ๆ เข้าด้วยกัน อีเมลฉบับเดียวที่เขียนว่า "ความคิดเห็นใหม่ 3 รายการ" ดีกว่าอีเมลสามฉบับ
• เสนอสรุปรายวันหรือรายสัปดาห์ สำหรับกิจกรรมที่มีความสำคัญต่ำ
• ใส่ลิงก์ยกเลิกการรับหรือการตั้งค่า ในอีเมลที่ไม่จำเป็น กฎเกี่ยวกับอีเมลการตลาดแตกต่างกันในแต่ละประเทศ ให้ตรวจว่ากฎใดใช้กับคุณ

การแจ้งเตือนแบบ Web push

Web push ทำให้เว็บไซต์ของคุณส่งการแจ้งเตือนที่ปรากฏเหมือนการแจ้งเตือนของแอปได้ ตามเอกสาร Push API ของ MDN การทำงานเป็นดังนี้:

1. เว็บไซต์ของคุณลงทะเบียน service worker ซึ่งเป็นสคริปต์ที่เบราว์เซอร์รันอยู่เบื้องหลังได้
2. เมื่อผู้ใช้ยอมรับ service worker จะสมัครรับผ่าน PushManager.subscribe() เบราว์เซอร์จะคืน subscription ที่มี endpoint และคีย์การเข้ารหัส
3. เซิร์ฟเวอร์ของคุณเก็บ subscription นั้น และเมื่อมีเหตุการณ์เกิดขึ้น ก็ส่งข้อความไปยัง endpoint โดยปกติจะลงนามด้วยคีย์ VAPID (คู่คีย์ที่ระบุตัวเซิร์ฟเวอร์ของคุณ)
4. เบราว์เซอร์เริ่ม service worker ของคุณ ซึ่งแสดงการแจ้งเตือน แม้หน้าเว็บของคุณจะไม่ได้เปิดอยู่

MDN ยังระบุด้วยว่าควรเก็บ endpoint เป็นความลับ เพราะแค่รู้ endpoint ก็เพียงพอที่จะส่งข้อความถึงผู้ใช้คนนั้นได้

iPhone และ iPad

WebKit เพิ่ม Web Push สำหรับเว็บแอปใน iOS และ iPadOS 16.4 โดยมีสองเงื่อนไขตามประกาศของ WebKit: เว็บไซต์ต้องเพิ่มลงในหน้าจอโฮม และต้องขอสิทธิ์ เป็นการตอบสนองต่อการกระทำของผู้ใช้ เช่น การแตะปุ่มสมัครรับ ดังนั้นบน iPhone push จะถึงเฉพาะผู้ใช้ที่ติดตั้งเว็บแอปของคุณแล้ว ดู แอปเนทีฟกับโปรเกรสซีฟเว็บแอป เพื่อดูว่าการติดตั้งเว็บแอปหมายถึงอะไร

ขอสิทธิ์อย่างเหมาะสม

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

การแจ้งเตือนตามกำหนดเวลาต้องมีตัวกระตุ้น

"เตือนก่อน 24 ชั่วโมง" หรือ "สรุปรายสัปดาห์ทุกวันจันทร์" ต้องมีบางอย่างที่ทำงานตามตาราง นั่นคือปัญหาของงานเบื้องหลัง (background job) ซึ่งครอบคลุมใน วิธีรันงานเบื้องหลัง รูปแบบที่พบบ่อยคือ ตัวจัดตารางภายนอกเรียก endpoint ที่มีการป้องกันทุกไม่กี่นาที แล้ว endpoint นั้นส่งสิ่งที่ถึงกำหนดแล้ว

พรอมต์ที่ให้เครื่องมือสร้างแอปของคุณ

เริ่มด้วยการแจ้งเตือนในแอป:

เพิ่มการแจ้งเตือนในแอป สร้างตาราง notifications (user, type, title, body, link, created_at, read_at) เพิ่มฟังก์ชันฝั่งเซิร์ฟเวอร์ notify(userId, type, data) ที่ทุกฟีเจอร์เรียกใช้ แสดงไอคอนกระดิ่งในส่วนหัวพร้อมจำนวนที่ยังไม่ได้อ่าน รายการเลื่อนลงของ 20 รายการล่าสุด และปุ่ม "ทำเครื่องหมายว่าอ่านทั้งหมด" ให้ poll หาการแจ้งเตือนใหม่ทุก 60 วินาที

จากนั้นการตั้งค่าและอีเมล:

เพิ่มการตั้งค่าการแจ้งเตือน สำหรับแต่ละประเภท (การตอบความคิดเห็น การกล่าวถึง การเรียกเก็บเงิน) ให้ผู้ใช้เลือกในแอป อีเมล ทั้งสองอย่าง หรือไม่รับเลย notify() ต้องเคารพการตั้งค่าเหล่านี้ ส่งอีเมลผ่าน [PROVIDER] โดยใช้ความลับ [ENV_NAME] บนเซิร์ฟเวอร์เท่านั้น จัดกลุ่มอีเมลความคิดเห็นเพื่อให้ผู้ใช้หนึ่งคนได้รับไม่เกินหนึ่งอีเมลต่อ 15 นาที

จากนั้น push หากคุณต้องการ:

เพิ่ม web push แบบเลือกได้ ลงทะเบียน service worker สร้างคีย์ VAPID และเก็บคีย์ส่วนตัวเป็นความลับ เพิ่มปุ่ม "เปิดการแจ้งเตือน" ในการตั้งค่าที่ขอสิทธิ์เฉพาะเมื่อผู้ใช้คลิก เก็บ subscription ของแต่ละผู้ใช้และแต่ละอุปกรณ์ ส่ง push จาก notify() เมื่อผู้ใช้เลือกรับ และลบ subscription ที่บริการ push รายงานว่าหมดอายุแล้ว

ข้อผิดพลาดที่พบบ่อย

• การแจ้งเตือนกระจัดกระจายไปทั่วโค้ด แต่ละฟีเจอร์ส่งอีเมลของตัวเองแบบต่างกัน และการตั้งค่าถูกละเลย ให้ใช้ฟังก์ชัน notify() เดียว
• ขอสิทธิ์ push ตอนโหลดหน้า คนส่วนใหญ่จะปฏิเสธ และคุณอาจไม่ได้โอกาสอีกครั้ง
• ไม่มีการตั้งค่า ผู้ใช้ที่ปิดการแจ้งเตือนที่รบกวนไม่ได้จะปิดทั้งหมด หรือไม่ก็จากไป
• ส่งจากเบราว์เซอร์ คีย์ของอีเมลและ push ต้องอยู่บนเซิร์ฟเวอร์
• ไม่ลบ push subscription ที่ใช้ไม่ได้แล้ว subscription ที่หมดอายุจะสะสมและเสียการส่ง
• รายละเอียดที่ละเอียดอ่อนในข้อความแจ้งเตือน หน้าจอล็อกจะแสดงข้อความนั้น "คุณมีข้อความใหม่" ปลอดภัยกว่าการแสดงตัวข้อความเอง
• ไม่มีบันทึกว่าส่งอะไรไปแล้ว เมื่อผู้ใช้บอกว่า "ฉันไม่ได้รับอีเมลเลย" บันทึกพร้อม ID ข้อความของผู้ให้บริการจะช่วยให้คุณหาสาเหตุได้

เช็กลิสต์

• ฟังก์ชัน notify() ฝั่งเซิร์ฟเวอร์ตัวเดียวถูกใช้ทุกที่
• ตารางการแจ้งเตือนพร้อมสถานะการอ่าน และกระดิ่งพร้อมจำนวนที่ยังไม่ได้อ่าน
• การตั้งค่าช่องทางต่อประเภท ซึ่ง notify() เคารพ
• อีเมลส่งจากเซิร์ฟเวอร์พร้อมโดเมนที่ยืนยันแล้ว มีการสรุปหรือการจัดกลุ่มสำหรับเหตุการณ์ที่ถี่
• ขอสิทธิ์ push เฉพาะหลังการกระทำของผู้ใช้ พร้อมคำอธิบาย
• ทดสอบ push บนเดสก์ท็อปและบน iPhone ที่เพิ่มแอปลงหน้าจอโฮมแล้ว
• ลบ push subscription ที่หมดอายุแล้ว
• ไม่มีเนื้อหาที่ละเอียดอ่อนในตัวอย่างของ push หรืออีเมล
• การเตือนตามกำหนดเวลามีตัวกระตุ้นที่เชื่อถือได้

การแจ้งเตือนบน Mythex

Mythex ไม่มีบริการอีเมลหรือ push ในตัวสำหรับแอปที่คุณสร้าง ดังนั้นคุณนำผู้ให้บริการอีเมลของคุณเอง และสร้างคีย์ push ของคุณเอง เก็บเป็นความลับของโปรเจกต์ ส่วนการแจ้งเตือนในแอปต้องใช้เพียงฐานข้อมูลของโปรเจกต์ ซึ่ง Mythex เพิ่มให้เมื่อคุณขอ ใช้พรอมต์เหมือนด้านบนในการสร้าง ทดสอบกระดิ่งและอีเมลใน Preview และทดสอบ push บน URL ที่เผยแพร่แล้ว เพราะ service worker และ push ต้องใช้ที่อยู่ HTTPS จริง สูตรในเอกสาร ส่งอีเมลจากแอปของคุณ มีพรอมต์เริ่มต้น Mythex ไม่ได้บันทึกงานตามกำหนดเวลาไว้ในเอกสาร ดังนั้นวางแผนการเตือนตามเวลาด้วยตัวกระตุ้นภายนอก ตามที่อธิบายใน วิธีรันงานเบื้องหลัง

คำถาม