بازیابی سبد خرید رهاشده با وب پوش و RetenX؛ طراحی جریان ارسال
برای بازیابی سبد خرید رهاشده، یک رویداد افزودن کالا به سبد را به‌تنهایی مبنای ارسال قرار ندهید. ابتدا باید کاربر برای دریافت اعلان رضایت داده باشد، سپس درست پیش از هر ارسال از سرور بررسی کنید که خریدی انجام نشده، کالا هنوز قابل‌فروش است و پیشنهاد پیام اعتبار دارد. این کنترل‌ها، همراه با سقف مشخص پیام و گروه کنترل، workflow را از یک یادآوری مزاحم به آزمایشی قابل‌اندازه‌گیری تبدیل می‌کند.
در این مقاله:
- اصول workflow سبد رهاشده
- رضایت و داده‌های لازم
- طراحی مرحله‌به‌مرحله جریان
- کنترل سروری درست پیش از ارسال
- متن، موجودی و پیشنهاد معتبر
- انتساب و گروه کنترل
- جایگاه Pushfa و RetenX
- پرسش‌های متداول
اصول workflow سبد رهاشده
سبد رهاشده باید یک وضعیت موقت و قابل‌تغییر در فروشگاه باشد، نه یک برچسب دائمی برای ارسال تبلیغاتی. برای هر سبد، شناسه‌ای پایدار، زمان آخرین تغییر، اقلام، مبلغ، وضعیت سفارش و شناسه مشترک وب‌پوش را نگه دارید. اگر کاربر با دستگاه دیگری خرید کرده یا سبد را خالی کرده است، وضعیت سرور باید بر داده قدیمی مرورگر مقدم باشد.
- رضایت مشخص: فقط به مشترکانی پیام دهید که اجازه دریافت اعلان داده‌اند و امکان لغو اشتراک یا مدیریت اعلان را در اختیارشان بگذارید.
- حذف خریدار: تکمیل سفارش باید پیش از هر مرحله ارسال بررسی شود؛ حتی اگر کاربر قبلاً روی پیام اول کلیک کرده باشد.
- فرکانس محدود: برای هر سبد و هر مشترک سقف تعریف کنید؛ برای نمونه، حداکثر دو یادآوری در ۷۲ ساعت، مگر اینکه سیاست کسب‌وکار شما آگاهانه مقدار دیگری تعیین کند.
- پیشنهاد واقعی: قیمت، تخفیف، مهلت و موجودی باید هنگام آماده‌سازی پیام از منبع معتبر خوانده شوند.
- سنجش منصفانه: بخشی از واجدان شرایط را بدون پیام نگه دارید تا اثر واقعی workflow با رفتار طبیعی مقایسه شود.
این اعداد فقط یک مثال اجرایی هستند، نه نرخ یا زمان‌بندی تضمین‌شده. فاصله ارسال را با توجه به چرخه خرید، حساسیت کالا و بازخورد لغو اشتراک اصلاح کنید.
رضایت و داده‌های لازم
درخواست اجازه وب‌پوش را به یک اقدام روشن کاربر مانند کلیک روی «دریافت وضعیت سفارش» یا «اطلاع از تخفیف» وابسته کنید و ارزش پیام‌ها را قبل از درخواست توضیح دهید. در iOS و iPadOS، وب‌پوش برای وب‌اپ‌هایی که به صفحه اصلی افزوده شده‌اند و پس از یک اقدام مستقیم کاربر درخواست می‌شود؛ تب معمولی مرورگر را نباید معادل آن فرض کرد. جزئیات فنی این محدودیت در راهنمای WebKit درباره وب‌پوش در iOS و iPadOS آمده است.
برای اجرای قابل‌ردیابی، حداقل این داده‌های سمت سرور را ثبت کنید:
- شناسه داخلی سبد و شناسه کاربر یا مشتری، با حداقل داده شخصی لازم؛
- شناسه مشترک وب‌پوش و زمان ثبت رضایت؛
- فهرست اقلام، نسخه قیمت و لینک صفحه سبد؛
- رویدادهای افزودن به سبد، شروع پرداخت، تکمیل خرید، لغو سفارش و انصراف از اشتراک؛
- زمان آخرین پیام این workflow، تعداد پیام‌ها و عضویت در گروه کنترل.
اطلاعات حساس را در متن اعلان یا پارامترهای URL قرار ندهید. اگر برای انتساب کمپین از UTM استفاده می‌کنید، نام کمپین و مرحله پیام را ثابت و غیرشخصی انتخاب کنید؛ شناسه فردی یا داده خصوصی نباید در URL بیاید.
طراحی مرحله‌به‌مرحله جریان
۱. آغاز با رویداد مناسب
رویداد add_to_cart به‌تنهایی برای همه فروشگاه‌ها کافی نیست. بهتر است شرط ورود، افزودن کالا یا آغاز پرداخت باشد و پس از یک بازه سکون تعریف شود؛ مثلاً اگر تا ۳۰ دقیقه سبد تغییر نکرد و سفارشی ثبت نشد، کاربر واجد شرایط بررسی اولیه شود. این زمان نمونه است و باید با چرخه واقعی خرید آزمایش شود.
۲. انتظار و بررسی دوباره
در ابتدای هر مرحله پیام، وضعیت سفارش را از سیستم فروش بخوانید. اگر خرید انجام شده، سبد خالی شده، کاربر لغو اشتراک کرده یا سقف پیام پر شده است، workflow را متوقف کنید. برای جلوگیری از مسابقه بین رویدادها، اجرای مرحله ارسال را با شناسه سبد و مرحله پیام به‌صورت یکتا ثبت کنید.
۳. پیام‌های محدود و متفاوت
یک الگوی محافظه‌کارانه می‌تواند شامل یادآوری ساده پس از فاصله کوتاه و، فقط در صورت ادامه شرایط، یک پیام ارزش‌محور در روز بعد باشد. پیام سوم را پیش‌فرض نکنید؛ تنها وقتی آن را آزمایش کنید که داده‌ها نشان دهند مزاحمت و لغو اشتراک افزایش نمی‌یابد. هر پیام باید به همان سبد یا صفحه مرتبط هدایت شود.
۴. توقف قطعی
پس از تکمیل خرید، هر پیام باقی‌مانده را لغو کنید. همچنین توقف را برای اتمام موجودی، پایان پیشنهاد، رد شدن پرداخت، انقضای رضایت یا رسیدن به سقف فرکانس در نظر بگیرید.
کنترل سروری درست پیش از ارسال
مهم‌ترین کنترل، فاصله بین «واجد شرایط شدن» و «ارسال واقعی» است. یک صف زمان‌بندی‌شده ممکن است چند ساعت بعد اجرا شود؛ بنابراین نتیجه بررسی اولیه را ذخیره نکنید و همان لحظه دوباره بررسی کنید.
- با شناسه سبد، آخرین وضعیت سفارش و پرداخت را بخوانید.
- بررسی کنید که سبد هنوز اقلامی دارد و اقلام برای کاربر قابل‌خرید هستند.
- قیمت، تخفیف، کد پیشنهاد و تاریخ انقضا را از منبع فعلی فروشگاه اعتبارسنجی کنید.
- رضایت فعال، معتبر بودن مشترک و سقف فرکانس را کنترل کنید.
- گروه کنترل و قوانین منع ارسال را اعمال کنید.
- فقط پس از عبور همه کنترل‌ها، پیام را در صف Pushfa قرار دهید و نتیجه را ثبت کنید.
اگر ارسال هم‌زمان با تکمیل خرید رخ داد، اولویت باید با جلوگیری از پیام نادرست باشد. برای این حالت، قفل کوتاه‌مدت یا بررسی نسخه وضعیت سفارش در سمت سرور مفید است. این منطق، پیشنهاد پیاده‌سازی روی backend فروشگاه است و نباید به نتیجه یک رویداد قدیمی در مرورگر وابسته باشد.
برای پیام‌های آفلاین، زمان انقضا را با عمر واقعی پیشنهاد هماهنگ کنید. TTL فقط مدت تلاش برای تحویل هنگام آفلاین‌بودن را محدود می‌کند و به معنی نگهداری نامحدود یا تحویل تضمین‌شده نیست؛ تفاوت رفتار انواع پیام و عمر آن‌ها در مستندات Firebase درباره طول عمر پیام توضیح داده شده است.
متن، موجودی و پیشنهاد معتبر
متن باید یادآور و دقیق باشد، نه ادعایی. در Pushfa، طول عنوان حداکثر ۳۵ و طول بدنه حداکثر ۱۵۰ کاراکتر است؛ نام کالا، مبلغ نهایی و دعوت به اقدام را طوری بنویسید که در همین محدودیت جا شود.
نمونه فرضی بدون تخفیف: عنوان: «سبد شما باقی مانده»؛ بدنه: «کفش ورزشی شما هنوز در سبد است. در صورت تمایل، ادامه خرید را از همین‌جا ببینید.»
نمونه فرضی با پیشنهاد: عنوان: «پیشنهاد سبد شما»؛ بدنه: «کد SAVE10 تا ساعت ۲۳:۵۹ معتبر است؛ قیمت و موجودی را پیش از پرداخت بررسی کنید.»
نمونه دوم فقط زمانی درست است که کد واقعاً برای همان کاربر فعال باشد، تاریخ انقضا از سرور خوانده شده باشد و کالا مشمول آن باشد. از عباراتی مانند «موجودی محدود» یا «آخرین فرصت» بدون داده معتبر استفاده نکنید. نمایش تصویر یا قالب خاص را نیز به پشتیبانی واقعی مرورگر و تنظیمات سرویس وابسته بدانید، نه یک قابلیت همیشگی.
انتساب و گروه کنترل
برای هر مرحله یک نام کمپین و برچسب ثابت بسازید؛ برای نمونه، cart_reminder_1 و cart_reminder_2. لینک را به صفحه سبد یا محصول مربوط بفرستید و UTMهای یکسانی مانند utm_source=webpush و utm_campaign=cart_recovery داشته باشید. اگر کاربر از کانال دیگری نیز پیام گرفته است، این هم‌پوشانی را ثبت کنید تا خرید را به‌اشتباه به وب‌پوش نسبت ندهید.
گروه کنترل باید هنگام ورود به workflow به‌صورت تصادفی انتخاب شود و تا پایان دوره از پیام بازیابی همان سبد محروم بماند. سپس حداقل این شاخص‌ها را بین دو گروه مقایسه کنید:
- نرخ تکمیل خرید در یک بازه ثابت؛
- درآمد یا حاشیه سود افزوده، نه فقط تعداد کلیک؛
- نرخ کلیک، لغو اشتراک و شکایت؛
- هزینه تخفیف و سهم سفارش‌های تکمیل‌شده بدون تخفیف.
گزارش تحویل یا کلیک نشان می‌دهد پیام در مسیر سرویس چه وضعیتی داشته است، اما تحویل یا تأیید نمایش را نباید معادل خواندن انسانی بدانید. در Pushfa گزارش‌های تحویل و کلیک، صف و APIهای سروری برای اتصال به backend در دسترس‌اند؛ کلیدهای خصوصی باید فقط روی سرور نگهداری شوند.
جایگاه Pushfa و RetenX
Pushfa از FCM، موضوع‌ها، توکن‌های مشترک ذخیره‌شده، نام مستعار، گزارش تحویل و کلیک و APIهای سروری پشتیبانی می‌کند. برای اتصال سمت کاربر، از کلید عمومی سرویس و فایل ریشه pushfa-messaging-sw.js دانلودشده از پنل استفاده کنید و قطعه‌کد دقیق همان پنل را به‌کار ببرید؛ نام بسته یا تابعی خارج از مستندات رسمی فرض نکنید.
RetenX را می‌توان برای تعریف جریان، صف‌گذاری، گزارش و شرط‌های رفتاری به‌کار برد، اما فعال‌بودن اشتراک پریمیوم و فعال‌سازی توسط مدیر لازم است. اگر کنترل نهایی خرید، موجودی یا قیمت در سامانه فروشگاه انجام می‌شود، آن کنترل را در backend خودتان نگه دارید و پیش از ارسال به workflow برگردانید؛ صرف ورود کاربر به یک مرحله نباید مجوز ارسال تلقی شود.
برای پیاده‌سازی پایه پوشفا می‌توانید راهنمای فعال‌سازی وب‌پوش در سایت را ببینید و برای تعیین سقف پیام، نکات کنترل فرکانس ارسال را با قواعد اختصاصی سبد خود تطبیق دهید.
پرسش‌های متداول
آیا بلافاصله پس از افزودن کالا پیام بفرستیم؟
معمولاً نه. ابتدا یک بازه سکون و سپس بررسی سروری سفارش، رضایت، موجودی و سقف پیام را اجرا کنید. این کار پیام‌های بی‌مورد برای کاربری را که هنوز در حال خرید است کاهش می‌دهد.
اگر کاربر پس از پیام اول خرید کند چه می‌شود؟
رویداد خرید باید در backend ثبت و مراحل باقی‌مانده متوقف شود. پیش از هر ارسال زمان‌بندی‌شده نیز وضعیت سفارش دوباره خوانده شود؛ لغو پیام فقط در زمان ایجاد workflow کافی نیست.
آیا گروه کنترل برای فروشگاه کوچک هم لازم است؟
بله، اگر حجم سفارش اجازه دهد. حتی یک گروه کنترل ساده و ثابت می‌تواند نشان دهد افزایش خرید واقعاً از پیام آمده یا بخشی از کاربران بدون پیام هم بازمی‌گشتند.
آیا نرخ تحویل به معنی دیده‌شدن پیام است؟
خیر. گزارش تحویل یا نمایش فنی، نشانه خواندن انسان نیست. کلیک و تکمیل خرید نیز باید با احتیاط و با درنظرگرفتن هم‌پوشانی کانال‌ها تفسیر شود.