ऐसे पुश नोटिफिकेशन जिन्हें लोग बंद नहीं करते: समय और डिज़ाइन

क्यों लोग पुश नोटिफिकेशन बंद कर देते हैं

कष्टप्रद नोटिफिकेशन ऐसे होते हैं जैसे कोई पूरा दिन कंधे पर टैप करता रहे, और फिर हैरान होकर देखे कि आपने छोड़ दिया। वे बाधित करते हैं, ध्यान माँगते हैं, और अक्सर कुछ वापस नहीं देते। कुछ दिनों के बाद लोग सबसे सरल काम कर लेते हैं: आपको साइलेंस कर देते हैं।

अधिकांश ऑप्ट-आउट सीधे कारणों की वजह से होते हैं। संदेश बहुत बार आते हैं, वे प्रासंगिक नहीं होते, या गलत समय पर आते हैं (रात में, काम के दौरान, या ठीक उस समय जब उपयोगकर्ता ने पहले से ही वह काम कर लिया)। कभी-कभी सामग्री अस्पष्ट या क्लिकबेइटी होती है, इसलिए उपयोगकर्ता उस पर भरोसा करना बंद कर देते हैं। और अगर पहला नोटिफिकेशन उस समय आ जाता है जब उपयोगकर्ता ऐप के मूल्य को समझ भी नहीं पाया है, तो ऐसा लगता है: "तुम मुझे ठीक से जानते भी नहीं, और तुम्हें मेरी लॉक स्क्रीन तक पहुँच चाहिए।"

पुश बंद करना मानसिक शोर कम करने का भी एक तरीका है। कई लोग पहले ही ईमेल, सोशल ऐप्स और ग्रुप चैट्स से नोटिफिकेशन थकान महसूस करते हैं। अगर आपका ऐप भी छोटे, यादृच्छिक पिंग जोड़ देता है, तो वह बाकी के साथ जोड़कर काट दिया जाता है। मोबाइल पर यह निर्णय कठोर होता है: एक बार बंद कर देने पर कई उपयोगकर्ता कभी इसे वापस नहीं खोलते।

वास्तविक लक्ष्य सिर्फ एक बार अनुमति जीतना नहीं है। यह महीनों तक अनुमति बनाए रखना है क्योंकि हर संदेश अपनी जगह कमाता है।

एक अच्छा नोटिफिकेशन परिभाषित करना आसान है: वह अपेक्षित, उपयोगी और समयानुकूल होता है। अपेक्षित का मतलब है उपयोगकर्ता अनुमान लगा सके कि उसे क्यों मिला। उपयोगी का मतलब है यह कुछ मदद करता है जिसके बारे में वे पहले से ही परवाह करते हैं। समयानुकूल का मतलब है यह तब आता है जब यह मदद कर सके, न कि सिर्फ जब आपकी प्रणाली तैयार हो।

जो पैटर्न आमतौर पर ऑप्ट-आउट ट्रिगर करते हैं वे अनुमानित हैं: पहले लॉन्च पर बिना स्पष्ट कारण के अनुमति माँगना, बिना व्यक्तिगत मूल्य वाले "हम आपको मिस कर रहे हैं" संदेश भेजना, उपयोगकर्ता के दो बार अनदेखा करने पर वही रिमाइंडर बार-बार भेजना, नियमित अपडेट के लिए urgency शब्दों का उपयोग, और मार्केटिंग ब्लास्ट्स को महत्वपूर्ण अलर्ट के साथ एक ही चैनल में मिलाना।

यदि आप पुश को एक सुविधा मानते हैं, तो उपयोगकर्ता इसे लाभ समझेंगे। यदि आप इसे मुफ्त विज्ञापन स्थान की तरह मानते हैं, तो उपयोगकर्ता इसे स्पैम समझेंगे।

कौन ऑप्ट-इन करने को तैयार होता है

लोग तब "Allow" दबाते हैं जब उन्हें विश्वास होता है कि नोटिफिकेशन उनकी मदद करेगा, ऐप की मदद नहीं। उन पुश नोटिफिकेशनों को पाना जो लोग डिसेबल नहीं करते, सबसे आसान तरीका है कि अनुमति को एक मूल्य-निर्देशन के रूप में ट्रीट करें: आप कुछ विशिष्ट वादा करते हैं, और फिर लगातार उसे पूरा करते हैं।

अनुमति माँगने से पहले वादा सादे शब्दों में कहें। "अप-टू-डेट रहें" जैसे अस्पष्ट वाक्यों से बचें। इसके बजाय बताएं क्या आएगा, यह क्यों महत्वपूर्ण है, और उपयोगकर्ता इसे कैसे नियंत्रित कर सकता है। एक अच्छा प्री-पर्मिशन स्क्रीन तीन चीज़ों का उत्तर देता है: आप क्या भेजेंगे (ऑर्डर स्टेटस, रिमाइंडर, प्राइस ड्रॉप, सुरक्षा अलर्ट), यह कितनी बार होगा (और "कभि-कभार" का मतलब क्या है), और वे बाद में इसे कैसे बदल सकते हैं (प्रेफरेंस, म्यूट, क्वाइट ऑवर्स)।

जब नोटिफिकेशन उपयोगकर्ता के वास्तविक लक्ष्य से मेल खाते हैं तो ऑप्ट-इन्स बढ़ते हैं। सोचें कि वे क्या हासिल करने की कोशिश कर रहे हैं, न कि आप क्या प्रमोट करना चाहते हैं।

लोग ठोस मूल्य के लिए नोटिफिकेशन स्वीकार करने की अधिक संभावना रखते हैं: बचत ("Price dropped"), रिमाइंडर ("आपकी नियुक्ति 2 घंटे में है"), अपडेट ("आपकी डिलीवरी 10 मिनट दूर है"), सुरक्षा ("नई साइन-इन"), या प्रगति ("आपने अपना साप्ताहिक लक्ष्य पूरा किया")।

शुरू में उम्मीदें सेट करें, भले ही वह कम "सेल्सी" लगे। अगर आप सप्ताह में पाँच संदेश भेजते हैं, तो कह दें। अगर यह ट्रिगर-ओनली है (जैसे शिपिंग अपडेट), तो वह भी बताएं। आश्चर्य अविश्वास पैदा करते हैं, और अविश्वास ऑप्ट-आउट में बदल जाता है।

सिस्टम प्रॉम्प्ट दिखाई देने से पहले मूल्य का एक छोटा सा उदाहरण दिखाएँ। एक यथार्थवादी उदाहरण एक पैराग्राफ की तुलना में ज्यादा असरदार हो सकता है:

"Sample notification: Your package is out for delivery - arriving between 3:10 and 3:40 PM."

यह एक पंक्ति लोगों को उस क्षण की कल्पना करने में मदद करती है जब यह उन्हें समय बचाएगा, और यह संकेत देती है कि आप उन्हें स्पैम नहीं करने वाले हैं।

ऐसी अनुमति का समय जो स्वाभाविक लगे

ज़्यादातर लोग नोटिफिकेशन से नफरत नहीं करते। उन्हें सिर्फ इसलिए परेशान होना पसंद नहीं कि उन्हें बहुत जल्दी पूछा जा रहा हो, इससे पहले कि वे समझ पाएँ कि उन्हें क्या मिलेगा। परमिशन का समय अक्सर फर्क बनाता है कि पुश नोटिफिकेशन लोग बंद नहीं करते या हमेशा के लिए बंद कर देते हैं।

एक सरल नियम काम करता है: उसी समय पूछें जब उपयोगकर्ता ने कोई ऐसा काम किया हो जो उनकी रुचि साबित करे। जब कोई आइटम सेव करता है, किसी टॉपिक को फॉलो करता है, ऑर्डर बुक करता है, या वर्कआउट पूरा करता है, तो उसने आपको बताया कि उसके लिए क्या महत्वपूर्ण है। उसी क्षण अपडेट ऑफ़र करने का सही समय है जो उस क्रिया से जुड़ा हो।

एक भरोसेमंद पैटर्न है सिस्टम परमिशन प्रॉम्प्ट से पहले एक सॉफ्ट-आस्क स्क्रीन। इसे छोटा और विशिष्ट रखें: वे क्या प्राप्त करेंगे, कितनी बार, और यह कैसे मदद करता है। फिर दो स्पष्ट बटन रखें: "Allow notifications" और "Not now." केवल तब सिस्टम प्रॉम्प्ट दिखाएँ जब वे "Allow" चुनें। यह आश्चर्य को हटाता है और अपेक्षाएँ सेट करता है।

अच्छे क्षण आम तौर पर किसी जीत के तुरंत बाद होते हैं (ऑर्डर प्लेस हुआ, लक्ष्य पूरा हुआ), तुरंत उस बाद जब उन्होंने फॉलो या सब्सक्राइब किया, जब उन्होंने सेव या बुकमार्क किया, जब उन्होंने रिमाइंडर सेट किया या किसी चीज़ को ट्रैक करना शुरू किया, या जब उन्होंने कोई फीचर ऑन किया जिसे अपडेट्स चाहिए।

खराब क्षण वे होते हैं जब उपयोगकर्ता व्यस्त, चिंतित या संदेह में होते हैं। पहले लॉन्च पर पूछना एक सामान्य गलती है क्योंकि तब भरोसा नहीं होता। साइनअप के दौरान पूछना भी जोखिम भरा है क्योंकि लोग फ़ॉर्म, पासवर्ड और वेरिफिकेशन से गुजर रहे होते हैं।

अगर वे ना कहते हैं, तो उन्हें दंडित मत करें और बार-बार प्रॉम्प्ट न दिखाएँ। सुखद तरीके से रिकवर करें। पुष्टि करें कि वे ऐप को सामान्य रूप से उपयोग कर सकते हैं, और सेटिंग्स में फीचर के पास बाद में एक शांत विकल्प दिखाएँ। उदाहरण के लिए: "जब आपकी सेव की हुई आइटम बदलती है तो नोटिफ़ाइ करें" के साथ एक टॉगल, ताकि विकल्प वास्तविक लाभ से जुड़ा लगे।

ठोस उदाहरण: एक रिसेल ऐप उपयोगकर्ताओं को "size 8 boots" के लिए सर्च सेव करने देता है। ठीक जब वे "Save search" टैप करते हैं, एक स्क्रीन कहती है, "नए मैच आने पर अलर्ट चाहेंगे? हम अधिकतम 1 प्रतिदिन भेजेंगे।" यह अनुरोध योग्य लगता है क्योंकि यह उस चीज़ से जुड़ा है जिसे उपयोगकर्ता ने अभी माँगा था।

नोटिफिकेशन प्रेफरेंस सेंटर डिज़ाइन करना

एक अच्छा प्रेफरेंस सेंटर आपका सेफ़्टी वॉल्व होता है। यह लोगों को सिस्टम स्तर पर नोटिफिकेशन बंद करने से रोकता है क्योंकि वे चीज़ों को ऊपर-नीचे कर सकते हैं बिना फँसे हुए महसूस किए।

तीन नियंत्रणों के साथ शुरू करें जिन्हें अधिकांश लोग जल्दी समझ सकें: टॉपिक्स, फ़्रीक्वेंसी, और क्वाइट ऑवर्स। टॉपिक्स उन्हें चुनने देते हैं कि वे वास्तव में किसके बारे में परवाह करते हैं। फ़्रीक्वेंसी उस वास्तविक प्रश्न का उत्तर देती है जो कई ऑप्ट-आउट्स के पीछे होता है: "आप मुझे इतना क्यों संदेश भेज रहे हैं?" क्वाइट ऑवर्स सबसे तेज़ रास्ते को रोकते हैं जिससे डिसेबल होता है: गलत समय पर एक बज।

शामिल करने के लिए नियंत्रण (और उन्हें कैसे लेबल करें)

विकल्पों को छोटा और साफ़ रखें। अगर आप 20 टॉगल्स ऑफर करते हैं, तो लोग उन्हें मैनेज नहीं करेंगे, वे बस आपको बंद कर देंगे।

एक छोटा सेट लक्ष्य बनाएं जैसे: टॉपिक कैटेगरी (ऑर्डर, रिमाइंडर, सुरक्षा, प्रोडक्ट अपडेट — ऐसे शब्द जिनका उपयोग उपयोगकर्ता करते हैं), फ़्रीक्वेंसी विकल्प (इंस्टेंट, डेली डाइजेस्ट, वीकली डाइजेस्ट), क्वाइट ऑवर्स (डिवाइस के समय के अनुसार टाइम विंडो), चैनल विकल्प (पुश बनाम ईमेल बनाम इन-ऐप अलर्ट), और एक पॉज़ विकल्प (24 घंटे या 7 दिनों के लिए स्नूज़)।

डिफ़ॉल्ट्स मायने रखते हैं। उन्हें सहायक पर रखें पर आक्रामक नहीं। कई उत्पादों में एक सुरक्षित डिफ़ॉल्ट यह है: महत्वपूर्ण अलर्ट ऑन (सुरक्षा या ट्रांज़ैक्शन स्टेटस), मार्केटिंग-स्टाइल अपडेट्स ऑफ, और जहाँ उपयुक्त हो फ़्रीक्वेंसी डाइ gest पर सेट। अगर सब कुछ डिफ़ॉल्ट रूप से ऑन है, तो आप पहले दिन ही नोटिफिकेशन थकान बना रहे हैं।

इसे कहाँ दिखाएँ

प्रेफरेंस को गहरे सेटिंग्स मेन्यू में छुपाएँ मत। उन्हें वहाँ रखें जहाँ लोग स्वाभाविक रूप से देखेंगे जब उन्हें परवाह होगी।

मुख्य क्रियाओं के बाद एक छोटा प्रॉम्प्ट ऑफर करें जैसे: "क्या आप इस बारे में अपडेट चाहते हैं?" और उन्हें सीधे टॉपिक और फ़्रीक्वेंसी विकल्प पर भेज दें। उदाहरण के लिए किसी ने ऑर्डर दिया, तो उन्हें "Order status" पुश सक्षम करने दें जबकि "Promos" ऑफ रहे।

इसे अकाउंट/सेटिंग्स के अंदर और किसी भी जगह जहां नोटिफिकेशन दिखाई देती है वहाँ भी आसान बनाएं (उदाहरण: इन-ऐप इनबॉक्स के पास "Manage notifications")। अगर कोई परेशान है, उन्हें 10 सेकंड से कम में "pause" या "less often" विकल्प मिलना चाहिए, बजाय इसके कि वे सिस्टम टॉगल तक जाएँ।

अगर आप Koder.ai के साथ प्रोडक्ट बनाते हैं, तो प्रेफरेंस सेंटर को फर्स्ट-क्लास फीचर मानें, न कि नोट के रूप में। एक ऑप्ट-इन बनाए रखना उसे फिर से जीतने से सस्ता है।

ऐसा संदेश डिज़ाइन जो उपयोगकर्ता भरोसा करें

लोग नोटिफिकेशन तब चालू रखते हैं जब संदेश मददगार कंधे पर हल्का टैप लगे, न कि ध्यान खींचने की कोशिश। सबसे अच्छे पुश वे हैं जो स्पष्ट होते हैं कि वे क्यों आए और व्यक्ति आगे क्या कर सकता है।

इन्सान की तरह लिखें। छोटे, सादे शब्दों का उपयोग करें, और महत्वपूर्ण विवरण पहले रखें। "Your report is ready" बेहतर है बनाम "New update available." विशिष्ट होना चालाक होने से बेहतर है।

एक संदेश का एक ही उद्देश्य रखें। अगर एक नोटिफिकेशन दो काम करने की कोशिश करता है (समाचार + प्रोमो + रिमाइंडर), तो वह विज्ञापन जैसा लगता है और लोग उसे नजरअंदाज करना सीख जाते हैं। अगर आपके पास और कहना है, तो कम नोटिफिकेशन भेजें और बाकी ऐप में सँभालें।

पर्सनलाइज़ेशन कमाने पर ही करें। इसे उस चीज़ पर आधारित रखें जो व्यक्ति ने स्पष्ट रूप से की, न कि जो आपने अनुमान लगाया।

उदाहरण के लिए, अगर किसी ने कल सोर्स कोड एक्सपोर्ट किया, तो "Export finished. Your ZIP is ready" समझ में आता है। अगर आप किसी ऐसे व्यक्ति को भेजते हैं जिसे कभी मोबाइल के लिए नहीं पूछा, "Build a mobile app today?" अजीब और परेशान करने वाला लगेगा।

अत्यावश्यकता ठीक है। दबाव नहीं। असली urgency बिना नाटक के परिणाम बताती है:

• अच्छा: "Payment failed. Update your card to avoid losing access tomorrow."
• बुरा: "Last chance! Act now!"

समय का महत्व जितना लोग सोचते उससे अधिक है। गलत घंटे में उपयोगी संदेश भी परेशानी बन जाता है। स्थानीय समय का सम्मान करें, और सामान्य नींद के घंटों से बचें। काम से संबंधित उत्पादों के लिए, जब तक वाकई जरूरी न हो, सामान्य कामकाजी घंटों के भीतर रहने की कोशिश करें।

एक सरल टेम्पलेट जो काम करता है

एक सुसंगत संरचना उपयोगकर्ताओं को आपके स्टाइल पर भरोसा करना सिखाती है:

• क्या हुआ (1 छोटी पंक्ति)
• क्यों यह मायने रखता है (वैकल्पिक, 1 छोटी वाक्यांश)
• क्या करना है (एक स्पष्ट क्रिया)

Koder.ai जैसे उत्पाद के लिए उदाहरण: "Deployment failed. Check logs to retry." यह सीधा है, यह उपयोगकर्ता की एक की गई क्रिया से मेल खाता है, और यह सब कुछ अत्यावश्यक होने का नाटक नहीं करता।

जब संदेश विशिष्ट, अपेक्षित और समयानुकूल होते हैं, तो उपयोगकर्ता नोटिफिकेशनों को उत्पाद का हिस्सा अनुभव करते हैं, न कि शोर।

चरण-दर-चरण: अपने नोटिफिकेशन सिस्टम की योजना बनाएं

यदि आप ऐसे पुश चाहते हैं जिन्हें लोग डिसेबल न करें, तो योजना उतनी ही मायने रखती है जितनी कॉपी। एक छोटी योजना आपको "जो समझ में आता है" भेजने से रोकती है और अनजाने में थकान पैदा करने से बचाती है।

1) नोटिफिकेशन इन्वेंटरी बनाएं

आप जो भी पुश भेज सकते हैं, उसकी सूची बनाएं, जिनमें स्पष्ट (ऑर्डर अपडेट, रिमाइंडर) और "शायद बाद में" वाले (डाइजेस्ट, प्रोमो) शामिल हों। हर एक को एक कामचलाऊ नाम दें ताकि आप स्पष्ट रूप से बात कर सकें।

हर नोटिफिकेशन के लिए लिखें: यह किसलिए है, किसकी मदद करता है, और उपयोगकर्ता ने इसे देखकर क्या करना चाहिए। यदि आप इन्हें एक वाक्य में नहीं बता सकते, तो यह संकेत है कि इसे भेजने लायक नहीं हो सकता।

2) संदेशों को उद्देश्य के अनुसार समूहित करें

अपनी इन्वेंटरी को कुछ मानव-समझने योग्य बकेट्स में समूहित करें। कई ऐप्स के लिए ये ज़्यादातर ज़रूरतें कवर करते हैं: रिमाइंडर (जिसका उपयोगकर्ता ने माँगा), अपडेट (स्थिति परिवर्तन), प्रोमो (बिक्री, अपसेल, मार्केटिंग), सुरक्षा/खाता (सिक्योरिटी अलर्ट, पॉलिसी परिवर्तन), और टिप्स/एजुकेशन (केवल यदि उपयोगकर्ता स्पष्ट रूप से चाहते हों)।

ये समूह आपके प्रेफरेंस सेंटर UX की रीढ़ बन जाते हैं। उपयोगकर्ता 25 टॉगल्स नहीं चाहते; वे 3 से 6 ऐसे विकल्प चाहते हैं जो स्पष्ट लगें।

3) ट्रिगर्स और सीमाएँ तय करें

प्रत्येक संदेश के लिए परिभाषित करें कि क्या ट्रिगर है और क्या सीमाएँ हैं। ट्रिगर्स यह बताते हैं "कब यह प्रासंगिक है?" सीमाएँ बताती हैं "हम स्पैम कैसे टालते हैं?"

एक व्यावहारिक सेट है: प्रति दिन अधिकतम, प्रति सप्ताह अधिकतम, और एक शांत विंडो (उदा., उपयोगकर्ता के स्थानीय समय में रात में कोई पुश नहीं)। यह भी तय करें कि जब कई नोटिफिकेशन एक साथ हों तो क्या होगा: कौन सा जीतता है और कौन से ड्रॉप कर दिए जाते हैं।

4) टेम्पलेट ड्राफ्ट करें और उन्हें उत्पाद जैसी नाम दें

प्रत्येक नोटिफिकेशन के लिए एक छोटा टेम्पलेट बनाएं: शीर्षक, बॉडी, और टैप एक्शन। इसका नाम उस तरह रखें जैसे उपयोगकर्ता इसे बताएगा, न कि आंतरिक कोड के जैसा। "Delivery update" बेहतर है बनाम "SHIP_STATUS_CHANGED_V2."

यह नामकरण अनुशासन तब काम आता है जब आप ऑप्ट-इन संदेश और सेटिंग्स बना रहे हों, और जब सपोर्ट को यह समझाना हो कि उपयोगकर्ता को क्या मिला था।

5) असली परिदृश्यों के साथ QA करें

अपनी योजना को अलग-अलग वास्तविक यात्राओं के साथ टेस्ट करें, न कि अकेले संदेशों के। एक नए उपयोगकर्ता (कम भरोसा), एक लौटे हुए उपयोगकर्ता (कम आश्चर्य चाहिए), और एक पावर उपयोगकर्ता (उच्च वॉल्यूम, नियंत्रण चाहिए) के परिदृश्यों से गुजरें। एक केस शामिल करें जहाँ कोई प्रोमो बंद कर देता है पर सुरक्षा अलर्ट चालू रखता है, और एक केस जहाँ कोई 30 दिनों के लिए निष्क्रिय हो जाता है।

यदि किसी परिदृश्य में पुश का बर्स्ट, भ्रमित करने वाला समय, या ऐसे संदेश हैं जो बहुत ज्यादा मानते हैं, तो अनुमति माँगने से पहले ट्रिगर बदलें या सीमाएँ कड़ी करें।

सामान्य गलतियाँ जो ऑप्ट-आउट का कारण बनती हैं

ज़्यादातर लोग नोटिफिकेशन से नफरत नहीं करते। उन्हें आश्चर्य, अव्यवस्था, और ऐसे संदेश पसंद नहीं जो कंपनी के लिए भेजे गए लगें, न कि उनके लिए। ऑप्ट-इन को एक बार की जीत बजाय एक चल रही रिश्ते के रूप में लेने का सबसे तेज़ तरीका भरोसा खोना है।

एक आम गलती है ऐप खुलते ही अनुमति माँगना, इससे पहले कि व्यक्ति ने कुछ किया हो। बिना संदर्भ के, यह अनुरोध यादृच्छिक लगता है, इसलिए उपयोगकर्ता इसे अस्वीकार कर देता है या स्वीकार कर के बाद में पछताता है। बेहतर नियम है: पहली "हाँ" कमाने के लिए एक स्पष्ट लाभ के साथ वही समय चुनें जब वह मायने रखता हो।

एक और भरोसा तोड़ने वाली बात वॉल्यूम है। कई टीमें किसी के ऑप्ट-इन होते ही उन्हें सक्रिय करने के लिए संदेशों का बर्स्ट भेजती हैं। इससे आम तौर पर नोटिफिकेशन थकान होती है, और उपयोगकर्ता अगला कदम सभी कुछ बंद कर देना होता है। यदि आपको शुरुआती संदेश भेजने ही हैं, तो उन्हें कम, विशिष्ट और उपयोगकर्ता के किए गए कार्य से जुड़े रखें।

अस्पष्ट कॉपी भी ऑप्ट-आउट को बढ़ाती है। "Check this out" या "Don't miss this" जैसे संदेश लोगों को ऐप खोलने पर मजबूर करते हैं ताकि वे जान सकें कि उन्हें किसलिए बाधित किया गया। यदि मूल्य वास्तविक है, तो साधारण शब्दों में बताइए।

समय संबंधी गलतियाँ भी उतनी ही नुकसानदेह हैं। अगर आप टाइम ज़ोन की अनदेखी करते हैं, तो आप लोगों को मीटिंग, डिनर, या नींद के दौरान जगाते हैं। एक भी 3 बजे का पिंग आपके सभी अलर्ट खोने का कारण बन सकता है।

अंत में, प्रेफरेंस को आसान बनाइए। अगर केवल विकल्प "सब" या "कुछ नहीं" हैं, तो "कुछ नहीं" जीतता है। लोगों को बिना खोजे पॉज़ करने का तरीका भी चाहिए।

ज्यादातर ऑप्ट-आउट के पीछे पैटर्न सुसंगत हैं: परमिशन प्रॉम्प्ट बहुत जल्दी आता है, पहले 24-72 घंटों में बहुत सारे नोटिफिकेशन आते हैं, संदेश बिंदु छुपाते हैं, भेजा गलत स्थानीय समय पर होता है, और कोई सरल नियंत्रण नहीं (पॉज़, क्वाइट ऑवर्स, टॉपिक विकल्प)।

उदाहरण: एक शॉपिंग ऐप तीन दिनों तक सुबह 7 बजे "Big news!" भेजता है, बिना किसी तरीके के प्रोमो को म्यूट किए जाने के साथ जबकि ऑर्डर अपडेट चालू हैं। उपयोगकर्ता पूरी तरह से नोटिफिकेशन बंद कर देता है, जिसमें सहायक ones भी शामिल हैं।

भेजने से पहले जल्दी जाँचें

भीجने से पहले 30 सेकंड रुकें। अधिकांश ऑप्ट-आउट ऐसे संदेश के बाद होते हैं जो अनपेक्षित, अस्पष्ट, या बहुत बार लगे।

5-सेकंड प्रासंगिकता परीक्षण

एक प्रश्न पूछें: क्या उपयोगकर्ता इस समय इसकी उम्मीद कर रहा होगा?

एक ऑर्डर शिप होने पर डिलीवरी अपडेट समझ में आता है। किसी ने जो आइटम अभी खरीदा, उसके अगले दिन प्रमो भेजना नहीं। एक त्वरित चेकलिस्ट उपयोग करें:

• क्या यह उपयोगकर्ता द्वारा अभी किए गए किसी काम से मेल खाता है?
• क्या वे इसे पहले पंक्ति से समझ सकते हैं बिना खोले?
• क्या यह उपयोगकर्ता के स्थानीय समय में उपयुक्त लैंड करेगा और क्वाइट ऑवर्स बचाएगा?
• क्या इस प्रकार के संदेश की कितनी बार सीमा है?
• अगर उन्हें यह पसंद नहीं आया, क्या वे इस श्रेणी को सेटिंग्स में बंद कर सकते हैं?

फिर संदेश को एक अजनबी की तरह पढ़ें। अगर मूल्य तुरंत स्पष्ट नहीं है, तो पहली पंक्ति फिर से लिखें। अगर इसे बहुत सन्दर्भ चाहिए, तो शायद यह पुश नोटिफिकेशन नहीं होना चाहिए।

थकान रोकने वाले टाइमिंग और कंट्रोल चेक

दो बातें चुपचाप थकान को बढ़ाती हैं: गलत समय और भागने का कोई रास्ता न होना। स्थानीय समय आप जितना समझते उससे अधिक मायने रखता है। आपका 9 बजे का भेजना उनके लिए 2 बजे रात हो सकता है, और एक अनचाहा जागना आपको चैनल खोवा सकता है।

फ़्रीक्वेंसी कैप्स दूसरे गार्डरेल हैं। प्रति श्रेणी एक छत तय करें (उदा., प्रति सप्ताह 2 प्रोमो से अधिक नहीं), फिर इसका पालन करें भले मार्केटिंग उत्साहित हो। जैसे ही आप अपनी ही नियम तोड़ते हैं, उपयोगकर्ता मान लेते हैं कि यह लगातार होगा।

अंत में, पुष्टि करें कि प्रेफरेंस सेंटर में यह सटीक श्रेणी मौजूद है। एक त्वरित सैनीटी टेस्ट: अगर कोई शिकायत करे, क्या सपोर्ट उन्हें 10 सेकंड के अंदर बता पाएगा कि इसे कहाँ बदला जाए? अगर नहीं, तो आप एक संदेश भेज रहे हैं जिस पर आप खड़े नहीं हो सकते।

उदाहरण: किसी ने फ्लाइट्स ब्राउज़ कीं, एक एकल प्राइस-ड्रॉप अलर्ट सहायक है। एक ही दिन में तीन अलर्ट, बिना "price drops" म्यूट करने की क्षमता के, स्पैम जैसा लगेगा चाहे डील वास्तविक हों।

एक यथार्थवादी उदाहरण: बिना झिझक के ऑप्ट-इन कमाना

कल्पना करें एक भोजन योजना ऐप की। वह पुश ऑप्ट-इन्स चाहता है, लेकिन साथ ही जानता है कि खराब पहली छाप जल्दी डिसेबल का कारण बनती है।

पहले सेशन पर, ऐप पहले उपयोगकर्ता की मदद करता है। वह उन्हें रेसिपी खोजने, पसंदीदा सेव करने, और एक सरल साप्ताहिक योजना बनाने देता है। कोई परमिशन पॉप-अप नहीं। इसके बजाय, यह एक छोटा नोट दिखाता है जैसे, "आप बाद में रिमाइंडर पा सकते हैं यदि आप चाहें।" उपयोगकर्ता ध्यान कार्य पर रहता है, न कि सिस्टम डायलॉग पर।

ऐप जिस क्षण पूछने का अधिकार कमाता है वह किसी स्पष्ट कार्रवाई से जुड़ा होता है। उपयोगकर्ता ने जब 3 रेसिपी सेव कीं, तब यह एक नरम स्क्रीन दिखाता है (यह अभी भी OS प्रॉम्प्ट नहीं है): "क्या आप खाना बनाने के समय याद दिलाना चाहेंगे? चुनें कि आप क्या चाहते हैं।" यदि उपयोगकर्ता "हाँ" टैप करता है, तो ऐप परमिशन अनुरोध ट्रिगर करता है। यदि वे "अभी नहीं" टैप करते हैं, तो ऐप पीछे हट जाता है और सामान्य रूप से काम करता रहता है।

अगली स्क्रीन एक सरल प्रेफरेंस सेंटर है जिसमें सादा भाषा और समझदार डिफ़ॉल्ट हैं। यह कुछ विकल्प देता है: खाने की रिमाइंडर (योजना किए गए डिनर पर), नई रेसिपीस (साप्ताहिक डाइजेस्ट), और डील्स (केवल अगर उपयोगकर्ता चाहें)। प्रत्येक विकल्प फ़्रीक्वेंसी समझाता है। उदाहरण: "Meal reminders: up to 1 per day on days you planned a meal." "New recipes: once a week." डील्स डिफ़ॉल्ट रूप से बंद हैं।

एक सप्ताह बाद, परिणाम सामान्य "लॉन्च पर पूछो" तरीके से अलग दिखते हैं। कुल मिलाकर कम लोग ऑप्ट-इन करते हैं, पर जो करते हैं वे खुश होते हैं। भेजे जाने वाले संदेश कम होते हैं क्योंकि ऐप केवल उन लोगों को पिंग करता है जिन्होंने उस प्रकार का संदेश माँगा था, चुनी हुई आवृत्ति पर। इससे कम डिसेबल और कम "सब बंद करो" क्षण होते हैं।

यही तरीका है जिससे आप ऐसे पुश नोटिफिकेशन पा सकते हैं जिन्हें लोग बंद नहीं करते: अनुमति के अनुरोध को उपयोगकर्ता की पहले हुई जीत से जोड़ें, और सुनिश्चित करें हर संदेश कुछ ऐसा लगे जो उन्होंने व्यक्तिगत रूप से माँगा हो।

मापें, सुधारें, और अगले कदम तय करें

नोटिफिकेशनों को एक उत्पाद फीचर की तरह ट्रीट करें: क्या होता है मापें, एक चीज़ बदलें, और तेजी से सीखें।

शुरू में उन परिणामों को ट्रैक करें जो बताते हैं कि आप भरोसा कमा रहे हैं या जला रहे हैं। सिर्फ ओपन पर मत रुकें। आपको लागत पक्ष भी चाहिए:

• ऑप्ट-इन दर (स्क्रीन, क्षण, और उपयोगकर्ता खंड के अनुसार)
• डिसेबल दर (विशिष्ट नोटिफिकेशनों के बाद और समय के साथ)
• ओपन दर (और डाउनस्ट्रीम क्रियाएँ, सिर्फ टैप नहीं)
• चर्न संकेत (अनइंस्टॉल, कम सत्र, ईमेल अनसब्सक्राइब)
• प्रेफरेंस संपादित करने वाले (कौन श्रेणियाँ बंद करते हैं बनाम सब कुछ बंद करते हैं)

अगला, टॉप अपराधियों की समीक्षा करें। पैटर्न खोजें: कोई विशिष्ट श्रेणी, टाइम विंडो, या दोहराए जाने वाला टेम्पलेट जो डिसेबल से पहले आता है। हर नोटिफिकेशन को सरल कारण लेबल दें (order update, reminder, promo) ताकि आप जवाब दे सकें: "कौन से संदेश 1,000 भेजने पर सबसे ज़्यादा ऑप्ट-आउट कारण बनते हैं?" पहले उन्हें ठीक करें।

बड़े रीलॉन्च्स के बजाय छोटे टेस्ट चलाएँ। एक समय में एक वेरिएबल बदलें: बाद में पूछना (एक स्पष्ट सफलता क्षण के बाद), कॉपी फिर से लिखना ताकि लाभ विशिष्ट हो, प्रति श्रेणी फ़्रीक्वेंसी कैप, जरूरी और अच्छा-है-जानकारी को अलग करना, और शुरू में कम श्रेणियाँ सक्षम रखना।

प्रेफरेंस को दृश्यमान और संपादनीय रखें। यदि उपयोगकर्ता किसी प्रकार के संदेश को जल्दी म्यूट कर सकते हैं, तो वे सब कुछ बंद करने की संभावना कम रखते हैं। एक उपयोगी नियम: कोई भी नोटिफिकेशन प्रेफरेंस सेंटर से 2 टैप या कम में संपादित होना चाहिए।

यदि आप तेज़ी से आगे बढ़ना चाहते हैं, तो अनुमति फ्लो और प्रेफरेंस सेंटर को Koder.ai (koder.ai) में बनाकर और इटररेट करके आप बदलाव जल्दी भेज सकते हैं, फिर जब आप तैयार हों तो स्रोत को एक्सपोर्ट कर लें।