वेब पुश नोटिफ़िकेशन: ये कैसे काम करते हैं और इन्हें अच्छे से कैसे इस्तेमाल करें

वेब पुश नोटिफ़िकेशन इकलौता ऐसा मार्केटिंग चैनल है जहाँ एक ग़लत डिज़ाइन फ़ैसला आपको किसी ग्राहक से हमेशा के लिए अलग कर सकता है. ग़लत पल पर परमिशन माँगिए, विज़िटर Block दबा देता है, और वह ब्राउज़र आपके लिए हमेशा के लिए बंद हो जाता है. न दोबारा पूछना, न दूसरा कैम्पेन, न कोई विन-बैक email. यही असंतुलन इस बात की वजह है कि एक भी संदेश लिखने से पहले इस तंत्र को समझना ज़रूरी है.

वेब पुश नोटिफ़िकेशन होते क्या हैं

वेब पुश नोटिफ़िकेशन आपके सर्वर से किसी सब्सक्राइबर के ब्राउज़र को भेजा गया संदेश है, जिसे ऑपरेटिंग सिस्टम का नोटिफ़िकेशन सेंटर दिखाता है, और जो आपकी साइट बंद होने पर भी पहुँचता है. यही आख़िरी हिस्सा पूरा मक़सद है: ऑन-पेज पॉपअप के उलट, वेब पुश उस व्यक्ति तक पहुँचता है जो इस समय आपकी वेबसाइट नहीं देख रहा.

यह तीन वेब प्लेटफ़ॉर्म API के साथ मिलकर काम करने से बनता है, और इनके बीच का बँटवारा इस चैनल के ज़्यादातर व्यवहार को समझा देता है: Service Worker API, Push API, और Notifications API.

वेब पुश भीतर से कैसे काम करता है

सर्विस वर्कर

सर्विस वर्कर एक JavaScript वर्कर है जो आपके वेब ऐप, ब्राउज़र और नेटवर्क के बीच प्रॉक्सी की तरह काम करता है. यह अपने अलग थ्रेड पर चलता है, इसकी DOM तक पहुँच नहीं होती, और इसे रजिस्टर करने वाला पेज बंद होने के बाद भी यह मौजूद रहता है. यही टिकाऊपन इसे तब पुश संदेश पाने और नोटिफ़िकेशन दिखाने देता है जब किसी ने आपका टैब खोला ही न हो. सर्विस वर्कर केवल सुरक्षित कॉन्टेक्स्ट में चलते हैं, यानी HTTPS, जिसमें डेवलपमेंट के लिए http://localhost को सुरक्षित माना जाता है.

सब्सक्रिप्शन: एक एंडपॉइंट और दो कीज़

सर्विस वर्कर सक्रिय होने के बाद पेज registration.pushManager.subscribe() कॉल करता है. ब्राउज़र अपने वेंडर की पुश सर्विस से बात करता है और एक PushSubscription लौटाता है जिसमें होता है:

• endpoint, एक विशिष्ट कैपेबिलिटी URL जिस पर पुश सर्विस संदेश स्वीकार करती है
• keys.p256dh, P-256 कर्व पर एक Elliptic Curve Diffie-Hellman पब्लिक की
• keys.auth, एक ऑथेंटिकेशन सीक्रेट

आपका सर्वर तीनों को स्टोर करता है और एंडपॉइंट को सीक्रेट की तरह मानता है, क्योंकि जिसके पास वह है वह उस सब्सक्राइबर को संदेश भेज सकता है. कीज़ इसलिए हैं क्योंकि पेलोड एंड टू एंड एन्क्रिप्टेड होते हैं. RFC 8291 बताता है कैसे: P-256 पर ECDH एक्सचेंज एक साझा सीक्रेट बनाता है, HKDF उससे कीज़ निकालता है, और पेलोड को aes128gcm कंटेंट एन्कोडिंग के तहत AES-128-GCM से सील किया जाता है. पुश सर्विस वही सिफ़र टेक्स्ट आगे बढ़ाती है जिसे वह पढ़ नहीं सकती.

पुश सर्विस

आप पुश संदेश सीधे किसी डिवाइस को नहीं भेजते. आप उन्हें ब्राउज़र वेंडर की चलाई हुई पुश सर्विस को भेजते हैं: Chrome के लिए Google के FCM एंडपॉइंट, Firefox के लिए Mozilla का autopush, Safari के लिए Apple की पुश सर्विस. RFC 8030, “Generic Event Delivery Using HTTP Push”, इस प्रोटोकॉल को परिभाषित करता है. आपका सर्वर सब्सक्रिप्शन एंडपॉइंट पर POST करता है, और पुश सर्विस मोबाइल डिलीवरी के मुश्किल हिस्से संभालती है: डिवाइस से एक बैटरी-कुशल कनेक्शन, ऑफ़लाइन होने पर क़तार, और संदेश आने पर ब्राउज़र को जगाना. इसीलिए डिलीवरी की गारंटी नहीं दी जा सकती. अगर डिवाइस काफ़ी देर तक बंद रहे, तो संदेश अपने TTL के अनुसार समाप्त होकर छोड़ दिए जाते हैं.

VAPID: यह साबित करना कि भेज कौन रहा है

एंडपॉइंट का सीक्रेट होना कमज़ोर सुरक्षा है. RFC 8292 इसमें Voluntary Application Server Identification यानी VAPID जोड़ता है, ताकि पुश सर्विस बता सके कि संदेश किस एप्लिकेशन सर्वर से आया.

आप NIST P-256 कर्व पर एक बार ECDSA की जोड़ी बनाते हैं. पब्लिक की ब्राउज़र के सब्सक्राइब करते समय applicationServerKey में जाती है, जो सब्सक्रिप्शन को आपके सर्वर से बाँध देती है. हर पुश के लिए आपका सर्वर ES256 से उस प्राइवेट की द्वारा साइन किया गया JWT भेजता है, जिसमें पुश सर्विस ओरिजिन के लिए aud क्लेम, अधिकतम 24 घंटे आगे का exp क्लेम, और वैकल्पिक रूप से संपर्क जानकारी वाला sub क्लेम होता है. पुश सर्विस सिग्नेचर सत्यापित करती है, इसलिए चोरी हुआ एंडपॉइंट अकेले आपके सब्सक्राइबर्स को स्पैम करने के लिए काफ़ी नहीं रह जाता.

डिलीवरी का पूरा रास्ता

1. पेज सर्विस वर्कर रजिस्टर करता है और परमिशन मिलने के बाद आपकी VAPID पब्लिक की के साथ subscribe() कॉल करता है.
2. आपका सर्वर लौटे हुए एंडपॉइंट और कीज़ को सब्सक्राइबर रिकॉर्ड के साथ स्टोर करता है.
3. भेजने के लिए आपका सर्वर पेलोड को p256dh और auth से एन्क्रिप्ट करता है, एक VAPID JWT साइन करता है, और एंडपॉइंट पर POST करता है.
4. पुश सर्विस रिक्वेस्ट को ऑथेंटिकेट करती है और एन्क्रिप्टेड संदेश पहुँचाती है.
5. ब्राउज़र सर्विस वर्कर को push इवेंट के साथ जगाता है, जो पेलोड डिक्रिप्ट करके ServiceWorkerRegistration.showNotification() कॉल करता है.
6. क्लिक होने पर सर्विस वर्कर में notificationclick चलता है, जहाँ आप गंतव्य URL खोलते हैं.

परमिशन मॉडल इतना सख़्त क्यों है

देखिए कि सब्सक्रिप्शन क्या देता है: एक बैकग्राउंड प्रोसेस जो आपकी साइट खुले बिना चलती है, साथ ही ऑपरेटिंग सिस्टम की नोटिफ़िकेशन सतह पर लिखने की क्षमता. इसीलिए ब्राउज़र इसे स्पष्ट, प्रति-ओरिजिन, उपयोगकर्ता द्वारा दी गई परमिशन के पीछे रखते हैं, और ज़्यादातर यह माँगते हैं कि रिक्वेस्ट किसी असली उपयोगकर्ता क्रिया के बाद ही आए.

एक दूसरी बाध्यता लोगों को चौंकाती है. Chrome और Edge सब्सक्राइब पर userVisibleOnly: true माँगते हैं, यानी यह वादा कि हर पुश उपयोगकर्ता को दिखने वाला नोटिफ़िकेशन बनाएगा, इसलिए ख़ामोश बैकग्राउंड पुश इस API का समर्थित उपयोग नहीं है. Firefox भी उन पुश संदेशों पर कोटा लगाता है जो कोई नोटिफ़िकेशन नहीं बनाते.

ब्राउज़र और प्लेटफ़ॉर्म सपोर्ट

MDN के अनुसार Push API मार्च 2023 से Baseline में व्यापक रूप से उपलब्ध है, यानी यह डेस्कटॉप पर Chrome, Edge, Firefox और Safari के मौजूदा वर्ज़न में, तथा Android पर Chrome और Firefox में काम करता है. दो चेतावनियाँ सुर्ख़ी से ज़्यादा मायने रखती हैं.

पहली, Notifications API हर जगह एक जैसी उपलब्ध नहीं है. MDN इसे सीमित उपलब्धता वाला बताता है क्योंकि Notification() कंस्ट्रक्टर ज़्यादातर मोबाइल ब्राउज़र में TypeError फेंकता है. जिस चीज़ का फ़ोन पर चलना ज़रूरी है, उसके लिए ServiceWorkerRegistration.showNotification() के ज़रिए परसिस्टेंट नोटिफ़िकेशन इस्तेमाल करें, जो वैसे भी वही सर्विस वर्कर रास्ता है जिस पर आप हैं.

दूसरी, नोटिफ़िकेशन विकल्प असमान रूप से लागू किए गए हैं. एक्शन बटन, बैज, इमेज और requireInteraction ब्राउज़र तथा ऑपरेटिंग सिस्टम के हिसाब से बदलते हैं, इसलिए नोटिफ़िकेशन ऐसे डिज़ाइन करें जो सिर्फ़ शीर्षक, बॉडी और आइकन के साथ भी सही पढ़े जाएं.

iOS और iPadOS की शर्त

यही चेतावनी तय करती है कि मोबाइल-भारी ऑडियंस के लिए वेब पुश व्यवहार्य है या नहीं, और इसे लगभग हर जगह ग़लत बताया जाता है.

Apple ने iOS और iPadOS 16.4 में Web Push जोड़ा, और यह केवल उन वेब ऐप्स के लिए काम करता है जिन्हें Home Screen पर जोड़ा गया हो. WebKit के शब्दों में, “we are adding support for Web Push to Home Screen web apps”, और “a web app that has been added to the Home Screen can request permission to receive push notifications”. उपयोगकर्ता इसे Share मेन्यू और “Add to Home Screen” के ज़रिए जोड़ता है, और उसके बाद परमिशन सीधे उपयोगकर्ता की क्रिया के जवाब में माँगी जानी चाहिए, जैसे सब्सक्राइब बटन दबाने पर.

iPhone पर सामान्य Safari टैब में खुली साइट पुश सब्सक्रिप्शन नहीं बना सकती. यह असली बाधा है: आप परमिशन माँगने से पहले ही एक इंस्टॉलेशन क़दम माँग रहे हैं. macOS पर यह आसान है, क्योंकि macOS Ventura पर Safari 16.1 ने सामान्य वेबसाइटों के लिए बिना किसी इंस्टॉलेशन क़दम के मानक-आधारित Web Push जोड़ दिया.

एक न्यूनतम सब्सक्रिप्शन उदाहरण

यह पूरा क्लाइंट-साइड फ़्लो है. यह क्लिक हैंडलर में होना चाहिए, पेज लोड पर नहीं.

async function subscribeToPush(vapidPublicKey) {
  // पुश और सर्विस वर्कर के लिए सुरक्षित कॉन्टेक्स्ट (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, // base64url में एन्कोडेड P-256 पब्लिक की
  });

  // एंडपॉइंट और कीज़ सर्वर पर सहेजें; एंडपॉइंट को सीक्रेट मानें.
  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) कॉल करते हैं, और गंतव्य URL खोलने के लिए notificationclick संभालते हैं.

परमिशन UX: जहाँ ज़्यादातर प्रोग्राम नाकाम होते हैं

पेज लोड पर कभी न पूछें

Lighthouse में इसके लिए अलग ऑडिट है: “if your page asks for permission to send notifications on page load, those notifications may not be relevant to your users or their needs”. इसकी सिफ़ारिश है कि एक ख़ास तरह का नोटिफ़िकेशन पेश करें और परमिशन तभी माँगें जब उपयोगकर्ता उस प्रकार के लिए ऑप्ट इन कर ले. Safari 12.1 और दूसरे ब्राउज़र इससे आगे गए, और उन्होंने रिक्वेस्ट करने से पहले पेज के साथ इंटरैक्शन को अनिवार्य कर दिया.

सॉफ़्ट प्री-प्रॉम्प्ट इस्तेमाल करें

पहले अपना ख़ुद का इन-पेज निमंत्रण दिखाएं. यह मूल्य स्पष्ट करता है, इसे बिना किसी स्थायी नुकसान के बंद किया जा सकता है, और असली ब्राउज़र प्रॉम्प्ट सिर्फ़ इस पर क्लिक करने से चलता है. जो व्यक्ति आज आपके सॉफ़्ट प्रॉम्प्ट को अनदेखा करता है, उससे अगले महीने दोबारा पूछा जा सकता है. जो Block दबा देता है, उससे नहीं. इसे कारगर बनाने के दो नियम हैं: “अपडेट पाएं” के बजाय बताएं कि आप वास्तव में क्या भेजेंगे, और ग़लती से क्लिक करवाने की कोशिश कभी न करें, क्योंकि अनजाने में मिली स्वीकृति तुरंत अनसब्सक्राइब में बदल जाती है.

संदर्भ में पूछें

Chrome की अपनी सिफ़ारिश है कि “let your users take the initiative and turn on notifications at their own pace”, यानी मौजूदा इंटरफ़ेस सतहों के भीतर टॉगल विनम्रता से रखें, और “showing prompts and/or overlays without context or immediately after a user lands on the site” से बचें.

कॉमर्स में जो पल काम करते हैं वे बहुत ख़ास हैं: बिक चुके प्रोडक्ट पर “स्टॉक में आने पर बताएं” वाला कंट्रोल, डिलीवरी अपडेट देने वाला ऑर्डर कन्फ़र्मेशन पेज, बार-बार देखे जाने वाले प्रोडक्ट पर प्राइस-वॉच टॉगल. परमिशन छीनी नहीं जाती, किसी नामित फ़ायदे के बदले मिलती है.

इनकार व्यावहारिक रूप से स्थायी होता है

जब कोई नोटिफ़िकेशन ब्लॉक करता है, ब्राउज़र वह फ़ैसला आपके ओरिजिन के लिए सहेज लेता है. बाद की Notification.requestPermission() कॉल बिना कुछ दिखाए सहेजी गई denied वैल्यू पर हल हो जाती हैं, इसीलिए MDN का अपना उदाहरण requestPermission() कॉल करने से पहले Notification.permission जाँचता है. ब्लॉक हटाने के लिए साइट सेटिंग्स में जाना पड़ता है, जो व्यावहारिक रूप से कोई नहीं करता.

ग़लती करने पर ब्राउज़र क्या करते हैं

नतीजा अब सिर्फ़ कम ऑप्ट-इन दर तक सीमित नहीं है.

• Chrome बहुत कम स्वीकृति दर वाले ओरिजिन को अपने आप शांत परमिशन UI में डाल देता है, डिवाइस प्रकार के हिसाब से अलग-अलग, जिससे सबके लिए प्रॉम्प्ट दब जाता है.
• Chrome उन साइटों पर रेट लिमिट लगाता है जो ज़्यादा पुश वॉल्यूम और कम एंगेजमेंट मिलाती हैं, और HTTP 429 लौटाता है. सख़्ती एक दिन, फिर सात, फिर चौदह दिन चलती है, और लगातार 42 बिना-बाधा वाले दिनों के बाद ही रीसेट होती है.
• Chrome अब उन साइटों की नोटिफ़िकेशन परमिशन अपने आप वापस ले लेता है जिनसे उपयोगकर्ता ने हाल में इंटरैक्ट नहीं किया, जहाँ “very low user engagement and a high volume of notifications being sent” हो. Google का तर्क सीधा है: “Less than 1% of all notifications receive any interaction from users.”

आप ख़राब तरीक़े से भेजकर उन सब्सक्राइबर्स को खो सकते हैं जो आपने पहले ही कमाए थे.

वेब पुश की email और SMS से तुलना

स्वामित्व का वह अंतर जो रणनीति बदल देता है

पुश सब्सक्रिप्शन एक कैपेबिलिटी URL है जो एक डिवाइस पर एक ब्राउज़र प्रोफ़ाइल से बंधा है. यह कोई व्यक्ति नहीं है. वही ग्राहक लैपटॉप पर Chrome और फ़ोन पर Firefox इस्तेमाल करे तो वे दो असंबंधित सब्सक्रिप्शन हैं, और आप जान नहीं सकते कि दोनों एक ही इंसान हैं, जब तक वे ख़ुद अपनी पहचान न बताएं.

यह पोर्टेबल भी नहीं है. आप email लिस्ट एक्सपोर्ट करके कल किसी दूसरे प्लेटफ़ॉर्म में लोड कर सकते हैं. पुश सब्सक्रिप्शन वेंडर के बीच नहीं ले जाए जा सकते, क्योंकि कीज़ और VAPID बाइंडिंग एक ख़ास एप्लिकेशन सर्वर की के विरुद्ध बनाई गई थीं.

इसलिए वेब पुश को अपने स्वामित्व वाले चैनल के लिए त्वरक मानें, विकल्प कभी नहीं. पुश के पल का उपयोग email पता या फ़ोन नंबर कमाने के लिए करें, उल्टा नहीं. मार्केटिंग ऑटोमेशन की संपूर्ण गाइड कई चैनलों को एक जर्नी में जोड़ने की बात करती है.

वे उपयोग जो सचमुच काम करते हैं

यह चैनल उन संदेशों को पुरस्कृत करता है जो समय-संवेदी, व्यक्तिगत रूप से प्रासंगिक और एक टैप में कार्रवाई योग्य हों.

• कार्ट छोड़ना. एक घंटे के भीतर एक पुश, बाद में email से मज़बूत किया गया. छोड़े गए कार्ट की email गाइड क्रम को समझाती है.
• स्टॉक में वापसी के अलर्ट. सबसे मज़बूत मामला, क्योंकि उपयोगकर्ता ने ख़ुद बताने को कहा था.
• देखे गए आइटम पर क़ीमत गिरना. वही तर्क, ख़ुद चुनी गई प्रासंगिकता.
• डिलीवरी और ऑर्डर की स्थिति. खोलने की मंशा ऊँची, शिकायत का जोखिम कम.
• सब्सक्राइब किए गए विषय में ताज़ा अपडेट. ख़बरें, परिणाम, उपलब्धता की खिड़कियाँ.

जो नाकाम होता है वह भी उतना ही साफ़ है: सामान्य “हमने नई पोस्ट प्रकाशित की” वाले ब्रॉडकास्ट, एक जैसे रोज़ाना डील, ऐसी कोई भी चीज़ जिसके लिए शीर्षक और एक पंक्ति से ज़्यादा चाहिए, उन सब्सक्राइबर्स को री-एंगेजमेंट की बौछार जिन्होंने पिछले बीस नोटिफ़िकेशन अनदेखे किए, और ऐसा ट्रांज़ैक्शनल कंटेंट जिसका टिकाऊ रिकॉर्ड चाहिए.

आवृत्ति, समय और सेगमेंटेशन

संयम से शुरू करें: प्रति सब्सक्राइबर हफ़्ते में एक से तीन नोटिफ़िकेशन, और तभी बढ़ाएं जब ऑप्ट-आउट और क्लिक दरें टिकी रहें. थकान email से ज़्यादा तेज़ी से दिखती है, क्योंकि म्यूट करने में सिर्फ़ एक टैप लगता है और नोटिफ़िकेशन तो ऑपरेटिंग सिस्टम ने पहले ही सामने रख दिया है.

समय एक फ़ायदा भी है और ख़तरा भी. पुश तुरंत पहुँचता है, इसलिए 02:00 बजे भेजा संदेश 02:00 बजे ही पहुँचता है. सब्सक्राइब के समय सब्सक्राइबर का टाइमज़ोन स्टोर या अनुमानित करें और भेजना एक तय खिड़की के भीतर रखें.

सेगमेंटेशन इस बात से सीमित है कि आप किसी व्यक्ति के बजाय किसी सब्सक्रिप्शन के बारे में क्या जानते हैं, इसलिए काम के आयाम व्यवहार-आधारित हैं: देखे गए पेज, देखे जा रहे प्रोडक्ट, कार्ट की स्थिति, ख़रीद की ताज़गी, प्लेटफ़ॉर्म. ग्राहक सेगमेंटेशन गाइड इसमें और गहराई तक जाती है.

वेब पुश को मापना

चार मेट्रिक मायने रखते हैं, और वे सब एक ही तरह से मापे नहीं जा सकते.

• डिलीवरी. क्या पुश सर्विस ने रिक्वेस्ट स्वीकार की. 201 का मतलब स्वीकार है, पहुँचा हुआ नहीं. 404 या 410 का मतलब है सब्सक्रिप्शन मर चुका है.
• डिस्प्ले. क्या नोटिफ़िकेशन दिखाया गया. यह आपको तभी पता चलता है जब showNotification() पूरा होने पर सर्विस वर्कर वापस रिपोर्ट करे.
• क्लिक-थ्रू रेट. क्लिक बँटा डिस्प्ले. यही वह संख्या है जिसे बेहतर करना सार्थक है.
• ऑप्ट-आउट रेट. प्रति सेंड अनसब्सक्राइब और परमिशन वापसी. इसे CTR से भी ज़्यादा ध्यान से देखें, क्योंकि यह चैनल की मौत का अग्रिम संकेतक है.

एट्रिब्यूशन के जाल

पुश एट्रिब्यूशन ख़ुद को बढ़ा-चढ़ाकर दिखाता है. नोटिफ़िकेशन उस डिवाइस पर आता है जिसे सब्सक्राइबर पहले से पकड़े हुए है, इसलिए वह अक्सर उस सेशन का श्रेय ले लेता है जो वैसे भी होने वाला था. वृद्धिशीलता मान लेने के बजाय होल्डआउट ग्रुप चलाएं. डिस्प्ले कम गिने जाते हैं जबकि हर क्लिक दर्ज होता है, इसलिए सेंड के आधार पर निकाला गया CTR प्रदर्शन को बढ़ा-चढ़ाकर दिखाता है. और चूँकि सब्सक्रिप्शन एक ब्राउज़र है, व्यक्ति नहीं, इसलिए फ़ोन पर क्लिक हुआ पुश जो डेस्कटॉप ख़रीद में बदलता है, दो असंबंधित घटनाओं जैसा दिखता है. email मार्केटिंग मेट्रिक्स गाइड सभी चैनलों में मापन की स्वच्छता को कवर करती है.

सहमति, GDPR और ऑप्ट-आउट

ब्राउज़र का परमिशन प्रॉम्प्ट एक तकनीकी गेट है. यह अपने आप मार्केटिंग के लिए पूरा क़ानूनी आधार नहीं बन जाता.

जहाँ आप EU या UK के लोगों तक मार्केटिंग कर रहे हैं, वहाँ पुश को वैसे ही मानें जैसे email को. प्रॉम्प्ट दिखने से पहले बताएं कि आप क्या भेजेंगे, ताकि सहमति सूचित और विशिष्ट हो. रिकॉर्ड रखें कि सब्सक्रिप्शन कब और कहाँ बना, और पुश की सहमति को किसी असंबंधित क्रिया के साथ कभी न जोड़ें. अगर आप सब्सक्रिप्शन को पहचाने गए ग्राहकों से जोड़ते हैं, तो वह डेटा आपके व्यक्तिगत-डेटा दायित्वों के भीतर आता है, जिसमें डिलीशन अनुरोध भी शामिल हैं.

ऑप्ट-आउट की स्वच्छता भी उतनी ही अहम है. साइट के भीतर प्राथमिकता नियंत्रण दें ताकि लोग ब्लॉक करने के बजाय आवृत्ति घटा सकें, ऐसा करने पर PushSubscription.unsubscribe() कॉल करें और सर्वर पर रिकॉर्ड हटा दें, और 404 या 410 मिलने पर सब्सक्रिप्शन साफ़ कर दें. MDN का मार्गदर्शन छोटा और सही है: उपयोगकर्ताओं को “offered an easy way to opt out of getting more in the future” मिलना चाहिए.

चैनल स्टैक में वेब पुश कहाँ बैठता है

वेब पुश अच्छा तीसरा चैनल है और बुरा पहला: तेज़, सीमांत रूप से मुफ़्त, और समय-महत्वपूर्ण अलर्ट के लिए बेजोड़, लेकिन डिवाइस से बंधा, ग़ैर-एक्सपोर्ट योग्य, और स्थायी नुकसान से बस एक क्लिक दूर.

इससे असली समस्या ऑर्केस्ट्रेशन बन जाती है. कौन-सा संदेश किस चैनल पर जाए, पुश से कन्वर्ज़न हो जाने पर email को कैसे रोकें, और अलग-अलग तरीक़ों से लोगों की पहचान करने वाली सतहों पर ग्राहक की एक ही तस्वीर कैसे बनाए रखें. Brevo email और SMS के साथ वेब तथा मोबाइल पुश भी देता है, और Tajo Brevo के ऊपर बैठकर Shopify स्टोर्स के लिए इस क्रॉस-चैनल लॉजिक का समन्वय करता है. SMS वाले हिस्से के लिए SMS ऑटोमेशन गाइड देखें.

मुख्य बातें

• वेब पुश तीन API का साथ है: बैकग्राउंड में चलने के लिए सर्विस वर्कर, सब्सक्रिप्शन और ट्रांसपोर्ट के लिए Push API, दिखाने के लिए Notifications API. सब्सक्रिप्शन का मतलब है एक एंडपॉइंट, एक p256dh की और एक auth सीक्रेट, पेलोड एंड टू एंड एन्क्रिप्टेड होते हैं, और VAPID भेजने वाले को साबित करता है.
• Push मार्च 2023 से Baseline में व्यापक रूप से उपलब्ध है, लेकिन iOS और iPadOS पर यह सिर्फ़ Home Screen पर जोड़े गए वेब ऐप्स के लिए काम करता है.
• पेज लोड पर कभी परमिशन न माँगें. सॉफ़्ट प्री-प्रॉम्प्ट इस्तेमाल करें, संदर्भ में पूछें, और याद रखें कि ब्लॉक उस ओरिजिन के लिए स्थायी है.
• Chrome अब शांत प्रॉम्प्ट, रेट लिमिट और अपने आप परमिशन वापसी लागू करता है, इसलिए ख़राब तरीक़े से भेजना आपको पहले से मौजूद सब्सक्राइबर्स की क़ीमत चुकाता है.
• सब्सक्रिप्शन एक ब्राउज़र है, व्यक्ति नहीं, और उसे एक्सपोर्ट नहीं किया जा सकता. पहले email लिस्ट बनाएं और उसे तेज़ करने के लिए पुश का उपयोग करें.