إظهار رسالة داخل التطبيق قبل طلب إذن الإشعارات

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

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

استخدم هذا الدليل إذا كنت ترغب في تصميم طلب HTML واحد متعدد المنصات في لوحة التحكم وتشغيله بواسطة حدث على كل من iOS و Android.

استخدم دليلاً مختلفًا إذا:

• سيقوم فريقك بشحن طلب خاص بـ iOS فقط في كود التطبيق (غير قابل للتعديل في لوحة التحكم، ولا يبدأ بحدث Journey): تمهيد إشعارات iOS.
• تحتاج إلى إعادة إشراك المستخدمين الذين عطلوا الإشعارات بالفعل أو لم يمنحوها أبدًا (للاستعادة فقط، وليس الطلب الأول): إنشاء نوافذ منبثقة لاستعادة الموافقة والرفض.

قبل أن تبدأ

مطلوب مساعدة المطور

أنت تقوم ببناء القالب في لوحة التحكم. شارك دليل الأحداث و postEvent مع فريق التطوير الخاص بك — فهم يتعاملون مع المتطلبين الأساسيين أدناه.

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

اعمل مع فريق التطوير الخاص بك على هذه المتطلبات الأساسية:

1. تأكد من أن التطبيق لا يطلب إذن الإشعارات في وقت سابق (بما في ذلك عند التشغيل الأول).
2. اتفق على اسم حدث مخصص ومتى يتم إطلاقه، على سبيل المثال onboarding_completed مباشرة بعد الإعداد الأولي، أو locked_feature_tapped عندما ينقر المستخدم على ميزة تحتاج إلى إشعارات. سيقوم فريقك باستدعاء postEvent بهذا الاسم. تعرف على المزيد حول الأحداث.

إنشاء الرسالة داخل التطبيق

الأزرار في هذا الدليل تعمل على JavaScript مخصص، والذي يعمل فقط في قالب رسالة داخل التطبيق قائم على HTML. لا يمكن لـ قالب رسالة داخل التطبيق الأصلي تشغيل هذا الكود، لذا لا تقم ببناء القالب باستخدام in-app أصلي.

1. اذهب إلى المحتوى ← الرسائل داخل التطبيق وانقر على إنشاء رسالة داخل التطبيق لفتح المحرر المدمج مباشرة.

2. أدخل اسمًا للقالب.

3. افتح علامة التبويب الكتل في اللوحة اليمنى وأضف كتلة نص أو عنوان مع عرضك التقديمي لتمكين الإشعارات.

4. أضف كتلة زر لإجراء القبول وأخرى لإجراء الرفض. يمكن لكلا الزرين تشغيل JavaScript الخاص بهما بمجرد تحميل الرسالة داخل التطبيق، دون الحاجة إلى انتظار أي شيء آخر.

نصيحة

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

5. حدد زر القبول واضبط نوع الإجراء على JavaScript مخصص.
6. الصق الكود أدناه فقط في onClick.

pushwoosh.registerForPushNotifications();
pushwoosh.closeInApp();

7. حدد زر الرفض واضبط نوع الإجراء على JavaScript مخصص.
8. الصق هذا فقط في onClick:

pushwoosh.closeInApp();

بعد حفظ القالب:

• زر القبول: يظهر مربع حوار إذن النظام.
• زر الرفض: تُغلق الرسالة داخل التطبيق ولا يظهر مربع حوار النظام.

رسالة داخل التطبيق لطلب الإذن المسبق معروضة قبل طلب النظام

نصيحة

لتحميل ZIP / المطور فقط: إذا قمت بإنشاء ملف HTML خام لـ تحميل ZIP، استخدم العلامات الكاملة هناك بدلاً من حقل onClick في المحرر:

<button onclick="pushwoosh.registerForPushNotifications(); pushwoosh.closeInApp();">تمكين الإشعارات</button>
<button onclick="pushwoosh.closeInApp();">ليس الآن</button>

تخطي الطلب للمستخدمين الذين وافقوا بالفعل

أضف شرط عرض حتى تخفي الرسالة داخل التطبيق نفسها للمستخدمين الذين منحوا الإشعارات بالفعل، حتى لو أظهر مشغل لاحق القالب مرة أخرى. تأتي حالة الموافقة على الإشعارات من Push Alerts Enabled، وهو وسم منطقي افتراضي يضبطه SDK من إذن إشعارات نظام الجهاز.

1. في لوحة الطبقات، انقر على الكتلة الأولى، ثم انقر مع الضغط على مفتاح Shift على كل كتلة أخرى لتحديد القالب بأكمله معًا.
2. قم بتشغيل إظهار هذه الكتلة بشكل شرطي. القاعدة التي تضبطها أدناه تنطبق على التحديد بأكمله مرة واحدة.
3. اضبط القاعدة على Push Alerts Enabled is false.
4. تحت إذا كانت القيمة غير معروفة، اختر إظهار الكتلة. يجب أن يرى التثبيت الجديد الذي لا يحتوي على قيمة وسم بعد الطلب.

تنبيه

يتم تحديث Push Alerts Enabled عند فتح التطبيق التالي للجهاز، وليس في اللحظة التي يغير فيها المستخدم مفتاح الإذن في إعدادات النظام. لا يزال بإمكان المستخدم الذي يمكّن الإشعارات من الإعدادات رؤية هذه الكتلة مرة أخرى حتى يعيد فتح التطبيق.

تشغيل الرسالة داخل التطبيق قبل طلب الإذن

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

1. اطلب من فريق التطوير الخاص بك استدعاء postEvent باسم الحدث المتفق عليه في اللحظة التي تريد فيها السؤال.
2. اذهب إلى منشئ رحلة العميل ← إنشاء حملة وابدأ بـ إدخال قائم على المشغل يستمع إلى ذلك الحدث.
3. أضف عنصر رسالة داخل التطبيق وحدد القالب الذي أنشأته. تعرف على المزيد حول إرسال الرسائل داخل التطبيق عبر رحلة العميل.
4. أطلق الرحلة عندما تكون مستعدًا لإظهار الطلب.

ملاحظة

لا تظهر الرسالة داخل التطبيق في اللحظة التي يتم فيها إطلاق الحدث. يتم التسليم عند فتح التطبيق التالي للجهاز بعد ذلك.

سيناريو مثال: طلب إذن الإشعارات مباشرة بعد الإعداد الأولي

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

1. أنشئ الحدث onboarding_completed وتأكد من أن فريق التطوير الخاص بك يطلقه عندما ينهي المستخدم تدفق الإعداد الأولي. تعرف على المزيد حول إنشاء الأحداث
2. اضبط onboarding_completed كمشغل لرحلتك، باستخدام إدخال قائم على المشغل.
3. أضف عنصر رسالة داخل التطبيق وحدد قالب الإذن المسبق الذي أنشأته.
4. أطلق الرحلة.

كل مستخدم يكمل الإعداد الأولي يرى الطلب مرة واحدة. شرط العرض من تخطي الطلب للمستخدمين الذين وافقوا بالفعل يمنعه من الإطلاق مرة أخرى للمستخدمين الذين منحوا الإشعارات بالفعل.

تحقق من أنه يعمل

طلب النظام يظهر مرة واحدة فقط، لذا يتطلب اختبار كلا الزرين جهازين اختبار (أو تثبيتين جديدين) لم يمنحا أو يرفضا الإشعارات بعد، واحد لكل زر. على كل جهاز:

1. أطلق الحدث المتفق عليه من التطبيق.
2. أعد فتح التطبيق وتأكد من أن الرحلة تسلم رسالتك داخل التطبيق.

ثم:

3. على الجهاز الأول، انقر على زر القبول وتأكد من ظهور مربع حوار إذن النظام.
4. على الجهاز الثاني، انقر على زر الرفض وتأكد من إغلاق الرسالة داخل التطبيق دون ظهور مربع حوار النظام.
5. بعد فتح التطبيق التالي، تأكد من أن Push Alerts Enabled يطابق حالة الإذن على كل جهاز.

إنشاء شريحة من المستخدمين الذين لا يزالون معطلين للإشعارات

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

1. في منشئ الشرائح، أضف مرشحًا بواسطة وسم Push Alerts Enabled.
2. اضبط المشغل على is false. تعرف على المزيد حول بناء الشرائح بواسطة الوسوم.

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

انظر أيضًا

• تمهيد إشعارات iOS: البديل الأصلي الخاص بـ iOS لهذا النهج القائم على HTML متعدد المنصات.
• إنشاء نوافذ منبثقة لاستعادة الرفض: استعادة المستخدمين الذين عطلوا الإشعارات بالفعل (ليس الطلب الأول)، باستخدام نفس وسم Push Alerts Enabled.
• إنشاء رسائل داخل التطبيق باستخدام JavaScript: المرجع الكامل لجسر JavaScript.