تعد الإشعارات الفورية أداة تسويق حيوية لأي شخص لديه تطبيق جوال.
إنها أفضل طريقة للتواصل مع المستخدمين ، وإرسال رسائل عاجلة إلى هواتفهم المحمولة.
يمكن لتطبيق الجوّال إرسال إشعار دفع للمستخدم ، وهو عبارة عن رسالة منبثقة مختصرة تظهر على هواتفهم الذكية حتى عندما لا يكون التطبيق مفتوحًا.
يمكن أن تتضمن هذه التنبيهات تذكيرات وتحديثات وخصومات والمزيد.
تم إنشاؤها لجذب عيون المستخدمين. العنوان والرسالة والصورة وعنوان URL كلها مكونات ممكنة لإشعار الدفع. يمكن أيضًا أن تكون الرموز التعبيرية والشعارات وأشياء أخرى جزءًا منها.
تحتوي أنظمة التشغيل مثل Apple OS و Google Android على واجهات متنوعة لدفع الإشعارات.
يمكن استخدام الإشعارات الفورية لتعزيز التفاعل وتعزيز استخدام التطبيق والتأثير على التحويلات وغير ذلك الكثير.
الخيارات لا حدود لها حقًا.
يمكن أن تكمل الإشعارات الفورية للأجهزة المحمولة ، والمعروفة أيضًا بإشعارات الدفع للأجهزة المحمولة ، استخدامك للقنوات مثل البريد الإلكتروني والرسائل القصيرة والإشعارات الفورية عبر الإنترنت بعدد من المزايا الخاصة.
ستتلقى وصفًا سريعًا لخدمة الإشعارات في هذا المنشور ومعلومات عن هدفها وتصميمها عالي المستوى وميزاتها الخاصة والمزيد.
هدف
لتطوير خدمة إعلام يمكنها توزيع رسائل المنتج إلى المستخدم بكفاءة عبر مجموعة متنوعة من القنوات
المتطلبات الأساسية:
- إرسال واجهة برمجة التطبيقات (API): انشر نقطة نهاية معتمدة بحيث يمكن لأي خلفية أو خدمة مصغرة بدء تسليم الإشعارات.
- القنوات المتوافقة: دعم تسليم التنبيهات إلى أي قناة تنشر واجهة برمجة تطبيقات ، مثل البريد الإلكتروني والرسائل النصية والدفع.
- تفضيلات المستخدم: السماح للمستخدمين بتحديد تفضيلات المستخدم الخاصة بهم لكل قناة وإشعار.
- حدود امتثال خدمة المصب: تجنب أن يكون لديك البريد الإلكتروني أو خدمة الرسائل القصيرة خنق أو توقفت.
- قابلة للتطوير: تسمح (نظريًا) بتحجيم أفقي غير محدود.
هندسة معمارية عالية المستوى
لنفترض أن الكود الخاص بك من المفترض أن يخطر شخصًا ما:
- يتم استدعاء نقطة نهاية POST / إرسال من خلال التعليمات البرمجية الخاصة بك. لكل قناة متاحة ، يتضمن الطلب معرف المستخدم الخاص بالمستلم ونوع الإخطار ومحتوياته.
- يتم استخدام تدفق بيانات اعتماد عميل OAuth2 بواسطة / إرسال نقطة النهاية لمصادقة الطلب.
- ثم يتم طلب خيارات إعلام المستخدم من قاعدة البيانات. توضح التفضيلات ما إذا كان المستخدم مشتركًا في قناة وإشعار معين أم لا.
- من قاعدة البيانات ، ستقرأ خصائص المستخدم مثل عناوين البريد الإلكتروني وأرقام الهواتف.
- ستنشئ نقطة النهاية هذه كائن رسالة يتضمن خصائص المستخدم والقنوات والمحتوى الخاص بالقناة. ومع ذلك ، فإنها لن تتضمن القنوات المعطلة. ثم يتم تسليم الرسالة إلى خدمة fan out.
- يتم نشر الرسائل الواردة في قوائم انتظار الوظائف عبر خدمة التوزيع. ومع ذلك ، يتم إجراء التصفية لتجاهل قوائم انتظار الوظائف للقنوات غير المحددة في الرسالة.
- تحتوي كل قناة على معالج وقائمة انتظار عمل. يأخذ المعالج المهمة ثم يطلب الخدمة المناسبة ، مثل البريد الإلكتروني للمعاملات أو خدمة الرسائل القصيرة.
عناصر العمارة الرئيسية
الإرسال / الإرسال
ربما لاحظت جيدًا أنه تم تضمين معرف المستخدم فقط ولا عنوان البريد الإلكتروني أو رقم الهاتف في الطلب إلى نقطة النهاية هذه. يمكّن هذا خدمات الإعلام من البقاء مجهول الهوية للمستخدمين.
لضمان قابلية التوسع ، يتم وضع نقطة النهاية خلف أ موازن التحميل.
لا توفر المصادقة النموذجية التي تواجه المستخدم حماية لنقطة النهاية.
يجب استخدام طريقة مصادقة مميزة تُعرف باسم تدفق بيانات اعتماد عميل OAuth2 المستخدم للاتصال من خادم إلى خادم نظرًا لأن الخدمة التي ترسل الطلب هي البرنامج نفسه.
سيوفر تطبيقك إشعارات في العديد من الأماكن المختلفة. يمكنك استخدام وظيفة الإرسال في أي مكان تقريبًا ، على سبيل المثال من قاعدة بيانات جديدة أو سير عمل الإنشاء ، من خلال تنفيذها كنقطة نهاية خلف موازن التحميل ، مما يضمن أنها قابلة للتطوير بشكل مستقل.
PUT / تفضيلات المستخدم
استخدم زوج مفتاح / قيمة أو قاعدة بيانات NoSQL قابلة للتطوير بشكل كبير. نسّق السجلات على النحو التالي: KEY: نموذج معرّف المستخدم: نموذج معرّف الإشعار ، VALUE: ["البريد الإلكتروني" ، "الحالة: صحيح" ، "SMS" ، "الحالة: خطأ" ، القناة: "البريد الإلكتروني" ، "البريد الإلكتروني" ، الحالة : حقيقي
في حالة وجود قيم "خاطئة" في السجلات ، ستستبعد نقطة نهاية الإرسال القناة المقابلة من الرسالة التي تم تسليمها إلى التوزيع. إذا لم يكن هناك سجل لقناة ، فإن المستخدم لم يشر صراحةً إلى تفضيلاته. يجب أن توافق على التقصير في هذا السيناريو.
يمكن للمستخدم تعديل البيانات في قاعدة بيانات تفضيلات المستخدم باستخدام واجهة المستخدم الخاصة بك ونقطة نهاية عادية يتم تأمينها بواسطة إجراءات المصادقة القياسية الخاصة بك.
سوف يغضب المستخدمون وسيضطرون إلى تصنيف تنبيهاتك على أنها رسائل غير مرغوب فيها أو إسكاتها إذا لم توفر لهم خيار تغيير تفضيلات الإشعارات الخاصة بهم. ستتعرض تجربة المستخدم لمزيد من الضرر نتيجة لذلك ، وقد تؤدي خدمات تسليم البريد الإلكتروني أو الرسائل القصيرة إلى تعليق حسابك.
معجب في
يقوم Fanout بنسخ رسالة وتوزيعها على مواقع مختلفة. فهي ميسورة التكلفة وقابلة للتطوير للغاية. استخدم SNS في AWS. استخدم Pub / Sub في Azure والموضوعات والاشتراكات في Google Cloud Platform.
لمنع إرسال رسائل غير مجدية إلى قوائم انتظار وظائف القناة المستبعدة ، يمكنك تكوين التصفية بين قوائم الانتظار وقوائم انتظار العمل. على سبيل المثال ، في AWS SNS ، يمكنك تحديد أن قائمة انتظار وظيفة البريد الإلكتروني يجب أن تتلقى رسالة التوزيع فقط إذا كانت تحتوي على قيمة "البريد الإلكتروني" في حقل "القنوات".
حتى إذا كان بإمكانك إنشاء رمز لإرسال الرسالة المتطابقة إلى قوائم انتظار المهام المطلوبة ، فإن التوزيع يكون أكثر كفاءة ويتطلب ترميزًا أقل. يوفر Fanout أيضًا سهولة إضافة قوائم الانتظار وإزالتها ، مما يسمح لك بتوسيع قنواتك وإعادة تنظيمها.
معالجة الوظيفة
يتم تخزين الرسائل في قوائم انتظار في انتظار المعالجة بواسطة معالجات الوظائف الخاصة بك. إنها أيضًا ميسورة التكلفة وقابلة للتطوير للغاية. معالجات الوظائف هي أجزاء من التعليمات البرمجية التي تعالج الرسائل من قوائم انتظار الوظائف. اعتمادًا على حجم الرسائل في قائمة الانتظار ، يمكن تغيير حجمها.
يجب أن يقوم معالج الوظيفة بإجراء مكالمة API إلى المزود المناسب لتسليم الإشعار في السيناريو الخاص بنا عبر خدمة البريد الإلكتروني للمعاملات.
غالبية مزودي خدمة البريد الإلكتروني والرسائل النصية القصيرة وما شابههم من مزودي خدمة توصيل الرسائل لديهم متطلبات صارمة لكمية ونوعية الرسائل التي ترسلها. بالإضافة إلى ذلك ، تريد فحصها وإعداد الإجراءات المناسبة بدقة. فيما يلي نصيحتنا حول كيفية تجنب إنهاء خدمات AWS SES.
يمكنك تحديد الحد الأقصى لعدد معالجات الوظائف لمنع تجاوز الحدود القصوى لمعدلات خدمات التوصيل.
مزيد من التحسينات
يمكنك إلقاء نظرة على مجموعة من هذه العناصر.
- يحتاجون إلى واجهات برمجة التطبيقات الخاصة بهم ، والجداول ، وما إلى ذلك من أجل الحصول على خدمة إعلام قابلة للتطوير داخل التطبيق.
- جمع وعرض تقرير الفتح / النقر
- إزالة محتويات الإشعارات من الرمز والسماح لفريق التصميم والمنتج بتعديل التنبيهات بصريًا بدلاً من تغيير الرمز
- بدون تغيير أي رمز ، يمكن لفريقك استخدام لوحة المعلومات لتنشيط أو تعطيل الإشعارات لقنوات معينة.
فوائد دفع الإخطار
- تعزيز تفاعل المستخدم: ستثير التحديثات والمواد الجديدة اهتمام المستخدمين لديك.
- تعزيز رؤية الاتصال: تأكد من تلقي رسائلك على الفور ، حتى عندما لا يكون الأشخاص نشطين. أرسل إشعارات عاجلة ووفر للمستخدمين تجربة سلسة.
- الاحتفاظ بالاحتفاظ: استخدم إشعارات الدفع المرئية بوضوح لحث المستخدمين على العودة. يمكنك زيادة الاحتفاظ بالمستخدمين وتقليل الاضطراب عن طريق دفع العملاء مرة أخرى إلى موقعك على الويب وتطبيقك.
- تعزيز التحويلات: من خلال إنشاء حملات دفع حول الجوائز داخل التطبيق أو العروض الترويجية أو الخصومات أو العروض الأخرى ، يمكنك زيادة المبيعات.
- توسيع نطاق مؤسستك: يجب أن يتوسع نهج الاتصال الخاص بك مع توسع جمهورك. مع توسع قاعدة عملائك ، تعد الإشعارات الفورية طريقة فعالة للبقاء على اتصال معهم.
- اجعل تجربة المستخدم متصلة (UX): من خلال توفير تنبيهات المعاملات للمستهلكين لإبقائهم على اطلاع وتوفير تجربة سلسة عبر القنوات ، يمكنك تقليل الاحتكاك طوال رحلة العميل.
وفي الختام
في الختام ، اكتسبنا المعرفة حول بنية خدمة إشعارات الدفع القابلة للتطوير. نظرنا أيضًا إلى الأدوات التي يوفرها جميع مزودي الخدمات السحابية الرئيسيين حتى تتمكن من بناء إشعاراتك عليها.
على الرغم من أنني بذلت قصارى جهدي لتزويدك بنظرة عامة على بنية نظام إشعارات الدفع ، فهناك الكثير مما يحدث وراء الكواليس.
أتمنى مخلصًا أن تجد هذه المعلومات مفيدة وأن تستخدمها بشكل جيد.
اترك تعليق