إشعارات الويب الفورية: كيف تعمل وكيف تستخدمها بإتقان

إشعارات الويب الفورية هي قناة التسويق الوحيدة التي يستطيع فيها قرار تصميمي سيئ واحد أن يغلق بابك أمام عميل إلى الأبد. اطلب الإذن في اللحظة الخطأ، ينقر الزائر على حظر، ويُغلق ذلك المتصفح في وجهك للأبد. لا طلب ثانٍ، ولا حملة أخرى، ولا رسالة استرداد. هذا اللاتماثل هو سبب استحقاق الآلية للفهم قبل أن تكتب رسالة واحدة.

ما هي إشعارات الويب الفورية

إشعار الويب الفوري رسالة تُرسل من خادمك إلى متصفح المشترك، ويعرضها مركز إشعارات نظام التشغيل، وتصل حتى عندما يكون موقعك مغلقًا. وهذا الجزء الأخير هو بيت القصيد: بخلاف النافذة المنبثقة داخل الصفحة، تصل إشعارات الويب إلى شخص لا ينظر إلى موقعك الآن.

وهي مبنية من ثلاث واجهات في منصة الويب تعمل معًا، والفصل بينها يفسّر معظم سلوك القناة: واجهة Service Worker، وواجهة Push، وواجهة Notifications.

كيف تعمل إشعارات الويب من الداخل

عامل الخدمة

عامل الخدمة هو عامل JavaScript يعمل كوسيط بين تطبيق الويب والمتصفح والشبكة. يعمل على خيط خاص به، ولا يملك وصولًا إلى DOM، ويستمر في الوجود بعد إغلاق الصفحة التي سجّلته. وهذا الاستمرار هو ما يتيح له استقبال رسالة دفع وعرض إشعار حين لا يكون تبويبك مفتوحًا لدى أحد. ولا يعمل عمّال الخدمة إلا في سياقات آمنة، أي HTTPS، مع اعتبار http://localhost آمنًا لأغراض التطوير.

الاشتراك: نقطة طرفية ومفتاحان

بمجرد أن يصبح عامل الخدمة نشطًا، تستدعي الصفحة registration.pushManager.subscribe(). يتحدث المتصفح مع خدمة الدفع الخاصة بمزوّده ويعيد كائن PushSubscription يحتوي على:

• endpoint، وهو رابط قدرة فريد تقبل خدمة الدفع الرسائل عليه
• keys.p256dh، وهو مفتاح عام لتبادل Diffie-Hellman على المنحنى الإهليلجي P-256
• keys.auth، وهو سرّ مصادقة

يخزّن خادمك الثلاثة جميعًا ويعامل النقطة الطرفية كسرّ، لأن كل من يمتلكها يستطيع الإرسال إلى ذلك المشترك. والمفاتيح موجودة لأن الحمولات مشفّرة من طرف إلى طرف. ويحدد RFC 8291 الكيفية: تبادل ECDH على P-256 يُنشئ سرًّا مشتركًا، ثم تشتق HKDF مفاتيح منه، ثم تُختم الحمولة بـ AES-128-GCM تحت ترميز المحتوى aes128gcm. وتنقل خدمة الدفع نصًا مشفّرًا لا تستطيع قراءته.

خدمة الدفع

أنت لا ترسل رسائل الدفع مباشرة إلى جهاز. بل ترسلها إلى خدمة دفع يشغّلها مزوّد المتصفح: نقاط FCM من Google لـ Chrome، وautopush من Mozilla لـ Firefox، وخدمة الدفع من Apple لـ Safari. ويعرّف RFC 8030، وعنوانه “التسليم العام للأحداث باستخدام HTTP Push”، هذا البروتوكول. يرسل خادمك طلب POST إلى نقطة الاشتراك، وتتولى خدمة الدفع الأجزاء الصعبة من التسليم على الأجهزة المحمولة: اتصال واحد موفّر للبطارية بالجهاز، والاصطفاف أثناء انقطاع الشبكة، وإيقاظ المتصفح عند وصول رسالة. ولهذا أيضًا لا يمكن ضمان التسليم. فإذا ظل الجهاز مطفأً مدة كافية، تنتهي صلاحية الرسائل وفق قيمة TTL وتُسقط.

VAPID: إثبات هوية المرسل

كون النقطة الطرفية سرًّا أمان هشّ. لذا يضيف RFC 8292 تعريف خادم التطبيق الطوعي، أو VAPID، حتى تستطيع خدمة الدفع معرفة خادم التطبيق الذي أتت منه الرسالة.

تولّد زوج مفاتيح ECDSA على منحنى NIST P-256 مرة واحدة. ويذهب المفتاح العام إلى applicationServerKey عند اشتراك المتصفح، فيربط الاشتراك بخادمك. ومع كل رسالة دفع، يرسل خادمك رمز JWT موقّعًا بالمفتاح الخاص المطابق باستخدام ES256، يحمل ادعاء aud لنطاق خدمة الدفع، وادعاء exp لا يتجاوز 24 ساعة، واختياريًا ادعاء sub ببيانات التواصل. تتحقق خدمة الدفع من التوقيع، فلا تعود نقطة طرفية مسروقة وحدها كافية لإغراق مشتركيك.

مسار التسليم من أوله إلى آخره

1. تسجّل الصفحة عامل خدمة، وبعد منح الإذن تستدعي subscribe() مع مفتاح VAPID العام لديك.
2. يخزّن خادمك النقطة الطرفية والمفاتيح المعادة مقابل سجل المشترك.
3. للإرسال، يشفّر خادمك الحمولة باستخدام p256dh وauth، ويوقّع رمز VAPID JWT، ويرسل POST إلى النقطة الطرفية.
4. تصادق خدمة الدفع على الطلب وتسلّم الرسالة المشفّرة.
5. يوقظ المتصفح عامل الخدمة بحدث push، فيفكّ تشفير الحمولة ويستدعي ServiceWorkerRegistration.showNotification().
6. النقرة تطلق حدث notificationclick داخل عامل الخدمة، حيث تفتح رابط الوجهة.

لماذا نموذج الإذن بهذه الصرامة

انظر إلى ما يمنحه الاشتراك: عملية خلفية تعمل دون أن يكون موقعك مفتوحًا، إضافة إلى القدرة على الرسم على سطح إشعارات نظام التشغيل. لذلك تحصر المتصفحات ذلك خلف إذن صريح، لكل نطاق، ممنوح من المستخدم، ويشترط أغلبها أن يتبع الطلب إيماءة حقيقية من المستخدم.

وهناك قيد ثانٍ يفاجئ الناس. تشترط Chrome وEdge تمرير userVisibleOnly: true عند الاشتراك، وهو وعد بأن كل رسالة دفع ستنتج إشعارًا مرئيًا للمستخدم، فالدفع الصامت في الخلفية ليس استخدامًا مدعومًا للواجهة. كما تطبّق Firefox حصة على رسائل الدفع التي لا تولّد إشعارًا.

دعم المتصفحات والمنصات

بحسب MDN، صارت واجهة Push API متاحة على نطاق واسع ضمن Baseline منذ مارس 2023، أي أنها تعمل عبر الإصدارات الحالية من Chrome وEdge وFirefox وSafari على سطح المكتب، وعلى Chrome وFirefox على Android. وهناك تحفظان أهم من العنوان نفسه.

أولًا، واجهة Notifications ليست متاحة بشكل موحّد. تصنّفها MDN بأنها محدودة التوفر لأن الباني Notification() يرمي TypeError على أغلب متصفحات الهاتف. ولأي شيء يجب أن يعمل على الهواتف، استخدم الإشعارات الدائمة عبر ServiceWorkerRegistration.showNotification()، وهو مسار عامل الخدمة الذي أنت عليه أصلًا.

ثانيًا، خيارات الإشعارات مطبّقة بتفاوت. أزرار الإجراءات والشارات والصور وrequireInteraction تختلف بين المتصفحات وأنظمة التشغيل، لذا صمّم إشعارات تظل مفهومة بعنوان ونص وأيقونة فقط.

شرط iOS وiPadOS

هذا التحفظ يحسم إن كانت إشعارات الويب صالحة لجمهور يغلب عليه الهاتف، وهو مذكور بشكل خاطئ في كل مكان تقريبًا.

أضافت Apple دعم Web Push في iOS وiPadOS 16.4، وهو يعمل فقط لتطبيقات الويب التي أُضيفت إلى الشاشة الرئيسية. وكما قالت WebKit: “نضيف دعم Web Push لتطبيقات الويب على الشاشة الرئيسية”، و”تطبيق الويب الذي أُضيف إلى الشاشة الرئيسية يستطيع طلب إذن استقبال الإشعارات”. يضيفه المستخدم عبر قائمة المشاركة وخيار “إضافة إلى الشاشة الرئيسية”، ثم يجب طلب الإذن استجابةً لتفاعل مباشر من المستخدم، كالنقر على زر اشتراك.

والموقع المفتوح في تبويب Safari عادي على iPhone لا يستطيع إنشاء اشتراك دفع. وهذا حاجز حقيقي: أنت تطلب خطوة تثبيت قبل أن تستطيع حتى طلب الإذن. أما على macOS فالأمر أسهل، لأن Safari 16.1 على macOS Ventura أضاف دعم 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, // مفتاح P-256 عام مرمّز بـ base64url
  });

  // خزّن النقطة الطرفية والمفاتيح على الخادم، وعامل النقطة الطرفية كسرّ.
  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 لفتح رابط الوجهة.

تجربة الإذن: حيث تفشل أغلب البرامج

لا تطلب أبدًا عند تحميل الصفحة

لدى Lighthouse تدقيق مخصص لهذا: “إذا طلبت صفحتك إذن إرسال الإشعارات عند تحميل الصفحة، فقد لا تكون تلك الإشعارات ذات صلة بمستخدميك أو باحتياجاتهم”. وتوصيته أن تعرض نوعًا محددًا من الإشعارات وأن تطلب الإذن فقط بعد أن يختار المستخدم ذلك النوع. وذهبت Safari 12.1 ومتصفحات أخرى أبعد، فاشترطت تفاعلًا مع الصفحة قبل إمكان تقديم الطلب أصلًا.

استخدم طلبًا تمهيديًا لطيفًا

اعرض دعوتك الخاصة داخل الصفحة أولًا. فهي تسمّي القيمة المعروضة، ويمكن إغلاقها بلا كلفة دائمة، ولا يشغّل نافذة المتصفح الحقيقية إلا النقر عليها. من يتجاهل طلبك التمهيدي اليوم يمكن سؤاله مجددًا الشهر المقبل. ومن ينقر على حظر لا يمكن سؤاله. وقاعدتان تجعلان الأمر ينجح: صف ما سترسله فعلًا بدل عبارة “احصل على التحديثات”، ولا تهندس أبدًا نقرة خاطئة، لأن القبول العرضي ينتج إلغاء اشتراك فوريًا.

اطلب في سياقه

توصية Chrome نفسها هي “دع مستخدميك يأخذون المبادرة ويفعّلون الإشعارات بوتيرتهم” بوضع مفاتيح التبديل بتحفّظ داخل أسطح الواجهة الموجودة، وتجنّب “عرض النوافذ أو الطبقات بلا سياق أو فور وصول المستخدم إلى الموقع”.

واللحظات التي تنجح في التجارة محددة: زر “أبلغني عند توفره” على منتج نفدت كميته، وصفحة تأكيد طلب تعرض تحديثات التوصيل، ومفتاح مراقبة سعر على منتج يُشاهد كثيرًا. هنا يُقايَض الإذن بمنفعة مسماة بدل أن يُحصَد.

الرفض دائم عمليًا

عندما يحظر أحدهم الإشعارات، يخزّن المتصفح ذلك القرار لنطاقك. والاستدعاءات اللاحقة لـ Notification.requestPermission() تُحسم إلى القيمة المخزّنة denied دون إظهار أي شيء، ولهذا يتحقق المثال الرسمي لدى MDN من Notification.permission قبل استدعاء requestPermission() أصلًا. وعكس الحظر يعني النبش في إعدادات الموقع، وهو ما لا يفعله أحد عمليًا.

ماذا تفعل المتصفحات حين تخطئ

لم تعد العواقب مجرد معدل اشتراك منخفض.

• تسجّل Chrome تلقائيًا النطاقات ذات معدلات القبول المتدنية جدًا في واجهة إذن أكثر هدوءًا، بشكل منفصل حسب نوع الجهاز، فتكبح النافذة أمام الجميع.
• تفرض Chrome حدود معدل على المواقع التي تجمع حجم دفع مرتفعًا مع تفاعل منخفض، فتعيد HTTP 429. ويجري التصعيد يومًا، ثم سبعة، ثم أربعة عشر، ولا يُعاد ضبطه إلا بعد 42 يومًا متتاليًا بلا إزعاج.
• صارت Chrome تسحب إذن الإشعارات تلقائيًا للمواقع التي لم يتفاعل معها المستخدم مؤخرًا، حيث يوجد “تفاعل منخفض جدًا من المستخدم وحجم كبير من الإشعارات المرسلة”. وتبرير Google صارخ: “أقل من 1% من كل الإشعارات تتلقى أي تفاعل من المستخدمين.”

يمكنك أن تخسر مشتركين كسبتهم بالفعل لمجرد أنك ترسل بشكل سيئ.

مقارنة إشعارات الويب بالبريد الإلكتروني والرسائل النصية

فارق الملكية الذي يغيّر الاستراتيجية

اشتراك الدفع رابط قدرة مرتبط بملف متصفح واحد على جهاز واحد. وهو ليس شخصًا. العميل نفسه الذي يستخدم Chrome على حاسوب محمول وFirefox على هاتف هو اشتراكان غير مرتبطين، ولا تستطيع معرفة أنهما الإنسان نفسه ما لم يعرّف عن نفسه.

وهو أيضًا غير قابل للنقل. تستطيع تصدير قائمة بريدية وتحميلها في منصة أخرى غدًا. ولا تستطيع نقل اشتراكات الدفع بين المزوّدين، لأن المفاتيح وربط VAPID أُنشئت مقابل مفتاح خادم تطبيق محدد.

لذا عامل إشعارات الويب كمسرّع لقناة تملكها، لا كبديل عنها أبدًا. استخدم لحظة الإشعار لكسب عنوان بريد أو رقم هاتف، لا العكس. والدليل الشامل لأتمتة التسويق يغطي ربط عدة قنوات في رحلة واحدة.

حالات استخدام تنجح فعلًا

تكافئ هذه القناة الرسائل الحساسة للوقت، وذات الصلة الشخصية، والقابلة للتنفيذ بنقرة واحدة.

• هجر العربة. إشعار خلال ساعة، تعزّزه رسالة بريد لاحقًا. ودليل رسائل العربة المهجورة يغطي الترتيب الزمني.
• تنبيهات عودة المنتج للمخزون. الحالة الأقوى، لأن المستخدم طلب صراحة أن يُخبَر.
• انخفاض أسعار المنتجات المراقَبة. المنطق نفسه، صلة يختارها المستخدم بنفسه.
• حالة التوصيل والطلب. نية فتح عالية، ومخاطر شكوى منخفضة.
• تحديثات عاجلة في موضوع مشترَك فيه. الأخبار والنتائج ونوافذ التوفر.

وما يفشل واضح بالقدر نفسه: البث العام من نوع “نشرنا مقالة جديدة”، والعروض اليومية غير المميّزة، وأي شيء يحتاج أكثر من عنوان وسطر واحد، وحملات إعادة التفاعل الموجهة لمشتركين تجاهلوا آخر عشرين إشعارًا، والمحتوى المعاملاتي الذي يحتاج سجلًا دائمًا.

التواتر والتوقيت والتقسيم إلى شرائح

ابدأ بتحفّظ: إشعار إلى ثلاثة لكل مشترك أسبوعيًا، ولا توسّع إلا إذا صمدت معدلات إلغاء الاشتراك والنقر. ويظهر الإجهاد أسرع مما في البريد الإلكتروني لأن الكتم يكلّف نقرة واحدة على إشعار عرضه نظام التشغيل أصلًا.

والتوقيت ميزة وخطر معًا. الإشعار يصل فورًا، فرسالة أُرسلت في الثانية صباحًا تصل في الثانية صباحًا. خزّن أو استنتج المنطقة الزمنية للمشترك عند الاشتراك، واحصر الإرسال داخل نافذة محددة.

والتقسيم إلى شرائح مقيّد بما تعرفه عن اشتراك لا عن شخص، لذا فالأبعاد العملية سلوكية: الصفحات المشاهَدة، والمنتجات المراقَبة، وحالة العربة، وحداثة الشراء، والمنصة. ودليل تقسيم العملاء إلى شرائح يتعمق أكثر.

قياس إشعارات الويب

أربعة مقاييس تهم، وليست كلها قابلة للقياس بالطريقة نفسها.

• التسليم. هل قبلت خدمة الدفع الطلب. الاستجابة 201 تعني القبول لا التسليم. أما 404 أو 410 فتعني أن الاشتراك ميت.
• العرض. هل عُرض الإشعار. لا تعرف ذلك إلا إذا أبلغ عامل الخدمة عند اكتمال showNotification().
• معدل النقر إلى الظهور. النقرات مقسومة على مرات العرض. هذا هو الرقم الجدير بالتحسين.
• معدل إلغاء الاشتراك. إلغاءات الاشتراك وسحب الأذونات لكل إرسال. راقبه عن كثب أكثر من معدل النقر، لأنه المؤشر المتقدّم لموت القناة.

مزالق الإسناد

إسناد الإشعارات يجامل نفسه. فالإشعار يصل على جهاز يمسكه المشترك أصلًا، فينسب إلى نفسه غالبًا جلسة كانت ستحدث على أي حال. شغّل مجموعات ضابطة بدل افتراض الأثر التزايدي. ومرات العرض تُحسب بأقل من الواقع بينما تُسجَّل كل نقرة، فمعدل نقر محسوب على أساس الإرسالات يبالغ في الأداء. ولأن الاشتراك متصفح لا شخص، فإن إشعارًا نُقر عليه على هاتف وانتهى بشراء على سطح المكتب يبدو حدثين غير مرتبطين. ودليل مقاييس التسويق بالبريد الإلكتروني يغطي نظافة القياس عبر القنوات.

الموافقة وGDPR وإلغاء الاشتراك

نافذة إذن المتصفح بوابة تقنية. وهي ليست تلقائيًا أساسًا قانونيًا كاملًا للتسويق.

وحيثما تسوّق لأشخاص في الاتحاد الأوروبي أو المملكة المتحدة، عامل الإشعارات كما تعامل البريد الإلكتروني. اشرح ما ستُرسله قبل ظهور النافذة، لتكون الموافقة مستنيرة ومحددة. وسجّل متى وأين أُنشئ الاشتراك، ولا تدمج موافقة الإشعارات في إجراء لا صلة له بها أبدًا. وإن ربطت الاشتراكات بعملاء معرّفين، فتلك البيانات تقع ضمن التزاماتك تجاه البيانات الشخصية، بما فيها طلبات الحذف.

ونظافة إلغاء الاشتراك لا تقل أهمية. وفّر أداة تفضيلات داخل الموقع حتى يستطيع الناس تقليل التواتر بدل الحظر، واستدعِ PushSubscription.unsubscribe() واحذف السجل على الخادم حين يفعلون، وامسح الاشتراكات عند ورود 404 أو 410. وإرشاد MDN قصير وصحيح: يجب أن يُمنح المستخدمون “طريقة سهلة للانسحاب من تلقّي المزيد مستقبلًا”.

أين تقع إشعارات الويب في منظومة القنوات

إشعارات الويب قناة ثالثة جيدة وقناة أولى سيئة: سريعة، ومجانية عند الحد، ولا تُضاهى في التنبيهات الحرجة زمنيًا، لكنها مقيّدة بالجهاز، وغير قابلة للتصدير، وعلى بعد نقرة واحدة من الخسارة الدائمة.

وهذا يجعل التنسيق هو المشكلة الحقيقية. أي رسالة تذهب إلى أي قناة، وكيف تكبح البريد حين حوّل الإشعار بالفعل، وكيف تحافظ على رؤية واحدة للعميل عبر أسطح تعرّف الأشخاص بطرق مختلفة. يقدّم Brevo إشعارات الويب والهاتف إلى جانب البريد الإلكتروني والرسائل النصية، وتجلس Tajo فوق Brevo لتنسيق هذا المنطق عبر القنوات لمتاجر Shopify. أما جانب الرسائل النصية فراجع دليل أتمتة الرسائل النصية.

الخلاصات الأساسية

• إشعارات الويب ثلاث واجهات تتعاون: عامل خدمة للتنفيذ في الخلفية، وواجهة Push للاشتراك والنقل، وواجهة Notifications للعرض. والاشتراك نقطة طرفية إضافة إلى مفتاح p256dh وسرّ auth، والحمولات مشفّرة من طرف إلى طرف، وVAPID يثبت هوية المرسل.
• صارت الإشعارات متاحة على نطاق واسع ضمن Baseline منذ مارس 2023، لكنها على iOS وiPadOS تعمل فقط لتطبيقات الويب المضافة إلى الشاشة الرئيسية.
• لا تطلب الإذن أبدًا عند تحميل الصفحة. استخدم طلبًا تمهيديًا لطيفًا، واطلب في سياقه، وتذكّر أن الحظر دائم لذلك النطاق.
• تفرض Chrome الآن نوافذ أهدأ وحدود معدل وسحبًا تلقائيًا للإذن، فالإرسال السيئ يكلّفك مشتركين تملكهم أصلًا.
• الاشتراك متصفح لا شخص، وهو غير قابل للتصدير. ابنِ القائمة البريدية أولًا واستخدم الإشعارات لتسريعها.