تطبيق iOS الخاص بك يعمل على Firebase Cloud Messaging. التسليم يعمل. لا شيء يحترق. ومع ذلك، لا يزال كل حملة مجزأة، وكل اختبار A/B، وكل طلب "هل يمكننا إرسال دفعة حول البيع" يهبط في قائمة انتظار الهندسة الخاصة بك، لأن FCM يمنحك قناة تسليم ولا شيء آخر. إذا بدا هذا مألوفًا، فإن هذا الدليل يوضح لك كيفية الانتقال من Firebase Cloud Messaging على iOS - دون خسارة مشترك، أو فرض إعادة تثبيت، أو عرض موجه إذن ثانٍ لمستخدميك.
النسخة المختصرة: على iOS، الهجرة هي تبديل طبقة، وليست إعادة بناء. إليك السبب، وكيفية القيام بذلك بالضبط.
ما يمنحك إياه FCM، وأين يتوقف
Firebase Cloud Messaging هو بنية تحتية مجانية وموثوقة. بالنسبة للكثير من فرق الهندسة، فهو الخيار الافتراضي، وللتسليم البحت، فهو خيار جيد. تظهر المشكلة في اليوم الذي يريد فيه فريق التسويق تشغيل حملات.
| القدرة | FCM | PushEngage |
|---|---|---|
| تسليم الإشعارات عبر APNs | نعم | نعم |
| التجزئة السلوكية | المواضيع فقط | شرائح ديناميكية، سمات، جغرافيا، جهاز |
| حملات مشغلة من أحداث التطبيق | ابنها بنفسك | تم تكوينه بواسطة لوحة التحكم |
| سلاسل التنقيط والرحلات | ابنها بنفسك | منشئ مرئي، قوالب |
| اختبار A/B | عبر وحدة تحكم Firebase، يقودها المطور | يقودها المسوق، اختيار الفائز الذكي |
| إسناد الإيرادات وتتبع الأهداف | لا | لكل حملة، لكل سير عمل |
| لوحة تحكم يمكن للمسوق الوصول إليها | لا | نعم |
النمط في هذا الجدول هو سبب تجاوز الفرق لـ FCM: كل شيء يتجاوز التسليم هو مشروع هندسي. للمقارنة الكاملة، انظر PushEngage مقابل Firebase Cloud Messaging.
ما يتم ترحيله فعليًا على iOS
خوف الهجرة دائمًا ما يتعلق بقائمة المشتركين: "إذا قمنا بتبديل حزم SDK، فهل نفقد المستخدمين الذين وافقوا؟" على iOS، الإجابة هي لا، ومن المفيد فهم السبب.
إذن الإشعارات على iOS ينتمي إلى تطبيقك، وليس إلى أي حزمة SDK. عندما منح المستخدم الإذن، فقد منحه لمعرف حزمة التطبيق الخاص بك، وتصدر Apple رمز جهاز APNs الذي يمكن لأي موفر دفع استخدامه. FCM على iOS هو في حد ذاته غلاف حول رمز APNs هذا. عندما تبدأ حزمة SDK الخاصة بـ PushEngage في العمل لأول مرة، فإنها تلتقط نفس إذن مستوى التطبيق، وتسجل رمز الجهاز مع PushEngage، ويكون المشترك مباشرًا - لا إعادة تثبيت، ولا إعادة مطالبة، ولا إجراء من المستخدم على الإطلاق.
هذا يعني أن قاعدة الموافقين لديك تنتقل مع وصول الأجهزة عبر الإنترنت بإصدار التطبيق المحدث. يصل الإصدار النموذجي إلى الغالبية العظمى من المستخدمين النشطين في غضون أسبوعين إلى ثلاثة أسابيع، وهي بالضبط الفترة التي يجب أن تخطط لتشغيل كلا النظامين بالتوازي.
الهجرة، خطوة بخطوة
الخطوة 1: إضافة حزمة SDK الخاصة بـ PushEngage
قم بالتثبيت عبر Swift Package Manager (موصى به) أو CocoaPods. الإصدار 1.0 يأتي كوحدتين: اربط PushEngage بهدف تطبيقك و PushEngageExtension بهدف امتداد خدمة الإشعارات الخاص بك.
# Podfile
target 'YourApp' do
pod 'PushEngage', '~> 1.0.0'
end
target 'YourNotificationServiceExtension' do
pod 'PushEngageExtension', '~> 1.0.0'
endالخطوة 2: التهيئة جنبًا إلى جنب مع إعدادك الحالي
import PushEngage
func application(_ application: UIApplication,
didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
PushEngage.setAppID(id: "YOUR_APP_ID")
PushEngage.setInitialInfo(for: application, with: launchOptions)
return true
}نظرًا لأن الإذن ممنوح بالفعل على مستوى التطبيق، يقوم المشتركون الحاليون بالتسجيل في PushEngage بصمت عند التشغيل الأول للبناء المحدث. يمر المستخدمون الجدد بتدفق الإذن العادي الخاص بك مرة واحدة.
الخطوة 3: تكوين مجموعة التطبيقات
أضف إمكانية مجموعات التطبيقات إلى هدف تطبيقك وكل هدف توسيع الإشعارات، باستخدام نفس معرف المجموعة، وأعلنه في كل Info.plist. هذه هي الطريقة التي يشارك بها التطبيق وملحقاته حالة المشترك، وهي الخطوة التي تعود إليها معظم أخطاء التكامل.
الخطوة 4: وجّه مفتاح APNs الخاص بك إلى PushEngage
قم بتحميل مفتاح المصادقة .p8 الحالي الخاص بك (أو شهادة .p12) في لوحة تحكم PushEngage - نفس بيانات الاعتماد التي قدمتها لـ Firebase. لا يتغير أي شيء في إعداد مطور Apple الخاص بك. يغطي دليل الإعداد هذه الشاشة تلو الأخرى.
الخطوة 5: تحقق، ثم اشحن
أرسل إشعارًا تجريبيًا من لوحة التحكم إلى جهاز تصحيح الأخطاء، وتأكد من عرض الوسائط الغنية من خلال الامتداد، وتأكد من ظهور المشترك في عرض جمهورك. ثم قم بالإصدار. ينمو عدد المشتركين لديك في PushEngage تلقائيًا مع طرح التحديث.
قم بتشغيل كلا النظامين أثناء الانتقال
لا تحتاج إلى قطع كامل، ولا يجب عليك القيام بذلك. احتفظ بـ FCM في مكانه لأي شيء متعلق بالمعاملات يرسله الواجهة الخلفية بالفعل، وانقل عمليات الإرسال التسويقية إلى PushEngage أثناء تسجيل المشتركين. يمكن لكلا SDK التعايش في نفس التطبيق - فهما يستهلكان نفس رمز APNs. بمجرد إعادة تسجيل قاعدة المستخدمين النشطين لديك ونقل حملاتك بالكامل، فإن إزالة تبعية Firebase Messaging هي مهمة تنظيف، وليست موعدًا نهائيًا.
ما يحصل عليه فريق التسويق الخاص بك في اليوم الأول
الهدف من هذا الترحيل ليس SDK - بل هو ما يتوقف عن كونه تذكرة هندسية بعد ذلك. من لوحة التحكم، يمكن لفريق التسويق الخاص بك إنشاء حملات مشغلة بناءً على أي حدث يتتبعه تطبيقك، وتقسيم الجمهور باستخدام التجزئة السلوكية، وتشغيل رحلات متسلسلة، واختبار A/B للنصوص، وتتبع الإيرادات لكل حملة مع تتبع الأهداف. مشاركتك بعد التكامل هي تتبع الأحداث الجديدة باستخدام trackEvent - استدعاء من سطر واحد - عندما يريد الفريق مشغلًا جديدًا.
سؤال التكلفة، بصراحة
تسليم FCM مجاني، وإذا كان التسليم الخام هو كل ما تحتاجه، فاحتفظ به. ما تقوم بتقييمه عند تقييم PushEngage هو طبقة التسويق - التجزئة، والأتمتة، والتتبع، ولوحة تحكم يمكن لفريق التسويق الخاص بك تشغيلها بمفرده. تتوسع الأسعار فقط مع المشتركين النشطين، لذلك لا تؤدي قاعدة التثبيت الكبيرة ذات المشاركة المختلطة إلى تضخيم الفاتورة، والقائمة المتقلصة تقللها. لقد قمنا بتقسيم مقارنة التكلفة الحقيقية في تسعير إشعارات الدفع من Firebase.
قم بالانتقال
تعد الهجرة من Firebase Cloud Messaging على نظام iOS بمثابة فترة بعد الظهر من التكامل ودورة إصدار من الصبر: أضف حزمة تطوير البرامج (SDK)، وشارك مجموعة التطبيقات (App Group)، وقم بتحميل مفتاح APNs الذي لديك بالفعل، ودع عملية الطرح تعيد تسجيل قاعدتك. لا عمليات إعادة تثبيت، ولا مشتركين مفقودين، ولا مطالبة إذن ثانية - ولا مزيد من حملات الدفع التي تنتظر دورة تطوير. ابدأ بدليل تسويق دفع التطبيقات إذا كنت تريد سياق الاستراتيجية، أو انتقل مباشرة إلى حزمة تطوير البرامج (SDK) وقم بتشغيلها هذا الأسبوع. كل خطة مدفوعة تأتي مع ضمان استعادة الأموال لمدة 14 يومًا.
