Web push notification: ทำงานอย่างไรและใช้ให้ได้ผลอย่างไร

Web push notification เป็นช่องทางการตลาดเดียวที่การตัดสินใจออกแบบผิดเพียงครั้งเดียวสามารถปิดประตูใส่คุณกับลูกค้าคนหนึ่งได้อย่างถาวร ขออนุญาตผิดจังหวะ ผู้เข้าชมกด Block แล้วเบราว์เซอร์นั้นก็ปิดใส่คุณตลอดไป ไม่มีการขอใหม่ ไม่มีแคมเปญที่สอง ไม่มีอีเมลชวนกลับ ความไม่สมมาตรนี้คือเหตุผลว่าทำไมกลไกของมันจึงควรค่าแก่การทำความเข้าใจก่อนที่คุณจะเขียนข้อความสักฉบับ

Web push notification คืออะไร

Web push notification คือข้อความที่ส่งจากเซิร์ฟเวอร์ของคุณไปยังเบราว์เซอร์ของผู้สมัครรับ แสดงผลโดยศูนย์การแจ้งเตือนของระบบปฏิบัติการ และส่งถึงแม้เว็บไซต์ของคุณจะปิดอยู่ ส่วนสุดท้ายนั่นคือสาระสำคัญทั้งหมด: ต่างจาก popup บนหน้าเว็บ web push เข้าถึงคนที่ตอนนี้ไม่ได้มองเว็บไซต์ของคุณอยู่

มันสร้างขึ้นจากสาม API ของแพลตฟอร์มเว็บที่ทำงานร่วมกัน และการแบ่งหน้าที่ระหว่างสามตัวนี้อธิบายพฤติกรรมส่วนใหญ่ของช่องทางนี้ได้: Service Worker API, Push API และ Notifications API

Web push ทำงานอย่างไรเบื้องหลัง

Service worker

Service worker คือ JavaScript worker ที่ทำหน้าที่เป็นตัวกลางระหว่างเว็บแอปของคุณ เบราว์เซอร์ และเครือข่าย มันรันบนเธรดของตัวเอง เข้าถึง DOM ไม่ได้ และยังคงอยู่ต่อหลังหน้าเว็บที่ลงทะเบียนมันถูกปิดไปแล้ว ความคงอยู่นั้นคือสิ่งที่ทำให้มันรับข้อความ push และแสดงการแจ้งเตือนได้ตอนที่ไม่มีใครเปิดแท็บของคุณไว้ Service worker ทำงานได้เฉพาะใน secure context เท่านั้น ซึ่งหมายถึง HTTPS โดยที่ http://localhost ถือว่าปลอดภัยสำหรับการพัฒนา

การสมัครรับ: endpoint บวกคีย์สองตัว

เมื่อ service worker ทำงานแล้ว หน้าเว็บจะเรียก registration.pushManager.subscribe() เบราว์เซอร์จะติดต่อ push service ของผู้ผลิตแล้วคืนค่า PushSubscription ที่ประกอบด้วย

• endpoint ซึ่งเป็น capability URL ที่ไม่ซ้ำกันและ push service รับข้อความผ่านมัน
• keys.p256dh ซึ่งเป็นคีย์สาธารณะแบบ Elliptic Curve Diffie-Hellman บนเส้นโค้ง P-256
• keys.auth ซึ่งเป็นความลับสำหรับยืนยันตัวตน

เซิร์ฟเวอร์ของคุณเก็บทั้งสามค่า และต้องปฏิบัติต่อ endpoint เหมือนความลับ เพราะใครก็ตามที่ถือมันไว้ส่งข้อความหาผู้สมัครรับรายนั้นได้ คีย์มีอยู่เพราะ payload ถูกเข้ารหัสแบบ end to end RFC 8291 ระบุวิธีไว้: การแลกเปลี่ยนแบบ ECDH บน P-256 สร้างความลับร่วม HKDF สร้างคีย์จากมัน แล้ว payload ถูกปิดผนึกด้วย AES-128-GCM ภายใต้การเข้ารหัสเนื้อหาแบบ aes128gcm ส่วน push service ส่งต่อเฉพาะข้อความเข้ารหัสที่มันอ่านไม่ออก

Push service

คุณไม่ได้ส่งข้อความ push ไปยังอุปกรณ์โดยตรง คุณส่งไปยัง push service ที่ดำเนินการโดยผู้ผลิตเบราว์เซอร์: endpoint ของ FCM ของ Google สำหรับ Chrome, autopush ของ Mozilla สำหรับ Firefox และ push service ของ Apple สำหรับ Safari RFC 8030 ที่ชื่อ “Generic Event Delivery Using HTTP Push” กำหนดโปรโตคอลไว้ เซิร์ฟเวอร์ของคุณ POST ไปยัง endpoint ของการสมัครรับ แล้ว push service จัดการส่วนที่ยากของการส่งบนมือถือ: การเชื่อมต่อเดียวที่ประหยัดแบตเตอรี่ไปยังอุปกรณ์ การเข้าคิวขณะออฟไลน์ และการปลุกเบราว์เซอร์เมื่อข้อความมาถึง นี่ยังเป็นเหตุผลว่าทำไมการส่งจึงรับประกันไม่ได้ หากอุปกรณ์ปิดอยู่นานพอ ข้อความจะหมดอายุตาม TTL แล้วถูกทิ้ง

VAPID: การพิสูจน์ว่าใครเป็นผู้ส่ง

การให้ endpoint เป็นความลับถือเป็นความปลอดภัยที่บาง RFC 8292 จึงเพิ่ม Voluntary Application Server Identification หรือ VAPID เข้ามา เพื่อให้ push service บอกได้ว่าข้อความมาจากเซิร์ฟเวอร์แอปพลิเคชันตัวใด

คุณสร้างคู่คีย์ ECDSA บนเส้นโค้ง NIST P-256 หนึ่งครั้ง คีย์สาธารณะไปอยู่ใน applicationServerKey ตอนที่เบราว์เซอร์สมัครรับ ซึ่งผูกการสมัครรับนั้นเข้ากับเซิร์ฟเวอร์ของคุณ ทุกครั้งที่ส่ง push เซิร์ฟเวอร์ของคุณจะส่ง JWT ที่ลงลายเซ็นด้วยคีย์ส่วนตัวที่คู่กันโดยใช้ ES256 ซึ่งบรรจุ claim aud สำหรับ origin ของ push service, claim exp ที่ไม่เกิน 24 ชั่วโมง และอาจมี claim sub พร้อมข้อมูลติดต่อ push service ตรวจสอบลายเซ็น ดังนั้นการขโมย endpoint ไปเพียงอย่างเดียวจึงไม่พอที่จะสแปมผู้สมัครรับของคุณอีกต่อไป

เส้นทางการส่ง ตั้งแต่ต้นจนจบ

1. หน้าเว็บลงทะเบียน service worker แล้วเมื่อได้รับอนุญาต จึงเรียก subscribe() พร้อมคีย์สาธารณะ VAPID ของคุณ
2. เซิร์ฟเวอร์ของคุณเก็บ endpoint และคีย์ที่ได้กลับมาไว้กับเรคคอร์ดของผู้สมัครรับ
3. เมื่อจะส่ง เซิร์ฟเวอร์ของคุณเข้ารหัส payload ด้วย p256dh และ auth ลงลายเซ็น VAPID JWT แล้ว POST ไปยัง endpoint
4. Push service ยืนยันตัวตนของคำขอแล้วส่งข้อความที่เข้ารหัสไป
5. เบราว์เซอร์ปลุก service worker ด้วยอีเวนต์ push ซึ่งถอดรหัส payload แล้วเรียก ServiceWorkerRegistration.showNotification()
6. การคลิกจุดอีเวนต์ notificationclick ใน service worker ซึ่งคุณเปิด URL ปลายทางจากตรงนั้น

ทำไมโมเดลการขออนุญาตจึงเข้มงวดนัก

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

มีข้อจำกัดที่สองที่คนมักแปลกใจ Chrome และ Edge กำหนดให้ใส่ userVisibleOnly: true ตอน subscribe ซึ่งเป็นคำสัญญาว่าทุก push จะสร้างการแจ้งเตือนที่ผู้ใช้มองเห็น การส่ง push เงียบ ๆ เบื้องหลังจึงไม่ใช่การใช้งาน API ที่รองรับ ส่วน Firefox ก็ใช้โควตากับข้อความ push ที่ไม่สร้างการแจ้งเตือน

การรองรับของเบราว์เซอร์และแพลตฟอร์ม

ตาม MDN ระบุว่า Push API อยู่ในสถานะ Baseline widely available ตั้งแต่มีนาคม 2023 หมายความว่าใช้งานได้ทั่วเวอร์ชันปัจจุบันของ Chrome, Edge, Firefox และ Safari บนเดสก์ท็อป และบน Chrome กับ Firefox สำหรับ Android มีข้อยกเว้นสองข้อที่สำคัญกว่าพาดหัว

ข้อแรก Notifications API ไม่ได้มีให้ใช้อย่างสม่ำเสมอ MDN ระบุว่าอยู่ในสถานะ limited availability เพราะ constructor Notification() โยน TypeError บนเบราว์เซอร์มือถือส่วนใหญ่ สำหรับอะไรก็ตามที่ต้องทำงานบนโทรศัพท์ ให้ใช้การแจ้งเตือนแบบคงอยู่ผ่าน ServiceWorkerRegistration.showNotification() แทน ซึ่งก็คือเส้นทาง service worker ที่คุณอยู่อยู่แล้ว

ข้อสอง ตัวเลือกของการแจ้งเตือนถูกนำไปใช้ไม่เท่ากัน ปุ่มแอ็กชัน badge รูปภาพ และ requireInteraction ต่างกันไปตามเบราว์เซอร์และระบบปฏิบัติการ จึงควรออกแบบการแจ้งเตือนให้อ่านรู้เรื่องแม้มีเพียงหัวข้อ เนื้อหา และไอคอน

ข้อกำหนดของ iOS และ iPadOS

ข้อยกเว้นนี้เป็นตัวตัดสินว่า web push ใช้ได้จริงหรือไม่กับกลุ่มเป้าหมายที่ใช้มือถือเป็นหลัก และแทบทุกที่ระบุมันไว้ผิด

Apple เพิ่ม Web Push ใน iOS และ iPadOS 16.4 และมันทำงานได้เฉพาะกับเว็บแอปที่เพิ่มลงหน้าจอโฮมแล้วเท่านั้น อย่างที่ WebKit กล่าวไว้ว่า “เรากำลังเพิ่มการรองรับ Web Push ให้กับเว็บแอปบนหน้าจอโฮม” และ “เว็บแอปที่ถูกเพิ่มลงหน้าจอโฮมแล้วสามารถขออนุญาตรับ push notification ได้” ผู้ใช้เพิ่มมันผ่านเมนู Share แล้วเลือก Add to Home Screen จากนั้นการขออนุญาตต้องเกิดจากการโต้ตอบโดยตรงของผู้ใช้ เช่นการแตะปุ่มสมัครรับ

เว็บไซต์ที่เปิดในแท็บ Safari ปกติบน iPhone สร้างการสมัครรับ push ไม่ได้ นั่นคืออุปสรรคจริง: คุณกำลังขอให้ผู้ใช้ทำขั้นตอนติดตั้งก่อนที่คุณจะขออนุญาตได้ด้วยซ้ำ บน macOS ง่ายกว่านั้น เพราะ Safari 16.1 บน macOS Ventura เพิ่ม Web Push ตามมาตรฐานสำหรับเว็บไซต์ทั่วไปโดยไม่ต้องติดตั้ง

ตัวอย่างการสมัครรับแบบย่อ

นี่คือกระบวนการฝั่งไคลเอนต์ทั้งหมด มันควรอยู่ในตัวจัดการการคลิก ไม่ใช่ตอนโหลดหน้า

async function subscribeToPush(vapidPublicKey) {
  // Push และ service worker ต้องใช้ secure context (HTTPS)
  if (!("serviceWorker" in navigator) || !("PushManager" in window)) return null;

  const registration = await navigator.serviceWorker.register("/sw.js");

  // ต้องเรียกจากการกระทำของผู้ใช้ และเรียกเพียงครั้งเดียวต่อผู้ใช้หนึ่งคน
  const permission = await Notification.requestPermission();
  if (permission !== "granted") return null;

  const subscription = await registration.pushManager.subscribe({
    userVisibleOnly: true,
    applicationServerKey: vapidPublicKey, // คีย์สาธารณะ P-256 เข้ารหัสแบบ base64url
  });

  // เก็บ endpoint และคีย์ไว้ฝั่งเซิร์ฟเวอร์ และปฏิบัติต่อ endpoint เหมือนความลับ
  await fetch("/api/push/subscribe", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(subscription),
  });

  return subscription;
}

ภายใน sw.js คุณจัดการอีเวนต์ push เรียก self.registration.showNotification(title, options) และจัดการ notificationclick เพื่อเปิด URL ปลายทาง

UX ของการขออนุญาต: จุดที่โปรแกรมส่วนใหญ่ล้มเหลว

อย่าขอตอนโหลดหน้าเด็ดขาด

Lighthouse มีการตรวจสอบเฉพาะสำหรับเรื่องนี้: “หากหน้าเว็บของคุณขออนุญาตส่งการแจ้งเตือนตอนโหลดหน้า การแจ้งเตือนเหล่านั้นอาจไม่เกี่ยวข้องกับผู้ใช้หรือความต้องการของพวกเขา” ข้อแนะนำของมันคือให้เสนอการแจ้งเตือนประเภทที่เจาะจง แล้วขออนุญาตหลังจากผู้ใช้เลือกรับประเภทนั้นแล้วเท่านั้น Safari 12.1 และเบราว์เซอร์อื่นไปไกลกว่านั้น โดยกำหนดให้ต้องมีการโต้ตอบกับหน้าเว็บก่อนจึงจะยื่นคำขอได้เลย

ใช้กล่องขอแบบนุ่มนวลนำก่อน

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

ขอในบริบทที่เหมาะสม

ข้อแนะนำของ Chrome เองคือให้ “ปล่อยให้ผู้ใช้เป็นฝ่ายเริ่มและเปิดการแจ้งเตือนตามจังหวะของตัวเอง” ด้วยการวางสวิตช์ไว้อย่างไม่รบกวนภายในส่วนต่อประสานที่มีอยู่แล้ว และหลีกเลี่ยงการ “แสดงกล่องขออนุญาตหรือ overlay โดยไม่มีบริบท หรือแสดงทันทีที่ผู้ใช้เข้ามาถึงเว็บไซต์”

จังหวะที่ได้ผลในงานคอมเมิร์ซนั้นเจาะจง: ปุ่ม “แจ้งเตือนฉันเมื่อสินค้ากลับมามีสต๊อก” บนสินค้าที่ขายหมด หน้ายืนยันคำสั่งซื้อที่เสนอการอัปเดตการจัดส่ง หรือสวิตช์เฝ้าราคาบนสินค้าที่ถูกดูบ่อย สิทธิ์นั้นถูกแลกด้วยประโยชน์ที่ระบุชื่อได้ ไม่ใช่ถูกเก็บเกี่ยวไปเฉย ๆ

การปฏิเสธถือว่าถาวรในทางปฏิบัติ

เมื่อมีคนบล็อกการแจ้งเตือน เบราว์เซอร์จะเก็บการตัดสินใจนั้นไว้สำหรับ origin ของคุณ การเรียก Notification.requestPermission() ในภายหลังจะคืนค่า denied ที่เก็บไว้โดยไม่แสดงอะไรเลย ซึ่งเป็นเหตุผลว่าทำไมตัวอย่างของ MDN เองจึงตรวจ Notification.permission ก่อนจะเรียก requestPermission() การย้อนกลับการบล็อกหมายถึงการเข้าไปขุดในการตั้งค่าเว็บไซต์ ซึ่งแทบไม่มีใครทำ

เบราว์เซอร์ทำอะไรเมื่อคุณทำผิด

ผลที่ตามมาไม่ได้มีแค่อัตราการยอมรับที่ต่ำอีกต่อไป

• Chrome จะนำ origin ที่มีอัตราการยอมรับต่ำมากเข้าสู่ UI การขออนุญาตแบบเงียบโดยอัตโนมัติ แยกตามประเภทอุปกรณ์ ซึ่งจะกดกล่องขออนุญาตสำหรับทุกคน
• Chrome จำกัดอัตราของเว็บไซต์ที่ผสมปริมาณ push สูงเข้ากับ engagement ต่ำ โดยคืน HTTP 429 การยกระดับเริ่มที่หนึ่งวัน จากนั้นเจ็ดวัน แล้วสิบสี่วัน และจะรีเซ็ตก็ต่อเมื่อผ่านไป 42 วันติดต่อกันโดยไม่มีการรบกวน
• ตอนนี้ Chrome เพิกถอนสิทธิ์การแจ้งเตือนโดยอัตโนมัติสำหรับเว็บไซต์ที่ผู้ใช้ไม่ได้โต้ตอบด้วยเมื่อเร็ว ๆ นี้ ในกรณีที่มี “engagement ของผู้ใช้ต่ำมากและมีการส่งการแจ้งเตือนในปริมาณสูง” เหตุผลของ Google ตรงไปตรงมา: “การแจ้งเตือนทั้งหมดน้อยกว่า 1% ที่ได้รับการโต้ตอบใด ๆ จากผู้ใช้”

คุณเสียผู้สมัครรับที่หามาได้แล้วไปเพียงเพราะส่งไม่ดี

Web push เทียบกับอีเมลและ SMS

ความต่างเรื่องความเป็นเจ้าของที่เปลี่ยนกลยุทธ์

การสมัครรับ push คือ capability URL ที่ผูกกับโปรไฟล์เบราว์เซอร์หนึ่งบนอุปกรณ์หนึ่งเครื่อง มันไม่ใช่คน ลูกค้าคนเดียวกันที่ใช้ Chrome บนแล็ปท็อปและ Firefox บนโทรศัพท์คือการสมัครรับสองรายการที่ไม่เกี่ยวกัน และคุณจะรู้ไม่ได้เลยว่าเป็นมนุษย์คนเดียวกัน เว้นแต่พวกเขาจะระบุตัวตนเอง

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

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

กรณีใช้งานที่ได้ผลจริง

ช่องทางนี้ให้รางวัลกับข้อความที่ไวต่อเวลา เกี่ยวข้องกับตัวบุคคล และลงมือทำได้ในแตะเดียว

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

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

ความถี่ จังหวะเวลา และการแบ่งกลุ่ม

เริ่มแบบระมัดระวัง: หนึ่งถึงสามการแจ้งเตือนต่อผู้สมัครรับหนึ่งรายต่อสัปดาห์ และขยายก็ต่อเมื่ออัตราการยกเลิกและอัตราการคลิกยังทรงตัว ความเบื่อหน่ายปรากฏเร็วกว่าในอีเมล เพราะการปิดเสียงใช้เพียงหนึ่งแตะบนการแจ้งเตือนที่ระบบปฏิบัติการแสดงให้เห็นอยู่แล้ว

จังหวะเวลาเป็นทั้งข้อได้เปรียบและอันตราย Push มาถึงทันที ข้อความที่ส่งตอน 02:00 จึงไปถึงตอน 02:00 ให้เก็บหรืออนุมานเขตเวลาของผู้สมัครรับตอนที่เขาสมัคร แล้วกักการส่งไว้ในกรอบเวลาที่กำหนด

การแบ่งกลุ่มถูกจำกัดด้วยสิ่งที่คุณรู้เกี่ยวกับการสมัครรับ ไม่ใช่เกี่ยวกับคน มิติที่ใช้ได้จริงจึงเป็นเชิงพฤติกรรม: หน้าที่ดู สินค้าที่เฝ้า สถานะตะกร้า ความใหม่ของการซื้อ และแพลตฟอร์ม คู่มือการแบ่งกลุ่มลูกค้า ลงลึกกว่านี้

การวัดผล web push

มีสี่ตัววัดที่สำคัญ และไม่ใช่ทุกตัวที่วัดได้ด้วยวิธีเดียวกัน

• การส่ง ว่า push service รับคำขอหรือไม่ รหัส 201 หมายถึงรับแล้ว ไม่ใช่ส่งถึงแล้ว ส่วน 404 หรือ 410 หมายถึงการสมัครรับนั้นตายแล้ว
• การแสดงผล ว่าการแจ้งเตือนถูกแสดงหรือไม่ คุณจะรู้ก็ต่อเมื่อ service worker รายงานกลับมาตอนที่ showNotification() ทำงานเสร็จ
• อัตราการคลิก จำนวนคลิกหารด้วยจำนวนการแสดงผล นี่คือตัวเลขที่ควรค่าแก่การปรับให้ดีขึ้น
• อัตราการยกเลิก การเลิกสมัครรับและการเพิกถอนสิทธิ์ต่อการส่งหนึ่งครั้ง เฝ้าดูมันใกล้ชิดกว่า CTR เพราะมันเป็นตัวชี้นำล่วงหน้าว่าช่องทางกำลังจะตาย

กับดักของการระบุที่มา

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

การยินยอม GDPR และการยกเลิก

กล่องขออนุญาตของเบราว์เซอร์เป็นด่านทางเทคนิค มันไม่ได้กลายเป็นฐานทางกฎหมายที่สมบูรณ์สำหรับการตลาดโดยอัตโนมัติ

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

สุขอนามัยของการยกเลิกก็สำคัญไม่แพ้กัน จัดให้มีตัวควบคุมความชอบภายในเว็บไซต์เพื่อให้คนลดความถี่ได้แทนที่จะบล็อก เรียก PushSubscription.unsubscribe() และลบเรคคอร์ดฝั่งเซิร์ฟเวอร์เมื่อพวกเขาทำเช่นนั้น และล้างการสมัครรับทิ้งเมื่อได้รหัส 404 หรือ 410 คำแนะนำของ MDN สั้นและถูกต้อง: ผู้ใช้ควร “ได้รับวิธีที่ง่ายในการเลือกไม่รับข้อความเพิ่มเติมในอนาคต”

Web push อยู่ตรงไหนในชุดช่องทาง

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

นั่นทำให้การจัดวางลำดับช่องทางเป็นปัญหาจริง ข้อความไหนไปช่องทางไหน คุณจะกดอีเมลไม่ให้ส่งอย่างไรเมื่อ push แปลงยอดไปแล้ว และคุณจะรักษามุมมองลูกค้าเดียวได้อย่างไรบนพื้นที่ที่ระบุตัวตนคนต่างกัน Brevo มี web และ mobile push ควบคู่ไปกับอีเมลและ SMS และ Tajo วางอยู่บน Brevo เพื่อประสานตรรกะข้ามช่องทางนั้นให้ร้าน Shopify สำหรับฝั่ง SMS ดู คู่มือระบบอัตโนมัติของ SMS

ประเด็นสำคัญ

• Web push คือสาม API ที่ทำงานร่วมกัน: service worker สำหรับการทำงานเบื้องหลัง Push API สำหรับการสมัครรับและการขนส่ง และ Notifications API สำหรับการแสดงผล การสมัครรับหนึ่งรายการคือ endpoint บวกคีย์ p256dh และความลับ auth ส่วน payload ถูกเข้ารหัสแบบ end to end และ VAPID พิสูจน์ตัวผู้ส่ง
• Push อยู่ในสถานะ Baseline widely available ตั้งแต่มีนาคม 2023 แต่บน iOS และ iPadOS มันทำงานได้เฉพาะกับเว็บแอปที่เพิ่มลงหน้าจอโฮมแล้ว
• อย่าขออนุญาตตอนโหลดหน้าเด็ดขาด ใช้กล่องขอแบบนุ่มนวลนำก่อน ขอในบริบทที่เหมาะสม และจำไว้ว่าการบล็อกนั้นถาวรสำหรับ origin นั้น
• ตอนนี้ Chrome บังคับใช้กล่องขออนุญาตแบบเงียบ การจำกัดอัตรา และการเพิกถอนสิทธิ์อัตโนมัติ การส่งที่แย่จึงทำให้คุณเสียผู้สมัครรับที่มีอยู่แล้ว
• การสมัครรับคือเบราว์เซอร์ ไม่ใช่คน และส่งออกไม่ได้ จงสร้างรายชื่ออีเมลก่อน แล้วใช้ push เร่งมันให้เร็วขึ้น