لقد بنيت قائمة المشتركين لديك في الإشعارات دفعة واحدة، كل اشتراك تم الحصول عليه بشق الأنفس، وكل اشتراك كلف أموالاً حقيقية للاستحواذ. لذلك، عندما يحين وقت تبديل موفري إشعارات الدفع، يكون الخوف محدداً: إلغاء العقد القديم واختفاء القائمة معه. قد يخبرك بائعك الحالي بذلك بالضبط.
هذا غير صحيح، وهذا الدليل يوضح لك السبب على مستوى المتصفح. يرتبط اشتراك إشعارات الدفع على الويب بنطاقك، وليس ببائعك. بمجرد رؤية الآليات، يتحول كل تبديل إلى أحد سيناريوهين واضحين، وقائمة قصيرة من الأسئلة المكتوبة لبائعك الحالي، وقائمة تحقق مدتها أسبوع واحد يمكن لفريقك تنفيذها دون دراما.
ملاحظة صادقة في البداية. سيخبرك فريق المبيعات لدى كل بائع، بما في ذلك فريقنا، أن الترحيل سهل. معظمهم يتوقفون عند هذا الحد. يعرض لك هذا المنشور الآلية بدلاً من ذلك، حتى يتمكن مطورك من التحقق من كل ادعاء، بما في ذلك الادعاءات التي نقدمها في النهاية.
ما هو اشتراك إشعارات الدفع على الويب فعليًا
عندما ينقر الزائر على "السماح" على موقعك، يقوم المتصفح بإنشاء اشتراك إشعارات دفع على الويب يعتمد على ثلاثة أجزاء:
- أصلك. النطاق الدقيق الذي تم منح الإذن عليه (
https://yoursite.com). يظل الإذن في المتصفح، مرتبطًا بالأصل. لا يذكر أي بائع. - عامل خدمة. ملف JavaScript صغير مستضاف على نطاقك يستقبل ويعرض الإشعارات. أي عامل خدمة مسجل يتحكم في التسليم.
- مفتاح خادم التطبيق. النصف العام لزوج مفاتيح VAPID. خدمة الدفع الخاصة بالمتصفح تقبل فقط الإرسالات الموقعة بالمفتاح الخاص المطابق. أي شخص يمتلك هذا المفتاح الخاص يمكنه إرسال رسائل إلى الاشتراك. (نظرة عامة على إشعارات الدفع على web.dev تغطي البروتوكول الكامل.)
سجل الاشتراك نفسه عبارة عن ثلاثة سلاسل نصية: عنوان URL لنقطة النهاية بالإضافة إلى مفتاحين قصيرين، p256dh و auth. هذا هو الأصل بأكمله. قائمتك بأكملها هي جدول بهذه السجلات.
قاعدة واحدة تقرر كل شيء لاحقًا: تقبل المتصفحات الإرسالات فقط من حامل المفتاح الخاص VAPID المطابق. مما يعني أن كل تبديل للبائع يتحول إلى سيناريوهين بالضبط، اعتمادًا على مكان وجود هذه المفاتيح.
السيناريو أ: مفاتيح VAPID الخاصة بك تنتقل، لذا يمكنك استيراد مشتركي الدفع في اليوم الأول
ينطبق السيناريو أ عندما تكون المفاتيح ملكك لتأخذها: لقد قمت بتكوين مفاتيح VAPID الخاصة بك أو مشروع Firebase الخاص بك عند الإعداد، أو يوافق بائعك الحالي على تسليم زوج المفاتيح. يقوم بعض الفرق بإعداد هذا بشكل متعمد من اليوم الأول؛ يتم تغطية النهج في دليلنا لـ تنفيذ إشعارات الدفع دون تقييد البائع.
بمجرد حصولك على المفتاح الخاص، يمكن لمزودك الجديد استيراد مشتركين الدفع مباشرة: كل نقطة نهاية، وسجل p256dh، وسجل auth تنتقل، ويمكنك إرسال رسائل إلى قائمتك الحالية بأكملها من اليوم الأول. وهذا يشمل المشتركين غير النشطين الذين لم يزوروا الموقع منذ شهور. لا أحد يعيد الاشتراك. لا أحد يلاحظ.
هناك فارق بسيط يستحق التوضيح. حتى في السيناريو أ، يكتمل الترحيل الدائم من خلال الزيارات المتكررة، لأن كل مشترك يحتاج في النهاية إلى الانتقال إلى عامل الخدمة الجديد. المفاتيح المستوردة تمنحك وصولاً في اليوم الأول أثناء حدوث هذا الترحيل بهدوء في الخلفية.
السيناريو ب: تبقى المفاتيح، ويتولى إعادة الاشتراك الصامتة
السيناريو ب هو الإعداد الافتراضي الشائع: يقوم البائع بإنشاء مفاتيح VAPID والاحتفاظ بها. بدون المفتاح الخاص، تكون السجلات المصدرة عديمة الفائدة من الناحية التشفيرية. الوصول في اليوم الأول هو صفر، وتحذير البائع القديم يبدو صحيحًا لمدة فقرة أخرى.
إليك ما يحدث بالفعل. في المرة التالية التي يزور فيها كل مشترك موقعك، يتولى عامل الخدمة الخاص بالمزود الجديد زمام الأمور: يقوم بإلغاء تسجيل التسجيل القديم، وإلغاء الاشتراك في الاشتراك القديم، وإعادة الاشتراك للزائر ضمن المفاتيح الجديدة. بهدوء، في زيارة واحدة، بدون مطالبة ثانية بالإذن.
لماذا لا يحتاج عامل الخدمة الجديد إلى مطالبة ثانية
تم منح إذن الإشعارات للمصدر الخاص بك، وليس للبائع. المتصفح يثق بالفعل في نطاقك. تبديل عامل الخدمة والمفاتيح تحت إذن ممنوح بالفعل غير مرئي للزائر، لأن المتصفح يعامله على أنه موقعك يقوم بإعادة تنظيم سباكته الخاصة. وهذا بالضبط ما هو عليه.
فخاخ يجب أن يعرفها مطورك
مصدر واحد، اشتراك واحد. لا يمكن للمتصفح الاحتفاظ باشتراكين للدفع لنفس المصدر. الاشتراك بمفتاح مختلف يفشل حتى يتم تحرير الاشتراك القديم. لذا فإن "تشغيل كلا البائعين بالتوازي" يعمل على مستوى القائمة، وليس داخل متصفح واحد: كل مشترك إما مع البائع القديم أو الجديد، وكل زيارة متكررة تنقل واحدًا آخر.
اشتراكات النطاق الفرعي للبائع لا تنتقل أبدًا. الاشتراكات التي تم جمعها على yoursite.vendor.com تنتمي إلى مصدر البائع، ولا يمكن لأي مزود ترحيلها. هذه القاعدة تُعاد بناؤها من الصفر. إنها أكبر فخ في أي ترحيل لإشعارات الدفع، وأقوى حجة لربط الاشتراكات بنطاق تتحكم فيه هذه المرة. إذا كنت تدير عدة علامات تجارية أو نطاقات إقليمية، فإن منطق المصدر نفسه يشكل بنيتك بأكملها؛ نغطيها في دفع الويب عبر نطاقات متعددة.
إليك السيناريوهان جنبًا إلى جنب:
| السيناريو أ: تنتقل المفاتيح | السيناريو ب: تبقى المفاتيح | |
|---|---|---|
| متى ينطبق | امتلاك مفاتيح VAPID / مشروع Firebase خاص، أو يقوم البائع بإصدار الزوج | قام البائع بإنشاء المفاتيح والاحتفاظ بها (الإعداد الافتراضي الشائع) |
| الوصول في اليوم الأول | قائمتك بأكملها، بما في ذلك المشتركون غير النشطين | صفر، حتى يعود الزوار |
| عند كل زيارة متكررة | ينتقل المشترك بهدوء إلى المفاتيح الجديدة | إعادة اشتراك صامتة ضمن المفاتيح الجديدة، بدون مطالبة ثانية |
| من تستعيد | الجميع | كل من يزور مرة أخرى |
| من تخسر | لا أحد | المشتركون الذين لا يعودون أبدًا (والذين لم يعد من الممكن تحقيق إيرادات منهم على أي حال) |
لماذا تنهي الجماهير التي تزور يوميًا هجرة الإشعارات الفورية بأسرع وقت
في السيناريو ب، فإن ساعة الاستحواذ هي تكرار زيارة جمهورك. لا شيء آخر. قد يزور مشترك التجارة الإلكترونية شهريًا، لذا يمتد الاستحواذ عبر الأشهر. يقوم المراهن بالتحقق من الاحتمالات والخطوط والنتائج يوميًا. يعود قارئ الأخبار لكل دورة عناوين.
هذا الإيقاع العائد هو سبب كون مواقع المراهنات والأخبار هي القطاعات الأفضل تجهيزًا على الإنترنت للتبديل بين مزودي الإشعارات الفورية: نفس تكرار الزيارة الذي يجعل الإشعارات الفورية لمواقع المراهنات محركًا للاحتفاظ يضغط أيضًا على هجرة تستغرق مواقع أخرى ربع سنة في أسبوع أو أسبوعين. أرسلت مواقع المراهنات والألعاب على PushEngage أكثر من 3.5 مليار إشعار، لذا فإن آليات الاستحواذ هذه هي واقع إنتاج يومي بالنسبة لنا، وليست نظرية.
| نمط عودة الجمهور | الاستحواذ النموذجي للقاعدة النشطة |
|---|---|
| الزوار اليوميون (احتمالات مباشرة، أخبار عاجلة، عروض يومية) | أيام إلى حوالي أسبوع |
| عدة زيارات في الأسبوع (مراهنون في عطلة نهاية الأسبوع، منتظمون) | 1-2 أسبوع |
| أسبوعيًا أو أقل (زوار موسمييون، مستخدمون سابقون) | أسابيع، تتسارع بسبب إرسالات البائع القديم والأحداث الكبرى |
| خامل (لم تتم زيارته منذ أشهر) | يمكن استرداده فقط في ظل السيناريو أ |
هذه هي الأنماط النموذجية للجماهير التي تزور يوميًا، وليست ضمانات؛ منحناك يعتمد على إيقاع حركة المرور الخاصة بك، وستراقبه مباشرة في لوحة التحكم. يمكنك أيضًا ثني المنحنى: جدولة الانتقال في الأسبوع السابق لعطلة نهاية أسبوع رئيسية، وحركة مرور الأحداث تقوم بالاستحواذ نيابة عنك. مواقع المراهنات التي تخطط لـ تسلسل إشعارات يوم المباراة تعرف بالفعل عطلات نهاية الأسبوع تلك.
إشعارات التطبيق أسهل: رموزك كانت ملكك دائمًا
إذا كنت ترسل أيضًا إشعارات التطبيق، خذ نفسًا عميقًا. هذا النصف سهل هيكليًا، لأنه لا يمكن لأي بائع احتجازه كرهينة.
يتم إصدار شهادات ومفاتيح APNs لحساب مطور Apple الخاص بك. مشروع FCM الخاص بك يعيش في وحدة تحكم Google الخاصة بك. مزود الإشعارات هو طبقة فوق بيانات الاعتماد التي تمتلكها، لذا فإن التبديل يعني توجيه طبقة جديدة إلى نفس بيانات الاعتماد. يتم تصدير رموز الأجهزة واستيرادها بشكل نظيف، دون إعادة تثبيت ودون مطالبة إذن ثانية.
ملاحظتان عمليتان. أولاً، قم بتصفية تصديرات الرموز للأجهزة النشطة تقريبًا لمدة 270 يومًا قبل الاستيراد، لأن FCM يعامل الرموز غير النشطة بعد حوالي 270 يومًا على أنها قديمة. تفريغ رموز لمدة خمس سنوات يضخم عدد المشتركين لديك، وعلى التسعير الذي يحسب المشتركين النشطين فقط، لا يستفيد أحد من ذلك. ثانيًا، يصل تغطية SDK الكاملة بسرعة تحديث المستخدمين لتطبيقك، عادةً ما يكون أسبوعًا أو أسبوعين لتطبيق الاستخدام اليومي مع التحديثات التلقائية.
إذا كان تطبيق iOS الخاص بك يرسل حاليًا عبر Firebase، فإن التدفق خطوة بخطوة هو موضوع بحد ذاته؛ راجع دليلنا لـ الهجرة من Firebase Cloud Messaging على iOS بدلاً من الارتجال من هذه المشاركة.
قبل تبديل مزودي الإشعارات الفورية، اطرح هذه الأسئلة الستة كتابيًا
تختلف تصديرات البائعين وسياسات المفاتيح، وهي تتغير. بدلاً من الثقة في أي جدول لقرارات البائعين (بما في ذلك جدول يمكننا نشره)، احصل على إجابات البائع الخاص بك بشكل رسمي. البريد الإلكتروني يعمل؛ تذكرة الدعم تعمل بشكل أفضل. إذا كنت تقيّم الوجهات في نفس الوقت، فإن نفس الأسئلة تشكل فحصًا مفيدًا أثناء مقارنة بدائل OneSignal.
- هل يمكنك تصدير سجلات اشتراك دفع الويب الكاملة الخاصة بي - عنوان URL لنقطة النهاية بالإضافة إلى مفاتيح
p256dhوauthلكل مشترك - أم المعرفات الداخلية فقط؟ المعرفات الداخلية لا معنى لها خارج نظام البائع. - هل ستصدر زوج مفاتيح VAPID الذي تم إنشاء اشتراكاتي بموجبه؟ هذه الإجابة الواحدة تقرر السيناريو أ مقابل السيناريو ب.
- على أي مشروع FCM أو Firebase يعمل دفع الويب الخاص بي، مشروعي أم مشروعك؟ إذا كان مشروعك، فقد تكون المفاتيح موجودة بالفعل في وحدة التحكم الخاصة بك.
- هل يمكنني تصدير الشرائح والعلامات وسمات المشترك وقوائم الحظر بشكل منفصل؟ لا يتم نقلها مع سجلات الاشتراك تلقائيًا.
- هل يمكنني تصدير رموز أجهزة دفع التطبيق الخاصة بي، وبأي تنسيق؟
- ماذا يحدث لبياناتي إذا قمت بالترقية أو الإلغاء - هل هناك حذف تلقائي أو فترة احتفاظ؟ يقوم بعض البائعين بحذف بيانات المشترك غير النشط في المستويات الأدنى. قم بالتصدير أولاً، دائمًا.
قائمة التحقق لأسبوع الترحيل
اطبع هذا القسم. ثماني خطوات، بالترتيب.
- قم بتصدير كل شيء قبل إلغاء أو تخفيض أي شيء. سجلات الاشتراك، رموز التطبيق، الشرائح، العلامات، السمات، قوائم الحظر. يصل الوصول إلى التصدير مع عقدك.
- احصل على إجابة مفاتيح VAPID كتابيًا. إنها تقرر السيناريو الخاص بك وما إذا كان يمكنك استيراد مشتركي الدفع في اليوم الأول.
- انقل قوائم الحظر أولاً، وليس أخيرًا. بالنسبة لمشغلي المراهنات والألعاب، هذا أمر غير قابل للتفاوض: يجب حظر اللاعبين الذين استبعدوا أنفسهم على المنصة الجديدة قبل استئناف أي حملة، وليس تسويتها لاحقًا.
- قم بتصفية رموز التطبيق لتكون نشطة لمدة ~270 يومًا قبل الاستيراد.
- قم بتثبيت حزمة تطوير البرامج (SDK) وعامل الخدمة الجديدين، وادمج مع أي عامل خدمة موجود (غلاف PWA، عامل البائع القديم) بدلاً من الكتابة فوقه.
- لا تحذف ملف عامل الخدمة للبائع القديم في اليوم الأول. لا يزال الزوار العائدون يحملون تسجيلات تشير إليه؛ الاستيلاء عليهم يلغي تسجيلهم بسلاسة. قم بإزالة الملف مبكرًا وستقوم بإنشاء أخطاء في وحدة التحكم بدلاً من عمليات الترحيل. قم بإزالته عند الإزالة النهائية.
- استمر في إرسال البائع القديم خلال النافذة المتوازية. هذا يتعارض مع الحدس ولكنه حاسم: كل إشعار يرسله البائع القديم يؤدي إلى زيارة مرة أخرى، وكل زيارة مرة أخرى تكمل ترحيل مشترك آخر. يصبح البائع الصادر الخاص بك أفضل أداة ترحيل لك.
- قم بقياس الاستيلاء يوميًا وقم بالتبديل عند الهضبة. تتبع القاعدة النشطة الجديدة مقابل القاعدة النشطة القديمة. عندما يستوي المنحنى، قم بإنهاء الإزالة، وإلغاء العقد القديم، وأرشفة التصديرات.
تكاليف التبديل عندما يقوم PushEngage بذلك نيابة عنك
في PushEngage، الترحيل هو خدمة فاخرة مجانية مضمنة في الخطط المدفوعة. تحصل على مهندس ترحيل، وليس مقالاً من مركز المساعدة: فهم يتعاملون مع تعيين التصدير، ومعالجة المفاتيح، ودمج عامل الخدمة، وخطة الاستيلاء. هذا مهم لأن حالات الفشل تكون صامتة - قد يؤدي الاستيراد الخام بتنسيقات حمولة غير متطابقة إلى إشعارات ناجحة تقنيًا ولكنها فارغة، وهذا هو بالضبط فئة الفشل الصامت الذي يلتقطه المتخصص قبل مشتركيك.
تستغرق مكالمة النطاق حوالي خمسة عشر دقيقة: عدد المشتركين لكل قناة، والمورد الحالي، وأسئلة المفاتيح المذكورة أعلاه. بنهاية المكالمة، ستعرف ما إذا كنت في السيناريو أ أو ب، ولديك خطة مؤرخة.
إذا كنت مستعدًا لتبديل مزودي إشعارات الدفع، فابدأ بالأسئلة الستة المكتوبة في هذا المنشور وانظر كيف يجيب موردك الحالي. ثم انظر إلى ما ستفعله منصة إشعارات الدفع عبر الويب المبنية حول التقسيم وإسناد الإيرادات مع القائمة التي تمتلكها بالفعل، وتحقق من أسعار PushEngage مقابل فاتورتك الحالية. تحمل كل خطة مدفوعة ضمان استعادة الأموال لمدة 14 يومًا، لذا فإن ترحيل إشعارات الدفع نفسه هو الجزء الأقل خطورة في القرار.