مدل 4 مرحله‌ای خستگی از اعلان‌های فشاری

اعلان‌های فشاری ارزان‌ترین راه برای از دست دادن یک کاربرند. منحنی ماندگاری با 1 اعلان در روز خوب به نظر می‌رسد؛ داده‌های صنعتی از Localytics و Urban Airship حول‌وحوش 88 درصد ماندگاری ۳‌ماهه جمع می‌شوند. با 3 اعلان در روز، منحنی 17 واحد درصدی افت می‌کند. با 5 اعلان در روز، 34 واحد افت می‌کند. شکل این افت تند و برگشت‌ناپذیر است: 46 درصد از کاربران به‌کلی اعلان‌ها را غیرفعال می‌کنند وقتی اپلیکیشنی هفته‌ای 2 تا 5 اعلان ناخواسته برایشان می‌فرستد.

پاسخ Soulwise یک مدل 4 مرحله‌ای خستگی است. این مدل افت نرخ بازشدن را در یک بازهٔ متحرک 14 روزه تشخیص می‌دهد و حجم اعلان‌ها را پیش از آنکه کاربر برای همیشه آن‌ها را غیرفعال کند، به‌تدریج کاهش می‌دهد.

این نوشته شما را با طراحی، آستانه‌ها و منطق بازیابی آشنا می‌کند.

۴ سطح

ماشین حالت کوچک است. هر کاربر در هر لحظه دقیقاً در ۱ سطح قرار دارد.

• T0 — سالم. برنامهٔ کامل. یادآور آیین صبحگاهی، تلنگر زمینه‌ای میانهٔ صبح، تأمل عصرگاهی، به‌علاوهٔ یادآورهای متصل به رویداد.
• T1 — تنزل‌یافته. تلنگر زمینه‌ای میانهٔ صبح متوقف می‌شود. باقی موارد ادامه می‌یابند.
• T2 — فقط لنگرها. تنها یادآور آیین صبحگاهی و مرور یکشنبه باقی می‌مانند. همهٔ پوش‌های اختیاری متوقف می‌شوند.
• T3 — فقط هفتگی. تنها ۱ پوش هفتگی باقی می‌ماند. ریتم روزانه معلق می‌شود.

ترتیب اهمیت دارد. میانهٔ صبح اولین موردی است که حذف می‌شود، چون کمترین وزن رویدادی را دارد: یک تلنگر زمینه‌ای است، نه بخشی از خودِ آیین روزانه. یادآور صبحگاهی بیش از همه حفظ می‌شود، چون پوش‌های روزانهٔ متصل به رویداد حدود 2.85 برابر پوش‌های عمومی نگه‌داشت کاربر ایجاد می‌کنند؛ حذف آن یعنی نابودی اپلیکیشن.

چه چیزی باعث تغییر سطح می‌شود

یک بازهٔ متحرک 14 روزه از داده‌های نرخ بازشدن برای هر کاربر. مدل هر روز به 14 روز گذشته نگاه می‌کند و نرخ بازشدن کاربر را برای اعلان‌های ارسال‌شده در آن بازه محاسبه می‌کند.

آستانهٔ Soulwise برابر است با 30 درصد افت نرخ بازشدن نسبت به خط پایهٔ شخصی کاربر. اگر کاربری معمولاً 60 درصد اعلان‌ها را باز می‌کند و بازهٔ متحرک به 42 درصد یا کمتر برسد، مدل او را یک سطح پایین می‌برد. این افت باید دست‌کم 3 روز ادامه داشته باشد تا به یک هفتهٔ بد تنها واکنش نشان داده نشود (یک سفر، بیماری، یا هفته‌ای پرکار).

ارتقا هم متقارن است. اگر کاربری در سطح T2 باشد و نرخ بازشدنش به مدت 3 روز متوالی دوباره از خط پایه‌اش منهای آستانهٔ 30 درصد بالاتر برود، به T1 می‌رود. بازگشت به T0 هم همین مسیر را طی می‌کند.

چرا نوتیفیکیشن‌های مبتنی‌بر رویداد بیشترین دوام را دارند

این دادهٔ Localytics / Urban Airship است که طراحی را شکل می‌دهد: نوتیفیکیشن‌های روزانهٔ مبتنی‌بر رویداد تقریباً 2.85 برابرِ نوتیفیکیشن‌های روزانهٔ عمومی ماندگاری ایجاد می‌کنند. یک پیام عمومیِ «سری به ما بزن!» ساعت 9 بامداد فراموش‌شدنی است. اما یک یادآور صبحگاهی که به فاز واقعی چرخهٔ امروز گره خورده («شروعی آرام. امروز چه کارهایی پیشِ رو داری؟») مبتنی‌بر رویداد است؛ اطلاعات تازه‌ای در خود دارد.

T2 یادآور صبحگاهی را حفظ می‌کند، چون حذف آن کل آیینِ روزانه را از بین می‌برد. باقی بخش‌های اپ حول این ساخته شده‌اند که کاربر یک‌بار صبح و یک‌بار شب وارد شود. بدون این یادآور، چرخه می‌شکند.

تجربهٔ کاربری بنر خستگی

وقتی کاربر به سطح پایین‌تر منتقل می‌شود، اپ در دفعهٔ بعد که آن را باز کند، بنر کوچکی داخل برنامه نشان می‌دهد:

«برای 7 روز کمی فاصله گرفتیم - دوباره فعالش کنیم؟»

این جمله ۳ کار می‌کند: تغییر را به رسمیت می‌شناسد، آن را به رفتار خودِ اپ نسبت می‌دهد (نه به کوتاهی کاربر) و اختیار را به کاربر می‌سپارد. کاربر می‌تواند اگر بخواهد اعلان‌ها برگردند، تنها با یک ضربه این انتقال را لغو کند.

این موضوع مهم است، چون انتقالِ خاموش به این حس می‌انجامد که انگار اپ کاربر را رها کرده. اما انتقالِ روشن این حس را می‌دهد که اپ به کاربر اهمیت می‌دهد. یک کار، اما با قاب‌بندی متفاوت.

ضدالگوهایی که آگاهانه نساختیم

مشخصات محصول دربارهٔ آنچه ممنوع است صراحت دارد:

• هیچ پیام احساس‌گناهِ «زنجیره‌ات را نشکن». زنجیره‌ها نوعی شرمسارسازی مبتنی بر بیزاری از باخت‌اند. مدل خستگی، کاربر را تنزل می‌دهد؛ شرمسارش نمی‌کند.
• هیچ پیام بازفعال‌سازی «دلمان برایت تنگ شده» در پایان T3. کاربری که در T3 است، خودش دارد چیزی به اپ می‌گوید. افزودن پیام‌های بیشتر، پاسخ نادرستی است.
• هیچ شمارندهٔ جعلی یا کمیاب‌نمایی در متن پیام‌ها. «X نفر همین حالا ثبت‌نام کردند» نمایشی از الگوی تاریک است، نه یک اعلان.
• هیچ محتوای قاعدگی یا طالع‌بینی در عنوان یا متن پیام‌ها. پیام‌ها از یک لینتِ CI عبور می‌کنند که بیلدهای حاوی الگوهای ممنوعه را رد می‌کند؛ مدل خستگی هرگز آن را دور نمی‌زند.

داده‌های درون سیستم واقعاً چه شکلی‌اند

این مدل وضعیت هر کاربر را با ۳ فیلد ذخیره می‌کند:

tier: 'T0' | 'T1' | 'T2' | 'T3'
rolling_open_rate_14d: 0.0 to 1.0
baseline_open_rate: 0.0 to 1.0 (computed from first 30 days)
last_tier_change_at: timestamp

این کل وضعیت خستگی است. نه تاریخچهٔ مرور، نه امتیازدهی به تعامل فراتر از نرخ بازشدن، نه مدل یادگیری ماشینی آموزش‌دیده روی کاربر. سادگی، خودِ هدف است: قواعد قابل‌بازرسی‌اند، آستانه‌ها مستندند و پیامدهای تجربهٔ کاربری قابل‌پیش‌بینی.

آنچه این نیست

نکته‌ای دربارهٔ دامنه.

مدل خستگی برای هر کاربر به‌صورت جداگانه است، نه برای گروه. ما به «کاربرانی مثل شما» نگاه نمی‌کنیم و آزمایش‌هایی اجرا نمی‌کنیم که کاربران را برای یادگیری دربارهٔ ماندگاری تنزل دهند. این مدل در خدمت فرد است.

این مدل جایگزین تنظیمات تحت کنترل کاربر هم نمی‌شود. ساعات سکوت، بی‌صداکردن هر دسته، و غیرفعال‌کردن صریح همهٔ اعلان‌ها همگی مستقل از مدل خستگی کار می‌کنند. این ۲ سامانه با هم ترکیب می‌شوند؛ انتخاب صریح کاربر همیشه بر استنتاج مدل پیروز است.

چرا این موضوع برای بقیهٔ اپلیکیشن مهم است

اعلان‌های فشاری همان چیزی هستند که یک آیین روزانه را روزانه نگه می‌دارند. اپلیکیشن چک‌اینی که امتیاز ارسال اعلان را از دست بدهد، حلقهٔ اصلی نگه‌داشت کاربرش را از دست می‌دهد. مدل 4‌سطحی برای این وجود دارد که اپلیکیشن از این امتیاز سوءاستفاده نکند و آن را به روش کُند از دست ندهد — یعنی فقط کمی آزاردهنده بودن، آن‌قدر که کافی باشد.

زمینهٔ کامل‌تر آیین روزانه در مرکز Soulwise آمده است. مدل خستگی یکی از دلایلی است که این آیین به جای پُرتوقع بودن، دوسویه باقی می‌ماند.

نسخهٔ کوتاه‌تر: تعداد درست اعلان‌ها، بزرگ‌ترین عددی است که باعث انصراف کاربر نشود. مدل خستگی همان چیزی است که اپلیکیشن با آن این عدد را برای هر کاربر، هر 14 روز پیدا می‌کند.