اعلانهای فشاری یک ابزار بازاریابی حیاتی برای هر کسی که یک برنامه تلفن همراه دارد است.
این بهترین راه برای برقراری ارتباط با کاربران شما، ارسال پیام های فوری به تلفن همراه آنها است.
یک برنامه تلفن همراه می تواند برای کاربر یک اعلان فشار ارسال کند، که یک پیام کوتاه پاپ آپ است که حتی زمانی که برنامه باز نیست، روی گوشی هوشمند او ظاهر می شود.
این هشدارها می تواند شامل یادآوری ها، به روز رسانی ها، تخفیف ها و موارد دیگر باشد.
آنها برای جلب نظر کاربران ساخته شده اند. عنوان، پیام، تصویر و URL همه اجزای ممکن یک اعلان فشار هستند. ایموجی ها، لوگوها و موارد دیگر نیز می توانند بخشی از آنها باشند.
سیستم عامل هایی مانند Apple OS و Google Android دارای رابط های متنوعی برای اعلان های فشاری هستند.
از اعلانهای فشاری میتوان برای ارتقای تعامل، افزایش استفاده از برنامه، تأثیر بر تبدیلها و موارد دیگر استفاده کرد.
گزینه ها واقعا بی حد و حصر هستند.
اعلانهای فشاری برای دستگاههای تلفن همراه، که به عنوان اعلانهای فشار برای دستگاههای تلفن همراه نیز شناخته میشوند، میتوانند استفاده شما از کانالهایی مانند ایمیل، پیامک و اعلانهای فشار آنلاین را با تعدادی مزایای ویژه تکمیل کنند.
در این پست توضیح سریعی از سرویس اطلاع رسانی و اطلاعاتی در مورد هدف، طراحی سطح بالا، ویژگی های خاص و موارد دیگر دریافت خواهید کرد.
هدف
برای توسعه یک سرویس اطلاع رسانی که می تواند پیام های محصول به کاربر را به طور موثر در کانال های مختلف توزیع کند
مورد نیاز:
- ارسال API: یک نقطه پایانی مجاز را منتشر کنید تا هر بکاند و میکروسرویس بتواند شروع به ارائه اعلانها کند.
- کانالهای سازگار: از ارسال هشدار به هر کانالی که API منتشر میکند، مانند ایمیل، پیام متنی و فشار پشتیبانی میکند.
- تنظیمات برگزیده کاربر: به کاربران امکان می دهد تنظیمات برگزیده کاربر خود را برای هر کانال و اعلان انتخاب کنند.
- محدودیتهای انطباق با خدمات پایین دستی: از داشتن خدمات خودداری کنید پست الکترونیک یا سرویس پیامک قطع یا متوقف شد.
- مقیاس پذیر: اجازه مقیاس افقی بی نهایت (از لحاظ نظری).
معماری سطح بالا
فرض کنید کد شما قرار است به کسی اطلاع دهد:
- نقطه پایانی POST /send توسط کد شما فراخوانی می شود. برای هر کانال موجود، درخواست شامل شناسه کاربری گیرنده، نوع اعلان و محتوای آن است.
- OAuth2 Client Credentials Flow توسط /send end-point برای احراز هویت درخواست استفاده می شود.
- سپس انتخاب های اعلان کاربر از پایگاه داده درخواست می شود. تنظیمات ترجیحی نشان می دهد که آیا کاربر در یک کانال خاص مشترک شده است یا خیر.
- از پایگاه داده، ویژگی های کاربر مانند آدرس ایمیل و شماره تلفن را می خواند.
- این نقطه پایانی یک شی پیام ایجاد می کند که شامل ویژگی های کاربر، کانال ها و محتوای خاص کانال است. اگرچه کانال های غیرفعال شده را شامل نمی شود. سپس پیام به یک سرویس هوادار تحویل داده می شود.
- پیامهای دریافتی از طریق سرویس fanout در صفهای شغلی پخش میشوند. با این حال، فیلترینگ برای نادیده گرفتن صفهای کاری برای کانالهایی که در پیام مشخص نشدهاند، انجام میشود.
- هر کانال یک پردازنده و یک صف کار دارد. پردازنده این وظیفه را بر عهده می گیرد و سپس سرویس مناسب مانند ایمیل تراکنش یا سرویس پیامک را درخواست می کند.
عناصر اصلی معماری
POST/ارسال شد
شاید به خوبی متوجه شده باشید که فقط userId و نه آدرس ایمیل و نه شماره تلفن در درخواست این نقطه پایانی گنجانده شده است. این به خدمات اطلاع رسانی امکان می دهد تا برای کاربران شما ناشناس باقی بمانند.
برای اطمینان از مقیاس پذیری، نقطه پایانی در پشت a قرار می گیرد متعادل کننده بار.
احراز هویت معمولی شما از نقطه پایانی محافظت نمی کند.
شما باید از یک روش احراز هویت متمایز به نام جریان اعتبار مشتری OAuth2 استفاده کنید که برای ارتباط سرور به سرور استفاده می شود زیرا سرویسی که درخواست را ارسال می کند خود نرم افزار است.
برنامه شما اعلان ها را در مکان های مختلف ارائه می دهد. میتوانید تابع ارسال را تقریباً در هر جایی، مانند یک پایگاه کد جدید یا گردش کار ساخت خود، با پیادهسازی آن بهعنوان یک نقطه پایانی در پشت یک متعادلکننده بار، که تضمین میکند که بهطور مستقل مقیاسپذیر است، استفاده کنید.
PUT/ تنظیمات برگزیده کاربر
از یک جفت کلید/مقدار یا پایگاه داده NoSQL استفاده کنید که بسیار مقیاس پذیر است. رکوردها را به صورت زیر قالب بندی کنید: KEY: شناسه کاربر نمونه: شناسه اعلان نمونه، VALUE: ["ایمیل"، "وضعیت: درست"، "پیامک"، "وضعیت: نادرست"، کانال: "ایمیل"، "ایمیل"، وضعیت : درست است، واقعی
اگر مقادیر "نادرست" در رکوردها وجود داشته باشد، نقطه پایانی ارسال، کانال مربوطه را از پیام ارسال شده به fanout حذف می کند. اگر سابقه ای برای یک کانال وجود نداشته باشد، کاربر به صراحت اولویت های خود را نشان نداده است. در این سناریو باید با پیش فرض موافقت کنید.
کاربر میتواند دادهها را در پایگاه داده ترجیحات کاربر با استفاده از رابط کاربری و یک نقطه پایانی معمولی که با روشهای احراز هویت استاندارد شما ایمن شده است، تغییر دهد.
کاربران عصبانی می شوند و مجبور می شوند هشدارهای شما را به عنوان هرزنامه تعیین کنند یا آنها را ساکت کنند اگر گزینه ای برای تغییر تنظیمات برگزیده اعلان در اختیار آنها قرار ندهید. در نتیجه تجربه کاربری شما بیشتر آسیب خواهد دید و خدمات ارسال ایمیل یا پیامک میتواند حساب شما را به حالت تعلیق درآورد.
Fan Out
Fanout یک پیام را کپی می کند و آن را در مکان های مختلف توزیع می کند. آنها مقرون به صرفه و بسیار مقیاس پذیر هستند. از SNS در AWS استفاده کنید. از Pub/Sub در Azure و موضوعات و اشتراکها در Google Cloud Platform استفاده کنید.
برای جلوگیری از ارسال پیامهای بیهوده به صفهای شغلی کانال حذف شده، میتوانید فیلتر را بین صفهای fanout و work پیکربندی کنید. به عنوان مثال، در AWS SNS، میتوانید تعیین کنید که صف شغل ایمیل فقط در صورتی پیام fanout را دریافت کند که مقدار «ایمیل» را در قسمت «کانالها» داشته باشد.
حتی اگر بتوانید کدی برای ارسال پیام یکسان به صف های شغلی مورد نیاز ایجاد کنید، fanout کارآمدتر است و نیاز به کدنویسی کمتری دارد. Fanout همچنین راحتی افزودن و حذف صفها را ارائه میدهد و به شما امکان میدهد کانالهای خود را گسترش داده و سازماندهی مجدد کنید.
پردازش شغل
پیامها در صفهایی ذخیره میشوند که در انتظار پردازش توسط پردازشگرهای شغلی شما هستند. آنها همچنین مقرون به صرفه و بسیار مقیاس پذیر هستند. پردازشگرهای کار قطعه کدی هستند که پیام های صف های شغل را پردازش می کنند. بسته به حجم پیام ها در صف، می توانند مقیاس شوند.
پردازشگر کار باید یک تماس API با ارائه دهنده مناسب برقرار کند تا اعلان را در سناریوی ما از طریق یک سرویس ایمیل تراکنشی ارائه کند.
اکثر ارائه دهندگان ارسال ایمیل، پیامک و پیام های مشابه الزامات زیادی برای کمیت و کالیبر پیام های ارسالی شما دارند. علاوه بر این، شما می خواهید این موارد را بررسی کنید و روش های مناسب را به طور کامل تنظیم کنید. در اینجا توصیه ما در مورد نحوه جلوگیری از خاتمه دادن به AWS SES است.
می توانید حداکثر تعداد پردازشگرهای شغلی را برای جلوگیری از تجاوز از سقف نرخ خدمات تحویل تعریف کنید.
پیشرفت های بیشتر
می توانید نگاهی اجمالی به مجموعه ای از این موارد داشته باشید.
- آنها برای داشتن یک سرویس اطلاع رسانی درون برنامه ای مقیاس پذیر به API ها، جداول و غیره خود نیاز دارند.
- جمع آوری و نمایش گزارش باز/کلیک کنید
- حذف محتویات اعلانها از کد و اجازه دادن به محصول و تیم طراحی شما در عوض بدون تغییر کد، هشدارها را به صورت بصری تغییر دهند.
- بدون تغییر کد، تیم شما میتواند از داشبورد برای فعال یا غیرفعال کردن اعلانها برای کانالهای خاص استفاده کند.
مزایای Push Notification
- تقویت تعامل با کاربر: به روز رسانی ها و مطالب جدید کاربران شما را علاقه مند نگه می دارد.
- افزایش دید ارتباطات: اطمینان حاصل کنید که پیام های شما بلافاصله دریافت می شود، حتی زمانی که افراد فعال نیستند. اعلان های فوری ارسال کنید و تجربه ای روان را برای کاربران فراهم کنید.
- حفظ حفظ: از اعلانهای فشاری استفاده کنید که به وضوح قابل مشاهده هستند تا کاربران خود را ترغیب به بازگشت کنید. میتوانید با بازگرداندن مشتریان به وبسایت و برنامه خود، حفظ کاربر را افزایش دهید و ریزش را کاهش دهید.
- افزایش تبدیل: با ایجاد کمپینهای فشاری پیرامون جوایز درونبرنامه، تبلیغات، تخفیفها یا سایر پیشنهادها، میتوانید فروش را افزایش دهید.
- سازمان خود را مقیاس دهید: رویکرد ارتباطی شما باید با گسترش مخاطبان شما مقیاس شود. همانطور که پایگاه مشتری شما گسترش می یابد، اعلان های فشار روشی موثر برای حفظ ارتباط با آنها هستند.
- تجربه کاربری را متصل کنید (UX): با ارائه هشدارهای تراکنشی به مصرف کنندگان برای مطلع نگه داشتن آنها و ارائه یک تجربه بین کانالی روان، می توانید اصطکاک را در طول سفر مشتری کاهش دهید.
نتیجه
در نتیجه، ما دانشی در مورد معماری سرویس اطلاع رسانی فشار مقیاس پذیر به دست آوردیم. ما همچنین ابزارهایی را که توسط همه ارائه دهندگان خدمات ابری اصلی ارائه شده است بررسی کردیم تا بتوانید اعلانهای خود را بر اساس آنها قرار دهید.
علیرغم این واقعیت که من تمام تلاش خود را کردم تا یک نمای کلی از معماری سیستم اعلان فشار را به شما ارائه دهم، در پشت صحنه چیزهای بیشتری در جریان است.
من صمیمانه امیدوارم که این اطلاعات برای شما مفید واقع شود و از آن به خوبی استفاده کنید.
پاسخ دهید