Thông báo đẩy trên web: cách hoạt động và cách dùng cho hiệu quả

Thông báo đẩy trên web là kênh marketing duy nhất mà chỉ một quyết định thiết kế tệ cũng có thể khóa bạn khỏi một khách hàng vĩnh viễn. Xin quyền sai thời điểm, khách nhấn Chặn, và trình duyệt đó đóng cửa với bạn mãi mãi. Không hỏi lại, không chiến dịch thứ hai, không email win-back. Chính sự bất đối xứng đó khiến bạn nên hiểu cơ chế trước khi viết một tin nhắn nào.

Thông báo đẩy trên web là gì

Thông báo đẩy trên web là một tin nhắn gửi từ máy chủ của bạn tới trình duyệt của người đăng ký, được trung tâm thông báo của hệ điều hành hiển thị, và được chuyển đi ngay cả khi trang web của bạn đã đóng. Vế cuối mới là điểm mấu chốt: khác với popup trên trang, web push tiếp cận được người đang không nhìn vào website của bạn.

Nó được dựng từ ba API nền tảng web phối hợp với nhau, và cách phân chia giữa chúng giải thích phần lớn hành vi của kênh này: Service Worker API, Push API và Notifications API.

Cách web push hoạt động bên dưới

Service worker

Service worker là một worker JavaScript đóng vai trò proxy giữa web app, trình duyệt và mạng. Nó chạy trên luồng riêng, không truy cập được DOM, và vẫn tồn tại sau khi trang đã đăng ký nó bị đóng. Chính tính bền bỉ đó cho phép nó nhận tin nhắn đẩy và hiển thị thông báo khi không ai đang mở tab của bạn. Service worker chỉ chạy trong ngữ cảnh bảo mật, tức là HTTPS, với http://localhost được coi là an toàn khi phát triển.

Subscription: một endpoint và hai khóa

Khi service worker đã hoạt động, trang gọi registration.pushManager.subscribe(). Trình duyệt trao đổi với dịch vụ đẩy của nhà cung cấp và trả về một đối tượng PushSubscription chứa:

• endpoint, một URL năng lực duy nhất mà dịch vụ đẩy nhận tin nhắn trên đó
• keys.p256dh, khóa công khai Elliptic Curve Diffie-Hellman trên đường cong P-256
• keys.auth, một bí mật xác thực

Máy chủ của bạn lưu cả ba và coi endpoint như một bí mật, vì bất kỳ ai giữ nó cũng gửi được tới người đăng ký đó. Các khóa tồn tại vì payload được mã hóa đầu cuối. RFC 8291 quy định cách làm: một trao đổi ECDH trên P-256 thiết lập bí mật chung, HKDF dẫn xuất khóa từ đó, và payload được niêm phong bằng AES-128-GCM theo content encoding aes128gcm. Dịch vụ đẩy chỉ chuyển tiếp bản mã mà nó không đọc được.

Dịch vụ đẩy

Bạn không gửi tin nhắn đẩy trực tiếp tới thiết bị. Bạn gửi tới một dịch vụ đẩy do nhà cung cấp trình duyệt vận hành: các endpoint FCM của Google cho Chrome, autopush của Mozilla cho Firefox, dịch vụ đẩy của Apple cho Safari. RFC 8030, “Generic Event Delivery Using HTTP Push”, định nghĩa giao thức này. Máy chủ của bạn gửi POST tới endpoint của subscription, còn dịch vụ đẩy lo phần khó của việc phân phối trên di động: một kết nối tiết kiệm pin tới thiết bị, xếp hàng khi ngoại tuyến, đánh thức trình duyệt khi có tin nhắn. Đây cũng là lý do không thể bảo đảm việc gửi đến nơi. Nếu thiết bị tắt đủ lâu, tin nhắn hết hạn theo TTL và bị loại bỏ.

VAPID: chứng minh ai là người gửi

Việc coi endpoint là bí mật vẫn là lớp bảo vệ mỏng. RFC 8292 bổ sung Voluntary Application Server Identification, gọi tắt là VAPID, để dịch vụ đẩy biết tin nhắn đến từ máy chủ ứng dụng nào.

Bạn tạo một cặp khóa ECDSA trên đường cong NIST P-256 một lần duy nhất. Khóa công khai được đưa vào applicationServerKey khi trình duyệt đăng ký, gắn subscription với máy chủ của bạn. Với mỗi lần đẩy, máy chủ gửi một JWT ký bằng khóa riêng tương ứng theo ES256, mang claim aud là origin của dịch vụ đẩy, claim exp không quá 24 giờ, và tùy chọn claim sub chứa thông tin liên hệ. Dịch vụ đẩy xác minh chữ ký, nên chỉ một endpoint bị đánh cắp thì không còn đủ để gửi rác cho người đăng ký của bạn.

Đường đi của thông báo, từ đầu đến cuối

1. Trang đăng ký service worker và, sau khi quyền được cấp, gọi subscribe() với khóa công khai VAPID của bạn.
2. Máy chủ lưu endpoint và các khóa trả về vào bản ghi người đăng ký.
3. Khi gửi, máy chủ mã hóa payload bằng p256dh và auth, ký một JWT VAPID, rồi POST tới endpoint.
4. Dịch vụ đẩy xác thực yêu cầu và chuyển tin nhắn đã mã hóa đi.
5. Trình duyệt đánh thức service worker bằng sự kiện push, service worker giải mã payload và gọi ServiceWorkerRegistration.showNotification().
6. Một cú nhấp kích hoạt notificationclick trong service worker, nơi bạn mở URL đích.

Vì sao mô hình quyền lại nghiêm ngặt đến vậy

Hãy nhìn vào thứ mà một subscription trao đi: một tiến trình nền chạy khi trang của bạn không hề mở, cộng với khả năng vẽ lên bề mặt thông báo của hệ điều hành. Vì thế trình duyệt đặt nó sau một quyền rõ ràng, theo từng origin, do người dùng cấp, và phần lớn còn yêu cầu lời yêu cầu phải theo sau một thao tác thật của người dùng.

Một ràng buộc thứ hai khiến nhiều người bất ngờ. Chrome và Edge yêu cầu userVisibleOnly: true khi subscribe, tức là một cam kết rằng mọi lần đẩy đều tạo ra một thông báo mà người dùng nhìn thấy, nên đẩy nền im lặng không phải là cách dùng được hỗ trợ. Firefox cũng áp hạn mức cho các tin nhắn đẩy không tạo ra thông báo.

Hỗ trợ trình duyệt và nền tảng

Theo MDN, Push API đã đạt trạng thái Baseline khả dụng rộng rãi từ tháng 3 năm 2023, nghĩa là nó chạy trên các phiên bản hiện hành của Chrome, Edge, Firefox và Safari trên máy tính, cùng Chrome và Firefox trên Android. Có hai lưu ý quan trọng hơn cả dòng tiêu đề đó.

Thứ nhất, Notifications API không khả dụng đồng đều. MDN đánh dấu nó là khả dụng hạn chế vì hàm khởi tạo Notification() ném lỗi TypeError trên hầu hết trình duyệt di động. Với bất cứ thứ gì phải chạy trên điện thoại, hãy dùng thông báo bền vững qua ServiceWorkerRegistration.showNotification(), vốn cũng chính là hướng service worker mà bạn đang đi.

Thứ hai, các tùy chọn thông báo được hiện thực không đồng đều. Nút hành động, huy hiệu, hình ảnh và requireInteraction khác nhau giữa các trình duyệt và hệ điều hành, nên hãy thiết kế thông báo vẫn đọc đúng khi chỉ có tiêu đề, phần thân và một biểu tượng.

Yêu cầu riêng của iOS và iPadOS

Lưu ý này quyết định web push có khả thi hay không với tệp đối tượng nghiêng về di động, và gần như ở đâu người ta cũng nói sai.

Apple bổ sung Web Push từ iOS và iPadOS 16.4, và nó chỉ chạy với web app đã được thêm vào Màn hình chính. Theo cách WebKit diễn đạt, “chúng tôi đang bổ sung hỗ trợ Web Push cho web app trên Màn hình chính”, và “một web app đã được thêm vào Màn hình chính có thể xin quyền nhận thông báo đẩy”. Người dùng thêm nó qua menu Chia sẻ và “Thêm vào Màn hình chính”, sau đó quyền phải được yêu cầu ngay sau một thao tác trực tiếp, chẳng hạn nhấn vào nút đăng ký nhận thông báo.

Một trang web mở trong tab Safari thông thường trên iPhone không thể tạo subscription push. Đó là rào cản thật: bạn đang yêu cầu một bước cài đặt trước khi thậm chí được phép xin quyền. Trên macOS thì dễ hơn, vì Safari 16.1 trên macOS Ventura đã đưa Web Push theo chuẩn vào các website thông thường mà không cần bước cài đặt nào.

Ví dụ đăng ký tối giản

Đây là toàn bộ luồng phía client. Nó thuộc về một trình xử lý sự kiện nhấp, không phải lúc tải trang.

async function subscribeToPush(vapidPublicKey) {
  // Push và service worker yêu cầu ngữ cảnh bảo mật (HTTPS).
  if (!("serviceWorker" in navigator) || !("PushManager" in window)) return null;

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

  // Phải được gọi từ một thao tác của người dùng, và chỉ một lần cho mỗi người.
  const permission = await Notification.requestPermission();
  if (permission !== "granted") return null;

  const subscription = await registration.pushManager.subscribe({
    userVisibleOnly: true,
    applicationServerKey: vapidPublicKey, // khóa công khai P-256 mã hóa base64url
  });

  // Lưu endpoint + khóa ở phía máy chủ; coi endpoint như một bí mật.
  await fetch("/api/push/subscribe", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(subscription),
  });

  return subscription;
}

Bên trong sw.js, bạn xử lý sự kiện push, gọi self.registration.showNotification(title, options), và xử lý notificationclick để mở URL đích.

Trải nghiệm xin quyền: nơi phần lớn chương trình thất bại

Đừng bao giờ hỏi lúc tải trang

Lighthouse có hẳn một mục kiểm tra riêng cho việc này: “nếu trang của bạn xin quyền gửi thông báo ngay khi tải trang, những thông báo đó có thể không liên quan tới người dùng hoặc nhu cầu của họ”. Khuyến nghị của nó là hãy đề xuất một loại thông báo cụ thể và chỉ xin quyền sau khi người dùng chọn nhận loại đó. Safari 12.1 và một số trình duyệt khác còn đi xa hơn, bắt buộc phải có tương tác với trang trước khi được phép gửi yêu cầu.

Dùng lời mời mềm trước

Hãy hiển thị lời mời của chính bạn ngay trên trang trước đã. Nó nêu rõ giá trị nhận được, có thể bị bỏ qua mà không mất mát vĩnh viễn, và chỉ khi người dùng nhấp vào thì lời nhắc thật của trình duyệt mới bật lên. Người bỏ qua lời mời mềm hôm nay vẫn có thể được hỏi lại vào tháng sau. Người nhấn Chặn thì không. Hai nguyên tắc làm nó hiệu quả: mô tả đúng thứ bạn sẽ gửi thay vì “nhận thông tin mới nhất”, và đừng bao giờ dàn dựng để người ta nhấp nhầm, vì một cú chấp nhận do nhầm sẽ dẫn tới hủy nhận ngay lập tức.

Hỏi đúng ngữ cảnh

Chính Chrome khuyến nghị hãy “để người dùng chủ động và tự bật thông báo theo nhịp của họ” bằng cách đặt các nút bật tắt một cách kín đáo trong các bề mặt giao diện sẵn có, và tránh “hiển thị lời nhắc hoặc lớp phủ khi không có ngữ cảnh, hoặc ngay khi người dùng vừa vào trang”.

Những khoảnh khắc hiệu quả trong thương mại điện tử rất cụ thể: nút “báo cho tôi khi có hàng lại” trên một sản phẩm đã hết, trang xác nhận đơn hàng đề nghị cập nhật giao hàng, nút theo dõi giá trên một sản phẩm được xem thường xuyên. Quyền được đánh đổi lấy một lợi ích có tên, chứ không bị thu gom.

Từ chối gần như là vĩnh viễn

Khi ai đó chặn thông báo, trình duyệt lưu quyết định ấy cho origin của bạn. Các lần gọi Notification.requestPermission() sau đó trả về giá trị denied đã lưu mà không hiển thị gì, và đó là lý do chính ví dụ của MDN kiểm tra Notification.permission trước khi gọi requestPermission(). Muốn gỡ chặn thì phải lục vào cài đặt trang, việc mà trên thực tế không ai làm.

Trình duyệt làm gì khi bạn làm sai

Hậu quả bây giờ không còn chỉ là tỷ lệ đồng ý thấp.

• Chrome tự động đưa các origin có tỷ lệ chấp nhận rất thấp vào giao diện xin quyền im lặng hơn, tính riêng theo loại thiết bị, khiến lời nhắc bị chặn với tất cả mọi người.
• Chrome giới hạn tần suất với các trang vừa gửi nhiều vừa có tương tác thấp, trả về HTTP 429. Mức phạt leo thang một ngày, rồi bảy ngày, rồi mười bốn ngày, chỉ đặt lại sau 42 ngày liên tiếp không gây phiền.
• Chrome hiện tự động thu hồi quyền thông báo với các trang mà người dùng gần đây không tương tác, khi có “mức tương tác của người dùng rất thấp và khối lượng thông báo được gửi rất lớn”. Lý do Google đưa ra rất phũ phàng: “Chưa tới 1% tổng số thông báo nhận được bất kỳ tương tác nào từ người dùng.”

Bạn có thể mất chính những người đăng ký đã giành được, chỉ vì gửi tệ.

So sánh web push với email và SMS

Khác biệt về quyền sở hữu làm thay đổi chiến lược

Một subscription push là một URL năng lực gắn với một hồ sơ trình duyệt trên một thiết bị. Nó không phải là một con người. Cùng một khách hàng dùng Chrome trên laptop và Firefox trên điện thoại là hai subscription không liên quan gì đến nhau, và bạn không thể biết đó là cùng một người trừ khi họ tự định danh.

Nó cũng không mang đi được. Bạn có thể xuất danh sách email và nạp vào một nền tảng khác ngay ngày mai. Bạn không thể chuyển subscription push giữa các nhà cung cấp, vì các khóa và ràng buộc VAPID đã được tạo ra dựa trên một khóa máy chủ ứng dụng cụ thể.

Vì vậy hãy coi web push là chất xúc tác cho một kênh bạn sở hữu, đừng bao giờ coi nó là vật thay thế. Hãy dùng khoảnh khắc push để lấy được một địa chỉ email hoặc số điện thoại, chứ không phải chiều ngược lại. Bài hướng dẫn toàn diện về marketing automation nói về việc nối nhiều kênh vào cùng một hành trình.

Những tình huống thực sự hiệu quả

Kênh này thưởng cho những tin nhắn nhạy về thời gian, liên quan trực tiếp tới cá nhân và có thể hành động chỉ trong một chạm.

• Bỏ giỏ hàng. Một thông báo đẩy trong vòng một giờ, được củng cố bằng email sau đó. Bài hướng dẫn email bỏ giỏ hàng nói kỹ về trình tự gửi.
• Cảnh báo có hàng trở lại. Trường hợp mạnh nhất, vì chính người dùng đã chủ động xin được báo.
• Giảm giá sản phẩm đang theo dõi. Cùng một logic, mức độ liên quan do người dùng tự chọn.
• Trạng thái đơn hàng và giao hàng. Ý định mở cao, rủi ro khiếu nại thấp.
• Tin nóng trong chủ đề đã đăng ký. Tin tức, kết quả, khung giờ mở bán.

Những thứ thất bại cũng rõ ràng không kém: thông báo chung chung kiểu “chúng tôi vừa đăng bài mới”, khuyến mãi hằng ngày không phân biệt, bất cứ nội dung nào cần nhiều hơn một tiêu đề và một dòng, các đợt gửi lại hàng loạt tới người đã phớt lờ hai mươi thông báo gần nhất, và nội dung giao dịch cần một bản ghi lưu lâu dài.

Tần suất, thời điểm và phân nhóm

Hãy bắt đầu thận trọng: một tới ba thông báo cho mỗi người đăng ký mỗi tuần, chỉ tăng nếu tỷ lệ hủy nhận và tỷ lệ nhấp giữ vững. Sự mệt mỏi xuất hiện nhanh hơn so với email, vì tắt tiếng chỉ tốn một chạm ngay trên thông báo mà hệ điều hành vừa hiển thị.

Thời điểm vừa là lợi thế vừa là hiểm họa. Push đến ngay lập tức, nên tin gửi lúc 02:00 sẽ đến lúc 02:00. Hãy lưu hoặc suy ra múi giờ của người đăng ký ngay khi họ đăng ký và giữ các lần gửi nằm trong một khung giờ đã định.

Phân nhóm bị giới hạn bởi những gì bạn biết về một subscription chứ không phải về một con người, nên các chiều khả dụng đều mang tính hành vi: trang đã xem, sản phẩm đang theo dõi, trạng thái giỏ hàng, thời gian mua gần nhất, nền tảng. Bài hướng dẫn phân khúc khách hàng đi sâu hơn.

Đo lường web push

Có bốn chỉ số quan trọng, và chúng không đo được theo cùng một cách.

• Gửi đi. Dịch vụ đẩy có chấp nhận yêu cầu hay không. Mã 201 nghĩa là đã chấp nhận, không phải đã đến nơi. Mã 404 hoặc 410 nghĩa là subscription đã chết.
• Hiển thị. Thông báo có được hiện lên hay không. Bạn chỉ biết điều này nếu service worker báo lại khi showNotification() hoàn tất.
• Tỷ lệ nhấp. Số lần nhấp chia cho số lần hiển thị. Đây là con số đáng tối ưu.
• Tỷ lệ hủy nhận. Số lượt hủy đăng ký và thu hồi quyền trên mỗi lần gửi. Hãy theo dõi nó sát hơn cả tỷ lệ nhấp, vì đó là chỉ báo sớm cho cái chết của kênh.

Cạm bẫy khi quy kết chuyển đổi

Việc quy kết cho push thường tự tâng bốc. Thông báo đến trên một thiết bị người đăng ký đang cầm trên tay, nên nó hay nhận công cho một phiên truy cập vốn dĩ vẫn sẽ xảy ra. Hãy chạy nhóm đối chứng thay vì mặc định cho rằng có tác động tăng thêm. Số lượt hiển thị bị đếm thiếu trong khi mọi cú nhấp đều được ghi nhận, nên tỷ lệ nhấp tính trên số lượt gửi sẽ thổi phồng hiệu quả. Và vì một subscription là một trình duyệt chứ không phải một con người, một cú nhấp trên điện thoại dẫn tới đơn hàng trên máy tính sẽ trông như hai sự kiện không liên quan. Bài hướng dẫn chỉ số email marketing nói về vệ sinh đo lường xuyên kênh.

Sự đồng ý, GDPR và hủy nhận

Lời nhắc quyền của trình duyệt là một rào kỹ thuật. Nó không mặc nhiên là cơ sở pháp lý đầy đủ cho hoạt động marketing.

Khi bạn làm marketing tới người ở EU hoặc Anh, hãy đối xử với push như với email. Giải thích bạn sẽ gửi gì trước khi lời nhắc xuất hiện, để sự đồng ý là có hiểu biết và cụ thể. Ghi lại thời điểm và nơi subscription được tạo, và đừng bao giờ gộp sự đồng ý nhận push vào một hành động không liên quan. Nếu bạn gắn subscription với khách hàng đã định danh, dữ liệu đó nằm trong nghĩa vụ về dữ liệu cá nhân của bạn, bao gồm cả yêu cầu xóa.

Vệ sinh phần hủy nhận cũng quan trọng không kém. Hãy cung cấp một trang tùy chọn ngay trên site để người ta giảm tần suất thay vì chặn hẳn, gọi PushSubscription.unsubscribe() và xóa bản ghi ở phía máy chủ khi họ làm vậy, và dọn các subscription trả về 404 hoặc 410. Hướng dẫn của MDN ngắn gọn và chính xác: người dùng cần được “trao một cách dễ dàng để từ chối nhận thêm về sau”.

Vị trí của web push trong hệ thống kênh

Web push là kênh thứ ba tốt và là kênh đầu tiên tệ: nhanh, gần như miễn phí ở mức biên và không kênh nào sánh được về cảnh báo gấp, nhưng gắn với thiết bị, không xuất được và chỉ cách việc mất trắng đúng một cú nhấp.

Vì thế bài toán thật sự là điều phối. Tin nào đi kênh nào, làm sao chặn email khi push đã chuyển đổi rồi, và làm sao giữ một cái nhìn duy nhất về khách hàng trên các bề mặt định danh con người theo cách khác nhau. Brevo cung cấp push cho web và di động bên cạnh email và SMS, còn Tajo nằm trên Brevo để điều phối logic đa kênh đó cho các cửa hàng Shopify. Về phần SMS, hãy xem hướng dẫn tự động hóa SMS.

Điểm chính cần nhớ

• Web push là ba API phối hợp: service worker để chạy nền, Push API để đăng ký và vận chuyển, Notifications API để hiển thị. Một subscription gồm một endpoint cộng khóa p256dh và bí mật auth, payload được mã hóa đầu cuối, và VAPID chứng minh người gửi.
• Push đã đạt Baseline khả dụng rộng rãi từ tháng 3 năm 2023, nhưng trên iOS và iPadOS nó chỉ chạy với web app đã thêm vào Màn hình chính.
• Đừng bao giờ xin quyền lúc tải trang. Hãy dùng lời mời mềm, hỏi đúng ngữ cảnh, và nhớ rằng một lần bị chặn là vĩnh viễn với origin đó.
• Chrome hiện áp lời nhắc im lặng hơn, giới hạn tần suất và tự động thu hồi quyền, nên gửi tệ khiến bạn mất chính những người đăng ký đang có.
• Một subscription là một trình duyệt chứ không phải một con người, và không thể xuất ra. Hãy dựng danh sách email trước rồi dùng push để tăng tốc nó.