يمنحك نظام iOS فرصة واحدة بالضبط لطلب إذن الدفعات باستخدام النافذة الأصلية. إذا نقر المستخدم على "عدم السماح"، يتم إخفاء هذا القرار في تطبيق الإعدادات حيث لا يذهب إليه أحد تقريبًا لعكسه. يجب أن تشكل هذه الحقيقة الوحيدة استراتيجيتك بالكامل لإذن إشعارات الدفع على نظام iOS - وهي السبب في أن التطبيقات ذات أعلى معدلات الموافقة نادرًا ما تعرض نافذة Apple الأصلية بشكل مباشر.
يغطي هذا الدليل كيفية عمل إذن نظام iOS فعليًا، ونمط التمهيد الذي يحمي فرصتك الوحيدة، وكيفية تنفيذ التدفق بأكمله ببضعة أسطر من كود SDK.
كيف يعمل إذن الدفعات على نظام iOS فعليًا
يقع كل تطبيق في إحدى حالات الإذن الثلاث: لم يُسأل المستخدم بعد، أو وافق المستخدم على الإذن، أو رفضه. النافذة الأصلية للنظام - التي تعرضها Apple، بصياغة لا يمكنك تغييرها - تنقل المستخدم من الحالة الأولى بشكل دائم. لا توجد نافذة أصلية ثانية. بمجرد الرفض، فإن الطريق الوحيد للعودة يمر عبر تطبيق الإعدادات، ومعدلات الاسترداد من الإعدادات ضعيفة بما يكفي بحيث يجب أن تعامل الرفض على أنه نهائي تقريبًا.
قارن ذلك بنظام Android، حيث كان إذن الإشعارات افتراضيًا في السابق. إنه السبب الرئيسي وراء تشغيل معدلات الموافقة على نظام iOS بالقرب من 51٪ بينما يعمل نظام Android بالقرب من 81٪، كما غطينا في دليل تسويق الدفعات للتطبيقات. على نظام iOS، يتم كسب الموافقة. الميزة: المشترك الذي قال "نعم" عن قصد يستحق أكثر، ويتفاعل أكثر، ويتخلى عن الخدمة بشكل أقل من المشترك الافتراضي. وظيفتك هي تهيئة الظروف قبل طرح السؤال.
لماذا التوقيت يتفوق على النسخ
الخطأ الأكثر شيوعًا في إذن نظام iOS هو خطأ هيكلي، وليس لفظي: تشغيل النافذة الأصلية عند أول تشغيل، قبل أن يكون لدى المستخدم أي فكرة عما يفعله التطبيق أو لماذا ستساعده الإشعارات. في تلك اللحظة، تكون الإجابة الصادقة على "هل يجب أن أسمح لهذا التطبيق بمقاطعتي؟" هي لا - ليس لدى المستخدم أي دليل بأي شكل من الأشكال، و"لا" هو الخيار الافتراضي الآمن.
الحل هو السؤال في لحظة قيمة - نقطة في الجلسة تكون فيها فائدة الإشعار ملموسة وواضحة:
- متسوق التجارة الإلكترونية يحفظ عنصرًا في قائمة الرغبات → "هل تريد معرفة متى ينخفض السعر؟"
- متسوق يكمل عملية شراء → "هل تريد تحديثات الشحن لهذا الطلب؟"
- قارئ ينهي مقالًا ثانيًا → "هل تريد تنبيهًا عندما ننشر حول هذا الموضوع؟"
- مستخدم ينهي الإعداد الأولي ويحقق نجاحه الأول → "هل تريد منا إخبارك عندما يحدث X؟"
نفس النافذة، نفس الصياغة من Apple - إجابة مختلفة بشكل كبير، لأن السؤال أصبح لديه سياق أخيرًا.
نمط التمهيد: طلب ناعم قبل الطلب الحقيقي
التمهيد يعني عرض شاشتك الخاصة داخل التطبيق - مربع حوار ما قبل الإذن الذي تتحكم فيه بالكامل - قبل تشغيل نافذة Apple الأصلية. للنمط قاعدة واحدة تجعله يعمل: قم بتشغيل النافذة الأصلية فقط بعد أن يوافق المستخدم على نافذتك.
إذا وافق المستخدم على طلبك اللطيف، فقد اتخذ قراره بالفعل؛ المطالبة الأصلية هي مجرد إجراء شكلي وتحقق معدلات تحويل عالية جدًا. إذا رفضوا طلبك اللطيف، فلم تخسر شيئًا - لم يتم عرض المطالبة الأصلية مطلقًا، ولا يزال الطلب لمرة واحدة قيد التشغيل، ويمكنك إعادة تشغيل الطلب اللطيف في وقت أفضل بعد أسابيع. يمكن تكرار الطلب اللطيف بشكل لا نهائي؛ مطالبة Apple ليست كذلك.
يحدد الطلب اللطيف الجيد القيمة المحددة ("تنبيهات انخفاض الأسعار على العناصر المحفوظة لديك")، ويظهر كيف ستبدو الإشعارات، ويقدم خيار رفض حقيقي لا يسبب الشعور بالذنب. تنطبق نفس المبادئ وراء المطالبات التي تحقق معدلات تحويل عالية للاشتراك في إشعارات الويب - التحديد يحقق التحويل، والغموض لا يحقق ذلك.
تنفيذ التدفق باستخدام PushEngage SDK
يمنحك iOS SDK 1.0 المكالمتين اللتين يحتاجهما هذا التدفق: واحدة للتحقق من الحالة الحالية، وواحدة لتشغيل المطالبة الأصلية في اللحظة التي تختارها.
// 1. Check state before deciding what UI to show
let status = PushEngage.getNotificationPermissionStatus()
switch status {
case "notYetRequested":
showSoftAskScreen() // your own UI — the native prompt is untouched
case "denied":
showSettingsNudgeIfEarned() // deep link to Settings, only at a high-value moment
case "granted":
break // already subscribed — get out of the way
default:
break
}
// 2. Only after the user accepts YOUR screen:
PushEngage.requestNotificationPermission { granted, error in
if granted {
// subscribed — thank them with value, not a welcome blast
}
}لاحظ ما يفرضه الكود: يتم تشغيل المطالبة الأصلية من داخل معالج قبول طلبك اللطيف وليس في أي مكان آخر. لا مفاجأة عند الإطلاق، ولا طلقة ضائعة.
استعادة المستخدمين الذين قالوا لا
بالنسبة للمستخدمين في حالة الرفض، تختفي المطالبة الأصلية، لكن اللعبة لم تنته بعد. خطة الاستعادة هي رابط إعدادات عميق - UIApplication.openNotificationSettingsURLString يأخذ المستخدم مباشرة إلى تبديل الإشعارات الخاص بتطبيقك. احفظه للحظات عندما يطلب المستخدم بنشاط شيئًا ستوفره الإشعارات ("احصل على إشعار عندما يعود المخزون" → "الإشعارات متوقفة لهذا التطبيق - قم بتشغيلها في الإعدادات؟"). تذكير الإعدادات في لحظة عشوائية يبدو مزعجًا؛ نفس التذكير في لحظة الرغبة الفورية يبدو مساعدة.
قِسْها كمقياس نمو هي عليه
معدل الاشتراك هو المضاعف لكل حملة دفعات ستشغلها على الإطلاق، مما يجعلها تستحق التنفيذ بشكل صحيح: تتبع قبول الطلب اللطيف وتحويل المطالبة الأصلية بشكل منفصل، وقسّم حسب لحظة التشغيل التي أطلقت الطلب، وتحقق من حالة الاشتراك باستخدام getSubscriptionNotificationStatus - الذي يتحقق من كل من الاشتراك والإذن - قبل عد أي شخص على أنه قابل للوصول. عشر نقاط تحسين في معدل الاشتراك تتراكم عبر كل حملة، كل أسبوع، طوال عمر التطبيق.
الإذن هو البوابة. بمجرد أن يتجاوز المستخدمها، كل شيء آخر - الحملات المشغلة، التقسيم، رحلات التنقيط - يعمل من لوحة تحكم PushEngage دون سطر آخر من كود التطبيق. دليل إعداد iOS يأخذك من تثبيت SDK إلى حملتك الأولى في فترة ما بعد الظهيرة.
