إذا كان تطبيق الجوال لديكم يعتمد على Amazon Pinpoint لإرسال الإشعارات الفورية والرسائل داخل التطبيق، فأمامكم موعد نهائي حاسم وانتقال ليس بالبسيط. في 30 أكتوبر 2026، تُنهي AWS رسمياً دعم Amazon Pinpoint. بعد هذا التاريخ، يتوقف الوصول إلى الكونسول وكل ما بنيتموه بداخله: نقاط النهاية (endpoints)، الجماهير المستهدفة (segments)، الحملات، الرحلات (journeys)، ولوحات التحليلات.
توقفت Pinpoint أيضاً عن قبول حسابات جديدة منذ 20 مايو 2025، لذا فالخدمة تسير على عدّاد تنازلي منذ فترة. توضح AWS الجدول الزمني الكامل في دليلها الرسمي لإنهاء الدعم.
فهم التوقف هو الجزء السهل. الجزء المعقّد هو الوجهة التي تحيلكم إليها AWS، إذ لا يوجد منتج بديل واحد. يتوزع عبء عملكم على 4 خدمات مختلفة من AWS بحسب ما كنتم تستخدمون Pinpoint من أجله. وبالنسبة لأهم قناتين تعتمد عليهما أغلب فرق الجوال، الإشعارات الفورية والرسائل داخل التطبيق، فإن المسار الموصى به لا ينقلهما بشكل مباشر.
في هذا الدليل: ما يتوقف فعلياً، إلى أين توجّه AWS كل جزء ولماذا ليس استبدالاً مطابقاً، وخطة من 4 خطوات لنقل برنامج الإشعارات والرسائل داخل التطبيق إلى Pushwoosh بدلاً من ذلك — بأرقام حقيقية حتى تتمكنوا من تحديد الميزانية فعلياً.
ما الذي يتوقف فعلياً
واجهات برمجة قنوات الرسائل لن تختفي. ما يختفي هو طبقة التفاعل، الجزء الذي يدخل إليه فريقا التسويق والمنتج.
بعد 30 أكتوبر 2026، يُفقَد الوصول إلى موارد Pinpoint: نقاط النهاية (سجلات المستخدمين والأجهزة المخزّنة)، الجماهير المستهدفة الديناميكية، الحملات المجدولة، أداة بناء الرحلات متعددة الخطوات، ولوحات التحليلات المدمجة التي كانت تتبع التسليم والفتح والتفاعل ضمن الرحلات.
ما يبقى، تحت اسم مختلف، هو طبقة القنوات الخام. تستمر الرسائل النصية والمكالمات الصوتية والإشعارات الفورية على الجوال ورموز التحقق (OTP) والتحقق من أرقام الهواتف في العمل عبر AWS End User Messaging، وهو الاسم الذي منحته AWS لواجهات برمجة قنوات Pinpoint منذ الربع الثالث من 2024. لذا إن كنتم تستخدمون Pinpoint فقط كقناة إرسال بسيطة، حيث تحتفظ الواجهة الخلفية الخاصة بكم بالمنطق وتكتفي باستدعاء الواجهة البرمجية لإرسال رسالة معاملاتية، فالوضع أخف عليكم. يكفي إعادة توجيه استدعاءات الواجهة البرمجية والمتابعة.
لكن إن كان فريقكم قد بنى الجماهير والحملات والرحلات داخل واجهة Pinpoint، فهذا بالضبط ما ينكسر. وإعادة بنائه داخل AWS هي حيث يبدأ العمل الحقيقي.
إلى أين توجهكم AWS، ولماذا ليس بديلاً مطابقاً 1:1
دليل الانتقال الخاص بـ AWS لا يمنحكم بديلاً واحداً، بل 4، واحداً لكل قدرة:
- التفاعل (نقاط النهاية، الجماهير، الحملات، الرحلات) ← حملات Amazon Connect الصادرة + Customer Profiles
- الأحداث وتحليلات الجوال ← Amazon Kinesis
- البريد الإلكتروني ← Amazon SES (Simple Email Service)
- الرسائل النصية والإشعارات الفورية والمكالمات الصوتية ورموز التحقق ← AWS End User Messaging
لا يزال المزوّد واحداً من الناحية التقنية. لكنها الآن 4 منتجات منفصلة، و4 لوحات تحكم، و4 مجموعات من التوثيق، تحل محل النظام الواحد الذي كان بين أيديكم. بالنسبة لفريق دون وحدة هندسة منصات مخصصة، هذا عبء أثقل بكثير مما توحي به عبارة “الانتقال إلى أداة جديدة” عادةً.
وبالنسبة لفرق الجوال تحديداً، فإن وجهة التفاعل هذه هي حيث تتعقّد الأمور. توجد في Amazon Connect ثغرات يسهل تفويتها إلى أن تكونوا بالفعل في منتصف عملية الانتقال.
- الرسائل داخل التطبيق غير موجودة إطلاقاً في Connect. تقرّ AWS بذلك بنفسها: يُدرِج توثيق الانتقال هذه القدرة ضمن الميزات غير المتوفرة، كتابةً. إذا كانت رسائل التعريف بالتطبيق (onboarding)، أو تلميحات الميزات، أو شاشات الاشتراك المدفوع جزءاً من عمل تطبيقكم، فلا يوجد لها مكان أصلي على المسار الموصى به.
- الإشعارات الفورية ليست قناة حملة أصلية. الإشعارات الفورية (GCM وAPNS وBaidu وغيرها) غير مدعومة أصلياً في حملات Connect. يقول دليل AWS إن بالإمكان إرسالها، لكن فقط عبر رحلة (journey)، باستخدام إجراء Lambda مرتبط بقوالب دفع Connect. عملياً، يعني ذلك كتابة وصيانة كود فقط لتكرار ما كانت Pinpoint تقدّمه جاهزاً.
- قناة Custom Channel متاحة جزئياً فقط. متوفرة في الرحلات وليست في الحملات. ثغرة أخرى في حزمة الجوال تترككم Connect لسدّها بأنفسكم.
- القوالب تشترك في المحرك لا في الصياغة. تستخدم قوالب Connect نفس محرك العرض Handlebars المستخدم في Pinpoint، لذا ينتقل المنطق. لكن أماكن السمات (attribute placeholders) مكتوبة بصياغة مختلفة: ما كان يُكتب
{{User.UserAttributes.PurchaseHistory}}في Pinpoint يصبح{{Attributes.Customer.Attributes.PurchaseHistory}}في Connect. يجب جلب كل قالب وإعادة كتابته يدوياً. - نقل نقاط النهاية مهمة برمجة نصية. لنقل مستخدميكم، تطلب منكم AWS تصدير جمهور بلا فلاتر إلى S3، ثم تشغيل نص برمجي بلغة Python لإعادة تشكيل نقاط النهاية هذه إلى Customer Profiles، حيث يقتصر الملف التعريفي الواحد على 3 عناوين بريد إلكتروني و4 أرقام هواتف. الأمر ينجح، لكنه أيضاً كود عليكم كتابته واختباره وتحمّل مسؤوليته.
لا شيء من هذا يجعل مسار AWS خاطئاً. إذا كنتم بالفعل معتمدين كلياً على Connect لحالات استخدام مركز الاتصال، فقد يكون هذا هو الخيار الصحيح تماماً لكم. لكن إذا كانت الإشعارات الفورية والرسائل داخل التطبيق هي سبب اعتمادكم على Pinpoint أصلاً، فإن مسار الانتقال الموصى به يسلّم هاتين القناتين مباشرةً إلى مهندسيكم لإعادة بنائهما. وهذا ما يستحق معرفته قبل البدء، لا بعد 3 دورات عمل (sprints).
نقل برنامج الإشعارات والرسائل داخل التطبيق إلى Pushwoosh خلال 4 خطوات
Pushwoosh منصة تفاعل عملاء مبنية أولاً لعالم الجوال: الإشعارات الفورية والرسائل داخل التطبيق وإشعارات الويب هي القنوات الأساسية، إلى جانب البريد الإلكتروني والرسائل النصية. بدلاً من توزيع برنامجكم عبر 4 خدمات من AWS، تعيدون بناءه مرة واحدة، في مكان واحد. إليكم كيف يسير الانتقال.
-
تصدير بيانات Pinpoint
اسحبوا نقاط النهاية والجماهير والحملات وتعريفات الرحلات باستخدام واجهات AWS البرمجية بينما لا تزال الكونسول متاحة. الانتظار حتى الاقتراب من الموعد النهائي يزيد صعوبة الاسترجاع فقط، وستحتاجون لهذا التصدير أياً كانت وجهتكم، فابدأوا مبكراً.
-
إعادة توجيه أدوات SDK للجوال
استبدلوا SDK الخاص بـ Pinpoint أو Amplify بـ SDK الخاص بـ Pushwoosh، ثم تأكدوا من تسجيل الأجهزة وتدفق الأحداث قبل تفعيل أي شيء يواجه المستخدم. هذه الخطوة تعيد ربط تطبيقكم بواجهة خلفية فعّالة للرسائل.
-
إعادة بناء الجماهير والرحلات
استوردوا مستخدميكم، وربطوا سمات Pinpoint بنموذج الوسوم والتقسيم في Pushwoosh، وأعيدوا إنشاء الأتمتة في أداة بناء الرحلات المرئية. إنه عمل شبه مطابق: تعيدون تطبيق منطق تعرفونه بالفعل بدلاً من التصميم من الصفر. وهذا بالضبط الجزء الذي كان سيقع على عاتق مهندسيكم في مسار Connect.
-
إعادة ربط الأحداث، ثم التجربة التجريبية
أعيدوا ربط الأحداث المخصصة كي تُطلَق المحفزات السلوكية، وشغّلوا إرسالاً تجريبياً على جمهور صغير للتأكد من التكافؤ، ولا تنتقلوا للحجم الكامل إلا بعدها. احجزوا وقتاً تقويمياً حقيقياً للتحقق من النطاق وأي تسجيل للمرسل، فلا شيء من ذلك يتسارع لمجرد اقتراب الموعد النهائي.
يظهر الفرق عن مسار AWS في التفاصيل المزعجة. حيث يطلب منكم دليل AWS كتابة وتشغيل نص Python لإعادة تشكيل نقاط النهاية إلى Customer Profiles، تستورد Pushwoosh المستخدمين عبر الواجهة أو الواجهة البرمجية، دون نص برمجي تكتبونه أو تصونونه. وحيث يطلب منكم Connect توجيه الإشعارات عبر رحلة مدعومة بـ Lambda، تكون الإشعارات الفورية مجرد قناة تختارونها. الجهد الهندسي الذي كنتم ستخصصون له ميزانية على جانب AWS يتبخر في معظمه.
لماذا يهم التوقيت لفرق الشرق الأوسط وشمال أفريقيا
القرار يحمل وزناً إضافياً لفرق المنطقة. أكثر من 70% من أجهزة الجوال في السعودية والإمارات ومصر تعمل بنظام Android، وأي مسار انتقال يعامل الإشعارات الفورية كإضافة لاحقة بدلاً من قناة أصلية يضع أكبر شريحة من جمهوركم في موقع أضعف. Amazon Connect، بحسب توثيق AWS نفسه، يمرّر الإشعارات الفورية عبر رحلة مرتبطة بإجراء Lambda وليس كحملة مباشرة — وهو عبء إضافي بالتحديد على الفرق التي تعتمد على Android كقناة رئيسية.
الفرق التي تخدم قطاعي التجارة الإلكترونية والتكنولوجيا المالية في الخليج، وكذلك الجهات الحكومية التي تبني تطبيقات ضمن مبادرات التحول الرقمي المرتبطة برؤية 2030، غالباً ما تعتمد على الرسائل داخل التطبيق لتوجيه المستخدمين الجدد أو توصيل تنبيهات الخدمة — وهي بالضبط القناة غير المدعومة على مسار Connect. جدولة الانتقال قبل 30 أكتوبر 2026 تجنّبكم اكتشاف هذه الثغرة في منتصف موسم تسويقي أو إطلاق خدمة حكومية جديدة.
الأمان والامتثال أثناء الانتقال
أي انتقال لبرنامج رسائل يعني نقل بيانات مستخدمين حقيقية، وهذا هو المكان الذي تستحق فيه شهادات الامتثال أن تكون جزءاً من قرار الانتقال لا مجرد بند لاحق. تحقّقوا من مكان استضافة بياناتكم والشهادات التي يحملها كل مزوّد فعلياً قبل التوقيع، فهذا المستوى من التحقّق مفيد خصوصاً عند التعامل مع عملاء مؤسسيين أو حكوميين في المنطقة، حيث تُطرح أسئلة الامتثال مبكراً في أي تقييم للمورّدين.
التكلفة
التسعير هو الجزء الذي تتجنّب معظم أدلة الانتقال توضيحه، لذا إليكم الأمر بوضوح. تحتسب Pushwoosh التسعير على أساس المستخدمين النشطين شهرياً (MAU) — راجعوا تفاصيل الأسعار الكاملة — وبالنسبة لبرنامج إشعارات ورسائل داخل التطبيق، فإن نقطة الدخول منخفضة عمداً:
- الإشعارات فقط — 7 دولارات لكل 1000 مستخدم نشط شهرياً. إذا كانت الإشعارات والرسائل داخل التطبيق هما كامل البرنامج، فهذه هي الباقة المناسبة، دون أي أعباء إضافية لقنوات لن تستخدموها.
- القنوات المتعددة — 13 دولاراً لكل 1000 مستخدم نشط شهرياً. تضيف البريد الإلكتروني والرسائل النصية وبقية القنوات عندما تريدون كل شيء تحت مظلة واحدة.
- باقة مخصصة — تبدأ من 2000 دولار شهرياً. تسعير حسب الحجم، ودعم مخصص، وشروط مؤسسية للإرسال بكميات كبيرة.
بالنسبة لفريق يحتاج أساساً لاستبدال الإشعارات والرسائل داخل التطبيق في Pinpoint، فإن نقطة دخول الـ7 دولارات أقل عبئاً بكثير من الالتزام بمجموعة كاملة لأتمتة التسويق. وهذه بالضبط المفاضلة التي تفرضها فئة Braze وCustomer.io وIterable.
لا تنتظروا حتى أكتوبر
عملية الانتقال بحد ذاتها معروفة: تصدير، إعادة توجيه، إعادة بناء، اختبار. القيد الحقيقي هو التقويم. 30 أكتوبر 2026 موعد نهائي ثابت، والخطوات التي تستهلك وقتاً تقويمياً حقيقياً (تحويل SDK، ربط الأحداث، إعداد النطاق والمرسل) تسير بوتيرتها الخاصة بغض النظر عن قرب الموعد.
يمكنكم البدء ببياناتكم الفعلية على الباقة المجانية بحد 1000 مستخدم نشط شهرياً، وهو ما يكفي لاستيراد جمهور حقيقي، وإعادة بناء رحلة، وتشغيل إرسال تجريبي لرؤية التكافؤ بأنفسكم قبل الالتزام بالانتقال الكامل. نصيحتنا، بعد متابعة عدد كافٍ من عمليات الانتقال المتأخرة: حددوا نطاق العمل استناداً إلى عدد مستخدميكم الفعلي وجدولكم الزمني الآن، بينما لا تزال كونسول Pinpoint متاحة للتصدير منها. الفرق التي تترك الأمر إلى سبتمبر هي التي تكتشف الثغرات قبل 3 أسابيع من انطفاء الأنوار.
