ویب پش نوٹیفکیشنز: یہ کیسے کام کرتی ہیں اور انہیں درست طریقے سے کیسے استعمال کریں
ویب پش نوٹیفکیشنز کیسے کام کرتی ہیں، سروس ورکر اور VAPID سے لے کر iOS سمیت حقیقی براؤزر سپورٹ تک، اور وہ اجازت کا تجربہ اور میٹرکس جو نتائج طے کرتے ہیں۔
ویب پش نوٹیفکیشنز واحد مارکیٹنگ چینل ہیں جہاں ڈیزائن کا ایک غلط فیصلہ آپ کو کسی گاہک تک رسائی سے ہمیشہ کے لیے محروم کر سکتا ہے۔ غلط لمحے پر اجازت مانگیے، وزیٹر Block دبا دے، اور وہ براؤزر آپ کے لیے ہمیشہ کے لیے بند۔ نہ دوبارہ درخواست، نہ دوسری مہم، نہ کوئی ون بیک ای میل۔ یہی عدم توازن وہ وجہ ہے کہ ایک بھی پیغام لکھنے سے پہلے اس میکانزم کو سمجھنا ضروری ہے۔
ویب پش نوٹیفکیشنز کیا ہیں
ویب پش نوٹیفکیشن وہ پیغام ہے جو آپ کے سرور سے کسی سبسکرائبر کے براؤزر کو بھیجا جاتا ہے، آپریٹنگ سسٹم کے نوٹیفکیشن سینٹر میں دکھایا جاتا ہے، اور اس وقت بھی پہنچتا ہے جب آپ کی سائٹ بند ہو۔ آخری بات ہی اصل نکتہ ہے: صفحے پر ظاہر ہونے والے پاپ اپ کے برعکس، ویب پش اس شخص تک پہنچتی ہے جو اس وقت آپ کی ویب سائٹ نہیں دیکھ رہا۔
یہ ویب پلیٹ فارم کے تین APIs کے مل کر کام کرنے سے بنتی ہے، اور ان کے درمیان تقسیم ہی اس چینل کے زیادہ تر رویے کی وضاحت کرتی ہے: Service Worker API، Push API، اور Notifications API۔
ویب پش پردے کے پیچھے کیسے کام کرتی ہے
سروس ورکر
سروس ورکر ایک JavaScript ورکر ہے جو آپ کی ویب ایپ، براؤزر اور نیٹ ورک کے درمیان پراکسی کا کام کرتا ہے۔ یہ اپنے الگ تھریڈ پر چلتا ہے، اس کی DOM تک رسائی نہیں ہوتی، اور اسے رجسٹر کرنے والا صفحہ بند ہونے کے بعد بھی یہ موجود رہتا ہے۔ یہی تسلسل اسے اس قابل بناتا ہے کہ جب کسی نے آپ کا ٹیب کھولا ہی نہ ہو تب بھی وہ پش پیغام وصول کر کے نوٹیفکیشن دکھا سکے۔ سروس ورکرز صرف محفوظ سیاق میں چلتے ہیں، یعنی HTTPS، جبکہ ڈویلپمنٹ کے لیے http://localhost کو محفوظ مانا جاتا ہے۔
سبسکرپشن: ایک اینڈ پوائنٹ اور دو کیز
جیسے ہی سروس ورکر فعال ہوتا ہے، صفحہ registration.pushManager.subscribe() کال کرتا ہے۔ براؤزر اپنے وینڈر کی پش سروس سے بات کرتا ہے اور ایک PushSubscription واپس کرتا ہے جس میں یہ شامل ہوتا ہے:
endpoint، ایک منفرد capability URL جس پر پش سروس پیغامات قبول کرتی ہےkeys.p256dh، P-256 کرو پر ایک Elliptic Curve Diffie-Hellman پبلک کیkeys.auth، ایک authentication secret
آپ کا سرور تینوں محفوظ کرتا ہے اور اینڈ پوائنٹ کو راز سمجھتا ہے، کیونکہ جس کے پاس بھی یہ ہو وہ اس سبسکرائبر کو پیغام بھیج سکتا ہے۔ کیز اس لیے موجود ہیں کہ پے لوڈ سرے سے سرے تک انکرپٹ ہوتے ہیں۔ 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 کلیم ہوتا ہے۔ پش سروس دستخط کی تصدیق کرتی ہے، اس لیے صرف چوری شدہ اینڈ پوائنٹ سے آپ کے سبسکرائبرز کو اسپام بھیجنا ممکن نہیں رہتا۔
ڈیلیوری کا مکمل راستہ
- صفحہ سروس ورکر رجسٹر کرتا ہے اور اجازت ملنے کے بعد آپ کی VAPID پبلک کی کے ساتھ
subscribe()کال کرتا ہے۔ - آپ کا سرور واپس آنے والا اینڈ پوائنٹ اور کیز سبسکرائبر کے ریکارڈ کے ساتھ محفوظ کرتا ہے۔
- بھیجنے کے لیے آپ کا سرور پے لوڈ کو
p256dhاورauthسے انکرپٹ کرتا ہے، VAPID JWT سائن کرتا ہے، اور اینڈ پوائنٹ پر POST کرتا ہے۔ - پش سروس درخواست کی تصدیق کرتی ہے اور انکرپٹڈ پیغام پہنچاتی ہے۔
- براؤزر سروس ورکر کو
pushایونٹ کے ساتھ جگاتا ہے، جو پے لوڈ ڈکرپٹ کر کےServiceWorkerRegistration.showNotification()کال کرتا ہے۔ - کلک پر سروس ورکر میں
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 میں ویب پش شامل کی، اور یہ صرف ان ویب ایپس کے لیے کام کرتی ہے جو ہوم اسکرین پر شامل کی گئی ہوں۔ WebKit کے الفاظ میں، “ہم Home Screen ویب ایپس کے لیے Web Push کی سپورٹ شامل کر رہے ہیں”، اور “جو ویب ایپ Home Screen پر شامل کی جا چکی ہو وہ پش نوٹیفکیشنز وصول کرنے کی اجازت مانگ سکتی ہے”۔ صارف اسے Share مینو اور “Add to Home Screen” کے ذریعے شامل کرتا ہے، اور پھر اجازت براہ راست صارف کے عمل کے جواب میں مانگی جانی چاہیے، مثلاً سبسکرائب بٹن دبانے پر۔
iPhone پر عام Safari ٹیب میں کھلی سائٹ پش سبسکرپشن نہیں بنا سکتی۔ یہ ایک حقیقی رکاوٹ ہے: آپ اجازت مانگنے سے پہلے ہی انسٹالیشن کا ایک قدم مانگ رہے ہیں۔ macOS پر معاملہ آسان ہے، کیونکہ macOS Ventura پر Safari 16.1 نے عام ویب سائٹس کے لیے معیارات پر مبنی ویب پش بغیر کسی انسٹالیشن قدم کے شامل کر دی۔
سبسکرپشن کی ایک مختصر مثال
یہ کلائنٹ کی طرف کا پورا عمل ہے۔ اس کی جگہ کلک ہینڈلر ہے، صفحہ لوڈ ہونے پر نہیں۔
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 سنبھالتے ہیں۔
اجازت کا تجربہ: جہاں زیادہ تر پروگرام ناکام ہوتے ہیں
صفحہ لوڈ ہوتے ہی کبھی نہ پوچھیں
Lighthouse کا اس کے لیے الگ آڈٹ ہے: “اگر آپ کا صفحہ لوڈ ہوتے ہی نوٹیفکیشنز بھیجنے کی اجازت مانگتا ہے تو ممکن ہے وہ نوٹیفکیشنز آپ کے صارفین یا ان کی ضروریات سے متعلق ہی نہ ہوں”۔ اس کی سفارش یہ ہے کہ نوٹیفکیشن کی ایک مخصوص قسم پیش کریں اور اجازت صرف تب مانگیں جب صارف اس قسم کے لیے آپٹ ان کر لے۔ Safari 12.1 اور دیگر براؤزرز اس سے بھی آگے گئے اور درخواست سے پہلے صفحے کے ساتھ تعامل لازمی قرار دیا۔
نرم پیشگی پرامپٹ استعمال کریں
پہلے اپنی صفحے کے اندر کی دعوت دکھائیں۔ یہ قدر واضح کرتی ہے، اسے بغیر کسی مستقل نقصان کے بند کیا جا سکتا ہے، اور صرف اس پر کلک کرنے سے اصل براؤزر پرامپٹ ظاہر ہوتا ہے۔ جو شخص آج آپ کا نرم پرامپٹ نظرانداز کرتا ہے، اس سے اگلے مہینے دوبارہ پوچھا جا سکتا ہے۔ جو Block دبا دے، اس سے نہیں۔ دو اصول اسے کارگر بناتے ہیں: “اپ ڈیٹس حاصل کریں” کے بجائے بتائیں کہ آپ واقعی کیا بھیجیں گے، اور کبھی غلطی سے کلک کرانے کی چال نہ چلیں، کیونکہ حادثاتی قبولیت فوری ان سبسکرائب پیدا کرتی ہے۔
سیاق کے اندر پوچھیں
Chrome کی اپنی سفارش یہ ہے کہ “اپنے صارفین کو پہل کرنے دیں اور انہیں اپنی رفتار سے نوٹیفکیشنز آن کرنے دیں”، یعنی موجودہ انٹرفیس کے اندر ٹوگل احتیاط سے رکھیں، اور “بغیر سیاق کے، یا صارف کے سائٹ پر پہنچتے ہی، پرامپٹس اور اوورلیز دکھانے” سے گریز کریں۔
کامرس میں جو لمحے کام کرتے ہیں وہ مخصوص ہیں: بک چکے پروڈکٹ پر “دستیاب ہونے پر مجھے بتائیں” کا کنٹرول، آرڈر کی تصدیق کے صفحے پر ڈیلیوری اپ ڈیٹس کی پیشکش، بار بار دیکھے جانے والے پروڈکٹ پر قیمت کی نگرانی کا ٹوگل۔ اجازت کسی نامزد فائدے کے بدلے لی جاتی ہے، چھین کر نہیں۔
انکار عملاً مستقل ہوتا ہے
جب کوئی نوٹیفکیشنز بلاک کرتا ہے تو براؤزر وہ فیصلہ آپ کے اوریجن کے لیے محفوظ کر لیتا ہے۔ بعد میں Notification.requestPermission() کی کالیں بغیر کچھ دکھائے محفوظ شدہ denied قدر پر حل ہو جاتی ہیں، اسی لیے MDN کی اپنی مثال requestPermission() کال کرنے سے پہلے Notification.permission جانچتی ہے۔ بلاک کو پلٹنے کے لیے سائٹ کی سیٹنگز کھنگالنی پڑتی ہیں، جو عملاً کوئی نہیں کرتا۔
غلطی پر براؤزر کیا کرتے ہیں
نتائج اب صرف کم آپٹ ان ریٹ تک محدود نہیں۔
- Chrome بہت کم قبولیت والے اوریجنز کو خود بخود خاموش اجازت انٹرفیس میں ڈال دیتا ہے، ڈیوائس کی قسم کے حساب سے الگ الگ، جس سے پرامپٹ سب کے لیے دب جاتا ہے۔
- Chrome ان سائٹس پر ریٹ لمٹ لگاتا ہے جو زیادہ پش حجم کو کم دلچسپی کے ساتھ ملاتی ہیں، اور HTTP 429 واپس کرتا ہے۔ سختی پہلے ایک دن، پھر سات، پھر چودہ دن چلتی ہے، اور صرف 42 مسلسل غیر مخل دنوں کے بعد ری سیٹ ہوتی ہے۔
- Chrome اب ان سائٹس کی نوٹیفکیشن اجازت خود بخود واپس لے لیتا ہے جن سے صارف نے حال ہی میں تعامل نہ کیا ہو، جہاں “صارف کی بہت کم دلچسپی اور بھیجی جانے والی نوٹیفکیشنز کا بہت زیادہ حجم” ہو۔ Google کا جواز دو ٹوک ہے: “تمام نوٹیفکیشنز میں سے 1% سے بھی کم کو صارفین کی طرف سے کوئی تعامل ملتا ہے۔”
آپ صرف غلط انداز میں بھیج کر وہ سبسکرائبرز کھو سکتے ہیں جو آپ پہلے ہی کما چکے تھے۔
ویب پش کا ای میل اور SMS سے موازنہ
| عنصر | ویب پش | ای میل | SMS |
|---|---|---|---|
| رسائی | صرف وہ براؤزر جنہوں نے آپٹ ان کیا | جس کے پاس بھی پتہ ہو | جس کے پاس بھی نمبر ہو |
| اضافی لاگت | عملاً صفر | بہت کم | فی پیغام، سب سے زیادہ |
| فوریت | چند سیکنڈ، OS خود سامنے لاتا ہے | منٹوں سے دنوں تک، ان باکس میں دب جاتی ہے | چند سیکنڈ |
| پیغام کی لمبائی | عنوان اور مختصر متن | لامحدود، بھرپور فارمیٹنگ | تقریباً 160 حروف فی سیگمنٹ |
| رضامندی | براؤزر پرامپٹ، ایک کلک | پتہ جمع کرنا، ترجیحاً ڈبل آپٹ ان | واضح اور سختی سے ضابطہ بند |
| شناخت | ایک ڈیوائس پر ایک براؤزر | ایک شخص | ایک شخص |
| منتقلی | کوئی نہیں | مکمل ایکسپورٹ | مکمل ایکسپورٹ |
ملکیت کا وہ فرق جو حکمت عملی بدل دیتا ہے
پش سبسکرپشن ایک capability URL ہے جو ایک ڈیوائس پر ایک براؤزر پروفائل سے بندھا ہوتا ہے۔ یہ کوئی شخص نہیں۔ وہی گاہک لیپ ٹاپ پر Chrome اور فون پر Firefox استعمال کرے تو یہ دو غیر متعلق سبسکرپشنز ہیں، اور آپ نہیں جان سکتے کہ یہ ایک ہی انسان ہے جب تک وہ خود اپنی شناخت نہ کرائے۔
یہ منتقل بھی نہیں کی جا سکتی۔ آپ ای میل لسٹ ایکسپورٹ کر کے کل کسی اور پلیٹ فارم میں ڈال سکتے ہیں۔ پش سبسکرپشنز وینڈرز کے درمیان منتقل نہیں کی جا سکتیں، کیونکہ کیز اور VAPID بائنڈنگ ایک مخصوص ایپلیکیشن سرور کی کے مقابل بنائی گئی تھیں۔
اس لیے ویب پش کو کسی ملکیتی چینل کے لیے مہمیز سمجھیں، اس کا متبادل کبھی نہیں۔ پش کے لمحے کو ای میل پتہ یا فون نمبر کمانے کے لیے استعمال کریں، الٹا نہیں۔ مارکیٹنگ آٹومیشن کی مکمل گائیڈ میں کئی چینلز کو ایک سفر میں جوڑنے کا طریقہ بیان ہے۔
وہ استعمالات جو واقعی کام کرتے ہیں
یہ چینل ان پیغامات کو انعام دیتا ہے جو وقت کے لحاظ سے حساس، ذاتی طور پر متعلقہ اور ایک ٹیپ میں قابل عمل ہوں۔
- کارٹ چھوڑنا۔ ایک گھنٹے کے اندر پش، اور بعد میں ای میل سے تقویت۔ ترتیب کی تفصیل ابینڈنڈ کارٹ ای میل گائیڈ میں ہے۔
- دوبارہ اسٹاک ہونے کی اطلاع۔ سب سے مضبوط صورت، کیونکہ صارف نے خود بتانے کو کہا تھا۔
- نگرانی میں رکھی اشیا پر قیمت میں کمی۔ وہی منطق، خود منتخب کردہ مطابقت۔
- ڈیلیوری اور آرڈر کی حالت۔ کھولنے کا ارادہ زیادہ، شکایت کا خطرہ کم۔
- سبسکرائب شدہ موضوع میں تازہ ترین خبر۔ خبریں، نتائج، دستیابی کے اوقات۔
جو ناکام ہوتا ہے وہ بھی اتنا ہی واضح ہے: عمومی “ہم نے نئی پوسٹ شائع کی” نشریات، بغیر تفریق روزانہ کی پیشکشیں، ہر وہ چیز جس کے لیے عنوان اور ایک سطر سے زیادہ درکار ہو، ان سبسکرائبرز کو دوبارہ متحرک کرنے کی مہمات جنہوں نے پچھلی بیس نوٹیفکیشنز نظرانداز کیں، اور وہ ٹرانزیکشنل مواد جس کا پائیدار ریکارڈ درکار ہو۔
تعدد، وقت اور سیگمنٹیشن
محتاط شروعات کریں: فی سبسکرائبر ہفتے میں ایک سے تین نوٹیفکیشنز، اور اضافہ صرف تب جب آپٹ آؤٹ اور کلک ریٹ قائم رہیں۔ تھکاوٹ ای میل کے مقابلے میں تیزی سے ظاہر ہوتی ہے، کیونکہ خاموش کرنے میں اس نوٹیفکیشن پر صرف ایک ٹیپ لگتی ہے جو آپریٹنگ سسٹم پہلے ہی سامنے لا چکا ہے۔
وقت بیک وقت فائدہ بھی ہے اور خطرہ بھی۔ پش فوراً پہنچتی ہے، اس لیے رات 02:00 بجے بھیجا گیا پیغام 02:00 بجے ہی پہنچے گا۔ سبسکرائب کے وقت سبسکرائبر کا ٹائم زون محفوظ کریں یا اخذ کریں، اور بھیجنے کو ایک متعین وقفے کے اندر رکھیں۔
سیگمنٹیشن اس بات سے محدود ہے کہ آپ کسی شخص کے بجائے سبسکرپشن کے بارے میں کیا جانتے ہیں، اس لیے قابل عمل پیمانے رویے پر مبنی ہیں: دیکھے گئے صفحات، نگرانی میں رکھے پروڈکٹس، کارٹ کی حالت، خریداری کی تازگی، پلیٹ فارم۔ گاہک سیگمنٹیشن گائیڈ اس میں مزید گہرائی میں جاتی ہے۔
ویب پش کی پیمائش
چار میٹرکس اہم ہیں، اور یہ سب ایک ہی طریقے سے ماپے نہیں جا سکتے۔
- ڈیلیوری۔ آیا پش سروس نے درخواست قبول کی۔ 201 کا مطلب قبول ہے، پہنچ جانا نہیں۔ 404 یا 410 کا مطلب ہے سبسکرپشن ختم ہو چکی۔
- ڈسپلے۔ آیا نوٹیفکیشن دکھائی گئی۔ یہ آپ کو تبھی معلوم ہوتا ہے جب
showNotification()مکمل ہونے پر سروس ورکر واپس اطلاع دے۔ - کلک تھرو ریٹ۔ کلکس تقسیم بر ڈسپلے۔ یہی وہ عدد ہے جسے بہتر بنانا فائدہ مند ہے۔
- آپٹ آؤٹ ریٹ۔ فی سینڈ ان سبسکرائب اور اجازت کی واپسیاں۔ اس پر CTR سے زیادہ نظر رکھیں، کیونکہ یہ چینل کی موت کا پیشگی اشارہ ہے۔
ایٹریبیوشن کے پھندے
پش ایٹریبیوشن اپنی تعریف خود کرتی ہے۔ نوٹیفکیشن اس ڈیوائس پر پہنچتی ہے جو سبسکرائبر پہلے ہی ہاتھ میں پکڑے ہوتا ہے، اس لیے اکثر وہ اس سیشن کا کریڈٹ لے لیتی ہے جو ویسے بھی ہونا تھا۔ اضافی اثر فرض کرنے کے بجائے ہولڈ آؤٹ گروپ چلائیں۔ ڈسپلے کم گنے جاتے ہیں جبکہ ہر کلک ریکارڈ ہوتا ہے، اس لیے سینڈز کے مقابل نکالا گیا CTR کارکردگی کو بڑھا چڑھا کر دکھاتا ہے۔ اور چونکہ سبسکرپشن ایک براؤزر ہے، کوئی شخص نہیں، اس لیے فون پر کلک ہونے والی پش جو ڈیسک ٹاپ پر خریداری پر ختم ہو، دو غیر متعلق واقعات لگتی ہے۔ ای میل مارکیٹنگ میٹرکس گائیڈ میں چینلز کے آر پار پیمائش کی صفائی بیان کی گئی ہے۔
رضامندی، GDPR اور آپٹ آؤٹ
براؤزر کا اجازت پرامپٹ ایک تکنیکی دروازہ ہے۔ یہ خود بخود مارکیٹنگ کے لیے مکمل قانونی بنیاد نہیں بن جاتا۔
جہاں آپ یورپی یونین یا برطانیہ کے لوگوں کو مارکیٹنگ کر رہے ہوں، پش کو ای میل جیسا ہی برتیں۔ پرامپٹ ظاہر ہونے سے پہلے بتائیں کہ آپ کیا بھیجیں گے، تاکہ رضامندی باخبر اور مخصوص ہو۔ ریکارڈ رکھیں کہ سبسکرپشن کب اور کہاں بنی، اور پش کی رضامندی کو کبھی کسی غیر متعلق عمل کے ساتھ نہ باندھیں۔ اگر آپ سبسکرپشنز کو شناخت شدہ گاہکوں سے جوڑتے ہیں تو وہ ڈیٹا آپ کی ذاتی ڈیٹا سے متعلق ذمہ داریوں میں آتا ہے، بشمول حذف کرنے کی درخواستیں۔
آپٹ آؤٹ کی صفائی بھی اتنی ہی اہم ہے۔ سائٹ کے اندر ترجیحات کا کنٹرول دیں تاکہ لوگ بلاک کرنے کے بجائے تعدد کم کر سکیں، جب وہ ایسا کریں تو PushSubscription.unsubscribe() کال کریں اور سرور پر ریکارڈ حذف کریں، اور 404 یا 410 پر سبسکرپشنز صاف کر دیں۔ MDN کی ہدایت مختصر اور درست ہے: صارفین کو “آئندہ مزید پیغامات سے آپٹ آؤٹ کرنے کا آسان راستہ” دیا جانا چاہیے۔
چینل اسٹیک میں ویب پش کی جگہ
ویب پش ایک اچھا تیسرا چینل ہے اور برا پہلا: تیز، اضافی لاگت کے لحاظ سے مفت اور وقت کے لحاظ سے حساس الرٹس کے لیے بے مثال، مگر ڈیوائس سے بندھا، ناقابل ایکسپورٹ اور ایک کلک میں مستقل نقصان کے قریب۔
اسی لیے اصل مسئلہ آرکسٹریشن ہے۔ کون سا پیغام کس چینل پر جائے، جب پش پہلے ہی کنورژن کرا دے تو ای میل کیسے روکی جائے، اور ایسی سطحوں کے آر پار گاہک کا ایک ہی منظر کیسے رکھا جائے جو لوگوں کی شناخت مختلف طریقوں سے کرتی ہیں۔ Brevo ای میل اور SMS کے ساتھ ویب اور موبائل پش پیش کرتا ہے، اور Tajo Brevo کے اوپر بیٹھ کر Shopify اسٹورز کے لیے اس کراس چینل منطق کو مربوط کرتا ہے۔ SMS کی طرف کے لیے SMS آٹومیشن گائیڈ دیکھیں۔
اہم نکات
- ویب پش تین APIs کا اشتراک ہے: بیک گراؤنڈ عمل کے لیے سروس ورکر، سبسکرپشن اور ترسیل کے لیے Push API، اور دکھانے کے لیے Notifications API۔ سبسکرپشن ایک اینڈ پوائنٹ کے ساتھ ایک
p256dhکی اور ایکauthراز ہے، پے لوڈ سرے سے سرے تک انکرپٹ ہوتے ہیں، اور VAPID بھیجنے والے کو ثابت کرتا ہے۔ - پش مارچ 2023 سے Baseline کے طور پر وسیع پیمانے پر دستیاب ہے، لیکن iOS اور iPadOS پر یہ صرف ہوم اسکرین پر شامل کی گئی ویب ایپس کے لیے کام کرتی ہے۔
- صفحہ لوڈ ہوتے ہی کبھی اجازت نہ مانگیں۔ نرم پیشگی پرامپٹ استعمال کریں، سیاق کے اندر پوچھیں، اور یاد رکھیں کہ اس اوریجن کے لیے بلاک مستقل ہے۔
- Chrome اب خاموش پرامپٹس، ریٹ لمٹس اور اجازت کی خودکار واپسی نافذ کرتا ہے، اس لیے غلط انداز میں بھیجنا آپ کو وہ سبسکرائبرز کا نقصان دیتا ہے جو آپ کے پاس پہلے سے ہیں۔
- سبسکرپشن ایک براؤزر ہے، کوئی شخص نہیں، اور اسے ایکسپورٹ نہیں کیا جا سکتا۔ پہلے ای میل لسٹ بنائیں اور پش کو اسے تیز کرنے کے لیے استعمال کریں۔