4-အဆင့် Push Notification ပင်ပန်းနွမ်းနယ်မှု မော်ဒယ်

Push notification များသည် အသုံးပြုသူတစ်ဦးကို ဆုံးရှုံးရန် အသက်သာဆုံး နည်းလမ်းဖြစ်သည်။ တစ်နေ့လျှင် push 1 ကြိမ်တွင် retention curve သည် ကောင်းမွန်နေပုံရသည် - Localytics နှင့် Urban Airship မှ စက်မှုလုပ်ငန်း ဒေတာများက သုံးလ retention 88 ရာခိုင်နှုန်းဝန်းကျင်တွင် စုဖွဲ့နေသည်။ တစ်နေ့လျှင် push 3 ကြိမ်တွင် curve သည် 17 ရာခိုင်နှုန်းအမှတ်ဖြင့် ကျဆင်းသွားသည်။ တစ်နေ့လျှင် push 5 ကြိမ်တွင်မူ 34 ဖြင့် ကျဆင်းသည်။ ပုံသဏ္ဌာန်မှာ ထောက်ထောက်နှင့် ပြန်လည်ပြုပြင်၍မရနိုင်ပါ - အသုံးပြုသူများသည် အပ်တစ်ခုက သူတို့မလိုလားသော push 2 မှ 5 ကြိမ်အထိ တစ်ပတ်လျှင် ပို့လာသောအခါ 46 ရာခိုင်နှုန်းက push ကို လုံးဝ ပိတ်လိုက်ကြသည်။

Soulwise ၏ တုံ့ပြန်မှုမှာ 4-အဆင့် ပင်ပန်းနွမ်းနယ်မှု မော်ဒယ်တစ်ခု ဖြစ်သည်။ ၎င်းသည် 14 ရက်တာ ရွေ့လျားနေသော ကာလအတွင်း open-rate ကျဆင်းမှုကို သိရှိနိုင်ပြီး အသုံးပြုသူ အပြီးအပိုင် မထွက်ခွာမီ notification ပမာဏကို တဖြည်းဖြည်း လျှော့ချပေးသည်။

ဤပို့စ်တွင် ဒီဇိုင်း၊ threshold များနှင့် ပြန်လည်ထူထောင်ရေး logic တို့ကို လမ်းလျှောက်ရှင်းပြထားသည်။

အကျဉ်းချုပ်

• Soulwise ၏ 4-အဆင့် push notification ပင်ပန်းနွမ်းနယ်မှု မော်ဒယ်သည် အသုံးပြုသူများ ရပ်တန့်မသွားမီ စိတ်ဝင်စားမှုလျော့ကျခြင်းကို ရှာဖွေပြီး notification အရေအတွက်ကို လျှော့ချရန် 14-ရက် open-rate ဝင်းဒိုးကို လှည့်ပတ်အသုံးပြုပါသည်။
• အဆင့် 0 (ကျန်းမာသော) သည် အပြည့်အစုံ အချိန်ဇယားဖြစ်သည်။
• အဆင့် 1 (လျှော့ချထားသော) သည် နံနက်ပိုင်းအလယ် push ကို ဖယ်ထုတ်ပါသည်။
• အဆင့် 2 (anchor-only) သည် နံနက်ပိုင်း ဓလေ့ထုံးတမ်း သတိပေးချက်နှင့် တနင်္ဂနွေ ပြန်လည်သုံးသပ်ချက်ကို ထိန်းသိမ်းထားပါသည်။
• အဆင့် 3 (weekly-only) သည် တစ်ပတ်လျှင် push တစ်ကြိမ်အထိ လျှော့ချပါသည်။

အဆင့်လေးဆင့်

State machine သည် သေးငယ်ပါသည်။ အသုံးပြုသူတိုင်းသည် တစ်ချိန်တွင် အဆင့်တစ်ခုထဲ၌သာ ရှိနေသည်။

• T0 - ကျန်းမာသန်စွမ်း။ အချိန်ဇယားအပြည့်အစုံ။ နံနက်ခင်း ဝတ်ပြုမှု prompt၊ နံနက်လယ် အခြေအနေအလိုက် တွန်းအားပေးချက်၊ ညနေခင်း ဆင်ခြင်သုံးသပ်မှု၊ ထို့အပြင် ဖြစ်ရပ်အလိုက် ချိတ်ဆက်ထားသော prompt များ။
• T1 - အဆင့်နှိမ့်ချ။ နံနက်လယ် အခြေအနေအလိုက် တွန်းအားပေးချက်ကို ခေတ္တရပ်နားထားသည်။ ကျန်အရာအားလုံး ဆက်လက်လုပ်ဆောင်နေသည်။
• T2 - ချိတ်ဆက်ချက်သာ။ နံနက်ခင်း ဝတ်ပြုမှု prompt နှင့် တနင်္ဂနွေ ပြန်လည်သုံးသပ်ချက်သာ ကျန်ရှိသည်။ ရွေးချယ်ပိုင်ခွင့်ရှိသော push အားလုံးကို ခေတ္တရပ်နားထားသည်။
• T3 - အပတ်စဉ်သာ။ အပတ်စဉ် push တစ်ခုသာ ကျန်ရှိသည်။ နေ့စဉ်စည်းချက်ကို ဆိုင်းငံ့ထားသည်။

အစီအစဉ်က အရေးကြီးပါသည်။ နံနက်လယ်သည် ဖြစ်ရပ်အလေးချိန် အနိမ့်ဆုံးဖြစ်သောကြောင့် ဦးစွာ ဖယ်ရှားခံရသည်— ၎င်းသည် နေ့စဉ် ဝတ်ပြုမှု၏ အစိတ်အပိုင်းမဟုတ်ဘဲ အခြေအနေအလိုက် တွန်းအားပေးချက်တစ်ခုသာ ဖြစ်သည်။ နံနက်ခင်း prompt ကို အကြာဆုံး ထိန်းသိမ်းထားရသည်၊ အကြောင်းမှာ ဖြစ်ရပ်အလိုက် ချိတ်ဆက်ထားသော နေ့စဉ် push များသည် ယေဘုယျ push များထက် retention ကို 2.85 ဆခန့် ပိုမိုထုတ်ပေးနိုင်သောကြောင့်ဖြစ်သည်; ၎င်းကို ဖျက်ဆီးခြင်းသည် app ကို ဖျက်ဆီးခြင်းဖြစ်သည်။

အဆင့်ပြောင်းလဲမှုကို ဘာက ဖြစ်ပေါ်စေသလဲ

အသုံးပြုသူတစ်ဦးချင်းစီအတွက် open-rate ဒေတာ၏ 14 ရက်တာ လှည့်ပတ်ကာလ။ နေ့စဉ်တွင် မော်ဒယ်က နောက်ဆုံး 14 ရက်ကို ကြည့်ပြီး ထိုကာလအတွင်း ပို့ထားသော push notification များအတွက် အသုံးပြုသူ၏ open rate ကို တွက်ချက်ပါသည်။

Soulwise ၏ သတ်မှတ်ချက်မှာ အသုံးပြုသူ၏ ကိုယ်ပိုင် baseline မှ 30 ရာခိုင်နှုန်း open-rate ကျဆင်းမှု ဖြစ်သည်။ အသုံးပြုသူတစ်ဦးက push များ၏ 60 ရာခိုင်နှုန်းကို ပုံမှန်ဖွင့်ကြည့်လေ့ရှိပြီး လှည့်ပတ်ကာလတွင် 42 ရာခိုင်နှုန်း သို့မဟုတ် ထိုထက်နိမ့်သွားပါက မော်ဒယ်က သူ့ကို အဆင့်တစ်ဆင့် နှိမ့်ချလိုက်ပါသည်။ အပတ်တစ်ပတ်တည်း ဆိုးဝါးခြင်း (အားလပ်ရက်၊ ဖျားနာခြင်း၊ အလုပ်များသော အပတ်) တစ်ခုကိုသာ တုံ့ပြန်မိခြင်းမှ ရှောင်ရှားရန် ထိုကျဆင်းမှုသည် အနည်းဆုံး 3 ရက်ကြာ ဆက်လက်တည်ရှိနေရပါမည်။

အဆင့်တိုးမြှင့်ခြင်းသည်လည်း ဟန်ချက်ညီသည်။ အသုံးပြုသူတစ်ဦးသည် T2 တွင်ရှိပြီး သူ၏ open rate သည် baseline အနုတ် 30 ရာခိုင်နှုန်း သတ်မှတ်ချက်ထက် 3 ရက်ဆက်တိုက် ပြန်တက်လာပါက သူတို့ T1 သို့ တက်သွားပါသည်။ T0 သို့ ပြန်လည်ရောက်ရှိရန်လည်း တူညီသော အဆင့်အတိုင်းပင် ဖြစ်သည်။

Event ကို အခြေခံသော push များ အရှည်ကြာဆုံး ရှင်သန်ရသည့် အကြောင်း

ဒီ design ကို မောင်းနှင်ပေးသော Localytics / Urban Airship data အချက်မှာ - event ကို အခြေခံသော နေ့စဉ် push များသည် ယေဘုယျ နေ့စဉ် push များထက် retention ကို 2.85 ဆခန့် ပိုထုတ်ပေးနိုင်ခြင်းပင်။ မနက် 9 နာရီတွင် ပို့သော ယေဘုယျ "ကျွန်ုပ်တို့ဆီ ဝင်ကြည့်လိုက်ပါ!" ဆိုသည်မှာ မှတ်မိစရာမရှိပေ။ ယနေ့၏ တကယ့် cycle phase နှင့် ချိတ်ဆက်ထားသော မနက်ခင်း prompt တစ်ခု ("ဖြည်းညှင်းစွာ စတင်ပါ။ ဒီနေ့ သင့်အတွက် ဘာတွေ ရှိနေသလဲ။") သည် event ကို အခြေခံထားသည် - အချက်အလက်အသစ် ပါဝင်နေသောကြောင့်ပင်။

T2 သည် မနက်ခင်း prompt ကို ဆက်လက်ထိန်းသိမ်းထားသည်၊ အဘယ်ကြောင့်ဆိုသော် ၎င်းကို ဖယ်ရှားလိုက်ပါက နေ့စဉ်ဝတ်တန်းတစ်ခုလုံး ပျက်စီးသွားသောကြောင့်ဖြစ်သည်။ app ထဲက အခြားအရာအားလုံးကို အသုံးပြုသူသည် မနက် တစ်ကြိမ်၊ ည တစ်ကြိမ် log in ဝင်ရောက်မှုကို အခြေခံ၍ တည်ဆောက်ထားသည်။ prompt မရှိလျှင် loop ပြတ်တောက်သွားမည်။

fatigue-banner UX

အသုံးပြုသူ တစ်ဦးကို လျှော့ချလိုက်သောအခါ နောက်တစ်ကြိမ် app ကို ဖွင့်လိုက်သည့်အချိန်တွင် app အတွင်း၌ banner သေးသေးတစ်ခု ပေါ်လာပါသည်။

"7 ရက်ကြာ လျှော့ထားခဲ့ပါတယ် - ပြန်တိုးချင်ပါသလား?"

ထိုစာကြောင်းသည် အရာသုံးခု လုပ်ဆောင်ပါသည်— ပြောင်းလဲမှုကို အသိအမှတ်ပြုသည်၊ ၎င်းကို app ၏ အပြုအမူဟု သတ်မှတ်သည် (အသုံးပြုသူ၏ ကျရှုံးမှု မဟုတ်ပါ)၊ ပြီးတော့ ရွေးချယ်ပိုင်ခွင့် ပေးသည်။ အသုံးပြုသူသည် notification များ ပြန်လိုချင်ပါက တစ်ချက်နှိပ်ရုံဖြင့် ထိုလျှော့ချမှုကို ကျော်လွှားနိုင်ပါသည်။

ဤအချက်က အရေးကြီးပါသည်။ အကြောင်းမှာ တိတ်တဆိတ် လျှော့ချမှုသည် app က အသုံးပြုသူကို စွန့်ပစ်လိုက်သလို ခံစားရစေသည်။ ထင်ရှားသော လျှော့ချမှုကမူ app က ဂရုစိုက်နေသလို ခံစားရစေသည်။ အလုပ်က အတူတူပင်ဖြစ်သော်လည်း တင်ပြပုံ ကွဲပြားခြင်းပါတည်း။

ကျွန်ုပ်တို့ တမင်တကာ မတည်ဆောက်ခဲ့သော anti-pattern များ

မည်သည်တို့ကို တားမြစ်ထားသည်ဆိုသည်ကို product spec က ရှင်းရှင်းလင်းလင်း ဖော်ပြထားသည် —

• "သင့် streak မကျိုးပါစေနဲ့" ဟူသော အပြစ်ရှိစေသည့် push မရှိပါ။ Streak များသည် ဆုံးရှုံးမှုကို ကြောက်ရွံ့စေပြီး အရှက်ရစေသည့်အရာဖြစ်သည်။ Fatigue model သည် အသုံးပြုသူများကို နှိမ့်ချသည်; အရှက်ရမစေပါ။
• T3 ၏ အဆုံးတွင် "သင့်ကို လွမ်းနေပါပြီ" ဟူသော reactivation push မရှိပါ။ T3 တွင်ရှိသော အသုံးပြုသူသည် app ကို တစ်စုံတစ်ရာ ပြောနေပြီးဖြစ်သည်။ push များ ထပ်ထည့်ခြင်းသည် မှားယွင်းသော တုံ့ပြန်မှုဖြစ်သည်။
• Push body များတွင် တုပြသည့် counter များ သို့မဟုတ် ရှားပါးမှု မရှိပါ။ "လူ X ဦး ယခုပင် စာရင်းသွင်းလိုက်ပြီ" ဆိုသည်မှာ dark-pattern ပြဇာတ်တစ်ခုသာဖြစ်ပြီး notification မဟုတ်ပါ။
• Push ခေါင်းစဉ် သို့မဟုတ် body များတွင် ဓမ္မတာ သို့မဟုတ် ဗေဒင်ဆိုင်ရာ အကြောင်းအရာ မရှိပါ။ Push သည် တားမြစ်ထားသော pattern များပါဝင်သည့် build များကို ငြင်းပယ်သော CI lint ကို ဖြတ်သန်းရသည်; fatigue model သည် ၎င်းကို ဘယ်တော့မှ ကျော်လွှားမသွားပါ။

စနစ်အတွင်းရှိ ဒေတာ အမှန်တကယ် မည်သို့ရှိသည်ကို

မော်ဒယ်သည် အသုံးပြုသူတစ်ဦးချင်းစီ၏ အခြေအနေကို ကွက်လပ်သုံးခုဖြင့် သိမ်းဆည်းထားသည်။

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

ဤသည်မှာ ပင်ပန်းနွမ်းနယ်မှု အခြေအနေ တစ်ခုလုံးဖြစ်သည်။ ကြည့်ရှုခဲ့သည့် မှတ်တမ်းမရှိ၊ open rate ထက်ကျော်လွန်သော ပါဝင်ဆက်နွှယ်မှု အမှတ်ပေးခြင်းမရှိ၊ အသုံးပြုသူအပေါ် လေ့ကျင့်ထားသော machine-learning မော်ဒယ်လည်း မရှိပါ။ ရိုးရှင်းမှုသည်ပင် အဓိကအချက်ဖြစ်သည်— စည်းမျဉ်းများကို စစ်ဆေးနိုင်၊ သတ်မှတ်အဆင့်များကို မှတ်တမ်းတင်ထား၊ UX ၏ အကျိုးဆက်များကို ကြိုတင်ခန့်မှန်းနိုင်သည်။

ဤအရာ မဟုတ်သည့်အရာများ

နယ်ပယ်အကွာအဝေးအကြောင်း မှတ်ချက်တစ်ခု။

fatigue မော်ဒယ်သည် per-user ဖြစ်ပြီး per-cohort မဟုတ်ပါ။ "သင်နှင့်တူသော အသုံးပြုသူများ" ကို ကျွန်ုပ်တို့ မကြည့်ပါ၊ retention အကြောင်း လေ့လာရန် အသုံးပြုသူများကို နှိမ့်ချသည့် စမ်းသပ်မှုများကိုလည်း မလုပ်ဆောင်ပါ။ မော်ဒယ်သည် တစ်ဦးချင်းစီအတွက် အလုပ်လုပ်ပါသည်။

၎င်းသည် အသုံးပြုသူ ထိန်းချုပ်နိုင်သော ဆက်တင်များကိုလည်း အစားမထိုးပါ။ Quiet hours၊ per-category mute နှင့် disable-all-pushes တို့သည် fatigue မော်ဒယ်နှင့် သီးခြားစီ အလုပ်လုပ်ကြပါသည်။ စနစ်နှစ်ခုသည် ပေါင်းစပ်အလုပ်လုပ်ကြသည်; အသုံးပြုသူ၏ တိကျသော ရွေးချယ်မှုသည် မော်ဒယ်၏ ခန့်မှန်းချက်ထက် အမြဲတမ်း အနိုင်ရပါသည်။

ဤအချက်သည် app ၏ ကျန်အပိုင်းများအတွက် အဘယ်ကြောင့် အရေးကြီးသနည်း

နေ့စဉ်ဓလေ့တစ်ခု နေ့စဉ်ဆက်လက်တည်ရှိနိုင်ရန်မှာ push notification များကြောင့်ဖြစ်သည်။ push ခွင့်ပြုချက်ဆုံးရှုံးသွားသော check-in app တစ်ခုသည် ၎င်း၏ အဓိက retention loop ကို ဆုံးရှုံးသွားပါသည်။ 4-tier model ရှိနေခြင်းမှာ app သည် ထိုခွင့်ပြုချက်ကို အလွဲသုံးစားမလုပ်မိစေရန်နှင့် အနည်းငယ်စီ ကြာရှည်စွာ စိတ်အနှောင့်အယှက်ဖြစ်စေခြင်းဖြင့် ဖြည်းဖြည်းချင်း ဆုံးရှုံးမသွားစေရန်ဖြစ်သည်။

နေ့စဉ်ဓလေ့နှင့်ပတ်သက်သော ပြည့်စုံသည့်အကြောင်းအရာများကို Soulwise hub တွင် ဖတ်ရှုနိုင်ပါသည်။ fatigue model သည် ဓလေ့ကို တောင်းဆိုသည့်ပုံစံအစား အပြန်အလှန်ပါဝင်နိုင်စေသည့် အကြောင်းရင်းတစ်ခုဖြစ်သည်။

အတိုချုံးပြောရလျှင် — မှန်ကန်သော push အရေအတွက်ဆိုသည်မှာ opt-out မဖြစ်စေသည့် အများဆုံးအရေအတွက်ဖြစ်သည်။ fatigue model သည် ထိုအရေအတွက်ကို အသုံးပြုသူတစ်ဦးချင်းအလိုက် 14 ရက်တိုင်း ရှာဖွေပေးသည့်နည်းလမ်းဖြစ်ပါသည်။

အမေးများသော မေးခွန်းများ

Push အရေအတွက်က retention အတွက် ဘာကြောင့် ဒီလောက်အရေးပါသလဲ။

Localytics နှင့် Urban Airship တို့၏ စက်မှုဒေတာ — တစ်ရက်လျှင် push တစ်ကြိမ်သည် သုံးလ retention 88% ခန့်နှင့် ကိုက်ညီပါသည်။ တစ်ရက်လျှင် push သုံးကြိမ်ဆိုလျှင် ၎င်းကို 17 ရာခိုင်နှုန်းအချက်အလက် ကျသွားစေသည်။ တစ်ရက်လျှင် push ငါးကြိမ်ဆိုလျှင် 34 ရာခိုင်နှုန်းအချက်အလက် ကျသွားသည်။ ကျဆင်းမှု ပုံသဏ္ဌာန်က မတ်စောက်ပါသည်။

ဒီနေရာမှာ "rolling 14 ရက် ကာလအကန့်" ဆိုတာ ဘာကို ဆိုလိုသလဲ။

နေ့စဉ်၌ မော်ဒယ်သည် အသုံးပြုသူ၏ ဖွင့်ကြည့်နှုန်းကို နောက်ဆုံး 14 ရက်အတွင်း ပြန်တွက်ချက်ပါသည်။ ကာလအကန့်သည် ရှေ့သို့ ရွေ့လျားသွားကာ ဟောင်းနေသော ဒေတာများ ထွက်ခွာသွားသည်။ ဤနည်းဖြင့် တစ်ပတ်တာ ဆိုးရွားမှုတစ်ခုတည်းကို လွန်ကဲစွာ တုံ့ပြန်ခြင်းမရှိဘဲ မကြာသေးမီက ပါဝင်မှု ကျဆင်းခြင်းကို အမြန် ဖမ်းဆုပ်နိုင်ပါသည်။

အသုံးပြုသူသည် အဆင့်နိမ့်မှ ပြန်လည် နာလန်ထူနိုင်ပါသလား။

ပြန်ထူနိုင်ပါသည်။ rolling ကာလအကန့်အတွင်း ဖွင့်ကြည့်နှုန်းသည် သတ်မှတ်အဆင့်ထက် ပြန်တက်လာပါက အသုံးပြုသူသည် အဆင့်ပြန်တက်လာပါသည်။ မော်ဒယ်သည် ညီမျှသည်။ ကျဆင်းမှုက အဆင့်လျှော့ချ၍ ပြန်ထူမှုက အဆင့်တိုးမြှင့်ပေးသည်။

ဤfeature ၏ အဆိုးဆုံး ပုံစံက အ�’ဘယ်လိုနည်း။

ပါဝင်မှု မည်သို့ပင်ရှိစေ အများဆုံး အရေအတွက်ဖြင့် ပို့သည့် ရိုးစင်းသော push စနစ်ဖြစ်သည်။ စက်မှုဒေတာအရ အသုံးပြုသူ 46% သည် မိမိ တကယ်မလိုလားသော app တစ်ခုထံမှ တစ်ပတ်လျှင် push 2 ကြိမ်မှ 5 ကြိမ်အထိ လက်ခံရရှိသည့်အခါ push ကို လုံးဝ ရပ်တန့်လိုက်ကြသည်။ ဤ opt-out မဖြစ်စေရန် fatigue မော်ဒယ် တည်ရှိနေခြင်း ဖြစ်ပါသည်။