4-स्तरीय Push Notification Fatigue मॉडेल

युजरला गमावण्याचा सर्वात स्वस्त मार्ग म्हणजे push notifications. दिवसाला 1 push असताना retention curve ठीक दिसतो — Localytics आणि Urban Airship यांचा उद्योगातील डेटा तीन महिन्यांच्या retention साठी सुमारे 88 टक्क्यांभोवती एकवटलेला आहे. दिवसाला 3 push असताना हा curve 17 टक्के पॉइंट्सने घसरतो. दिवसाला 5 push असताना तो 34 ने घसरतो. हा आकार तीव्र आणि अपरिवर्तनीय आहे: जेव्हा एखादे app आठवड्याला 2 ते 5 नको असलेले push पाठवते, तेव्हा 46 टक्के युजर्स push पूर्णपणे बंद करतात.

Soulwise चे यावरचे उत्तर म्हणजे 4-स्तरीय fatigue मॉडेल. ते सलग 14-दिवसांच्या window मध्ये open-rate ची घट ओळखते आणि युजर कायमचा बंद करण्याआधीच हळूहळू notification चे प्रमाण कमी करते.

ही पोस्ट या डिझाइन, थ्रेशोल्ड्स आणि recovery logic यांची माहिती देते.

थोडक्यात

• Soulwise चे 4-स्तरीय पुश नोटिफिकेशन फटिग मॉडेल 14-दिवसांच्या रोलिंग ओपन-रेट विंडोचा वापर करते, जेणेकरून वापरकर्त्यांची घटती आवड ओळखता येते आणि ते ऑप्ट-आउट करण्याआधीच नोटिफिकेशनचे प्रमाण कमी करता येते.
• स्तर 0 (हेल्दी) म्हणजे पूर्ण शेड्यूल.
• स्तर 1 (डिमोटेड) मध्ये सकाळच्या मध्यंतरीचा पुश वगळला जातो.
• स्तर 2 (फक्त अँकर) मध्ये सकाळचा रिच्युअल प्रॉम्प्ट आणि रविवारचा आढावा ठेवला जातो.
• स्तर 3 (फक्त आठवडी) मध्ये आठवड्यातून एकच पुश ठेवला जातो.

चार स्तर

स्टेट मशीन लहान आहे. प्रत्येक वापरकर्ता एका वेळी नेमक्या एका स्तरात असतो.

• T0 - Healthy. पूर्ण वेळापत्रक. सकाळचा रिच्युअल प्रॉम्प्ट, सकाळ-मध्याचा संदर्भानुसार नज, संध्याकाळचे चिंतन, आणि सोबत इव्हेंट-अँकर्ड प्रॉम्प्ट.
• T1 - Demoted. सकाळ-मध्याचा संदर्भानुसार नज थांबवला जातो. बाकी सर्व सुरू राहते.
• T2 - Anchor-only. फक्त सकाळचा रिच्युअल प्रॉम्प्ट आणि रविवारचा आढावा शिल्लक राहतो. सर्व ऐच्छिक पुश थांबवले जातात.
• T3 - Weekly-only. फक्त एकच साप्ताहिक पुश टिकतो. रोजची लय स्थगित होते.

क्रम महत्त्वाचा आहे. सकाळ-मध्याचा नज सर्वात आधी जातो कारण त्याचे इव्हेंट वेट सर्वात कमी असते: तो एक संदर्भानुसार नज आहे, रोजच्या रिच्युअलचा भाग नाही. सकाळचा प्रॉम्प्ट सर्वात जास्त काळ टिकवला जातो कारण इव्हेंट-अँकर्ड रोजचे पुश सर्वसाधारण पुशच्या तुलनेत सुमारे 2.85x रिटेन्शन देतात; तो बंद केला तर app बंद पडते.

टियर बदल कशामुळे होतो

प्रत्येक वापरकर्त्यासाठी 14 दिवसांच्या रोलिंग विंडोमधील ओपन-रेट डेटा. मॉडेल दररोज मागील 14 दिवस तपासते आणि त्या विंडोदरम्यान पाठवलेल्या push notifications साठी वापरकर्त्याचा ओपन रेट काढते.

Soulwise चा थ्रेशोल्ड म्हणजे वापरकर्त्याच्या स्वतःच्या बेसलाइनवरून 30 टक्के ओपन-रेट घट. एखादा वापरकर्ता साधारणपणे 60 टक्के push उघडत असेल आणि रोलिंग विंडो 42 टक्के किंवा त्याखाली घसरली, तर मॉडेल त्यांना एक टियर खाली आणते. एखाद्या वाईट आठवड्यावर (सुट्टी, आजारपण, कामाचा ताण असलेला आठवडा) प्रतिक्रिया देणे टाळण्यासाठी ही घट किमान 3 दिवस टिकून राहावी लागते.

बढती सममित असते. एखादा वापरकर्ता T2 वर असेल आणि त्यांचा ओपन रेट सलग 3 दिवस त्यांच्या बेसलाइनवजा 30 टक्के थ्रेशोल्डच्या वर परत चढला, तर ते T1 वर वर जातात. T0 पर्यंत पुनर्प्राप्तीसाठीही तीच पायरी लागू होते.

इव्हेंट-अँकर्ड पुश सर्वाधिक काळ का टिकतात

Localytics / Urban Airship चा डेटा पॉइंट जो या डिझाइनला चालना देतो: इव्हेंट-अँकर्ड रोजच्या पुशमुळे जेनेरिक रोजच्या पुशच्या तुलनेत साधारण 2.85x रिटेन्शन मिळते. 9 वाजता येणारा जेनेरिक "आमच्याशी संपर्क करा!" हा विसरला जातो. आजच्या प्रत्यक्ष सायकल फेजशी जोडलेला सकाळचा प्रॉम्प्ट ("शांत सुरुवात. आज तुमच्या ताटात काय आहे?") हा इव्हेंट-अँकर्ड असतो - त्यात नवीन माहिती असते.

T2 सकाळचा प्रॉम्प्ट ठेवतो, कारण तो काढून टाकल्यास संपूर्ण रोजचा रिच्युअलच नाहीसा होतो. app मधील बाकी सगळं काही युजर सकाळी एकदा आणि रात्री एकदा लॉग इन करेल या भोवती बांधलेलं आहे. प्रॉम्प्टशिवाय हा लूप तुटतो.

फटीग-बॅनर UX

जेव्हा एखाद्या युजरला डिमोट केलं जातं, तेव्हा तो पुढच्या वेळी app उघडल्यावर app आत एक छोटा बॅनर दाखवतो:

"आम्ही 7 दिवसांसाठी थोडं कमी केलं आहे - पुन्हा वाढवायचं का?"

हे वाक्य तीन गोष्टी करतं: ते बदलाची दखल घेतं, त्याचं श्रेय app च्या वर्तनाला देतं (युजरच्या अपयशाला नाही), आणि निर्णयाचं स्वातंत्र्य देतं. युजरला जर नोटिफिकेशन्स परत हवी असतील, तर तो एका टॅपने डिमोशन रद्द करू शकतो.

हे महत्त्वाचं आहे कारण मूकपणे केलेलं डिमोशन म्हणजे app ने युजरला सोडून दिल्यासारखं वाटतं. उघडपणे केलेलं डिमोशन म्हणजे app ला काळजी असल्यासारखं वाटतं. तीच कृती, पण वेगळ्या मांडणीसह.

आम्ही जाणूनबुजून बनवले नाहीत असे anti-patterns

काय निषिद्ध आहे हे product spec मध्ये स्पष्ट आहे:

• "तुमची streak तोडू नका" असा अपराधभावाचा push नाही. Streaks म्हणजे नुकसान-टाळण्याच्या भीतीतून येणारी लाजिरवाणी वागणूक. Fatigue model वापरकर्त्यांना खाली आणते; त्यांना लाजवत नाही.
• T3 च्या शेवटी "आम्हाला तुमची आठवण येते" असा reactivation push नाही. T3 वर असलेला वापरकर्ता app ला आधीच काहीतरी सांगत असतो. आणखी push देणे हा चुकीचा प्रतिसाद आहे.
• Push च्या मजकुरात खोटे counters किंवा कृत्रिम टंचाई नाही. "X लोकांनी आत्ताच sign up केले" हे dark-pattern नाटक आहे, notification नाही.
• Push च्या titles किंवा मजकुरात मासिक पाळी किंवा ज्योतिष content नाही. Push एका CI lint मधून जाते जे निषिद्ध patterns असलेले builds नाकारते; 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

हीच संपूर्ण fatigue स्थिती आहे. ब्राउझिंग इतिहास नाही, ओपन रेटपलीकडे कोणतेही एंगेजमेंट स्कोअरिंग नाही, वापरकर्त्यावर प्रशिक्षित केलेले कोणतेही मशीन-लर्निंग मॉडेल नाही. साधेपणा हाच मुद्दा आहे: नियम तपासता येण्याजोगे आहेत, थ्रेशोल्ड्स दस्तऐवजीकृत आहेत, UX परिणाम पूर्वानुमेय आहेत.

हे काय नाही

व्याप्तीबद्दल एक टीप.

fatigue मॉडेल प्रत्येक वापरकर्त्यासाठी असते, समूहासाठी नाही. आम्ही "तुमच्यासारखे वापरकर्ते" बघत नाही किंवा retention शिकण्यासाठी वापरकर्त्यांना खाली ढकलणारे प्रयोग करत नाही. हे मॉडेल व्यक्तीसाठी काम करते.

ते वापरकर्त्याच्या नियंत्रणातील settings ची जागाही घेत नाही. Quiet hours, प्रत्येक वर्गासाठी mute, आणि स्पष्टपणे सर्व push बंद करणे — हे सर्व fatigue मॉडेलपासून स्वतंत्रपणे काम करतात. दोन्ही सिस्टम एकत्र चालतात; मॉडेलच्या अंदाजापेक्षा वापरकर्त्याची स्पष्ट निवड नेहमी जिंकते.

उरलेल्या app साठी हे का महत्त्वाचं आहे

Push notifications मुळेच रोजचा एखादा सोहळा रोज टिकून राहतो. ज्या check-in app चे push अधिकार जातात, ती आपलं मुख्य retention loop गमावते. 4-tier model यासाठीच आहे, की app ने या अधिकाराचा गैरवापर करू नये आणि तो हळूहळू गमावू नये - म्हणजे थोडासाच त्रासदायक होत राहून, तेवढाच जास्त काळ.

रोजच्या सोहळ्याचा सविस्तर संदर्भ Soulwise hub इथे आहे. हा सोहळा मागणी करणारा न राहता परस्परपूरक का राहतो, याचं एक कारण म्हणजे हे fatigue model.

थोडक्यात सांगायचं तर: योग्य push ची संख्या म्हणजे अशी सर्वात मोठी संख्या, जिच्यामुळे कोणी opt-out करत नाही. प्रत्येक user साठी, दर 14 दिवसांनी ती संख्या app कशी शोधते, ते हे fatigue model ठरवतं.

नेहमीचे प्रश्न

रिटेन्शनसाठी push चे प्रमाण इतके महत्त्वाचे का असते?

Localytics आणि Urban Airship यांचा इंडस्ट्री डेटा: दिवसाला एक push साधारणपणे 88% तीन-महिन्यांच्या रिटेन्शनशी जुळतो. दिवसाला तीन push केल्यास हे प्रमाण 17 टक्के पॉइंट्सने घटते. दिवसाला पाच push केल्यास ते 34 टक्के पॉइंट्सने घटते. हा आलेख खूप तीव्र आहे.

इथे "rolling 14-दिवसांची विंडो" म्हणजे काय?

मॉडेल दररोज वापरकर्त्याचा गेल्या 14 दिवसांतील ओपन रेट पुन्हा मोजते. ही विंडो पुढे सरकते; जुना डेटा कालबाह्य होतो. यामुळे एखाद्या वाईट आठवड्यावर जास्त प्रतिक्रिया न देता अलीकडची घटलेली सहभागिता पटकन पकडली जाते.

वापरकर्ता कमी टियरमधून पुन्हा वर येऊ शकतो का?

होय. जर rolling विंडोमध्ये ओपन रेट पुन्हा थ्रेशोल्डच्या वर गेले, तर वापरकर्ता पुन्हा वर सरकतो. हे मॉडेल समतोल आहे. घट खाली आणते, सुधारणा वर नेते.

या फीचरची सर्वात वाईट आवृत्ती कोणती?

सहभाग कितीही असो, जास्तीत जास्त push पाठवणारी एक भोळसट push सिस्टम. इंडस्ट्री डेटा दाखवतो की एखाद्या app कडून आठवड्याला 2 ते 5 push मिळाल्यावर — जे त्यांना नकोच असतात — 46% वापरकर्ते push पूर्णपणे बंद करतात. हे थकवा-मॉडेल अशासाठी आहे की असे opt-out कधीच घडू नये.